导读：真正成熟的 AI Agent 协作，不是把多个机器人拉进同一个聊天框，而是让每个执行单元拥有独立上下文，再通过共享任务图、可持久消息、集中权限和事件驱动机制协同工作。

本文将围绕一个核心问题展开：如果要让多个 AI Agent 像工程团队一样并行工作，系统底层到底需要哪些“看不见但很关键”的机制？

一、别再把多 Agent 协作理解成“多开几个聊天窗口”

很多人第一次听到 Agent Teams，会自然联想到“一个负责人带几个助手”。这个理解只对了一半。真正有价值的部分，不是队友数量变多，而是协作方式从“单点输出”升级成“共享状态驱动”。

单会话更像一个人从头做到尾；子 Agent 更像负责人临时派一个专家去查资料、跑测试、做审查；Agent Teams 则更接近一个小型工程团队：有人负责拆任务，有人负责研究，有人负责实现，有人负责验证，彼此之间可以交流，任务状态也会被统一记录。

这套机制的关键是：每个队友都有自己的上下文窗口，不必把所有过程塞进负责人上下文里；团队之间通过任务表、消息邮箱、权限请求、事件通知来协作。也就是说，它不是“群聊”，而是一套轻量级多进程协作系统。

形态	适合场景	核心优势	主要代价
单会话	短任务、顺序任务、单文件修改	简单、便宜、可控	上下文容易拥挤，难以并行
Subagent	专项调研、局部测试、独立审查	隔离上下文，结果回传清晰	Worker 之间协作能力有限
Agent Teams	并行探索、跨层任务、多角色讨论	共享任务表，队友可直接通信	Token 成本更高，调度更复杂

如果任务本身没有并行价值，比如只改一个小配置、修一个确定错误、补一个文案，单会话反而更好。如果任务天然可以切成多个角度，比如架构调研、跨端改造、复杂缺陷排查、代码审查与测试并行推进，团队机制才值得打开。

二、平面团队：为什么队友不能无限派生队友？

Agent Teams 的队伍结构是“平面”的。负责人负责创建团队，队友挂在同一张团队名册下面，每个队友都有清晰身份，比如 researcher@team、tester@team。系统故意避免“队友再派生队友”的层层嵌套。

原因很简单：一旦允许无限委托，团队名册、权限归属、消息路由和结果回收都会迅速失控。谁对谁负责？哪个队友拥有审批权？哪个任务属于哪个上级？这些问题如果不在结构上限制，后面靠提示词很难补救。

所以它采用平面团队：所有队友都能被负责人看见，所有成员都在同一张团队配置里，沟通和任务分配围绕同一个团队运行。这种设计牺牲了无限扩展的“想象力”，换来了工程上最重要的可控性。

• 负责人负责拆解、分配、综合和审批，是团队的协调中心。

• 队友拥有自己的上下文，适合独立完成一个清晰任务。

• 团队名册是运行时事实来源，记录成员、会话、后端、权限模式等信息。

• 队友不能继续生成队友，避免组织结构变成不可追踪的树状委托链。

三、共享任务图：真正的协作核心不是消息，而是 TaskList

很多人会以为多 Agent 协作最关键的是“怎么互相发消息”。实际上，消息只是协作的补充，真正的调度核心是共享任务图。

任务表不是普通 Todo 清单。普通 Todo 只有“做没做”；共享任务图还记录任务依赖。一个任务可以阻塞另一个任务，也可以被多个任务阻塞。只有前置任务完成后，后续任务才会自动变成可执行状态。

这个设计让并行不再依赖自然语言协商，而是依赖显式状态。例如，研究任务完成后，开发任务才解锁；开发任务完成后，测试任务才解锁；测试完成后，负责人再整合结果。每一步都能被状态机追踪。

TaskList 把任务从待办清单升级成依赖图

字段/概念	通俗解释	工程意义
pending	任务还没开始	可被队友领取，但可能被依赖阻塞
in_progress	任务已经被某个队友领取	避免多人同时做同一项
completed	任务完成	会解锁依赖它的后续任务
owner	当前任务归属哪个队友	解决并发抢占和责任归属
blockedBy	当前任务依赖哪些前置项	让顺序关系变成可计算状态
blocks	当前任务会解锁哪些后续项	让完成事件能推动任务图前进

这就是团队协作的第一条底层原则：先把任务变成状态，再让 Agent 围绕状态工作。没有状态外部化，多 Agent 只能靠聊天猜彼此进度；有了共享任务图，系统才能知道谁在做什么、什么能做、什么还不能做。

四、自动 Claim：一个很小但完整的调度器

当队友空闲时，运行时会去任务表中寻找可领取任务。可领取任务通常要满足三个条件：状态是 pending；还没有 owner；它依赖的前置任务已经完成。

找到任务后，系统会先把这个任务“抢占”给当前队友，再交给它执行。如果提交失败，就释放抢占，让后续流程重新选择。这个小动作非常关键，因为多个队友可能同时看到同一个任务，如果没有原子抢占，就会出现重复执行和结果覆盖。

这里最值得学习的工程思想是：调度和推理要分离。模型负责理解任务内容和产出结果，运行时负责判断任务是否可执行、是否已被别人领取、依赖是否已经满足。

这也是很多企业做 Agent 平台容易踩坑的地方：把所有判断都塞给大模型，让模型自己在自然语言里判断“我该做哪个任务”。短期看很灵活，长期看不可控。成熟做法应该是把关键状态结构化，让模型只处理它擅长的部分。

五、Mailbox：为什么文件系统也能成为多进程通信层？

Agent Teams 的消息系统采用一种很务实的设计：用文件系统 Mailbox 做跨进程通信。每个队友有自己的 inbox，消息写进去后，接收方再读取。

这种做法看起来没有传统 IPC、RPC、Socket 那么“高级”，但非常适合 AI Agent 场景。因为 Agent 协作通常不是微秒级交易，而是秒级、分钟级任务推进。更重要的是，人类需要能调试：队友卡住时，可以去检查邮箱文件，看看它到底收到了什么、是否已读、最近一次 idle 是什么原因。

• 名称寻址：发送给某个指定队友，比如 researcher 或 tester。

• 广播寻址：发送给团队内多个成员，用于统一通知。

• 本地 Socket 扩展：当需要低延迟或跨实例通信时，可以扩展到本机其他实例。

• 远程 Bridge 扩展：把消息投递到远程控制对等端，形成更大的协作拓扑。

这背后有一个很重要的架构取舍：Agent 系统的通信不一定要追求最低延迟，而要追求可恢复、可审计、可理解。文件邮箱恰好天然具备这些优势。

六、事件面：TaskCompleted 与 TeammateIdle 让团队自动续跑

一个队友执行完一轮任务后，如果只是停在那里，系统仍然需要人工不断提醒。成熟的团队协作机制会在回合结束后触发事件，让后续流程自动发生。

常见的两个关键事件是任务完成和队友空闲。任务完成可以触发质量门禁，例如检查结果是否足够完整；队友空闲可以通知负责人，也可以让队友回到任务图继续领取新工作。

这套设计让团队系统不是纯 pull，也不是纯 push。pull 指空闲队友主动回到任务表找活；push 指任务完成和空闲状态主动触发通知或后续自动化。两者叠加后，多 Agent 协作才有“自己转起来”的能力。

七、异步 Agent 生命周期：后台任务要能跑、能看、能杀

当一个 Agent 被设置为后台运行时，它会进入异步生命周期。它不是主线程的临时函数调用，而是一个被注册、可跟踪、可上报、可完成、可失败、可显式终止的后台任务。

这点在长任务里非常关键。用户可能中断当前主流程，但后台队友仍然可以继续做研究、验证、整理结果。系统必须记录它的 agentId、进度、状态和最终输出，否则后台并行就会变成不可见的黑盒。

这里还涉及工作区隔离。多个队友同时改动代码，如果都挤在同一个目录，冲突几乎不可避免。通过独立 worktree，每个执行单元可以在自己的分支目录里工作，减少互相覆盖的风险。官方资料也强调，worktree 的价值是让并行会话的文件修改互不碰撞。

八、三种后端：tmux、iTerm2、In-Process 的统一抽象

团队机制需要落到真实运行环境。不同用户环境不一样：有人在 tmux 里，有人在 iTerm2 里，也有人什么终端复用器都没有。系统不能因为缺少某个工具就完全不可用，所以引入了后端适配层。

tmux 和 iTerm2 模式会启动独立 CLI 进程，并以分屏方式展示队友输出；In-Process 模式则在同一个进程内运行多个队友，通过上下文隔离和内存队列模拟完整通信协议。

后端	进程模型	通信机制	适合人群
tmux	独立 CLI 进程，终端分屏	文件 Mailbox	Linux/macOS 用户，适合并行可视化
iTerm2	独立 CLI 进程，iTerm2 分屏	文件 Mailbox	macOS 用户，重视终端体验
In-Process	同进程运行，靠上下文隔离	内存消息队列	没有终端复用器，或需要轻量回退

真正优雅的设计在于：上层工具不用关心队友到底运行在哪种后端。负责人只负责创建队友、发送消息、分配任务，底层自动选择最合适的执行方式。

九、权限同步：队友可以并行，审批必须集中

多 Agent 并行之后，一个安全问题马上出现：如果每个队友都能自行审批危险操作，系统风险会急剧放大。成熟做法是把危险操作审批集中到负责人。

当队友遇到权限检查时，它会创建权限请求，写入 pending 区域，同时通知负责人。负责人展示给用户审批，结果再写入 resolved 区域。队友轮询到结果后再继续或停止。

这就是“并行执行”和“集中授权”的分离。队友可以并行探索、并行测试、并行修改，但只要碰到高风险动作，就必须回到统一审批链。这个原则非常适合企业级 Agent 平台：效率交给队友，安全交给控制平面。

十、团队记忆：共享知识不是共享混乱

团队记忆用于保存所有成员都需要知道的事实，比如项目约定、接口结论、历史决策、测试经验等。它和个人记忆分开，避免个人偏好污染团队事实。

但共享记忆也带来安全风险：如果路径没有严格验证，恶意输入可能尝试写出目录、利用编码绕过、利用 Unicode 伪装路径、制造符号链接循环。

• 拒绝空字节，避免底层路径截断问题。

• 拒绝编码后的目录穿越，避免用转义形式绕过检查。

• 拒绝 Unicode 伪装字符，避免看起来像普通路径但语义不同。

• 拒绝反斜杠逃逸，避免跨平台路径差异带来的漏洞。

• 检测符号链接循环与路径逃逸，确保最终位置仍在允许范围内。

这说明记忆系统绝不只是“保存一段文字”。在 Agent 工程里，任何能写入长期状态的机制，都必须被当成安全边界来设计。

十一、In-Process 模式：同进程协作也要保持身份隔离

当没有 tmux 或 iTerm2 时，系统会回退到 In-Process 模式。它的目标不是偷懒，而是在同一个进程里尽可能还原队友协议：每个队友仍然有身份、上下文、消息队列、空闲状态和独立取消控制。

这就像在一个大办公室里安排多个工位：虽然物理空间在一起，但每个人的任务、对话、状态和责任仍然分开。

这种设计还有一个好处：上层 API 不变。无论底层是分屏进程还是进程内队列，负责人都可以用同一套方式管理队友。对用户而言，这是体验一致；对工程而言，这是抽象边界清晰。

十二、文件 Mailbox 与传统 IPC：不是落后，而是取舍不同

有些人看到文件 Mailbox 会觉得不够现代。但在 AI Agent 团队协作里，它其实很务实。因为 Agent 的执行周期通常较长，失败恢复和人类调试比极限延迟更重要。

如果做的是高频服务调用，RPC 当然更合适；但如果做的是多 Agent 工程协作，消息能不能留下痕迹、能不能被人看懂、进程崩溃后能不能恢复，反而更关键。

十三、从系统设计看，Agent Teams 真正提供了什么？

把前面所有机制串起来，可以看到 Agent Teams 提供的不是“多个 AI 同时回答”，而是一套协作运行时。

• 组织层：平面团队结构，避免无限委托。

• 调度层：共享任务图、依赖解锁、自动 claim。

• 通信层：Mailbox、名称寻址、广播、本地和远程扩展。

• 事件层：TaskCompleted、TeammateIdle 让队伍自动续跑。

• 生命周期层：后台 Agent 可注册、可跟踪、可通知、可终止。

• 安全层：权限集中审批，危险动作回到负责人。

• 记忆层：团队事实共享，同时防止路径逃逸和注入。

• 后端层：tmux、iTerm2、In-Process 统一适配。

这套能力的长期价值在于，它让 AI Agent 从“一个聪明助手”逐步变成“一个可管理团队”。未来企业内部真正有用的 Agent 平台，大概率都会走类似方向：任务结构化、状态外部化、权限集中化、结果可追踪。

十四、普通开发者和团队怎么用这套思想？

即使暂时不直接使用 Agent Teams，也可以把它背后的工程思想用到自己的 AI 应用里。

1. 先拆任务，再开并行

不要一上来就开很多 Agent。先判断任务是否真的能并行，文件范围是否能分开，依赖关系是否清楚。如果多个队友都要改同一批文件，冲突成本可能超过并行收益。

2. 把状态写出来，不要全靠自然语言记忆

任务状态、消息状态、审批状态、队友状态，都应该有结构化记录。只有状态写出来，系统才有恢复、追踪和自动续跑的可能。

3. 负责人不是摆设，而是控制平面

负责人要做三件事：拆任务、做审批、合结果。它不一定亲自完成所有细节，但必须掌握全局状态和安全边界。

4. 并行越强，越需要隔离

并行队友越多，就越要考虑 worktree、权限审批、消息追踪、任务锁定和完成门禁。否则表面上效率提高，实际可能产生更多冲突和返工。

十五、总结：AI Agent 的团队化，核心是“共享状态 + 独立上下文”

Agent Teams 的关键启发可以用一句话概括：让每个 Agent 拥有独立上下文，同时让它们围绕共享状态协作。

独立上下文解决的是容量问题。每个队友可以专注一个方向，不必把所有中间过程塞进负责人对话里。共享状态解决的是协作问题。任务表告诉队友该做什么，Mailbox 让队友能交流，事件面让系统能续跑，权限同步让安全不失控。

所以，真正的多 Agent 工程不是“多几个模型并发调用”，而是把组织结构、任务依赖、消息通信、权限审批、记忆共享、异常恢复和后端适配做成一个可靠运行时。

这也是未来 AI 编程工具、企业 Agent 平台、自动化研发系统要重点建设的方向：少一点玄学提示词，多一点工程化状态机；少一点盲目并行，多一点可恢复、可观测、可治理的协作内核。

---

参考资料：https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd=6fkr