多智能体协作通过消息传递实现松耦合组合

核心结论：单个 Hermes Agent 就是一名顶尖的“万能操作员”，但生产级任务从来不是一个人的战斗。想让多个 Agent 真正协作而不互相踩脚，关键不是把代码焊死在一起，而是让它们通过消息传递实现松耦合组合——像专业团队一样各司其职，靠标准协议而不是内部 API 交换任务与结果。

2026 年 5 月，Hermes Agent 社区中出现了一个标志性的 Issue（#27528）：一位用户希望让 MCP 客户端像派发一次性任务一样调用 Hermes Agent，却发现——Agent 根本收不到这个“外部”提示。因为 Hermes 的网关和外部桥接进程之间没有直接 IPC 通道，天然隔离了内部状态。这看似是限制，实则揭示了多智能体协作中一个被严重低估的真理：好的协作架构，必须尊重 Agent 的自治边界。强行让两个 Agent 共享内存、互相调用内部方法，只会让你的系统退化成一座一碰就倒的纸牌屋。

因此本章不会教你如何“把两个 Agent 黏在一起”。我们会从通信协议设计、拓扑模式和冲突解决三个维度，厘清在 Hermes 生态中构建多智能体系统的可行路径。每一条建议都源自当前的源码设计哲学与社区实践，确保你搭出来的不是临时脚手架，而是能独立演进的 Agent 舰队。

一、现象与背景：单体 Agent 的“全能悖论”

截至 Hermes Agent v0.14.0，一个单实例 Agent 已经具备记忆系统、工具调用和多终端后端。它能写代码、能操作 UI、能自我复盘。但当任务复杂度跨过临界点——例如你需要同时处理“实时监控服务器日志、根据异常内容生成修复计划、在仿真环境里验证计划、最后推送变更到生产”，单一 Agent 就会陷入上下文过载、工具冲突和记忆干扰的三重困境。

这在多智能体领域被称为“全能悖论”：Agent 既要保持深度推理，又要保持广域操作，结果往往是两边都不讨好。从社区实践看，分裂成多个专职 Agent，让它们通过消息传递协作，成为当前最优解。

二、核心维度分析

2.1 Agent 间通信协议设计：消息格式、握手与任务委派流程

多 Agent 协作的第一个工程问题就是“它们说什么语言”。当前 Hermes Agent 内部并没有内置一套专有的多 Agent 通信协议，但这恰好倒逼出一种健康的设计：通信协议与 Agent 实现解耦。

消息格式定义

目前社区涌现出两种主流消息封装方式：

解读：从当前调研资料看，A2A 协议正在成为跨平台多智能体通信的事实标准，Hermes 社区已有成员通过 Skill 机制实现了 Hermes 到外部 Agent Zero 的 A2A 桥接。这意味着你可以用相同的消息格式，让 Hermes 与任何支持 A2A 的 Agent 对话，而不用为每个对手方写适配器。

握手机制与任务委派

松耦合的一个核心原则是“先查询能力，再委派任务”。一种经过验证的流程如下：

1. 协调 Agent（或外部调度器）向候选 Worker Agent 发送 能力查询消息（capability_inquiry），期望返回该 Agent 的可用工具集、当前负载与专长描述。
2. 协调者根据回复决定委派，发送 任务委派消息（task_delegation），包含任务描述、输入数据引用、期望输出格式和回调队列。
3. Worker Agent 将任务写入内部待办，返回确认（ack），然后独立执行。
4. 完成后，Worker 将结果推送到预先约定的 结果交付地址（可以是消息队列 Topic、HTTP Webhook 或共享存储路径）。

这一流程直接规避了 Issue #27528 里暴露的死结：不必要求 MCP 客户端直接“侵入” Agent 的提示流，而是通过一套标准的外部握手协议，把任务送达边界，由 Agent 自主决定何时领取、如何执行。

2.2 主从模式与对等模式：对比不同拓扑的适用场景及配置示例

当你有了通信协议，下一个问题是：这些 Agent 之间该摆成什么队形？

主从模式（Orchestrator-Worker）

协调者掌控全局任务拆分与决策，Worker 只负责执行并返回结果。这是当前 Hermes 多 Agent 实践中的主流模型。

适用场景：

• 确定性业务流程，如 ETL 流水线、代码审查与测试链路。
• 对执行顺序有严格要求的任务。

配置示例（概念级）：

orchestrator:
  agent_id: "lead-01"
  worker_agents: ["code-checker", "test-runner", "doc-writer"]
  routing_rules:
    - when: "new_commit"
      delegate_to: "code-checker"
    - when: "code_check_pass"
      delegate_to: "test-runner"
      on_failure: "lead-01.review"

优势在于调度逻辑集中，易于监控和重试。代价是协调者本身可能成为单点瓶颈和错误放大器。

对等模式（Peer-to-Peer）

每个 Agent 都可以发现其他 Agent 并直接发起协作，没有固定领导。这适用于探索型任务——例如多个 Agent 各自研究一个子课题，定期通过“讨论消息”交换发现，由共识算法决定最终答案。

适用场景：

• 多视角推理（一个分析财务，一个分析法律，二者对等辩论）。
• 弹性任务市场（Agent 可以根据自身专长“抢单”）。

这种模式在 Hermes 中可以通过 Pub/Sub 消息总线 实现：每个 Agent 订阅自己感兴趣的话题，当别人发布带有特定标签的消息时，它会自己决定是否参与。松耦合程度极高，但也带来冲突解决和共识的难题（见 2.3）。

对比表格

2.3 冲突解决与共识：如何处理两个 Agent 的记忆不一致或工具调用冲突

当多个 Agent 持续运行，矛盾几乎不可避免：Agent A 记住文件在 /data/v1，Agent B 却把它移到了 /data/v2；或者两个 Agent 同时调用同一个部署工具，导致状态损坏。

冲突的根源

1. 记忆层割裂：Hermes 每个实例有自己独立的记忆层（短期工作记忆 + 语义记忆 + 过程记忆），如果不做显式同步，Agent 之间对世界的认知会逐渐分叉。
2. 共享资源竞争：多个 Agent 操作同一文件系统、数据库或 API 端点时，没有锁机制就会碰撞。

解决策略（从简单到复杂）

策略一：事实来源单一化（Single Source of Truth）
不要试图让 Agent 的记忆保持一致。相反，强制所有 Agent 将可变状态写回一个共享事实存储（如 Git 仓库或一个消息日志），并在做决策前重新读取。这样就变成：记忆不一致没关系，决策那一刻的依据是一致的外部事实。

策略二：不可变任务日志 + 事件溯源
把所有任务指令和结果都写入一个只能追加的日志（类似 cron 作业存储的设计）。任何 Agent 的状态都可以通过重放日志重建。这解决了“谁在什么时候做了什么”的审计问题，也能在冲突发生时回溯因果链。

策略三：乐观并发 + 冲突检测
对于工具调用，可以让多个 Agent 并行尝试，但每个操作都带上预期版本号。如果底层资源版本已变，操作自动失败，转由协调者重新决策。这在数据库领域是成熟模式，可以直接搬用到 Agent 工具层。

解读：Hermes Agent 的现有“周期性复盘”机制（Nudge）在这里可以发挥奇效。你可以让 Worker Agent 在感知到冲突或失败时，不直接处理，而是生成一个复盘请求交给协调者，由协调者统一决策——把局部冲突升华为全局学习契机。

三、结论对比表：怎么选协作模式？

关键行动指南：

1. 起步阶段永远使用主从模式配合 A2A 协议，将每个 Agent 的工具集和能力写进 manifest 中。
2. 把任务指令和结果写进不可变日志（哪怕是简单的 SQLite 表），用事件溯源思维记录协作全流程。
3. 永远不要跨 Agent 共享内存对象，只通过消息传递状态——这是松耦合的底线。

四、按场景推荐：可操作的落地路径

场景 1：代码审查流水线（半天可搭建）

• 使用 lead-01 作为协调 Agent，它监听 Git Webhook 事件。
• code-checker Worker 订阅 A2A 的 code_review_request 消息，执行静态检查，结果写回 A2A 回调队列。
• 配置一个简单的路由脚本：如果静态检查通过，协调者自动给 test-runner 发消息。
• 整个链路状态全部追加到 audit.log 文件中，供事后回溯。

场景 2：多视角研究报告（实验性，适合探索）

• 搭建轻量消息总线（如 Redis Pub/Sub），为每个领域 Agent（法律、财务、技术）创建不同话题。
• 一个协调 Agent 发布初始问题，各专家 Agent 独立调研，每 5 分钟在“讨论”话题中发布一条结论消息。
• 协调者在收到所有轮次消息后，依据预设的多数投票或置信度权重生成最终报告。
• 如果两个 Agent 直接矛盾，协调者再发起一个“辩论轮”，要求各自提供证据引用。

场景 3：对既有系统的 MCP 集成（利用现有基础设施）

• 如果公司已有 MCP 工具生态，可以利用社区讨论中的 agent_task 思路（待观察官方实现）——将任务包装成一次性的 cron 作业写入共享存储，让目标 Agent 自行拉取。
• 关键：不要尝试让 MCP 客户端直接桥接 Agent 网关，走文件或数据库介导方式，保持桥接进程与网关的天然隔离。

现实检验：从社区实践看隐藏的坑

截至当前调研资料（2026 年 5 月 – 6 月），社区明确暴露出的问题包括：

• 桥接与网关无直接通道：如果你强行用某种方式绕过，可能破坏 Agent 的审批状态机，导致安全风控失效。
• 一次性作业的生命周期管理：提案中“运行一次后自动删除”的 cron 作业尚需额外实现，如果残留在共享存储中，可能导致重复执行。
• Agent 记忆的独立性：Hermes 的记忆模块本就是给单实例设计的，多 Agent 场景下你需要在记忆层之上自建一层共享事件索引，而不是幻想有一个“全局共享记忆池”。

过渡到下一章

多 Agent 舰队已经就绪，但它们发出的所有指令、产出的所有知识，都还运行在你指定的那几个公开模型上。如果企业安全策略要求你必须使用私有的、部署在内网的大语言模型怎么办？下一章 “自定义 Provider 接入自有模型只需实现抽象接口” 会告诉你，Hermes 是如何通过一个极简的 Provider 抽象，让你把任何模型——无论是自研的还是微调的——无缝嵌进已经建好的 Agent 架构里。这艘舰队，从此可以驶向你自己的海域。