一句话：别把 Agent 当“会说话的搜索框”。成熟工作流的关键，是把一次性对话沉淀成可复用的 Skills、可调度的 Cron、可协作的多代理与可投递的多平台出口。
目录
- 1. 为什么“会聊天”不等于“有工作流”
- 2. Hermes 是什么：可成长的 Agent 运行时
- 3. X 社区共识：四层成熟度模型
- 4. 成熟工作流的六块积木
- 5. 从 0 到 1：最小可用自动化
- 6. 三个可复用工作流模板
- 7. 质量与成本：把自动化做稳
- 8. 常见坑与避坑清单
- 9. 成熟度自检表
- 10. 总结
- 参考链接
1. 为什么“会聊天”不等于“有工作流”
很多人装完一个 Agent 后，第一周很兴奋：能搜网页、能改代码、能回消息。第二周开始发现问题：
- 每次都从零解释：偏好、环境、项目约定说了又说。
- 成功经验留不住：今天调通的部署流程，下周又重踩一遍。
- 只能人在时才跑：手机上没法持续触发，夜里没法自动巡检。
- 自动化变“加速制造垃圾”：还没验证质量，就先上定时任务。
反复强调同一句话：
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/quickstart4.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 晨报hermescroncreate"0 9 * * 1-5"\"生成今日 AI 与开源动态晨报，控制在 8 条以内，投递简洁可读版本"\--skillmorning-brief\--name"weekday-morning-brief"# 每小时巡检：无问题时静默hermescroncreate"every 1h"\"检查服务健康。若全部正常，最终只输出 [SILENT]；异常时给出症状、影响、建议动作"\--name"service-health-watch"4.5 Delegation：把大任务拆成可验收子任务
主 Agent 不该把所有中间过程塞进自己的上下文。成熟做法是：
- 主控定义目标与验收标准
- 子代理并行执行独立子任务
- 主控只回收可验证结果（路径、URL、测试输出）
适用：
- 并行调研
- 多仓库检查
- 长链路代码任务中的局部模块
4.6 Profiles：用隔离换清晰
当你同时做“工程开发 + 金融简报 + 内容写作”时，一个大而全的 profile 很容易上下文互相污染。
更成熟的做法：
default：主控 / 工程research：投研与数据writer：内容创作
hermes profile create research --no-skills hermes profile create writer hermes profile listBlank Slate /--no-skills在社区很受欢迎，原因很简单：先空，再只装你真正会用的能力，上下文更干净，行为更可控。
5. 从 0 到 1：最小可用自动化
下面是一条社区验证过的最短路径。
Step 1：安装并完成基础配置
# Linux / macOS / WSL2curl-fsSLhttps://hermes-agent.nousresearch.com/install.sh|bash# 配置向导hermes setup# 或一站式接入 Nous Portalhermes setup--portal# 健康检查hermes doctorStep 2：先做深度 Onboarding，再谈自动化
X 上高杠杆步骤不是“先写 20 个 cron”，而是先让 Agent 理解你：
- 背景、目标、工作方式
- 一天真实任务清单
- 反问提示：
基于你对我目标与日常任务的了解，列出你最适合接手的 5 个工作流。 每个工作流写清：触发条件、输入、输出、验收标准、是否适合定时。Step 3：先手工跑通 1 个高价值流程
推荐首个流程：
- 晨报 / 行业简报
- 代码仓库健康检查
- 内容选题 + 大纲
跑通后立刻：
/learn 把刚才这条晨报流程沉淀成 skill，包含触发条件、步骤、失败降级和验收清单Step 4：再上 Cron
只有在“手动触发也稳定”之后，才做定时。
Step 5：每周复盘一次
检查：
- 哪些 cron 在制造噪音？
- 哪些 skill 步骤过时？
- 哪些失败模式该写进 Pitfalls？
6. 三个可复用工作流模板
模板 A：信息简报流水线（L1 → L4）
目标：每天固定时间给你一份“能扫完”的简报，而不是信息垃圾场。
关键设计：
- 固定模板：标题、日期、Top N、行动建议
- 失败降级：某个源挂了，其余继续
- 空结果静默：
[SILENT]，别为了“证明我还活着”刷屏
模板 B：内容生产流水线（L2 → L3）
角色拆分：
| 角色 | 职责 | 不该做 |
|---|---|---|
| Research | 找素材、核事实、列引用 | 直接发文 |
| Writer | 成稿、结构调整、语气统一 | 编造数据 |
| Editor | 标题、目录、合规、发布清单 | 重写全部事实 |
主控只做：
- 分配任务
- 验收“引用是否可点开、结论是否有证据”
- 决定是否进入下一阶段
这比“一个 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 的共识，可以压缩成三句话：
- Harness 比单次模型更重要：Memory + Skills + Gateway + Cron 才是复利来源。
- 先质量，后规模：L1/L2 没做稳，就别上 L4。
- 自动化要会闭嘴：没有增量就静默，有问题时才升级成人机协同。
Hermes 的价值，不在于它某次回答有多惊艳，而在于你能否把它训练成：
- 记得住你的约束
- 复用得了你的流程
- 在你不在场时仍按标准执行
- 在失败时给出可验证的现场信息
如果你现在才开始，不要追求“全能数字员工”。
先做出一个每天真正替你省 15 分钟、且结果可信的自动化。
这一个跑稳了，后面的团队化、专科化、事件驱动才会自然长出来。
参考链接
- Hermes 官方文档：https://hermes-agent.nousresearch.com/docs/
- GitHub 仓库：https://github.com/NousResearch/hermes-agent
- Skills 系统：https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
- Cron 调度：https://hermes-agent.nousresearch.com/docs/user-guide/features/cron
- Messaging Gateway：https://hermes-agent.nousresearch.com/docs/user-guide/messaging/
- agentskills.io 开放标准：https://agentskills.io
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
