一句话：别把 Agent 当“会说话的搜索框”。成熟工作流的关键，是把一次性对话沉淀成可复用的 Skills、可调度的 Cron、可协作的多代理与可投递的多平台出口。

目录

• 1. 为什么“会聊天”不等于“有工作流”
• 2. Hermes 是什么：可成长的 Agent 运行时
• 3. X 社区共识：四层成熟度模型
• 4. 成熟工作流的六块积木
• 5. 从 0 到 1：最小可用自动化
• 6. 三个可复用工作流模板
• 7. 质量与成本：把自动化做稳
• 8. 常见坑与避坑清单
• 9. 成熟度自检表
• 10. 总结
• 参考链接

1. 为什么“会聊天”不等于“有工作流”

很多人装完一个 Agent 后，第一周很兴奋：能搜网页、能改代码、能回消息。第二周开始发现问题：

1. 每次都从零解释：偏好、环境、项目约定说了又说。
2. 成功经验留不住：今天调通的部署流程，下周又重踩一遍。
3. 只能人在时才跑：手机上没法持续触发，夜里没法自动巡检。
4. 自动化变“加速制造垃圾”：还没验证质量，就先上定时任务。

反复强调同一句话：

Master quality at Level 1–2 before scaling. Automating slop creates faster slop.
（先把质量做稳，再谈规模；自动化垃圾只会更快生产垃圾。）

所以，成熟工作流不是“多装几个工具”，而是建立一条闭环：

执行 → 验证 → 沉淀 Skill → 定时/事件触发 → 跨平台投递 → 复盘改进

2. Hermes 是什么：可成长的 Agent 运行时

Hermes Agent 是 Nous Research 开源的 AI Agent 框架。它和“IDE 内嵌编程助手”或“单 API 聊天壳”不同，更像一个可长期运行、可自我沉淀的运行时：

能力	作用
Skills	把流程写成可复用程序文档，按需加载
Memory	跨会话记住偏好、环境、稳定约定
Gateway	一套进程接入 Telegram / Discord / 飞书 / 微信等平台
Cron	自然语言或 cron 表达式调度任务
Delegation	子代理并行拆活，隔离上下文
Profiles	多实例隔离配置、技能与记忆
Provider 无关	可切换模型与提供商，不绑死单一生态

官方定位很清楚：

It’s not a coding copilot tethered to an IDE or a chatbot wrapper around a single API. It’s an autonomous agent that gets more capable the longer it runs.

也就是说，时间越长、沉淀越多，它越像“你的工作系统”，而不是“又一个聊天窗口”。

架构总览

3. 社区共识：四层成熟度模型

一批长期使用者把 Hermes 工作流拆成了四层。这个模型比“功能清单”更实用，因为它回答的是：你现在该不该上自动化。

Level 1：单体编排器（Prototype）

• 只有一个主 Agent
• 用来试流程、验质量、沉淀失败经验
• 目标：把“能做”变成“稳定做”

适合：日常问答、代码小改、研究摘要、单次部署。

Level 2：专科 Agent（Specialists）

• 把已验证流程拆成专科角色
• 例如：Research Agent、Content Agent、Ops Agent
• 每个角色有独立 scope、skills、必要时独立 profile

适合：内容生产、代码审查、运维巡检等边界清晰任务。

Level 3：编排团队（Orchestrated Team）

• 再引入 Orchestrator
• 主控只负责路由与验收
• 专科 Agent 负责执行

适合：跨角色协作，例如“调研 → 写稿 → 排版 → 分发”。

Level 4：自动触发团队（Automated Team）

• Cron / Webhook / GitHub 事件触发
• 任务异步跑，结果投递到消息平台
• 用验证清单、静默规则、失败告警兜底

适合：晨报、盘后简报、PR 审查、夜间原型开发、站点巡检。

社区金律：不要跳级。
没在 L1/L2 验证过的流程，直接挂到 L4，只会得到“每天自动失败一次”的系统。

4. 成熟工作流的六块积木

4.1 Skills：把流程变成可调用资产

Skills 不是“提示词收藏夹”，而是带触发条件、步骤、坑点、验收标准的程序文档。兼容 agentskills.io 开放标准。

推荐结构：

---
name: morning-brief
description: Use when generating a daily AI/news morning brief for messaging delivery.
version: 1.0.0
---

# Morning Brief

## When to Use
- 每天固定时间生成简报
- 用户说“发晨报 / morning brief”

## Procedure
1. 拉取信息源
2. 过滤噪声，保留可行动条目
3. 按固定模板输出
4. 投递到目标平台

## Pitfalls
- 信息源失败时不要中断整份简报
- 空结果时输出 [SILENT]，避免噪音

## Verification
- [ ] 有日期标题
- [ ] 至少 3 条有效信息，或明确说明无新增
- [ ] 已按目标渠道格式输出

更快的沉淀方式是 /learn：把刚跑通的流程、目录、文档链接蒸馏成 Skill。

/learn how I just generated and delivered the morning brief
/learn ./ops-runbooks focus on rollback + healthcheck
/learn https://docs.example.com/api/quickstart

4.2 Memory：只记“下周还重要”的事实

Memory 适合：

• 用户偏好（语言、风格、默认执行策略）
• 环境事实（WSL / 路径 / 工具怪癖）
• 稳定约定（输出格式、平台限制）

不适合：

• 任务进度、PR 编号、临时 TODO
• 一周后就会过期的状态

一个实用原则：

如果这条信息能避免用户再次纠正你，就写进 Memory；如果只是本次任务状态，就别写。

4.3 Gateway：把 Agent 接到真实生活入口

成熟工作流的标志之一，是人不在电脑前也能触发和收结果。

Gateway 把多平台消息、会话、Cron 调度统一到一个进程：

hermes gateway setup
hermes gateway status

常见组合：

平台	常见用途
Telegram	主控、工程任务、长回复
飞书	团队协作、金融/业务简报
微信	内容创作与轻量交互
Discord / Slack	社区或团队通知

4.4 Cron：从“你记得做”变成“系统记得做”

Hermes Cron 支持：

• 自然语言：every 2h、every morning at 9am
• 标准表达式：0 9 * * 1-5
• Skill 绑定：任务开始前自动加载技能
• 投递目标：原会话 / 指定平台 / 本地文件
• no-agent 模式：只跑脚本，stdout 原样投递，省 token

示例：

# 工作日 9:00 晨报
hermes cron create "0 9 * * 1-5" \
  "生成今日 AI 与开源动态晨报，控制在 8 条以内，投递简洁可读版本" \
  --skill morning-brief \
  --name "weekday-morning-brief"

# 每小时巡检：无问题时静默
hermes cron create "every 1h" \
  "检查服务健康。若全部正常，最终只输出 [SILENT]；异常时给出症状、影响、建议动作" \
  --name "service-health-watch"

4.5 Delegation：把大任务拆成可验收子任务

主 Agent 不该把所有中间过程塞进自己的上下文。成熟做法是：

1. 主控定义目标与验收标准
2. 子代理并行执行独立子任务
3. 主控只回收可验证结果（路径、URL、测试输出）

适用：

• 并行调研
• 多仓库检查
• 长链路代码任务中的局部模块

4.6 Profiles：用隔离换清晰

当你同时做“工程开发 + 金融简报 + 内容写作”时，一个大而全的 profile 很容易上下文互相污染。

更成熟的做法：

• default：主控 / 工程
• research：投研与数据
• writer：内容创作

hermes profile create research --no-skills
hermes profile create writer
hermes profile list

Blank Slate / --no-skills 在社区很受欢迎，原因很简单：先空，再只装你真正会用的能力，上下文更干净，行为更可控。

5. 从 0 到 1：最小可用自动化

下面是一条社区验证过的最短路径。

Step 1：安装并完成基础配置

# Linux / macOS / WSL2
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# 配置向导
hermes setup
# 或一站式接入 Nous Portal
hermes setup --portal

# 健康检查
hermes doctor

Step 2：先做深度 Onboarding，再谈自动化

X 上高杠杆步骤不是“先写 20 个 cron”，而是先让 Agent 理解你：

1. 背景、目标、工作方式
2. 一天真实任务清单
3. 反问提示：

基于你对我目标与日常任务的了解，列出你最适合接手的 5 个工作流。
每个工作流写清：触发条件、输入、输出、验收标准、是否适合定时。

Step 3：先手工跑通 1 个高价值流程

推荐首个流程：

• 晨报 / 行业简报
• 代码仓库健康检查
• 内容选题 + 大纲

跑通后立刻：

/learn 把刚才这条晨报流程沉淀成 skill，包含触发条件、步骤、失败降级和验收清单

Step 4：再上 Cron

只有在“手动触发也稳定”之后，才做定时。

Step 5：每周复盘一次

检查：

• 哪些 cron 在制造噪音？
• 哪些 skill 步骤过时？
• 哪些失败模式该写进 Pitfalls？

6. 三个可复用工作流模板

模板 A：信息简报流水线（L1 → L4）

目标：每天固定时间给你一份“能扫完”的简报，而不是信息垃圾场。

关键设计：

1. 固定模板：标题、日期、Top N、行动建议
2. 失败降级：某个源挂了，其余继续
3. 空结果静默：[SILENT]，别为了“证明我还活着”刷屏

模板 B：内容生产流水线（L2 → L3）

角色拆分：

角色	职责	不该做
Research	找素材、核事实、列引用	直接发文
Writer	成稿、结构调整、语气统一	编造数据
Editor	标题、目录、合规、发布清单	重写全部事实

主控只做：

1. 分配任务
2. 验收“引用是否可点开、结论是否有证据”
3. 决定是否进入下一阶段

这比“一个 Agent 从头写到尾”更稳，因为职责边界清楚。

模板 C：工程自动化流水线（L3 → L4）

典型场景：

• PR 打开后自动审查
• 夜间跑测试摘要
• 文档漂移检查

Webhook 思路示例：

hermes webhook subscribe github-pr-review \
  --events "pull_request" \
  --prompt "审查该 PR 的安全、性能、可维护性与文档一致性。若无实质问题，最终输出 [SILENT]。" \
  --skills "github-code-review"

成熟工程流必须强调：

• 证明完成：测试输出、文件路径、命令结果
• 不允许只回一句“done”

7. 质量与成本：把自动化做稳

7.1 辅助模型分流

把“抽取、压缩、检索摘要”等机械任务交给便宜模型，把主模型预算留给决策与编排。这是长期跑自动化时最重要的省钱策略之一。

7.2 脚本采集 + Agent 决策

数据拉取尽量脚本化；Agent 只处理“判断、总结、决策、表达”。

原因：

• 脚本稳定、便宜、可测
• LLM 适合处理变化与例外，不适合当脆弱爬虫本体

7.3 验证契约（Verification Contract）

给每个自动化任务写死验收条件：

完成标准：
1. 输出必须包含日期与来源数量
2. 每条结论至少附 1 个可访问链接或原始数据字段
3. 若关键步骤失败，明确标注失败点，不得伪装成功
4. 无新增内容时输出 [SILENT]

7.4 模型与任务匹配

任务类型	更合适的策略
编排 / 复杂判断	强推理主模型
摘要 / 压缩 / 抽取	便宜辅助模型
纯巡检 / 阈值检查	no-agent 脚本
长任务并行	子代理 + 验收回收

8. 常见坑与避坑清单

坑 1：一上来就全自动

❌ 第一天创建 10 个 cron
✅ 先手工稳定 1 个流程，再自动化

坑 2：Skill 写成散文

❌ “你要聪明一点，尽量做好”
✅ 触发条件 + 步骤 + 坑点 + 验收清单

坑 3：Memory 被临时状态污染

❌ 记录“今天修了 PR #123”
✅ 记录“该仓库测试命令是 pnpm test，发布前必须跑”

坑 4：自动化没有静默策略

❌ 每小时都报“一切正常”
✅ 正常时 [SILENT]，异常时才打断你

坑 5：把“跑完了”当成“做对了”

❌ 代理说 done 就结束
✅ 要求返回可验证句柄：文件路径、测试日志、HTTP 状态、截图

坑 6：一个 profile 塞所有人格

❌ 工程、写作、投研全混一个上下文
✅ 用 profile / 专科 agent 隔离职责

9. 成熟度自检表

如果你在搭 Hermes 工作流，可以用这张表自检：

□ 1. 至少有 1 个手工验证稳定的核心流程
□ 2. 该流程已沉淀为 Skill（含 Pitfalls + Verification）
□ 3. Memory 只保存长期有效事实，不存任务流水账
□ 4. Gateway 已接通至少一个移动端入口
□ 5. 至少 1 个 Cron，且具备静默/失败策略
□ 6. 关键任务有验证契约，不只看“done”
□ 7. 高价值流程开始拆专科角色，而不是无限堆单聊
□ 8. 每周有复盘：更新 skill、关掉噪音任务
□ 9. 成本有分流：脚本/辅助模型/主模型分层
□ 10. 能说清自己处在 L1 / L2 / L3 / L4 哪一层

达到 7 项以上，通常就算“开始成熟”；达到 9–10 项，才配叫“可长期运行的工作系统”。

10. 总结

X 社区对 Hermes 的共识，可以压缩成三句话：

1. Harness 比单次模型更重要：Memory + Skills + Gateway + Cron 才是复利来源。
2. 先质量，后规模：L1/L2 没做稳，就别上 L4。
3. 自动化要会闭嘴：没有增量就静默，有问题时才升级成人机协同。

Hermes 的价值，不在于它某次回答有多惊艳，而在于你能否把它训练成：

• 记得住你的约束
• 复用得了你的流程
• 在你不在场时仍按标准执行
• 在失败时给出可验证的现场信息

如果你现在才开始，不要追求“全能数字员工”。
先做出一个每天真正替你省 15 分钟、且结果可信的自动化。
这一个跑稳了，后面的团队化、专科化、事件驱动才会自然长出来。

参考链接

1. Hermes 官方文档：https://hermes-agent.nousresearch.com/docs/
2. GitHub 仓库：https://github.com/NousResearch/hermes-agent
3. Skills 系统：https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
4. Cron 调度：https://hermes-agent.nousresearch.com/docs/user-guide/features/cron
5. Messaging Gateway：https://hermes-agent.nousresearch.com/docs/user-guide/messaging/
6. agentskills.io 开放标准：https://agentskills.io

---