为什么智能体团队不共享上下文
首先，坦白地说：这是实验性功能，且默认关闭
首先需要说明的是——除非你主动开启，否则智能体团队功能是禁用的。文档中带有警告：它们是“实验性的且默认禁用”，需要通过在设置或环境中设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 来启用，“如果没有该变量，会话启动时不会建立团队，不会写入团队目录，且 Claude 不会生成或推荐团队成员。”
所以这里并没有什么违背承诺的地方。这是一个处于早期阶段的功能，有着明确记录的局限性，而上下文边界是一个设计决策，而非疏忽。
共享的是协作，而非对话
根据架构部分的介绍，看看一个团队是由什么组成的：一个团队主智能体（lead）、团队成员（teammates）、一个共享的任务列表和一个邮箱。邮箱是位于 ~/.claude/teams/{team-name}/inboxes/{agent-name}.json 的 JSON 文件。任务列表则保存在 ~/.claude/tasks/{team-name}/ 下。
这两样东西——任务和消息——就是全部的共享基础。团队成员可以查看任务状态、认领可用工作，并通过名称给彼此发送消息。但它们看不到彼此的推理过程，也看不到你的。
将其与子智能体（subagents）进行对比（文档中也是直接对比的）：子智能体拥有自己的上下文窗口，并将结果报告给调用者；团队成员拥有自己的上下文窗口，并且是“完全独立的”，它们彼此发送消息，而不是向上汇报。这两种模型都隔离了上下文。团队模式只是增加了一个通道。
启动提示词是唯一的简报
这是实际产生的结果，值得将其作为一条规则：你希望团队成员知道的任何信息，都必须写在启动提示词中、写在它加载的文件中，或者写在稍后有人发给它的消息中。
文档本身的最佳实践也是这么说的——团队成员会自动加载项目上下文，“但它们不会继承主智能体的对话历史”，因此你应该“在启动提示词中包含特定于任务的细节”。其示例启动提示词长达数句，指定了模块、重点领域、Token 存储方法和输出格式。
注意在实践中是谁撰写了这份简报：是主智能体，基于它对你们对话的压缩理解。每个团队成员的初始知识，都是由另一个模型对你们进行的讨论所做的总结，并经过了主智能体认为相关的任何内容的过滤。
团队成员获取的是项目上下文，而不是你的上下文
这种划分很重要。团队成员会从其工作目录中读取 CLAUDE.md——文档证实“CLAUDE.md 正常工作”——外加来自你的项目和用户设置的 MCP 服务器和技能。
因此，已提交的、文件形式的知识得以传播。其他一切则不然。你在聊天中提到的限制、你一小时前给主智能体的纠正、你在打开终端前的会议上做出的决定：这些都不在文件里，所以都无法触达团队。
如果你将子智能体定义用作团队成员类型，还有一个相关的陷阱：文档指出，当该定义作为团队成员运行时，其 skills 和 mcpServers 的 frontmatter 字段“不会被应用”，因为团队成员会像常规会话一样，从项目和用户设置中加载技能和 MCP 服务器。
团队成员学到的东西会随着团队的结束而消亡
团队是会话作用域的。团队名称派生自会话——session- 加上会话 ID 的前八个字符——并且“当会话结束时，团队配置目录会被删除”。任务列表目录保存在本地且绝不会上传，其保留期由你用于转录文本的相同 cleanupPeriodDays 决定。
因此，任务保留了下来，而团队没有。没有任何积累：今天早上了解了你的错误处理约定的审查员（reviewer）团队成员，今天下午就不复存在了，明天的审查员又要从相同的启动提示词开始。对于进行中的团队成员，也没有会话恢复功能——/resume 和 /rewind 无法恢复它们，主智能体“可能会尝试向不再存在的团队成员发送消息”。
消息是文本，且刻意设计为低信任度
你可能会认为邮箱可以承载知识。它可以承载句子，但它的设计初衷是对这些句子保持警惕。
当一个智能体给另一个智能体发送消息时，“Claude Code 会告诉接收智能体该消息来自另一个 Claude 会话，而不是来自你。”团队成员“无法代表你批准权限提示或提供同意”，而被拒绝执行某项操作的团队成员“无法将其转发给另一个团队成员以绕过检查”。在自动模式下，分类器会将转发的批准声明视为不可信输入，并在投递前审查每条消息，甚至会直接拦截某些消息。
这是正确的安全设计——这意味着邮箱是一个协作通道，而不是知识总线。同样值得了解的实际形式是：要触达所有人，你需要向每个接收者发送一条消息。
而且重新建立需要花费真金白银
文档明确指出，智能体团队“使用的 Token 数量明显多于单个会话”，并随着活跃团队成员的数量而增加，对于大多数工作流，建议使用 3-5 个成员。这些 Token 的部分花费在于每个团队成员独立读取相同的文件以重建相同的理解——这是用昂贵的方式去解决一个本可以通过共享存储一次性解决的问题。
人们尝试过的方法
编写庞大的启动提示词。 这是文档中给出的答案，在一定程度上有效。但这样一来，你必须在每个会话中为每个团队成员手动撰写简报，而简报又是对你对话的压缩——因此，在团队成员需要做出判断时，限制背后的原因往往恰好被遗漏了。
把所有内容都放进 `CLAUDE.md`。 直觉是正确的，因为团队成员确实会读取它。限制在于大小：指导原则是保持指令文件简短，因为长文件会消耗上下文，且执行的一致性会降低。一个装满了四个团队成员所需的所有内容的 CLAUDE.md，最终会变成没人遵守的文件。
让主智能体转发发现。 可行，但这会让主智能体成为瓶颈，消耗 Token 去重写一个团队成员学到的东西以便另一个成员阅读。而且和启动提示词一样，这种方式也会造成信息损耗。
自己阅读每个团队成员的转录文本。 你可以这样做——在面板中选择一个团队成员并按回车键，即可直接查看并向其发送消息。这对于引导方向很有用，但作为一种机制则毫无用处：你变成了集成层。
改用子智能体。 有时是正确的。子智能体成本更低且会进行汇报，文档建议在工作节点不需要彼此交流时使用它们。但这同样无法解决知识共享问题——子智能体具有相同的隔离性，只是少了邮箱功能。
在仓库中保留一个临时草稿文件。 这是最有效的权宜之计，也是正确答案的手工版本：一个存在于任何单个智能体上下文之外、但所有智能体都可以读写的地方。值得注意的是，这也是人们独立摸索后殊途同归的做法。
解决方案：为团队提供一个可读写的统一存储
保持隔离。独立的上下文窗口是五个智能体团队能够并行工作而不会被彼此的输出淹没的原因，而低信任度的消息传递规则正在保护你。
需要解决的是，目前的“隔离上下文”意味着“隔离知识”。这两者是可以分离的。给团队一个位于所有上下文窗口之外的存储：主智能体将限制和决策写入其中，团队成员在开始工作时读取它，并将它们的发现写回，而第二天的下一个团队就可以从上一个团队学到的东西开始，而不是从全新的启动提示词开始。
MemoryLake 就是为此设计的记忆层——将决策、限制和源文档保存在一个存储中，每个团队成员、Codex 以及 ChatGPT 都可以通过 MCP 或 API 访问。任务列表协调工作；存储承载知识。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境或机密管理器中，而不是直接粘贴到会话中。
步骤 2：上传你的第一批记忆
放入你的团队成员不断重复探索的文档、图像和文件：架构决策及其原因、事故报告、API 契约、约定，以及你已经否决的方法列表。上传源文件而不是摘要——启动提示词已经是一个摘要了，而摘要这一层往往会丢失原因。
步骤 3：连接你的 AI 和智能体
让 Claude、Codex、OpenClaw 和其他 AI 智能体通过 MCP 或 API 访问记忆。团队成员会像常规会话一样，从你的项目和用户设置中加载 MCP 服务器，因此只需配置一次服务器，就能让每个团队成员拥有相同的存储——无需为每个成员单独设置，也不依赖于主智能体是否记得转发。
这在实践中带来了什么改变
第一个区别是启动提示词变得更短、更好。它不再将你的整个对话压缩成一份简报，而是说明该团队成员负责什么，并指向存储以获取其余内容。损耗更少，输入更少，且对每个团队成员都完全相同。
第二个区别是，发现能够从团队中幸存下来。当负责调试的团队成员得知重试端点不是幂等的，该信息就会存入存储中，明天的团队就能继承它。而现在，这个发现只存在于一个随着会话结束而被销毁的上下文窗口中。
第三个区别是，并行工作不再需要重复推导相同的上下文五次。每个团队成员读取检索到的限制，其成本远低于每个团队成员通过阅读代码库来推断它——考虑到文档本身警告过团队会消耗明显更多的 Token，这一点非常重要，对于在每个会话中重新阅读代码库的智能体来说更是如此。
而且它与 Claude Code 现有的功能相得益彰。CLAUDE.md 继续承载常规规则，自动记忆（auto memory）继续保留其本地笔记，任务列表继续进行协调。它们都不必成为记录系统——反正它们也做不到，因为自动记忆不会离开写入它的机器。
智能体团队的最佳实践
在生成任何人之前，先写下限制条件
如果你和主智能体刚刚花了 40 分钟得出结论，那么该结论需要存在于团队成员能够读取的某个地方。在生成成员前花 10 分钟写下来，可以避免三个团队成员各自独立地重新发明一个已被否决的设计。
让启动提示词关注职责，而非教育
说明该团队成员负责什么、“完成”的标准是什么，以及去哪里寻找上下文。试图在提示词中传授整个项目，只会让简报变成 600 字却依然遗漏了关键内容。
给团队成员起可预测的名字
主智能体在生成每个团队成员时会为其命名，任何团队成员都可以通过该名称向其他成员发送消息。在你的启动指令中告诉主智能体如何称呼它们，以便你稍后引用它们——并记住，要触达所有人，需要向每个接收者发送一条消息。
不要依赖消息来传递知识
邮箱是文本形式的，且传入的消息会被视为来自另一个 Claude 会话，而不是来自你，权限声明也明确不被信任。将消息用于协作——例如“我已完成 auth 模块”——而将存储用于事实。
做好团队无法在恢复（resume）后存活的准备
/resume 和 /rewind 无法恢复进行中的团队成员，主智能体可能会尝试向不再存在的团队成员发送消息。如果发生这种情况，告诉它生成新的成员——并确保新成员能够读取旧成员学到的东西。
从 3-5 个团队成员开始，并先进行只读工作
这是文档中推荐的做法，也符合失败模式的规律：协作开销和 Token 成本随着团队规模而增加，而并行实现容易引发文件冲突。审查、研究和竞争性假设调试是团队发挥其价值的地方。
不要将这些与强制执行混淆
指令文件和记忆是上下文，而不是强制配置。如果某些要求必须在每个团队成员的输出中得到满足——例如格式化、受保护的路径、禁止直接推送到 main 分支——请将其放入 hook 或 CI 中，这适用于所有成员，而不依赖于它们中的任何一个读取了什么。
结论
Claude Code 智能体团队不共享上下文，因为团队成员在设计上是独立的：每个成员都有自己的上下文窗口，每个成员都会加载项目上下文——CLAUDE.md、MCP 服务器、技能——并且“主智能体的对话历史不会继承”。它们共享的是一个任务列表和一个邮箱，而邮箱刻意将智能体之间的消息视为不可信，不适用于任何类似于授权的操作。团队本身是会话作用域的：当会话结束时，配置目录会被删除，进行中的团队成员无法在恢复后存活，且没有任何东西可以从一个团队积累到下一个团队。
因此，保持隔离并解决共享问题。将限制和决策写入每个团队成员都可以读写的存储中，让启动提示词关注职责而非教育，并让任务列表进行协作。这样，五个智能体就能基于对你项目的统一理解来工作，而不是基于对你对话的五种不同压缩。