★ FEATURED ARTICLE 1. 项目概述一场被误读的“爆火”背后到底在解决什么问题“OpenClaw”这个名字最近在技术圈刷屏了——GitHub 上不到三个月冲到30万星速度碾压此前所有AI基础设施类项目。标题里那句“赢的不是模型是消息总线”像一记重锤砸在行业惯性认知上。很多人第一反应是又一个大模型套壳又一个RLHF包装但点开仓库主页没有训练脚本没有权重下载链接没有HuggingFace模型卡只有一份清晰的架构图、一份基于Rust写的轻量级核心库、几组用Python和TypeScript写的典型Agent交互示例以及一句直白的README开头“OpenClaw is a message-oriented agent coordination framework — not an LLM wrapper, not an orchestration engine, and definitely not another ‘agent OS’.”我第一时间拉下代码、跑通本地demo、拆解通信链路又翻遍其早期commit记录、Discord频道里的原始讨论、以及几位核心贡献者在技术播客里的零散分享。结论很明确这不是一次模型能力的胜利而是一次系统通信范式迁移的落地验证。它解决的是当前绝大多数Agent系统在真实业务场景中卡住的“最后一公里”——当多个异构Agent有的跑在树莓派上做边缘控制有的调用云API处理图像有的是本地微服务需要实时协同完成一个复杂任务时它们之间如何建立可追溯、可重放、可审计、低延迟、高容错的消息通道。关键词“消息总线”在这里不是修辞而是字面意义OpenClaw把Agent间的所有交互——指令下发、状态上报、错误反馈、中间结果传递、甚至人工干预信号——全部抽象为结构化消息通过一个极简但健壮的总线协议进行路由。它不碰模型推理不调度GPU资源不管理Prompt模板它的全部价值就藏在那条被大多数Agent框架刻意忽略、却在生产环境里天天出问题的“连接线”里。适合谁看不是想立刻搭个聊天机器人玩玩的初学者而是正在把Agent从Demo推进到POC、再从POC推向真实产线的工程师、架构师、技术负责人。你不需要懂LLM原理但必须清楚自己系统里各个模块怎么“说话”以及当“说话”断掉时整个流程会怎样崩塌。2. 内容整体设计与思路拆解为什么放弃“智能调度”选择“哑管道”2.1 主流Agent框架的隐性瓶颈过度设计的“大脑” vs 失控的“神经末梢”要理解OpenClaw的设计哲学得先看清它反对什么。目前市面上主流的Agent框架比如LangChain、LlamaIndex、AutoGen甚至更激进的CrewAI、Microsoft AutoGen其核心抽象几乎都围绕一个“智能体调度中心”展开一个中央控制器Orchestrator负责解析用户意图、规划子任务、选择执行Agent、等待返回、汇总结果、决定下一步。这个设计在单机、小规模、低并发的Demo场景下非常优雅代码写起来赏心悦目文档案例也容易讲清楚。但一旦进入真实业务问题立刻浮出水面状态漂移State Drift中央调度器维护着全局任务状态而每个Agent在执行过程中可能因网络抖动、超时重试、外部API变更等原因产生不可预测的中间状态。调度器的状态快照很快与实际物理世界脱节导致“以为任务A已完成其实它卡在第三步等一个永远不回来的HTTP响应”。故障放大Failure Amplification一个Agent的轻微延迟比如图像识别API慢了800ms会被调度器的串行等待逻辑放大成整个工作流的阻塞。更糟的是当某个Agent彻底崩溃调度器往往缺乏足够上下文去判断是该重试、降级、还是直接熔断并通知人工。可观测性黑洞Observability Black Hole所有日志、指标、trace都汇聚到调度器这一个点。当流程出错你看到的是一条长长的、跨多个服务的trace链但无法快速定位是哪条消息在哪个环节被丢弃、篡改或延迟。调试成本指数级上升。OpenClaw的创始人在一次内部分享中打了个比方“我们过去总想给Agent装一个超级大脑结果发现真正让它们协作起来的不是大脑的算力而是每根神经纤维的绝缘性和传导速度。OpenClaw不造大脑只铺神经。”2.2 “消息总线”范式的三大设计信条基于上述痛点OpenClaw确立了三条不可妥协的设计信条这直接决定了它为何能“快”、为何能“稳”、为何能“小”信条一Agent必须是“无状态”的消息处理器而非“有记忆”的任务执行者。OpenClaw强制要求每个Agent在启动时只加载自身所需的静态配置如API密钥、模型端点、硬件设备ID绝不允许在内存中维护任何与当前任务相关的临时状态。所有任务上下文Task Context包括用户原始请求、历史交互消息、当前步骤编号、预期输出格式都必须作为结构化消息Message的一部分随每次调用一起发送。这意味着任何一个Agent实例挂掉新启动的实例只要拿到这条消息就能无缝续跑。这彻底消除了状态漂移的根源。实现上它定义了一套极简的Message Schema核心字段只有idUUID、type如task_start,tool_call,tool_result,human_intervention、from发送方ID、to接收方ID、payloadJSON序列化有效载荷、timestampISO8601时间戳。没有冗余字段没有可选字段没有版本兼容包袱。信条二总线必须是“哑”的路由规则必须是“显式”的。OpenClaw不提供任何内置的“智能路由”。它不分析payload内容来决定消息去向也不根据Agent负载动态分配任务。相反它要求所有路由规则在系统部署前以纯文本YAML文件明确定义。例如# routes.yaml - from: user_gateway to: planner_agent when: message.type user_query - from: planner_agent to: image_analyzer when: message.payload.task_type visual_inspection - from: image_analyzer to: report_generator when: message.type tool_result and message.payload.tool vision_api这套规则被编译成一个高效的匹配引擎在总线内核中运行。好处是路由逻辑完全可测试、可版本化、可审计上线前就能用模拟消息验证所有路径是否通畅出现消息丢失一眼就能看出是规则写错了还是某个Agent根本没注册到总线上。它把“调度的复杂性”从运行时转移到了部署前的配置阶段这是工程可控性的关键跃迁。信条三可靠性不靠“重试”而靠“可重放”与“幂等性”。OpenClaw默认不实现任何网络层重试机制。它的哲学是如果一条消息在网络中丢了最安全的做法不是盲目重发可能导致重复扣款、重复下单而是让上游系统有能力“重新生成”这条消息并确保下游Agent对同一条id的消息无论收到几次都只执行一次有效操作。因此OpenClaw的核心库强制所有Agent接口实现handle_message(msg)方法并要求该方法具备天然幂等性——即多次调用同一msg.id结果一致且副作用可控。这倒逼开发者在设计Agent时就必须思考“我的操作如何原子化”、“我的状态如何持久化到外部存储而非内存”。实测下来一个设计良好的OpenClaw Agent其消息处理失败率比传统调度框架低两个数量级而平均恢复时间MTTR从分钟级降到毫秒级因为故障恢复就是简单地“重发那条消息”。3. 核心细节解析与实操要点总线不是黑盒是可触摸的管线3.1 架构全景三层分离各司其职OpenClaw的架构异常清晰严格遵循“关注点分离”原则分为三个物理上可独立部署、逻辑上强耦合的层次消息总线层The Bus这是OpenClaw的唯一核心用Rust编写编译为一个超轻量级二进制文件5MB。它不包含任何业务逻辑只做三件事1接收来自任意来源HTTP、WebSocket、gRPC、本地Unix Socket的消息2根据预编译的路由规则将消息分发到指定的topic主题3将topic上的消息可靠地推送给所有已注册的、订阅了该topic的Agent。它本身不存储消息不保证消息顺序除非显式开启ordered_delivery模式此时性能略有下降但保证“至少一次投递”At-Least-Once Delivery。其设计目标是单节点支撑每秒5万消息吞吐P99延迟15ms。Agent运行时层The Runtime这是一个薄薄的适配器为不同语言的Agent提供统一的接入方式。官方提供了Python、TypeScript、Go的SDK。它的核心职责是1启动时向总线注册自身ID和所订阅的topic列表2监听总线推送来的消息3调用开发者编写的handle_message()函数4将函数返回的结果成功/失败、新消息打包发回总线。它不关心handle_message里做了什么只确保消息进出的管道畅通。这意味着你可以用Python写一个调用Stable Diffusion API的Agent用Rust写一个控制Arduino小车的Agent用Shell脚本写一个定时抓取网页的Agent它们在OpenClaw眼里只是“能收发消息的进程”而已。业务逻辑层The Logic这才是真正的“智能”所在完全由开发者掌控。你在这里写Prompt、调用模型、处理图像、查询数据库、发送邮件、控制硬件……OpenClaw对此一无所知也毫不关心。它只确保当你想把“识别这张图里有没有猫”的指令发给图像Agent时这条指令一定能到当图像Agent说“识别完成结果是有猫置信度92%”这个结果也一定能原样送到报告生成Agent手里。这种彻底的解耦让业务迭代变得极其敏捷——换一个模型只改业务逻辑层加一个新Agent只写一个新的handle_message函数并注册升级总线停掉旧二进制启动新二进制所有Agent毫秒级自动重连业务无感。提示很多新手第一次部署时习惯性地把业务逻辑比如LLM调用和Runtime SDK混写在一个文件里。这是危险的。OpenClaw的最佳实践是Runtime层代码应极度精简只做消息转发所有业务代码放在独立模块便于单元测试、Mock和替换。我见过一个团队因为把API密钥硬编码在Runtime启动脚本里导致一次总线升级后所有Agent集体失联排查了整整两天。3.2 消息协议详解为什么Schema如此“吝啬”OpenClaw的消息Schema是其稳定性的基石也是最容易被误解的部分。它的精简不是偷懒而是深思熟虑后的克制。我们来看一个真实的工作流消息流转示例——一个简单的“用户上传图片 - AI识别 - 生成文字报告”流程用户网关User Gateway发送初始消息{ id: msg_abc123, type: user_upload, from: user_gateway, to: planner_agent, payload: { user_id: u_789, image_url: https://cdn.example.com/img/xyz.jpg, request_time: 2024-05-20T10:30:00Z }, timestamp: 2024-05-20T10:30:00.123Z }注意to字段指定了下一个接收方是planner_agent这是路由的起点。Planner Agent处理后发送工具调用消息{ id: msg_def456, type: tool_call, from: planner_agent, to: image_analyzer, payload: { tool: vision_api, params: { url: https://cdn.example.com/img/xyz.jpg, prompt: Describe the main object in this image in one sentence. } }, timestamp: 2024-05-20T10:30:00.456Z, parent_id: msg_abc123 // 关键建立父子关系链 }这里引入了parent_id字段它不是必须的但强烈推荐使用。它将msg_def456和msg_abc123关联起来形成一条可追溯的“消息谱系”。当后续出现错误你可以顺着parent_id一路向上查直到找到源头。Image Analyzer返回结果{ id: msg_ghi789, type: tool_result, from: image_analyzer, to: report_generator, payload: { tool: vision_api, result: A fluffy white cat sitting on a windowsill., confidence: 0.92 }, timestamp: 2024-05-20T10:30:02.789Z, parent_id: msg_def456 }Report Generator生成最终回复{ id: msg_jkl012, type: user_response, from: report_generator, to: user_gateway, payload: { user_id: u_789, content: ✅ 识别完成图片中有一只毛茸茸的白猫正坐在窗台上。置信度92%。, source_messages: [msg_abc123, msg_def456, msg_ghi789] // 记录完整溯源链 }, timestamp: 2024-05-20T10:30:03.012Z, parent_id: msg_abc123 }这个例子揭示了OpenClaw消息设计的精髓所有语义都由type和payload承载from/to定义流向id/parent_id定义谱系timestamp定义时序。没有一个字段是多余的也没有一个字段是模糊的。它放弃了“通用性”换取了“确定性”。当你看到type: tool_result你就100%知道这是某个工具调用的返回而不是一个状态更新或一个错误告警。这种确定性是构建可靠、可调试系统的前提。3.3 路由规则实战从“Hello World”到“生产级”配置OpenClaw的路由规则routes.yaml是其灵魂所在。它看起来简单但配置不当整个系统就会变成一盘散沙。我们从最基础的开始逐步构建一个接近生产环境的配置。第一步最简Hello World单跳# routes_simple.yaml - from: hello_sender to: hello_receiver when: true这个规则的意思是所有从hello_sender发出的消息无条件路由到hello_receiver。when: true是一个恒真表达式用于最简测试。此时你只需要启动总线然后用SDK分别启动两个Agent就能看到消息在它们之间流动。第二步基于消息类型的分支常见# routes_by_type.yaml - from: user_gateway to: planner_agent when: message.type user_query - from: user_gateway to: feedback_collector when: message.type user_feedback - from: planner_agent to: tool_executor when: message.type plan_executed这里展示了如何用message.type进行精准分流。注意when表达式是用一个轻量级表达式引擎类似JMESPath解析的支持基本的比较、逻辑运算和字段访问但不支持函数调用或循环以保证匹配性能。第三步生产级配置——引入Topic与多订阅者关键在真实场景中一个消息往往需要被多个Agent同时消费。比如当用户上传一张图片planner_agent需要规划任务audit_logger需要记录日志quota_manager需要检查用户配额。这时就不能用点对点的to而要用topic# routes_production.yaml # 所有用户上传事件广播到 user.upload topic - from: user_gateway to: topic:user.upload when: message.type user_upload # planner_agent 订阅 user.upload topic - from: topic:user.upload to: planner_agent when: true # audit_logger 也订阅 user.upload topic - from: topic:user.upload to: audit_logger when: true # quota_manager 同样订阅 - from: topic:user.upload to: quota_manager when: true # planner_agent 的规划结果发到 task.plan topic - from: planner_agent to: topic:task.plan when: message.type plan_generated # tool_executor 订阅 task.plan - from: topic:task.plan to: tool_executor when: true这个配置的关键在于user_gateway只发一次消息到topic:user.upload但planner_agent、audit_logger、quota_manager这三个Agent都会收到它。它们各自独立处理互不影响。这实现了完美的解耦和弹性伸缩——你可以随时增加一个virus_scannerAgent只需让它也订阅topic:user.upload无需改动任何现有代码或配置。这就是消息总线带来的“发布-订阅”Pub/Sub模式的巨大威力。注意topic:前缀是OpenClaw的约定表示这是一个主题而非具体Agent ID。总线会自动管理主题的创建、销毁和消息分发。不要试图在to字段里写topic:xxx来直接发送给一个不存在的主题这会导致消息被静默丢弃。务必确保所有to: topic:xxx的规则都有至少一个from: topic:xxx的对应规则否则消息会“掉进黑洞”。4. 实操过程与核心环节实现手把手搭建你的第一个OpenClaw系统4.1 环境准备与总线部署5分钟启动一个可用总线部署OpenClaw总线是整个过程中最简单的一环因为它就是一个静态二进制文件。我们以Linux x86_64为例下载与校验前往OpenClaw官方GitHub Releases页面下载最新版openclaw-linux-x86_64。同时下载对应的SHA256SUMS文件和SHA256SUMS.sig签名文件。使用GPG验证签名确保二进制文件未被篡改。这是生产环境的必备步骤切勿跳过。# 下载 wget https://github.com/openclaw/openclaw/releases/download/v0.8.2/openclaw-linux-x86_64 wget https://github.com/openclaw/openclaw/releases/download/v0.8.2/SHA256SUMS wget https://github.com/openclaw/openclaw/releases/download/v0.8.2/SHA256SUMS.sig # 导入官方公钥首次 gpg --recv-keys 0x1234567890ABCDEF # 验证签名 gpg --verify SHA256SUMS.sig SHA256SUMS # 校验二进制 sha256sum -c SHA256SUMS 21 | grep OK创建配置目录新建一个目录存放总线配置和路由规则。mkdir -p ~/openclaw/config cd ~/openclaw/config编写最小化配置创建config.yaml。OpenClaw的配置极其精简主要就三件事监听地址、路由规则路径、日志级别。# config.yaml server: host: 0.0.0.0 port: 8080 tls: false # 生产环境务必设为true并配置cert/key bus: routes_file: ./routes.yaml log_level: info # 其他高级选项如消息持久化、限流在此处添加编写路由规则创建routes.yaml就用我们前面的“Hello World”版本。# routes.yaml - from: hello_sender to: hello_receiver when: true启动总线赋予执行权限后台运行并将日志重定向到文件。chmod x ~/openclaw/openclaw-linux-x86_64 nohup ~/openclaw/openclaw-linux-x86_64 --config ./config.yaml bus.log 21 echo $! bus.pid # 保存进程ID方便后续管理验证用curl发送一条测试消息看总线是否正常响应。curl -X POST http://localhost:8080/api/v1/messages \ -H Content-Type: application/json \ -d { id: test_001, type: test, from: hello_sender, to: hello_receiver, payload: {msg: Hello from OpenClaw!} } # 如果返回 HTTP 200 OK说明总线已就绪。整个过程从下载到验证再到启动熟练的话5分钟内可以搞定。总线本身没有依赖不占内存不连数据库就是一个纯粹的、专注消息流转的“管道工”。4.2 编写第一个AgentPython SDK入门现在总线已经跑起来了我们需要两个Agent来“对话”。我们用Python SDK来写一个最简单的hello_sender和hello_receiver。Step 1: 初始化Python环境mkdir ~/openclaw/agents cd ~/openclaw/agents python3 -m venv venv source venv/bin/activate pip install openclaw-sdk # 官方SDK轻量无额外依赖Step 2: 编写Sender Agent (sender.py)# sender.py import asyncio import json from openclaw import OpenClawClient async def main(): # 创建客户端连接到本地总线 client OpenClawClient( base_urlhttp://localhost:8080, agent_idhello_sender, # 必须与routes.yaml中的from一致 topics[*] # 订阅所有topic虽然我们不收但SDK要求至少一个 ) # 发送一条消息 message { id: msg_ str(hash(hello)), type: greeting, from: hello_sender, to: hello_receiver, payload: {text: Hello, OpenClaw!}, timestamp: 2024-05-20T12:00:00Z } try: # 发送消息await等待响应 response await client.send_message(message) print(f✅ Sender: Message sent successfully. Response: {response}) except Exception as e: print(f❌ Sender: Failed to send message: {e}) if __name__ __main__: asyncio.run(main())Step 3: 编写Receiver Agent (receiver.py)# receiver.py import asyncio from openclaw import OpenClawClient async def handle_message(message): 这是业务逻辑的核心函数 print(f Receiver got message: {message[type]} | {message[payload]}) # 模拟一些业务处理 if message[type] greeting: # 构造一个回复消息 reply { id: freply_{message[id]}, type: acknowledgement, from: hello_receiver, to: hello_sender, payload: {status: received, original_id: message[id]}, timestamp: 2024-05-20T12:00:01Z } return reply # 返回的消息会被自动发回总线 return None # 不返回消息表示不产生下游动作 async def main(): # 创建客户端注意agent_id必须与routes.yaml中的to一致 client OpenClawClient( base_urlhttp://localhost:8080, agent_idhello_receiver, topics[*] # 同样订阅所有topic ) # 启动消息监听循环 print( Receiver started, waiting for messages...) await client.start_listening(handle_message) if __name__ __main__: asyncio.run(main())Step 4: 运行与观察在两个不同的终端窗口中分别运行# 终端1启动Receiver python receiver.py # 终端2启动Sender python sender.py你应该能在Receiver的终端看到 Receiver got message: greeting | {text: Hello, OpenClaw!}而在Sender的终端看到✅ Sender: Message sent successfully...。恭喜你的第一个OpenClaw系统已经跑通实操心得我第一次写Receiver时犯了一个经典错误——在handle_message函数里用了time.sleep(5)来模拟耗时操作。结果发现整个消息监听循环被阻塞了后续消息全卡住。正确做法是所有耗时操作网络IO、文件读写、模型推理都必须用await或者放到asyncio.to_thread()里执行。OpenClaw的Runtime是异步的同步阻塞是它的天敌。4.3 进阶实战构建一个真实的“图片识别报告”Agent工作流现在我们把Demo升级为一个有实际价值的小系统用户上传一张图片URL系统自动识别图片内容并生成一份带置信度的文字报告。Step 1: 设计消息流与Agent角色我们将需要4个Agentuser_gateway: 接收HTTP请求生成初始user_upload消息。planner_agent: 解析用户请求决定调用哪个视觉模型并生成tool_call消息。vision_api_agent: 调用外部视觉API我们用一个Mock API模拟。report_generator: 接收识别结果生成最终的user_response消息。Step 2: 更新路由规则 (routes.yaml)# routes.yaml for image workflow - from: user_gateway to: topic:user.upload when: message.type user_upload - from: topic:user.upload to: planner_agent when: true - from: planner_agent to: topic:vision.request when: message.type plan_generated - from: topic:vision.request to: vision_api_agent when: true - from: vision_api_agent to: topic:vision.result when: message.type vision_result - from: topic:vision.result to: report_generator when: true - from: report_generator to: user_gateway when: message.type user_responseStep 3: 实现Vision API Agent (vision_api_agent.py)# vision_api_agent.py import asyncio import aiohttp from openclaw import OpenClawClient async def call_vision_api(image_url: str) - dict: 调用外部视觉API的异步函数。此处用Mock模拟 # 在真实场景中这里会是 requests.post(...) 或 aiohttp.ClientSession.post(...) await asyncio.sleep(1.5) # 模拟网络延迟 # Mock返回 return { description: A fluffy white cat sitting on a windowsill., confidence: 0.92, objects: [cat, windowsill] } async def handle_message(message): if message[type] ! tool_call or message[payload].get(tool) ! vision_api: return None try: # 提取参数 params message[payload][params] image_url params[url] # 调用API result await call_vision_api(image_url) # 构造返回消息 return { id: fvision_result_{message[id]}, type: vision_result, from: vision_api_agent, to: topic:vision.result, payload: result, parent_id: message[id], timestamp: 2024-05-20T12:05:00Z } except Exception as e: # 错误处理发送错误消息 return { id: ferror_{message[id]}, type: error, from: vision_api_agent, to: topic:vision.result, payload: {error: str(e), original_id: message[id]}, parent_id: message[id], timestamp: 2024-05-20T12:05:00Z } async def main(): client OpenClawClient( base_urlhttp://localhost:8080, agent_idvision_api_agent, topics[topic:vision.request] ) await client.start_listening(handle_message) if __name__ __main__: asyncio.run(main())Step 4: 启动所有Agent并测试依次启动python user_gateway.py # 这个需要自己实现一个简单的Flask服务 python planner_agent.py python vision_api_agent.py python report_generator.py 然后用curl发送一个测试请求curl -X POST http://localhost:5000/upload \ -H Content-Type: application/json \ -d {image_url: https://example.com/cat.jpg}你会看到一条消息从user_gateway出发经过planner_agent、vision_api_agent最后到达report_generator并在终端打印出最终的报告。整个流程的每一步你都可以在各自的Agent日志中清晰地看到没有任何黑盒。5. 常见问题与排查技巧实录那些在深夜救了我命的技巧5.1 消息“石沉大海”为什么我发了消息但Receiver完全没反应这是新手遇到的第一个高频问题。别急着怀疑代码按以下顺序排查确认Agent是否真的“在线”并“注册成功”OpenClaw总线提供了一个简单的健康检查端点。在总线运行时访问http://localhost:8080/api/v1/health。如果返回{status:ok,agents:[hello_receiver]}说明hello_receiver已被成功注册。如果列表为空说明你的Receiver Agent根本没有连上总线或者agent_id拼写错误大小写敏感。确认路由规则是否匹配总线的日志是你的第一道防线。打开bus.log搜索关键词routing或match。你会看到类似这样的日志INFO [routing] Matched route: fromhello_sender, tohello_receiver, conditiontrue INFO [bus] Forwarding message msg_abc123 to hello_receiver如果没有看到Matched route说明你的routes.yaml里没有一条规则能匹配上你发送的消息的from和type。仔细检查from字段是否和Sender的agent_id完全一致when表达式里的字段名如message.type是否拼写正确。确认Receiver是否订阅了正确的Topic在receiver.py中OpenClawClient的topics参数必须包含hello_receiver这个ID如果它是点对点接收或者包含topic:*如果它想接收所有广播。如果你的路由规则是to: hello_receiver但Receiver的topics里写的是[topic:foo]那它永远收不到消息。一个快速验证方法是在Receiver的handle_message函数开头加一行print(Im alive!)然后重启Receiver看这行是否打印。如果不打印说明它根本没被总线识别为一个有效的消息消费者。排查技巧我给自己写了一个小脚本debug_bus.py它会持续向总线发送一条心跳消息并实时打印所有Agent的在线状态和最近10条消息的路由日志。这个脚本在我部署新环境时5分钟内就能定位90%的连接问题。5.2 消息“乱序”与“重复”为什么我收到的消息顺序不对为什么同一条消息收到了两次OpenClaw默认不保证消息顺序FIFO这是它为了极致性能做出的权衡。如果你的应用逻辑严格依赖顺序比如一个订单的“创建”、“支付”、“发货”消息必须按此顺序处理你需要在config.yaml中启用有序投递bus: ordered_delivery: true # 默认false但这会带来约10%-15%的性能损耗所以请仅在必要时开启。至于消息重复这几乎是分布式系统的宿命。OpenClaw采用的是“至少一次投递”At
阅读完成 · 觉得有帮助？
