Agent 管理学：AI Coding 的确定性边界

过去一年，我们在 Agent 管理学论坛里和上百位开发者一起踩坑、复盘、迭代。这篇文章是我们的阶段性总结。

一、翻篇的争论

“AI 写的代码根本不能用。”

这句话从 2023 年底 ChatGPT 刚出来的时候就有人说，一路说到了 2025 年。中间 AI 在不断刷新它能搞定的项目规模，但批评从未停止。

直到 2025 年 12 月。Andrej Karpathy 表示 AI 编程将成为软件工程的未来。Linus Torvalds 开始用 AI 写代码。连最顽固的老派黑客们都开始投降了。

与此同时：

Anthropic 用 Claude Code 从零写了个 C 编译器，能编译 Linux 内核
FAST 会议上出现了完全由 AI 编写的可扩展的文件系统
PingCAP 的 CTO 黄东旭、太极图形的创始人胡渊明都是 AI Coding 的深度使用者，甚至大规模在团队内推广提效

所以问题来了：同样的 AI，为什么有人用它造出了生产级系统，甚至在企业内大规模推广提效，而有人做个 web 个人项目都漏洞百出？

如果你有这些问题，这篇文章就是为你准备的。一言以蔽之：AI Coding 不是一个技术问题，而是一个管理问题。

二、受挫的技术先锋

Anthropic 公布了完全使用 Claude Code 开发的 C 语言编译器，成功编译了 Linux 6.9 内核。公布之后，网络上除了营销号的狂欢以外，质疑却大多来自技术社区：宏定义根本没被使用、路径是硬编码的、没有处理 x86 16 位实模式启动代码……然后每每在评论区对 AI 的嘲笑中结束：看吧，AI 还是不行，我还是不可替代的。

越是传统意义上的技术大神，在 AI Coding 上反而接受的越慢。原因不在 AI——在他们的管理思维还没跟上。

AI 是你的同事

假设你招了一个智商极高、学习能力极强、但刚入职第一天的员工。你跟他说”写一个能编译 Linux 的编译器”，只给这一句话。会发生什么？

我相信他绝对不会写出来一个兼容一切生态的全功能编译器。Hello World 能不能用？你没说。动态链接？你没提。16 位实模式自己实现还是调用现有工具？验收的时候，你觉得他”瞎搞”。但其实是你的管理出了问题。

AI 会做到你定义的标准，然后停下来。 如果你的标准不清楚，它就会停到一个符合常识的地方，无论这个常识是不是你的常识。

这就是为什么技术大神反而抗拒。他们擅长把需求翻译成完美的代码。但问题出在需求本身——把需求说清楚，把边界定明确，把验收标准量化。技术专家看着千疮百孔的 Claude Code 编译器嘲笑，殊不知他写过的好软件根本不因为他，而是因为他的产品经理。

百年前的旧难题

经济学里有一个研究了几十年的经典问题叫做委托-代理问题。巧合的是，经济学里的”Agent”和我们今天说的 AI Agent 是同一个词。

AI 已经足够有能力，值得我们把它当作经济学意义上的行为体来看待。当你把任务委托给一个 Agent，天然会出现三个挑战：

信息不对称：你不完全知道它在做什么
目标偏差：它的理解和你的意图有出入
验证困难：你很难判断它做得到底好不好

管理学给出的答案是建立契约和制度：明确目标定义，设置过程检查点，制定可衡量的验收标准。我们的答案本质上一样。这也是论坛取名”Agent 管理学”的原因。

三、确定性的边界

就像团队的领导没有时间 review 每一行代码一样，我们充分相信同事的能力。好的管理从来不是追求每一步的完美控制，它是在关键节点设定清晰的标准，中间留出空间。

我们把这些关键节点叫做”确定性的边界”，把整个 AI Coding 的流程拆成三段，在每一段建立明确的契约。

3.1 需求端：文档即产物，AI 即编译器

传统开发中，代码是最终交付物。在 AI Coding 时代，文档才是。AI 扮演的角色更接近编译器——它把你的文档”编译”成可运行的代码。编译器的输出质量取决于输入的质量。这意味着文档必须足够扎实。

我们的实践路径是：从 PRD 出发，生成架构文档，再细化为详细的执行文档，最后让 AI 严格按照执行文档实现。Kiro、SpecKit 这类工具能帮你在早期把文档体系搭建起来，但它们宣称自己就是最终答案，导致很多人尝试之后草草了事，觉得”也不过如此”。

问题出在哪？既然文档成了最终产物，文档本身就需要验收和测试。用一句话生成 spec 和用一句话生成软件，结果是一样的——都是把不确定性交给了 AI，最终必然走向失控。

这里有两个难题：第一，AI 生成文档的速度是人类阅读的几十倍，你根本看不过来。第二，让 AI 来 review，它会告诉你”结构清晰，建议补充异常处理”——正确但无用，什么都没解决。

实际上，问题不在 review 这个动作本身，在于大部分人拿到一份 spec 的时候，根本不知道自己应该盯着什么看。很多技术人会下意识地审查架构是否合理、接口命名是否规范、数据模型是否优雅。然而我们要审查的唯一部分，就是用户故事。

用户故事描述的是真实的人要用软件完成的真实的事。“作为一个主播，我要能在直播间里发起投票”——这是用户故事。它不关心你的架构怎么设计、API 怎么命名、数据库用的什么。它只关心一件事：这个人能不能完成他想做的事。

反过来说，如果你的文档能让每一条用户故事从头到尾走通——每一步需要调用的接口都有定义，参数和返回值都完整，异常情况都有覆盖——那这份文档是完整的。这就是我们说的”文档测试”：用用户故事作为测试用例去跑文档，和主观性的”文档 review”做区分。让 AI 拿着每一条用户故事逐步走，结果是确定性的，不依赖任何人的主观判断。

架构层面的 review 仍然需要，只是不需要人来做。让不同的模型从不同角度交叉验证，比一个人盯着看效果更好，成本也低得多。人负责用户故事，AI 负责技术细节，各守各的层。

3.2 执行端：注意力的边界

AI 有一个和人类很相似的特性：注意力有限。当 Context Window 里塞的信息太多，它的表现会显著下降。每一次交给 AI 的任务，必须控制在它能 handle 的范围内。

这有两个维度：

空间上是模块化。 你要给它完整的输入条件：这个模块实现什么功能，输入值是什么，返回值是什么。API Contract 写清楚，测试套件把边界框住。在这个明确的围栏里 AI 可以自由发挥，围栏之外的事情它不需要操心。

时间上是分步推进。 即使在同一个模块内，也不能一口气把所有需求丢给它然后祈祷。你要把任务拆成小块，每一块完成之后验收，然后为下一块重新整理上下文。你给它的上下文越干净、越聚焦，输出质量就越高。

在这两个维度之上，我们还会用一个独立的 AI 去 review 每次提交，确保改动没有超出当前任务的范围。

3.3 验收端：没有标准就别怪 AI

这是三段里最重要的一段。大部分人对 AI Coding 的不满，根源都在验收标准不清晰。

回到编译器案例：技术社区的批评为什么没有意义？因为验收标准是”编译 Linux”，不是”做一个通用编译器”。你没有在契约里写明的东西，Agent 没有义务去实现。如果你在乎 Hello World 能不能跑，那就把它写进测试套件。

AI 的产出速度是人类的百倍。在这个速度下，一个小的偏差如果没有被及时发现，几个小时之后就会变成几十个文件里的系统性问题。你需要在每一步完成之后立刻验证，确认没有跑偏再进入下一步。

所以我们的做法是把测试基建前置。在所有执行文档生成完之后、第一行业务代码落地之前，先根据 API Contract 搭建完整的测试框架。所有暂时不存在的依赖全部用 Mock Server 和 Mock 数据替代，构建一个和整个服务解耦的独立测试体系。AI 跑偏了，测试会立刻告诉你。

如果你发现自己写不出测试，别急着写代码——写不出测试说明你的需求从一开始就是模糊的，回去改文档。

如果有任何 agent 编程框架不包含任何测试和质量管控基建，都可以统一归为大忽悠。

在测试之外，对抗式的 Code Review 是另一层保障。每次 AI 产出代码之后，交给另一个 AI（最好是不同的模型）来审查：是否严格遵循执行文档？测试基建负责验证结果对不对，对抗式 Review 负责验证过程有没有越界，两层共同构成验收端的确定性边界。

四、AI 原生团队

第三章讲的是怎么管好一个 Agent 做一件事。但在实际项目中，你不会只开一个会话。论坛里的成员在日常开发中同时调度二三十个 Agent 并行工作已经是常态。

多 Agent 并行时，第三章的那些基建——API Contract、Mock Server、测试套件——从好实践变成了生存前提。我们早期踩过这个坑：每个 Agent 的单独产出都能通过测试，合在一起就到处冲突，因为模块之间的契约不够明确。解决方案没有新花样，就是回到第三章的基本功，把契约做得足够扎实，让每个 Agent 在完全独立的环境里工作。

这些实践如今已经部分被整合进了主流的 Coding Framework 中，比如通过 git worktree 隔离已经成为 Cursor 和 Claude Code 的标准能力。

技术上的协调问题有解。但当它被解决之后，一个更根本的问题浮出水面：人该怎么组织？

一个人带着三十个 Agent 的产出量已经超过了传统五到十人团队。生产力变了，组织方式必然要跟着变——就像蒸汽机让手工作坊变成了工厂，不是因为有人觉得工厂更好，而是作坊装不下新的产能了。

传统的一个 Tech Lead 带五六个 IC 的结构，在每个人都能带三十个 Agent 的时候反而制造了更多的协调开销。目前我们观察到两条路线：头狼模式和 Tri-Ownership 模式。

头狼的天花板

PingCAP 的 CTO 黄东旭在他的 Vibe Engineering 实践中展示了头狼模式的威力：单人驱动大规模 Agent 协作，用 AI 重写了 TiDB 的 PostgreSQL 兼容层，代码质量接近生产水平。他用了一个很准确的比喻——头狼带着狼群在自己的领地里耕耘。

头狼模式的优势很明显：决策链极短，没有沟通损耗，一个人的审美和判断贯穿整个产品。但它有两个硬性的限制：

第一，同一片领地里很难容纳两匹头狼，1+1 < 2。顶级工程师各自的 Agent 工作流、Prompt 风格、代码习惯都高度个人化。两个顶尖的人很难在同一个模块里协作，因为他们各自训练出来的 Agent 团队”说的语言不一样”。

第二，天花板在于验收。东旭自己说，他 90% 的时间花在了评估 AI 的工作成果上。以东旭的能力，他扛得住。但对大多数人来说，Agent 军团的产出速度是人类的百倍，如果验收跟不上，只会让屎山越滚越大。而且头狼本身是极度稀缺的。

头狼模式证明了 AI 原生开发的可行性，但对个体要求极高。

拆解超级个体

换一个思路：既然超级个体找不到，就把超级个体的能力拆开，分配给三个可培养的角色。

Product Owner（PO） 负责做什么：定义产品愿景、管理用户故事、设定优先级。PO 对产出的价值负责，最重要的能力是敢于说”不做什么”。

Tech Owner（TO） 负责怎么做：带领 Agent 军团完成所有开发，核心工作不是写代码，而是编排多个 Agent 的工作流、设计模块边界、处理执行过程中的异常。

Quality Owner（QO） 负责做得对不对：独立于开发，全流程管理质量，从用户故事阶段就参与验收标准的定义，到测试框架的搭建，到最终的端到端验收。QO 的独立性是整个框架的关键。

回到对抗性的逻辑：控制 Agent 军团的 TO 交付的东西，天然需要一个独立的第三方来验证。NASA 在挑战者号灾难后建立了独立验证与确认项目，核心原则是软件验证必须由独立于开发者的组织执行。我们借鉴的是同样的思想。

你会注意到，这个团队结构里没有”程序员”这个角色。写代码的是 Agent。人类做的事情是定义需求、设定边界、审查产出、协调冲突——全部都是管理工作。

两人团队也可以运转：PO 兼任 QO，和 TO 搭档，验收的独立性会打折扣，但对于较小的项目已经够用。

展望：边界会逐渐放松

需要澄清一点：本文讨论的所有实践，针对的是超大型、企业级的 AI Coding 项目——写一个长期运行的数据库，写一个云端协作工具，写一个需要长期维护的商业系统。对于小型项目，你不需要这么重的流程。

更让我们兴奋的是另一个方向。在一些开放性的问题上，我们发现放手让 Agent 自己规划路径，效果往往超出预期。你只定义 High Level 的目标，让它自己构思方案、自己制造工具、自己在循环中迭代。AI 在这种自主模式下展现出的创造力，经常让我们惊讶。

这也许预示着一个趋势：随着模型能力持续增长，我们需要建立的”确定性边界”会越来越少。管理的颗粒度会从微观走向宏观，从”定义每一步”走向”定义目标，放手执行”。今天你需要写详细的执行文档让 AI 照着做，也许明年你只需要写 PRD，后年你只需要描述用户故事。确定性的边界不会消失，但它会不断向上抽象。

同时，Agent 对不同人的增益方差极大：对用得最好的人可能是 10x，对普通人可能只有 10%。AI 不是一个均匀的效率提升器，它是一个放大器，放大的是你的管理能力和系统思维。

程序员们引以为傲的”手艺”正在贬值。但系统设计能力、需求分析能力、对业务的理解，反而变得前所未有地重要。Agent 能写出任何你描述清楚的东西，但它不能替你决定该写什么，因为它并非自己成果的用户。

如果你能从造物中获得成就感，那你活在一个最好的时代。你对 Agent 的管理能力，就是你创造力的上限。

瑞典马工