Loop还没跑稳,GraphAI又来了,学不完根本学不完

0 评论 787 浏览 0 收藏 9 分钟

Loop还没跑稳,GraphAI又来了,学不完根本学不完

写在前面

AI 编程圈这半年最容易让人疲惫的,不是模型太多,而是概念太密。Prompt engineering 还没完全消化,Context engineering、Harness engineering、Loop engineering 又排队进来,现在 Graph 又成了新词。

很多开发者第一反应都一样:这不就是工作流引擎换个名字吗?拆任务、表达依赖、失败重试,这些东西软件工程不是早就讨论过了吗?

但如果把这些概念放在一条线上看,会发现它们不是五个互相打架的新名词,而是一件事的连续迁移:谁来判断“下一步该做什么”。

从Prompt到Graph,搬走的是判断权

写 prompt 的时候,判断权几乎都在你手里。你告诉模型做什么、怎么做、做到哪一步停;模型像演员,你递一句台词,它演一句。

写 loop 的时候,判断权开始交出去一部分。你不再每一步都手动提示,而是给出目标、约束、验收标准,让 Agent 自己反复执行、检查、修正。去年有人用 bash 死循环驱动 Claude Code,从零写出一门编程语言,验证的就是这类思路:人不再逐步喂指令,而是设计一个能持续逼近结果的循环。

到了 Graph,事情又上了一层。你不只是在设计一个循环,而是在设计一组互相协作的循环:哪个 Agent 先跑,哪个结果作为下游输入,哪一步失败要回退,哪一步需要人工审批,哪类任务能并行。

这时你手里拿的就不是一句 prompt,也不是一条流水线,而是一张任务架构图。

Loop没有过时,只是变成了Graph里的砖

很多人听到 Graph,会误以为 Loop 被淘汰了。实际更准确的说法是:Loop 从主角变成了基础单元。

一个 Loop 适合解决“同一个目标反复逼近”的问题,比如自动修复测试、定时清理技术债、持续补全文档、反复生成并校验报告。它的优势是简单、稳定、容易复用。

但真实工程任务经常不是一条线。比如你让 Agent 做一次大型重构,它可能需要:

阶段
典型动作
为什么不能只靠单Loop
需求拆解
读任务、圈定范围、识别风险
需要决定后续分支
代码理解
扫目录、找调用链、读测试
结果会影响实现路径
实现修改
小步改代码、补类型、处理边界
需要和测试阶段互相反馈
验证回归
跑测试、看日志、定位失败
失败原因可能回到不同节点
交付审查
生成摘要、列风险、等人确认
高风险动作不能自动越权

如果这些节点都挤在一个循环里,Agent 很容易装糊涂:失败了就再跑一遍,跑偏了也很难解释偏在哪里。Graph 的价值,是把“谁依赖谁、哪步先哪步后、失败后回到哪里”提前画清楚。

成熟Agent系统里,至少有两张图

更成熟的 Agent 产品,往往不是只有一张大图,而是两类图同时存在。

第一类是长期组织图。它像排班表,定义哪些 Agent 长期负责哪些能力:代码理解、测试执行、浏览器操作、文档整理、安全审查、发布检查。这张图不应该频繁变化,因为它代表团队能力边界。

第二类是任务运行图。它像当天工单,针对某个具体任务临时生成:这次先读哪些文件、需要哪些工具、哪些节点可以并行、哪些节点必须等人工确认。任务结束后,这张图可以归档,也可以沉淀成模板。

对开发者来说,这个区别很关键。很多人做 Agent 时只写 prompt 和 tool list,结果系统一复杂就失控。真正该设计的是:

设计对象
解决的问题
角色图
哪些 Agent 长期负责哪些职责
任务图
当前任务如何拆解和调度
权限图
哪些节点能读文件、写文件、联网、提交代码
验收图
哪些结果要测试、截图、日志或人工确认

Prompt 是局部表达,Graph 才是系统结构。

Graph工程本质上是在管理脑力流水线

这个变化有点像一百多年前的科学管理。泰勒拿秒表拆解工厂动作,把体力劳动拆成标准工序;今天开发者在做的,是把脑力劳动拆成可交给 Agent 的任务节点。

这句话听起来不太舒服,但很现实。过去我们认为“分析代码、判断下一步、写方案、做验证”是一个人脑内连续发生的工作。Agent 出现之后,这些动作可以被拆开、记录、复用、并行和审计。

Graph 工程的核心不是“画图好看”,而是把隐性的脑力过程显性化:

  1. 把目标拆成节点。
  2. 把节点之间的依赖写清楚。
  3. 把每个节点的输入、输出和失败条件定义清楚。
  4. 把工具权限和人工审批放到正确位置。
  5. 把成功路径沉淀成模板,失败路径沉淀成回退策略。

这也是为什么 AI 编程工具会从“帮你写代码”走向“帮你管理一组能写代码的 Agent”。以后比拼的不只是单个模型多聪明,而是谁能把一支无人团队组织得更稳。

开发者现在该怎么学Graph

别一上来就追最复杂的框架。Graph 思维可以从日常工作里拆。

先选一个高频任务,比如修复单测失败、生成周报、给旧项目补 README、做一次小型重构。然后把它拆成节点:

节点
输入
输出
验收
定位问题
报错日志、相关文件
问题假设
能指出失败位置
制定计划
问题假设、项目约束
修改步骤
步骤可小步执行
执行修改
计划、源码
代码 diff
改动范围可控
运行验证
diff、测试命令
测试结果
失败能回到定位节点
交付总结
diff、测试结果
变更说明
能供人审查

把这张表写清楚,你已经在做 Graph 了。框架只是实现形式,真正值钱的是你对任务结构的理解。

常见问题

Q:Graph是不是新的工作流引擎?
A:它借用了工作流引擎的很多思想,但重点不只是流程编排,而是把 Agent 的判断、权限、反馈和失败恢复结构化。

Q:Loop还需要学吗?
A:需要。Loop 是 Graph 的基础单元。不会设计稳定循环,就很难设计稳定任务图。

Q:什么时候该用Loop,什么时候该用Graph?
A:单目标、线性、可反复逼近的任务适合 Loop;多角色、多依赖、多验收路径的任务更适合 Graph。

Q:个人开发者怎么开始?
A:从一个高频任务开始,把“输入、处理、输出、验收、失败回退”写成表格,再让 Agent 按表执行。不要一开始就追复杂框架。

本文由作者【易安说AI】,微信公众号:【易安说AI】,原创/授权 发布于平台,未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!