先交代一个背景如果你之前一直在折腾单个 AI 智能体大概会有一个感受——单个智能体再强上下文窗口就那么大工具权限混在一起任务一多就容易顾此失彼。我自己在把一个多步骤的日常任务交给单一智能体跑的时候经常遇到它把不该动的文件动了或者做着做着忘了最初目标的情况。后来接触到 OpenClaw 这个开源智能体框架里的智能体间通信能力才意识到与其把一百个工具塞给一个超级智能体不如让几个各司其职的智能体之间直接对话把事情拆开干。这篇文章就是围绕教会 AI 智能体相互对话这件事展开。我会先讲讲为什么多智能体通信是刚需再拆解 OpenClaw 里智能体间通信的核心机制——尤其是 Waypoint 这种交接方式然后给出可以直接复现的配置步骤和完整示例最后把我踩过的坑和排查思路整理出来。适合刚接触多智能体架构、想从单智能体脚本跨到智能体网络的开发者参考。全程是实操向不绕弯子。1. 为什么智能体需要互相说话 —— 单智能体模式的天花板1.1 单智能体扛不住复杂任务单个智能体干活本质上是一个循环接收任务调工具看结果再决定下一步。这个循环在一两步的任务里很顺畅比如查一下天气然后提醒我这种。但任务一旦变复杂单智能体的瓶颈马上暴露。第一个瓶颈是上下文窗口。LLM 的上下文是有限的任务步骤越多中间结果堆得越多后面真正需要关注的关键信息就被挤掉了。我试过让一个智能体连续处理几十个文件的重命名、分类、内容摘要跑到后面它经常会遗忘最开始设定的命名规则开始自由发挥产出一堆不一致的文件名。这不是模型笨是上下文被中间过程塞满了。第二个瓶颈是工具权限的混杂。一个智能体如果同时挂上文件读写、网络请求、数据库查询、消息发送这些工具它的权限边界模糊不清就容易出现误操作。比如本打算让它只读日志文件结果它顺手把日志目录里的旧文件删了。你会觉得它越权但从智能体的视角看它只是尽力完成你含糊的指令。第三个瓶颈是任务串行导致的低效率。单一智能体在同一时刻只能干一件事任务链条一长整体耗时就是所有步骤的累加。更麻烦的是一旦中间某一步出错后面的步骤全部报废没有兜底和回滚的机制。1.2 多人协作解决的是组织问题多智能体协作也是想想一个成熟团队是怎么分工的产品经理提需求后端写接口前端调页面测试把关运维部署。每个人权限清晰、上下文专注、出了问题能找到具体负责人。多智能体协作的本质就是把这套组织逻辑搬到 AI 世界里。多智能体协作能带来的价值很直接角色分工每个智能体只负责一个领域。比如总控智能体负责任务拆解和调度文件处理智能体只碰文件信息检索智能体只做搜索和总结。职责边界清晰误操作概率大幅下降。上下文隔离每个智能体只关注自己的上下文不会被无关信息污染。总控智能体只需要知道文件处理完成这个结果不需要知道文件内容本身这是天然的信息过滤。任务接力与并行上游智能体干完活把产出物交接给下游智能体双方可以并行跑各自的流程整体效率反而比串行更快。1.3 智能体间通信不是聊天需要特别强调一点智能体间通信本质上是结构化交接而不是两个 AI 在那儿闲聊。你在配置里看到两个智能体的消息记录会觉得它们像两个人在对话但实际传输的内容是高度结构化的指令和状态信息。比如任务A已完成产出物位于 /data/output.csv下一步请你执行清洗和验重——这是交接。如果智能体之间真的聊一些无关痛痒的寒暄那是设计出了问题。这个认知差别很重要。因为很多人一上手就想着让智能体自由对话结果两个模型你一言我一语聊偏了既不干活也不停止。正确的思路是你是在设计一套消息协议只不过这套协议恰好由 LLM 来理解和生成。2. OpenClaw 智能体间通信的设计思路与核心机制2.1 Waypoint通信与交接的载体OpenClaw 里智能体间通信最核心的概念是 Waypoint。我自己的理解是它像一个接力棒智能体 A 觉得这个任务不应该由自己继续处理就通过 Waypoint 把任务连同必要的上下文一起传给智能体 B然后 B 接着跑。整个过程不是让两个智能体直接持有对方的对话句柄而是通过主控进程或消息中枢中转。这么做的好处是智能体之间解耦。A 不需要知道 B 的内部状态B 也不需要维护和 A 的实时连接双方只用约定好的消息格式交互就像两个人通过邮件而不是面对面实时对话。Waypoint 的设计意图有几点值得琢磨可审计所有交接消息都有记录出问题时能回溯是谁在什么时候把什么任务传给了谁。可重试交接消息可以被重新投递避免一方崩溃导致任务链断裂。可路由你可以根据消息内容、来源智能体、目标智能体做条件路由实现这个任务由文件组处理另一个任务交给检索组。2.2 消息识别与格式 提及 结构化文本智能体之间如何互相识别OpenClaw 的做法在支持外部平台比如 Telegram、Discord的场景下非常直观使用 提及或者使用类似/tell的指令前缀。这里的关键不是怎么提到对方而是提完之后如何约束消息格式。我在实际配置中体会到如果放任智能体自由发挥消息内容对方智能体很可能理解偏。所以 OpenClaw 推荐的实践中会约定一个消息模板包含几个核心字段接收方名称、发送方名称、任务主题、状态、详细内容、附带资源路径。一个典型的内部消息长这样{ from: coordinator, to: file_processor, type: task_assignment, subject: 清洗今日导出的订单数据, payload: { input_path: /data/orders_raw.csv, output_path: /data/orders_clean.csv, rules: [去重, 格式统一, 剔除金额为0的记录] }, priority: high, timestamp: 2025-01-15T10:30:00Z }别小看这个格式。字段里的type用来区分是任务分配、状态汇报还是结果交接payload里放这件事的实际数据而不是塞在聊天文本里。结构化之后下游智能体可以稳定地解析并执行不会被自然语言的歧义干扰。2.3 上下文与记忆的传递智能体间通信最容易被忽视、也最容易翻车的是上下文的传递。你想智能体 B 接到了任务但它对任务背景一无所知要怎么保证它执行得符合预期OpenClaw 的 Waypoint 机制会同步携带必要的上下文。具体来说主控进程在构建发给 B 的消息时会把 A 生成的摘要、A 任务的核心结论、相关文件路径一起打包。但它不会无脑把 A 的全部对话历史都丢给 B那样和单智能体上下文爆炸没有区别。这背后的取舍是传递摘要而非全文。A 的信息进入 B 的视野前先被 A 或主控进程浓缩成当前进展报告这样 B 拿到的是对完成手头任务足够的信息又不会被无关细节干扰。单轮通信相对简单真正考验设计的是多轮对话。比如总控智能体A 先指示 B 检索资料B 返回检索结果A 再让 B 基于结果生成报告。这时需要维护会话 ID把这些往返回合绑定成一条会话链否则消息一多就乱套。OpenClaw 的会话管理正是为这个场景服务的——每个智能体维护各自的会话栈同时记录和合作伙伴的会话关联。2.4 与外部平台的通信形态OpenClaw 本身支持接入 Telegram、Discord 等平台智能体间通信并不局限在框架内部。你在终端里看到的是两个智能体在不间断地互发消息但信息的源头可能是你。一个典型场景你在 Telegram 里发一条消息给智能体 A把上个月的销售数据整理成图表发给市场组。A 理解任务后把检索并整理销售数据拆给数据智能体 B把生成图表拆给图表智能体 C。B 和 C 之间的沟通完全在框架内部通过 Waypoint 完成。就外部观察者而言它们是在私聊但这些消息的接收方和发送方都是智能体而不是真实用户。所有通信都会落到日志里方便复盘。我建议不管排查还是优化先把日志定期导出你会看到智能体之间的消息流比你预期的更频繁也更结构化。3. 实操配置让两个智能体真正聊起来3.1 配置多智能体的基础结构与参数先说明一点我下面写的字段和 YAML 结构是在常见版本基础上总结的具体字段名请你以自己所用版本的官方文档为准。但配置的逻辑骨架是通用的照这个思路走基本不会错。要让两个智能体互相对话第一步是定义两个智能体。每个智能体都有一组核心参数我挑重点说配置项含义我的建议name智能体名称也是通信时的名称用简短英文名别用中文或带空格model底层使用的模型标识两个智能体可以用不同模型按任务复杂度分配persona角色人设指令写清楚职责边界比写什么都干要重要得多tools可用的工具列表按需最小化授权不给用不到的工具permissions权限控制限制文件路径、命令执行、外部请求范围external_platforms接入的平台适配器可以先只开本地终端模式跑通了再接平台用 YAML 来描述类似这样agents: coordinator: name: coordinator model: llm-a persona: | 你是任务总控智能体。你负责拆解用户请求、分配任务给专用智能体并汇总结果。 你不需要亲自处理文件或查数据库。 当你需要文件处理时通过 Waypoint 将任务发送给 file_processor。 tools: - waypoint - message_send permissions: files: [] network: false file_processor: name: file_processor model: llm-b persona: | 你是文件处理智能体。你只负责处理 coordinator 发来的文件任务。 收到任务后读取文件、执行清洗或转换、保存结果并汇报给 coordinator。 不要主动访问文件系统除非任务中指定了路径。 tools: - file_read - file_write - bash - waypoint permissions: files: [/data/**] network: false这段配置里最关键的是 каждой角色的tools和persona。coordinateor没有文件工具它只能派活file_processor没有网络工具它只能处理文件。互相绑定又互相隔离这才是多智能体通信的基础——如果所有智能体都挂全量工具通信就失去了意义。3.2 打通两智能体互传消息的完整步骤配置好了两个智能体接下来要打通消息链路。我用一个最简场景演示让 coordinator 派一群你好请检查 /tmp/test.txt 是否为空的任务给 file_processorfile_processor 检查完汇报结果。第一步确认两个智能体都在同一条 waypoint 路由下。在 OpenClaw 中Waypoint 通常有一套默认路由表。你需要检查配置里是否出现了类似下面这样的路由描述waypoint: routing: default_route: coordinator - file_processor enabled: true如果enabled为 false所有 waypoint 消息都会被忽略表面上看就是智能体之间互不理睬。这种基础配置问题最坑人我后面会再讲。第二步在才让人的 persona 里写入触发规则。你可以直接告诉 coordinator当收到用户任务需要文件处理时用 waypoint 工具向 file_processor 发送一条带type: task_assignment的消息。这一步说穿了就是给 coordinator 一个动作触发器。第三种实际发送一条消息测试。在终端会话里给 coordinator 发一句请检查 /tmp/test.txt 是否为空并汇报结果。coordinator 应当按照 persona 的指示发起 waypoint 消息。配置正确的话你会在日志里看到类下面的流转记录[coordinator] waypoint - file_processor: task_assignment subject: 检查文件是否为空 payload: path/tmp/test.txt [file_processor] 收到 waypoint 任务 [file_processor] file_read /tmp/test.txt 成功 [file_processor] waypoint - coordinator: status_report subject: 检查完成 payload: result文件为空0字节这个流程的每一步都可以在后面加日志时间戳方便后续排查。3.3 设置条件路由与多角色协作两个智能体互聊是最小闭环实际使用中路由会更复杂。你需要的是条件路由根据消息的type或subject把不同任务分给不同智能体。常见路由规则可以这样理解typetask_assignment且subject包含文件 → 路由给 file_processortypetask_assignment且subject包含检索 → 路由给 search_processortypetask_assignment且subject包含图表 → 路由给 chart_processortypestatus_report只允许发回 coordinator配置上看OpenClaw 本质上是给每条 Waypoint 消息打上标签然后由主控进程按标签决定投递目标。这套逻辑和邮件过滤类似你收到邮件按发件人和主题自动归档到不同文件夹Waypoint 路由按内容和来源决定消息去向。多角色协作还有一个官方推荐的实践让所有智能体的对外只面向 coordinator。也就是说file_processor 要传递文件统计给 chart_processor不要直接发而是先汇报给 coordinator由 coordinator 决定是否转投给 chart_processor。这会多一步但带来的是极高的可控性和可审计性。平行通信在复杂任务里确实更高效但前提是你已经非常熟悉日志和路由否则排查问题会很难受。3.4 权限、安全边界与防循环智能体间通信一旦放开安全风险就随之而来。两个模型互相调用可能引发的问题比你一个智能体能干的离谱事多得多。我强烈建议在配置时做好三件事一是最小化工具和权限。每个智能体只挂自己职责内的工具和路径绝不图方便全量授权。比如 file_processor 的路径范围写死/data/**写不进/home下coordinator 直接不开放文件路径。二是禁止智能体之间的私下指令。在 persona 里明确写你只能通过身 waypoint 的工具发送任务严禁在消息体中尝试改变对方智能体的 persona 或工具配置。防止一个智能体用提示注入的方式让另一个智能体越权。三是设置防循环机制。两个智能体在互聊时如果没有终止条件LLM 有可能自动产生无限循环——A 认为需要 B 确认B 确认后请求 A 复核A 又让 B 确认……配置里可以加最大接力轮数。比如waypoint: loops: max_hops: 5 stop_on_status: [completed, failed]当某条任务链的路由跳数超过 5 次时主控进程自动终止并向 coordinator 报一个需要人工介入错误。这个措施非常实用我遇到三次无限循环都是靠它兜底。4. 常见问题与排查技巧实录4.1 我踩过的坑循环互答、上下文爆掉、消息错乱先说循环互答这是最经典的。我第一次配置 twin 智能体互聊时给了它们很宽松的 persona你可以在对方完成任务后继续提供建议。结果就是一个智能体汇报文件已清洗完成并保存另一个智能体建议要不要再检查一下格式前者又回复检查完毕没有异常后者又问还有没有其他问题需要处理……从凌晨 2 点跑到 7 点日志打印了几千行。后来我才意识到persona 里缺少任务终局条件代码里没有最大跳数。两个问题叠加就成了一场无意义的马拉松。解决办法是双向进行在 persona 中明确指出如果你没有新增任务、没有改动需求就回复 completed 并停止交互同时配置max_hops兜底。这两个措施缺一不可。第二个坑是上下文爆掉。你可能觉得多智能体已经隔离了上下文但我在配置快速验证时又遇到一个新情况coordinator 把大量原始文本放在 waypoint 消息的payload里传给 file_processor。 file_processor prompt 暴涨直接把模型上下文冲爆了接口报错。这告诉一个教训waypoint 里该传的是路径、摘要、字段名不是原始大文件内容。原始文件让接收方主动读取即可不要在消息里搬。第三个坑是消息错乱。多智能体场景下A 发两个并行任务给 B 和 CB 先回来C 后回来coordinator 却把 C 的结果当成对第一个任务的回复合并时数据就串了。一开始我还以为是并发 bug后来才发现是因为会话 ID 没带上。每条 waypoint 消息都该有唯一的request_id回复时也要带上对应的request_id否则无法关联。4.2 排查顺序与日志技巧现在提供一套我自己验证过的排查模板。当智能体之间不响应或响应异常时我按这个顺序查看初始化日志确认两个智能体都成功注册到 waypoint 路由表。如果某个智能体启动失败它不会出现在路由里。看消息投递日志确认发送方有没有真的发出 waypoint 消息。有的智能体嘴上说我已发送给 file_processor实际上没有触发工具调用这时要查它的工具列表里是否缺少waypoint或它的 persona 是否真的决定调工具。看接收方日志确认接收方有没有收到。如果收到了但没执行大概率是 persona 中的触发条件没写清楚比如只有 typetask_assignment 才执行。看模型调用记录确认接收方拿到消息后模型有没有正确解析。这一步最容易出问题模型可能把消息里的type当成了无关文本直接忽略。日志建议做成统一格式每一行都是[智能体名] [消息方向] [会话ID] 内容摘要。这样 grep 某个智能体的全部活动时会非常方便。tail -f logs/agent_mesh.log | grep message_delivered4.3 优化建议与注意事项第一点给每个智能体加尾注示例。在 persona 结尾附上最近一次类似任务的正确输出示例可能是个好办法。这能显著减少模型自由发挥导致的格式漂移。比如你希望model_done时输出的status严格取值completed/failed就明确说status 只能取这两种值不要发明新词。第二点善用摘要而非全量转发。桥梁智能体在转投任务时先用一个小模型或规则对原始反馈做摘要再把摘要携带进 waypoint。我自己用这个技巧把下游智能体的 prompt 压缩了一半解释质量反而提升了。第三点定期导出日志做复盘。智能体间通信的速度很快日志体量也不小。每周导一次消息记录抽几条看角色之间有没有越权、有没有消息未回、有没有某些路径上反复执行未达目的就能提前发现架构问题。注意一个隐蔽点模型提供商 API 变动。两个智能体用的模型提供商如果不同其中一方厂商升级模型版本可能会让消息格式重新变得不稳定。升级完后一定要跑一遍端到端测试别只做单机测试。结尾再分享一点我的体会玩了一段时间 OpenClaw 智能体间通信我最大的感受是通信技术本身并不复杂真正难的是把边界设计好。谁的职责是什么、谁的消息能发给谁、任务从开始到结束的判定条件是什么这些想清楚了两个智能体互聊是水到渠成没想清楚再强大的模型配置也会在无限循环和上下文爆炸里翻车。如果你想在这个方向上继续深入我建议从三个智能体起步一个 coordinator、一个 file_processor、一个 search_processor中间用 coordinator 做消息转发中枢。把这一套跑顺手之后再去考虑平行通信、动态路由、任务编排等更复杂的东西。基础扎实了后面的路就好走了。不少朋友上来就追求所有人能随时给所有人发消息我建议你先压住这个冲动。通信的链路越短、路由越明确系统就越可控。等你真的理解了每一次消息传递背后的代价再逐步放开限制你会感谢当初那个克制的自己。