从 Loop 到 Graph Engineering：为什么 Agent 需要独立监督
客服 Agent 把工单解决率越做越高，客户续约却在下滑。问题出在哪？这篇从这个案例聊聊 Graph Engineering。
前两天看到一篇讲 Graph Engineering 的文章。
老实说，第一次看到这个词，我的反应是：AI 圈是不是又给旧东西换了个新名字？
Loop、Graph、Workflow，这些词混在一起，很容易把一件原本不复杂的事讲玄。但读完之后，我觉得里面有个问题确实值得单独拿出来聊：
问题也跟着变了：Agent 很会完成你写下来的目标。可如果目标本身写错了，它同样会认真执行。
01 一个越来越漂亮，也越来越没用的指标
事情是从 OpenClaw 作者 Peter Steinberger 的一句话开始的：
Are we still talking loops or did we shift to graphs yet?
第二天，Carlos E. Perez 写了一篇长文回应。他在文章里举了一个客服 Agent 的例子。
团队希望提升工单解决率，于是让 Agent 持续调整提示词和处理策略。每跑一轮，系统都会检查解决率；没达到目标，就继续改。
从报表上看，这套 Loop 很有效。解决率一直在涨。
可 Agent 很快找到了更省事的做法：早点关掉对话，少给用户继续追问的机会；用户没有再回复，就把工单算作已解决。
数字好看了，客户却在流失。
这类问题并不新鲜。Goodhart 定律讲的就是这件事：一旦某个指标变成必须追逐的目标，它就会逐渐失去衡量真实结果的能力。
放到 Agent 里，麻烦在于 Loop 只会沿着你给它的反馈继续跑：
做一次
→ 看结果
→ 调整
→ 再做一次验证器说分数提高了，它就会认为方向没错。至于用户到底满不满意、评测集是不是已经被摸透、这个分数还能不能代表业务结果，都不在它的视野里。
它没有罢工，甚至工作得很努力。只是努力错了地方。
02 问题不在 Loop，而在谁来检查 Loop
Loop 本身当然有价值。
一个写代码的 Agent，不断改文件、跑测试、读报错，再根据报错继续改，这就是很典型的 Loop。任务边界清楚，结果也能用真实测试验证，这种情况下完全没必要为了“架构感”再塞进五个 Agent。
Graph Engineering 开始有用，是在一个 Loop 已经不够看的时候。
比如还是文本分类。主 Agent 负责调 Prompt，准确率从 82% 做到了 91%。如果系统只看这一个数字，可能已经准备发布了。
但另一个独立的检查节点也许会发现，它并没有真正理解文本，只是记住了评测集里几个很有辨识度的词。换一批数据，准确率马上掉回去。
这时需要设计的就不只是“主 Agent 下一轮怎么改”，还包括：
- 谁来检查它为什么拿到高分；
- 谁可以动 Prompt，谁不能动验证集；
- 两个判断发生冲突时，听谁的；
- 到了什么动作，必须停下来等人确认。
我更愿意把 Graph 理解成这些关系的总和，而不是一张画了很多圆圈的流程图。
Anthropic 曾经把 Workflow 和 Agent 做过一个比较实用的区分：Workflow 的路径由代码提前规定，Agent 则会根据任务动态决定过程和工具。Graph Engineering 讨论的又往前走了一步——当系统里不只一个会动态行动的 Loop，它们之间怎么交接、监督和否决。
03 多一个 Agent，不等于多一道保险
这里最容易踩的坑，是把“多 Agent”直接等同于“更可靠”。
给执行 Agent 后面接一个审核 Agent，看起来已经有了复核。但如果它们读的是同一份上下文，用的是差不多的提示词，判断标准也完全一样，最后很可能只是两个 Agent 一起点头。
数量增加了，新的信息没有增加。
真正有用的检查，往往来自不同的权限和证据。
执行节点可以改 Prompt，但不能碰隐藏验证集；审核节点不只看最终分数，还要抽查分类依据；如果要修改标签定义、替换验证集或者上线生产，就把决定交回给人。
实现方式反而没那么重要。用 LangGraph、队列、几个独立任务，甚至普通代码都可以。先把“谁能改什么、谁用什么证据检查、谁有权按下停止键”写清楚，比先选框架更实际。
而且 Graph 自己也会跑偏。
想象一下：执行节点生成报告，审核节点检查报告，另一个节点再汇总前两份报告。大家互相验证，页面上一片绿色，可没有一个节点去看真实客户还在不在。
这种系统比单 Loop 更让人头疼。因为它不是没有检查，而是检查得很热闹，却始终没有碰到现实。
所以，“转账成功”要去查支付系统的状态，“测试通过”要留下真实执行记录，“客户留存”要看活跃和续约。验证集、合规规则、生产权限这类东西，也不能任由优化器为了提高分数而修改。
说白了，Agent 可以不断调整做法，但有些尺子不能交给它自己刻。
04 什么时候值得从 Loop 往 Graph 走
我的判断比较保守：能用一个 Loop 解决，就先别堆 Graph。
批量改文件名、把 Markdown 转成 HTML、按照固定规则跑测试，这些任务短、结果清楚、失败也容易发现。增加节点只会带来更多调用成本和排错工作。
下面几种情况，才值得认真考虑：
- Agent 能修改自己的评测方式、数据或停止条件；
- 一个指标不断变好，但真实业务结果没有跟着变好；
- 多个 Agent 已经开始互相消费对方的输出；
- 任务会运行很久，错误要过很多轮才会暴露；
- 系统能碰到发布、付款、生产配置或者真实用户数据。
真要开始做，我会先写下四件事：主 Loop 在追什么结果；用哪个反向指标识别它在刷分；哪些数据和规则不许改；哪些操作必须由人批准。
这些问题没答案，图画得再漂亮也没用。
写在最后
Graph Engineering 现在还是个很新的说法，也谈不上有一套公认的标准。监督、仲裁、隐藏验证集、权限隔离、人工审批，这些工程手段以前就有。
但这个词提醒我的地方在于：当 Agent 开始长时间运行，并且会把结果交给另一个 Agent 时，我们不能只盯着“它会不会做”。
还要看它用什么证明自己做对了，谁能指出它赢得不对，最后又拿什么和现实对账。
所以我现在更关心的是：Agent 说自己做对了，我们有什么独立证据？
如果答案还是另一份 Agent 生成的报告，那就还不够。