随着 AI Agent 从概念走向实际应用，一个问题开始浮现：为什么很多看似强大的 Agent，依然无法稳定完成复杂任务？
答案可能并不在模型能力，而在系统架构。
有 AI 开发者 Ichigo（@iiiichigo_chan）围绕AI Agent 工程化中的核心挑战，提出了“Graph Engineering（图工程）”这一方法论。
他认为，传统 Prompt Engineering 关注的是“如何让模型回答得更好”，但真正可靠的 Agent 系统，需要解决的是任务如何拆解、信息如何流转、错误如何恢复，以及哪些环节需要人工介入。
他指出，现实工作并不是简单的“研究—分析—写作”线性流程，而是包含并行任务、条件分支、验证机制和失败处理的复杂系统。
Graph Engineering 的核心，就是在调用模型之前，先设计 AI 工作流的结构：让代码处理确定性规则，让模型处理不确定性推理，通过 State（状态）、Nodes（节点）、Edges（边）和 Gates（门）构建可控的 Agent 网络。
结合 AI 产品研究案例，他指出了如何通过独立信息收集、证据验证、人工审核和最终生成等节点，降低 Agent “自我强化错误”的风险。
他还强调，优秀的 Agent 系统不应围绕“成功路径”设计，而应围绕失败、重试、降级和停止机制设计。
以下为文章全文——
《Graph Engineering：构建能够分支、验证、恢复和停止的 AI Agent 实战指南》
你的 Agent 完全按照提示词执行，但它仍然失败。
一个研究员漏掉了关键来源，第二个研究员重复了同样的错误，审核者看到一份看起来很专业的答案，于是批准了它。
等结果交到你手里时，已经没人能解释，到底是哪一个决策污染了整个流程。
这不是 Prompt 的问题，这是控制流（Control Flow）的问题。
Graph Engineering（图工程），是一种在让模型执行任务之前，先设计 AI 工作流程结构的方法。
你需要提前决定：
- 哪些任务可以并行执行；
- 哪些任务必须等待；
- 哪些证据需要在步骤之间传递；
- 失败后应该流向哪里；
- 哪些决策仍然需要人类参与。
模型负责推理，而图（Graph）决定推理如何变成真正的工作。
对话掩盖了系统架构
聊天让所有任务看起来都是线性的：研究 → 分析 → 写作 → 审核，但真实工作很少是这种形态。
比如，产品研究和价格研究可以同时进行，安全审查不应该共享写作者的假设，失败的来源验证应该返回研究阶段，而不是重新启动整个任务。
再比如，高风险操作可能需要人工批准，而普通任务可以继续自动运行。
一旦这些关系变得重要，一段很长的对话就不再是正确的抽象方式。
Anthropic 提出了一个非常有用的区分，Workflow（工作流）遵循预定义的代码路径，而 Agent（智能体） 可以在运行时自行选择流程和工具。
而 Graph Engineering 可以将两者结合，即将确定性的决策交给代码，将不确定性的决策交给模型。（来源：Anthropic《Building effective agents》）
这也是第一条规则，即不要让 LLM 决定那些普通代码已经知道答案的问题。
例如，如果三个任务彼此独立，就同时启动三个任务；如果评分低于 0.8，就进入审核；如果重试次数达到 3 次，就停止。
这些都是图的规则，而不是推理任务。
一个有效 Graph 的四个组成部分
你不需要学习复杂的图论，你只需要四个东西。
1. State（状态）
State 是聊天窗口之外，任务真正拥有的记忆。
它应该保存工作流恢复和路由所需的信息：
- 原始需求；
- 收集到的证据；
- 节点状态；
- 重试次数；
- 审批结果；
- 预算；
- 最终产物。
不要把整个聊天记录当作 State，大部分对话内容只是无用的信息残留。
2. Nodes（节点）
一个 Node 负责一个边界明确的任务。
例如：
collect_pricing
是一个节点。
verify_claims
是一个节点。
write_report
是一个节点。
但“研究所有内容，判断重点，写报告，并确保准确”，不是一个节点。它实际上是一个隐藏的工作流，被塞进了一条 Prompt。
3. Edges（边）
Edge 回答一个问题：下一步允许执行什么？
有些 Edge 是固定的：证据完成 → 写作
有些 Edge 根据状态变化：
证据不足 → 再次研究
来源冲突 → 人工审核
预算耗尽 → 停止并返回部分结果
4. Gates（门）
Gate 的作用，是阻止错误继续向下传播。
它可以是：
- 测试；
- Schema 验证器；
- 权限检查；
- 确定性规则；
- 评估模型；
- 人工批准。
没有 Gate 的 Graph，只是一个更快传播错误的方法。
围绕失败设计 Graph，而不是围绕成功路径
大多数流程图展示的是，“事情顺利完成时会怎样”。
但生产系统真正重要的是，“失败时怎么办”。
在加入 Agent 前，为每个关键节点定义五种结果：
Pass（通过）
输出满足要求。
Retry（重试）
当前节点可以根据明确反馈修复问题。
Reroute（重新路由）
另一个专家或工具更适合处理。
Escalate（升级）
必须由人类做决定。
Stop（停止）
继续运行会浪费成本或制造风险，这会改变 Prompt 的设计方式。
不要问模型，“这个结果好吗？”，而应该让验证器返回：
{
"decision": "retry",
"reason": "Two revenue claims have no primary source",
"target": "collect_company_data"
}
这个输出有价值，因为 Graph 可以直接执行下一步动作。
Anthropic 建议让 Agent 基于环境反馈运行，并设置最大迭代次数等停止条件。原因很简单，Agent 的错误会不断累积。
一个薄弱假设，会成为下一步的上下文，然后又成为后续步骤的“证据”。（来源：Anthropic《Building effective agents》）
一个真实研究任务的 Graph 示例
假设任务：比较三款 AI 编程产品，并为一家 20 人工程团队提供有来源支持的推荐。
单Agent 方式
一个 Agent：搜索 → 阅读 → 比较 → 写作
全部塞进一个上下文窗口，简单。
但问题是，它把发现、判断、写作混在一起。
一旦失败，很难定位到底哪里出了问题。
Graph 方式
Node 1：Scope（定义范围）
把需求转化为明确标准：
- 价格；
- 隐私；
- 部署方式；
- 模型支持；
- 管理能力；
- 迁移成本。
输出不是文章，而是一个 Schema。
Node 2-5：Collect Evidence（收集证据）
启动多个独立 Worker：
- 官方文档；
- 定价信息；
- 安全资料；
- 用户反馈。
每个 Worker 返回统一格式：
{
"claim": "The enterprise plan supports SSO",
"source": "https://...",
"source_type": "official_docs",
"published_at": "2026-07-12",
"confidence": "high"
}
Node 6：Normalize（标准化）
使用代码完成：
- 删除重复 URL；
- 拒绝缺失字段；
- 统一日期；
- 按产品归类。
这里不需要调用模型。
Node 7：Challenge（挑战）
让验证器专门寻找错误。
它应该：
- 寻找相反证据；
- 检查过期价格；
- 检查地区限制；
- 发现遗漏条件。
Node 8：Human Gate（人工审核）
只有未解决的冲突、高影响建议，才交给人，普通证据继续流转。
Node 9：Synthesize（综合输出）
写作者只接收已验证证据、决策标准、未解决的问题，它不会看到原始研究过程。
这一点非常重要：上下文应该沿着 Graph 的边流动，而不是不断堆积到一个巨大窗口里。
Anthropic 在 Code Execution 和 MCP 的架构中也展示了类似模式：中间数据可以保留在执行环境中，模型只看到明确返回的信息。这样可以降低上下文压力、延迟、成本、敏感信息暴露等。（来源：Anthropic《Code execution with MCP》）
验证必须成为独立分支
不要让同一个 Agent 在同一个上下文里既创造内容，又批准自己的内容。因为它已经知道自己为什么做出这个判断，这会让它成为一个糟糕的怀疑者。
更强的验证流程是：
- Worker 提出一个结论；
- 确定性检查验证格式和来源；
- 验证器尝试推翻这个结论；
- 人类只查看重大分歧。
验证器应该返回证据，而不是感觉。
错误示例：
This looks accurate and well supported.
更好的方式：
{
"pass": false,
"failed_rule": "primary_source_required",
"unsupported_claims": [3, 7],
"next_action": "research_again"
}
Evals（评估）不是上线之后才添加的东西。Anthropic 指出，早期 Eval 能帮助团队定义成功标准，后期 Eval 则提供质量基线、延迟、Token 使用、成本、回归检测等。（来源：Anthropic《Demystifying evals for AI agents》）
在 Graph 中，这些 Eval 就成为 Gates。
每个 Graph 都要管理三种预算
Agent Graph 可以提升质量，但也可能悄悄毁掉延迟、成本、安全性，每次运行都需要关注三个预算。
1. 时间预算
并行分支只有真正独立时，才能减少总耗时。
因为最终汇合点必须等待最慢的那个分支完成。
2. Token 预算
每增加一个Worker、Judge、Retry、Synthesis，都会增加成本，因此应该传递结构化证据，而不是整个聊天记录。
3. 风险预算
不同动作不应该拥有同样权限，读取文档和发送付款，不应该共享同一个权限策略。
Graph 应该让这些权衡显性化，加入每节点 Token 上限、工作流截止时间、重试限制、权限等级等。
预算耗尽时，返回最佳部分结果，并明确说明失败原因，不要让 Agent 为了完成任务不断循环。
什么时候不要构建 Graph？
Graph Engineering 并不是把每个 Prompt 都变成基础设施。
以下情况，一个模型调用就够，即任务短，风险低，容易检查时。简单 Chain 适合每一步都严格依赖上一步。
但当出现以下情况时，就应该考虑 Graph：
- 独立任务可以并行；
- 不同输入需要不同专家或工具；
- 失败需要重试、备用方案或升级；
- 任务需要暂停后恢复；
- 高影响输出需要独立验证；
- 人类需要批准关键决策，但不想监督每一步。
Anthropic 的建议很直接，即先使用最简单的解决方案，只有当复杂度能够明显改善结果时，再增加复杂度。
Graph 有价值，是因为它暴露复杂性，而不是制造复杂性。
第一个 Graph 可以只有一张纸那么简单
从一个你已经重复执行的任务开始，画出当前流程，一个个方框。然后，标注每条箭头实际传递的数据。
标记：
- 决策点；
- 外部操作；
- 失败路径；
- 人工审批。
然后简化：
- 合并无法独立评估的节点；
- 删除代码可以替代的模型调用；
- 拆分需要不同上下文的任务；
- 在最终输出前加入一个验证器；
- 在增加 Retry 前加入 Stop Rule。
框架只是工具，真正重要的是 Graph 里的决策。
目前已有一些相关框架：
LangGraph 官方文档
支持基于 State、Nodes 和 Conditional Edges 构建 Agent 工作流。
Microsoft AutoGen GraphFlow 文档
支持顺序、并行、条件和循环执行。
Anthropic Building effective agents
介绍了 Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer 等 Agent 架构模式。
框架可以替换，但你的 Graph 决策才是真正的产品。
转变
Prompt Engineering 问的是，下一步模型应该说什么，或者做什么？
Graph Engineering 问的是，当前应该存在哪些信息？谁应该处理它？什么能证明结果正确？失败之后应该流向哪里？
这是一个更难的问题，但也是让一个聪明的 Demo，变成一个你可以反复信任的系统的关键。
关注：@iiiichigo_chan