prompt工程 vs loop工程 vs graph工程：每一层到底改变了什么

过去两年，AI 工程领域不断出现新的关键词。

最早被大家熟知的是提示词工程（Prompt Engineering）。后来，上下文工程、工具链工程逐渐进入视野。到了 2026 年，循环工程（Loop Engineering）和图工程（Graph Engineering）又成为开发者讨论的热点。

很多人把它们看成一场技术路线竞争。

其实不是。

它们更像是一套逐层叠加的控制系统。

• prompt 解决的是：一次模型调用，应该如何回答。
• loop 解决的是：一个智能体，应该如何持续完成任务。
• graph 解决的是：多个智能体，应该如何分工协作。

层级越高，控制范围越大。但下面的能力不会消失。

一个智能体拥有循环之后，提示词依然存在，只是它从一次性的指令，变成了整个执行系统中的一个组件。

理解这三层关系，是理解未来 AI 应用架构的关键。

01 从prompt到graph，AI 工程到底发生了什么变化

1.1 第一阶段：提示词工程解决“怎么回答”

提示词工程的核心，是设计一次模型交互。

工程师需要告诉模型：

你是谁。

你要完成什么任务。

你应该遵循什么规则。

你应该以什么格式输出。

早期的大多数 AI 应用，本质都是这个模式。

用户输入问题，模型生成答案。

如果结果不好，人修改提示词，再试一次。

这种方式简单直接，也非常有效。

尤其是在任务边界清晰、人工能够及时检查结果的场景里，提示词依然是成本最低的解决方案。

但它有一个天然限制：

它默认有人站在循环之外。

有人观察结果。

有人判断质量。

有人决定下一步怎么做。

一旦任务变成连续执行，比如自动写代码、分析数据、调用工具、修改文件，单次提示词就很难支撑。

1.2 第二阶段：上下文工程解决“给模型什么信息”

提示词之后，工程重点开始转向上下文。

问题不再只是：

“我要怎么告诉模型？”

而变成：

“模型真正需要知道什么？”

上下文窗口有限。

每一个 token 都有成本。

如果把所有资料全部塞进去，模型未必更聪明，反而可能被大量无关信息干扰。

因此，上下文工程关注的是信息筛选。

哪些内容应该进入模型？

哪些内容应该被隐藏？

哪些信息需要实时获取？

哪些信息需要长期保存？

这一步，本质是在管理模型的认知资源。

1.3 第三阶段：工具链工程解决“模型如何行动”

当 AI 开始执行任务，仅靠文字交流已经不够。

它需要工具。

比如：

读取文件。

查询数据库。

调用 API。

运行代码。

修改项目。

于是出现了工具链工程。

工具链决定了智能体所在的工作环境。

模型不再只是回答问题，而是进入一个可以行动的系统。

但工具链仍然缺少一个关键能力：

它知道有什么工具，却不知道应该如何持续推进目标。

02 loop 工程：让 AI 从回答者变成执行者

loop 工程真正改变的是 AI 的工作方式。

以前，人和模型之间是一问一答。

现在，模型需要进入一个持续循环：

观察。

行动。

验证。

修正。

再次行动。

这就是智能体（Agent）的基本运行模式。

2.1 loop 的核心不是行动，而是反馈

很多人误以为，智能体变强，是因为它能调用更多工具。

其实更关键的是反馈机制。

一个普通模型：

输入问题。

生成答案。

结束。

一个智能体：

接收目标。

分析当前状态。

采取行动。

检查结果。

根据反馈调整策略。

区别不在于“会不会做”，而在于“能不能持续纠错”。

2.2 循环最大的难点：什么时候停止

无人监督系统最危险的问题，不是不会工作。

而是不知道什么时候应该停。

一个没有停止条件的循环，会不断消耗 token。

它不会主动告诉你：

“我已经完成了。”

它只会继续尝试。

因此，一个成熟的智能体必须定义完成标准。

例如：

测试全部通过。

输出符合 schema。

评分达到阈值。

第二个模型确认结果合格。

没有停止条件的循环，本质上只是自动运行，而不是自动完成。

2.3 loop 工程包含哪些关键组件

一个完整的智能体循环，通常包含几个部分：

① 自动化触发

让任务能够按照时间或事件自动启动。

② 工作环境隔离

避免多个智能体同时修改同一份资源。

③ 技能库

把项目知识沉淀下来，避免每次重新解释。

④ 工具连接

让模型能够访问数据库、代码仓库、外部服务。

⑤ 子智能体

让不同模型承担不同角色。

例如一个负责执行，一个负责检查。

⑥ 外部状态

把重要信息保存在对话之外。

因为模型不会永久记住之前发生的一切。

循环工程的本质，是把一次提示词调用，升级成一个可以持续运行的小型系统。

03 grahp 工程：让多个智能体形成组织能力

loop 解决的是一个智能体如何持续工作。

但当任务复杂到需要多个角色协同，新的问题出现了：

谁负责分析？

谁负责执行？

谁负责检查？

失败之后，任务应该回到哪里？

这时候，单纯的循环已经不够。

系统需要一张“图”。

3.1 graph 工程改变的是智能体之间的关系

如果说循环工程关注的是：

“一个 AI 怎么把事情做完。”

那么 graph 工程关注的是：

“多个 AI 怎么一起把事情做好。”

这里的“图”，不是简单的流程图。

它描述的是智能体之间的连接关系。

包括：

• 节点是什么。
• 节点负责什么。
• 节点之间如何传递信息。
• 什么时候分叉。
• 什么时候合并。
• 什么时候结束。

一个简单的例子：

研究型任务可能需要：

一个研究员负责搜集资料。

一个分析师负责整理信息。

一个审稿人负责检查结论。

一个协调者负责分配任务。

这些角色之间的关系，就是一张图。

3.2 生产环境通常同时存在两张图

多智能体系统里，一个容易被忽略的事实是：

系统通常同时运行两张图。

① 组织图：回答“谁负责什么”

组织图比较稳定。

它类似公司的组织架构。

长期存在的智能体拥有固定角色。

例如：

• 产品分析智能体。
• 代码开发智能体。
• 测试智能体。
• 数据分析智能体。

它们不会因为一次任务结束就消失。

② 工作图：回答“现在正在做什么”

工作图则是动态的。

它随着具体任务生成。

比如：

用户要求开发一个新功能。

系统可能临时创建：

• 需求分析节点。
• 技术方案节点。
• 代码实现节点。
• 测试节点。
• 上线检查节点。

任务完成后，这些节点可能直接消失。

组织图负责稳定分工。

工作图负责灵活执行。

一个成熟的多智能体系统，需要同时管理两者。

3.3 graph 工程真正增加的，是系统设计能力

很多人认为，多智能体就是增加更多模型。

其实不是。

增加智能体很容易。

难的是设计它们之间的关系。

一个错误的设计：

让十个智能体同时思考同一个问题。

结果通常是：

• 更多成本。
• 更多冲突。
• 更多重复劳动。

一个好的设计：

让不同智能体承担不同认知任务。

例如：

• 一个负责发散。
• 一个负责验证。
• 一个负责执行。
• 一个负责挑错。

graph 工程的价值，不在于“更多 AI”。

而在于让 AI 之间形成有效协作。

04 三层架构，到底应该怎么选择

很多团队的问题不是不会使用 AI。

而是不知道什么时候需要升级架构。

实际上，可以按照几个问题判断。

4.1 第一问：有没有人持续检查结果？

如果有。

提示词工程通常已经够用。

例如：

写一篇文章。

生成一个方案。

总结一份资料。

只要人会检查输出，就没有必要马上引入复杂智能体。

因为循环带来的价值，不是让结果更漂亮。

而是减少人工监督。

4.2 第二问：“完成”能不能被自动判断？

如果不能。

不要急着做循环。

这是很多智能体项目失败的原因。

系统一直运行。

但是没人知道什么时候算完成。

例如：

“优化代码。”

这个目标太模糊。

优化到什么程度？

速度提高多少？

错误减少多少？

测试通过了吗？

如果没有明确标准，循环只是在不断消耗资源。

一个好的智能体，需要明确停止条件。

4.3 第三问：任务是否需要持续执行？

如果任务可以一次完成。

提示词通常更合适。

如果任务需要：

调用工具。

修改环境。

不断验证。

根据反馈调整。

那么循环工程更有价值。

比如：

自动修复代码。

自动分析数据。

自动运营任务。

这些场景天然适合循环。

4.4 第四问：是否需要多个角色并行？

如果需要。

才考虑图工程。

例如：

市场研究。

产品设计。

技术开发。

风险审核。

这些任务天然包含多个视角。

让一个智能体完成所有事情，往往会产生认知冲突。

拆成多个角色，反而更有效。

但很多简单任务，并不需要多智能体。

一个循环已经足够。