Github 原文：shareAI-lab/learn-claude-code
问题
假如现在有个超级复杂的任务——重构整个后端”涉及认证模块、数据库层、API 路由、测试。
一个 Agent 在修 API 路由时，认证模块的细节已经不在上下文里了。上下文窗口就那么大，单个 Agent 的注意力覆盖不了所有模块。
我们之前介绍的子 Agent，也就是 Subagent 是临时工，叫来干一件事就走了。但有些任务需要能通信、能协作的队友，这就是 Agent teams。
解决方案
这一次的东西有些复杂，在之前的流程中增加了一大坨东西，别害怕，别着急，我们一点一点来介绍。其实整体来说，就是加了 3 个东西。
-
MessageBus：就是文件收件箱；
-
Spawn_teammate_thread：启动队友线程，就是说召唤一个队友帮忙；
-
Inbox 注入：接受队友的消息，并注入 history（这个就理解成上下文就行）。
你会发现其实就是个办公 OA 工具。你在做设计，突然发现有东西你做不完了，赶紧找来另一个设计师或者其他设计师，过来帮你干，然后大家在一个企业内，互相在 OA 里发消息沟通，消息还会同步汇报给你，然后你就在 jira 之类的其他工具里记录下一个一个的都被完成了。
和Subagent的区别
那么问题来了，这个东西和 subagent 相比，到底区别在哪里？简单来说可以分为以下 3 点：
| 子 Agent | 队友 Agent | |
|---|---|---|
| 生命周期 | 一次性，用完销毁 | 多轮（教学版限 10 轮，真实 CC 用 idle loop） |
| 通信 | 只回传结论 | 异步收件箱，随时通信 |
| 上下文 | 完全隔离 | 通过消息共享信息 |
-
Subagent 只会在当前的任务中创建，完成后就会销毁，就是一个项目制外包，用完就可以开了；但是队友 Agent 不会，他是你的随叫随到的合作伙伴，平时你们各干各的，需要的时候就呼叫过来一起干活；
-
之前我们介绍过，Subagent 只向主 Agent 传递结果，但是队友 Agent 之间相当于有一个 OA 系统，互相聊天。与之相对的，Subagent 之间也好还是和主 Agent 也好，上下文都是互相隔离的，但是队友 Agent 是可以共享信息的，就像一个团队知识库一样。
工作原理
MessageBus 收件箱
每个 Agent（包括 Lead 和队友）有一个 .jsonl 邮箱。发消息就是往对方的文件里 append 一行 JSON。读消息有点特殊，是“阅后即焚”式，即读文件 + 删除（消费式），也就是说 Agent 只会拿到一次这个消息，且其他的 Agent 也不会拿到这个消息。
除此之外，这里也做了防冲突设计proper-lockfile，当多个线程同时读或者写同一个 inbox 的时候，会触发只有一个能拿到消息，其他的都不会看到消息（因为被删除了）。
启动队友
不同于 Subagent，队友 Agent 有有自己的loop 循环，几乎和Lead 完全一样的能力配置，在执行完成后会把结果发送给 Lead 的收件箱 inbox，同时还会和 Lead 实时沟通。
除此之外，就跟其他 AI 操作一样，也有防止错误无限循环的兜底机制，在教学文章中设定的是最多循环 10 次，但是CC 使用了一个参数idle_notification，每轮都会发一次到 Lead 的 inbox 里，然后等到允许后再继续循环一次。
Lead 查看 inbox
既然大家都往 lead 的 inbox 里发信息，那么 lead 要什么时候看信息呢？
最简单的方式，也就是教学里面的方法就是lead 每次循环都检查一次，并做出反应，把结果放到外挂的 history 里面。不过 CC 做的更像真实的人和人之间的情况，CC 是让 Lead 每秒钟检查一次，如果一旦有更新，立即就调整，不需要等到下一次循环。
权限向上冒泡
这个和 Subagent 是一样的，就是当 Team agent 需要权限申请，不是由他来申请，而是由 Lead 来申请。
上下文压缩
需要注意的是，这个 Agent 也会存在上下文爆了的问题，所以需要压缩，但是他的角色是固定的，也就是说这是上下文的一部分，因此可能会被压缩没了，CC 这里的处理方式就是这部分信息不允许被压缩，因为他属于System prompt，CC 要求这部分被会被自动压缩。