成本从后台走到前台

传统 SaaS 的成本通常按席位、存储或调用量理解。AI 助手早期也延续了这种感觉：用户付一个月费，然后尽量多用。Agent 把这个模型推到了极限。

一个长程 Agent 任务可能读完整仓库，创建计划，反复检索，调用工具，跑测试，失败后重试，再生成解释。它消耗的不是一次回答，而是一段运行过程。

因此，成本不再只是财务后台的账单。它会直接影响用户是否敢点「开始任务」。

GitHub 的计费变化是信号

GitHub Copilot 向用量计费迁移，引发开发者讨论，背后逻辑并不难理解。补全一行代码、让 cloud agent 跑几个小时、让代码审查 agent 检查大型 PR，这些任务对供应商的成本完全不同。

问题在于用户感知没有跟上。很多人仍然用「订阅工具」的心智使用 Agent，直到月底看到额度变化，才意识到长任务的推理和上下文成本是真实存在的。

这会逼产品补上成本解释。一个成熟 Agent 不只要告诉用户能做什么，还要告诉用户这类任务大概会消耗多少、为什么消耗、有没有便宜路径。

AWS 把 token 写进执行历史

AWS Step Functions 的 AgentCore 集成里，一个细节很关键：执行历史展示 agent input、output、token usage 和 duration，并能链接到 CloudWatch 里的 turn 详情。

成本治理和可观测性会合在一起。企业不只要知道任务有没有成功，还要知道每个任务花了多少推理资源，哪些步骤最贵，失败重试消耗了多少。

这些数据会进入预算、审计和优化流程。模型路由、缓存、上下文裁剪、审批策略都会围绕它调整。

成本解释会成为体验

未来好的 Agent 产品会在任务开始前给出成本预估，在运行中显示预算消耗，在结束后给出成本解释。它还会主动建议：这个任务用大模型是否必要，能否先用便宜模型做筛选，哪些子任务适合并行，哪些步骤需要人工确认。

这听起来像财务功能，实际是产品信任。用户能理解成本，才会更愿意授权 Agent 做长任务。企业能归集成本，才会让 Agent 进入正式流程。

Agent 的能力越强，成本治理越不能藏在账单页。