事情还是源于前段事件的Claude Code的源码，Anthropic家的命令行AI编程助手，被人在npm包里扒出来了一本无疑说是Agent构建教科书。

刚好最近工作也涉及到了Multi-Agent的完整实现，所以今天就想从「源码」视角，把 Claude Code 的多 Agent 机制和代价一起梳理一下，看看当多个AI agent要一起干活时，怎么让它们不打架、不阻塞、不乱花钱。

这篇文章我想跟你聊的，不是源码里每一行代码长什么样，而是我从源码里看到的那些真正重要的设计选择——。以及2026年整个行业都在搞Multi-Agent时，为什么Claude Code的做法仍然是最值得学的。

先说说2026年的行业现状吧，真的太魔幻了。

今年2月，Anthropic随Opus 4.6发布了Agent Teams，多个Claude实例可以并行工作，通过mailbox系统直接互相通信。不是那种一个主agent派任务给下属的玩法，是真正意义上的peer-to-peer协作。你可以用Shift加Up或Down直接接管任何一个subagent，像切tmux窗口一样自然。

同一个月，OpenAI的Codex App上线，号称能把多个AI编码agent放在同一个界面里协调。微软VS Code也跟进了，1.109版本支持并行跑多个subagent，还能在同一个Agent Sessions视图里比较不同agent的输出。Cursor 2.0的Composer甚至支持同时跑8个agent。

Gartner预测到2026年底，40%的企业应用会整合task-specific agents。

听着很热闹对吧。但热闹背后有个问题，大多数人包括我，都以为Multi-Agent的关键是，怎么让更多的agent同时跑起来。就像我曾经在项目中设计子agent的时候，满脑子想的都是，怎么让它们同时启动、怎么分配任务、怎么收集结果。

但实际上，真正的难点是，怎么让它们跑起来的时候不互相搞懵对方或者搞炸我的token...

这就是我想从Claude Code源码里跟你分享的第一个核心认知。

第一个问题，隔离，上下文隔离和工具隔离。

第一次我在项目里见识到多agent的破坏性，就是源于我想当然的把三个agent放在同一个环境里，它们共享同一份状态。测试agent删文件的时候，代码agent完全不知道，还在那傻乎乎地接着写。更离谱的是，三个agent同时读同一个配置文件，读出来的内容互相覆盖，最后谁写的都不知道。

我一开始的直觉是，给每个agent一份完全独立的上下文，各干各的，互不干扰。这思路看起来对吧，隔离嘛，就是别让他们碰面。

但Claude Code的源码告诉我，全隔离也不行。

想想看，用户按Ctrl加C想中止整个任务，主线程把中止信号广播出去，如果子agent因为是全新上下文收不到这个信号，它会对外面发生啥一无所知，自顾自继续跑。子agent跟世界完全脱节了，变成了一匹脱缰的野马。

所以Claude Code怎么做。它做了一个非常细腻的折中，按字段粒度决定每个状态该怎么处理。

读文件的缓存，克隆一份给subagent，这样子agent改多少文件都不会影响父agent的文件视图。改全局UI状态的权力，直接关掉，子agent只能看不能写，不然两边同时改同一份React状态，界面直接就花了。但注册后台任务的通路得留着，不然子agent起的后台进程变成孤儿，永远在后台跑没人回收，不知道汇报给谁。

还有深度计数。每派一个subagent，深度加一，超过阈值就报警甚至强制停止。这个设计棒，因为我自己踩过嵌套失控的坑，一个agent派了另一个，另一个又派了一个，token消耗直接指数级爆炸，跑俩任务token就限额了。

再来先说工具隔离。

主agent拥有一大堆工具，读文件、写文件、执行命令、派subagent、问用户问题等等几十个...但，我们不能把这堆工具原封不动地丢给subagent。

原因是，如果subagent也能调派新subagent的工具，那它就能派子子agent，子子agent又派子子子agent，盗梦空间了就属于是，token消耗直接起飞。再比如subagent通过工具直接改写和污染主agent的待办状态，主agent连干到哪儿了下一步干啥也不知道了。

所以Claude Code给subagent发工具的思路是按agent身份走三道准入门。

第一道门是所有subagent通用黑名单，被禁的工具有几类：能派新subagent的工具、能主动问用户问题的工具、能切换规划模式的工具、能停止其他任务的工具。 第二道门是自定义agent多套一层黑名单，自定义的agent比内置agent要再严一点，因为没有官方的安全保障。 第三道门是后台异步agent走白名单，这类agent完全后台跑，没法跟用户交互，所以只准用事先圈定好的一小批工具。白名单的逻辑是只有明确列出来的才能用，比黑名单更保险。

三道门走下来，每个subagent拿到的都是一份量身定制的工具池，既够它干活，又不会越权。

源码里其实就是一个过滤函数，顺着全局黑名单、自定义agent加严、异步白名单这三道条件依次判定。最后留下来的，才是这个subagent能用的工具。

我们借鉴到设计自己的多agent系统时，就记住一条原则，不要假设所有agent都能用所有工具，按类型做细粒度的权限控制。

我看完这块源码的感受是，所谓隔离不是一刀切，而是要根据每个状态的语义单独决策。这个细腻劲儿，正是工业级系统和玩具级系统的分水岭。

玩具级系统的思路是，给每个agent一份独立的环境，跑完拉倒。工业级系统的思路是，agent之间需要共享什么、需要隔离什么、需要保留什么通路，每一项都要精心设计。别说个人不需要工业级，除非你舍得花一个工业级的token成本让agent策马奔腾。

第二个问题，通信。

我最初的设计是，主agent调一个函数，等subagent跑完返回。这思路看起来没毛病，RPC不就是这么做的吗。后端开发那么多年，条件反射就是，A调B，B返回结果给A，天经地义。

但Claude Code的源码告诉我，这思路在agent场景里根本跑不通。

想想看，如果subagent跑一个5分钟的代码评审任务，那这5分钟里主agent在干嘛。答案是，它啥也干不了，被同步阻塞死了。用户在这5分钟里跟它说话也没反应，就像你给别人发微信，对方已读不回，你还得一直傻等。更可怕的是，如果你想同时派5个subagent并行调研5个模块，要么一个个排队等，要么得手动搓并发代码，整体乱成一锅粥。

我当初就是卡在这一步。我想让三个agent并行跑，结果它们互相抢资源，主线程被锁死，整个系统卡在那儿不动。

Claude Code的解法是，消息驱动。

每个subagent有一个信箱，父agent要给它布置新活，就往信箱里扔一张字条，然后立刻返回，不站在那儿等。subagent自己的agentic loop每轮结束后瞄一眼信箱，有新字条就捡起来注入对话历史，带着新消息进入下一轮LLM调用。

这个设计妙在哪。它天然异步，天然支持并发，天然兼容agentic loop。父agent从来不阻塞等子，它可以同时派5个subagent出去，谁先完成谁先给它发通知，按到达顺序处理就行。

更妙的是，subagent跑完之后的完成通知，Claude Code不是用结构化对象发的，而是拼成一段XML，伪装成一条用户消息塞给父agent的对话历史。为啥这么搞。因为LLM对XML非常友好，Anthropic训练Claude的时候就强调了XML的结构化表达。而且XML是纯文本，可以直接塞进对话历史，父agent不需要额外的状态机去等通知，它就像收到一条新的用户输入一样处理。

这种把系统事件伪装成对话的设计，它不是从技术角度出发的，是从LLM的认知角度出发的。它考虑的不是，我怎么给父agent发一个事件，而是，父agent作为一个LLM，它最自然地处理什么格式的信息。

还有一个很妙的设计，auto-background。subagent跑起来之后，如果30秒内跑完，主agent就在前台阻塞等，像普通工具调用一样。但如果超过2分钟还没完，自动转到后台，主agent可以先继续干别的。这个设计说到底是在把同步工具调用自动降级成异步通知，没有它，长任务会一直占着主agent的执行权。

整个通信体系就两个关键字->异步+消息。没有直接函数调用，没有锁，没有回调地狱，全靠读写共享的任务状态和消息队列。

第三个问题，成本控制。

曾几何时我以为Multi-Agent就是把活分出去，花多少钱是不变的，就是执行上快了一些而已，模型那么聪明，这点账算不明白么。

好的它算不明白，我懒得算+模型它不算，结果就是几个富二代agent同时挥霍我的token。

Claude Code的源码里有一个特别隐蔽但又特别精妙的设计，叫Fork Subagent。它不是为了解决功能问题，是为了解决经济问题。

先补一个背景知识。Claude Code的system prompt长度是上万token，里面塞了大量的工具说明、规范约定、用户上下文。每派一个常规的subagent，如果它有自己独立的system prompt，LLM API那边就得对这一万多token重新从头算一遍。

这有两个代价，钱和延迟。在生产环境里，subagent派得越频繁，这个开销线性放大。

Anthropic有个prompt缓存机制可以缓解这事。API请求里如果前缀跟之前某次请求字节级别完全相同，这段前缀可以不重新算，直接走缓存，价钱只要原来的10%，延迟也大幅降低。

关键来了，prompt缓存命中的条件是什么。字节级别完全相同。系统prompt一个字不一样、工具列表顺序不一样、甚至空格位置不一样，都会直接没命中缓存。

所以Claude Code设计了一种特殊的subagent，叫Fork Subagent。它的system prompt和工具池跟父agent完全一样，这样就能复用父的缓存。具体要对齐五样东西，系统prompt的内容、用户上下文、系统上下文、工具池的顺序和定义、对话历史的前缀。五样都一致，缓存就命中了。

一个特别有意思的细节是，Fork Subagent的system prompt不重新生成。正常的subagent有个生成system prompt的函数，跑的时候现生成一段文本。但Fork机制用的那个函数直接返回空字符串。为啥。因为Fork subagent的system prompt根本不走这个函数生成，而是直接用父agent已经渲染好的那份字节。如果重新调一次生成函数，里面可能有些小差异，生成出来的prompt跟父agent就可能差一个字符，缓存就没了。最稳的办法是，把父agent那边已经渲染出来的prompt，作为字节原样拿过来用，一个字节都不动。

这个设计并不是在解决一个技术问题，而是在解决一个经济问题。Claude Code靠Fork机制，在缓存友好的场景下能把subagent的成本降到原来的10%左右。这代表什么，你的subagent可以调得更频繁。原本成本考虑不敢派的活，现在都能派了，这反过来又让整个agent系统的能力边界扩大了。

成本优化本身就是能力的一部分。格局大大！

说完这三个核心问题，我想聊聊Claude Code里一个真正能把Multi-Agent威力发挥到最大的模式，Coordinator模式。

前面讲的subagent，不管是常规的还是Fork的，本质都是父子结构。父agent派一个子，自己该干啥干啥，子完成了通知一声。这种模式适合单个任务加临时帮手，就像你临时叫个外卖员帮你跑个腿。

但如果你的任务量很大，需要一堆agent同时开工呢。比如一个大的代码迁移，要并行调研10个模块。这时候父子结构就显得单薄了，就像你一个人管十个外卖员，每个都要你亲自派活、亲自收结果，你根本忙不过来。

Coordinator模式下，主agent不干实际工作了，它只做三件事，派worker、收结果、合成答案。它是个纯协调者，通过system prompt强制约束出来的。

这个模式的prompt里有句我特别喜欢的话，Parallelism is your superpower. Workers are async. Launch independent workers concurrently whenever possible, don't serialize work that can run simultaneously and look for opportunities to fan out.

翻译一下，并行是你的超能力，worker全是异步的，能并行的绝不串行，多找机会一口气派一堆出去。

这句话背后是一个很关键的工程事实。Claude Code的派worker工具调用可以在同一条assistant消息里出现多次，底层会一起并发执行，不是一个跑完再跑下一个。所以协调者要做的就是在一次LLM回合里，一口气生成多个派worker的工具调用。派worker调研auth模块、派worker调研session模块、派worker调研token模块，三个调用同时启动，三个worker同时干活。

串行和并行的差距有多大。串行，派worker1等结果派worker2等结果派worker3，用户等十分钟。并行，同时派三个worker，三份结果陆续到，用户等三分钟多一点。这就是并行是超能力的真正含义。

协调者的任务流水线被切成四个阶段。调研阶段workers并行，调查代码库、找文件、理解问题。合成阶段协调者亲自做，读完发现、理解问题、写实现规格。实现阶段workers按规格做具体修改。验证阶段workers测试改动是否真的工作。

注意中间的合成阶段是协调者亲自做，这是协调者存在的意义，理解全局，做决策。prompt里反复强调，不要偷懒让worker基于你的发现去实现修复，而是自己把发现读懂、写成具体的规格再派下去。如果协调者只是转发，它就没有存在价值，worker直接跟用户对话就行了。

协调者要持续派活，遇到一个新任务，是给老worker发消息续命，还是派个新worker从头开始。Claude Code的prompt里给出了一张决策表。新任务跟worker现有上下文高度相关，续命老worker，因为它已经知道那些文件了。新任务跟worker现有上下文没关系，或者之前worker的工作走偏了，派新worker，避免旧上下文干扰判断。验证这种需要新鲜眼光的工作，永远派新worker，不能让刚写完代码的worker自己验自己。

这个设计其实挺反映人类团队合作的直觉。有的活就该让懂上下文的人接着干，沟通成本低。有的活就该换个人做，避免认知偏差。就像你自己写了一份代码，你会倾向于觉得它没问题，这时候就需要一个 fresh eyes 来挑错。

讲完Claude Code的源码，我想补充两个2026年的业界面相，这套东西不是孤例，而是整个行业正在发生的范式转移。

第一个，Agent Teams。2026年2月Anthropic发布的Agent Teams，跟Coordinator模式不是同一个东西。Agent Teams是多个Claude实例真正并行工作，通过mailbox系统互相通信，peer-to-peer，不是只能hierarchical。Anthropic内部用这个功能做了一个完整的C编译器，2000个sessions，2万美元的API成本，10万行代码。

这个数字是什么概念。2万美元API成本做一个C编译器，放在以前想都不敢想。而且它不是在吹牛，Anthropic的Boris Churnney在2026年5月的Code with Claude活动上直接说，Anthropic内部已经没有手写代码了。Clouds通过Slack互相协调，代码在循环里自己跑，问题在代码库里自己解决。他特别反感vibe coding这个词，觉得它低估了实际发生的事。

第二个，整个行业的跟进速度。2026年2月到现在，OpenAI的Codex App、微软VS Code、Cursor 2.0、Composio全都在推multi-agent并行。Pydantic AI Harness在3月就发了multi-branch coordination方案，用git worktree做隔离，每个agent跑在自己的分支上，最后统一合并。VS Code现在甚至支持Claude和Codex agent同时在同一个界面里跑，你可以直接比较它们的输出，挑一个最好的用。

但有意思的是，大家搞的方向不太一样。有的是hierarchical，有的是peer-to-peer，有的是基于git worktree的隔离，有的是基于消息队列的通信。Claude Code的源码之所以能当教科书，是因为它在每一个维度上都给出了清晰的选择，而且这些选择是自洽的、成体系的。

写到这里，我想把这套东西浓缩成5条可以直接用到自己项目里的原则。

第一条，上下文隔离要按字段粒度做。不要粗暴地给subagent一个空context，也不要全盘共享。对着父agent的每项状态问一句，子agent拿这个状态干啥，会不会影响父，就能避开大部分坑。

第二条，通信走消息，不走函数调用。父到子是写入子的消息队列，子下一轮循环自己读取。子到父是把完成通知包装成XML消息，伪装成用户消息注入父的对话。天然异步、天然支持并发、天然兼容agentic loop。

第三条，工具权限要分级管控。全局黑名单防递归防乱问用户，类型黑名单自定义agent更严，异步白名单后台agent只能用子集。每种agent按自己的场景配工具，不要一刀切。

第四条，缓存友好是一种架构能力。API成本和延迟对生产环境agent来说是能力的一部分。设计subagent的时候，考虑它的prompt前缀能不能复用父agent的缓存，能省80%到90%的成本。

第五条，并行优先加协调者合成。真正的多agent系统威力在并发。通过异步消息和消息队列做基础，通过协调者做合成，避免大agent大循环什么都自己扛的窘境。协调者要亲自合成，不能当传话筒。

最后我想说说看完这些源码后，我自己的一个真实感受。

我之前搞agent项目崩掉的时候，我的第一反应是，肯定是我代码写得有问题，或者模型不够强。我甚至怀疑过，是不是我用的模型太便宜了，换个贵的就能好。

但看完Claude Code的源码后，我意识到问题不在这。问题在于，我把Multi-Agent想得太简单了。

我以为它就是多开几个agent让它们一起干活。但工业级的Multi-Agent系统，要考虑的是隔离、通信、并发、成本、递归控制，每一个维度都有它自己的陷阱，而且陷阱之间还会互相影响。你解决了隔离，通信又出问题。你解决了通信，成本又扛不住。你压住了成本，并发又上不去。

Claude Code的源码最厉害的地方，不是它用了什么高深的技术，而是它在每一个看似不起眼的地方都做了选择。隔离是全隔离还是部分隔离，通信是同步还是异步，成本是忽略还是优化，这些选择没有标准答案，但Claude Code给出了它自己的答案，而且这些答案是自洽的、成体系的。

这可能就是为什么2026年整个行业都在搞Multi-Agent，但Claude Code的做法仍然最值得学。因为它不是在一个个孤立的功能点上发力，而是在一个完整的系统思维里，把每一个选择都串了起来。

大时代啊，朋友们。