工业界的做法：不搜结构，改接口

上一篇算下来，让 meta agent 去搜索更好的 agent 结构，多数时候回不了本。

而同一时期，Anthropic 用 16 个并行 Claude 写出了十万行 Rust 的 C 编译器，并且说自己超过 80% 的生产代码由 Claude 撰写。

这两个画面不矛盾，因为它们优化的根本不是同一样东西。学术那条路在搜 agent 的结构，工业这条路在改 agent 和世界之间的接口。

案例一：用 git 冲突当并发原语

那个编译器项目的协调机制，简单到让人怀疑是不是漏了什么：

认领任务 → 往 current_tasks/ 写个文件，比如 parse_if_statement.txt
两个 agent 抢同一个 → git 同步时天然冲突
干完 → 拉取上游、合并、推送、释放锁

没有消息总线，没有中央调度器，没有角色分工。作者自己写明：agent 之间没有别的通信方式，也没有任何管理高层目标的流程。

它把并发控制外包给了一个已经存在四十年的系统。 git 本来就要解决「多人改同一份代码」，那么「多个 agent 改同一份代码」就是同一个问题。

成本账摆在这儿：两周里跑了约 2000 个会话，烧掉 20 亿输入 token 和 1.4 亿输出 token，折合大约 两万美元。换来的是多数测试套件 99% 通过率，以及成功编译 Linux 6.9 的三个架构。

案例二：brain、hands、session 拆成三份

Managed Agents 那篇讲的是另一种接口改造：把原本耦合在一个容器里的东西拆成三份。

拆开之后拿到四样东西：

一、从「宠物」变成「牲口」。 原来耦合在一起，容器挂了会话就没了。拆开之后，容器挂了只是一次工具调用返回错误，harness 把它当普通失败交回给 Claude。harness 自己挂了也能 wake(sessionId) 从日志里恢复。

二、凭据隔离。 这一条是安全上的结构性修复：原来的设计里，Claude 生成的任何不可信代码，和凭据跑在同一个容器里。拆开之后提示词注入拿不到 token。

三、灵活性。 brain 可以把 hands 传给另一个 brain；也能在客户 VPC 里干活而不用打通网络。

四、快了很多。 首字延迟 p50 降了约 60%，p95 降了超过 90% —— 因为推理可以立刻开始，不用等容器起来。

这四样收益里没有一样来自「更聪明的 agent」。 全部来自把边界划对了地方。

案例三：跨会话交接靠一个进度文件

长时程 agent 的核心矛盾是：它要在一段段离散的会话里干活，而每段会话对上一段没有记忆。

Anthropic 那篇讲长时程 harness 的做法很朴素：一个进度文件，配合 git 历史。让新会话开局就能快速搞清楚现在做到哪儿了。

这条和上面两条是同一个思路的第三次出现：不去增强模型的记忆，而是把状态放到一个模型每次都能读到的地方。

那条 80% 意味着什么

Anthropic 那篇讲递归自我改进的文章给了一组组织层面的数：

• 截至 2026 年 5 月，超过 80% 合入生产的代码由 Claude 撰写
• 工程师每季度合入的代码量是 2021–2025 年的 8 倍
• 模型能处理的任务时长大约每四个月翻一倍：2024 年 3 月 4 分钟，2026 年 3 月 1.5 小时，2026 年 5 月 12 小时

但它同时点了一个瓶颈，我认为比上面那些数更重要：

人工代码审查成了新的瓶颈。

代码生成的速度超过了人验证的能力。这是 Amdahl 定律在组织层面的显形 —— 你把一段加速了 8 倍，没加速的那段就成了全部。

它还明确说了当前的能力缺口在哪：Claude 擅长执行，欠缺的是选择目标的判断力。人还在提供目标，只是不再需要提供方法。

而对「完全的递归自我改进」，那篇的措辞是还没到，而且不是必然会到。

这四个案例的共同点

把它们放一起看，工业界这条路的方法论是清晰的：

一、外包给已有系统。 并发控制交给 git，状态交给文件系统，恢复交给事件日志。不发明新的协调机制。

二、边界划在故障处。 brain/hands/session 的拆法，本质是按「什么东西会挂」来划的 —— 容器会挂、harness 会挂、会话不该挂。划对了之后，每种故障都变成可以被上一层处理的普通错误。

三、优化接口而不是结构。 十万行编译器那个项目，没有一处在设计更好的 agent，全在设计 agent 怎么协作、怎么被验证。

这一条我自己验证过一次，虽然是被动的。我那套东西跑长任务时反复被杀，后来发现真正救命的不是任何模型能力，是每个子任务结束就把状态落盘这个动作 —— 进程没了，磁盘还在，再跑一次从断点续。那是接口设计，不是 agent 设计。 而我当时给自己的理由只是「一次跑不完是常态」，没意识到它和 brain/hands/session 那套拆法是同一个思路。

四、瓶颈会转移，要盯着它。 生成快了，审查就成了瓶颈。每解决一个瓶颈都会暴露下一个，而下一个经常不在技术这边。

边界与代价

这些是单一组织的实践，而且那个组织有极强的特殊性。 模型是自家的、算力管够、工程师全员深度使用。「80% 代码由 Claude 写」这个数放到别的组织，前提条件就不成立了。

两万美元买十万行代码，经济性没有被证明。 那个编译器能编 Linux，但生成的代码明显不如 GCC 高效，也缺独立的汇编器和链接器。它证明的是可行性。 至于这笔钱花得值不值，取决于你要的是编译器还是「证明这条路走得通」。

「用 git 当并发原语」有明确的适用边界。 它成立的前提是任务可以被切成互不重叠的文件级改动。换成需要细粒度协商的任务，文件锁就不够了 —— 作者自己也说这是很早期的原型。

这一整个系列我都没有第一手数据。 四篇里的每个数字都是别人的实验或别人的生产环境。我能做的是把它们的条件说清楚 —— 而条件说不清楚的数字，不该被拿去做决定。

这四篇合起来

• 第一篇：四种范式 —— 搜代码、改自己、优化 harness、改协作方式
• 第二篇：四条路的成败取决于同一样东西，而优化会精确地停在验证器的边界上
• 第三篇：meta agent 搜索多数时候回不了本，回本点在约 15000 个样例
• 这一篇：工业界没在搜结构，在改接口 —— 而且收益全部来自把边界划对地方

如果只留一条：先把便宜的杠杆用完。 接口、验证器、协作方式这些改动的成本是一次性的，而搜索更好的 agent 结构，成本是每次评估都要付的。