作者：Raynaaa（Echoverse回响宇宙）

过去一年，AI Agent 的讨论从 Prompt Engineering 变成 Context Engineering，再到 Harness Engineering、Loop Engineering，现在又轮到 Graph Engineering。名词越来越多，很容易让人觉得，这是不是 AI 圈又在给旧东西换名字？

某种程度上确实如此。Graph 并不是什么新技术，工作流、状态机、任务依赖图在传统软件工程中早就存在了。但我觉得，这轮讨论有一个值得关注的变化：当模型本身已经可以完成越来越复杂的任务，AI 系统的瓶颈，开始从单次推理能力转向整个执行过程的组织能力。

换句话说，模型越来越聪明，不代表让它自由发挥，就能得到一个更可靠的系统。

01｜一个越来越聪明的 Agent，为什么反而容易失控？

先说 Loop。

目前大量 Agent 都建立在一个很简单的循环上：模型理解任务、调用工具、观察结果、继续思考，直到认为自己完成了工作。

这个结构的好处是灵活。用户只需要告诉 Agent 想要什么，至于中间怎么做，可以交给模型自己决定。

但问题也出在这里。

假设让一个 Agent 完成一份竞品研究报告。它需要搜索资料、核实数据、分析产品、判断商业模式，最后完成写作。如果全部放进同一个执行循环，模型就需要同时负责规划、执行、检查，以及判断何时结束。

任务越长，问题越明显。上下文不断积累，早期约束可能逐渐失去影响；某一步调查出现错误，后续分析可能建立在错误事实上；即便只需要修改一个数据，也可能触发大量重复工作。

更麻烦的是，模型可以判断自己应该做什么，却不一定能可靠地判断自己做得对不对。

这不只是我的感觉。普林斯顿大学 Arvind Narayanan 团队今年在机器学习顶会 ICML 上发了一篇 Agent 可靠性研究，跟踪了过去两年的主流模型：按他们画的趋势线，准确率每年涨 22 个百分点，可靠性得分（满分 1）每年只涨 0.06。这里的可靠性，看的是同一个任务反复跑稳不稳定、换个问法还对不对、对自己有没有把握判断得准不准。论文测到的最新一代 GPT-5.5 和 Claude Opus 4.7，在 GAIA 这套通用助手任务上，并不比上一代更可靠。

左图是准确率，右图是综合可靠性，横轴是模型发布时间，点按 Anthropic、Google、OpenAI 区分。正文的“每年涨 22 个百分点”和“每年涨 0.06”是图中趋势线的斜率，不是首尾两个点的差。来源：普林斯顿大学的 Agent 评测榜 HAL Reliability Tracker，论文《Towards a Science of AI Agent Reliability》（ICML 2026），截图于 2026 年 11 月 5 日

这意味着，单纯提高模型的推理能力，并不能解决所有系统性问题。

当然，Loop 本身没有错。做 Agent 开发框架的 LangChain 今年 6 月写《The Art of Loop Engineering》时，甚至把 Agent 执行、结果验证、事件触发和系统持续改进，都描述成不同层次的循环。

所以要改的不是循环本身，而是别让同一个模型既干活、又检查、又决定什么时候收工。

02｜Graph 的价值，是把一部分控制权从模型手里拿回来

Graph Engineering 的思路，是把复杂任务组织成一张由节点和连接关系构成的执行图。

节点负责完成具体工作，连接关系决定下一步执行什么，以及满足什么条件才能继续。

如果还是刚才那份竞品报告，系统可以先拆成资料搜集、数据验证、商业分析、报告生成几个部分。

其中，资料搜集可以并行；商业分析必须等待关键数据验证；报告生成完成后还要经过一次质量检查。如果检查不通过，只需要退回对应部分重新执行，而不是推倒整个任务。

拆开看，一张 Agent Graph 由四样东西组成。

第一是共享状态（State），相当于一本任务账本，记着查到的资料、验证过的数据、每一步做到哪了。各个节点读写的都是这本账，不靠一长串聊天记录传话。所以上下文不会越滚越长，哪一步写错了也查得到。每个节点也只该拿到它需要的那几页，把整本账塞给所有人，就又变回了一个塞满的上下文窗口。

第二是节点（Node），也就是干活的单元。它可以是一个 Agent，可以是一段普通代码（比如按规则核对数字），也可以是一个等人点头的审批点。哪些事该交给代码，有个很好用的标准：一件事描述起来用不着“判断”“决定”“评估”“总结”这几个词，比如合并、排序、去重，就该交给代码。让模型来做，只会多出成本、延迟和不确定性。

第三是边（Edge），决定下一步去哪。有的边是固定的，比如数据验证完一定进入商业分析；有的边带条件，比如质量检查没过就退回去。条件可以用代码写死，也可以交给模型判断。画边之前可以先问一句：下一步真的要读上一步的结果吗？说不出两步之间传的是什么，这条边就不该有，后一步也不必等。很多流程慢，就慢在把“然后”当成了依赖。

第四是检查点（Checkpoint），每走完一步把状态存一次。出了故障，从最近的检查点接着跑；需要人工确认时，系统也能停在这里等人。

蓝框是 Agent，灰框是代码，虚线框是人工；蓝色虚线是 Correction Edge，深色圆点是检查点。最上面那条长箭头是 Learning Edge，第 03 节会讲到。示意图，Echoverse 绘制

换句话说，Loop 在节点里面，Graph 在节点之间。节点内部照样是“做、查、改，直到通过”的循环；拆分、并行、汇总、退回，发生在节点之间，单靠一个循环表达不了。也因为要重试、退回、等人确认，生产环境里的图几乎总会有环，通常不是只能单向往前走的 DAG（有向无环图）。

这四样东西组合起来，带来三个变化。

第一，依赖关系不再完全交给模型临时判断。 系统可以通过任务图明确哪些工作必须串行，哪些可以并行，减少无意义等待。

第二，执行状态可以被持久化。 靠的就是检查点。LangChain 的编排框架 LangGraph 就是这么做的：某个节点失败了，从上一个检查点接着跑，已经成功的节点不用重跑。

第三，验证可以成为执行条件，而不是一条 Prompt。 系统可以要求关键数据通过规则校验，或者在涉及外部操作时等待人工确认，再允许下一步执行。

我觉得第三点尤其重要。

以前可能会在 Prompt 里写一句「请仔细检查，确保所有数据正确」。但模型是否真的检查、检查是否有效，仍然依赖它自己的判断。

Graph 则允许开发者直接规定：没有通过验证，就不能进入下一个节点。

说白了，Prompt 只是建议，边是代码。长对话跑到几十轮，模型可能早忘了提示词里那句叮嘱，写在边上的规则不会忘。

这相当于把一部分原本寄托在模型自觉上的要求，变成了系统必须遵守的规则。

哪些步骤必须停下来等人点头，该看“错了有多难撤回”，而不是看模型有多大把握。改一段文案，错了能回滚，可以先放行；删数据、动钱，模型再自信也不放。理由很简单：置信度是唯一一个模型自己能左右的数。

不过，Graph 也不是越复杂越好。

对于深度研究这类路径高度开放的任务，过度预定义的 Graph 反而会限制模型探索。

所以，我更倾向于把 Graph 看作一种控制权分配方式，而不是 Loop 的替代品。

已知的规则交给代码，未知的判断交给模型；需要灵活探索的地方保留 Loop，需要稳定交付的地方引入 Graph。

现在不少 Graph 的讨论最后都落在“多拆几个 Agent”上，但我觉得，先想清楚哪些控制权该收回来，比多加几个 Agent 有用得多。

03｜下一轮竞争，可能是看谁能把一次成功变成可重复的能力

如果只是任务拆解、并行执行和失败重试，Graph Engineering 其实还没有跳出传统工作流系统的范畴。

我同意 LangChain 联合创始人 Harrison Chase 7 月在一篇长文里的判断：真正新的是节点里装的东西变了。Graph 的每个节点，现在都可以是一个具备完整推理和工具调用能力的 Agent。

以前编排的是函数和 API，现在可以编排一组具有一定自主能力的智能单元。整个系统既有确定性的执行规则，也保留了模型处理开放问题的能力。

这会改变 AI 产品的竞争方式。

过去评价一个 Agent，我们经常关注它一次能完成多复杂的任务，或者在某个 Benchmark 上取得多高的分数。但如果把 Agent 当作长期运行的产品，我反而更想看三个指标：

第一个是任务成功率：同一类任务重复跑，结果能不能稳住。看的不是它最好能做到多好，而是同一件事交给它十次，能不能十次都交出合格的东西。客户不会只用一次，偶尔翻车一次，前面九次放心也就白搭了。

第二个是单位成功成本：算上 Token、工具调用、失败重试和人工介入，真正完成一次任务要花多少钱。已经有公司按结果收费了，这时单位成功成本直接决定它每单赚多少。客服软件公司 Intercom 今年改名 Fin，9 月被 Salesforce 收购。它的客服 Agent 按“结果”收费，每个 0.99 美元，一个结果基本就是替客户解决一个问题，事没办成就不收钱。模型、工具和失败重试的钱，全得从这 0.99 美元里出，办成一单之前失败的那几次也算在内。

对按结果收费的公司来说，Agent 偶尔能做得多好不值钱，次次都做得到，才有毛利。

第三个是经验复用率：上一次发现的问题，能不能让下一次执行更可靠，而不是重新犯错。LangChain 6 月那篇《The Art of Loop Engineering》里的最后一层循环，也就是“系统持续改进”那一层，做的就是这件事：让一个分析 Agent 去读生产环境里的运行记录，反过来改提示词、工具和评分规则。

尤其是第三点。

Graph 本身并不会让系统自动学习。Checkpoint 保存的是执行状态，不等于模型掌握了新知识。只有当失败原因、验证结果和人工修正被进一步提炼成可复用的规则、记忆或执行策略，系统才有可能不断改进。

这一步可以理解成一条 Learning Edge。图里有两种往回走的边：短的是 Correction Edge，质量检查不通过，把那一块退回去重做，只修这一次；长的是 Learning Edge，把一次通过的结果提炼成一条规则，送回最前面负责拆任务的节点，之后每一次都按新规则来拆。常见的情况是，大多数人只搭了 Correction Edge，所以系统跑得快，却从来不变聪明。

左边每次都在同一个地方出错、退回、重做；右边第一次纠错后通过的经验变成规则①，写进了下一次的规划。示意图，Echoverse 绘制

但 Graph 提供了一个很好的基础：任务在哪里失败、哪个节点成本最高、什么条件导致返工，都可以被更清楚地记录和分析。

这也让我重新思考 AI 产品的护城河。

如果两家产品调用的是同样的基础模型，拥有相似的工具能力，它们的差异可能越来越不在于谁的 Prompt 更漂亮，而在于谁积累了更好的任务组织方式、更有效的验证机制，以及更多经过真实执行检验的经验。

这部分能力并不能靠简单更换一个更强的模型直接获得。

当然，也不是所有 AI 产品都需要复杂的 Graph。对于低风险、短链路、开放探索的任务，简单的 Agent Loop 可能已经足够好。多加一层架构，也意味着更多开发和维护成本。

真正值得投资的不是 Graph 这个概念，而是那些能够降低单位成功成本、提高交付可靠性的系统能力。

我觉得这可能是 AI Agent 竞争中一个正在发生、但还没有被充分重视的变化。

过去，我们一直在追问模型还能变得多聪明。

接下来，更值得追问的或许是：

当聪明的模型逐渐成为所有人的共同基础，谁能把一次成功的执行，变成一千次可重复的结果？