Hermes Agent 进阶用法：工具联动的十种实战模式

官方文档教你每个工具的用法，但不教你工具之间怎么衔接。这篇文章补上这一块——基于真实使用中沉淀出来的联动模式，不讲概念，只讲能跑通的组合。

一、为什么工具联动比单工具重要

Hermes Agent 提供了二十多种工具：memory、skill、delegate_task、cron、session_search、web_search、browser、terminal、send_message……单独看每个工具的文档，你能学会怎么调用它。但你不会知道：

• 哪些工具天然就该成对使用
• 哪些组合能替掉原本需要人工盯着的重复劳动
• 一个工具的输出怎样自动成为另一个工具的输入

这篇文章不讲”memory 命令怎么敲”，而讲”memory + cron + delegate_task 怎么串成一条自动研究管线”。所有模式均来自实际使用，能直接复现。

---

图 1：Hermes Agent 工具生态系统分层架构 — 输入层、核心层、记忆层、工具层、存储层

二、知识底座：Wiki + Cron 自动化研究管线

2.1 单用 Wiki 的问题

Wiki 是 LLM 驱动的关系型知识库。你可以往里面存论文摘要、技术概念、项目约定。但如果你只用手动触发——每次想更新 Wiki 都得自己发一条指令——那它只是一个静态笔记，和你本地的 Markdown 文件夹没有本质区别。

2.2 加入 Cron 后的变化

# cronjob 配置示意
schedule: "0 9 * * 1"        # 每周一早九点
prompt: |
  扫描 arXiv 本周 cs.RO 分类下与四旋翼动力学相关的论文。
  对每篇相关论文：
    1. 提取摘要与方法亮点
    2. 与 Wiki 现有条目做去重检查
    3. 新论文写入 Wiki，标记来源和日期
    4. 输出本周期新增条目摘要到 QQ

模式核心：

环节	负责工具
定时触发	cronjob
资料检索	web_search + arxiv API
去重判断	memory（持久事实） + Wiki 查询
结构存储	Wiki write
结果投递	send_message（QQ）

这就是自动化研究管线的雏形：你定义研究方向一次，后续的采集、去重、入库、通知全部无人值守。

2.3 关键细节

• Wiki 存的是结构化事实（论文标题、作者、arXiv ID、方法分类），不是整篇全文
• Cron 的 prompt 里要写清楚去重逻辑，否则每周都在重复入库
• 通知只发增量，不发全量——否则每周一早上被刷屏

---

三、多核并行：Delegate_task 的三种打开方式

3.1 基础用法：分派独立任务

当你需要同时分析三篇论文，每篇分析互不依赖时：

# delegate_task 并行模式
tasks = [
    {"goal": "分析论文 A 的方法、实验、局限性"},
    {"goal": "分析论文 B 的方法、实验、局限性"},
    {"goal": "分析论文 C 的方法、实验、局限性"},
]

三个子代理并行运行，各自拥有独立的上下文窗口和终端会话。主线程只接收最终摘要，不会被中间过程淹没。

3.2 进阶用法：分层委托

对于复杂分析任务，用 orchestrator 角色做二层分解：

# 顶层 orchestrator 分解任务
{"role": "orchestrator", "goal": "对比三类可微物理仿真器的优劣",
 "context": "需从建模精度、计算速度、易用性三个维度分别评估"}

# orchestrator 内部再 spawn 三个 leaf worker
# Worker 1: 评估 Brax 的性能和精度
# Worker 2: 评估 TorchSim 的性能和精度
# Worker 3: 评估 Warp 的性能和精度

Orchestrator 拿到三个子报告的摘要后，在本地做横向对比，最终只输出一张对比表给主线程。两层压缩，上下文消耗极低。

3.3 常见陷阱

• 子代理没有你的记忆。必须通过 context 参数显式传递所有关键信息（文件路径、项目结构、已知前提）
• 子代理不能问澄清问题。任务描述必须自包含，不能留”你需要的话可以问我”这种开口
• 并行数有上限。默认 3 个并发，超过的需要排队
• Orchestrator 会自说自话。子代理返回的是自述摘要，不是经验证的事实。对于涉及外部写入（上传、部署、发布）的操作，必须在主线程复验

---

四、流水线模式：Skill 链的端到端生产

4.1 Skill 不只是”模板”

单个 Skill 教你怎么做一件事（比如怎么用 fireworks-tech-graph 画架构图）。但真正的效率来自Skill 之间的自动串联。

Hermes 的 Skill 机制支持 related_skills 字段——你可以在 Skill A 里声明”我需要 Skill B 和 C 配合”。当 Agent 加载 Skill A 时，会自动感知到 B 和 C 的存在，并在需要时加载它们。

4.2 一条完整的生产链

以内容生成为例（通用的端到端生产流程，不限于某一特定平台）：

[Skill A: 研究调研]
  → related: [academic-survey-research]
  → 输出: 论文列表 + 关键发现摘要

[Skill B: 内容生成]  
  → related: [fireworks-tech-graph]
  → 依赖 Skill A 的输出作为输入
  → 生成正文 + 自动触发配图生成

[Skill C: 质量审查]
  → 检查章节完整性、引用准确性、配图无重叠

[Skill D: 发布部署]
  → 将最终产物推送到目标平台

每个 Skill 负责一个明确阶段。Agent 加载链首 Skill 后，按依赖关系逐级加载后续 Skill，形成一个完整的自动流水线。

4.3 设计要点

• 每个 Skill 只做一件事，输出一个明确的中间产物
• related_skills 声明链式依赖，不写循环引用
• 中间产物通过文件系统传递（写到固定路径），不依赖 Agent 的短时记忆
• 链尾 Skill 做最终格式化，抹平前面环节产生的格式差异

---

五、对话记忆：用 Session Search 找回两个月前的方案

5.1 Memory 不够用的场景

Memory 工具存的是持久事实——偏好、环境配置、稳定约定。它的容量有限（约 5000 字符），适合存”用户用 pytest 做测试”这类事实，不适合存”上次怎么修的那个 PX4 编译 bug，改了 CMakeLists.txt 的三行”。

后者属于会话历史——详细、冗长、但偶尔需要回溯。

5.2 Session Search 的正确用法

# 模糊搜索过去的会话
session_search(query="PX4 uxrce_dds_client 编译卡死 修复方法")
# 返回匹配的会话摘要，包含当时的操作步骤和修复代码

关键区别：

工具	适合存什么	不适合存什么
memory	稳定事实（偏好、环境、约定）	操作日志、调试过程、临时方案
session_search	完整会话历史	频繁变更的配置项
skill	可复用的操作流程	一次性的实验记录

5.3 为什么这很重要

两个月后你遇到一个类似的编译错误，你可能完全不记得当时怎么修的了。但你只需要告诉 Agent：”搜一下上次 PX4 编译卡死怎么解决的”，它就帮你找到当时的完整上下文——包括试过的失败路径，因而你不会重复踩坑。

---

六、多平台同体：同一 Agent 的多界面访问

6.1 架构

┌─────────────────────────────┐
│       Hermes Agent 核心     │
│   (同一套 memory/skill/工具) │
├──────────┬────────┬─────────┤
│ QQ 界面  │ 终端   │ Cron    │
│ (即时指令│ (长任务 │ (定时   │
│  快速回复│  开发) │  自治)  │
└──────────┴────────┴─────────┘

同一个 Agent、同一套 memory 和 skill、同一组工具——只是入口不同。

6.2 实际使用模式

• QQ：发一条简短的文字指令，Agent 立刻执行并回复。适合快速问答、触发已知流程、接收 cron 通知
• 终端：长任务开发、编译、测试。Agent 有完整的文件系统和终端访问权，和 QQ 端共享同一份 memory
• Cron：无人值守的定时任务。没有交互界面，prompt 自包含，结果投递到 QQ 或保存到文件

三种入口共享同一份 memory——你在终端里修了一个 bug 并沉淀为 skill，QQ 端立刻能用。你在 QQ 端存的偏好，cron 任务也能读到。

---

七、Cron 的四种实战模式

7.1 模式一：Watchdog（静默监控）

no_agent: true                    # 不经过 LLM，纯脚本判断
script: "check_gpu_quota.sh"      # 检查 GPU 资源余量
schedule: "0 */6 * * *"           # 每 6 小时

脚本的 stdout 只在有问题时输出（正常情况静默），Agent 只在异常时通知你。适合资源监控、服务健康检查。

7.2 模式二：周期性扫描

schedule: "0 9 * * 1"             # 每周一早九点
prompt: "扫描本周 arXiv cs.RO 新论文，筛选与四旋翼控制相关的……"
deliver: "qqbot"                  # 结果发到 QQ

LLM 驱动——需要判断、筛选、总结。适合学术扫描、新闻监测、定期报告。

7.3 模式三：数据采集链

# Job A: 采集原始数据
schedule: "0 */2 * * *"
prompt: "调用 GitHub API 获取指定仓库的最新 commit 列表，存到 ~/.hermes/data/commits.json"

# Job B: 分析数据（依赖 Job A 的输出）
schedule: "30 */2 * * *"
context_from: ["job_a_id"]        # 注入 Job A 的最新输出
prompt: "分析最新的 commit 数据，提取高频改动文件和活跃时段模式"

两个 cron job 通过 context_from 串联，形成数据管道。

7.4 模式四：定时交付

schedule: "0 8 * * *"             # 每天早上 8 点
prompt: "整理过去 24 小时内 Wiki 中新增的论文条目，生成一份简报"
deliver: "qqbot"                  # 推送到 QQ

固定时间的汇总输出。用户不需要主动查询，每天到点自动收到。

---

图 2：从 Cron 定时触发到 send_message 投递的完整工具联动管道

八、自进化：踩坑 → 沉淀 Skill → 下次自动避开

8.1 标准闭环

使用 Skill ──→ 发现步骤有误/遗漏
    │
    ▼
手动修复 + 验证通过
    │
    ▼
skill_manage(action='patch') 更新 Skill
    │
    ▼
下次使用同一 Skill 时自动走修正后的流程

这不是”Agent 自己学习”，而是你把经验编码进 Skill——最可靠的进化方式。

8.2 什么时候需要沉淀

• 一个操作踩了坑，靠一套特定步骤解决了 → 立即 patch 到对应 Skill 的 pitfalls 段
• 一个操作成功完成但没有 Skill 记录 → 创建新 Skill
• 一个 Skill 长期不用、步骤已过时 → 删除或标记废弃

8.3 Memory 的角色

Memory 告诉你环境信息（”WSL 下 github.com:22 端口常超时”），Skill 告诉你怎么应对（”用 GIT_SSH_COMMAND 绕过”）。两者配合，缺一不可。

---

九、典型案例：一条完整的联动链

以下是一条真实跑通过的联动链（领域无关，展示工具衔接逻辑）：

需求：持续跟踪某个学术方向的最新进展，每周自动汇总

链式流程：

① [Cron 定时触发]
  └→ 每周一早 9:00 启动研究任务

② [web_search + arxiv API]
  └→ 按关键词检索本周新论文

③ [delegate_task × 3 并行]
  └→ Worker 1: 提取每篇论文的方法亮点
  └→ Worker 2: 检查与 Wiki 现有条目的重复度
  └→ Worker 3: 按影响力指标排序

④ [主线程合成]
  └→ 合并三个 worker 的输出，去重，排序

⑤ [memory 去重检查]
  └→ 查询已入库论文列表，过滤已存在条目

⑥ [Wiki 写入]
  └→ 新论文按模板写入 Wiki 知识库

⑦ [skill 辅助格式化]
  └→ 调用已沉淀的格式化 skill，统一输出格式

⑧ [send_message 投递]
  └→ 增量摘要推送到 QQ：本周新增 X 篇，亮点如下……

⑨ [session_search 可回溯]
  └→ 两个月后问"上次那个方向搜到什么来着"
  └→ 直接找回当时的研究摘要

关键衔接点：

• Cron → web_search：定时任务携带具体的检索策略
• web_search → delegate_task：检索结果作为并行分析的输入
• delegate_task → memory：去重判断依赖持久事实
• memory → Wiki：确认新条目后才写入
• Wiki → send_message：只投递增量摘要

---

十、搭建清单：从零跑通第一条链

10.1 前提

• Hermes Agent 已安装并配好至少一个模型 Provider
• 至少一个消息平台已接入（QQ、Telegram 等）
• 文件系统和终端可用

10.2 最小可行链

目标：每天自动查一次 arXiv，新论文通知到 QQ。

第一步：验证单个工具

# 确认 web_search 可用
web_search "site:arxiv.org quadrotor control 2026"

# 确认 send_message 可用  
send_message(action="list")  # 查看可用平台

第二步：创建 Cron Job

name: "arXiv 日扫描"
schedule: "0 9 * * *"                           # 每天早九点
prompt: |
  检索 arXiv 上今天新增的 quadrotor dynamics 相关论文。
  对每篇论文提取：标题、作者、arXiv ID、核心方法。
  格式化为简短列表。
deliver: "qqbot"                                # 结果发 QQ

第三步：测试运行

cronjob(action="run", job_id="<job_id>")

确认 QQ 收到消息后，这条链就跑通了。

10.3 渐进扩展

• 加入 memory：记录已通知过的论文，下次去重
• 加入 Wiki：把论文入库，形成可检索的知识库
• 加入 delegate_task：论文多时并行分析
• 加入 skill：沉淀格式模板，统一输出风格

每次只加一个工具，确认跑通再加下一个。

10.4 日常维护

• 定期检查 cron job 的执行日志
• 工具 API 变更时更新对应 skill
• 新发现的坑及时 patch 到 skill 的 pitfalls 段

---

图 3：高频工具联动配对 — 箭头标注了典型的协同模式

工具联动速查表

输入工具	输出工具	衔接方式	典型场景
web_search	delegate_task	搜索结果作为并行分析输入	多论文同步分析
delegate_task	memory	分析结论写入持久事实	论文入库去重
memory	web_search	已有知识指导新检索策略	增量研究
cron	web_search	定时触发检索	自动扫描
cron	send_message	定时投递结果	每日简报
terminal	skill_manage	踩坑修复 → 沉淀 skill	自进化
session_search	terminal	找回历史修复方案 → 直接复用	避免重复踩坑
wiki	send_message	知识库增量通知	研究周报
todo	delegate_task	任务拆解 → 并行执行	复杂项目
skill A	skill B	related_skills 链式加载	端到端流水线

---

关键原则

1. 工具输出即接口。每个工具的输出如果能被另一个工具直接消费，它们就有联动价值
2. 持久化优先。Memory 和 Wiki 存事实，Session Search 存历史，文件系统存中间产物——不要在 Agent 的短时记忆里靠”上下文”传递关键数据
3. 先跑通，后扩展。最小可行链（两个工具串联）验证通过后，再加第三个。不要一次串五个
4. 坑即 Skill。每踩一个坑就 patch 到对应 skill，下次自动避开
5. Cron 要可观测。定时任务必须把关键结果投递到你能看到的地方，否则跑错了你都不知道