为什么你的 AI 智能体还需要你盯着？闭环之上，还缺一张工作流图
你会检查智能体做的每一步。
不是因为你喜欢盯着，而是因为除了你，没有别的机制负责检查。
想从这把监督者的椅子上站起来，需要两样东西。但几乎所有人都只搭了其中一样。
闭环（loop），让一项任务在没有你盯着的情况下做到正确。工作流图（graph），决定究竟应该有哪些任务。
下面我们把两者分清，讲透那些不那么显眼的运行机制，以及怎样让你只审批一个关键结果，而不是确认所有步骤。
一、真正的闭环，必须有一道能判失败的检查
剥去其他包装，一个闭环只有四步：
产出 → 检查 → 修正 → 重复，直到验收通过。
其中，检查才是核心。
如果你离开之后，没有任何机制能够判定这份工作“不合格”，那你搭的就不是闭环，只是一个调度器。
这听起来很明显，但几乎没人先写检查条件。
大家通常先让智能体干活，再在末尾补上一道审查。而所谓审查，不过是请另一个模型看一眼结果。
两个乐观主义者互相点头。
正确的顺序是：先写通过条件，而且要写到程序可以判断。
例如，以下才是明确的通过条件：
-
测试套件的退出码为 0。 -
每条论断都附有对应的来源行。 -
代码差异只涉及计划中列出的文件。
下面这些都不算真正的检查：
-
“输出看起来不错。” -
“模型说自己很有信心。” -
“过程中没有报错。”
最后一条尤其容易骗过谨慎的人。
没有报错，不等于已经证明正确。
如果把闭环建立在这个基础上，你得到的会是一套信心十足、持续重复同一个错误的系统。直到预算耗尽，日志依然干干净净。
二、闭环有一个没人提醒你的天花板
闭环能让一个工作单元做得更好。这就是它的全部职责，而且它确实很擅长。
但它无法决定应该拆出哪些工作单元、按什么顺序执行，也无法从整体上发现：五个步骤中，有两个根本不用互相等待。
于是你可能拥有一个很优秀的智能体，却让它按错误的顺序，串行执行了三个本就选错的步骤。
每一步都做对了，整体却依然很慢，组织方式也不对。
继续调闭环解决不了这个问题，因为故障不在任何一个工作单元内部。
人们往往在这个时候开始责怪模型。但也恰恰是在这里，更上一层的设计开始显出价值。
三、工作流图，是闭环之上的那一层
工作流图描述的是工作的整体形状：
-
哪些工作要执行； -
哪些可以同时执行； -
哪些必须等待； -
哪些根本不该执行； -
结果应该退回哪里。
它只由两类元素组成。
节点（node），是一个边界清楚的工作单元：接收一个输入，完成一项工作，交出一个输出。
边（edge），表示依赖关系：这个节点的输出，是下一个节点的输入。
许多无谓的等待，都源自同一个错误：把“然后”误当成依赖。
“总结这个文件，然后查询天气。”
这两件事之间没有依赖。查询天气并不需要读取文件摘要。
它们原本是两个独立节点，只是被一段线性脚本串在了一起。串行顺序的来源，仅仅是你输入要求时的先后。
所以，请逐一审视你现有流水线里的每一根箭头：
下一步，真的会读取上一步的输出吗？
如果你连跨过这根箭头的具体变量都说不出来，那这里就没有依赖，等待只是浪费。
多数任务链里，都藏着两三根这样的箭头。找出它们，往往就是最有效的一次提速。
原作者在文中附有五层架构的完整讲解入口：agent-layers.vercel.app。
四、四类节点，其中一类根本不需要模型
理解工作流图，只需要四个词：
拆分器、执行者、代码节点、验收关卡。
1. 拆分器：决定工作怎么切
拆分器位于最前端，把整体工作拆成多个单元。
它的决定比其他节点更有影响力，因为拆分维度一旦选错，下游再努力也是浪费。
例如，按文件夹拆一个代码仓库，可能让四个执行者反复审查同样的三个文件。
如果按改动的影响范围来拆，每个执行者就有机会看到其他人看不到的问题。
2. 执行者：一人一块，各自独立
每个执行者只负责一个工作单元，用一个明确的视角，在自己的上下文里完成它。
最后这个条件，常常被忽略。
如果让四个审查者共用同一个上下文窗口，他们的意见会逐渐趋同：第一个人写下一个发现，其余人读到了，最后四份报告都围着同一个问题打转。
你付了四份钱，买到的却是一份意见，外加三声回音。
3. 代码节点：别把确定性的活也交给模型
代码节点，是大家最容易忘记的存在。
合并、按明确规则排序、去重、逐项比较修改前后的导出内容——这些都不需要推理。
它们各有唯一正确答案，几行代码就能完成。原本没有成本波动和结果波动的步骤，一旦交给模型，反而多了调用成本、延迟和不确定性。
一个实用判断是：如果描述这项转换时，根本用不到“判断、决定、评估、概括”这类词，那它多半就该写成代码。
如果连工作流图里的每一次衔接都要派一个智能体来处理，系统光是维持自身运转，就已经在不断花钱了。
五、闭环到底放在哪里？
一句话就能消除混淆：
闭环在节点内部，工作流图在节点之间。
一个工作单元内部，做的是：
产出、检查、修正、重复，直到通过。
多个工作单元之间，做的是：
拆分、分发并行、合并、把关、退回。
后面这些，都不是站在某一个工作单元内部就能描述和安排的。
所以，这根本不是二选一。
如果工作流图里的节点没有内部闭环，你只是在并行生产未经验证的结果。它甚至比串行更糟，因为未经验证的东西变得更多了。
反过来，只有闭环、没有外部工作流图，就像队列里有一个表现很好的步骤，可这支队列从来没人认真设计过。
六、两条返回路径，大多数人漏掉了第二条
一张没有返回路径的工作流图，只是一条流水线。
它产出结果，然后把经历忘掉。
下周再运行，仍然从同一个起点出发，带着同样的盲区。
真正有效的工作流图，有两条职责不同的返回路径。
第一条是短程的纠错回路。
验收关卡拒绝某个工作单元，把它退回产生它的步骤，修复的是当前这一轮执行。
第二条是长程的学习回路。
已经验收通过的结果，被提炼成约束，再反馈给拆分器。改善的是之后的每一轮执行。
几乎所有人都做了第一条，却跳过了第二条。最明显的症状就是：系统跑得很快，却永远不会变聪明。
学习回路传回去的，不是结果本身，而是从结果中提炼出来的约束。例如：
- 已验收的结果：
utils切片迁移完成，首次验收就通过。 - 提炼出的约束：
适配器必须完整、准确地保留关键字参数。 - 约束落点：
拆分器此后为每个切片编写的任务简报。
注意这个落点。
不是只塞进执行者的指令里，而是进入决定“工作怎么切”的任务简报。
经过确认的原因成为规则，下一次拆分工作，就能站在这次已经获得的认识上继续，而不是重新起步。
七、退回一个单元，不要退回整批
这是返回路径上最昂贵的错误之一，值得讲得直白一点。
假设四个切片都已完成迁移，其中一个测试不通过。
如果把整批退回，那另外三个原本正确的切片，也会被重新改写。
新版本只会变得不一样，却不一定更好，因为它们原来就没有问题。
接着，你不得不把四个切片重新验证一遍。而那三个之前通过的切片，这次可能因为新引入的、毫不相关的问题而失败。
于是，你花了钱，把一个失败变成了四个不确定结果。
一轮执行里这样来上两次，系统就很难收敛。
从外部看，像是模型反复犯错。实际上，是错误的退回路径在破坏已经做对的工作。
每次退回，都应该带上这些信息：
- 工作单元：
handlers切片。 - 验收结论：
不通过。 - 失败原因：
test_auth_redirect测试失败。 - 证据：
预期 302，实际200；位置为handlers/auth.py:88。 - 修改范围：
只修这个文件，不要动其他切片。
最后这条，比它看起来更重要。
如果不划定范围，返工任务就会自己长大：智能体打开文件，看见旁边还有两个问题，于是顺手一起修了。原本只涉及一个切片的纠错，最后变成了四个文件的差异，而且没人审查过新增范围。
纠错尝试最多三次。
如果一个工作单元连续三次修正都不过关，问题就应该上溯到产生它的计划。而节点内部的闭环，看不到那份整体计划。
八、按影响范围放行，不要按模型信心放行
很多教程会设计一个置信度分数，设置阈值，超过阈值就自动放行。
但这个变量选错了。
模型信心是这类决策里最弱的依据，原因容易被忽略：它是模型自己能影响的那一项。
真正有分量的问题是：
这次改动如果错了，会造成什么后果？
按错误的撤销成本，把工作分成几条通道。
第一类：可撤销，而且影响局部
例如，改一段文案、增加一个测试、修改一个有测试覆盖的独立函数。
即使合并出错，代价也只是一次回滚。这条通道可以最先开放自动放行。
第二类：可撤销，但影响广泛
例如，共享工具函数、模式结构的新增项，或者任何会影响十几个调用方的改动。
这类工作既要通过确定性检查，也要有一条没有异常的执行轨迹，才能放行。
第三类：很难撤销
例如，数据迁移、删除操作、写入生产数据，或者涉及资金流转的操作。
不管分数多高，这条自动放行通道都不开放。
注意，这不是“把阈值设得特别高”。
而是根本不开放这条通道。
两者区别很大：阈值以后可能被调低，而关闭的通道不是靠调分数就能打开的。
在允许自动放行的通道里，验收关卡也应该按顺序读取证据：
-
确定性的检查结果。 -
本轮执行的实际轨迹。 -
这个节点过去产出的工作被回滚的频率。 -
最后，才是模型对自己的评价。
九、从你自己的哪项工作开始？
选一件你会反复做的事。
画出拆分器、执行通道、合并点、一个验收关卡，以及一条返回边。
先建验收关卡。
只要系统能够明确、响亮地暴露失败，后面的事就容易多了。
没有验收关卡的工作流图，只是在更快地产出未经验证的内容。
然后再建执行通道。
最后才补学习回路。因为在系统真正开始验收结果之前，你还没有“已通过的结果”可以用来提炼约束。
把人放在一个关键步骤上：后果最重大、最难撤销的那个位置。
让人审批合并，决定哪些修复可以交付。
不要让人逐条审查中间产物，也不要每走一步都找人确认。
如果把人塞进工作流图中间，他就会成为最慢的节点。整张图的运行速度，最终就取决于一个人读东西的速度。
十、把整套方法记成三句话
衡量执行路径，不要只看最终碰巧得到了什么答案。
一个不会改变后续执行的验收结论，只是一份报告。
任何没有被转化成长期约束的失败，你迟早还会遇到。
多数人会继续打磨一个闭环，然后把它叫作系统。
而那些在闭环外面真正画出工作流图的人，会开始运营一整支智能体队伍，甚至不太理解，为什么其他人跟上这件事会那么吃力。
原文附带的课程与关注信息
以下为原作者的推广内容，保留供回查，不代表译者推荐或提供相应服务。
原作者表示，已把全部五层内容整理成一门二十节课的课程，包含模板、配置和搭建顺序：
https://agent-layers.vercel.app
如果想先拿到关于工作流图这一层的单页说明，可以向原作者私信关键词 Graph。
原作者也邀请读者关注其账号，继续了解智能体内部机制，并订阅其 Telegram 频道：
https://t.me/+75nMf005jRpjMDU1
译文说明：本文为英文文章意译，文末推广内容来自原作者。