当生成代码变得越来越便宜，一个团队到底应该如何判断一次修改是否真的便宜？
关键在于：AI 确实降低了写出一版代码的成本，但没有降低理解、评审和长期拥有这段代码的成本。过去，一个看似很小的需求可能要先讨论两天，因为真正动手尝试本身就很贵。现在，与其一直猜它会不会牵一发动全身，不如先让 Agent 花几分钟做一个受约束的尝试，再对着真实的 diff 判断。尝试的门槛降到了极低。
为什么 100% 测试通过，仍然不能放心合并？
如果 AI 生成代码已经不再是主要的成本瓶颈，那么新的问题就变成了：如何让系统自己产生足够可信的证据，让人能够快速判断一个改动是否值得接受？
今天的编码 Agent 通常不会只交一份裸补丁。我们会要求它补齐测试、运行现有测试，有些团队甚至要求覆盖率达到 100%。这样产出的候选改动，当然比一次未经验证的生成可靠得多。
但即便测试全部通过、覆盖率达到 100%，也不等于可以随时合并。测试能够证明代码符合已有测试里的预期，却不能证明这个预期本身是否正确：
权限测试可以证明某个角色现在能够访问一个接口，却不能决定这个角色是否应该拥有权限。
数据保留测试可以证明记录会在 30 天后删除，却不能决定公司对用户的承诺究竟应该是 30 天还是 90 天。
计费测试可以证明公式按照规则运行，却不能判断这套规则是否符合产品契约。
如果代码和测试来自同一个 Agent、同一份需求理解，还会有另一层风险：它可能把需求理解错了，然后用一套同样建立在错误理解上的测试，完整证明自己的实现没有偏离。测试写得越齐全，这种一致性有时反而越像正确性。
因此，测试通过只是合并的必要证据，它可以证明候选实现跨过了机械校验的门槛，却不能替团队回答核心问题：这个行为是否应该存在，以及出了问题之后谁来负责。
从代码生成到验证系统：为什么 Agent 需要 Loop 和 Graph
正是因为“生成容易、验证困难”，今天的 Agent 系统越来越少讨论“写一个完美的提示词让模型一次生成”，而开始讨论循环、自检和多角色协作。Loop 和 Graph，在本文关心的问题上，分别改变了验证进入执行过程和组织结构的方式。
Loop：让验证进入执行过程
在单次生成的模式下，无论代码看起来多完整，系统都没有机制发现自己的错误。Loop（循环式 Agent）真正带来的变化，是把校验嵌进了执行过程。
Agent 读取目标、执行动作、观察结果，然后根据测试和报错继续调整，直到任务完成。测试、Linter 和实际运行结果不再只是人类最后看一眼的验收材料，而是系统下一轮行动的输入。验证被提前到了 Agent 自己动手的过程中。
Graph：让验证进入组织结构
当一个任务需要规划、编码、测试、安全检查和合规判断时，把所有职责塞进同一条上下文会越来越难管理。Graph（图式工作流）解决的是任务拆分与路由的问题。
代码质量、安全、合规和产品契约不是同一种问题，可以由图中的不同节点分别处理。系统还可以根据改动类型决定接下来走哪条路径：一个只修改 UI 显示字段的补丁，和一个触碰底层权限逻辑的补丁，不必经历完全相同的验证流程。
架构复杂，不等于监督完整
了解了 Loop 和 Graph 是为了组织验证流程，我们需要警惕一种错觉：节点越多、分工越细的 Graph，系统就越可信。
假设一张图里有编码 Agent、测试 Agent、安全 Agent、评审 Agent 和合并决策 Agent。从结构上看，它远比一个简单的 Loop 严谨。但如果评审和合并决策仍然全部由 AI 完成，是否需要人工介入的严重程度阈值也由另一个 Agent 决定，那么这套系统只是完成了更多层的“自我检查”。它不等于真的有人看过，更不等于有人愿意承担结果。
反过来，一个架构很简单的 Loop，也可以有明确的责任边界：限制 diff 大小，不允许修改对外契约，并在合并前必须交给具名评审者。这里的约束不是为了给 Agent 增加仪式，而是为了把人的评审成本压缩到一个可处理的范围。
组织方式与监督责任：两个相对独立的维度
- Loop 或 Graph 决定系统如何执行、协作和收集证据。
- 自动或人工监督决定谁做最终判断、谁为结果负责。
结论：未来工程师设计的是责任流，而不是代码流
这个视角改变了看待“便宜改动”的方式：AI 可以把第一次尝试变成一种低成本的探价，但最终成本仍取决于人能否理解和拥有结果。
下一阶段值得培养的能力，不再只是设计一张能让更多任务“自动完成”的图，而是设计一张让人知道何时必须介入，并在介入时能快速形成判断的图。这里至少有三件事：
- 定义硬性边界：自动放行和必须人工评审的边界，应该由改动的语义和责任决定（如触碰计费、隐私等逻辑），而不是只看 diff 行数或某个 Agent 给出的风险分数。
- 让决策可审计：图式系统不能只留下“无需人工评审”的结论，还要展示它匹配了哪条规则、排除了哪些风险，以及规则最后由谁维护。
- 打包证据：利用图的分工缩小人的工作。送到评审者面前的不该是整条工作流的状态，而是一个清楚的证据包：具体 diff、影响范围，以及相对上一个已批准版本发生了什么变化。
以前，人负责生产代码，机器负责执行代码。而在未来，当机器开始高效生产代码时，人类开始设计验证流程与责任系统。
真正值得问的或许不是“我们该用 Loop 还是 Graph”，而是：当系统已经能自己完成这么多事时，人的判断究竟在哪个节点介入？如果它没有介入，谁愿意为这个决定负责？