AI Agent靠Prompt已经不够了,下一步是“Graph图工程”

随着 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 在同一个上下文里既创造内容，又批准自己的内容。因为它已经知道自己为什么做出这个判断，这会让它成为一个糟糕的怀疑者。

更强的验证流程是：

1. Worker 提出一个结论；
2. 确定性检查验证格式和来源；
3. 验证器尝试推翻这个结论；
4. 人类只查看重大分歧。

验证器应该返回证据，而不是感觉。

错误示例：

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