AI代理的委托代理问题

# crawshaw - 2026-05-07 来源: https://crawshaw.io/blog/agent-principal-agent ## 代理人委托-代理问题 *2026-05-07* 代码审查已经失效。 行业中建立的代码审查流程，即审查后提交（review-then-commit），曾是一种让信任度相对较低的工程师群体协作的简单机制。它最初似乎是在90年代为Apache服务器开源项目开发的，2000年代初被谷歌公司化，并通过多种方式在整个行业普及，其中最引人注目的是GitHub的PR。 其流程非常简单： 1. 人类做出修改。 2. 这些修改被打包，发送给另一个人进行评论。 3. 经过多轮评论和调整，直到审查者批准（LGTM）。 4. 修改被提交。 这不是Michael Fagan的缺陷分析工作，也不是航空航天等领域中用于关键系统变更的类似工单的流程。它无法帮你发现bug。但它能将设计变更传达给其他维护代码库心智模型的工程师，审查者也可以通过这个过程向贡献者传授规范。它有其优势，而且由于在主干分支变更前有一个关卡，因此不需要太多信任。这使得它成为公司规模化发展的好工具，因为当工程师人数超过约10-12人（也就是所谓的“两个披萨”团队）时，信任会迅速瓦解。它也非常适合开源项目的规模化。它将工作量转移到审查者身上，但提出修改的人也有工作要做。这种不平衡虽然存在，但通常是可控的。 ## 代码审查的危机 Agent打破了这一切。如果你将Agent插入到现有流程中，你最好的结果将是： 1. 人类**指示机器**进行修改。 2. **人类审查代码，通过评论迭代，直到批准。** 3. 这些修改被打包，发送给另一个人进行评论。 4. 经过多轮评论和调整，直到审查者批准（LGTM）。 5. 修改被提交。 这使审查工作量加倍。但公司本来就已经受限于审查能力。在一个运转良好的团队中，一次代码审查周期可能需要一天。（如果两个工程师相处融洽且非常了解彼此的工作，可以缩短到一小时。）但在整个行业中，在Agent出现前，乐观估计也需要**数天**（https://reviewnudgebot.com/blog/how-to-accelerate-code-reviews-with-nudges-insights-from-microsofts-study/）才能让一个审查合并。 此外，工程师使用Agent的全部原因就是它能提高生产力。生成的修改总量增加了。所以我们不仅审查工作量加倍，总修改量也增加了。当你对旧模型进行修改时，你会在从Agent中提取所有可能的价值之前就用尽审查带宽。（根据轶事，你在获得Agent价值的哪怕一小部分之前就会用尽带宽。） 但情况还会更糟，因为没有人真正以这种方式扩展旧流程。 ## 代理人委托-代理问题 现实中实际发生的是这样的流程： 1. **人类指示机器进行修改。** 2. 这些修改经过轻度QA，被打包，发送给另一个人进行评论。 3. 来自审查者的评论回来，**被批量发送给机器进行调整**，直到审查者批准（LGTM）。 4. 修改被提交。 这就是经济学家所说的**委托-代理问题**（https://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem）：审查者是委托人，贡献者是代理人，而代码审查之所以有效，只是因为审查者可以通过阅读代码廉价地推断出付出的努力。Agent破坏了那个信号。这正是正在扼杀开源项目的原因，通常被称为“垃圾PR”。驱动Agent的人类没有动机去真正阅读代码或花时间思考审查者所说的话。 结果是极度的不平衡。“贡献者”打出一两句话，质量跟糟糕的bug报告差不多，花5分钟摆弄一下生成的程序，然后给另一位工程师带来严重的审查负担。你可以在根本不了解底层项目、其约束条件或构建工具的情况下做到这一点。这是一场无法管理的灾难。即使在审查者拿钱做这项工作的情况下，这也行不通，因为他们自己通过提示Agent可能效率更高。 ## 潜在的解决方案 小规模高信任团队可以采用一个简单的流程： 1. 人类指示机器进行修改。 2. 人类审查代码，通过评论迭代，直到批准。 3. 他们将修改推送到生产环境并部署。 仍然有一个人处于循环中。仍然有一个审查者，但没有深陷于如何解决问题的细节中。最重要的是，没有委托-代理问题，因为驱动机器的人类通过拥有部署来承担其行动的责任。 轶事证据表明这对小团队有效。在exe.dev（https://exe.dev/）的九人团队中，我们成功实现了这一点。我们花了更多时间编写集成测试、端到端测试，建立基于Agent的工作流程来分析提交的安全性、性能或可用性bug，以最小化风险。这些是团队传统上直到规模更大、更成熟时才会开发的大量基础设施，但另一方面，由于Agent的存在，开发起来要容易得多。我们还必须非常谨慎地选择同事，并有意识地进行沟通。但我们就是这样交付的。 这在低信任环境中是不可持续的，比如大公司。你必须信任你的同事，在他们进行架构变更之前主动开启对话。大公司的没有人相信他们的同事会对他们“拥有”的服务进行大规模变更。而且大公司里没有人愿意在没有任何代码审查来分摊责任的情况下，为一次重大宕机背锅。（低信任环境是可怕的地方。） 我确信大公司中有一些与标准做法决裂的小孤岛团队，并正在从Agent中获得真正价值。我也确信有一些个人贡献者（IC）的工作方式能让他们最大化Agent的价值，而无需涉及同事。（例如，如果你从事质量工作，Agent可以帮助你编写和执行无休止的大规模实验，这些实验永远不需要审查，只需把有效的部分发送出去即可。）但大公司中的绝大多数工程师无法进行修改，尤其是Agent擅长的跨功能修改，因为审查会消耗掉所有生产力收益。 ## 历史书中的一些线索 在撰写本文时，我还没有看到有人描述一种能让Agent驱动的开发在大公司“规模化”的流程。然而，过去有证据表明这是可能的。我想指出20世纪90年代的微软，当时并没有强制要求提交前审查的做法。有些团队可能有，但整个公司虽然庞大，却是由众多独立团队组成，并通过QA流程不断同步。这被那些推崇Agent出现前的大团队流程的人视为“过时的”、“牛仔式”开发风格。但它确实有效。它创造了微软一些最长久成功的产品，比如win32 API。（当然我们可以无休止地批评这个30年前的API，但它仍然存在，并且比一些通过代码审查流程构建的“替代品”要好得多。）关于微软这段历史，似乎很少有文字记载，如果你当时在场，我很想听听或读到你的经历。 在有人为低信任环境下的Agent使用开发出稳健流程之前，小团队拥有大团队无法匹敌的巨大力量倍增器。趁还能交付，赶紧交付。