Anthropic 为协调 Claude Code Agents 新增跨会话消息功能

Anthropic 为 Claude Code 新增了跨会话消息功能，首次让原本彼此隔离的编程 agents 有机会成为协作者。anthropic techmeme 的报道之所以重要，是因为消息功能改变了开发者在多个终端之间分配工作的方式。同时，它也带来了一个更棘手的问题：agents 应在何时信任、质疑或等待彼此。

该功能允许一个 Claude Code 会话向另一个指定名称的会话发送文本。这些文本可包含发现、问题、状态更新或求助请求。接收会话会在工作过程中显示消息，从而减少开发者在终端之间复制上下文的需要。

此次更新并未打造一个完全托管的工程团队。它为 agents 提供了通信能力，但开发者仍需负责任务边界、文件所有权、权限和最终审查。这一区别使 Anthropic 的协调模式与较早的做法形成对照：此前通常是在直接人工监督下运行多个相互独立的 agents。

Anthropic Techmeme 报道中有哪些变化

Claude Code 会话现在拥有一个原生渠道，可在工作时交换简洁、与任务相关的信息。

根据围绕此次发布的文档和用户报告，该功能出现在 Claude Code 2.1.224 版本中。它可用于 macOS 和 Linux，包括通过 WSL 2 运行的 Linux 环境。发布时未列出原生 Windows 支持。

一个会话可以发现符合条件的同伴，并通过名称向另一个会话发送消息。随后，它可以发送包含摘要、问题、请求或更新的消息。接收 agent 会看到一张标明发送者的卡片，并可通过同一渠道回复。

这比共享完整对话更有限。跨会话消息传递的是为接收者撰写的文本，而不是发送者的完整记录、打开的文件、工具权限或隐藏推理。这一限制在保持每个会话上下文独立的同时，为选定信息提供了受控传递路径。

据报道，同一台计算机上的本地消息通过本地 socket 传输，也就是同一台设备上进程之间的通信通道。跨机器回复可使用 Anthropic 的中继基础设施，但需遵守 messaging documentation 中说明的可用性和提供商条件。

该功能还限制了接收消息能够执行的操作。一条消息不能替另一个 agent 批准权限请求。它不能悄然更改接收者的配置。看似 slash command 的文本会作为文本送达，而不会自动执行。

这些边界很重要，因为 agent 消息可能包含指令。若将每条传入消息都视为可执行授权，一个出错或遭入侵的会话就可能扩大其错误的影响。Claude Code 反而将通信视为信息，接收会话必须在现有控制措施内自行解读。

最直接的使用场景是将项目拆分到并行终端中。一个会话可能修改应用程序编程接口，另一个则构建使用该接口的界面。当响应字段发生变化时，后端 agent 可通知前端 agent，而无需等待开发者注意到并转达更新。

另一个会话可能在调查失败的测试，而独立的 agent 负责实现某项功能。一旦调查确定原因，它就可以向构建者发送简短说明。构建者无需导入调查者的全部工作历史，即可获得有用结论。

Anthropic 早已支持并行开展 Claude Code 工作。其较早发布的桌面版描述了可同时运行多个本地和远程会话，例如一个修复 bug，另一个研究 GitHub。新功能将这些工作通道连接起来，而不再让用户成为它们唯一的沟通桥梁。

这正是其中的张力所在。发送文本是一项有限的技术能力。允许自主编程会话彼此作出反应，则改变了围绕它的运行模式。

为什么 Agent 协调现在如此重要

随着开发者在人工检查间隔期间交给每个 Claude Code 会话更多工作，消息功能的价值也在增长。

Anthropic 在 2026 年 6 月的分析中研究了约 235,000 人进行的约 400,000 个 Claude Code 会话。该公司发现，用户作出了约 70% 的规划决策，而 Claude 作出了约 80% 的执行决策。

在该数据集中，一个典型提示会触发约 10 次 agent 操作。有些提示会导致超过 100 次操作。根据 usage research，每一轮平均产生约 2,400 个词的输出。

这些发现说明了为何人工协调会变得昂贵。监督一次简短交互的开发者可以在脑中保留状态。但当开发者监督多个 agents，且每个 agent 都要执行许多操作时，开发者就会成为问题、完成情况、阻碍和变化假设的路由器。

此前，并行会话提高了吞吐量，却没有消除这一路由负担。开发者可以分配不同工作，但通常仍需监控每个终端，也必须将一个会话的发现复制并粘贴到另一个会话中。

跨会话消息自动化了其中一部分交接。完成依赖项的 agent 可以立即提醒另一个 agent。因接口不明确而受阻的会话可以询问负责该接口的会话，而不必将每个问题都上报给用户。

这一变化给那些将每段对话视为自包含工作区的编程助手带来压力。模型质量依然重要，但 agent 协调正成为另一项产品维度。编程工具将越来越需要跨任务、代码仓库、机器和时间管理工作。

这种压力也波及编排框架。这些系统通常创建一个主导 agent，由其向下属 agents 分配工作并收集结果。Anthropic 的新渠道支持一种更扁平的模式：独立启动的会话以同伴身份进行通信。

同伴模式提供了灵活性。开发者可以按需创建会话，并赋予每个会话聚焦的职责。会话无需单一控制器转发每次更新。

然而，这种灵活性将组织决策转移给开发者。仍然需要有人决定哪个 agent 负责某项任务、哪些消息值得采取行动，以及如何解决相互冲突的结果。消息功能降低了通信成本，但没有提供完整的管理层。

Anthropic 自身的产品材料称，工程师已经在一个代码库中运行多个 Claude Code 会话。该公司举例称，Rakuten 在工程师将任务分配至并行会话的情况下，将平均功能交付周期从 24 个工作日缩短至 5 天。这些数据是公司挑选的客户案例，并非独立基准测试。

更广泛的证据仍指向更长、更加自主的编程工作流。Anthropic 发现，专注于运行软件的会话占比从 2025 年 10 月的 14% 上升到 2026 年 4 月的 21%。涉及写作和数据分析的工作也在同期增长。

随着 agent 任务扩展，一个会话产生的信息更可能影响另一个会话。原生消息功能为这些信息提供了直接通道。该功能出现之际，协调负担已变得足够明显，足以证明其必要性。

Claude Code 消息功能取代的是人工转达，而非人工控制

Anthropic 正将开发者从日常交接中解放出来，同时保留其对架构、权限和验收的责任。

设想一名开发者将身份验证变更拆分给三个会话。第一个更新服务器端点，第二个修改客户端界面，第三个审查测试和文档。

服务器会话发现刷新 token 现在使用不同的响应字段。它将新字段名称发送给客户端会话，并要求测试会话更新其 fixtures。每个接收者都能吸收这些信息，而无需开发者重复两次。

这一工作流节省了注意力，但并未消除判断。消息描述的可能是尚未提交的实验，而不是最终接口。若接收者将这一更新视为既定事实，就可能基于永远不会发布的代码进行构建。

更安全的工作流会赋予每个会话明确角色。服务器 agent 负责端点文件，客户端 agent 负责界面组件。测试 agent 可以报告失败，但未经批准不得重写共享契约。

Git worktrees 可以强化这些边界。worktree 为每个会话提供一个独立检出的工作目录，同时关联同一代码仓库。Agents 可以独立修改，然后通过常规版本控制审查将其合并。

社区对这次发布的反应反复回到这一点。一些经验丰富的用户表示，他们早已通过共享文件、终端工具、自定义邮箱或 Model Context Protocol 服务器连接 agents。他们欢迎原生消息功能，但认为所有权和合并冲突才是更棘手的问题。

一名讨论参与者概括了实际限制：当 agents 拥有独立 worktrees 后，交接并非主要瓶颈。防止两个 agents 修改同一批文件更重要。另一名参与者描述了如何在 agent 开始编辑共享代码之前，使用小型 claim 文件标示临时所有权。

这些都是轶事报告，但揭示了真实的系统问题。两个能力合格的 agents 都可能各自选择合理的修改，但在合并时发生冲突。只有当 agents 共享准确假设并遵循可执行的协调政策时，通信才有帮助。

因此，这次发布的影响比聊天功能更深远，却又不如一个 agent 团队完整。它传递上下文，却不能保证一致性；它告诉另一名工作者发生了什么，却无法证明消息正确。

开发者可以通过要求消息提供证据来降低这一风险。当这些细节重要时，agent 应发送 commit 标识符、测试结果、文件路径或接口定义。“后端已完成”所提供的保障，不如一条注明已完成变更及其验证状态的消息。

同样的纪律也适用于提问。向另一名 agent 求助的会话应说明其决策边界，并区分信息请求与授权修改共享代码。

这类似于人类工程团队之间的沟通。消息可以减少等待，但不能取代稳定的接口、所有权规则、代码审查或测试。Claude Code 现在支持了对话层。周边工程流程仍决定这类对话是否会产出可靠的软件。

对于需要跨多种工具追踪决策的团队，一个可搜索的技术知识库可以在临时 agent 对话结束后保留最终结论。会话消息有助于即时协调，而持久化文档则记录已被接受的状态。

原生消息功能挑战自定义 Agent 编排

Anthropic 的主要优势不在于发明了代理通信，而在于将其设为广泛使用的编程环境中的默认组成部分。

在此次发布之前，开发者就已构建过跨会话通信机制。有些人使用共享的 Markdown 或 JSON 文件作为收件箱；另一些人则依赖终端复用器、本地数据库、Shell 钩子或 MCP 服务器。

例如，Claude Relay 在 Anthropic 推出原生通道之前，就通过中心进程和本地套接字连接本地 Claude Code 会话。其设计允许一个会话列出其他会话、向另一个会话提问、广播请求，并以通知形式接收回复。

其他社区项目连接的并不只是 Claude 会话，而是不同的编程助手。这种方式让 Claude 代理可以请基于 Codex 或 Gemini 的代理进行审查。跨模型通信能够带来有价值的分歧，尤其是在一个模型发现另一个模型遗漏的错误时。

Anthropic 的原生功能目前具备不同的优势：它为受支持的 Claude Code 用户免去了安装和配置工作。此前需要插件才能实现的能力，如今可以成为普通多终端会话的一部分。

默认设置会塑造采用率。大多数开发者不会为了避免偶尔的复制粘贴工作而专门搭建消息总线。但当同样的能力本就存在、无需单独服务，并且自然地出现在编程工具中时，他们可能会使用它。

这让自定义编排处于一个颇有意思的位置。当 Claude Code 内置对等消息功能后，简单的中继产品会失去一部分差异化优势。更高级的系统则可以在传输层之上展开竞争，例如提供调度、审计日志、资源锁、预算控制和跨模型支持。

OpenAI 的 Codex 环境同样强调并行代理工作和结构化委派。其他编程工具则采用后台代理、任务队列、隔离环境或管理者—工作者模式。竞争焦点正从工具能否运行多个代理，转向这些代理能够以多安全的方式进行协调。

Anthropic 更扁平的对等模型不同于严格的层级结构。主代理系统将任务分配与综合处理集中起来；对等消息则让专门化会话直接通信，既可减少延迟，也能保留每个代理聚焦的上下文。

没有任何一种方式适用于所有工作流。集中协调能提供明确的权责关系与汇总状态；直接的对等通信则能减轻主代理的上下文负担，避免每个技术问题都必须通过单一流程转发。

这种取舍类似于分布式软件设计。集中式系统在协调者成为瓶颈之前更容易推理；分布式系统能够扩展通信路径，却会引入一致性、顺序和冲突问题。

Claude Code 的跨会话消息功能并未消除这些问题，而是将其带入日常开发者工具中。过去只需监督一个代理的团队，如今需要采用类似于并发人类协作的规范。

该功能也提升了精简上下文的重要性。发送完整记录会消耗注意力和 token，同时暴露无关细节。只发送摘要固然高效，但摘要可能遗漏关键约束。

因此，强大的编排层应将消息视为带有来源信息的主张。它应记录谁发送了消息、消息何时到达、涉及何项任务，以及有哪些证据支撑。Anthropic 带标签的消息卡片提供了部分上下文，但对于高风险代码库，团队仍需要持久的审计实践。

竞争空间依然很大。能够将通信与可强制执行的任务归属、冲突检测和可见的决策轨迹结合起来的供应商，能够提供的不只是消息功能。Anthropic 建立了一个有用的基线，而不是一套完整的代理团队操作系统。

真正的风险，是围绕错误信息进行自信协调

能够快速通信的代理，可能会比孤立代理采取行动更快地传播错误假设。

假设某个会话错误地判定数据库迁移已经完成。它向两个依赖该结果的会话发送消息，后者随即根据假定的架构更新应用代码和测试。最初的错误如今已影响三个工作流。

问题不在于恶意通信，而在于缺乏验证的自信。语言模型可能会把不完整的结果总结得仿佛已经尘埃落定，尤其是当一项长任务同时包含部分成功和未解决的失败时。

跨会话消息为接收代理创建了另一个输入通道。接收者必须判断发送者的表述究竟是观察结果、假设、请求，还是具有约束力的项目决策。自然语言不会强制区分这些类别。

权限边界降低了一类风险。据报道，一条消息不能授予另一个会话权限，也不能改变其配置。这能防止代理将通信通道用作直接绕过授权的手段。

但权限控制并不能保证逻辑安全。获授权的代理仍可能因相信不准确的信息而修改错误的实现。测试和人工审查依然至关重要，因为许多协调失败发生在被允许执行的操作之内。

Anthropic 于 2026 年 4 月发布的 Claude Code 事后分析提供了相关警示。该公司将质量投诉追溯到三项独立变更，其中包括一个会反复丢弃早期推理的空闲会话错误。该错误使 Claude 看起来健忘，并在 Anthropic 修复前导致异常的工具选择。

该公司表示，这些变更通过了人工审查、自动审查、单元测试、端到端测试和内部使用。这篇质量事后分析说明，故障如何能跨越多重保障，直到在真实工作流中才变得明显。

如果受影响的会话将错误结论发送给正常的对等会话，消息功能可能会放大类似故障。反过来，当另一个会话质疑该结论时，对等审查也有助于发现问题。结果取决于工作流如何处理分歧。

开发者应避免在没有冲突策略的情况下分配重叠的写入权限。独立 worktree、明确的文件归属和狭窄的任务范围可减少意外干扰。共享架构和配置文件应接受更严格的审查，因为多项任务都可能依赖于它们。

消息也应将状态与证据分开。状态更新可以说明一项任务似乎已完成；证据则应指出相关测试、diff、构件或命令结果。接收会话随后可以判断该主张是否满足其依赖要求。

安全团队应考虑跨代理的提示注入。检查不可信代码库内容的会话，可能会遇到旨在影响其行为的文本。如果它将该指令总结给另一个会话，有害指引就可能在未共享原始文件的情况下跨越边界。

Claude Code 的权限模型提供了一定阻力，但团队不应假设本地消息天然可信。发送者身份只能说明是哪一个会话生成了文本，并不能证明该会话的来源安全，或其结论准确。

随着消息触发下游工作，可审计性变得更加重要。团队需要知道代理为何修改某个文件、哪条消息影响了这一决定，以及人类是否批准了最终合并。缺少这条轨迹后，调试代理协调故障可能比调试单个孤立会话更困难。

采用情况也带来另一项不确定性。只有当开发者持续为会话命名、明确职责，并指示代理在合适时机通信时，这项功能才有价值。消息过多会变成噪声，消息过少则会保留原本的交接问题。

原生 Windows 支持在发布时也较为有限，尽管 WSL 2 为部分 Windows 用户提供了途径。在混合环境中工作的团队，在围绕该功能设计关键工作流之前，需要确认哪些会话能够参与。

因此，Anthropic 对传输问题的解决比对治理问题更为明确。该通道能够传递信息，但可靠协作仍取决于验证、归属、安全边界和可见的人类控制。

Claude Code 跨会话消息功能之后值得关注的事项

下一项考验在于，Anthropic 能否将消息功能转化为可靠协调，同时不向开发者隐藏会造成重大影响的决策。

第一个信号是产品向 macOS 和 Linux 之外扩展。原生 Windows 支持将使该功能覆盖更多企业开发环境。对更多 Claude 界面的支持，也将表明 Anthropic 将消息功能视为 Claude Code 实用功能，还是通用协作层。

平台扩展会加强构建共同代理网络的理由；持续碎片化则会让消息功能仍受限于特定本地设置。团队应关注 Anthropic 的发行说明和设置文档，了解操作系统与提供商支持的变化。

第二个信号是增加文本之外的协调原语。共享任务状态、明确归属、依赖跟踪、确认机制和冲突警告，能够解决社区用户已经指出的问题。

一个有用的系统应能区分“我发现了这一点”和“该接口已获批准”。它还应让未解决的分歧对开发者可见。如果 Anthropic 加入这些控制机制，跨会话消息将成为结构化代理团队的基础。

如果开发止步于自由格式文本，自定义编排工具仍将保留重要角色。它们可以在多个模型之间提供任务队列、锁、预算、审计历史和策略。消息功能仍将是便捷的基础设施，而非核心工作流。

第三个信号来自真实项目的证据。Anthropic 的产品页面已经描述了运行并行 Claude Code 会话的组织，并报告交付时间大幅缩短。跨会话消息需要单独评估，因为增加通信既可能减少等待，也可能带来新的协调开销。

有用的衡量指标包括集成失败、重复编辑、合并冲突、人工干预，以及用于协调代理输出的时间。仅看任务完成速度并不够。一个更快却产生更多隐藏不一致性的工作流，并不代表明确改进。

Anthropic 的研究发现，人类保留了大部分规划决策，而 Claude 处理了大部分执行决策。跨会话消息将检验这种平衡是否仍能维持。如果代理开始彼此协商计划，即使每一项单独行动仍获许可，人类对规划的控制也可能被削弱。

这并不意味着代理间规划不可取，而是意味着可见性很重要。开发者需要看到重要决策、分歧和假设变化的摘要，而不是被每一次日常交流淹没。

竞争对手的反应将提供另一条线索。如果编程代理供应商加入兼容的通信机制，跨模型消息可能成为标准层。如果每家供应商都建立封闭网络，团队将依赖第三方桥接工具来协调混合代理集群。

这条 Anthropic Techmeme 标题捕捉到的是一次小型界面变更背后更大的含义。开发者不再只能监督几个沉默的代理，而是能够监督会交换发现并根据彼此工作调整行动的代理。

这种能力值得关注，但不应不加判断地信任。最理想的早期部署会将消息功能用于范围明确的进度更新、问题沟通和基于证据的交接，同时明确文件归属，并为重要的集成决策保留人工审批。

测试这一功能的团队应从边界清晰的项目开始。可将一个会话分配给后端模块，另一个会话负责独立的客户端层。要求两个代理在进行修改前报告测试情况，并识别所有共享文件。

随后，应衡量该通道是否真正减少了人工介入。统计代理直接解决的问题、它们引发的冲突，以及仍需人工决策的事项。这些证据将揭示：协调会话究竟是在改善工作流程，还是仅仅转移了其复杂性。

跨会话消息传递并不是一个自主的工程组织。它是一种使其成为可能的通信原语。开发者现在面临的是一个实际问题：哪些交接可以安全地不再依赖人工中转，哪些决策仍需要由人居于核心位置？