【hermes多智能体协作】个人学习笔记

2026年多智能体协作框架全景图

框架	协作隐喻	核心优势	2026年状态	推荐指数
CrewAI	角色扮演	简单易用，生态丰富	快速原型首选	⭐⭐⭐⭐⭐
AgentScope	操作系统	Java支持，工程化强	企业级落地首选	⭐⭐⭐⭐⭐
MetaGPT	工厂流水线	产出质量高，流程严	代码/文档生成神器	⭐⭐⭐⭐
AG2 (AutoGen)	群聊辩论	灵活，支持代码执行	科研/探索首选	⭐⭐⭐⭐
LangGraph	精密状态机	控制力最强，可回溯	复杂业务流首选	⭐⭐⭐⭐⭐
Dify	搭积木	可视化，零代码	业务人员首选	⭐⭐⭐⭐

与LangGraph 那种"强编排"的流程图模式不同，Hermes 的多智能体协作更偏向于**"联邦制" (Federated)** 和 "自进化" (Self-Evolving) 。它的核心优势在于：不仅能让多个智能体一起干活，还能让它们把干活的经验沉淀下来，下次干得更好。

核心协作模式：Hermes 是如何"组队"的？

Hermes 的多智能体架构主要依赖以下三种机制：

子代理并行处理 (Sub-Agent Parallelism) ：主代理（Manager）可以将一个大任务拆解，分发给多个子代理同时执行，最后汇总结果。
技能联邦 (Skill Federation) ：不同角色的 Agent 可以共享或调用彼此沉淀的"技能文件"（Markdown 格式的 SOP）。
跨框架通信 ：Hermes 支持与其他框架（如 OpenClaw）的 Agent 互相发消息，组成混合战队。内部通信采用RPC通信机制。

实战场景

场景一：并行监控与情报汇总（效率型协作）

这是 Hermes 最擅长的场景，利用其并行处理能力，解决"单线程跑太慢"的问题。

业务痛点 ：你需要监控 5 个竞品的网站价格、3 个技术论坛的最新动态，如果用单线程 Agent 一个个跑，可能要半小时。现在利用主agent带领子agent的方式并行执行方式把任务做完**。Hermes 协作流** ：
1. 主代理 (Manager)：接收指令"监控竞品动态"。
2. 子代理集群 (Worker Agents) ：Manager 瞬间启动 8 个子 Agent。
  - Agent A-D：分别监控 4 个电商网站。
  - Agent E-G：分别监控 3 个技术论坛。
  - Agent H：负责监控社交媒体舆情。
3. 并行执行 ：所有子 Agent 同时调用浏览器工具进行抓取。
4. 汇总与沉淀：Manager 收集所有结果，生成一份《每日情报日报》，并推送到飞书/钉钉。
5. 进化点 ：如果某个网站改版导致抓取失败，负责的子 Agent 会自动修正抓取策略，并更新自己的"爬虫技能"，下次就不会错了。

详细流程介绍：

在 Hermes 中，实现并行监控的核心技能编排模式被称为 "扇出-汇聚" (Fan-Out / Fan-In) 。这通常通过 delegate 工具或内部的 Subagent 调度器来实现。

1. 编排逻辑架构

我们将任务拆解为三个阶段的技能流：

阶段一：规划与扇出 (Planner & Fan-Out)
- 触发技能 ：monitor_competitors
- 动作：主 Agent (Manager) 接收到指令（如"监控这 5 个网站"）。它不会自己逐个去跑，而是调用 delegate 工具。（远程智能体的控制器）
- 编排细节 ：Manager 将 5 个网址拆解为 5 个独立的任务包，每个任务包包含：目标URL、提取规则、对比基准。
阶段二：并行执行 (Worker Execution)
- 执行技能 ：web_research / browser_automation（playwright+谷歌浏览器）
- 动作：Hermes 启动 5 个独立的子进程（Subprocesses）。每个子进程加载一个独立的"浏览器环境"（如 Camoufox 隐身浏览器）。
- 关键点 ：这些子 Agent 之间互不可见 ，它们只与父 Agent 通信。这意味着它们不会互相干扰上下文，也不会因为一个网站的反爬机制导致整个任务卡死。
阶段三：汇聚与合成 (Aggregator & Synthesis)
- 汇总技能 ：data_analysis / report_generation
- 动作：Manager 等待所有子进程返回结果（或通过流式接收结果）。一旦收集完毕，它调用"写作技能"将 5 份零散数据整合成一份《情报日报》。

关于其agent团队的通信机制

内部子 Agent 通信机制：基于 RPC 的流式管道

Hermes 的子 Agent 通信不是简单的文本传递，而是基于 进程间通信 (IPC) 和 远程过程调用 (RPC) 的高性能管道。

1. 物理隔离与通道 (Transport Layer)

进程级隔离 ：每个子 Agent 都是一个独立的操作系统进程（Subprocess）。这意味着它们拥有独立的内存空间、独立的 Python 环境和独立的临时文件存储。（多实例）
通信管道 ：父 Agent 与子 Agent 之间通过 RPC (Remote Procedure Call) 通道连接。
- 命令下发 ：父 Agent 通过标准输入 (stdin) 或 Socket 向子进程发送 JSON 格式的任务指令。
- 结果回传 ：子 Agent 通过标准输出 (stdout) 将结果流式回传给父 Agent。

2. 消息协议 (Message Protocol)

通信内容通常遵循 Hermes 的内部消息协议，包含以下关键要素：

心跳与状态 ：子 Agent 会定期发送"心跳"或状态更新（如"正在打开浏览器"、"正在提取价格"），父 Agent 的监控面板可以实时显示这些进度。
工具调用透传 ：如果子 Agent 需要调用工具（如 browser.open_url），它会通过 RPC 请求父 Agent 的资源（或者直接在自己的沙箱环境中执行，取决于安全配置）。
流式返回 ：对于长文本或大数据量的监控结果，子 Agent 不会等到最后才返回，而是以流 (Stream) 的形式分块发送数据。这使得父 Agent 可以在子任务还没完全结束时，就开始预处理的逻辑。

3. 上下文管理 (Context Management)

这是 Hermes 通信机制中最精妙的一点："上下文共享但隔离"。

只读继承 ：子 Agent 启动时，会继承父 Agent 的系统提示词 (System Prompt) 和关键记忆 (Key Memories)（如你的 API Key、偏好设置）。
写隔离 ：子 Agent 在执行过程中产生的临时记忆、思考过程，不会污染父 Agent 的主上下文窗口。只有最终的"结论"会被写回父 Agent 的记忆库。这有效防止了"上下文爆炸"。

可能存在的问题

容错性 ：如果监控"竞品 B"的子 Agent 因为网站改版崩溃了，其他 4 个 Agent 不受影响，父 Agent 可以捕获异常并标记该任务失败，而不是让整个监控流程中断。
资源动态分配 ：Hermes 允许配置 max_concurrent_requests，你可以根据服务器性能动态调整同时运行的监控 Agent 数量。

避坑建议

避免"死锁" ：在设计技能时，不要让子 Agent 等待父 Agent 的确认，同时父 Agent 又在等待子 Agent 的结果。Hermes 的 delegate 通常是异步非阻塞的，但在某些配置下需要设置合理的 timeout。
数据格式标准化 ：子 Agent 返回的数据必须是结构化的（如 JSON），以便父 Agent 的"汇总技能"能直接解析。如果子 Agent 返回了一大段废话，汇总阶段会非常消耗 Token。

关于主skill 子 skill 的优化理解

流程：定时任务 A 启动子 Skill 采集 -> (未知时间后) -> 定时任务 B 启动主 Skill 汇总。
问题：
- 如果子 Skill 采集很慢（比如网络波动，平时 5 分钟跑完，今天跑了 15 分钟），而主 Skill 的定时任务在 10 分钟后准时启动，主 Skill 会读到什么？
- 它会读到"空文件"或者"旧数据"。Hermes 的主 Skill 可能会强行总结一堆空话，或者因为找不到 JSON 文件而报错崩溃。
- 结论：两个独立的定时任务之间没有"握手"机制，这是最大的不稳定因素

优化：单入口"扇出-汇聚"模式

不要拆分成两个独立的定时任务，而是只保留一个"总控"定时任务。

总控定时任务 (Manager Cron) ：
- 每天 8:00 启动。
- 动作：调用一个**"总控 Skill"**。
总控 Skill (The Orchestrator) ：
- 步骤 1 (扇出) ：利用 Hermes 的 delegate 工具，并行启动 3-5 个子 Skill（采集任务）。
- 步骤 2 (等待)：显式等待所有子 Skill 返回"完成"信号。
- 步骤 3 (汇聚) ：确认所有 JSON 文件都已生成且完整。
- 步骤 4 (总结)：调用主 Skill 的逻辑，读取所有 JSON，生成最终报告。
- 步骤 5 (发送)：发送报告并清理临时 JSON 文件。

优点：彻底解决了"时间赛跑"问题。主 Skill 只有在数据 100% 准备好后才会运作。

技术实现建议 (2026版)

如果你现在要动手搭建，建议关注以下配置：

利用 hermes gateway ：
- 配置 config.yaml 开启多通道接入（如同时开启 Telegram 和 CLI）。
配置多模型后端 ：
- Hermes 支持在一台机器上运行多个独立的智能体，每个使用不同的模型（如一个用 Qwen-Max 做逻辑判断，一个用 Ollama 跑本地小模型做简单分类），互不干扰。
关注"技能文件"管理 ：
- Hermes 的技能存储在 ~/.hermes/skills/ 目录下。在多智能体协作中，确保不同角色的 Agent 有权限读取公共技能库，这是它们协作的基础。

Hermes Agent 官方设定和最佳实践中的并发上限是 3 个子 Agent。

这并不是因为技术做不到更多，而是基于大模型行为特性的主动设计：

防止"注意力涣散" (Attention Dispersion)
- 当父 Agent 需要同时管理和汇总超过 3 个以上的子任务时，大模型的上下文窗口会迅速膨胀，导致其"注意力"分散。
- 结果往往是：父 Agent 无法精准地整合所有子任务的细节，导致最终输出的质量下降，或者遗漏关键信息。限制在 3 个是为了保证管理质量 和结果精度。
上下文窗口保护
- 虽然 Hermes 有记忆压缩技术，但如果 5-10 个子 Agent 同时向父 Agent 回传大量数据，父 Agent 的上下文（Context Window）很容易被撑爆。
- 3 个并发是一个平衡点，既能实现并行加速（如同时监控 3 个竞品），又能确保数据能被有效处理。
资源与稳定性
- 每个子 Agent 都是一个独立的 Python 进程，拥有独立的浏览器实例（如 Camoufox）和内存占用。
- 在普通的消费级硬件（如 16G/32G 内存的服务器）上，同时运行 3 个带浏览器的 Agent 已经接近负载极限。限制数量可以防止宿主机 OOM（内存溢出）。

子代理和独立agent示例核心区别对比表

维度	`delegate` 工具 (子代理)	独立 Agent 实例 (Spawn/Process)
形象比喻	临时项目组	独立外包公司
进程关系	共享进程：在同一个 Python 进程中通过线程/协程运行。	独立进程：启动一个全新的、完全隔离的操作系统进程 (`hermes chat ...`)。
生命周期	短命：随父 Agent 而生，任务结束即销毁。	长寿：可以在后台独立运行数小时甚至数天，父进程挂了它还在。
上下文/记忆	隔离但受限：有独立对话，但通常不持久化到数据库，父 Agent 只看结果。	完全独立：拥有自己独立的数据库记录、完整的会话历史和记忆文件。
工具权限	受限：通常只能使用父 Agent 分配的部分工具（如禁止递归委派）。	完整：拥有完整的工具集权限，甚至可以自己再去委派任务。
交互性	无：黑盒执行，父 Agent 只能等结果。	强：支持伪终端 (PTY) 交互，你可以随时"插嘴"指导它。
适用场景	快速并行：如同时搜 3 个网站、并行写 3 个模块代码。	长时任务：如后台跑一整晚的回归测试、独立开发一个完整功能。

避坑指南

上下文限制 ：虽然 Hermes 有记忆系统，但底层 LLM 的上下文窗口依然有限。在多智能体高频交互时，注意压缩会话历史，只保留关键决策点。
死循环风险 ：如果两个 Agent 互相等待对方输出，可能会死锁。建议在 Hermes 的编排逻辑中设置超时机制或最大重试次数。
资源消耗 ：并行运行多个 Agent 会消耗较多内存和 API 额度。建议先在本地用轻量级模型（如 Qwen-7B/14B）调试流程，跑通后再上云端大模型。

总结： 用 Hermes 做多智能体协作，核心不在于"画流程图"，而在于**"培养团队"** 。你不仅是配置它们怎么干活，更是在训练它们怎么积累经验。