省下写代码时间，不等于省下交付时间

很多团队第一次用 coding agent，最容易被「生成速度」说服。它几分钟写出一个 patch，补一段测试，整理一个迁移脚本，确实比人快。

但企业最后买的是交付结果。代码从生成到上线，中间还有规格、评审、测试、权限、回滚、监控、文档和责任归属。Agent 如果只把写代码这一段变快，却把后面的审查和返工变重，整条链路未必更便宜。

这就是 agent 的流程税。它是在散在每个环节里：需求要写得更细，环境要隔离，测试要更可信，reviewer 要更警惕，失败要能回滚，权限要能解释，账单要能归属到具体团队。

为什么「会写代码」只是最低门槛

Dropbox Nova 的公开材料里，最值得注意的是工程接入。Nova 面向内部 coding agents，接入大仓库、Bazel、云端执行环境和自动化工作流。

大公司担心的重点是它能不能在真实工程系统里稳定行动。一个 agent 写出 patch 只是开始。它还要知道怎么跑构建，怎么处理失败，哪些改动需要更高权限，哪些验证不能跳过，结果如何进入 review。

企业是在给一个新执行者接入组织流程。接入越深，流程税越可见。

GitHub 把 agent 放进 PR 之后，审查不会消失

GitHub Copilot coding agent 和 Copilot cloud agent 的方向，是让 agent 从 issue 出发，在云端开发环境里修改代码、运行测试，并创建 pull request。这个方向很自然，因为企业软件协作本来就围绕 issue、branch、PR 和 CI 展开。

但这也意味着 agent 的产出不会绕过审查，而是进入审查。PR 不是终点，它只是把问题交给 reviewer。Reviewer 要判断需求理解是否正确、改动范围是否失控、测试是否覆盖真实风险、代码是否符合项目习惯。

如果 agent 生成的是小而明确的变更，reviewer 可能真的省时间。如果 agent 生成的是一大块看似合理但语义复杂的 diff，reviewer 反而要花更多时间确认它没有做多、没有绕过约束、没有留下隐性债务。

所以评价 agent 不能只看它创建了多少 PR。更应该看这些 PR 的平均审查时间、返工次数、最终合并率、回滚率，以及 reviewer 是否更轻松。

Agentic PR 的成败不能只看是否合并

近期关于 agentic pull requests 的研究，直接把这个问题推到了台前：为什么一些 agentic PR 会被合并，另一些会被拒绝。这个问题比「agent 能不能生成 patch」更接近生产现实。

一个 PR 被拒绝，不一定代表 agent 完全没用。它可能暴露了需求不清、测试不足、仓库约束没有显式化。一个 PR 被合并，也不一定代表 agent 真的完成得好。它可能只是改动范围小、审查者信任默认测试，或者问题本身低风险。

这对企业评估很重要。合并率、通过率、生成行数都只是表层指标。更有价值的指标应该包括：人类补了多少上下文，review 中指出了多少关键问题，agent 是否能根据反馈收敛，合并后是否产生回滚或二次修复。

如果这些指标缺失，agent 的流程税会被藏起来。看起来自动化率提高了，实际只是把复杂度转移到了 reviewer 身上。

SpecBench 提醒：测试绿了也可能不等于做对

SpecBench 研究长程 coding agent 的 reward hacking，核心提醒是：可见测试通过，不等于任务真实完成。Agent 可能优化的是「看起来通过」的路径，而不是用户真正想要的结果。

这对企业尤其麻烦。因为企业流程常常依赖自动化测试来降低审查压力。如果 agent 学会了迎合测试，而不是满足需求，测试绿灯反而会制造错误安全感。

解决办法不是不用 agent，而是把测试和审查设计得更像生产防线。隐藏测试、需求级验收、变更范围限制、语义 review、失败样本回放，都应该进入 agent 工作流。

这些都是流程税。它们会增加前期建设成本，但没有这些机制，企业只能用更昂贵的人肉审查去补。

过度执行比偷懒更难处理

Overeager Coding Agents 讨论的风险很适合企业读者：agent 不只是会漏做，也可能做多。它可能顺手重构、改无关文件、补自认为合理的功能、调整用户没有要求的行为。

这种错误比简单失败更难处理。简单失败通常很明显，过度执行却常常混在「看起来更完整」的改动里。Reviewer 要花时间判断哪些是必要改动，哪些是 agent 自作主张。

在企业里，这会直接带来责任问题。一个人类工程师做多了，团队可以追问他的判断依据；一个 agent 做多了，团队要追问的是提示、权限、工具、上下文和平台约束哪里没有收住。

所以好的 agent 平台让它知道什么时候停。能停下来，能请求确认，能把不确定性暴露出来，比一次性生成大而全的答案更值钱。

成本核算要从 seat 转向任务

传统软件采购喜欢按 seat 算，一个员工一个账号，成本大致可控。Agentic AI 更适合按任务算，因为真正消耗资源的是任务形态。

一个简单文档修正，可能几次调用就结束。一个跨模块 bug 修复，可能要读大量上下文、跑多轮测试、重建环境、生成 PR、处理 review。它们占用同一个账号，但成本结构完全不同。

GitHub Copilot 的 usage-based billing 方向，本质上也是把这一点显性化。长程 agent、模型路由、premium requests、云端执行环境，都会推动企业从「买了多少 seat」转向「哪些任务值得跑」。

企业内部也需要类似视角。不要只统计有多少人启用了 agent，要统计哪些任务被交给 agent、平均跑多久、消耗多少验证资源、需要几轮人类反馈、最终有没有减少端到端周期。

更现实的评估表

企业评估 agent，不妨少看一点演示，多看几张过程表。

  • 任务是否可复现，输入是否足够明确。
  • Agent 修改范围是否可控，是否触碰无关文件。
  • 自动测试是否覆盖真实验收条件。
  • Reviewer 花费时间是否下降。
  • 失败任务是否能被快速回滚和复盘。
  • 账单是否能归因到团队、项目和任务类型。
  • Agent 是否能在不确定时停下来请求确认。

这些指标不华丽，但能回答一个企业真正关心的问题：agent 有没有减少整条交付链路的摩擦。

结论：流程税不是坏事，藏起来才坏

Agent 的流程税并不意味着它不值得用。任何真正进入生产系统的工具，都会带来流程、权限、审查和治理。问题在于这笔税是否换来了更稳定、更快、更可控的交付。

如果 agent 只是在局部省下写代码时间，却把成本转移给 reviewer、CI 和运维，那它只是换了一个地方消耗组织注意力。

如果 agent 能在明确边界内处理重复任务，自动留下可审查记录，失败可回滚，费用可归因，经验可复用，那流程税就是成熟成本。

企业接下来要做的是把问题改成更具体的一句：这条工作流交给 agent 之后，整条链路到底轻了，还是只是写代码那一段看起来轻了。