第13章为什么要让OpenClaw和Hermes协作

本章前置检查：

□ 独立部署并运行过 OpenClaw（完成第一篇）
□ 独立部署并运行过 Hermes（完成第二篇）
□ 理解两者各自的能力边界（第1章和第7章）

本章预估总时长：2.5小时

本章难点提示：

13.2节（分工协作场景）可以通过实际案例建立直观感受，不必记忆全部场景。
13.4节（最佳搭配策略）是第三篇的核心决策参考，建议在第一遍阅读时重点标注。生产环境部署前建议再次回顾。
13.6节（协同工作原理）偏底层通信机制，如果你时间有限，可以先快速通读建立概念，遇到通信问题时再回来细读。

🎯 本章教学目标：理解OpenClaw与Hermes的设计互补性，掌握典型协作场景的判断方法，能够根据任务类型选择合适的协作模式，熟悉双Agent协同的数据交换与记忆共享机制。

13.1 设计哲学的天然互补

🎯 本节目标：从架构源头理解两者为何能够“1+1>2”。

预计时长：0.5小时

13.1.1 OpenClaw：向外求广度

OpenClaw的设计哲学可以概括为“连接一切”。它的核心能力是：

多渠道接入：20+消息平台，微信、飞书、Telegram、Discord等开箱即用。
多Agent编排：Agent Teams、子Agent、精细化路由。
确定性执行：通过AGENTS.md和SOUL.md精确定义Agent的行为边界。
人工可控：所有工具权限、记忆隔离、敏感操作审批均可配置。

如果把AI公司比作一家企业，OpenClaw就是前台接待和行政总监——它负责接电话、分派任务、开周会，但不负责深度思考。

13.1.2 Hermes：向内求深度

Hermes的设计哲学是“持续进化”。它的核心能力是：

闭环学习：自动从任务执行中提炼技能，越用越聪明。
三层记忆：跨会话持久化用户偏好、项目上下文和成功经验。
自主反思：定期自省，主动优化记忆和技能。
模型无关：支持400+模型，可任意切换云端或本地推理。

延续上面的比喻，Hermes就是坐在工位上的核心研究员——它不接电话，但能写代码、做分析、总结经验，并且越干越顺手。

13.1.3 为什么它们天然互补？

从架构层面看，两者的关注点几乎没有重叠：

维度	OpenClaw	Hermes
关注点	消息路由、会话管理、权限控制	工具执行、记忆、学习进化
擅长	确定性、可编排的流程	开放性、探索性的任务
扩展方式	插件（Skill） + 网关扩展	工具集 + MCP + 自动技能
用户交互	多渠道（群聊/私聊）	CLI、消息网关（次要）
记忆模型	主动配置的RAG + 向量库	被动沉淀的三层记忆

这种差异意味着：它们可以各自做自己最擅长的事，而把不擅长的事交给对方。

例如：

OpenClaw接到一句“帮我分析一下这个项目的代码质量”，它可以立即将任务委托给Hermes，而不是自己强行分析（它没有深度学习能力）。
Hermes在执行深度研究时，如果需要从飞书群聊中获取最新讨论记录，它可以请求OpenClaw代为拉取，而不是自己再去对接飞书API（它不擅长多渠道路由）。

龙马注：我第一次打通ACP时的感受是——OpenClaw像项目经理，Hermes像技术骨干。项目经理不会自己去写代码，技术骨干也不需要自己去接客户的电话。各司其职，效率翻倍。

✏️ 即时自测：OpenClaw和Hermes在设计哲学上最本质的区别是什么？

✏️ 自测答案：OpenClaw向外扩展广度（连接多渠道、编排多Agent），Hermes向内挖掘深度（记忆、学习、进化）。

🛠️ 实践任务（本节）：回顾你已完成的第一篇和第二篇，分别列出OpenClaw和Hermes各3个“它特别擅长而另一个做不好”的场景。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

13.2 分工协作的典型场景

🎯 本节目标：掌握4种最常见的双Agent协作模式，能根据需求选择合适的模式。

预计时长：0.5小时

场景一：多渠道指令驱动开发（飞书 → OpenClaw → Hermes → 反馈）

典型流程：

用户在企业微信群（飞书）中@机器人：“帮我重构auth.py模块，增加JWT过期自动刷新功能。”
OpenClaw接收到消息，识别出这是一个开发任务。
OpenClaw通过ACP协议将任务委托给Hermes，附带源代码仓库路径和需求描述。
Hermes克隆仓库、分析代码、编写新功能、运行测试。
Hermes将修改后的代码和测试结果通过ACP返回给OpenClaw。
OpenClaw将结果格式化后推送到飞书群，附带PR链接。

适用条件：任务需要执行代码、分析数据、调用工具链，且不需要实时回话交互。

场景二：多渠道信息聚合 + 深度研究

典型流程：

OpenClaw同时监听飞书、Telegram、Discord三个渠道中用户发送的研究请求（如“帮我研究一下AI Agent的最新进展”）。
OpenClaw将请求合并去重后，交给Hermes进行深度研究。
Hermes执行web_search、arxiv_search、github_trending等工具，生成结构化报告。
Hermes将报告摘要返回给OpenClaw。
OpenClaw根据请求的来源渠道，分别将报告推送到对应的聊天会话中。

适用条件：需要从多个来源汇总信息后再进行统一处理。

场景三：定时自动化巡检 + 异常处理

典型流程：

OpenClaw的Cron定时任务每天早上8点触发：“检查所有在线服务的健康状态”。
OpenClaw将任务委托给Hermes执行详细检查（磁盘、内存、API延迟）。
Hermes执行检查，发现某服务响应超时，自动尝试重启（通过terminal工具）。
Hermes生成巡检报告，通过ACP返回给OpenClaw。
OpenClaw将报告推送到飞书监控群，如果发现异常还额外发送告警到值班人员的Telegram。

适用条件：周期性任务，且需要根据执行结果进行智能决策。

场景四：知识库构建 + 长期记忆

典型流程：

OpenClaw在各渠道收集用户与Agent的对话（经脱敏处理）。
定时将对话记录发送给Hermes。
Hermes通过memory工具将重要信息写入MEMORY.md，并通过skill_manage自动生成可复用的技能。
当新用户提问时，OpenClaw先向Hermes查询“是否有已沉淀的相关经验”。
Hermes从记忆中检索并返回摘要，OpenClaw再结合摘要生成最终回复。

适用条件：需要长期积累领域知识、不断优化答案质量的场景。

沈飞注：在量化场景中，场景三和场景四使用最频繁。我们每小时的行情推送和风控检查属于场景三；因子库的持续构建和策略复盘属于场景四。一个简单判断标准：如果任务是“重复且规律”，用OpenClaw调度；如果任务是“需要思考和学习”，用Hermes执行。

🛠️ 实践任务（本节）：选择一个你日常工作中的场景，尝试按照上述四种模式之一设计双Agent协作流程。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

13.3 核心价值：1+1>2

🎯 本节目标：理解双Agent协作带来的实际收益，而不仅仅是理论上的“可连接”。

预计时长：0.3小时

价值一：能力和资源的专业化

OpenClaw不需要具备Hermes的深度学习和记忆能力，可以保持轻量和快速响应。
Hermes不需要处理多渠道接入和复杂的路由逻辑，可以专注于执行和学习。
各自独立迭代，升级风险隔离。

价值二：消除单点故障

如果Hermes挂了，OpenClaw仍然可以响应基础对话和路由任务。
如果OpenClaw挂了，Hermes仍可通过CLI继续执行已下发的任务（事后同步状态）。
双Agent互相监控：OpenClaw定期Ping Hermes健康端点，Hermes也可以反向检查OpenClaw。

价值三：成本优化与灵活部署

可以将OpenClaw部署在公网（处理多渠道入口），Hermes部署在内网（保护API密钥和敏感数据）。
可以根据任务类型选择不同的模型：OpenClaw用低成本模型做路由和简单问答；Hermes用高性能模型做深度分析。
可以随时替换某一侧的模型或工具集，不影响另一侧。

价值四：能力叠加而非简单堆砌

OpenClaw拥有160+社区Skill，Hermes拥有自动生成Skill的能力——两者结合后，Hermes可以“吞下”OpenClaw的Skill并进一步优化。
OpenClaw的多Agent Teams + Hermes的子Agent委托 → 构建深度达2～3层的并行任务分解能力。
共享记忆让两个Agent“互相学习”：OpenClaw学到的用户偏好可以同步给Hermes；Hermes总结的经验可以回流给OpenClaw使用。

龙马注：我最看中的是第三点——成本优化。Hermes跑DeepSeek-V4做深度分析，OpenClaw跑轻量模型做消息路由，两个用ACP串起来。月初算过，比之前只用GPT-4o节省了约40%的API费用，而且响应速度没有明显下降。

🛠️ 实践任务（本节）：列出你认为对你最有吸引力的2个价值点，并写下预期收益。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

13.4 在一人多Agent公司中的最佳搭配策略

🎯 本节目标：根据任务特征，系统化地分配OpenClaw和Hermes的职责。

预计时长：0.4小时

决策框架：三项关键判断

判断维度	偏向OpenClaw	偏向Hermes
交互方式	多渠道、群聊、短消息	单次深度任务、命令行、脚本
任务确定性	规则明确、流程固定	开放性、探索性
记忆需求	短期、无需跨会话	长期、跨会话复用

典型职责分配速查表

职责类型	推荐Agent	理由
消息渠道接入与路由	OpenClaw	原生支持20+平台，配置简单
用户认证与设备配对	OpenClaw	内置设备管理、配对流程
团队协调与任务分解	OpenClaw	Agent Teams成熟，子Agent调度灵活
代码编写与调试	Hermes	内置debugger、自动修复技能
数据分析与因子挖掘	Hermes	三层记忆，可沉淀因子方法论
定时巡检与监控	OpenClaw	Cron稳定可靠，可与渠道绑定
深度研究与论文检索	Hermes	支持长上下文、工具链完整
策略过拟合检测	Hermes	自动生成回测报告，可自省
风控监控与审计	独立Hermes	必须隔离，不与交易Agent共享记忆
交易执行（实盘）	OpenClaw	确定性高，可绑定风控约束

量化场景典型分配（第五篇预览）

研发环境：OpenClaw接收飞书研究请求 → 转发Hermes分析 → 结果回写共享数据库。
实盘环境：OpenClaw每小时拉取行情 → 调用Hermes计算因子 → Hermes返回信号 → OpenClaw执行交易 → 风控Agent（独立Hermes）实时监控回撤。

沈飞注：这个分配方案经过2个月的实盘验证，比“全部交给一个Agent”稳定得多。关键是风控Agent必须独立，不能和交易Agent共享Process，也不能共享记忆。一旦风控逻辑被污染，整个系统就失去了底线。

🛠️ 实践任务（本节）：根据你的个人业务场景，画一个职责分配表（列出任务→指派Agent）。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

13.5 协作生态速览：ACP、技能迁移与共享记忆生态图谱

🎯 本节目标：快速了解支撑双Agent协作的三大基础设施，为后续章节做铺垫。

预计时长：0.2小时

13.5.1 ACP协议——通信桥梁

ACP (Agent Client Protocol) 是OpenClaw和Hermes之间标准化的通信协议（详见第14章）。它负责：

会话映射：将OpenClaw的会话ID与Hermes的会话关联。
工具调用代理：允许Hermes通过OpenClaw间接调用某些渠道专属工具（如发送飞书消息）。
状态同步：心跳、断线重连、任务进度回调。

13.5.2 技能一键迁移——从OpenClaw到Hermes

Hermes提供了hermes claw migrate命令，可以：

迁移OpenClaw的工作区配置、Agent定义（AGENTS.md）
迁移已安装的社区Skill（自动转换为agentskills.io格式）
迁移API密钥和渠道配置

这意味者：你之前为OpenClaw积累的Skill资产，可以直接在Hermes中复用，并借助Hermes的闭环学习机制进一步优化。

13.5.3 共享记忆生态图谱——三种典型方案

方案	实现方式	适用场景
运行时传递	请求中携带必要记忆片段	简单任务、一次性调用
中间共享库	OpenClaw和Hermes读写同一SQLite/Redis	中频共享、中等数据量
外部记忆提供商	使用Hindsight、Mem0等	企业级、大规模共享

第16章将详细展开共享记忆的架构设计与最佳实践。

龙马注：这三个生态点，是双Agent协作的“三驾马车”。没有ACP，它们无法通信；没有技能迁移，你可能要在两边重复造轮子；没有共享记忆，两个Agent永远在“初次见面”。建议你在学完第14、15、16章后，再回头来读这个速览，会有恍然大悟的感觉。

🛠️ 实践任务（本节）：记下这三个生态关键词（ACP、技能迁移、共享记忆），在后续学习中随时对照。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

13.6 OpenClaw与Hermes协同工作的核心原理

🎯 本节目标：从数据交换、会话同步、记忆共享三个维度，深入理解双Agent协作的内部机制。

预计时长：0.6小时

13.6.1 消息流转全过程（以飞书消息触发Hermes任务为例）

用户发送消息
用户在飞书群中@OpenClaw机器人：“分析一下这个CSV文件的销量趋势”。
OpenClaw接收与预处理
OpenClaw的飞书渠道适配器接收消息，提取文本、文件URL、发送者ID、群ID。
Gateway根据路由规则（bindings）决定由哪个Agent处理——此处配置为“将该群的所有消息转发给Hermes协作Agent”。
ACP协议封装与发送
OpenClaw构造一个ACP请求，包含：
- session_id：映射到当前飞书会话
- task：任务描述（“分析CSV销量趋势”）
- attachments：文件URL（Hermes需要先下载）
- context：可选记忆片段（如用户偏好“以周为单位分析”）
- callback_uri：OpenClaw的回调地址，用于接收异步结果
Hermes接收并执行
Hermes的ACP服务端接收到请求，创建独立会话（不继承父会话历史）。
Agent执行：
- 调用file工具下载CSV
- 调用code_interpreter运行Python分析脚本
- 生成趋势图表和结论
结果回传
执行完成后，Hermes通过ACP将结果（文本摘要 + 图表URL）发送到OpenClaw的callback_uri。
OpenClaw发送回复
OpenClaw将结果格式化后，通过飞书渠道适配器回传给用户。

13.6.2 ACP协议的双向通信与可靠性机制

机制	说明
序列化格式	近期ACP优化为紧凑二进制格式，大幅降低长消息的传输延迟
心跳保活	每隔30秒互发Ping/Pong，超时3次后标记连接断开并触发重连
流式回调	Hermes可在执行过程中实时返回中间结果（如“正在下载文件…”“分析完成30%…”）
超时与重试	请求可设置`timeout`（默认60秒）；超时后OpenClaw可选择重试或降级
任务队列	Hermes端支持任务排队，避免瞬时高并发打爆模型API

13.6.3 数据交换类型与格式

ACP支持多种数据类型的交换，自动序列化/反序列化：

类型	说明	示例
文本/指令	自然语言任务描述	`"分析CSV销量趋势"`
文件附件	文件URL或base64编码的小文件	CSV、图片、PDF
会话上下文	JSON格式的记忆片段	`{"prefer_weekly": true}`
工具调用请求/响应	Hermes可反向请求OpenClaw执行渠道特定操作	`{"tool": "feishu_send_message", "params": {...}}`
技能定义	完整的SKILL.md内容	用于技能迁移或同步

13.6.4 共享记忆的两种工作模式

模式一：运行时传递（轻量、无持久化）

OpenClaw在请求中直接附带当前用户的关键记忆片段（从OpenClaw自己的记忆库中检索）。Hermes仅在此次请求中使用这些记忆，不会写入自己的MEMORY.md。

适用场景：一次性查询、不重要的临时偏好。

模式二：定期同步共享知识库（强一致、可持久化）

OpenClaw和Hermes通过外部共享存储（如共享目录、Redis、MySQL）读写同一份记忆数据。支持三种实现方案：

方案	实现	优缺点
共享文件系统	两者挂载同一NFS目录，直接读写MEMORY.md	简单，但并发写入需加锁
中间数据库	OpenClaw写SQLite/Redis，Hermes通过MCP查询	性能好，需维护中间件
外部记忆提供商	同时接入Hindsight或Mem0	功能强大，需付费/自托管

13.6.5 会话同步与上下文连续性

当用户与OpenClaw的会话需要切换到Hermes时，如何保持连续性？

单向传递：OpenClaw创建子会话时，将最近N条对话记录作为上下文打包发送给Hermes。Hermes将其注入系统提示词，使新会话“理解”之前的对话。
双向回流：Hermes执行完毕后，将本次对话的关键点（用户偏好、决策依据）写回共享记忆，OpenClaw下一次发请求时可以检索到。实现跨会话的“记忆延续”。

13.6.6 协作的可靠性保障

组件	保障措施
OpenClaw端	请求队列、超时重试、断线后缓存未送达消息
Hermes端	任务状态持久化（检查点）、支持断点续执行
ACP连接	自动重连、心跳保活、协议版本协商
共享记忆	乐观锁（版本号）防止并发写冲突；定期校验和修复

龙马注：13.6节看起来复杂，但在实际使用中，90%的情况下你只需要知道“ACP会把任务A发给Hermes，Hermes做完后会把结果B发回来”。至于底层二进制格式、心跳间隔这些，除非你在内网部署遇到防火墙问题，否则基本不用手动调整。但是理解超时和重试机制对排查“为什么Hermes没回复”这类问题很有帮助。

沈飞注：在量化实盘中，我们最依赖的是“异步回调”机制。Hermes跑一个因子回测可能耗时10分钟，如果用同步等待，OpenClaw会卡住，用户飞书得不到任何反馈。通过流式回调，Hermes每隔30秒发送一次进度（“回测完成30%…”），用户体验好很多。建议你在设计耗时任务时，优先采用异步+进度推送的模式。

🛠️ 实践任务（本节）：

画一张OpenClaw与Hermes协作的消息时序图（从飞书消息到结果返回）。
列举你认为最容易出问题的3个环节（如网络超时、ACPI版本不兼容等），后续在第14章配置时重点关注。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

第13章参考资料与扩展阅读

ACP协议官方文档（OpenClaw） https://docs.openclaw.ai/zh-CN/protocol/acp
ACP协议在Hermes中的实现 https://hermes-agent.nousresearch.com/docs/features/acp
Hermes Agent与OpenClaw双剑合璧：三种协作模式详解 https://developer.aliyun.com/article/1730226（15.1–15.4典型案例）
ACP vs OpenClaw原生协议：性能对比测试 https://www.volcengine.com/docs/87732/2277056（二进制优化数据）
OpenClaw 4.2 Task Flow编排系统与ACP集成 https://openclaw.com/blog/taskflow-acp
共享记忆在双Agent系统中的实践：从文件同步到Mesh Memory https://vectorize.io/articles/mesh-memory-hermes-openclaw
技能一键迁移实战：从OpenClaw到Hermes https://www.ai-indeed.com/encyclopedia/19598.html（hermes claw migrate详解）

第三篇综合任务（第13章完成后）

任务：完成以下所有检查项。

能够清晰阐述OpenClaw和Hermes各自擅长什么、不擅长什么
从13.2节的4种协作场景中，至少选择一个与自己业务相关的场景做流程设计
理解13.6节的数据交换与记忆共享原理，能够画出消息时序草图
记录下你在ACP、技能迁移、共享记忆三个生态方面的疑问，留待后续章节解答

完成后，保存一份协作设计笔记，命名为chapter13_collaboration_design.md。

龙马的评审：

“13.6节的原理讲得很细，但我建议读者不要被二进制格式、心跳保活这些底层细节吓到——在实际配置ACP时，你只需要关注openclaw.json里的acp.connections数组和Hermes侧的hermes acp listen命令。其他参数保持默认就能跑通。当你遇到连接断开、消息丢失时，再回来翻阅13.6节的机制说明，定位具体原因。

另外，hermes claw migrate命令是我在迁移旧项目时的救命稻草。建议你在正式把OpenClaw和Hermes打通之前，先在测试环境跑一遍迁移（使用--dry-run参数），确认无误后再执行真正迁移。”

沈飞的评审：

“13.4节的搭配策略表值得在团队内部推广。我们量化研发小组现在约定：所有策略研发相关的任务（因子挖掘、回测、归因分析）都通过飞书发给OpenClaw，然后自动转入Hermes；所有定时运维任务（数据备份、日志清理）直接用OpenClaw Cron。这样研发和运维的关注点被清晰分离，出错时排查路径也更短。

13.6节的异步回调与进度推送机制对量化策略的实盘监控至关重要。建议你在设计Hermes的长耗时任务Skill时，显式加入进度上报的步骤（例如调用hermes acp progress --message '...'），让OpenClaw可以在飞书群里推送阶段性进度。否则用户会以为Agent卡死了。”

下一章预告：第14章协作架构设计与ACP协议安装配置 —— 你将亲手配置ACP协议，打通OpenClaw和Hermes的连接，并学会使用hermes claw migrate一键迁移已有的Skill资产。这是让理论落地的关键实操章节。

文章版权归作者所有，未经允许请勿转载。

THE END