Source-linked AI summary
What makes prompts a graph: necessary and sufficient conditions for prompt graph engineering
Sandeco Macedo
TL;DR
现代语言模型应用是图，而非彼此孤立的提示；但该领域尚无对提示图工程的精确定义。本文提出四项必要且充分的条件，并将其应用于六个系统，发现该测试能稳定区分纳入、排除和部分符合的案例。
问题
该领域缺乏参考定义，用于规定提示何时构成显式、可执行的图，而非字符串、推理拓扑、智能体对话或编排产物。
方法
本文重构这一概念的谱系，提出四项构成条件，并将其操作化为纳入与排除测试。
结果
应用于六个系统时，该测试纳入以图为先的框架，根据运行模式区分 AutoGen，并排除缺乏一等图产物的涌现式委派。
要点与局限
该定义为检查、复用、执行和优化提示图提供了共享词汇，同时提出了有关结构质量与价值的经验问题。
要点与局限
分类由单一分析者完成，未进行复现或评定者间一致性检验；六个系统构成的样本可能无法推广到其他系统类型。
Abstract
from arXiv · showhide
Prompts stopped being isolated strings some time ago. In real systems, one model call feeds another, retrieval interleaves with generation, routers branch, and aggregators merge parallel results. Practice converged on a single structure to hold this together: the graph. Frameworks such as LangGraph, DSPy, and Prompt Flow expose it openly, and research systems already optimize it automatically. The vocabulary, however, lags behind. Graph names, variously, a reasoning topology inside one sampling strategy, a multi-agent conversation, or an orchestration artifact, while prompt engineering still evokes writing one good string. What is missing is a reference definition treating prompts as nodes of an explicit, executable, improvable graph. We build that definition through conceptual analysis over sources with persistent identifiers, complemented by primary grey literature. We reconstruct the genealogy of the idea, from dataflow graphs and build systems, through prompt chaining and the thought topologies (chain, tree, graph), to graphs compiled and optimized as artifacts. We then propose a constitutive definition of prompt graph engineering, state its four conditions (explicit structure, separation between structure and prompt content, executable semantics, and the graph as a first-class engineering artifact), and operationalize them as an inclusion and exclusion test. We draw the boundary against six neighboring concepts and apply the test to six real systems (LangGraph, DSPy, Prompt Flow, AutoGen, CrewAI, and Claude Code subagents); it includes and excludes consistently. We close with a research agenda organized along four design tension axes. The contribution is an operational definition and a shared vocabulary for a practice that industry already exercises daily without naming precisely.
1 引言
现代语言模型应用被设计为由检索、模型调用、路由、并行处理、聚合和验证构成的可执行结构，而不再是彼此孤立的 prompts。本文将 prompt graph engineering 定义为对这一结构进行显式化、可检查和可改进的工程实践，并将其与“graph”的邻近用法区分开来，在真实系统中检验这一界定。
- 动机: 工程单元已从单个 prompt 字符串转变为连接检索、规划、路由、并行调用、聚合和验证的结构。这一转变使 prompt 组合、执行和控制流成为工程核心问题。
- 谱系: Prompt 结构从单个 prompts 演化为人工整理的 chains 、单次生成内部的推理 chains 、分支 trees ，以及可合并、可循环的 graphs [1]。与此同时，声明式 pipelines、函数调用 DAGs 和 agent workflows 将这些结构转化为可执行或可搜索的程序 。
- 问题: “Graph”在 graph-of-thoughts [1]、multi-agent 对话轨迹 和编排实践中的含义仍然模糊，而 flow engineering 缺乏关于路由、合并和工件状态的明确标准。缺失的概念，是对携带 prompt 的节点如何组合、路由和执行进行工程化。
- 动机: 不透明的脚本和临时拼凑的 agent 对话无法被可靠地检查、进行类型检查、版本化或优化；相反，优化器要求该结构作为对象存在 。因此，有必要将 graph 视为一等工程工件，而非偶然的实现细节。
- 贡献: 本文贡献包括：梳理谱系；提出带有纳入/排除测试的构成性定义；划定与六个邻近概念的边界；对六个真实系统进行一致分类；以及提出按张力轴组织的研究议程。本文有意采取定义性取向：既不提出新框架，也不构建 benchmark，而是提供共享词汇和可复现的成员资格测试；经核验的 DOI 来源作为正式引文，产品文档则以脚注形式列出 。
2 相关工作
相关工作从五条研究脉络和三个较小的邻近领域围绕 prompt graph engineering 展开，但尚未定义其构成条件。本文将 prompt graph 定位为组合各次调用的内部结构，有别于驱动 agent harness 的外部循环 。
- 2 相关工作: 既有研究脉络和较小的邻近领域为 prompt graph engineering 提供了背景，但没有给出构成性定义。相关工作包括五条研究脉络，以及接口先例、术语和定义方法。
- 2 相关工作: Prompt engineering 综述系统梳理了针对单个 prompt 的技术，却未充分定义 prompt 本身的组合方式。
- 2 相关工作: Prompt graph 组织调用的内部组合，而外部循环则通过 agent harness 驱动 agent 。本文沿着从 prompt 到 context、harness 和 loop 的演进脉络展开 。
3 谱系（RQ1）
Prompt graph engineering 继承了基于图的计算传统：显式依赖将编排与计算分离，使工作流可并行化、可检查且可重新运行。其谱系随后分化为模型内部的推理拓扑与外部编写、可执行的组合，最终汇聚为可优化的图工件。
- 3 谱系（RQ1）: 基于图的计算早于 prompts，从数据流和构建依赖发展到科学工作流，其共享单元可以被审计并重新运行 。这些传统确立了图作为协调步骤的结构，同时避免将步骤焊接在一起。
- 3 谱系（RQ1）: 早期 prompt engineering 将 prompt 视为单个字符串，并通过少样本示例、指令遵循、推理线索、目录和综述逐步发展 。分解首先挑战了这样一种假设：一个字符串就是 prompt 设计的完整单元。
- 3 谱系（RQ1）: 一条谱系将结构保留在模型推理之中：chain-of-thought 是线性的，self-consistency 将多条链并行化，tree-of-thoughts 分支搜索，而 graph-of-thoughts 支持合并、细化和循环 [1]。这条谱系在生成过程内部发展推理拓扑，而不是在模型外部工程化工作流。
- 3 谱系（RQ1）: 另一条谱系将结构外化为编写的模型调用链、可视化节点—边编辑器、概率程序、异构节点和智能体工作流图 。这条工程谱系强调可组合性、可控性、形式语义和显式交互结构。
4 构成性定义（RQ2）
Prompt graph engineering 由四项必要条件界定：显式图结构、结构与 prompt 内容可分离、可执行语义，以及作为一等工程制品的地位。该定义形成一项纳入测试，要求同时满足四项条件，同时排除可视化编辑器、无环性、多模型、框架或 agent 等偶然特征。
- 参考定义: Prompt graph engineering 将经 prompt 调用的 language-model 计算表示、组合并执行为由作者定义的计算节点以及数据或控制依赖构成的显式图 。该定义以必要条件而非示例为框架，旨在将这一概念与相邻实践区分开来。
- 四项条件: 四项构成性条件是 G1 显式结构、G2 结构与内容分离、G3 可执行语义，以及 G4 一等工程制品的地位。该图必须支持运行时调度、路由、共享状态、分支、并行与循环，同时能够独立于执行过程被检查、版本化、验证和优化。
- 范围与排除项: 该定义排除偶然要求：图可以通过编码而非可视化编辑构建，可以有环而非无环，也可以使用一个模型、一个框架或不使用 agent 。带有退出条件的循环支持反思与重试循环 。
- 判定程序: 候选对象只有在 T1–T4 均回答“是”时，才属于 prompt graph engineering：具有可显式枚举的节点和边、可分离的结构与内容、可执行的图语义，以及超越单次运行且可检查的制品。T1 要求无需执行即可通过检查、API 或序列化完成枚举；T3 要求由图而非外围手写控制流决定运行时行为。
5 边界（RQ3）
Prompt graph engineering 位于显式、可执行、作为一等对象的图结构，与由作者编写、以 prompt 参数化的模型调用的交汇处。其边界检验依据各邻近概念缺失的条件加以区分，同时将 prompt programming 视为这一概念的一种代码化实现。
- Prompt engineering 与 programming: 经典 prompt engineering 处理节点内部的措辞，因此未通过 T1；而 DSPy 等 prompt programming 通过将模块组合设为可优化对象，通过全部四项检验 。Prompt engineering 仍局限于各图节点；DSPy 将签名与生成的 prompt 文本分离，并在执行期间解释模块组合。
- Thought topologies: Thought topologies 区分修辞结构与调用结构：chain-of-thought 未通过 T1，而 tree-of-thought 和 graph-of-thought 系统则在显式拓扑上编排调用 [1]。Graph-of-thoughts 可以将操作图具体化，因此 T1 和 T3 可以认为通过。
- Agent orchestration: 自由对话式 multi-agent systems 未通过 T1，因为其交互形态逐轮生成，事先没有枚举该形态的表示 。当编排流程被具体化时，便越过了这一边界，例如 MetaGPT 的标准化流程 和 StateFlow 的状态机 。
- RAG pipelines: RAG pipelines 属于部分符合的案例：硬编码的 retrieve-then-generate 代码未通过 T1，而声明式 framework 对象可能通过 T1，但通常未通过 T4，且经常未通过 T2 。结论取决于流程所在的位置，以及该图在执行上下文之外是否仍然可用。
- 边界综合: 边界标准是合取性的：prompt graph engineering 同时要求显式图结构，以及由作者编写、以 prompt 参数化的模型调用节点。Thought topologies 具有图但没有作者编写性；自由 agent 对话具有 prompts 但没有结构；经典 workflow engines 具有结构但没有 prompts；单 prompt 创作则两者皆无。
6 将测试应用于真实系统（RQ4）
将 T1–T4 应用于六个系统，可以清晰区分完全符合条件的图系统、部分符合或依赖运行模式的系统，以及被排除的案例。这一分析还凸显了新兴的图优化系统，但仍受单一分析者分类、灰色文献证据和六系统样本的限制。
- 应用 T1–T4: LangGraph 之所以通过，是因为其显式且可独立编辑的 StateGraph 在类型化状态上执行，并且保持可序列化、可视化以及可用于追踪和评估。其运行时支持循环、分支、中断和检查点。
- 应用 T1–T4: DSPy 通过了测试：它具有可枚举的模块结构，基于签名将结构与生成的 prompt content 分离，支持可执行组合，并提供面向优化器的程序 。这表明，prompt graph engineering 可以以编译和优化为中心，而非依赖手工编写的 prompts。
- 应用 T1–T4: Prompt Flow 通过 YAML 声明的 DAG、分别引用的模板、运行时执行，以及可视化、版本化和批量评估的 artifacts，在字面意义上满足测试，但缺少原生循环 。因此，反思性反馈循环必须置于节点内部，从而削弱了对反思模式的支持。
- 依赖运行模式的系统: AutoGen 的对话模式未通过 T1 和 T4，因为交互结构是逐轮涌现的；而 GraphFlow 将显式有向图具体化，显著恢复了这些条件 。CrewAI 呈现出类似的分化：涌现式 Crews 在 T1 上至多部分符合，而显式 Flows 通过 T1 和 T3，但在 T4 上仍属部分符合。
- 局限: 分类由一名分析者依据可重复的标准完成，而灰色文献证据、快速变化的产品和六系统样本限制了结果的泛化。跨评审者一致性被确定为首项实证后续工作；更广泛的测试还应纳入 serving layers、可视化构建器和企业级 orchestrators。
- 应用 T1–T4: LangGraph、DSPy 和 Prompt Flow 通过全部四项测试，而 AutoGen 和 CrewAI 在不同运行模式下均属部分符合，Claude Code subagents 则被排除。Figure 4 和 Table 2 总结了这种一致的区分结果：三个系统清晰通过，多智能体框架因运行模式而分化，编码 harness 未满足结构条件。
7 研究议程（RQ5）
研究议程沿四条张力轴组织尚未解决的 prompt graph 设计问题：显式—涌现、静态—动态、节点粒度，以及手动—自动改进。同时，它还识别出验证与上下文规范方面的横向挑战。
- 议程概览: 该议程将所分析系统之间的分歧界定为四条张力轴上的开放设计问题，并汇总于 Figure 5。这些轴涵盖结构、动态性、节点粒度和改进自动化。
- 显式结构与涌现结构: 显式结构支持检查、验证和优化，而涌现结构则通过运行时委派适应未预见的任务 。Graph-first 系统负责编写流程；多智能体框架可能选择性地将其具体化，而 coding harness 则可以让结构完全涌现。
- 静态结构与动态结构: 静态图在执行前保留知识，而动态图提升表达能力；一个尚未充分探索的中间方案，是将静态骨架与动态实例化区域结合起来 [1]。Prompt Flow 固定一个 DAG，LangGraph 在固定节点上进行路由，而 LLMCompiler 则为每个任务实例构建一张图 。
- 节点粒度: 细粒度的 prompt 调用支持可分析的数据流 ，而粗粒度的智能体则提供封装性和角色清晰度 。尚未解决的问题是跨粒度组合；当前框架迫使工程师在两者之间做出选择。
- 手动改进与自动改进: 改进方式涵盖手工调优的图、prompt 优化 、文本梯度 、编译后的 pipeline ，以及结构搜索 。自动化依赖 G4，但随机且昂贵的图搜索又带来了其他问题。
- 横向问题: 在这些轴上，验证必须处理类型、循环终止、成本和延迟；同时，上下文规范将分解视为经策划的上下文管理 。某些验证属性可能需要语义判断，或需要具备模型的节点 。
8 结论
本文通过四项条件界定提示图谱工程，并将这一定义操作化为纳入与排除测试。这一概念词汇将现有工程实践与一条涵盖数据流模型、构建系统、链式调用、思维拓扑以及编译或搜索所得图谱的演化脉络对接起来。
- 演化脉络: 本文从数据流模型和构建系统出发，经由提示链和思维拓扑，追溯提示图谱演化史，直至将图谱作为对象进行编译和搜索。
- 贡献: 提示图谱工程要求具备显式结构、将结构与提示内容分离、可执行语义，以及将图谱视为一等工程制品。这些条件被转化为纳入与排除测试，用于区分提示图谱工程与相邻概念。
- 工程收益: 每项条件都带来具体的工程收益：检查需要显式结构，复用与编译需要结构分离，执行需要语义，优化则需要将图谱作为制品。本文将这一贡献呈现为具有工程收益的概念清理，而非官僚主义。
关于生成式 AI 使用情况的声明
作者独立开展研究并撰写稿件，仅使用 Grammarly 和 Claude Opus 4.8 协助文字编辑、结构组织与翻译，随后审阅内容并承担全部责任。
- 关于生成式 AI 使用情况的声明: 作者使用 Grammarly 进行文字一致性检查，使用 Claude Opus 4.8 进行文本结构组织和英语翻译，随后根据需要审阅并编辑内容。作者对本出版物的内容承担全部责任。