当AI 学会“组队开黑”

本文来自微信公众号： 思考机器 ，作者：陆三金&kimi，原文标题：《当 AI 学会「组队开黑」》

2026年2月5日，北京时间凌晨，硅谷的炮火准时响了。OpenAI和Anthropic，两家最头部的AI公司，前后脚发布新模型。相隔不到一小时。

OpenAI这边是GPT-5.3-Codex，自称"迄今最强编程智能体"。

Anthropic那边是Claude Opus 4.6，带着100万token的上下文窗口杀进来。

两家公司都憋足了劲，要在同一个时间节点上交卷。

但模型发布是一方面，这不是我们今天要关注的重点。

还有一条暗线，值得关注：Anthropic本次除了Opus 4.6，还发布了agent teams预览版，即agent集群，他们用16个Agent写编译器，另外，Cursor的几百个Agent项目还在继续更新，之前Kimi也亮出了Agent Swarm。

它们目前虽然都在预览和测试阶段，但意图很明显：大家都在押注并行Agent这条路。

Anthropic的研究员Nicholas Carlini搞了一个疯狂的实验。

他让16个Claude实例一起工作。任务是：从零开始写一个C编译器，用Rust语言，要能编译Linux内核。

没有人类干预。完全自主。

近2000次Claude Code会话。20亿输入token，1.4亿输出token。成本接近2万美元。

两周后，他们得到了一个10万行代码的编译器。它能编译Linux 6.9内核，能在x86、ARM、RISC-V上运行。它还能编译QEMU、FFmpeg、SQLite、Redis。

甚至能运行Doom。

这不是demo，不是PPT。这是实打实的10万行代码，能boot一个真实的操作系统。

关键不在于"写出了编译器"。而在于"怎么写的"。

16个Claude，各自独立运行。它们通过文件锁机制协调任务，一个Agent负责解析if语句，另一个负责函数定义代码生成，还有一个专门盯着代码去重。

它们会冲突。会覆盖彼此的代码。会产生merge conflict。但Claude够聪明，能自己解决。

这就是Agent Teams的本质：不是一个大模型在干活，是一群大模型在分工协作。

Anthropic不是唯一一个这么干的。

1月底，月之暗面的Kimi K2.5发布。核心卖点是什么？Agent Swarm。

最多100个子Agent并行工作。执行时间缩短4.5倍。成本比Claude Opus 4.5低76%。

Kimi的这个集群我当时还试过，看着系统在自动生成每个Agent，并给每个Agent设定角色、分配任务、执行任务，再看看每个角色的提示词及进度条，甚至还有点感动，因为多agent系统把你的目标拆成了一个个具体的事项，再委派专人，真的有点将军坐帐前的感觉。

Cursor，那个最火的AI编程IDE，也在搞"Self-Driving Codebases"。本质也是多Agent协作。在他们的浏览器项目被全网群嘲之后，团队并没有放弃，仍然在尝试，最新的说法是：“在最近一次为期一周的运行中，我们的系统在数百个智能体上达到了每小时超过1000次提交的峰值。“

OpenAI的Codex，虽然官方宣传里没明说"Swarm"，但也提出了"随着模型能力日益强大，差距已从智能体能完成什么任务，转向人类如何更轻松地与之互动、指挥并监督多个智能体并行工作。"

整个行业，从2026年初开始，齐刷刷转向同一个方向：多Agent并行。

但就在7个月前，有人公开反对过这个方向。

2025年6月12日，Cognition的CPO Walden Yan发了一篇文章，标题很直接：《Don't Build Multi-Agents》。

Cognition是Devin的母公司。Devin是当时最火的AI程序员。

Walden的核心论点很简单：多Agent架构很脆弱。你把任务拆给多个Agent，它们会丢失上下文，会做出冲突的决策。

他举了一个例子：让Agent做一个Flappy Bird游戏。一个Agent负责背景，一个负责小鸟。结果背景做成了超级马里奥风格，小鸟做得完全不像游戏素材。两个Agent各自为政，最后还得人来擦屁股。

他提出两个核心原则：

第一，要共享完整的上下文，不只是传递消息，而是传递完整的思考轨迹。

第二，每个行动都带着隐含的决策，多个Agent的决策会冲突。

结论是：用单线程的线性Agent，才是更可靠的做法。

当时这篇文章在圈子里引发了不小的讨论。很多人觉得说得对。多Agent确实容易失控。

但7个月后，情况彻底反转。

Anthropic用16个Agent写了一个编译器。Kimi支持100个Agent并行。Cursor一直在尝试多agent长时间并行，意图迈向自动驾驶代码库。

不是说Walden错了。他的担忧都是真实的。但现在的问题变成了：即使有风险，我们也必须走这条路。

因为单Agent的极限已经到了。

为什么必须是并行？

想象一下早期的计算机。单核CPU。一个任务一个任务处理。简单、直观、可控。但当你需要同时处理大量任务时，它就捉襟见肘了。

然后多核CPU出现了。复杂、难以协调、有各种并发问题。但它是唯一能在物理极限下继续提升性能的路径。

Agent的发展是一样的。

单Agent的问题不是"不够聪明"，而是"必须串行"。它一次只能做一件事。遇到复杂工程，只能一件一件来。上下文窗口再大，也有极限。

但真实的软件工程是并行的。

你在写前端的时候，后端可以同时写。你在做测试的时候，运维可以同步准备环境。这才是人类团队的协作方式。

Kimi K2.5的数据很说明问题：用100个Agent并行，执行时间缩短4.5倍。

这不是"多个笨蛋一起干活"。这是"专业分工"。

就像Anthropic那个C编译器项目：有的Agent专门负责代码去重，有的专门优化性能，有的专门写文档，有的从Rust程序员的角度critique架构设计。

每个Agent都在做自己最擅长的事。

但这里有个有趣的落差。

对于普通用户来说，这一切没什么感觉。

你不会在ChatGPT的对话框里看到"正在启动16个Agent为你服务"。你看到的只是答案更快地出现了，或者质量更高了。

就像消费者不会感受到芯片制程从7nm进步到3nm，但手机确实更快了、更省电了。

真正的变革发生在开发者和企业层面。

以前，AI是"助手"。你告诉它做什么，它帮你做。

现在，AI正在成为"团队"。你给它一个目标，它自己拆解任务、分配工作、并行执行、最后给你结果。

这个转变的意义被大大低估了。

当Devin在2025年中坚持单Agent路线时，它代表的是"可控、可靠、渐进式进化"。

但当Anthropic、OpenAI、Kimi、Cursor全部转向多Agent时，它代表的是"我们必须突破单Agent的物理极限，哪怕要承担风险"。

这不是技术路线的分歧。这是对问题严重程度的判断不同。

Devin觉得"可以用更好的上下文管理来解决"。大厂们觉得"工程复杂度已经超出单Agent的处理能力，必须并行化"。

历史似乎站在大厂这边。

回到标题：当AI学会"组队开黑"。

这听起来像个游戏术语，但其实很贴切。

单Agent时代，是"个人英雄主义"。一个大模型，单枪匹马，试图解决所有问题。

多Agent时代，是"团队协作"。每个人都有专长，有人负责打输出，有人负责加血，有人负责探视野。

这个转变意味着什么？

意味着AI从"工具"变成了"团队"。不是"我有一个很聪明的AI助手"，而是"我有一个由AI组成的工程团队"。

这个团队可以7x24小时工作，不需要休息，不会抱怨，成本只有人类团队的零头。

当然，它还不完美。Agent之间会冲突，会丢失上下文，会产生不一致的决策。Walden Yan在2025年指出的问题，现在依然存在。

但趋势已经很明显了。

从2026年春节这波发布开始，AI行业进入了一个新阶段：从"让AI更聪明"，转向"让AI更会协作"。

这不是终点。甚至不是终点的起点。

但这可能是起点的终点——单Agent时代的终点，多Agent时代的起点。

当AI学会组队，它就不再是一个助手了。

它是一支军队。