Loops and Graphs：如何不再盯着 Agent，只在最后一步进行审批！

点击下方“JavaEdge”，选择“设为星标”

第一时间关注技术干货！

本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！

• 魔都架构师 | 全网30W技术追随者

• 大厂分布式系统/数据中台实战专家

• 主导交易系统百万级流量调优 & 车联网平台架构

• AIGC应用开发先行者 | 区块链落地实践者

• 以技术驱动创新，我们的征途是改变世界！

• 实战干货：编程严选网

0 前言

你会检查 Agent 执行的每一步。不是因为你想这么做，而是因为没有其他机制替你完成这件事。

想真正从这个“监工椅”上站起来，需要两样东西，而几乎所有人都只构建了其中一个。

loop让一个工作单元在没有你的情况下不断修正，直到它正确。graph则决定到底有哪些工作单元，以及它们应该如何组织。

下面我们来拆开讲清楚这两者的区别、那些不那么直观的运行机制，以及最终让你只需要审批一件事，而不是审批每一步的关键所在。

1 Loop就是一个可以失败的检查

把其他东西全部去掉，一个Loop其实只有四个部分：执行、检查、修正、重复，直到通过。其中最重要的是检查。

如果没有一种机制能在你离开之后判定工作失败，那就不是Loop，而只是一个调度器。这听起来很明显，但几乎没人先写检查条件。

他们通常先把工作流程搭起来，然后在最后再加一个评审环节，而这个评审环节就是让另一个模型来检查输出。两个乐观主义者互相点头。

先写条件，而且要把它写成程序可以直接判断的形式：

GREEN    测试套件以 0 状态码退出
GREEN    每个结论都带有来源行号
GREEN    diff 只修改计划中列出的文件


 NOT A CHECK   输出看起来不错
NOT A CHECK   模型说自己很有信心
NOT A CHECK   没有报错

最后这一条很容易让谨慎的人也掉进去。没有报错，并不意味着结果正确。

如果你基于这种条件构建Loop，最终得到的可能是一个非常自信的系统：它会不断重复同一个错误，直到预算耗尽，而整个过程的日志还干干净净。

2 一个没人提醒你的上限

Loop可以让一个工作单元变得更好。这就是它全部的职责，而它在这件事上非常擅长。

但它无法决定到底有哪些工作单元存在，也无法决定它们的执行顺序，更无法发现五个步骤中的两个其实根本不需要互相等待。

于是，你得到的是一个非常优秀的 Agent，却让它以错误的顺序，一个接一个地执行三个本来就不该这样执行的步骤。

每一个步骤本身都正确。最终结果却依然很慢，而且整体形态就是错的。

继续调Loop解决不了这个问题，因为故障根本不在任何一个工作单元内部。

这通常就是人们开始责怪模型的时刻。同时，也是下一层架构开始产生价值的时刻。

3 graph就是位于上层的那一层

graph描述的是整个工作的形状：哪些任务要运行，哪些可以同时运行，哪些必须等待，哪些根本不需要运行，以及结果应该流向哪里。

只有两样东西：

• 节点是一个工作单元：一个边界明确的任务，有一个输入，也有一个输出

• 边是依赖关系：这个节点的输出会作为另一个节点的输入

几乎所有不必要等待背后的错误，都来自把“然后”当成了一条边。

如“总结文件，然后查询天气”之间其实不存在依赖关系。查询天气无需读取文件摘要。

它们本就是两个相互独立的节点，只是因为你写脚本时按照这个顺序输入了两个操作，于是脚本顺手把它们串了起来。

所以，把这件事应用到你现有流水线中的每一条箭头：下一步真的会读取上一步的输出吗？

如果你说不出到底是哪个变量从前一步传到了后一步，那这就不存在真正的依赖边，这次等待纯浪费。

大多数工作链都有两三条这样的箭头，而找出它们，通常就是能够获得的最大单项提速。

4 四种节点，其中一种甚至不是模型

Splitter、Worker、Code Node、Gate——这就是全部词汇表。

4.1 Splitter

负责把工作拆成多个单元，并位于最前端。如果拆分维度错了，后面所有工作都被浪费：

• 按文件夹拆分一个代码仓库，四个 Worker 可能反复审查同样的三个文件

• 按影响范围（blast radius）拆分，那么每个 Worker 看到的内容都会有所不同，彼此无法完全替代

• 每次只处理一个工作单元

• 使用一种视角

• 并拥有自己的上下文

最后这一点经常被忽略，如果你给四个审计员共享同一个上下文窗口，他们最终会趋同：第一个人写下一个发现，其他人看到后就会继续围绕这个发现展开，最后四份报告都集中在同一问题。

你付了四个人的钱，却只得到一个观点和三个回声。

4.3 Code Node

人们最容易忘记存在的一类节点。

合并、排序、去重、比较所有导出内容在修改前后的差异……

这些都不需要推理。每一项都有唯一正确答案，而且通常只需几行代码。让模型来做这些事情，只会给原本没有成本、延迟和随机性的步骤增加成本、延迟和波动。

如果你能够在不使用“判断”“决定”“评估”或“总结”这些词的情况下描述某个转换过程，那它就应该写成代码。

如果graph上的每一条边都要经过一个 Agent，你就必须为自己的连线一一付费。

5 Loop到底应该放在哪？

Loop存在于节点内部，graph存在于节点之间。

在一个工作单元内部：执行、检查、修正、重复，直到通过。 produce, check, correct, repeat until green。

在工作单元之间：拆分、扇出、合并、门控、返回。split, fan out, merge, gate, send back。第二组操作，没有任何一个可以从单个工作单元内部表达出来。

所以你根本不需要二选一：

• 一个节点内部没有Loop的graph，会并行地产生未经验证的工作，而且因为产生得更多，它甚至比串行执行更糟糕

• 而一个外部没有graph的Loop，只不过是在一个没人设计过的队列里，拥有一个非常优秀的步骤

没有返回路径的graph，本质上只是一个流水线。它产生结果，然后忘掉一切。

下周，它又会从同一个地方开始，并重复同样盲点。真正能持续工作的graph，需要两条返回路径，而且它们承担完全不同的职责。

6.1 修正边（correction edge）

很短。

Gate 拒绝某个工作单元，并把它退回产生它的步骤，由这个步骤修复当前这次运行。

6.2 学习边（learning edge）

很长。

一个被接受的结果会回到 Splitter，成为新的约束条件，从而修正之后的每一次运行。

几乎所有人都会构建第一条，却跳过第二条。最明显的表现，就是一个系统运行得很快，却永远不会变得更聪明。

学习边传递的不是输出，而是从输出中提炼出的约束：

ACCEPTED   utils slice 已完成迁移，第一次运行即通过（the splitter's brief for every later slice）
DERIVED    adapters 必须原样保留 keyword args（the splitter's brief for every later slice）（the splitter's brief for every later slice）
LANDS IN   后续每个 slice 的拆分说明（the splitter's brief for every later slice）

注意它最终落（lands）在哪里。不是 Worker 的指令里，而是落在决定工作如何拆分的 brief 中。

一个已经确认的原因会变成一条规则，于是下一次出现问题时，就可以从这一次结束的地方继续向前推进。

7 返回工作单元，而非整个批次

这是返回路径上代价最高的错误。

四个 slice 被迁移了。其中一个测试失败。如果你把整个批次退回，另外三本来正确 slice 也会被重新改写。

它们的下一版会变得不一样，却不会变得更好，因为它们本就没问题。

然后你又要重新验证全部四个，而这一次，其中任何一个原本正确的 slice 都可能因为无关原因失败。

你把一次失败变成了四个不确定的结果，还为此付出额外成本。如果一次运行中这样做两次，整个系统就永远无法收敛。

外部看，这像是模型一次又一次失败。实际是你的返回路径破坏了原本正确的工作。

每次返回时，都应该携带四样东西，而且每样都有自己的作用：

UNIT      handlers slice
VERDICT   red
REASON    test_auth_redirect 失败
EVIDENCE  预期 302，实际得到 200，handlers/auth.py:88
SCOPE     只修复这个文件，不要修改其他 slice

最后这一行的重要性比看起来更高。

没有 Scope，返回的工作单元就会不断膨胀：Agent 打开文件，发现旁边还有两个问题，于是顺手一起修掉。原本只需要修一个 slice，最后变成一个涉及四个文件的 diff，而且没人审查过。

最多允许三次尝试。如果一个工作单元连续三次修正仍失败，问题很可能出在产生这个工作单元的计划，而Loop本身是看不到这个计划的。

8 根据影响范围打开 Gate，而不是根据置信度

很多方案都会建立一个置信度分数，设置一个阈值，然后让超过阈值的结果自动通过。这是错误的变量。

置信度之所以是最弱的决策输入，原因易被忽略：它是唯一一个模型本身能够影响的变量。

真正应该关注的是：如果这次修改是错的，会发生什么？应该按照错误发生后的修复成本来划分工作：

8.1 可逆且影响范围有限

如复制修改、测试、具有覆盖率的独立函数。一次错误合并只需回滚，因此这条通道可优先自动放行。

8.2 可逆但影响范围广

如共享工具函数、Schema 增加和任何被十几个调用方使用的内容。应该要求确定性检查通过，并且整个运行轨迹保持干净。

8.3 难以逆转

如数据库迁移、删除操作和任何会写入生产数据或涉及资金转移的操作。这条通道无论分数多高都不能自动打开。

第三种并不是“把阈值设置得非常高”。它是一条根本不会自动打开的通道。这个区别非常重要，因为阈值可以不断被调整，而关闭的通道不会。

在一条已开放的通道内部，Gate 应按以下顺序读取证据：

• 先看确定性结果

• 然后看本次运行的轨迹

• 再看这个节点过去的工作有多频繁被回滚

• 最后才看模型自己的判断

找个你反复做的事情。画出 Splitter、各个执行通道、Merge、一个 Gate，以及一条返回边。

• 先构建 Gate。一旦有了一个能够明确失败的机制，后面所有事情都会容易很多。因为一个没有 Gate 的graph，只不过是一种更快地产生未经验证输出的方式

• 然后构建各个执行通道

• 最后再构建学习边。之所以最后做，是因为在真正产生可接受的结果之前，你根本无法从这些结果中提炼约束。

把人放在一个步骤上：放在后果最高、可逆性最低的位置。

审批 Merge。决定哪些修复应该发布。而不是审核中间输出，也不是确认每一步。

一个处于graph中间的人类，会成为整个graph里最慢的节点。而整个graph最终能跑多快，就取决于这个人阅读信息的速度。

整个方法论可以浓缩成三句话：

• 衡量整条路径，而不只是最终得到的答案

• 一个不会改变下一步执行方式的结论，只是一份报告

• 任何没有被转化为永久约束的失败，你以后都会再次遇到

大多数人会继续不断调优一个Loop，然后把它称为系统。

而真正画出围绕Loop的graph的人，会开始运行一整套 Agent 集群，却很难理解为什么其他人总是这么难追上。

编程严选网：http://www.javaedge.cn/ 专注分享AI时代下软件开发全场景最新最佳实践~