Prompt/Loop/Graph 三层工程分层解析

三个概念，三种来源

这三个概念来自完全不同的地方，我们先从这里说起。

Prompt engineering 在发展过程中经历了一次更名。早期的讨论主要围绕措辞展开——用什么角色、指定哪些魔法词。后来人们意识到，决定结果的并不是措辞，而是模型能看到什么。因此更准确的说法开始流行：context engineering（上下文工程）。

Loop engineering 是随着 Ralph 风格的配置在社区中传播开来的。机制简单得近乎令人失望：一行 while 循环，反复向模型发送同一指令，由测试决定对错，经过足够轮次后，通过验收的版本自然浮出水面。

Graph engineering 随着 LangGraph 这类编排框架出现，它们主张显式地绘制 Agent 的执行路径——谁交接给谁、是否可以回退、哪里必须停下来等待人工确认。

三条独立的线索，最终被塞进了同一张对比表里。而问题恰恰就出在这张表上——它们根本不是同一种东西。

它们不在同一个层级上

它们的关系不是并排的，而是堆叠的：

这里必须先说清楚一件事，否则你会掉进下一个陷阱：栈是真实存在的，并不意味着每一层都是必需的。

一旦"标准三层架构"这个概念扎根在脑子里，每个任务看起来都像需要全部三层。实际情况是，很多运行良好的系统只有一层或两层：

Anthropic 在《Building effective agents》中提出的原则非常实用：从最简单的方案开始，只有在复杂度能切实带来改善时，才去增加它。

所以正确的心智模型不是"三层架构"，而是——三层可选的嵌套结构。默认从底层开始，要知道往上走是要付出代价的。

分层解析：每一层实际在管控什么

每层说四件事：它是什么、怎么做、人们容易搞反的一点，以及它的上限在哪里。

Prompt engineering：决定模型这一次看到什么

它早就不是"把话说得漂亮"这回事了。你真正在管理的是：这一次模型能看到哪些东西，看不到哪些。

这个演变的理由很简单：一旦任务跨越多轮推理，一句精心打磨的话就不够用了，工作的重心转向管理整个上下文状态——系统指令、工具定义、外部数据、消息历史，全部在内。

实际操作中只有几种常见手法。系统 prompt 需要处在合适的高度：足够具体以真正引导行为，但又不能把每种情况都写死——规则太细粒度，一旦出现预料之外的情况就会相互矛盾；规则太模糊，则什么也传达不了。工具描述需要说清楚每个工具的用途；工具之间的重叠越多，模型选错的频率就越高。提前约定好输出格式，这样后续不用临时写正则。多给几个多样化的例子，而不是堆砌边缘情况。

人们容易搞反的一点：更长的上下文并不等于更好的上下文。塞得越满，中间部分就越被稀释——这是真实的、可测量的衰减，不是模型"不够聪明"。注意力是一种预算，你把它花在哪里是一种权衡，不存在"多就是稳"这回事。搞清楚模型这一次不需要看到什么，往往比搞清楚要说什么更容易。

上限：这是一个软约束。模型未必完全听从你，而且当时你可能根本察觉不到。

这一层最大的优点和最大的问题都来自同一个事实——改一句话立即生效，但这也意味着你在依赖模型的配合意愿。

Loop engineering：一个任务，加一个检查

这里有句话可以当作公理：

Loop 是带检查的任务。没有检查的任务只是空想。

前面提到 Ralph 的形态：就是那一行 while。但真正的设计不在循环本身，而在围绕它的三个文件，每个各司其职。一份 spec，说明这个项目最终应该是什么样、什么不在范围内。一份 progress list，记录已完成和待完成的。还有一条指令，每轮原封不动地喂给模型：先读另外两份，再挑一件事来做。循环本身微不足道；把这三个文件做对才是难点。

人们容易搞反的一点：每一轮上下文都会被清空——模型对上一轮做了什么没有记忆。这听起来像是个缺陷。实际上是特性。失忆保证了每一轮都从干净的 slate 开始，所以一轮的错误理解不会被一路携带下去。代价是，任何需要跨轮次保留的东西必须存在磁盘上——那份 progress list 不是给人看的备注，而是模型进入下一轮的唯一记忆。

停止信号从哪里来：循环怎么知道自己做完了？它需要一个能自动判定的东西——测试退出码、编译器输出、类型检查。"看起来没问题"不算，因为你没法把它写进条件里。

它通常怎么崩掉，两种方式。一种是空转：每轮模型都觉得做了点什么，实际上什么都没推进，tokens 烧了一堆却毫无产出。另一种是返工：它找不到上一轮已经建好的东西，以为不存在，又建了一遍——就像一个承包商没看见昨天埋的管道，把地面刨开再铺一次。

上限：没有验证信号的 loop 是在批量生产垃圾。而且它的失败最难察觉——它一直在跑，只是方向错了。

Graph engineering：同一个名字，两个不同的东西

这里有个歧义需要先澄清。"Graph"在这里指的是两个完全不同的东西：

编排图（Orchestration graphs）：LangGraph 那类，绘制流程走哪条路径

知识图谱（Knowledge graphs）：GraphRAG / 代码关系那种，绘制实体之间如何关联

同一个词，指的是不同的对象。本文讲的是第一种。第二种会单独成篇——本系列第七篇。

编排图的作用是把"这个工作的先后顺序是什么"从你脑子里挪到纸上：谁接谁的处理结果、哪一步可以发回去、哪一步必须停下来等人点头。

常见的有五种形态，每种适合一类工作：

顺序执行（Sequential）：一步接一步。写代码就是这种方式——先设计，再测试，最后实现。

路由（Routing）：先分类，再决定谁来处理。工单进来，先分拣，退款走退款路径，宕机走宕机路径。

并行（Parallel）：独立的部分同时跑，再合并结果。同一份 diff 分别交给安全审查、性能审查、可读性审查三个视角去看，再汇总意见。

编排器加工作者（Orchestrator with workers）：一个拆分分配，多个埋头执行。

评估加优化（Evaluator-optimizer）：把输出过一遍审查；不过就打回去。

真实系统基本上都是这五种形态的组合。不用发明新的。

画图有两个容易被忽视的好处。一是可恢复性——每个节点都可以设置检查点，崩溃后从最后一个检查点恢复而不是从头来。二是可追溯性——事后能解释为什么走了那条路径，这在有人要追问时很重要。

人们容易搞反的一点：它规定的是哪些路径不能走，而不是工作怎么做。后面展开说。

上限：它只能表达你预先想到的东西。任何需要当场判断的、任何你没见过的情形——graph 都毫无用处。还有一个隐藏成本：一旦画好，graph 就成了负担，现实变化意味着重画。重画的代价远高于改一句话，所以开始之前值得好好规划。

同一个意思，换个说法——装修

我们用一个类比把三层都过一遍：

三句话对应三种特质：

Prompt 是简报。"主卧朝北的墙，米白色，两遍漆，边角贴美纹纸。"不花一分钱，立即生效——但承包商可能觉得差不多就行，而且你当时察觉不到。

Loop 是返工机制。光有简报不够，你需要检查。关键词不是"返工"，而是靠尺——没有靠尺的返工只是做两遍。

Graph 是工序序列。它不会告诉你墙应该刷什么颜色。它只是让"先铺砖后做防水"这件事在流程上不可能发生。

一句话概括三层如何分工：序列排除你做不到的、返工逼它达到标准、简报决定实际怎么做。

三种特质，三种崩法

关于成本那行说一下：agents 的约 4 倍和多 agents 的约 15 倍来自 Anthropic 的公开文章；graphs 的 2–3 倍是公开资料中流传的粗略数字。这些是量级参考，不是精确测量。

值得细看的是最后一行。三种失败模式截然不同：prompt 失败你能看到——它没照做，就在那里。loop 失败你看不到——它还在跑，只是方向偏了。graph 失败你改不了——图已经定死了，现实动了。

后两种处理起来要难得多，而这恰恰是你增加层次后会获得的新问题。这就是"往上走要付出代价"的具体含义。

两个容易搞反的地方

Graph 不做规划；它做负面约束

很容易把堆叠理解成一条指挥链：graph 做规划、loop 执行、prompt 落地。但 graph 对怎么做工作什么都不说。它只声明："不能跳过测试直接去实现。"这个设计拆成哪些模块、哪个文件先写——那才是真正的规划，发生在下面两层。

另一种说法：

轨道决定你能去哪里、必须在哪里停下——它对为什么出门毫无意见。引擎只会向前推，直到终点或停止信号。方向盘决定在轨道允许的空间里你实际怎么移动。

轨道永远不会替你规划行程。它只是让"开出轨"这件事变得不可能。

层越高，能力越弱

"顶层/底层"的框架让人感觉顶层更重要。实际上恰恰相反——控制越多，表达能力越弱。graph 只能表达你预先想到的东西，一旦现实超出了 graph 的想象，它一点办法都没有。

再深入一层：这三层都不实现任何东西。模型在做功。三层只是三种塑造模型行为的方式——graph 通过结构、loop 通过重复和验证、prompt 通过语言。

这意味着：随着模型变强，上面两层的重要性会下降。这一整套东西值多少，在一定程度上是模型目前缺什么的函数。

三个问题，帮你在层之间做选择

如果这篇文章只能让你记住一件事，就记住这三个问题：

问题一：如果错了，能被机器自动捕获吗？

能 → 用 loop。测试、编译器、类型系统都可以作为靠尺。不能 → 不要用，尽管看起来很诱人。没有验证信号的 loop 是在批量生产垃圾。

验证标准很简单："这是正确的"能写成一条以状态码退出的命令吗？如果能，你就能 loop。如果不能，就不要。

问题二：我现在能画出流程图吗？

能，而且这个流程需要被复用、可审计、有的人工节点 → 用 graph。不能 → 不要强求。

这里"画不出来"指的是那种工作，你甚至说不出它需要多少步：可能是三步，也可能是二十步来回，取决于发现了什么。这种工作应该让模型边走边判断，强行套上 graph 只是把它框死。Anthropic 的指引也是这个意思——步骤数量无法预测的开放性问题，应该交给 agent，而不是固定流程。

注意问的是"现在能画吗"，不是"最终能画出来吗"。graph 只有在你事先想清楚了才能约束任何东西；边走边打的 graph 只是换了一种写法乱成一团。

问题三：以上都不是？

那就用 prompt engineering。这不是妥协，这是正确答案。把一个单次分类任务包装成 loop 加编排 graph，只会让它更慢、更贵、更难调试。

下一篇：这三个概念有没有一个三者共同生长的真实场景？

概念部分就到这里。一句话收尾，也贯穿本系列后续内容。

Prompt 层只能请求，无法保证。你写"省着点用 tokens"，模型可能会照做——但一旦它超过了限额，你拦不住，因为这句话没有执行力。

如果你想要保证，你需要另一种机制。比如一条硬线：花到这个数额就停。这条线不跟模型商量，也不关心模型同不同意。

所以：如果你想要的是保证，prompt 层给不了你。它必须往上走一层。

下一篇讲点具体的——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 很有帮助 ⭐

如果这篇文章帮你理清了这三个概念，点个反应或关注都算数。如果你身边有人被这些词绕住了，转给他。

进一步的操作，你可以考虑屏蔽此人或举报滥用行为。