过去一周，我把自己当成一个“数字团队经理”，在 Claude Code 里组了几拨多 Agent 的小队，审 PR、重构模块、做并行调研。体验很直接：这不只是把算力并行化，而是在软件里复制一套组织设计。换句话说，多 Agent 如果只看作工具，你会嫌它“费 token、易跑偏”；但如果像管理真实团队那样做角色、立规矩、设质量门，多 Agent 的产出会像项目冲刺一样有节奏地落到地面。

我的核心观点是：把 Agent Team 当“团队”来管理，而不是“助手”来指挥。角色清晰、边界明确、沟通可见、质量可控，Claude Code 就能跑出组织效率；反之，它会变成一场并行的噪音。

一句话的心智模型：从单体到团队

单会话的 AI 助手，更像单体应用，所有上下文挤在一个窗口里，信息一多就开始压缩和遗忘。Agent Team 则像微服务加上一个项目经理：

• Lead Agent 负责规划与协调，像 PM/Tech Lead；
• 多个 Teammate 有独立上下文，各自承担专业任务，互不干扰但能通信；
• 共享任务列表像看板，配合依赖与锁，尽量避免踩踏；
• 消息系统承担“Slack”角色，支持点对点与广播、计划审批与优雅关停。

很多人会把它和 SubAgent 混淆。差异在于信息流与协作方式：SubAgent 只能向主会话回报结果，彼此之间无法对话；Agent Team 的 Teammate 可以直接通信，用户也能随时插话。简单说，SubAgent 是“调用链”，Agent Team 是“协作网”。当任务需要讨论、挑战、并发推进，后者才显得有生命力。

从系统提示词看架构意图：设计的是协作，而不是工具拼装

Lead 的主动性与边界

系统提示词里明确写着“proactively”判断是否开团队。这是一种产品哲学：工具不等你发号施令，它会主动评估任务复杂度并建议并行。这听上去很聪明，但作为 PM，我会在提示词里加两条“管理学”的约束：

• 给开启团队设门槛和预算提示，比如“当子任务数≥2且文件集合重叠度低于 30%时建议组队，预计 token 增幅约 N 倍”；
• 对 Lead 开团队的行为加可见日志，让用户清楚“为什么要多人协作”，避免“默默扩容”。

Teammate 的上下文隔离与沟通契约

Teammate 不继承 Lead 的对话历史，只加载 CLAUDE.md、MCP servers 和 Skills。好处是执行更专注，也更可控；副作用是“失忆”，如果你的需求描述含糊，它就会走样。系统提示词里还有一条关键规则：只用 SendMessage 工具进行团队沟通，普通输出不会被他人看见。这是显式沟通契约的体现。

在实际管理中，我会给每个 Teammate下发一页“沟通模板”：状态、风险、依赖、下一步。就像真实团队的日报，它能把隐性认知变成显性协作，降低跑偏概率。

任务列表是看板，不是备忘录

任务有 pending/in_progress/completed 三种状态，还支持依赖与文件锁。提示词鼓励以 ID 顺序认领，同时定期检查列表。这些都是典型的看板实践。我会再加两条团队规则：

• 为任务绑定“文件所有权”，写明谁可以改哪些目录；
• 让下游任务显示上游的完成标准，避免“名义完成”。

这是解决文件冲突的根本之道：任务依赖+所有权边界，比“善意提醒”更有效。

Mailbox 不只是消息，更是治理

消息系统支持私信、广播、关停握手，以及 plan_approval_response（方案先审再做）。我把这一套看作“治理机制”：把“规划—审查—执行—关停”变成可观察的过程，才能把并发风险关在笼子里。广播的成本随人数线性增长，这也提醒我们：不要用广播替代清晰的任务接口。

把开关打开，先跑一个有价值的团队

Agent Team 还是实验功能，需要通过环境变量开启：

• settings.json：{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" }}
• 或 export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

对第一次尝试的人，我会推荐一个“可感知价值”的用例：让三个审查员分别从安全、性能、测试覆盖率三个角度审查同一个 PR，最后由 Lead 汇总报告。它没有写文件风险，反馈容易对齐，能让你体会“多视角并行”的真实收益。

显示模式怎么选更省心

• in-process：默认模式，一个终端内切换 Teammate，易上手、通用；
• split-pane：每个 Teammate 一个面板，看起来很酷，但对终端兼容有要求，适合老手。

我的建议是先用 in-process 熟悉节奏，再考虑分屏。工具应该服务协作，而不是成为协作的负担。

一个真实场景：重构 auth 模块，避免把“并行”变成“混战”

我常用的分工是：

• 一位负责核心认证逻辑；
• 一位负责相关测试更新；
• 一位负责 API 文档同步。

关键在于边界声明：“每个人只改自己负责的文件”。把任务依赖做成“逻辑先于测试，测试先于文档”，再配合所有权约束，能够避免最常见的文件覆盖事故。很多人把这句话当提醒，我把它当制度：不带边界的并发，等于邀请冲突。

进阶玩法：让流程为你兜底

Delegate Mode：把 Lead 变回项目经理

Lead 常常“手痒”自己写代码。切换到 Delegate Mode，它就只能用协调工具，不读写文件、不执行命令。对产品经理而言，这是把“角色边界”写进系统，避免技术负责人在关键节点“越俎代庖”。

Plan Approval：方案先过审，执行才动手

高风险改动我会强制要求 Teammate 进入“plan mode”：只读探索、输出方案、等待审批。这一关是质量的分水岭，尤其是涉及数据层、鉴权、接口稳定性时。

Hooks：把质量门变成自动化守夜人

• TeammateIdle Hook：空闲前触发，exit code = 2 可退回继续工作——可用于“测试未过不准闲”；
• TaskCompleted Hook：任务标记完成时触发，exit code = 2 阻止完成并反馈——可用于“必须 lint 干净、覆盖率达标”。

这不是苛刻，而是把“完成定义”写进系统。AI 说“已完成”，与“确实完成”，中间隔着一个验收门。

直连 Teammate：在跑偏现场纠偏

当 Teammate 偏航，用 in-process 切换或在分屏模式里直接对话，效果比通过 Lead 转述更快。真实团队里我们也这样做：到现场，明确问题，把偏差当场收敛。

避坑清单：来自几次“翻车”后的复盘

文件冲突是头号风险

任务列表有文件锁，但文件写入没有锁。并发编辑同一文件，覆盖丢失最常见。解决办法不是“更小心”，而是在任务分配时划清所有权，并用任务依赖减少共享写入的时段。把约束写在 CLAUDE.md 与任务描述里，效果立竿见影。

Lead 与 Teammate 都可能“失控”

Lead 喜欢下场写代码，Teammate 喜欢扩展任务边界。我的做法是“双重保险”：提示词明确角色、Delegate Mode 限制行为，再用 Plan Approval 把执行权握在审查手里。任务颗粒度也要适中，越大越容易偏航且难以纠偏。

Token 消耗不是小事，是预算

每个 Teammate 都是一个独立实例，团队人数乘以上下文往返，就是新增的预算。我们曾做过内部演练：5 人团队的成本接近 5 倍，若加方案审批、消息广播等流程，开销还会继续放大。我的经验是：

• 从 2-3 个 Teammate 起步；
• 能用 Sonnet 不用 Opus，除非任务确有复杂性；
• 把“预算”写在提示词里，提醒 Lead 做权衡。

Teammate 的“失忆”要用上下文补回来

它不读 Lead 历史，所以起步时的提示词要充分：任务背景、文件范围、关注点、约束条件都要写清。更重要的是，长时间运行的任务有较高中断风险，尽量拆成短步执行，减少不可恢复的损失。

协作摩擦的琐碎成本

有时 Teammate 忘记改任务状态，下游一直被阻塞；关停需要等当前工具调用结束；权限请求频繁打断。解决之道是“预授权常见操作”“在看板上可视化阻塞”“让 Lead 定时巡检”，把琐碎摩擦变成流程上的可见项，而不是心情上的负担。

不要指望 AI 自觉保证质量

如果没有验证，Agent 很容易把“差不多”当“完成”。把 TaskCompleted Hook 和测试门一起上，关键任务必须有人审。这是团队的底线，也是产品的底线。

什么时候用，什么时候不用：两个落地的判断

• 适合用：多角度并行审查、独立模块并行开发、跨层协作（前后端/测试）、竞争性假设验证。
• 不适合用：强依赖的串行任务、同一文件的多处修改、日常小修小补、预算紧张场景。

给你两个实操判断：

• 文件集合重叠度低吗？低于三成，适合并行；
• 同步点数量多吗？越多越像串行，越少越能并行。

第一次尝试，建议从不改文件的任务入手，比如多维度审一个 PR 或并行调研一个技术方案。等体会到“并行的价值”，再把它引入开发场景。

产品落地建议：把规则写进“团队宪法”

• 让 CLAUDE.md 承担“团队宪法”：角色、所有权、完成定义、沟通模板、预算边界；
• 把 Hooks 接到你的 CI：测试门、lint 门、覆盖率门，完成时自动验收；
• 建立观测面板：任务状态、阻塞点、消息流量、token 预算，让团队状态可视；
• 从一个小型试点开始，明确成功指标（交付速度、缺陷率、审查覆盖度），再扩面。

结语：在软件里复制组织设计

Agent Team 把真实团队的协作经验——消息系统、任务依赖、所有权、审批与关停——搬进了 AI 编程。它并不神奇，真正让它有效的是那些朴素而坚实的管理动作：边界、沟通、质量、预算。当我们把它当“团队”而非“助手”，它会给项目带来可衡量的推进速度和更稳定的结果。

我相信这会成为一条新的产品范式，其他大厂也会很快跟进。但别忘了，它仍在早期：文件冲突、会话恢复、token 消耗都需要你的流程兜底。把规则写进系统，把观测留在眼前，多 Agent 才会成为团队的助推器，而不是系统性的噪音。

延伸阅读：

• Claude Code Agent Team 官方文档
• Anthropic Engineering Blog - Building a C compiler
• Hacker News 讨论帖
• kieranklaassen 的 Swarm 编排 SKILL

如果你也在探索 AI 工具与 Agent 协作，欢迎持续交流。我会把更多一线实践与复盘写成系列，帮你把“并行的潜力”变成“稳定的产出”。