从 Loop 到 Graph：AI Agent 工作流为什么需要两张图

把 AI 编程理解成“问模型问题”，已经太窄了。更准确的说法是：开发者正在把 Agent 当成可以调度的执行单元，而不是一次性回答器。Loop Engineering 先解决的是“一个任务怎么自己往前跑”，Agent Graph 解决的是“多个任务怎么接起来不乱套”。

Loop 先管住一件事

一个好的循环，最少要有四样东西：目标、约束、检查方法和状态保存。没有目标，Agent 就只是在聊天；没有检查，Agent 可能一路说得很顺但其实做错了；没有状态保存，下一轮就会把前面的事情忘掉；没有约束，任务会越改越散。

所以 loop 的价值，不是“让 AI 多跑几轮”，而是把反复执行这件事变成工程动作。它适合做 refactor、测试修复、批量清理、研究整理、内容生产这些会反复试、反复改的工作。

Graph 是把多件事排好

当一个任务不止一轮，就不能只靠一个大循环顶着。你需要知道哪些步骤可以并行，哪些步骤得等前一步结果出来，哪些失败了要回退，哪些必须人工拍板。这个时候，图比脚本有用得多。

图的好处不是看起来高级，而是把责任拆清楚。研究、实现、审核、部署、回滚，这些动作可以在不同节点里跑。每个节点负责自己的证据，下一步只在条件满足时继续。

最容易乱的地方

很多 Agent 系统看起来很自动，实际责任很混。谁能改生产？谁能删文件？谁只负责读？谁的输出必须被复核？这些问题不提前写清楚，系统越自动越危险。

还有一种常见问题，是 loop 一直在跑，graph 却已经失控。比如实现节点反复修，审核节点没有拿到完整 diff，部署节点又只看到了“已完成”三个字。这样看起来流程很多，实际证据是断的。

实际落地时怎么拆

可以先把任务拆成三类节点：收集证据、改动产物、验证结果。收集证据的节点只读，不改文件；改动产物的节点可以写，但不能部署；验证节点只看结果和证据，确认通过后再把状态交给部署。这样每一步的权限都比较清楚。

更稳的做法，是让 loop 负责推进单件事，让 graph 负责控制顺序和权限。这样 Agent 可以跑很久，但不会乱跑。成熟的 Agent 工作流，不是模型特别会说，而是系统把顺序排得明白。能跑、能停、能查证，才算真的有用。