编程 Agent 通常没法按结果收费，我们能
编程 Agent 通常没法按结果收费，我们能
Agentic Batch Changes 现已上线，我们按结果定价：只有合并的 changeset 才收费。
Agentic Batch Changes 现已上线，按照你合并的 changeset 收费。下面说说我们为什么选这条路。
每周我都会和工程负责人聊，最近几乎每次都会聊到账单。我们已经进入一个时代，刷 token 用量不再是目标；没人是靠冲上用量排行榜前列获得晋升的，而要向账单负责的工程副总裁也很难给出合理交代。
我不觉得这是谁的错。AI 工具就是这么定价的。每个编程 Agent 都按投入收费，按 token 计费（通常还加一笔费用），不管有没有东西真正落到你的代码库里。其他垂直领域有不少创新（Sierra、Fin、Decagon 等都按解决结果收费），但开发工具依然牢牢绑在按席位和按用量的定价上。
Agentic Batch Changes 现已上线，我们按结果收费：只有它生成的 changeset 被合并进你的代码库时，你才付费。没合并，就不收费。
生成 pull request 其实并不难。代码很便宜。我聊过的团队真正头疼的是后续落地。那些改动、那些要动到每个仓库的迁移，往往永远躺在待办列表里，因为接手一个迁移意味着三个月的干系人管理和谈判，而且永远没法证明工作已经完成。PR 没人审，慢慢就过期了；第一周看起来快做完的迁移，到第六个月还开着。
一份 diff 不是结果，合并了的 changeset 才是。所以我们就按这个收费。
为什么要这样对自己下狠手？
原因很简单：我们对产品有信心，而按结果定价是证明这一点最清楚、最实在的方式。这种定价方式也让我们的利益和客户的利益完全绑在一起。
我们提出这个方案时，财务团队的第一反应是“坚决不行”。后来让他们改变想法的，是理解了 agent 的工作方式。如果一段脚本就能搞定，它不会立刻搬出 coding agent；而在迁移场景里，大多数时候一段脚本就够了。一个 agent 可以生成上千种情况的 switch 语句，而不是部署一千个 agent，这就压低了到达终点的成本。
我很愿意相信这是行业的未来，但我们能做而别人不能，是有原因的。大多数 coding agent 从一开始就被设计成通用问题解决器，用来规划度假或者开放式探索，和用来执行变更的概率差不多。这种开放性让它们很强大，但也让投资回报率成了一个无法回答的问题。
Agentic Batch Changes 是一个专用 agent，在运行框架、系统提示、权限和工具上都有意收窄了范围，只为解决一个具体问题。我们构建这套运行框架，就是为了在大规模下把成本压到最低，而不是花钱让一个 agent 把同一件事重复做一百遍、一千遍。
如果你手里管着预算，现在可以用一个能数得出来的数字来证明这笔支出是合理的。不是算力预测，也不是一个跟迁移有没有完成毫无关系的席位。一个已经合并的变更，是你能指得出来的东西。
Canva 的一个团队在 beta 期间用它完成了库迁移。那里的高级软件工程师 William L. 这样说：
“我们用 Agentic Batch Changes 在多个代码库中提交并合并了 50 多个拉取请求，作为库迁移的一部分。Web UI 让跟踪每个 PR 及其状态变得很容易。没有它，我们要么得管理巨大的 PR，要么得维护电子表格；而 Agentic Batch Changes 让评审人和我的工作都轻松了不少。”
William L.，高级软件工程师，Canva
这次迁移的费用，按合并的五十多个拉取请求计算。不是我们开启的那些，也不是智能体花在到达那里的时间。