Loop Engineering 之后，Agent Graph 才是 AI 编程的下一层结构

AI 编程的重心正在从“写好一句提示词”转向“设计能持续工作的系统”。过去一年，Loop Engineering 把这个变化讲清楚了：开发者不再反复手动提示 Agent，而是给它一个目标、一个检查方式和一个继续迭代的循环，让它在多轮执行中把任务推进到完成。

但循环不是终点。Peter Steinberger 提出的“从 loop 到 graph”真正有价值的地方，是把单个 Agent 的反复尝试，升级为多个 Agent、多个职责和多个依赖之间的组织方式。循环让行为可编程，图让协作可编程。

Loop 解决的是持续推进

早期的 Agent 使用方式很像聊天：你发一句，它做一步，然后等你判断下一步。Loop Engineering 改变的是控制权。一个循环会把目标、约束、检查条件、历史压缩和下一轮行动放进同一套机制里。任务没完成，就继续运行；证据不足，就补验证；测试失败，就回到修复。

这类方式适合迁移、性能优化、批量清理、测试补齐、文档更新等工作。它的优点是认知负担低：人只要定义结果和边界，Agent 负责反复靠近结果。

Graph 解决的是职责边界

循环跑得久以后会遇到另一类问题：一个 Agent 什么都管，容易把计划、执行、验证、回滚、发布混在一起。Graph 的意义不是把流程画得更复杂，而是承认复杂任务本来就有多个角色：有人负责代码，有人负责测试，有人负责安全，有人负责部署，有人负责最后裁决。

更成熟的 Agent 系统至少需要两张图：组织图定义谁长期负责什么领域，工作图定义当前任务如何拆分、依赖和流转。组织图保留上下文，工作图随任务生成和消失。

为什么这对开发者重要

如果只是修一个小 bug，loop 已经够用。但当任务变成长周期迁移、跨仓库重构、多站点发布或生产事故排查，图结构会更可靠。它迫使系统提前声明：哪个分支能并行，哪个步骤必须等测试通过，哪个 Agent 可以改生产配置，哪个动作需要人工确认。

这也是从个人效率工具走向工程系统的分水岭。提示词优化关注的是模型怎么回答；循环工程关注的是模型怎么持续做事；图工程关注的是多个 Agent 如何在边界内协作。

落地时不要先追动态组织

动态 Graph 听起来诱人，但第一步应该很朴素：把常见任务拆成固定角色，把完成条件写清楚，把验证命令机器化，把日志和决策留下来。等固定图能稳定运行，再考虑让系统根据证据调整依赖关系。

真正有用的 Agent Graph，不是多几个头像在聊天，而是能让责任、上下文、权限、证据和失败处理都可追踪。Loop 时代没有结束，它正在成为 Graph 的一个节点。