企业采购一款 AI 软件时，过去通常面对一条相对清晰的商业链路：软件厂商向企业收费，再用收入购买模型、云计算和其他基础服务。客户只需判断产品是否值得购买，不必关心每一次推理究竟由谁的账户承担。
这条边界正在发生变化。
10 月 14 日，OpenAI 发布 Amp 客户案例。Amp 是一款面向软件开发者的 AI Agent 产品，部分用户每周会消耗 100 亿 Token。案例提到，Amp 接入“Sign in with ChatGPT”后，符合条件的用户可以让部分 AI 请求使用自己 ChatGPT 套餐中包含的用量，从而更愿意把长任务交给 Agent，而不是逐次计算 Token 成本。
OpenAI 近期公布的产品说明进一步显示，这项机制把身份登录和用量授权拆成了两个独立步骤：用户可以只登录，也可以另行授权第三方应用使用套餐内符合条件的 AI 用量；用户能够按应用设置每周上限并查看消耗。当前公开规则同时明确，商业应用中的套餐用量共享仅适用于符合条件的 Go、Plus 和 Pro 用户，第三方应用仍可对订阅、基础设施、服务或高级功能单独收费。企业组织能否使用相关功能，还受组织策略与管理员设置约束。
这不是一个可以直接外推到所有企业采购的成熟模式。Amp 的信息来自供应商客户案例，没有公开用户样本、任务成功率、留存变化、收入影响、完整成本或独立验证；每周 100 亿 Token 描述的是“部分用户”，也不是典型水平。当前套餐共享的适用范围还没有覆盖企业套餐。
但它释放出一个值得企业提前研究的信号：AI 能力正在从“由应用统一购买的后台成本”，变成一种可能由员工、企业和软件厂商共同携带、授权与支付的生产要素。 当算力权益可以随用户进入不同应用，企业采购的就不再只是一个软件席位，而是一组跨平台的身份、用量、结果与责任关系。
一个软件，可能出现三张账单
在传统 SaaS 模式中，一名员工使用某个产品，企业通常只看到软件订阅费。AI 应用则可能同时产生三类费用：
如果三张账没有合并，采购团队容易得到两个相反却同样错误的结论。
一种是认为“员工已经购买了模型套餐，所以第三方应用的 AI 成本几乎为零”。事实上，模型用量只是完整成本的一部分；应用厂商仍需提供运行环境、工具连接、存储、安全和支持，企业也仍要承担治理与人工成本。
另一种是把应用订阅费与模型套餐简单相加，认为发生了重复采购。实际上，二者可能购买的是不同能力：前者负责把通用模型嵌入具体业务流程，后者提供可跨应用使用的智能供给。只有当两者都在为同一项没有差异的能力收费，才构成真正重复。
FinOps Foundation 对生成式 AI 单位经济性的建议也支持这一判断：成熟核算不应停留在每 Token 成本，而应逐步转向每次协助、每个 Agent 动作或每个业务结果的完整成本，并把成本呈现在实际消费发生的位置。
因此，企业需要把“多少钱买了多少 Token”改写为：“为了完成哪个业务结果，谁消耗了什么资源，失败和复核花了多少，最终结果是否被业务接受。”
- 应用费：为工作流、界面、数据连接、行业能力和服务支持付费；
- 模型与用量费：由应用厂商、企业统一账户或用户已有套餐承担；
- 内部交付费：包括数据准备、权限配置、人工复核、失败重试、风险治理与流程变更。
算力权益可携带后，应用厂商必须证明自己的独立价值
当基础模型用量由用户已有套餐承担时，第三方应用不能再主要依靠模型调用差价解释价格。它必须清楚回答：除了一次模型请求，自己还创造了什么不可替代的价值？
真正值得付费的部分通常来自以下几层：
这会推动 AI 软件从“卖一个带模型的界面”，转向“交付一个可验收的工作系统”。对客户而言，这反而有利：模型选择可能更灵活，基础用量更加透明，应用价值也更容易与实际结果对齐。
但企业不能据此要求所有供应商都把模型成本完全剥离。有些工作需要厂商统一选择模型、管理容量并承担服务等级；有些行业方案还依赖专用评测、缓存、微调或多模型路由。关键不在于由谁付款，而在于付款结构是否与责任结构一致。
如果模型由客户账户提供，应用厂商是否仍对结果质量负责？如果客户切换模型导致性能下降，谁负责重新验收？如果套餐达到上限，应用是停止、降级、转用厂商额度，还是产生额外费用？这些都必须在采购前写清楚。
- 对特定业务对象、术语和例外的理解；
- 与企业系统、数据和权限的可靠连接；
- 把长任务拆解、执行、检查和恢复的工作流；
- 对输出质量、过程证据和业务结果的验证；
- 安全运行、版本管理、故障响应和客户支持。
“允许使用套餐”不是简单的登录授权
OpenAI 当前设计中最值得企业借鉴的地方，是把身份登录和用量授权分开。用户登录第三方应用，并不自动意味着同意它消耗套餐资源；授权使用套餐，也不等于开放 ChatGPT 对话、记忆或 API 密钥。
这说明企业至少需要区分五类记录：
如果系统只有登录日志和月底账单，企业仍然无法判断一笔消耗是否合理。用量必须能关联到业务任务和结果，而不是只关联到某个用户。
授权也不应是一次永久同意。企业可按应用、团队、任务类别和时间设置上限，对高价值长任务开放更多资源，对未经验证的应用先给予小额度；当任务质量下降、供应商条款变化或异常消耗出现时，能够暂停授权而不必同时删除用户账号。
这与 NIST 对第三方 AI 风险的建议一致：组织应维护获准供应商和技术清单，持续评估第三方表现与变化，在合同中保留评估权，并为关键第三方系统故障准备替代和退出机制。
- 记录：需要回答的问题
- 身份记录：谁在使用应用，以个人身份还是企业身份进入？
- 权益记录：哪个套餐、额度或合同允许本次调用？授权是否仍有效？
- 用量记录：哪个应用、任务和模型消耗了多少资源？是否接近上限？
- 结果记录：请求是否完成，结果是否被接受，是否需要重试或人工修正？
- 责任记录：出错、超支、数据泄露或服务中断时，由谁响应和承担后果？
新的采购单位，不应再是“每人一个 AI 席位”
席位制适合衡量访问权，却不适合衡量 Agent 的实际工作。一名员工可能偶尔使用多个专业应用，也可能通过一个应用运行数小时任务；两个相同价格的席位，对应的资源消耗和业务价值可能相差几个数量级。
企业可以把采购拆成三种不同对象：
这样做不是为了把每一次点击都财务化，而是为了避免三种资源混在同一席位价格中。当某个应用更换底层模型或支持客户自带权益时，企业可以单独比较专业能力是否仍值得付费；当某类任务需要更强模型时，也可以增加任务预算，而不必为整个组织升级套餐。
相应地，供应商评价也应从活跃用户数转向任务结果：首次完成率、人工接管率、结果被业务接受的比例、单位有效结果成本、额度耗尽后的降级表现，以及因模型或产品变化触发的重新验收成本。
- 人的通用权益：员工可使用的基础模型、通用助手和共享用量；
- 应用的专业能力：业务工作流、连接器、行业知识、评测与服务；
- 任务的执行预算：某类任务允许消耗的模型、计算、工具和人工复核资源。
企业现在可以做一次“小范围双账试验”
即使所在企业目前还不能使用套餐共享，也可以用现有 API、云市场或多模型平台模拟这种结构。
选择一个低后果、任务边界清晰、模型消耗可观的专业应用，同时保留两种运行方式：一部分任务由供应商统一提供模型能力，另一部分由企业自己的模型账户承担。在相同任务集上比较：
试验结束后，企业应能明确区分：哪些价值来自基础模型，哪些来自应用工作流，哪些来自自身数据和人员。如果仍无法区分，就不适合立即扩大采购规模。
Amp 案例尚不能证明“用户自带 AI 用量”一定会降低企业总成本，也不能证明这一机制会成为所有商业软件的默认形态。但它让一个新的产业分工开始可见：基础模型平台可能直接向用户提供可携带的智能权益，专业应用负责把这种能力变成具体工作，企业则负责决定哪些任务值得消耗资源、谁可以授权，以及结果如何验收。
当智能可以像身份一样被带入不同应用，企业采购的重点将从“谁提供模型”转向“谁对结果负责”。真正专业的 AI 采购，不是把账单拆得越细越好，而是让每一笔用量都能找到业务目的，让每一项收费都能对应独立价值，让每一次授权都能撤回，并让任何故障都有明确责任人。
- 完成同一业务结果的完整成本，而不是标价或 Token 单价；
- 模型切换后质量、速度和人工复核是否变化；
- 供应商能否提供任务级用量、失败和重试证据；
- 额度不足、模型不可用或授权撤销时能否平稳降级；
- 数据、日志、评测集和工作流配置在退出时能否迁移。
