我在 Hermes 上叠了一层自定义编排，然后拆了

一次没必要的过度工程。Hermes 本身没错，是我把它当成了它不擅长的东西。

一、先说结论

Hermes 是好工具。它擅长做 AI 入口——对话、记忆、Skill、调工具。 Hermes 不擅长长任务——记忆紊乱、跨会话上下文丢失。

我这两周犯的错不是”用了 Hermes”，是—— 明明发现了它的短板，不是把长任务交给专业工具（工作流引擎），反而在 Hermes 上叠加一层自定义协议去”补”这个短板。

叠出来的东西：sprint_contract、feature_list、双 Reset 机制、pending_eval 防丢字段、落盘顺序铁律、YOLO 模式、4 个 P0 Hook……

这些不是 Hermes 的设计。是我自己加的补丁。

正解是什么？

让 Hermes 做它擅长的事，LLM 搞不定的活交给工作流引擎。

二、事情怎么开始的

起点很朴素

我想做一件事：输入主题，比如”Claude Code 最佳实践”，AI 自动帮我产出文章、PPT、口播、视频。

流程很长：

主题 → 搜文档 + 下载 100 个 B 站视频 → 蒸馏 → 入库
     → 生成文章 → PPT → 口播稿 → TTS → 合成视频

端到端可能几小时到十几小时。

Hermes 出场

我先装了 Hermes（Nous Research 开源的 AI Agent）。它的定位很清楚：

随时唤醒的对话入口（TUI / 飞书 / Telegram 等）
自我改进的 Skill 系统
跨会话的用户画像记忆
内置 Cron、子 Agent 并行

Hermes 本身是个相当成熟的个人助手。短任务它做得很好：总结文章、调 MCP 工具、对话澄清、定时提醒——这些都没问题。

问题出在哪里

但我要跑的”主题 → 视频”这种长流程，Hermes 明显搞不定：

跑到后半段记忆乱了（前面做过什么记混）
上下文撑不住（单轮输入就膨胀到 10k+ token）
失败了没法优雅重试
审批点要等跨天根本等不到（会话早失忆）

这时我该做的选择：承认”长任务不是 Hermes 的主场”，把它交给专业工具。 我实际做的选择：在 Hermes 上叠加一层自定义协议，把它当成工作流引擎用。

后面的事就是连环爆。

三、我叠的那层有多复杂

为了让 Hermes 承担它不该承担的编排职责，我加了：

我加的机制	为了解决什么	真实情况
sprint_contract.json	给 Planner 和 Generator 立协议	把本该是函数签名的东西写成了 JSON schema
feature_list.json 作 Source of Truth	跨 session 不丢状态	土法造了一个 event log
双 Reset 机制（Hermes + CC feature）	LLM 上下文会满	给”LLM 当编排”的根本问题打补丁
pending_eval 字段	Reset 前没落盘的决策别丢	给补丁再打补丁
落盘顺序铁律（handoff → context_state → runtime_state）	事务性保证	手动模拟数据库事务
YOLO 模式 + abort 回滚	自动推进 + 出错回滚	手动写了一个 saga
4 个 P0 Hook	AGENTS.md 文字约束不住 Claude Code	LLM 不守规矩，只能硬拦
Generator/Evaluator 角色分离	防止 Hermes 自己越权干活	Prompt 工程约束 LLM 职责

光维护这套协议本身的代码，已经比业务代码还多。

四、真正的病根

某天晚上盯着架构图发呆，突然想通：

我在用 LLM（Hermes）当状态机，然后用一堆工程手段把它约束成确定性系统。

这不就是荒谬吗——

我加的机制	真正想要的是
双 Reset + handoff	一个有持久化的状态机
pending_eval 防丢	事务性写入
落盘顺序铁律	ACID
YOLO + abort	编排引擎的 saga
4 个 P0 Hook	函数边界
sprint_contract	一个 Workflow 输入类

这些能力工作流编排领域 20 年前就有了。我非要用 Hermes + Prompt + 文件协议重新发明一遍，而且发明得还不如前辈。

五、判据只有一条

回到正确的分工问题。我过去想复杂了——纠结”几步算重任务”、“几分钟算长任务”——这些都没意义。

真正有用的判据只有一条：

LLM 一次能搞定的 → Hermes 自己干 LLM 搞不定的 → 交给工作流引擎

LLM 搞不定的典型表现：

记忆紊乱（任务太长记不住前面做了什么）
上下文丢失（跨会话忘了之前的状态）
并发混乱（同时要协调几十个任务做不好）
重试无序（失败了不知道从哪续上）
跨天失忆（中间要等就失联）

出现上述任何一个，就该下放给工作流引擎。

六、2026 年的正解：五层分工

用户
  ↓
Hermes（入口层）
    ├─ 轻任务直接干（LLM 搞得定的）
    └─ 重任务 delegate（通过 MCP）
         ↓
Temporal MCP Server（桥梁）
         ↓
Temporal（系统编排层：长流程/并行/HITL/强可靠）
    └─ Activity 内部
         ↓
LangGraph（Agent 编排层：某些节点需要 LLM 循环决策时用）
         ↓
Anthropic SDK / MCP Tools（LLM 应用层）
         ↓
Langfuse（全链路 LLM trace / cost / eval）

每一层各自擅长

层	擅长	代表工具
入口层	对话、记忆、Skill、随时唤醒	Hermes
系统编排	跨天流程、大量并行、HITL、强可靠	Temporal
Agent 编排	LLM 循环用工具、反思改进、多 Agent 协作	LangGraph
LLM 应用	模型调用、工具抽象	Anthropic SDK + MCP
可观测	Token / trace / eval / cost	Langfuse

这五个不是竞品，是栈。

一个妙的副作用：Hermes 反过来能运维 Temporal

把两者通过 MCP 打通后，Hermes 不仅 delegate 任务给 Temporal，还能通过 MCP 反过来查 / 启动 / 审批 / 重试 Temporal 的 Workflow。

也就是说 Hermes 同时扮演三重角色：

用户入口：对话、通知
轻任务执行者：搜 vault、调 MCP
Temporal 的运维客户端：自然语言操作工作流

这不是我设计出来的，是MCP 解耦后自然长出来的能力。

七、Hermes ↔ Temporal 的协作原则

基于这两周的经验，确定了几条协作原则：

所有用户触达走 Hermes。审批通知、完成通知都是 Temporal 的 Activity 调 Hermes 的 MCP 工具，再由 Hermes 推到飞书/TUI。用户看到的通信通道是统一的。
Hermes 启动 Workflow 立即返回。不阻塞会话。拿到 workflow_id 就回复用户”已启动，完成时告诉你”。长流程不占 Hermes 会话。
Hermes 不管 Workflow 状态。状态全在 Temporal 里。要查就通过 MCP 的 query_status 问一下，不自己维护。
LLM 搞不定的事一律下放。不要再在 Hermes 上叠协议救它。
叠加的那套协议全部拆除。sprint_contract、feature_list、双 Reset、YOLO、4 个 Hook——全拆。保留的只是其中的概念（DAG 拆解、acceptance、checkpoint 三类型），换成 Temporal 原生的实现。

八、这两周的认知收益

1. 不要在错误的工具上打补丁

我的错不是”用 Hermes”，是”发现了它的短板还硬要让它做”。

识别一个工具的能力边界比”怎么用这个工具”更重要。 边界外的活，换工具比打补丁便宜 10 倍。

2. 抗崩比聪明重要

Hermes + 我叠加的那套协议，设计得很”聪明”——会自我反思、会 Reset、会 YOLO。

但它不抗崩。跑 3 小时的任务，中途出一次意外整个 sprint 就乱套。

Temporal 设计得很”笨”——Workflow 就是一段代码，Activity 就是函数。

但它极其抗崩。进程杀了重启、机器宕机、网络断连，回来自动续上。

生产环境里，“笨但稳”远比”聪明但脆”有价值。

3. 复杂度守恒

系统总复杂度不会消失，只会转移。

叠加协议的方式 → 把复杂度堆在”文件协议 + Prompt 约束 + Hook 硬拦”上（概率性、不可预测）。

换工作流引擎 → 把复杂度转移到”学 Temporal + 写 Workflow 代码”上（确定性、可 debug）。

选可驾驭的复杂度，不选漂移的复杂度。

4. 不要否定热门工具，要搞清它的定位

写这篇文章的草稿时我本来想连 LangGraph 一起批判（“都是 LLM 编排嘛”），后来想清楚了——LangGraph 在 Agent 级编排上无可替代。

它不适合做跨天的系统编排，但它就是”LLM 自主选工具 + 循环决策”这类场景的最佳工具。

同样的道理：Hermes 不适合做长流程编排，但它就是 AI 对话入口和 Skill 管理的好工具。

不要因为工具在某个场景不合适，就全盘否定它的价值。

5. 工具栈是分层的，不是竞品关系

不要问”用 A 还是用 B”。问”这一层该用什么”。

入口 → Hermes
系统编排 → Temporal
Agent 编排 → LangGraph
LLM 应用 → Anthropic SDK + MCP
可观测 → Langfuse

五层各司其职，没有谁代替谁。

九、接下来的路线

拆掉叠加协议。sprint_contract、双 Reset、pending_eval、YOLO、4 个 Hook 全部移除。
用 Temporal 作为外层骨架。先跑通最简 Pipeline：主题 → 下载 → 蒸馏 → 入库。
写 Temporal MCP Server。Hermes 和 Temporal 的桥梁——同时也让 Claude Code 能直接操作工作流。
LangGraph 按需引入。Research Agent（LLM 自己选搜索源）、文章生成（Critic-Writer 反思）这种节点才用。蒸馏、TTS 这种固定流程坚决单次 LLM。
Langfuse 全链路接入。成本、token、prompt 质量一起管。
HITL 用 Signal。Temporal 的 Activity 调 Hermes MCP 通知用户 → 用户回复 → 转 signal → Workflow 继续。

详细路线：study/temporal-agent/implementation-plan.md。

十、一句话

如果你发现自己在给一个工具”叠加协议”来救它的短板——停下来。 工具的能力边界不是靠打补丁扩展的。 边界外的活，换工具比打补丁便宜 10 倍。
Hermes 擅长对话入口，就让它做入口。 Temporal 擅长系统编排，就让它做编排。 LangGraph 擅长 Agent 循环，就让它做循环。 分层才是 2026 年的正解。

两周前装 Hermes，以为找到了 Agent 架构银弹。 两周后发现自己在用 LLM + 文件协议重发明工作流引擎。 承认错得快，比嘴硬继续打补丁强。

写于 2026-04-23 晚 被拆掉的叠加协议：github.com/zzyong24/superAgent（仓库会保留，但那套协议会清掉） 下一阶段：Hermes 当入口 + Temporal 当编排 + LangGraph 按需嵌入 + Langfuse trace 全链路 详细落地路线：study/temporal-agent/implementation-plan.md