What makes prompts a graph: necessary and sufficient conditions for prompt graph engineering
本文提出了“提示词图工程”（prompt graph engineering）的构成性定义与操作框架，旨在将现代提示词系统正式表征为显式的、可执行的图，从而为这一在工业界已无处不在但缺乏精确理论定义的实践，建立必要条件、共同词汇表及研究议程。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正试图教一个超级聪明的机器人如何破解谜题。起初，你只是写了一封巨大的、完美的信件给机器人，希望它能从这一封信息中理清一切。那是旧的方法：一个提示词，一个答案。但随着机器人们变得越来越聪明，谜题也变得越来越难，仅仅靠那一封信已经不够了。工程师们意识到他们需要将问题拆解开来。他们开始让机器人制定计划，然后检查自己的工作，接着向专家寻求帮助，最后对最佳答案进行投票。突然之间，“提示词”不再仅仅是一封信了；它变成了一个按照特定顺序协作工作的机器人团队。
这就是棘手之处所在。当你有这样一个通过传递纸条进行沟通的机器人团队时，你需要一张地图来展示谁与谁交谈，谁在等待谁，以及谁做出最终决定。在计算机科学的世界里，这张地图被称为图（graph）。把“图”想象成一张地铁图：车站是步骤（比如“阅读线索”或“呼叫专家”），而轨道则是告诉机器人下一步该去哪里的指令。有些轨道会在出错时循环回溯；有些则会同时分叉成两条路径。科学家和工程师们目前面临的大问题是：一个杂乱无章的机器人指令集合，何时才算成为一个真正的、正式的“图”，从而可以被我们研究、修复和改进？如果我们无法就“图”究竟是什么达成共识，我们就无法构建更好的工具来管理这些机器人团队。
这篇由 Sandeco Macedo 撰写的论文，就像是一个试图为这个新领域画出官方边界线的侦探。作者认为，我们使用“图”这个词过于宽泛了。有时人们用它来描述一个机器人在自己脑海中是如何“思考”的，有时则用它来描述工程师为了控制机器人而“绘制”的一张地图。论文指出，要被称为“提示图工程（Prompt Graph Engineering）”，它必须是一种特定的、经过工程化设计的地图，而不仅仅是随机的对话或思维过程。
作者提出了一个严格的四部分测试，来判定一个系统是否为真正的“提示图”。首先，地图必须是显性的（explicit）：在机器人开始运行之前，你必须能在纸上（或代码中）看到车站和轨道。其次，地图必须与笔记分离：你应该能够在不重写机器人阅读的信件（内容）的情况下改变轨道上的指令（结构），反之亦然。第三，地图必须是可执行的（executable）：它不仅仅是一幅画；计算机必须实际运行它，并根据规则决定下一个访问哪个车站。第四，地图必须是一个真实的实体（real object）：它必须作为一个文件或设计存在，可以被保存、版本化并持续改进，就像房屋的蓝图一样。
利用这个测试，论文将真正的工具与模仿者区分开来。它确认了像 LangGraph 和 DSPy 这样的系统是真正的提示图，因为它们拥有清晰的地图、分离的结构和执行这些结构的运行时环境。然而，它排除了某些流行的多智能体系统，在那些系统中，机器人只是自由地聊天，而它们所经过的路径只有在交谈结束后才被发现；那些属于“涌现式”流，而不是工程化的图。论文还澄清了，虽然“思维拓扑（thought topologies）”（即机器人生成思想树的过程）看起来像图，但它们并不相同，因为画图的是机器人，而不是工程师。
最终，论文表明我们正处于一个转折点。我们已经从编写单封信件，转向了设计复杂的、带有循环和分支的系统。通过精确定义什么是“提示图”，作者为工程师们提供了一套共同的词汇和一份清单。这并不能解决所有问题，但它能防止我们将一场混乱的对话称为“图”，并帮助我们专注于构建那些其结构本身就可以被检查、测试和优化的系统。论文总结道，虽然构建这些地图的做法已经在实验室和公司中展开，但拥有一个清晰的定义，是衡量这些地图在多大程度上提升了我们 AI 系统性能的必要第一步。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。