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

钢镚 · 2026-07-30

过去两年，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 第四问：是否需要多个角色并行？如果需要。才考虑图工程。例如：市场研究。产品设计。技术开发。风险审核。这些任务天然包含多个视角。让一个智能体完成所有事情，往往会产生认知冲突。拆成多个角色，反而更有效。但很多简单任务，并不需要多智能体。一个循环已经足够。