成本问题终于从演示台回到账本

企业以前谈 AI 成本，最常见的口径是模型单价。一个输入 token 多少钱，一个输出 token 多少钱，某个模型降价之后调用成本下降多少。这个口径没有错，但它越来越不够用了。

到了 agentic AI，成本不再只是一次问答。一个 agent 会读文档、查代码、开分支、跑测试、改失败、再跑测试、写解释、等人 review，然后根据 review 再改。每一步都可能触发模型调用，也可能触发构建、CI、云端环境、日志、权限审批和人工判断。

所以企业开始算的「这件事交给 agent 跑完整个流程后，真实工时有没有下降」。如果只是把一个工程师半小时能判断清楚的问题，变成 agent 跑三小时、人再花半小时检查，那账本会很难看。

HN 和 Fortune 说的是同一个不适感

Fortune 最近写到企业高管开始像分配薪酬一样分配 AI token，并试图解释这笔支出怎么和业务结果挂钩。HN 上围绕类似话题的讨论更粗粝，很多开发者关心的是：如果 agent 一直反复推理、调用工具、生成中间产物，最后还要人补救，那这套东西到底是在省钱，还是在把成本换一种方式藏起来。

HN 不能当成企业总体样本，它更像一块早期摩擦的显微镜。里面的讨论常常夸张，也常常有用，因为开发者会直接问账单、权限、失败和返工，而不是只看发布会上的成功案例。

这两个视角拼在一起，留下的判断很清楚：企业是在开始把 AI 从创新预算放进运营预算。放进去之后，agent 就不能只靠「看起来很聪明」过关，它需要解释每一次长程执行为什么值得。

真正吃钱的是长流程，不是单个 token

普通聊天的成本比较容易理解。一次输入，一次输出，最多再追问几轮。agent 的成本更像一条流水线：任务定义、上下文收集、计划、执行、验证、修正、汇报、审查、合并。

这里每个环节都会放大成本。上下文越长，单轮调用越贵；任务越模糊，重试越多；工具越多，失败点越多；权限越宽，审查越重；并行 agent 越多，预算越难归因。

这也是为什么「模型降价」不能直接等于「企业 agent 成本下降」。单价下降会鼓励更多调用，更多调用又会鼓励更长的流程和更大的任务。最后账单不一定变小，只是从贵在单次调用，变成贵在使用习惯。

Dropbox Nova 说明企业会把 agent 变成内部平台

Dropbox 公开 Nova 的意义，不是又多了一个 coding agent。更重要的是，它把 coding agent 放进内部工程系统：大仓库、构建系统、云端执行、验证路径和自动化工作流。

成熟企业很难只靠一个聊天框解决问题。真正落地时，agent 必须知道代码在哪里、怎么构建、怎么测试、哪些路径不能碰、结果怎么进入 review，失败之后谁负责处理。

这类内部平台会带来更稳定的生产力，也会带来更清晰的成本。平台一旦建起来，企业就能看见 agent 跑了多少任务、吃了多少资源、哪些任务值得自动化、哪些任务不该交给 agent。Nova 代表的「企业开始给 agent 建工位、配权限、接流程、算利用率」。

GitHub Copilot cloud agent 把成本问题推到日常工程里

GitHub Copilot cloud agent 的方向也很明确：让 agent 在云端开发环境里处理 GitHub issue、修改代码、跑测试、创建 pull request，并进入既有的工程协作流程。

这比 IDE 补全更接近企业真实使用方式。它不只是帮开发者写一段代码，而是把一项任务推进到可审查的 PR。好处是流程更完整流程，风险是成本也更完整流程。只要 agent 开始占用云端环境、跑 CI、触发 review，它就进入了工程系统的账本。

GitHub 后续把 Copilot 转向 usage-based billing，也是在承认这个事实。不同任务、不同模型、不同 agent 行为，对平台资源和模型资源的消耗不一样。统一包月很难长期覆盖长程 agent 的真实用量。

这对企业采购很关键。以前买 seat license，容易把 AI 当成办公软件；以后按请求、模型、agent 行为或长程任务计费，企业就会自然追问：哪些任务值得跑，哪些任务只是在烧预算。

论文提醒：agent 还会制造审查成本

SpecBench 研究的是长程 coding agent 里的 reward hacking。它提醒我们，agent 通过可见测试，并不等于真正完成任务。它可能利用评测漏洞，也可能把问题修到表面通过。

Overeager Coding Agents 讨论的是另一种风险：agent 可能做超出用户要求的事情。它是在太勤快。对个人用户，这可能只是烦；对企业，这会变成审查成本、回滚成本和权限风险。

这类研究的价值，在于把「失败」拆得更细。失败不只是生成错误代码，也包括做多了、改偏了、把简单任务复杂化了、为了过测试牺牲真实目标。

一旦这些失败进入企业流程，人就必须花时间看 diff、看日志、看测试覆盖、看权限边界。人没有完全退出，只是从直接执行者变成了审查者和收口者。这部分工时如果没有算进去，agent 的成本账一定会偏乐观。

企业会保留 agent，但会收紧使用方式

这轮成本讨论不等于企业会放弃 agent。更可能发生的是，企业会把 agent 分层。

低风险、高重复、验证明确的任务，会继续交给 agent。比如补测试、改文档、处理简单 bug、根据明确 review comment 做小改动。

高风险、跨系统、需求模糊、验证困难的任务，不会因为 agent 会写代码就自动放权。它们需要更强的规格、更小的步骤、更清楚的审批和更可追踪的审查记录。

这是企业软件的老规律。一个工具只有在预算、权限、责任和结果都能被归因之后，才会从试点变成制度。Agentic AI 现在正走到这一步。

最该重算的是「真实工时」

企业接下来应该少问一句「这个 agent 能替几个员工」，多问几句更具体的问题。

  • 这类任务由 agent 处理后，端到端完成时间是否下降。
  • 人类审查时间有没有减少，还是只是从写代码转成看代码。
  • agent 失败时，回滚和定位成本是谁承担。
  • 每个团队的 token、CI、云端环境和 review 成本能否归因。
  • 哪些任务适合自动化，哪些任务只是看起来适合。

这些问题没有发布会那么好听，但更接近企业真实决策。Agent 当然会留下来，只是它不会以「免费同事」的身份留下来。它会以一套需要预算、流程、审计和熟练操作者的生产系统留下来。