现在写提示词，必须知道什么是Prompt Graph Engineering ｜最新

继Loop Engineering、Graph Engineering等概念进入讨论之后，一篇2026年7月底发布的论文又提出了一个更贴近Prompt本身的工程概念：Prompt Graph Engineering，提示词图工程。

它关注的已经不是“怎样把一个Prompt写得更好”，而是怎样把多个Prompt、模型调用和工具组织成一张显式、可执行、可维护的Graph。当Prompt从一段文本变成系统中的一个节点，工程对象也开始从“写好一句提示词”，扩展到设计Prompt之间的结构与关系。

这篇论文的价值在于，它没有停留在提出一个新名词上。研究者进一步给出了Prompt Graph Engineering的四个必要且充分条件，并将其转化为一套可以直接判断LangGraph、DSPy、AutoGen、CrewAI乃至Claude Code等真实系统的测试方法：什么才算Prompt Graph Engineering，什么只是看起来像Graph。

什么是Prompt Graph Engineering？

传统Prompt Engineering关注的是一个Prompt怎么写，Prompt Graph Engineering关注的则是：多个携带Prompt的计算节点，应该怎样组成一个可执行、可维护的Graph。

研究者将其定义为：把Prompt参与的语言模型计算表示、组合并执行为一个显式Graph。其中Node可以是Prompt参数化的模型调用，也可以是确定性转换；Edge负责表达数据依赖或控制依赖。关键不在于系统里“有很多Prompt”，而在于这些Prompt之间的关系是否真正成为一个可以识别和操作的工程对象。

为什么现在需要这个概念？因为现代LLM应用早已不再只有一个System Prompt。一个真实系统可能同时包含检索、规划、路由、并行模型调用、聚合和验证，决定系统行为的已经是多个Prompt与工具之间的组织结构。研究者因此认为，工程单位正在从单一String逐渐扩展到Graph：Prompt位于节点，数据与控制依赖位于边。

问题在于，“Graph”在LLM领域一直指向不同对象：Graph of Thoughts描述模型生成的Thought拓扑；Multi-Agent System可能在运行时涌现出Agent交互拓扑；LangGraph、Prompt Flow中的Graph则是工程师显式定义、由Runtime执行的程序结构。

如果这些都被笼统称为Graph，我们就无法准确讨论Graph Structure本身是否改善了系统，也无法比较DSPy Program、Agent Conversation和LangGraph StateGraph。于是这篇论文真正要解决的问题变成了：

满足什么条件，一个系统才真正属于Prompt Graph Engineering？

Prompt为什么会走向Graph？

Prompt Graph并不是突然出现的新结构，它来自两条逐渐汇合的技术路线。

第一条来自传统计算系统。早期Dataflow、Make和Scientific Workflow早已把程序组织成Graph，由Node执行计算、Edge表达依赖。这套体系留下了三个关键思想：计算与编排分离、显式依赖带来并行能力、Graph本身成为可保存和检查的工程对象。

另一条来自Prompt自身的发展。Few-shot、Instruction Following最初仍围绕单次调用，随后Least-to-Most、Decomposed Prompting开始把复杂任务拆成多个调用。一旦出现多个调用，工程问题自然从“Prompt怎么写”扩展成“这些调用怎样连接”。

之后结构又分成两个方向：

• Thought Topology路线：Chain-of-Thought、Self-Consistency、Tree of Thoughts、Graph of Thoughts逐渐把模型生成的中间Thought组织成链、树和图。这里的Node主要由模型生成。
• Engineering Artifact路线：AI Chains、PromptChainer、DSP/DSPy、LLMCompiler、LangGraph、Prompt Flow等把多个调用变成工程师可以定义、执行、保存和优化的结构。这里的Node主要由工程师定义。

因此Prompt Graph Engineering与Graph of Thoughts最核心的区别并不是“有没有Graph”，而是Graph是谁设计的、Node是谁定义的。前者把Graph作为程序Artifact，后者主要把Graph作为推理或搜索拓扑。

研究者还指出，多个Prompt组成结构的工程实践其实早于“Graph”这个词在LLM领域流行。AI Chains等工作在2021—2022年已经出现，而Graph of Thoughts在2023年推动“Graph”进入公共词汇，随后工程系统迅速吸收了这一表达。Prompt Graph Engineering因此更像是在给已经存在但缺乏统一边界的实践补上正式定义。

第一张图展示了这条历史：传统计算图与Prompt路线经过任务分解后分流为Thought Topology和Engineering Artifact，最终走向可以被编译和优化的Graph。

论文第二张图则把结构变化压缩成四种形态：Single Prompt → Chain → Tree → Graph。Chain允许调用串联，Tree允许分支，Graph进一步加入Routing、Parallelism、Aggregation和Cycle。真正增加的不是Node数量，而是结构的自由组合能力。

Prompt Graph必须满足四个条件

研究者给出了Prompt Graph Engineering的四个必要且充分条件：

• G1 显式结构。 系统中的节点和连接关系必须能够在执行前被明确识别和列出；如果所谓的“图”只有运行结束后才能从日志中还原出来，就不满足这一条件。
• G2 结构与Prompt内容分离。 修改某个节点中的Prompt，不应迫使整个Graph一起重写；调整Graph结构，也不应要求重新编写所有Prompt。结构和内容必须能够独立变化。
• G3 可执行语义。 Graph不能只是一张架构示意图，而必须真正参与系统执行，由运行时根据Graph决定节点调度、条件分支、状态传递、并行执行和循环等行为。
• G4 一等工程对象。 Graph必须独立于某一次执行而存在，可以被保存、查看、版本管理、检查、评估和优化，而不是随着一次任务结束就消失。

四项缺一不可。论文进一步把它们转化为T1—T4测试：Graph能否在执行前被明确列出？结构与Prompt能否独立修改？系统是否真正按照Graph运行？Graph能否作为独立对象被其他工具继续处理？ 四项全部满足，才属于Prompt Graph Engineering。

这里判断的是“算不算Prompt Graph”，而不是“这个Prompt Graph做得有多成熟”。例如，一个只有“检索—生成—验证”三个节点、用YAML明确保存结构的简单系统，只要满足上述四项条件，同样属于Prompt Graph Engineering。它和DSPy、LangGraph之间的区别，是工程成熟度，而不是概念归属。

Prompt Graph和现有概念是什么关系？

四个条件的意义，在于它终于能把几个经常混在一起的概念分开。

• Prompt Engineering研究Node内部：措辞、Few-shot、格式和Prompt Pattern；Prompt Graph Engineering研究Node之间的结构。前者不会被后者取代，而是成为Graph中的局部工程。
• Graph of Thoughts虽然有Graph，但Node主要是模型生成的Thought；Prompt Graph的Node则由工程师定义。前者更接近Inference Strategy，后者是Engineering Artifact。
• Multi-Agent System不一定属于Prompt Graph。如果Agent之间的调用关系只在运行时临时产生，它只是Emergent Structure；只有Interaction Flow被显式表示为State Machine或Graph后才跨过边界。
• RAG也取决于实现方式。硬编码的Retrieve→Generate可能不满足T1；如果Router、Retriever、Generator、Verifier等被提升为显式、可执行、可版本化Graph，就属于Prompt Graph Engineering。
• 传统Workflow Engine已经拥有Graph、Runtime和Artifact，但Prompt Graph的Node包含Prompt参数化的LLM调用，因此必须额外处理随机输出、自然语言参数、Token Cost、Latency和语义验证等问题。

可以把边界压缩成一句话：

传统Prompt Engineering有Prompt但没有Graph；传统Workflow有Graph但没有Prompt语义；Thought Topology有Graph但Node由模型产生；Prompt Graph Engineering要求工程师显式拥有这张Graph。

LangGraph、DSPy都算，CC为什么不算？

论文用T1—T4检查了六个真实系统，结论并不是按“是不是Agent框架”来划分，而是看它们是否真的满足Prompt Graph Engineering的四个条件。

• LangGraph：四项全部通过。 StateGraph可以显式定义节点和连接关系，运行时原生支持状态管理、条件分支、循环、中断和检查点，因此它在可执行语义这一项上最完整。
• DSPy：四项全部通过。 程序结构、节点输入输出定义与Prompt优化彼此分离，优化器可以直接对整个程序进行调整，因此它在Graph作为独立工程对象这一项上最突出。
• Prompt Flow：四项全部通过。 它用YAML显式描述DAG，Prompt模板与流程结构分离，整个流程可以被执行、可视化、版本管理和评估；主要限制是对循环结构的原生支持较弱。
• AutoGen、CrewAI：部分通过。 普通对话或任务委派往往是在运行过程中临时形成，因此不完全满足显式Graph的要求；只有GraphFlow、Flows这类把流程明确表示出来的模式，才进入Prompt Graph Engineering。论文判断的是具体运行模式，而不是给整个框架统一贴标签。
• Claude Code Subagents：被排除。 Subagent本身虽然是预先定义好的Prompt单元，但由哪个Subagent执行、什么时候执行、结果交给谁，都是由主Agent在运行过程中临时决定的。整个委派关系无法在执行前被完整列出，因此T1、T3和T4都不成立。

这并不是性能高低的判断。Claude Code强调的是动态委派能力，Prompt Graph Engineering强调的是显式、可执行、可保存的Graph结构，两者解决的是不同工程问题。

论文也保留了两个限制：这份分类基于2026年7月的产品状态，框架升级后结果可能变化；同时，目前分类由单一分析者完成，还缺少第二位分析者进行一致性验证。

结语

Prompt正在从一段独立文本，变成复杂AI系统中的一个节点。

当系统只有一次模型调用时，工程重点是“Prompt怎么写”；当系统开始包含检索、路由、并行、验证和循环时，问题就变成了“这些Prompt应该怎样组织”。

Prompt Graph Engineering因此关注的不只是Prompt内容，而是Prompt之间的结构、依赖与执行方式。

文章来自于"AI修猫Prompt"，作者 "AI修猫Prompt"。