OpenClaw 的 sessions_send 机制

在 OpenClaw 的体系里，智能体之间的精准通信（也就是 A2A，Agent to Agent）主要靠一套名为 sessions_* 的工具集来完成。这套工具的核心使命，是让分布在不同工作区甚至不同通讯平台上的智能体，能够像团队一样协同工作，全程无需用户手动介入。

其中，sessions_send 是整个工具集的“心脏”——它允许一个会话向另一个指定的活跃会话发送消息。它的功能说明和使用规范，统一存放在 Workspace 的 TOOLS.md 文件中，AI 启动时自动注入，相当于一份随时可查的“员工手册”。

不妨把整个工具集拆开来看：

• sessions_list：看在线名单，找合适的同事。
• sessions_history：翻阅旧档案，不用重复问老板。
• sessions_send：精准发消息，让同事去干活。
• sessions_spawn：开个新窗口，雇个临时工处理专事。

有了这四个工具，每个 AI Agent 就不再是信息孤岛，而是一个能互相通信的智能集群。

举个例子

把 OpenClaw 想象成一家“全能助理公司”。你作为老板，平时只跟总管助理（也就是主会话）对接，但公司后台其实还有很多专业助理在协同办公——财务助理、工作助理、采购助理，各司其职。而 sessions_* 工具集，就是这些助理之间沟通协作的一套流程制度。

来个具体的场景：你想买一台高性能笔记本，但不确定这个月的预算和奖金够不够。你对总管助理说：“我想买台 MacBook，算算我的奖金够不够付？”

总管助理接到任务后，第一步是搞清楚现在有哪些专业助理可以帮忙。它调用 sessions_list，发现 WhatsApp 上的财务助理和 Slack 上的工作助理都处于活跃状态。

接着，它需要分别获取信息：先问工作助理奖金情况，再翻财务助理的账本。它调用 sessions_send 给工作助理发消息：“请查一下老板这个月的绩效奖金是多少？”工作助理查到后，通过 Ping-Pong 确认机制回信：“奖金是 5000 元。”

随后，总管助理想知道你这个月已经花了多少钱。它没有重复问财务助理，而是调用 sessions_history 直接去翻看财务助理那边的对话转录日志——发现你前几天在 WhatsApp 上跟财务助理说“昨天买衣服花了 2000 元”。上下文直接从日志里获取，省去了重复沟通。

现在总管助理知道你的账户余额了，但还不知道电脑当前售价。为了不干扰现有的助理工作，它决定找个“实习生”去干这件杂事。于是调用 sessions_spawn 临时创建一个比价助理会话，这个新分身专门去网页上搜索最新价格，并汇报结果。任务完成后，临时会话自动关闭。

通过这四个工具的配合，在 Telegram 上的总管助理最后直接回复你：

“老板，我问了工作助理（list + send），你这月有 5000 奖金。翻了财务助理的记录（history），你已经花了 2000。我刚派个新的分身（spawn）去查了价，电脑要 8000。所以你还得再存 5000 才够哦！”

架构中的位置

Layer 2：网关控制面与 Session Router

系统默认维持会话间的物理与内存隔离。这一点在工业级测试中至关重要——如果 Agent 之间共享内存，一个发生逻辑幻觉的节点会瞬间污染整个测试工具链。这道隔离墙确保每个 Agent 都在自己的“单间”里工作，从源头上掐断了风险的横向蔓延。

红色穿透线

sessions_send 是唯一被允许动态穿透隔离墙、建立跨会话路由的内部协议。它的起点在 Layer 4 的沙箱执行层，终点指向另一个沙箱。注意，sessions_send 没有任何聊天软件的属性，它就是一条受到网关严格监控的跨进程通信管道。这段路由，是确保代码数据不泄露、执行权限不越界的核心安检通道。

Layer 5：混合记忆系统

这里把原始日志、知识图谱和向量索引完全独立在 Layer 3 的推理大脑之外。这就是所谓的“状态外置”——大脑只负责运算，所有的记忆和审计痕迹全部沉淀在外部存储中。这种架构是满足 B 端审计要求的基础设施。

完整执行流程

第一步：目标解析

说白了就是分布式系统中的寻址。用 sessionKey 或 label 查找，本质上是在构建一套动态的服务注册表。通过标签寻址，系统可以具备极强的扩展性——新进一个 Agent，只要能匹配标签就能被找到。

第二步：权限检查

这是核心防御筹码。A2A 策略结合沙箱限制，相当于在 AI 内部构建了一套防火墙，让它们在受控的权限范围内进行有限的协作。

第三步：消息投递 & 第四步：等待回复

启动目标 Agent 并选择性地同步等待，这其实就是异步任务队列。通过控制等待行为，可以防止主程序因为某个子节点的推理延迟而陷入假死。

第五步：A2A 协商

设定了最多 5 轮的限制，防止递归深度溢出，收敛复杂度。

第六步：最终通知

状态外置。数据投递回原始频道，意味着所有的中间协商过程都是透明且可追溯的。这不仅是信息的同步，更是审计日志的归档。

A2A 多轮协商流程

在实际业务中，Agent A 作为请求者，得到 Agent B 的执行确认后，如果还继续回复“谢谢”“辛苦了”之类的礼貌性语句，会造成逻辑冗余。这个流程通过在第三次指令中预设 REPLY_SKIP 逻辑，让 Agent B 在完成动作后直接触发系统级的最终通知，省去了无效交互。

sessions_send 参数

基础参数（7个）

1. sessionKey（目标会话标识）：字符串，指定消息发送到的目标 Agent 会话唯一 ID。好比工位编号，确保消息准确送达。
2. text（消息内容主体）：字符串，承载要发送的文本指令或信息。
3. replySkip（跳过回复标志）：布尔，控制目标 Agent 是否需要回复。True 表示单向通信，避免无效对话循环。
4. announceSkip（跳过广播标志）：布尔，控制该消息是否在用户界面或公共频道显示。True 表示静默执行，不在 UI 上显示。
5. images（图像资源）：数组，允许传递图像文件。
6. files（文件资源）：数组，允许传递各种附件。
7. metadata（元数据）：字典，携带额外结构化信息，如业务流水号、优先级，方便追踪和审计。

扩展参数（6个）

8. wait（同步/异步标志）：布尔，控制发送后是否等待目标 Agent 响应。True 同步等待，False 异步发送。
9. timeout（超时时间）：数值（秒），设置等待响应的最长时间。超时后系统中断连接并采取措施。
   • timeoutSeconds = 0：加入队列并返回 { runId, status: "accepted" }。
   • timeoutSeconds > 0：等待最多 N 秒直到完成，返回 { runId, status: "ok", reply }。
10. priority（优先级）：数值，在并发场景下确定消息处理顺序。
11. context_mode（上下文模式）：枚举，定义发送时是否包含历史会话上下文。可选 "none"、"current"、"full"。
12. trace_id（追踪 ID）：字符串，贯穿所有相关 Agent 和服务，方便问题排查和审计。
13. max_tokens（最大 Token 数量）：数值，限制目标 Agent 处理该消息时能使用的最大 Token，用于成本控制。

四种模式

通过组合 replySkip 和 announceSkip 两个参数，可以衍生出四种典型的协作模式：

协作模式：Reply ON & Announce ON

适用场景：复杂任务的分工协作与人类监管。
举例：代码安全分析过程中，Agent A 发现潜在漏洞，需要和 Agent B（安全专家）进行多轮对话探讨漏洞成因和修复方案。这种模式必须让两个 Agent 充分交换信息。

任务派发模式：Reply SKIP & Announce ON

适用场景：主 Agent 向子 Agent 下达耗时任务。
举例：主 Agent 让 Agent B 对上千行代码进行静态分析，分析可能需要几分钟甚至更长时间。主 Agent 下达指令后，不必等待，可以去处理其他任务。这种模式能有效提升系统并发能力。

暗中核查模式：Reply ON & Announce SKIP

适用场景：向内存 Agent 悄悄校验事实，不打扰用户。
举例：代码审计或芯片验证过程中，Agent A 在本地生成代码片段，Agent B 在后台对安全性、合规性进行校验。校验结果写入审计日志，但不会主动向 Agent A 或用户发送任何信息。这套机制是代码安全持续审计的前提。

底层遥测模式：Reply SKIP & Announce SKIP

适用场景：向日志或监控 Agent 悄无声息地单向灌输数据。
举例：Agent C 负责收集系统运行指标（CPU、内存、Agent 间通讯延迟等），并将这些数据静默发送到监控系统，用于诊断和性能优化。这种模式是实现工业级系统监控的基础。

任务派发和暗中核查这两种模式，恰好对应了 sessions_send 流程图中强调的 replySkip 和 announceSkip 参数，是实现工业级管控的核心所在。