翻倍且没有事后复盘：那份编码智能体带来的 CI 账单

该项支出在六周内攀升了 130%，工程团队却无人察觉。PR（拉取请求）的合入速度变快了。仪表板上的单次 PR CI 成本看起来与上季度持平。Agent 的分支在第一次尝试时通过测试（显示为绿色）的频率比人类的分支更高，这实际上反而拉低了 CI 持续时间的中位数。财务部门在季度复核中发现了这一点，将其标记为不明变动，并要求工程部门提交事后分析报告（postmortem）。工程团队无话可说 —— 既没有事故，也没有回退，更没有部署失败。仅仅是一项预算支出在仪表板显示一切正常的情况下，悄无声息地翻了一倍。

这个“事后分析报告”式的缺口本身就是一个产物。成本从以人力为主的曲线转向了以基础设施为主的曲线，而负责人力预算的团队与负责基础设施预算的团队并非同一个。Agent 没有弄坏任何东西，它只是改变了损益表（P&L）中承担这项工作的科目。

平台层面的数据在更大规模上讲述了同样的故事。GitHub 报告称，AI Agent 创建的 PR 从 2025 年 9 月的约 400 万个增长到 2026 年 3 月的 1,700 多万个，每周 Actions 计算时长从 2023 年的 5 亿分钟攀升至 2026 年单周 21 亿分钟。2026 年 6 月 1 日，Copilot 转向按需计费，并开始按照与其他工作流相同的费率针对 Actions 时长收取 Copilot 代码评审费用 —— 这是供应商在针对你财务团队所关注的同一曲线进行重新定价。账单变动是因为工作流变动了。仪表板是最后才反应出来的地方，因为仪表板是围绕不再占据主导地位的工作流设计的。

CI 曾是 O(commits) 成本；Agent 把它变成了 O(plan steps)

人类工程师在认为修改已经准备就绪或接近就绪时才会推送 commit。每个 PR 可能产生两到三次 CI 运行 —— 第一次推送时、处理评审意见后、以及 rebase 之后。CI 成本随人类提交的 commit 数量而扩展，而 commit 数量受限于人类执行 git push 的频率。

Coding Agent 不会在准备就绪时推送，它为了“查明”是否准备就绪而推送。测试不再是工作结束时的关卡，而是工作过程中的反馈信号。Agent 方案的每一次迭代都会触发一次 CI 运行，因为对 Agent 来说，这是验证其上一次编辑是否朝着目标迈进的最廉价方式。一个 PR 中有 10 个方案步骤并不罕见，20 个也不罕见。单次 PR 的成本没变，是因为“单次 PR”一直是个错误的分母。真正发生变动的分母是“单次结果对应的运行次数”，而 Agent 极大地增加了这个数值。

这正是工程仪表板所隐藏的部分。仪表板几乎总是通过“每个 PR”、“每个 commit”或“每次合并的变更”来归一化 CI 成本。这些分母中的每一个都隐含地假设创作单元是人类节奏的。当作者是 Agent 时，每一个分母都会随着分子同步膨胀，导致比例保持平稳。账单涨了，比例没变。仪表板在技术上是正确的，但在运营分析上毫无用处。

一个有用的分母应该根据 Agent 无法注水的指标来衡量 CI 成本：已发布的特性、用户可见的修复或合规性认证等外部要求。一旦你切换到这个分母，曲线就会立即显现，与财务部门的对话也会从“为什么基础设施支出增长了”转变为“由 Agent 创作的工作内容的单特性成本是多少，这是否是我们愿意支付的费率”。

归因缺口是失效模式

如果你的 CI 日志无法区分 Agent 提交的 commit 和人类提交的 commit，你就无法进行财务团队所要求的分析。你无法回答“增长是否来自 Agent”，因为数据中缺失了这一列。

这种修复在元数据层面很直接，但在实现层面却很繁琐。CI 中运行的每个作业都应标记触发它的 commit 的作者类别。该标签必须在作业入队（enqueue）时添加 —— 通过 git log 进行追溯归因总是会漏算，因为有些 commit 会被压缩（squash），有些 Agent 会以人类身份进行提交，还有些方案步骤在永不合入的临时分支上运行。在触发时捕获它，存储在作业中，并发送到追踪运行分钟数的同一个仪表板。

同样的归因问题也出现在 LLM 成本层。那些已经建立了生产环境 Agent 成本监控的从业者通常会达成一个共识：标签在请求创建时附加，绝不从日志中回溯重构。Anthropic 的 usage API 现在允许你为每个调用标记项目、团队和任务标识符；CI 的对等做法是在入队时为每个作业标记 actor=agent 或 actor=human，并将该标签传播到每个下游指标。没有标签，你只能审计成本；有了标签，你才能治理成本。

GitHub 在 2026 年 6 月推出的成本中心和人均预算功能正是为此而生。平台为你提供了一个数据列。你的工作是配置 CI 环境变量以正确填充它 —— 并留意 Agent 何时以人类身份运行，因为这会悄无声息地导致归因错误。

每作者预算不是惩罚；它是一个信号通道

当财务部门标记了偏差时，本能反应是限制某些东西。限制 Agent 的运行次数，限制每个 PR 的分钟数，限制 Agent 允许使用的模型。限制止住了亏损，但也停止了工作，且没有告诉团队需要改变什么。

每作者 CI 预算有不同的目的。它是一个信号通道。它告诉 Agent —— 或者监督 Agent 的人类 —— 内环循环（inner loop）已经变得昂贵，并且这种反馈足够早，可以在季度末审计回顾之前改变循环，而不是在事后追溯。有三种结构化模式可以在不破坏工作流的情况下产生这种信号。

第一种是分层 CI 配置，其中 Agent 的内环运行使用快速、廉价的测试子集，而完整的测试套件则保留在 PR 被标记为准备好接受人工评审的时刻。这借鉴了像 Bazel 这样的快速单体仓库（monorepo）构建系统 —— 以及 Buildkite 上的动态流水线 —— 的工作方式，允许你从 diff 中计算受影响的目标集，并仅运行与其相关的测试。Agent 获得了快速反馈。完整的测试套件在合并前仍然会运行。“Agent 迭代二十次”的成本降低了一个数量级，因为其中十九次迭代不会运行缓慢的集成层。

第二种是将成本信号反馈给 Agent 本身。如果 Agent 可以将上次 CI 运行的成本作为其观察（observation）的一部分来读取，它就可以在后续步骤中选择更便宜的验证策略 —— 运行测试子集，推迟慢速层级，或者决定阅读源代码而不是运行探针。大多数团队跳过了这一点，因为将成本传回 Agent 感觉像是过度工程。但一旦 Agent 的运行频率超过人类团队，这就是杠杆率最高的基建工作。

第三种是硬性限制，它不是在单次运行级别触发，而是在单项任务级别触发。一个预算规定“此 PR 在多次迭代中已使用了 40 分钟的 Actions 时间；该分支的下一次推送需要人工签核”，这给了人类介入的机会，而没有预先禁止迭代。这种限制不是拒绝，而是一个检查点，而检查点正是让你能够信任一个拥有真实预算的自治循环的关键。

预测模型是隐藏的假设

出问题的不是 CI 账单。鉴于新的工作负载，CI 账单的表现完全符合预期。出问题的是财务计划与分析（FP&A）团队运行的预测模型。该模型建立在 CI 成本随员工人数和交付功能量线性增长的假设之上，因为一个人每天只能推送有限数量的提交，且只有在工作大致完成时才会开启 PR。该模型中的常数 —— 每位工程师每周的分钟数、每个 PR 的运行次数、每次失败部署的重试次数 —— 曾经足够稳定，以至于季度偏差只是一个噪声项。

一旦 Agent 开始编写提交，这些常数就不再稳定。每位工程师每周的分钟数变成了“每位工程师监督的 Agent 循环”每周的分钟数，而其倍数取决于工程师可以监督多少个并发 Agent，这本身又是本季度评审工具和 Agent 规划循环优化程度的函数。预测模型有了一个新的自变量，而财务部门并未被告知这一点，因为推广过程看起来像是一个生产力工具，而不是成本曲线的改变。

工程部门应该与财务部门进行的对话不是“我们发现了偏差并对其进行了限制”。而是“成本模型假设劳动力是束缚性约束，而这已不再成立；这是新的模型，这是新的运行率假设，这是由于吞吐量提升我们现在愿意为每个功能支付的新成本”。如果没有这种对话，财务部门就是在针对一个已不存在的劳动力主导的成本模型进行预测，而工程部门则将每个季度的偏差视为一次次的意外。这种偏差并非意外。它是新常态通过一个未更新的模型表现了出来。

将编程 Agent 视为成本曲线的位移，而非生产力工具

处理这起事件的团队希望他们能早点实践的原则虽小，却让人有些不适。在广泛推行编程 Agent 之前，写下你预期它会变动的预算细目以及变动幅度。CI 分钟数是显而易见的。LLM Token 开销也是显而易见的。不太明显的包括：如果 Agent 的迭代产生了更多构建产物，则涉及产物存储成本；因为每次推送都会运行，所以涉及密钥扫描和依赖项审查成本；按事件量计费的代码评审工具成本；以及可观测性数据摄取成本，因为 Agent 的追踪（traces）不是免费的。

然后在推广之前建立归因机制。在任务入队时标记作业。增加成本中心。在第一个由 Agent 编写的 PR 落地之前就建立每作者仪表板，而不是在第二次季度偏差评审之后。确定财务和工程部门都同意跟踪的每个功能的成本分母。在开始之前，以书面形式承诺你所购买的运行率 —— 这样当达到该比例时，对话的主题就是重新协商费率，而不是解释为什么会产生偏差。

编程 Agent 不是团队采用的一个工具。它是一个改变了“哪项预算为哪项工作买单”的工作流。如果组织没有注意到这种位移，就会不断在那些忘记部署监控的地方发现成本超支。你想要编写的复盘报告应该是发生在偏差产生之前的报告 —— 那份报告会说：劳动力曲线正在变平，基础设施曲线正在上扬，而负责支付这两项费用的团队已经就这种权衡的价值达成了共识。