这条新闻最刺眼的地方不是贵

这两天 HN 上有一条讨论很容易被写歪：企业内部用 agentic AI，token 成本可能高到让管理层重新算账。最省事的写法，是把它写成「AI 也不便宜」。这句话没错，但太浅，也容易把问题带偏。

值得写的是账单背后的误判。很多团队第一次把 agent 接进工作流时，以为自己买的是便宜劳动力。跑一阵才发现，账单里付的不只是模型推理，还有一整套新流程的摩擦：描述任务、生成计划、拆子任务、跑测试、看 diff、解释失败、修提示词、重跑、再 review。

如果这些动作最后换来的是更少返工、更快交付、更低事故率，那就值得。如果只是把原来一个人半小时能说清的事情，变成三轮 prompt、两份计划、一堆中间文件和五次模型调用，那它就把忙碌换了一个形态。

企业最容易漏算的是流程成本

模型厂商喜欢把成本讲成每百万 token 多少钱。这个口径适合定价页，不适合企业算账。企业该算的是任务成本。

一个 coding agent 任务从开始到结束，至少有几类成本。第一是输入成本：人要把背景、目标、边界和验收口径讲清楚。第二是运行成本：模型要读仓库、搜文件、试方案、跑命令。第三是审查成本：人要看它改了什么、为什么改、有没有越界。第四是失败成本：跑偏以后要回滚、定位、复述问题，再开下一轮。

以前这些成本很多藏在人脑里，沟通短，返工也短。agent 进来后，它们被显性化了，变成 token、日志、计划、PR、测试报告和 review 评论。显性化不是坏事，但它会先让组织觉得「怎么更慢了」。

GitHub 把 Copilot 转向 usage-based billing，就是一个很硬的信号。普通聊天、代码补全、多小时 autonomous coding session，过去容易被塞进同一个订阅想象里。现在平台开始把更长、更重、更 agentic 的调用拆出来计量，企业也就不能继续假装「买了 seat 就等于边际成本接近零」。

这不是说 agent 不能省钱。恰恰相反，只有把任务成本看清楚，省钱才可能真实发生。否则团队很容易把一个本来应该由脚本、规则引擎或一次人工判断解决的问题，交给一个会反复读取上下文、生成解释、申请工具、等待测试、再生成新解释的 agent。

Spec 变厚，不一定说明工程变专业

HN 上另一个讨论是 spec-driven development workflow for Claude Code。它把需求、代码分析、设计、子任务和上下文清理拆成阶段。这个方向是对的，但也有一个危险：团队可能会误以为文档越多，agent 越可靠。

真实情况通常更难看。很多 spec 只是为了让模型继续工作而生成的中间物，不一定帮助人判断，也不一定帮助系统变稳定。计划写得漂亮，不代表代码改得克制；任务拆得细，不代表边界清楚；测试全绿，不代表没有 reward hacking。

所以 spec-driven 的价值，在于让关键判断提前暴露：这件事该不该做，改动范围在哪里，哪些行为明确禁止，验收标准能不能被隐藏测试或真实流程检验。不能回答这些问题的 spec，只是新的忙碌工作。

Agent 最贵的时候，是它做多了

最近有一篇论文题目很直白：Overeager Coding Agents。这个词比「幻觉」更适合形容很多生产问题。幻觉是答错；overeager 是做多。

做多的成本更难算。一个 agent 自作主张重构了不该动的模块，表面上可能测试还过了，甚至 diff 看起来挺勤奋。但 review 成本、合并风险、后续维护负担都被推高了。企业怕的重点是它太愿意把每个任务都扩大成一个工程项目。

Dropbox 做 Nova 的价值就在这里。它把 Nova 接进 monorepo、Bazel、内部验证和工作流。官方博客里最值得注意的是 Nova 被放在 Dropbox 真实的构建、测试和验证路径里。大组织需要的是限制 agent 的行动半径，让它在正确的地方花 token，而不是到处展现主动性。

PR 合并率不是一个干净指标

另一个容易误导管理层的指标，是 agent PR 有没有被合并。看起来很直观，实际上很脏。最近关于 agentic pull requests 的研究就提醒：PR 被合并或拒绝，不能直接等同 agent 成功或失败。

一个 PR 被拒，可能是技术失败，也可能是没有解释清楚、触碰了组织流程、改动时机不对、reviewer 不信任、上下文不足。一个 PR 被合，也不一定说明 agent 真懂系统，可能只是改动足够小、风险足够低、人工补救足够多。

这也是为什么企业如果只盯「agent 产出多少 PR」，很快会得到一堆漂亮但没用的数据。更该看的指标是：哪些任务适合 agent，一次通过率是多少，人工 review 花了多久，返工是否减少，事故是否下降，哪些类别的问题反复失败。

便宜的 agent，需要更贵的边界

这听起来有点反直觉：要让 agent 便宜，企业反而要先投入更贵的边界。

边界包括沙箱、权限、日志、隐藏测试、回滚、上下文管理、任务分流、模型路由和预算归因。没有这些东西，agent 看起来启动成本低，长期运行成本会变高。它会反复读错上下文、反复踩同类坑、在不该调用大模型的地方调用大模型、在不该修改的地方修改。

GitHub 的 Copilot 文档也把这一点说得很现实：cloud agent 会在临时开发环境里改代码、运行测试、创建 PR，但简单任务不一定值得交给它。这个提醒很重要。企业采用 agent 的成熟标志，重点是能判断哪些任务应该由 agent 跑完整流程，哪些任务根本不该启动这套流程。

最后的问题是怎么少用错

我不认为这轮成本讨论会让企业停止用 agent。正相反，它会把下一阶段的采用方式变得更现实。

第一阶段是试用，大家问「它会不会写」。第二阶段是扩散，大家问「能不能让更多人用」。第三阶段才刚开始，问题会变成「哪些地方不该用，哪些地方必须加边界，哪些调用根本不值得发生」。

真正成熟的团队，不会把 agent 当成无限便宜的员工，也不会因为账单变高就退回手工时代。它们会建立一套更冷的判断：把 agent 放到反馈明确、验证充分、改动半径可控、失败可回滚的地方；把它从模糊、低价值、审查成本过高的地方拿出来。

省时间这件事不会自动发生。它要靠少启动无意义任务、少生成无用中间物、少做越界改动、少让人类替模型擦屁股。到那一步，agent 才真的开始便宜。