从 Prompt → Context → Harness → Loop → GraphAgent 架构的第五层已来。结合我对 Hermes Agent 的优化实践拆解 Graph Engineering 的核心能力以及如何提升自己的 Agent 工程化水平。如果你还在研究怎么把 prompt 写得更好、怎么让 RAG 更精准恭喜你你已经落后了半个版本。过去两年Agent 工程化经历了四次跳跃代码Prompt 工程 → Context 工程 → Harness 工程 → Loop 工程 → Graph 工程大多数人停在第一层少数人到了第三层极少数人在第五层。今天这篇文章不聊概念只聊我在这四个月里对 Hermes Agent 做的架构级改造——把 Agent 从一条线变成一张图以及这个过程中总结出的方法论。一、为什么需要第五层先问一个问题你的 Agent 是一个脚本还是一个系统如果你的 Agent 是这样的代码user_input → LLM → tool_call → LLM → tool_call → output那它还在第二层Loop Engineering。线性循环每步依赖上一步失败就重试复杂就崩溃。真实世界的 Agent 场景需要什么代码用户有多个意图 → 路由到不同子图 → 每个子图有不同的保底策略 → 某个路径失败 → 自动走备选路径 → 恢复上下文 → 继续 → 成功 → 学习并记忆这不是一条线这是一张图。我管它叫 Graph Engineering用有向图DAG 条件分支 循环 回退来编排 Agent 的行为逻辑。二、我做了什么Hermes 的 16 节点条件图如果你看过我上一篇文章《Hermes Agent 源码拆解》你就知道 Hermes 的默认架构是一个线性 Runner。我做的第一件事就是把它拆了重构成一张图。改造前的架构代码用户输入 → 模型调用 → 工具执行 → 结果返回 →循环一个线性的 while 循环。重试加个 try-catch。分支不可能。改造后的架构代码┌─────────────────────────────────────────┐ │ 意图路由 (Intent Router) │ └────┬──────────┬──────────┬──────────────┘ │ │ │ ┌────▼──┐ ┌────▼──┐ ┌────▼──────┐ │ 研究 │ │ 编码 │ │ 写作/分析 │ └───┬───┘ └───┬───┘ └─────┬─────┘ │ │ │ ┌───▼─────────▼────────────▼────┐ │ 执行引擎 (Execution Engine) │ │ ┌─────┐ ┌──────┐ ┌─────┐ │ │ │L1重试│→│L2恢复│→│L3降级│ │ │ └─────┘ └──────┘ └─────┘ │ │ ┌─────────────────────────┐ │ │ │ Workflow Memory (7YAML) │ │ │ └─────────────────────────┘ │ │ ┌─────────────────────────┐ │ │ │ TraceID Observability│ │ │ └─────────────────────────┘ │ └──────────────┬────────────────┘ │ ┌──────────────▼────────────────┐ │ 自我演化 (Evolution Loop) │ │ 成功→存记忆 / 失败→学教训 │ └───────────────────────────────┘总共 16 个节点、3 个路由器、3 级恢复机制。核心组件1. 意图路由器Intent Router这不是一个简单的 if-else。它是一个条件节点图——根据用户输入的特征任务类型、复杂度、上下文长度动态路由到不同的子图。代码用户说写一篇关于Agent的文章 → Router 识别为「写作」类型 → 路由到 Research 子图并行调研 → 路由到 Writing 子图生成-审核分离 → 路由到 Format 子图排版合规2. 三级恢复机制Recovery Ladder这是整个系统最值钱的部分。Agent 一定会失败工具超时、API 报错、上下文溢出问题不是怎么避免失败而是失败后怎么办。级别策略代价适用场景L1 重试相同参数 timeout 加倍低网络波动、临时超时L2 恢复切换工具/方法中API 报错、工具失效L3 降级用更简单的方法完成高核心依赖不可用举个例子查股票数据L1参数不变timeout 翻倍 → 还失败 L2换数据源Sina→Tencent→ 还失败 L3向用户说明「数据不可用我给你昨天的收盘价」3. Workflow Memory工作流记忆大多数 Agent 的记忆系统只存用户信息「用户喜欢 Python」。我加了一层 工作流记忆——存的是「怎么做这个任务」。记忆类型存储内容示例用户偏好风格、习惯「用户喜欢对比表格」工作流任务步骤链「写头条→先调研→再写稿→最后审核」失败教训错误模式「web_search 在中国大陆不稳定优先用 Playwright」成功模式有效策略「并行调研效率提升 3 倍」这些存在 7 个 YAML 文件里不是向量数据库——YAML 比 embedding 更适合结构化工作流。4. TraceID 可观测性每个请求分配一个 TraceID贯穿整个图的生命周期。当某个路径失败时你能知道哪个节点失败了之前经过了哪些节点每个节点的耗时和 token 消耗这不是锦上添花——没有可观测性你就没法 debug 一张图。三、Graph Engineering 的三个核心能力说了这么多我的实践来抽象一下 Graph Engineering 到底在做什么。能力一状态机驱动的路由传统 Agent 是文本驱动的模型决定下一步。Graph Engineering 是状态驱动的——模型输出被解析成结构化状态状态机根据状态选择路径。代码文本驱动模型说我需要查一个API → 模型自己调用 tool → 模型判断结果 状态驱动模型输出被解析 → Router 检查状态「意图查询依赖None」 → 自动路由到搜索子图 → 完成后的状态触发下一步路由为什么状态驱动更好 因为可以调试。文本流是黑盒状态流是白盒。能力二容错的显式化在 Loop Engineering 里错误处理是靠 prompt 隐含的代码如果你失败了请重试一次在 Graph Engineering 里错误处理是图上的一条边代码节点 A搜索→ 成功 → 节点 B分析 → 失败 → 节点 C切换搜索源 → 成功 → 节点 B → 失败 → 节点 D降级到缓存数据容错不再是模型的义务而是架构的属性。能力三学习和演化的闭环Graph Engineering 的终极形态不是固定的图而是自演化的图。代码执行 → 记录 → 分析 → 调整 → 再执行我管这个叫 Evolution Loop代码成功路径 → 可能不够优 → 分析可不可能更短 → 调整减少一个节点 → 下次走更短的路 失败路径 → 学到的教训 → 分析为什么会失败 → 调整加一个前置检查节点 → 以后不再犯四、Graph vs Loop一张表看懂区别维度Loop EngineeringGraph Engineering控制流线性循环有向图DAG 分支 回退容错靠 prompt 描述图上显式边上下文管理全部塞窗口子图隔离 Checkpoint可观测性log 文本TraceID 节点级监控路由逻辑模型决定下一步状态机 模型共同决策记忆系统记忆对话记忆工作流 失败模式调试难度高黑盒中状态可回溯Token 效率低整段上下文高隔离上下文节省 8-12%对模型依赖高中结构兜底五、怎么开始提升你的 Agent 工程化能力理论说够了来点能带走的。第一级加一个 Checkpoint 系统不管你用的是什么 Agent 框架先做这件事给每个步骤加 Checkpoint。Checkpoint 不是日志——是可恢复的状态快照。当进程重启时Agent 不是从零开始而是从最近的 Checkpoint 恢复。代码· python# 最简 Checkpoint 系统 class Checkpoint: def __init__(self): self.db sqlite3.connect(checkpoints.db) # 7 张表sessions, nodes, traces, results, memory, errors, metrics def save(self, session_id, node_id, state): self.db.execute( INSERT INTO nodes VALUES (?, ?, ?, ?), (session_id, node_id, json.dumps(state), time.now()) ) def restore(self, session_id): pass # 恢复最近的 checkpoints第二级加一个 Recovery Ladder在你的 Agent 循环里不要只试一次。套一层三级 recovery代码· pythondef execute_with_recovery(task, level1): try: return try_execute(task) except Exception as e: if level 1: return execute_with_recovery(task, level2) # 换工具 elif level 2: return execute_with_recovery(task, level3) # 降级 else: return fallback_response(暂时处理不了)这是最简单但回报最高的改动。 一个 Recovery Ladder 可以让你的 Agent 的「可用率」从 70% 提到 95%。第三级加一个 Router当你的 Agent 有 3 个以上不同类型的任务时加一个意图路由器。用户输入 → 分类器 → 路由到不同的 Agent 配置 分类简单查询 / 深度研究 / 代码生成 / 写作 每个分类有不同的 - 系统 prompt - 工具集 - 上下文窗口预算 - 执行策略第四级加一条 Evolution Loop这是最难的一级也是回报最高的一级。代码执行后 → 分析 → 如果失败 → 记录失败模式 → 下次先查失败模式库 → 避开已知坑Hermes 有一个叫 Dojo 的模块就在做这件事。我的实现更轻量——每次成功或失败结构化成 YAML 存到工作流记忆里下次执行时自动检索。六、你可能会问的几个问题QGraph Engineering 适合小项目吗A看规模。如果你只有一个 Agent、处理一种固定任务、维护期小于 3 个月Loop 足够了。Graph 的 ROI 在系统复杂度超过某个阈值后才体现——我自己的经验是 3 个月以上的 Agent 项目才值得上 Graph。QGraph Engineering 和 LangGraph 什么关系ALangGraph 是实现 Graph Engineering 的一种框架不是唯一的选择。你可以自己画图——用 YAML 定义节点用 Python 实现路由甚至用 JSON 描述状态机。核心是思维方式不是框架。QGraph Engineering 等于 Agent 工作流编排A不是。工作流编排是线性的A→B→C。Graph Engineering 是有条件分支和回退的图。区别在于能不能应对意外——线性编排假设一切顺利Graph 不假设。Q图上节点太多会不会失控A会。这就是为什么要分级——核心节点控制在 10 个以内子图可以到 20 个。超过 30 个节点一定需要可视化监控工具。七、能带走的Agent 架构有 5 层Prompt → Context → Harness → Loop → Graph。大多数人还在第二层高手在第五层。Graph Engineering 的核心不是图是容错。把「失败后的路径」画在图上而不是写在 prompt 里。三级 Recovery Ladder 是性价比最高的改动——400 行代码可用率从 70% 提到 95%。工作流记忆比对话记忆重要——存用户偏好不如存「怎么做这个任务」。可观测性是 Graph 的前提——没有 TraceID你无法调试一张图。自演化是终极形态——固定图不是终点能自我优化的图才是。