继 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。一个真实的 AI 系统往往同时包含检索、规划、路由、并行模型调用、聚合与验证，真正决定系统行为的，已经是多个 Prompt 与工具之间的组织结构。研究者因此认为，工程单位正在从单一字符串逐步扩展到 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是否属于 Prompt Graph，也取决于具体实现方式。硬编码的 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 之间的结构、依赖关系与执行方式。