发布了什么，以及它实际传递了什么
跨会话消息传递需要 Claude Code v2.1.224 或更高版本，并在 macOS 和 Linux（包括 WSL 2 内的 Linux）上运行——原生 Windows 不提供此功能。当会话满足要求时，根据文档，“消息传递功能已开启，无需启用任何设置”。
该功能由两个工具驱动：用于发现 Claude 可以访问哪些智能体的 ListAgents，以及用于按名称向其中一个智能体发送消息的 SendMessage。你不需要调用其中任何一个——“Claude 会通过 ListAgents 发现目标，并通过 SendMessage 发送，因此你无需自己调用这两个工具。”你可以输入类似这样的提示词：“询问在我另一个终端中运行的会话，迁移是否已完成，” 然后 Claude 会撰写实际的消息。
收件箱中收到的消息如下所示，这是文档本身的示例：
`` 架构迁移已完成：新列为 tenant_id，现在可以安全地变基（rebase）到 main。 ``
这就是整个功能的形态，它确实非常有用。当一个会话做出的更改破坏了另一个会话正在构建的内容时，Claude 可以在你注意到之前警告该会话。当一个会话解决了一个阻碍另一个会话的问题时，答案就会传递过去。文档中记录的用例包括移交发现、协调并行工作树（worktrees）、获取长期运行工作的状态以及跨机器回复。
准确了解这些限制是非常值得的，因为它们定义了你仍然需要自己解决的问题：
- 仅限文本。 “限制”部分指出“仅限纯文本”。关键的一句话是：“消息是 Claude 写入另一个 Claude 的一段文本，绝非对话历史或文件。要移动整个对话或其上下文，请改为恢复会话。” 接收会话“仅获取该文本，绝不会获取发送者的对话历史或文件”。
- 跨机器仅限回复。 同一台机器上的消息通过每个会话的套接字（socket）传输，绝不通过 Anthropic 服务器。发送到你在其他机器上或 Web 上的会话的消息会通过 Remote Control 经由 Anthropic 服务器传输——在此情况下，Claude “只能回复，无法发起对话”。
- 发现基于文件系统。 每个会话都会在磁盘上的文件中注册自己，并在那里绑定一个收件箱套接字，因此只有当两个会话能够看到相同的文件时，它们才能互相访问。容器内的会话和宿主机上的会话无法互相访问；同一容器内的两个会话则可以。
- 不保证送达。 每条消息都会根据接收会话的入站控制进行检查，最终状态为已送达（Delivered）、已暂存（Held）或已拒绝（Refused），这受
crossSessionInbound（accept/hold/refuse）控制。暂存的消息会打开一个会过期的批准对话框——dialogExpiry默认为 5 分钟——且 Claude Code 最多暂存 100 条消息，超过该限制时会丢弃最旧的消息，每个会话等待读取的已接受消息上限为 50 条。 - 消息没有权限。 它“无法批准任何事情”，也无法更改配置——Claude 收到指令，绝不因为另一个会话的要求而更改权限设置、
CLAUDE.md或其他配置——文本中的/compact“作为纯文本送达”且绝不会被执行，接收端仍会触发权限提示。 - 一旦送达，就会产生费用。 已送达的消息“会计入使用量，就像你输入的提示词一样”。
这些都不是抱怨。这是一个边界清晰的协调通道，而且这些边界是刻意设计的——一条能够批准权限或重写 CLAUDE.md 的消息将是一个安全问题，而不是一个功能。
为什么会话仍然不共享上下文
传递消息不等于共享记忆
这两者之间的区别至关重要。消息是单个 Claude 在某一时刻对某事的总结，一次性传递给另一个会话。而共享记忆意味着多个会话从同一个持久记录中读取数据——只需写入一次，即可供每个会话使用，包括那些尚未创建的会话。
消息传递为你提供了前者。这就像在办公室里大喊大叫与在共享文档中写作的区别。两者都很有用，但只有后者到了明天依然存在。
消息是总结，而总结刻意是有损的
Claude 会自己撰写消息——文档指出，即使是相同的提示词，“Claude 发送的内容也会有所不同”。对于协调性的呼叫（ping）来说，这是正确的设计，但对于知识传递来说则是错误的：你原本需要的注意事项恰恰是被压缩掉的内容，而且事后没有记录表明丢弃了什么。
同样的设计模式也出现在下一级的子智能体（subagents）中，每个子智能体“在自己的上下文窗口中运行”并“仅返回总结”。总结是 Claude Code 在整个过程中保护上下文预算的方式。这也是为什么没有任何东西能够累积的原因。
会话结束后什么都不会留下
关闭所有三个终端，它们之间传递的每条消息都会随着保存它们的对话一起消失。下周的会话将完全像以前一样从你的文件开始——这就是为什么无论上周四你的会话之间交流得多么顺畅，Claude Code 在开始每个新会话时仍然没有你的项目上下文。
三个容易被混淆为一个的功能
文档非常仔细地将这些功能区分开来，而使用错误的功能是人们最终感到失望的最常见原因：
- 恢复会话（Resume a session）——在其他地方继续某一个对话，或与新会话共享其上下文。这是文档中记录的移动上下文的方法，它移动的是单个对话的上下文。
- 跨会话消息传递（Cross-session messaging）——由你启动和引导的独立会话，通过传递文本进行交流。
- 智能体团队（Agent teams）——由 Claude 生成并监督的协调会话团队，其结构化协议消息仅保留在团队内部。
此外，还有用于监视多个会话的智能体视图（agent view）、用于从另一台设备进行引导的 Remote Control，以及用于将外部事件（如 CI 结果）推送到会话中的通道（channels）。共有六种机制，但没有一种是用来保存项目知识的地方。
人们尝试过的方法
恢复会话而不是发送消息。 当你真正需要上下文时，这是正确的做法，也是文档引导你去做的事情。它让你继续进行一个对话，而不是让三个会话共享一个基础。
将所有内容放入 `CLAUDE.md`。 这是标准答案，也确实是长期规则的正确归宿，因为每个会话都会加载它。但这是按请求计费的，所以它必须保持简短；而且它保存的是你决定写下来的内容，而不是你昨天学到的知识。
在终端之间复制粘贴。 这正是消息传递旨在取代的操作，Anthropic 也是这样宣传的——“无需你在终端之间进行复制粘贴”。现在情况有所改善，但仍然是手动传递总结。
使用一个巨大的会话而不是多个会话。 通过重新引入压缩问题来避免协调问题：长会话会丢失其自身上下文的中间部分。
带有每个工作树注释的工作树（Worktrees）。 纪律严明且可行。但你现在正在维护 N 套互不了解的注释，这在文件形式上是同样的分歧问题。
将智能体团队用于一切。 当你希望一个受监督的团队专注于一个目标时，这是正确的；但作为通用的上下文共享机制，这是错误的——团队协议消息仅保留在团队内部，且团队会结束。
解决方案：为每个会话提供一个可供读取的统一存储库
将协调通道留给协调工作，并将知识放在所有会话都能读取的地方。
这是上述六个功能都没有覆盖的层级：一个比所有会话都长寿的存储库，任何会话都可以将发现写入其中，任何其他会话都可以读取——包括你在其他机器上、容器内、原生 Windows 上或完全不同的工具中的会话。它不是一条会被消耗掉的消息，也不是一个会不断增长直到加载成本高昂的文件。
MemoryLake 就是为此而生的——这是一个统一的记忆层，你的会话和智能体可以通过 MCP 或 API 进行读取，保存你工作中所产生的决策和文档。消息传递现在将架构更改告知会话 B；而存储库则是下周会话 D 能够了解该更改的原因。
这里有两个明确的界限。这并不能取代跨会话消息传递，也不应该取代——任务进行中关于更改刚刚破坏了某些内容的警告需要立即送达，这正是消息传递的用途。此外，共享存储库并不能保证会话一定会根据其读取的内容采取行动，那是模型行为。它所改变的是，知识存在于某个持久且可检索的地方，而不仅仅存在于对话内部。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中——请注意，来自另一个会话的消息被明确禁止更改你的配置，你的凭据也理应受到同样的保护。
步骤 2：上传你的第一批记忆
放入那些保存了你的会话不断重新发现的内容的文档、图像和文件：架构决策、架构注释、某人上周遇到的限制。尽可能上传源文件而不是总结——传递消息的全部问题就在于它已经是一个总结了。
步骤 3：连接你的 AI 和智能体
让 Claude、Codex、OpenClaw 和其他 AI 智能体通过 MCP 或 API 访问记忆。Claude Code 支持 MCP 服务器，因此每个会话都可以从其自身的配置中读取相同的存储库——包括消息传递无法触及的会话，例如原生 Windows 上或与宿主机隔离的容器内的会话。
这在实践中改变了什么
第一个区别是，发现不再只是一条消息，而是变成了一个事实。会话 A 发现供应商 API 在失败时返回 200；它不会去呼叫会话 B 并在两者关闭时丢失该信息，而是将其存入存储库中，未来的每个会话都将拥有它。
第二个区别是，消息传递无法桥接的机器和容器不再是问题。跨机器消息传递仅限回复，且容器隔离的会话无法看到彼此的套接字——但它们都可以访问 API。你的工作笔记本电脑和你的容器都读取相同的知识，这就是跨机器不丢失上下文的实际应用版本。
第三个区别是，消息变得更短、更好。当共享基础已经存在时，消息只需携带新内容——例如“现在可以安全地变基到 main”，而不是用一整段话重新阐述迁移是什么。
而且它独立于工具而存在。架构决策在 Codex 和 Cursor 中同样适用。如果保存在 Claude Code 会话之间的对话中，它只是一个 Claude Code 的产物；如果保存在存储库中，它就可以被任何支持 MCP 的智能体访问。
运行多个会话的最佳实践
为你的会话命名
会话会响应你使用 /rename 或 --name 标志设置的名称；如果没有设置，Claude Code 会根据工作目录的文件夹派生一个名称，例如 myapp-3f。两个会话最终可能会有相同的名称，在 /list-agents 中通过工作目录进行区分。根据它们正在做的事情为它们命名——例如 migration、payments-api——可以使 Claude 的寻址更加可靠，并使你以后能够看懂这些消息。
使用 /list-agents 进行诊断，而不是发送
在要求 Claude 发送消息之前，你永远不需要运行它，因为 Claude 会自己找到目标。它发挥作用的地方在于故障排除：如果无法识别 /list-agents，则说明该会话不具备该功能——请先检查 claude --version 第一。如果它起作用但消息未送达，则可能适用更具体的限制：权限拒绝规则、接收者的入站控制，或者超出本机的会话的仅限回复限制。
为无人值守的工作程序谨慎决定入站策略
运行 claude -p 的工作程序会绑定一个收件箱套接字并出现在列表中，但它无法显示批准对话框，因此暂存的消息会一直保持暂存状态。如果你希望无头（headless）工作程序接受消息，请在其 --settings 中将 crossSessionInbound 设置为 accept——不要在你的用户设置中设置，否则这将适用于你运行的每个会话。
将决策发送到存储库，将状态发送到会话
一个很好的经验法则：如果它仅在当下成立（“测试运行已完成”、“我正在变基”），请通过消息发送。如果它到下个月仍然成立（“由于共享架构约束，我们选择了 tenant_id 而不是 org_id”），请将其写入存储库。状态会过期，但决策不应该。
在不可用时不要依赖消息传递
除了操作系统要求外，跨会话消息传递在 Amazon Bedrock、AWS 上的 Claude 平台、Google Cloud 的 Agent Platform 或 Microsoft Foundry 上均不可用，并且当 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK 或 DISABLE_GROWTHBOOK 等环境变量禁用了它所依赖的功能标志（feature-flag）评估时，该功能也会保持关闭状态。如果你的设置遇到了其中任何一种情况，共享存储库就是你拥有的唯一通道。
结论
Claude Code 会话之间互相发送消息是一项真正的改进，值得你调整工作流程来适应它——它消除了在终端之间复制粘贴的操作，完美适用于一个会话需要在任务中途告知另一个会话某些内容的情况。只需阅读文档本身的表述：消息是文本，“绝非对话历史或文件”，而移动对话的上下文意味着恢复会话。
因此，请根据通道的实际用途来使用它。协调工作通过消息传递进行，单个对话通过恢复会话来移动，受监督的组使用智能体团队——而下个月仍然成立的知识则放入每个会话都会读取的存储库中。这最后一层是 Claude Code 没有提供的，而它正是让三个终端感觉像是在同一个项目下工作的关键所在。