anthropic-agent-teams

过去一年,我看过太多 multi-agent 的 demo。

几乎都长一个样:一个 PM agent 把任务拆给 coder agent,coder agent 写完丢给 reviewer agent,reviewer agent 不满意又踢回去。视频里全程行云流水,看完让人想立刻在公司搭一套。

然后你真的搭了一套。

三个 agent 开始无限互踢,token 烧得心慌,跑到第二十轮你不得不强行按下停止键——它们正在为一个变量该叫 userId 还是 user_id 互相说服对方。

这就是过去一年 multi-agent 的真实落地状态:demo 惊艳,放上线,寄。

[配图建议:两三个 agent 头像之间互相循环的箭头,中间一个燃烧的 token 图标]

然后 Anthropic 在 Claude Code 里悄悄上了一个叫 Agent Teams 的功能。

这事看起来不大——藏在一个 experimental 的环境变量后面,默认关闭,文档措辞克制。但你把它的设计细节摊开看,会发现 Anthropic 在用一种跟所有人都不一样的方式,回答「agent 该怎么协作」这件事。

而且,它给出的答案,可能比所有 demo 都更接近正确。

过去一年的 multi-agent,都死在同一个坑里

把市面上你能想到的 multi-agent 方案抽象一下,大致都长这样:

你定义几个 agent 的角色——PM、coder、reviewer、tester。给每个角色写一段 system prompt。然后你启动一个 orchestrator,它来决定谁该出场、谁该闭嘴、什么时候 handoff 给下一个。

整套系统的核心假设是:让一个 LLM 来编排另一群 LLM。

听起来很合理。LLM 那么聪明,让它当中层管理者,有什么不行的?

行不行,跑过的人都知道。

落地里你会反复撞上三个坑。

第一个坑是无限循环。 两个 agent 在小事上死磕,你期待它们达成共识,它们却在反复让步、反复反悔。原因不复杂——LLM 没有”够了,这件事就这么定了”的执念,每一轮调用都是一次重新思考。一个人类项目经理喊一句「别吵了按 A 方案」就能停下来的事,agent 之间会吵到 token 烧光。

第二个坑是人没法介入。 当你看着屏幕觉得不对劲,想说一句「等等,别走那个方向」,你发现没有地方插嘴。orchestrator 在自己的循环里跑,你的输入要么打断整个流程,要么被完全忽略。你只能看着,像看着一台失控的洗衣机。

第三个坑是没有可观察性。 三个 agent 在跑,谁现在在干嘛?上一条消息是谁发的?哪个 agent 卡住了?大部分框架的答案是 console.log——一整屏滚动的文本,出了问题靠肉眼 grep。

这三个坑加起来,把 multi-agent 从「未来工作方式」打回成「demo 道具」。能录视频,不能交付。

但更深层的问题在底下——

这些方案的默认人设是「agent 自主跑,人事后看结果」。

这个人设在 2026 年的 LLM 能力上,就是不成立的。

不是 LLM 不够聪明,是它还不够「靠谱」。它在 80% 的场景下能做对,剩下 20% 会用一种你完全意想不到的方式翻车。如果你的产品形态默认”全自动”,那 20% 的翻车就是 100% 的事故。

所以行业过去一年的实际状态是:几乎所有 multi-agent 框架都在卷”如何让 orchestrator 更聪明”——更好的 routing、更细的 handoff、更复杂的对话协议。

没有人退后一步问:也许问题不在于 orchestrator 不够聪明,而在于「orchestrator 该不该是 LLM」这件事本身。

Anthropic 退后了这一步。

它不是另一个框架,它是一个工位

把 Agent Teams 这个东西摊开,它长这样:

你在终端里跟 Claude Code 聊天,聊着聊着你说一句「这件事 spawn 几个队友帮我并行做」。Claude Code 不是 fork 出几个进程,也不是去 import 一个 multi-agent 框架——它就在本地起几个独立的 Claude Code session,每个 session 是一个完整的、独立的 Claude。

这些 session 之间共享一份任务列表。文件就在 ~/.claude/tasks/{team-name}/ 下面,你可以 cat 它,可以 vim 它,可以 git diff 它。

它们之间通过一个叫 Mailbox 的东西互发消息。lead 可以给 teammate 发,teammate 也可以直接给另一个 teammate 发,不需要绕回 lead。

[配图建议:Anthropic 文档里那张 subagents vs agent teams 对比图]

这件事的关键不在「它能跑」,而在「它怎么设计的」。

第一个关键设计是:teammate 之间可以直接通信。

听起来是个小细节,但这是 Agent Teams 跟 subagents 的真正分水岭。subagents 是一个发散-汇聚结构——主 agent 把任务分出去,子 agent 各做各的,做完汇报回来,彼此不说话。这适合”你做你的、我做我的、最后我来综合”的场景。

但有一类工作 subagents 根本搞不定——需要互相挑战的工作。一个 agent 写了方案,另一个 agent 看完觉得有问题,需要直接跟前者讨论。这种来回不能走 lead 中转,因为 lead 一旦介入就会变成「裁判」,而你要的是「同行评议」。

Agent Teams 允许 teammate A 直接 ping teammate B,这就让「团队」这个词第一次成立了。subagents 是工具人,Agent Teams 是同事。

第二个关键设计是:人始终在环里。

这个设计在文档里被反复强调,措辞克制到有点像合规声明:

You stay in control. Claude won’t create a team without your approval.

翻译一下:Claude 不会未经你同意就拉一个团队。

你以为这只是一句客气话。但你顺着文档往下看,会发现每一个高风险动作都有人类闸门:

• 创建团队 → 需要你确认
• shutdown 一个 teammate → 需要发请求,对方可以拒
• 清理整个 team → 必须由 lead 走,且会检查活跃 teammate
• 高复杂度任务 → 可以强制 teammate 走 plan mode,lead 审批才能执行

这跟我们刚才说的那三个坑——无限循环、人没法介入、没有可观察性——是一一对应的。

这不是 Anthropic 客气。这是它在用 API 设计声明立场:LLM 不够可靠到能跑闭环,所以闭环里必须留一个人类插槽。

那这玩意儿到底怎么跑起来?

实操上只有三步。

第一步,在你的 ~/.claude/settings.json 里加一行环境变量打开开关:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

第二步,进入 Claude Code,用自然语言告诉它你想干什么、要几个队友、各自负责什么。不需要写 YAML、不需要定义 state graph,中文也行:

创建一个 4 人小组并行 review 这个 PR:一个看安全、一个看性能、一个看测试覆盖、一个看可读性。每人给出独立报告,你来综合。

第三步,等。lead 会自己拉人、自己派活、有问题主动 ping 你。你只在它确实需要决定的时候插话。

整套流程没有”配置”环节,只有”对话”。这一点跟你之前用过的任何 multi-agent 框架都不一样——后者你得先学一个 DSL,而这里你说人话就行。

让五个 Claude 互相打架,你会得到一个意外的答案

Anthropic 在文档里给的两个用例,前一个是「并行代码评审」——三个 reviewer 分别从安全、性能、测试三个角度看同一个 PR。这个例子很合理,但不算特别。

真正有意思的是第二个例子。我把原文抄下来:

Users report the app exits after one message instead of staying connected. Spawn 5 agent teammates to investigate different hypotheses. Have them talk to each other to try to disprove each other’s theories, like a scientific debate.

翻译:用户反映 app 收到第一条消息就退出。开 5 个 agent,各自抱一个假设,像科学辩论一样互相反驳,最后把幸存的共识写下来。

看到这个 prompt 的时候我愣了一下。

因为它解决了 LLM 调 bug 的一个底层缺陷——锚定偏差。

你让一个 LLM 调一个 bug,任何 bug,它会做的第一件事是产生一个”看起来合理的解释”。然后剩下 90% 的时间,它都在用这个解释去理解证据。证据跟假设不一致的时候,它会扭曲证据,而不是扭曲假设。

这不是 Claude 的问题,也不是 GPT 的问题,是这一代生成式模型的通病。你给它一个起点,它就在那个起点周围 1 米内打转。

单个 agent 调 bug,第一个假设是什么,基本就决定了它会走到哪里。

但是,5 个 agent 各抱一个假设,互相挑战呢?

A 说是网络层断了。B 说不对,是会话 token 过期。C 说都不是,是 message handler 抛异常被静默吞了。D 说你们都错了,是状态机的某个 state 被 race condition 覆盖。E 说我觉得是个根本不在这四个范围里的东西。

这五个 agent 互相挑战的过程,做了一件人类侦探剧里反复出现的事——每个侦探坚持自己的嫌疑人,然后互相找对方理论的漏洞。

这个结构的厉害之处在于:每个 agent 都受锚定偏差影响,但他们被锚在不同的点上。最后能在五轮辩论里存活下来的那个理论,大概率不是某个 agent 拍脑袋觉得最合理的那个,而是经得起其他四个角度反复怼的那个。

这等价于人类做事时用的一招——故意找人来反对你。一个想清楚问题的研究员,会主动去问”这个结论最大的反对意见是什么”。但 LLM 单兵作战时不会这么做,它会朝着自己的假设一路走到黑。

现在你强行让五个 LLM 互相反对,锚定偏差被结构本身消解掉了。

[配图建议:5 个 agent 头像围成一圈,每个之间都有双向箭头,中间是一个被各方质问的”假设”气泡]

这就让 Agent Teams 的定位变得很微妙。

大多数人想象的 multi-agent,是并行干活——5 个 agent 写 5 个模块,5 倍速。

Anthropic 这个例子里,5 个 agent 不是在并行干活,他们是在并行思考同一件事。

这是一个根本性的定位差异。

前者是把 multi-agent 当自动化工具用——目标是更快、更省人力。

后者是把 multi-agent 当认知工具用——目标是更准、更不容易自欺。

后者要难得多,但价值也大得多。因为单个 LLM 最大的弱点从来不是慢,是它在自信地犯错时,你看不出它在犯错。

哪些场景值得用这种”互相打架”的玩法? 我观察下来,大致四类:

• 根因不明的 bug:现象清楚但成因有多种可能时,让多个 agent 各抱一个假设互相反驳。Anthropic 文档那个 5 人辩论是典型。
• 架构方案选型:微服务还是单体、Redux 还是 Context、SSE 还是 WebSocket——这种”两种方案都成立、但工程后果不一样”的决策,让几个 agent 各抱一种各自推一波。
• PR 评审:文档里给的例子。安全、性能、测试覆盖、可读性各派一个 agent,比一个 reviewer 来回切换角度有效得多。
• 需求文档挑漏洞:把 PRD 丢进去,让几个 agent 分别扮演”想偷懒的开发”、“挑刺的测试”、“较真的安全”、“想钻空子的用户”,每人找一类漏洞。

反过来,如果你的任务是「这个单测为什么挂了」——别用辩论模式。一个 agent 就够,多开是烧钱。

那些不起眼的设计里,藏着一个判断

顺着 Agent Teams 的文档读,会有一些设计你第一眼看会觉得「呃,有点笨」。

比如任务列表是一个文件,在 ~/.claude/tasks/ 里,多个 teammate 抢同一个任务靠文件锁避免冲突。

学过分布式系统的看到这个会皱眉:文件锁?2026 年了还用文件锁?不应该是一个 actor model 加 message bus 吗?或者至少一个 Redis?

不是 Anthropic 不知道有更”先进”的方案。是它故意选了这一个。

因为文件锁是可观察的。你随时可以 ls,可以 cat,可以 git diff。你想知道现在团队在干什么,打开一个文本编辑器就能看见。

一个 message bus 你看不见。一个 Redis 你需要专门的工具。但一个 markdown 文件人人都能读。

这件事单独看是个小决定。但你把它跟其他几个决定放一起,会看见一致的姿态。

决定二:shutdown teammate 要发请求,对方可以拒绝。

这听起来很奇怪——子进程怎么可以拒绝被杀?但 Anthropic 偏偏这么设计:lead 发一个 shutdown_request,teammate 可以 approve(优雅退出),也可以 reject(并给出理由)。

区别在哪里?区别在,这是把 teammate 当同事而不是子进程。同事你拍肩膀让他下班,他可以说「我手上这件事还差五分钟,等我做完」。子进程不行,子进程只有被 kill。

这个设计意味着 Anthropic 认为:agent 自身的判断,在某些时刻应该被尊重。它有可能在做一件你看不见但重要的事。

决定三:subagent 的角色定义可以复用为 teammate。

你定义了一个 security-reviewer 子代理,有一天发现这个角色不只是「让它跑一次给个报告」那么简单——你希望它常驻一个团队、参与多轮讨论。Agent Teams 直接复用同一份定义,把它从 subagent 升格成 teammate。

这意味着「角色」在 Anthropic 的系统里是一等公民。一个 security-reviewer 是个对象,不是一段 prompt 模板。它可以被以不同方式调度——一次性、常驻、临时——但本身是稳定的。

决定四:三个介入点的 hooks。

Anthropic 给了三个 hook:TeammateIdle、TaskCreated、TaskCompleted。每个都可以让你写一段代码强制约束 agent 行为。

最实用的是 TaskCompleted。teammate 说自己任务做完了,准备 mark 成 completed——你的 hook 自动跑一遍 npm test。测试没过?exit 2 带上失败信息,teammate 收到反馈,自己回去重做。整个过程不需要你在场。

举个最小例子,在 .claude/settings.json 里这么写:

{
  "hooks": {
    "TaskCompleted": [{
      "command": "npm test || (echo '测试未通过,任务未完成' && exit 2)"
    }]
  }
}

这一行 shell 把质量门禁从 prompt 里搬到了 shell 里——从概率防御变成确定性防御。teammate 想跳过测试?系统级别不让。

另外两个 hook 用法类似:TeammateIdle 让你在 teammate 打算摸鱼时把它踢回去继续;TaskCreated 让你在它要建一个不该建的任务时直接拦下。三个 hook 加起来,你拥有了对 agent 行为的硬约束接口——不是相信它会听话,是不给它不听话的机会。

[配图建议:一个 2 列 4 行的表格。左列:文件锁 / Shutdown 审批 / 角色一等公民 / Hooks 介入。右列:可观察 / 尊重判断 / 可调度 / 强制约束]

把这四个决定连起来看,你会发现 Anthropic 在每一个 API 设计上都在重复同一句话:

LLM 还不够可靠到能跑全自治的 multi-agent system,但「半自治 + 强人类干预接口」是当下最能落地的形态。

这是一个产品判断,也是一个对当下 LLM 能力的诚实评估。Anthropic 没有装作”我们做到了 AGI 协作”,而是给出了一套承认 LLM 不够稳之后的工程妥协。

这种克制本身就是态度。

实战:什么时候该开 Agent Teams,什么时候别开

讲了这么多设计哲学,落到地上一个最现实的问题:你下次写代码时,什么情况值得开一个 team?

我给一个最朴素的判断框架。

值得开的四种情况:

1. 多角度评审:同一份代码或方案,需要从 N 个独立维度看一遍——安全、性能、UX、合规。一个 agent 切来切去容易顾此失彼,N 个 agent 各管一摊更彻底。
2. 根因不清的诊断:bug 现象明确但成因不明,用辩论模式让假设互相挑战。
3. 天然并行的新功能:一个 feature 拆得开——前端、后端、测试、文档各自独立。四个 agent 各占一摊,不打架。
4. brainstorm / 选型:需要主动产生多个独立视角的决策,比如选库、选架构、设计 API。

不该开的四种情况:

1. 任务很小:就改一个 if 条件——多开团队的协调成本远超收益。
2. 强依赖串行:必须先做 A 才能做 B,再做 C 才能做 D。这种任务根本并行不了,multi-agent 是负优化。
3. 多个 agent 改同一文件:Agent Teams 没有合并冲突的机制,两个 teammate 改同一份代码会互相覆盖。文档里专门强调过这条。
4. token 预算紧:每个 teammate 是一个完整 Claude 实例,token 按线性叠加。5 个队友跑半小时,等于你一个人跑两个半小时。

规模上,3-5 人是甜点区。 文档建议每个 teammate 配 5-6 个任务,这样既不闲也不挤。你有 15 个独立任务,起 3 个 teammate;你只有 6 个任务,起 1-2 个就够,别为了”用上 multi-agent”而硬开 team。

还有几个容易踩的坑,提前说在前面:

• /resume 和 /rewind 不支持 in-process 队友。会话断了,team 就废了——重要工作记得自己存个 task log。
• 任务状态会滞后。teammate 偶尔忘了把任务标完成,会让依赖它的任务卡住。看到卡住的任务,手动 update 一下。
• lead 偶尔自己抢着干活。本来该等队友的结果,它撸袖子自己上了。看到这种情况直接告诉它「等他们做完再继续」。
• 要同时管多个 team?办不到。一个 lead 一次只能管一个团队,做完了清理掉再开下一个。

最后一条最反直觉,但要点出来:Agent Teams 是工具,不是目标。能用单 session 写完的事,就用单 session——把节省下来的 token 留给真正值得辩论的问题。

人类 PM,Agent 同事

把视角拉远。

过去一年市面上 multi-agent 的主流形态,大致可以总结成几种:

• 重编排型:核心是一张 state graph,你定义节点和转移条件,agent 在图里跑。
• 重 handoff 型:核心是 agent 之间互相”交接”,像一条流水线。
• 重角色型:核心是一组预定义的人设(产品、研发、测试),让它们模拟一个团队。
• 重对话型:核心是 agent 之间聊天,聊到达成某种共识。

这些方案各有适用场景,但有一个共同的底色——它们都假设人类不参与中间过程。

Agent Teams 是另一种形态:

• 任务列表是文件,人可读。
• 通信靠 mailbox,人可旁观。
• shutdown 要审批,人可叫停。
• 关键节点有 hooks,人可拦截。
• lead 永远是你启动的那个 session,人可指挥。

它本质上是把 agent 协作的所有关键决策点,都暴露给人类。

我把这个形态总结成一句话:人类做 PM,agent 做可调度的同事。

这件事的有趣之处在于,它跟 Karpathy 几年前提出的 software 2.0 是一脉相承的——人在 AI 时代不是被替代,而是被升维。从写代码升维到设计代码,从执行任务升维到指挥执行。

Agent Teams 在干的事情是把这件事做成了开发工具的默认形态。它不需要你研究多 agent 编排理论,不需要你写 state machine,不需要你 deploy 一套服务。你打开 Claude Code,说一句「开个团队」,它就给你一个工位。

这件事的隐含结论也值得说一下。

既然 agent 协作的正确形态是「围绕人类构建的协作脚手架」,那这个脚手架不会从 LLM 框架里自己长出来。它必须由工具厂商提供。

而最自然的脚手架,就是 IDE。

因为 IDE 是开发者本来就在的地方,IDE 有文件系统、有 process 模型、有终端、有 UI——这些正是协作所需要的物质基础。在 IDE 外面搭一套独立的 multi-agent 平台,总会显得隔靴搔痒:你要在两个 app 之间切换,要 sync context,要重新 attach 文件。在 IDE 里,这些都是免费的。

Anthropic 把 Agent Teams 焊进 Claude Code,本质上是在占位:未来开发者跟 AI 协作的入口,不在浏览器,不在 SaaS 平台,而在你天天用的那个编辑器。

这个判断如果成立,接下来该紧张的就不只是 multi-agent 框架公司了。所有 AI Coding IDE 都得回答一个问题:你的工具有没有给开发者提供一个跟 agent 协作的可信框架?

没有,你就还停留在「单兵 AI 助手」这一代。

你的下一个 PR

回到开头那个我熟悉的场景。

三个 agent 在循环里互踢,我按下停止键的那一刻,曾经有一阵子让我对 multi-agent 这件事完全失去信心。

现在我大概明白当时为什么会失败了。

不是 LLM 不够聪明。是那一代 multi-agent 框架在一个错的抽象层上构建——它们假设了一个其实不存在的”自主 agent”,然后试图让多个不存在的东西协作。

Anthropic 这次的选择是反过来:承认 agent 不自主,所以把所有不自主的地方,都做成人类可以踩进去的接口。

这听起来一点都不性感。它没有 AGI 的味道,没有 swarm intelligence 的科幻感,没有惊艳的 demo 视频。

但它可能是当下唯一能跑起来的形态。

真正改变 agent 协作方式的,可能不是更聪明的编排算法,而是更克制的产品形态——克制到让人能随时插手、随时叫停、随时接管。

这意味着,在很长一段时间里,我们要的不是”被替代”,而是”被增援”。

你的下一个 PR,可能是三个 Claude 一起写的。

但谁来 review?

答案没变——还是你。

只不过,你 review 的对象,从一行行代码,变成了一支团队。