图工程编排模式

核心思想（来自 deer-workflow /字节跳动 DeerFlow 3.0）

Code is the plan. Agents do the work.

• TypeScript 定义合法执行路径（确定性控制流）
• Agent 只负责每个节点的语义推理（可替换的运行时）
• 分开"怎么走"和"走什么" —— 编排层和推理层解耦

为什么不用 LangChain/LangGraph

LangChain 的问题：框架太重，黑盒太多，Prompt 和编排混在一起，调试困难。

deer-workflow 的答案：

• 编排 = 普通代码（可审查、可测试、可版本控制）
• Agent = 可替换的运行时（今天 Codex，明天 Claude Code，后天 Hermes）
• 输出 = JSONL 事件流（生产和调试都能用）

Hermes 应用模式

模式 1：DAG 任务拆解

用户任务 → Hermes 拆解成 DAG 节点 → 每个节点委派给 Agent → 汇总

# 确定性编排（代码写死路径）
tasks = [
    {"goal": "研究 X 方案", "context": "..."},
    {"goal": "研究 Y 方案", "context": "..."},
]
results = delegate_task(tasks=tasks)  # 并行执行

# 确定性汇总（代码做决策）
if results[0]["feasible"]:
    path = "X"

模式 2：Phase-aware 进度

借鉴 deer-workflow 的分阶段进度：

• 每个阶段完成有明确状态标记
• 终端实时显示进度
• 失败节点可以单独重试

Hermes 中通过 todo 实现阶段管理。

模式 3：JSONL 事件流

所有 Agent 操作输出 JSONL，方便后续分析：

{"phase":"planning","status":"start"}
{"phase":"execution","node":"kicad_track","status":"done","duration_ms":2300}
{"phase":"verification","status":"fail","reason":"DRC违规"}

与 MCP 网关的结合

MCP 网关的 4 个 meta-tool 已经是图工程的前半段：

• gateway_list_servers → 能力发现
• gateway_list_tools → 节点定义
• gateway_invoke → 节点执行

差的是后半段：编排引擎。可以用这个模式补上。

参考

• deer-workflow: https://github.com/deerwork-ai/deer-workflow
• Graph Engineering Guide: https://www.aibuilderclub.com/blog/graph-engineering-guide-2026
• 字节跳动 DeerFlow 3.0: https://github.com/bytedance/deer-flow