Claude Code Agent Teams实验复盘：16个Agent、10万行Rust、2万美元的成本账

8月下旬，Claude Code的Agent Teams功能里出现了一个实验性项目，很快在技术社区传开：16个Opus 4.6实例自我组织成团队，在两周时间里完成了接近2000个工作会话，产出约10万行Rust代码——其中包括一个可以编译Linux 6.9内核的C编译器。

总费用：约2万美元的API成本。

这个实验的配置很值得一看：16个Agent没有人工指派角色，它们自己完成了分工——有负责架构设计的，有写核心模块的，有专职写测试的，还有专门做代码评审的。人类在两周里做的事，主要是观察和偶尔回答方向性问题。

最关键的细节：协作接口从人移到了软件

这个实验里有一个变化比"写了几行代码"重要得多：Agent之间的协作接口，从人类转移到了软件。

传统AI编程的协作模式是"人当路由器"：AI A写完代码交给人，人看了再交给AI B测试，测试完人再决定是否合并。人是所有协作的中间节点，也是瓶颈。

而这个实验里，Agent之间直接通过结构化的任务看板和代码评审接口协作——写代码的Agent提交，评审的Agent把关，测试的Agent验证，问题以任务形式流转，全程不需要人参与。人类只处理"目标层"的问题，不处理"执行层"的流转。

如果这个模式成熟，它改变的不只是效率，而是软件工程的组织形态——一个开发者可能从"管理自己的时间"变成"管理一个Agent团队"。

但2万美元的账单藏着三个问题

冷静看，这个实验暴露的问题和它展示的能力一样多。

第一，成本结构完全不同。 10万行代码2万美元，折合每行0.2美元。听起来不贵？但注意这是一次性产出成本，不含维护。如果这10万行代码的churn率（短期内被重写或删除的比例）达到行业观察到的AI代码水平——有数据认为AI参与项目的代码churn率比人工项目高39%——那么真实成本要按这个系数放大。

第二，10万行代码谁审？ 这是更致命的问题。16个Agent两周产出的10万行代码，如果要人工审查，按每天1000行的实际审阅速度，一个人要审4个月。不审就合并？这个C编译器是实验品无所谓，换成生产系统的支付模块呢？产出能力和审查能力的缺口，在多Agent模式下被放大到了极限。

第三，黑箱程度指数级上升。 单个AI生成代码时，人还能大致跟上它的思路。16个Agent自我组织、互相评审、自主决策时，代码的"设计理由"分散在近2000个会话里，没有任何一个人能完整重构出"这个系统为什么长成这样"。出了问题，定位的难度可想而知。

全自主和可控执行的分界线

这个实验划出了一条清晰的分界线：AI工程能力存在"全自主"和"可控执行"两个极端，中间隔着巨大的工程可靠性鸿沟。

全自主多Agent模式适合的场景很明确——探索性、可抛弃、失败成本低的任务，比如实验项目、原型验证、技术调研。这次实验本身就是最好的例子：它就是一次可抛弃的探索。

但企业级Java开发的绝大多数场景在分界线的另一侧：生产代码、存量系统、有合规要求的业务。这些场景里，“AI能做"从来不等于"AI做的能用”——差距在于过程是否可控、结果是否可验证、失败是否可回滚。

可控执行的核心不是限制AI的能力，而是把人的判断力放在关键节点上。任务拆解完之后、接口设计定稿之前、代码生成落地的那一步——每个节点人工确认一次，确认成本很低，但把整个流程从黑箱变成了白箱。

计划模式：把自主性装进流程里

飞算JavaAI的智能体计划模式提供的正是这种中间形态。复杂任务先自动拆解成多步骤，但不是一口气执行完——每一步执行前可视化呈现，人可以确认、调整或叫停；执行中断点可保存，随时续接；多步骤之间通过子代理协同，但协同的过程对使用者透明。

这个设计背后的判断和上面那份2万美元账单的启示是一致的：多Agent的编排能力是真实价值，但它的正确打开方式是"人监督下的流程自动化"，不是"无人化的自我组织"。 工程场景需要的不是16个AI自我组队的奇观，而是一个AI把任务拆成16步、每一步都能被人审查和接管的确定性。

16个Agent两周写10万行代码，展示的是AI工程能力的天花板。而每天在IDEA里可靠地完成一个个具体任务，才是地板——对大多数团队来说，把地板做扎实比够到天花板更有价值。