什么是提示词工程、Loop 工程以及 Graph 工程？

目录

提示词工程、Loop 工程、Graph 工程——这三个词最近总被摆在同一张表里比较，好像在让人三选一。但它们根本不在同一个层面上。搞清楚这件事，比学会其中任何一个都值钱。这一篇不聊具体工具，只把三层各自在管什么、天花板在哪讲清楚，最后给你三个问题，帮你判断手上这件事该归哪一层管。

三个词，三条各自长出来的线

先说说这三个词是怎么冒出来的，因为它们的来路完全不同。

提示词工程这两年被重新命名了一次。早期讨论的是”怎么把一句话写好”——加什么角色设定、用什么口令。后来大家发现真正决定效果的不是措辞，是这一次到底给模型看了什么，于是有了 Context Engineering 这个更准的说法。

Loop 工程是随着 Ralph 那类做法在社区流传起来的。做法简单得有点出乎意料：一行 while 循环，反复把同一段指令喂给模型，让测试来判对错，跑够多轮，能过验收的那一版自己就出来了。

Graph 工程跟着 LangGraph 这类编排框架进入视野，主张把 Agent 的执行路径显式画成图——谁调谁、能不能回退、哪里必须停。

三条线是各自长出来的，最后被人摆进同一张表里做对比。问题恰恰出在这张表上——它们压根不是一类东西。

🧱 它们根本不在同一层

正确的关系不是并列，是层叠：

层	关注什么	控制粒度
Graph 工程	路径怎么组织	阶段级
Loop 工程	迭代怎么收敛	轮次级
提示词工程	单次怎么沟通	Token 级

但这里要补一句，否则就会踩进另一个坑：分层关系成立，不等于每层都必须有。

脑子里一旦装进”标准三层架构”，很容易见到任务就想套满三层。实际上大量跑得很好的系统只有一层或两层：

形态	什么时候是这样
只有提示词	单次分类、抽取、改写——上任何编排都是负收益
提示词 + Loop	靠测试兜底反复迭代，路径根本没画过
提示词 + Graph	路径能全枚举，不需要自主迭代
三层齐全	生产级的研发工作流

Anthropic 在《Building effective agents》里给的原则很实在：从最简单的方案开始，只在效果明显改善时才增加复杂度。

所以正确的心智模型不是”三层架构”，而是——三个可选的嵌套层，默认从最底层开始，往上加是有代价的。

🔍 逐层看：每一层到底在管什么

下面三段，每层讲四件事：是什么、怎么做、一个容易犯错的关键点、天花板在哪。

提示词工程：决定这一次模型看到什么

它已经不只是”把话说漂亮”了。真正要管的是：这一次让模型看到哪些东西，又不让它看到哪些。

演进的原因很直接：任务一旦跨越多轮推理，光靠单句措辞就不够了，重点转向管理整个上下文状态——系统指令、工具定义、外部数据、历史消息等等。

具体到做法上，无非这么几种。系统提示要写在一个合适的高度：具体到能指导行为，又不至于把每种情况都写死——太细的规则一旦遇上没预料到的场景就会互相打架，太笼统又等于没说。工具描述要写清楚各自管什么，功能重叠的工具越多，模型越容易出错。输出格式提前约定好，省得后面拿正则去匹配。示例给一组多样化的，比堆一堆边界情况有用。

一个容易犯错的关键点：上下文不是越长越好。塞得越满，中间那部分越容易被稀释掉——这是实打实会发生的衰减，不是”模型不够聪明”。注意力是有预算的，往哪儿花是个取舍问题，不是”给得越多越保险”。想清楚哪些东西这一次根本不必让模型看见，往往比想清楚该说什么更省事。

天花板：它是软约束。模型未必完全听你指挥，而且你当场也未必能完全看出来。

这一层最大的优势和最大的问题其实是同一件事——改一句话就能见效，所以也就只能靠模型的意愿。

Loop 工程：一个任务，加一次校验

这一层有句话可以当公理用：

A loop is a task with a check. A task without a check is just hope.
一个循环 = 一个任务 + 一次校验。没有校验的任务，只是许愿。

Ralph 的形态前面提过了，核心就那一行 while。但真正的设计不在循环里，在配套的文件里，一共三份，各管一段：一份规范，写清楚这个项目要做成什么样、什么不许做；一份进度清单，记录哪些做完了、下一步该做什么；还有一份每轮都原样喂进去的指令，告诉模型”先读前两份，再挑一件事做”。循环本身没什么技术含量，难的是把这三份文件写对。

一个容易犯错的关键点：每轮上下文完全刷新，模型是失忆的——它压根不记得上一轮干了什么。这听起来像缺陷，其实是特性。失忆保证了每轮都从干净状态出发，不会把上一轮的错误理解一路带到后面。代价是所有跨轮次的记忆都得落到磁盘上，也就是那份进度清单——它不是给人看的备忘录，是模型下一轮唯一的记忆。

循环信号从哪来：循环靠什么知道该停？需要有自动判定的信号——比如测试的退出码、编译结果、类型检查。只有一句”我看着挺好的”，不能算数，因为这句话没法做条件判断，必须要有明确的信号量。

典型的翻车方式有两种，一种是空转（死循环）：模型每轮都觉得自己干了点什么，实际上什么也没推进，token一直在烧，却没有产出任何有用的结果。另一种是重复劳动：它没找到上一轮已经做好的东西，以为还没做，于是又做了一遍——就像装修师傅没看见昨天铺好的管子，把地刨开又铺一次。

天花板：没有验证信号的循环，是在批量生产垃圾。而且它的失败最难发现——它一直在跑，但方向是错的。

Graph 工程：不能混淆的图

这一层得先解决一个歧义。同样叫”图”，其实在说两个完全不同的内容：

• 编排图：LangGraph 那一类，画的是流程该走哪条路
• 知识图：GraphRAG、代码关系图那一类，画的是实体之间是什么关系

同名不同物。这一篇讲的是前者，编排图。后者会在这个系列的第 7 篇单独讲。

编排图干的事，是把”这活按什么顺序走”从脑子里搬到纸面上：谁接谁的活、哪一步能退回去重做、哪一步必须停下来等人点头。

常见的走法就五种，每种对应一类活：

• 串行：一步做完接下一步。写代码就是这样，先出设计，再写测试，最后写实现。
• 路由：先看是什么类型，再决定交给谁。工单进来先分类，退款的走退款流程，报障的走报障流程。
• 并行：几件互不相干的事同时开工，最后汇总。同一份代码分头查安全、查性能、查可读性，查完合并意见。
• 编排者带执行者：一个负责拆活分活，一群负责埋头干。
• 评估-优化：干完再过一道评审，不合格打回去重做。

真实系统基本都是这几种拼起来的，不用自己发明新花样。

画图还有两个常被忽略的好处：一是可恢复——图上每个节点都能存档，跑挂了从最近的存档点续，不用从头再来；二是可审计——事后能说清楚”当时为什么走了这条路”，这在需要审计的场景很关键。

一个容易犯错的关键点：它规定的是”不许走哪条路”，不是”该怎么做”。这条很重要，后面会单独说。

天花板：它只能表达你事先想到过的东西。需要现场判断的、之前没见过的情况，图一律无能为力。还有个隐性成本——图画好之后就变成了负担，现实一变就得改图，改图比改一句提示词成本高得多，所以事先要规划好。

🏠 用装修来类比

下面我们用装修做下类比：

概念	装修里对应什么
提示词工程	你怎么跟师傅交代要做什么
Loop 工程	干完 → 验收 → 不合格 → 返工 → 再验收
验证信号	监理的靠尺、水平仪、闭水试验
Graph 工程	施工顺序规范（水电 → 防水 → 闭水 → 贴砖 → 木工 → 油漆）
人工介入点	关键节点业主到场签字
每轮上下文刷新	每天早上换一个新的装修师傅

三句话说明白各自的特点：

提示词是交代。“主卧朝北那面墙，米白色，刷两遍，边角贴美纹纸。”成本为零，立刻见效，但师傅可能觉得差不多就可以了，而你当场看不出来问题。

Loop 是返工机制。 光交代没用，得有验收。这里的关键不是”返工”两个字，是靠尺——没有靠尺的返工，只是重复施工。

Graph 是施工顺序。 它不告诉你墙该刷什么颜色，它只让”不做防水直接贴砖”这件事在流程上不可能发生。

一句话记住三者的分工：顺序管住不许干什么，返工逼着干到合格，交代决定具体怎么干。

⚖️ 三种脾气，三种翻车方式

	提示词工程	Loop 工程	Graph 工程
控制权归谁	模型	模型（人只定终止条件）	人（人画路径，模型填空）
确定性	低	最低	高
前期投入	极低	低，但要先建验证体系	高
单位成本	1x	4x，多 Agent 15x	2–3x，但少走弯路
可调试性	好	最差	最好
典型失败	模型不听	跑偏且没人发现	图画错了，或者太僵硬

成本那一行说明一下：Agent 约 4x、多 Agent 约 15x 出自 Anthropic 的公开说明，Graph 的 2–3x 是公开资料里流传的粗略估计。这些是量级参考，不是实测值。

这张表里最值得琢磨的是最后一行。三种失败方式完全不同：提示词的失败你看得见——它没照做，摆在那儿；Loop 的失败你看不见——它一直在跑，只是方向错了；Graph 的失败你改不动——图定死了，现实变了。

后两种比第一种难对付得多，而它们恰恰是往上加层之后才会出现的新问题。这也是”往上加是要付代价的”这句话的具体含义。

🚧 两个容易犯错的地方

Graph 不做规划，它做的是负向约束

很容易把三层理解成一条指挥链：Graph 规划、Loop 执行、Prompt 实现。但图里一个字都没说”该怎么做”，它只宣布”不许跳过测试直接写实现”。至于这个设计该拆成哪几个模块、实现该先写哪个文件——那些才是真正的规划，而它们发生在下面两层。

换个说法可能更好懂：

轨道说了算的是能去哪、哪儿必须停，但它不管你这趟出门要办什么事。
引擎只负责往前推，一直推到终点，或者撞上停车信号。
方向盘在轨道给的余地里，决定具体怎么走。

轨道从不替你规划行程，它只是让”往旁边开”这件事根本做不到。

层级越高，能力反而越弱

顺着”顶层、底层”的说法，很容易觉得上层更重要。实际恰好相反——控制力越强，表达力越弱。Graph 只能表达你事先想到过的东西，一旦现实超出图的想象，它帮不上任何忙。

再往深一层说：这三层没有任何一层在”实现”什么。真正干活的从来是模型本身，三层只是塑造模型行为的三种手段——Graph 用结构，Loop 用重复和验证，提示词用语言。

这就意味着，模型变强，上面两层的必要性会缩水。这套东西的价值，某种程度上是在补模型当前的短板。

✅ 选型三问

如果这篇你只带走一样东西，我希望通过下面这三个问题，帮助你做选型：

第一问：错了，机器能自动发现吗？

能 → 上 Loop。测试、编译器、类型系统都可以当靠尺。
不能 → 别上，无论它看起来多诱人。没有验证信号的循环是在批量生产垃圾。

判断标准很朴素：把”做对了”这件事，能不能写成一条跑完会给你退出码的命令？写得出来就能循环，写不出来就别循环。

第二问：我现在能把流程图画出来吗？

画得出来，而且这套流程还要反复用、要能查账、要留几个人工点头的地方 → 上 Graph。
画不出来 → 别硬画。

这里说的”画不出来”，指的是那种连要走几步都说不准的活：可能三步搞定，也可能来回折腾二十步，全看中间遇上什么。这种活本来就该让模型自己边走边判断，硬画一张图只会把它框死。Anthropic 给的建议也是这个意思——步数没法预估的开放问题，交给 Agent 自己跑，别拿固定流程去套。

还要注意，问的是”现在能不能画”，不是”以后能不能画”。想清楚了再画，图才管得住事；边跑边补的图，只是把混乱换个形式记下来而已。

第三问：上面两个都不需要？

那就用提示词工程。这不是妥协，这是正解。 一个单次的分类任务，套上循环和编排，只会让它变慢、变贵、变得更难查错。

下一篇：有没有一个真东西，三层是同时长出来的？

概念到这儿就讲完了。最后留一句话，它会一直贯穿这个系列。

提示词这一层只能”要求”，给不了”保证”。你写一句”省着点花 Token”，模型多半会照做，但它真超了，你也拦不住——因为这句话没有任何强制力。

想要保证，就得换一层手段。比如设一条硬线：这一趟花超多少就自动停。这条线不跟模型讲道理，也不管它愿不愿意，到了就停。

所以：你要的如果是”保证”，提示词这一层给不了，得往上挪一层。

下一篇聊一个具体的东西——我自己在做的 pdlc-skills，为什么它天然落在这三层上。

---

想自己试一下：

curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
  | bash -s -- --global

项目主页：kanfu-panda.github.io/pdlc ｜ 源码：github.com/kanfu-panda/pdlc-skills

觉得有用的话，给个 star 是对我最大的支持 ⭐

---

如果这篇帮你把三个概念捋清了，点个赞或者加个关注；

要是身边也有人正被这几个概念困扰，转发给他。