Agent 内部的提示词图谱：无人绘制的跨提示词回归链

一位资深工程师向 planner 提示词（prompt）提交了一个只有四个单词的修改——“if uncertain, ask first”（如果不确定，先询问）。Planner 自身的评估集（用于评分计划是否合理）提升了 0.5 分。他们合并了代码。两周后，verifier 的评估显示通过率出现了 3 个百分点的回归，且没人能复现。根本原因在于：planner 现在会提出更多澄清性问题，executor 在第二轮收到的任务描述变短了，而 verifier 的评分准则（rubric）是针对之前 executor 较长的输出进行隐式调优的。一个没人标记为高风险的修改，一次性改变了下游的三个分布。

当你把智能体（agent）内部的提示词看作一个扁平的文件文件夹，而不是一个带有“边”（edges）的图（graph）时，就会发生这种情况。提示词有负责人，但它们之间的“边”却无人看管。

智能体系统积累提示词的方式就像服务积累端点（endpoints）一样。一个中等规模的智能体拥有 planner、executor、verifier、summarizer，顶层可能有 router，底层有 memory-write 提示词。每一个都是一个会被版本化、评审并根据其自身评估集进行评分的字符串。而没有被版本化、评审或评分的是依赖图——即 planner 的输出是 executor 的输入，executor 的输出是 verifier 的输入，而 verifier 的评分准则是针对一个已经不存在的 executor 进行校准的，因为上个 Sprint 有人更改了 executor 的提示词。

提示词构成了一个图，而你的仓库却假装它们是一个文件夹​

走进大多数 AI 代码库，提示词都存放在 prompts/ 目录下。有时每个智能体阶段都有一个子目录，有时每个提示词旁边都有一个 versions.yaml。但几乎从未有过一个工件（artifact）来命名这些“边”：哪个提示词的输出被哪个提示词的输入消耗，这种交接采取什么形式，以及哪个评估是针对该特定边而不是针对端点行为进行评分的。

这种缺失是结构性的，而非出于懒惰。版本控制是围绕文件构建的，提示词符合这个模型。评估套件是围绕智能体边界的输入-输出对构建的，提示词也符合这个模型。这两个工具都看不见提示词之间的图，因为标准工具栈中没有任何东西要求它可见。新入职的员工阅读提示词目录的方式，就像你阅读一个没有架构图的微服务文件夹一样：每个文件看起来都是自洽的，接口是隐式的，而学习拓扑结构的唯一方法就是破坏它。

系统工程中最接近的类比是服务与服务网格（service mesh）之间的区别。隔离的微服务是一个接收请求并返回响应的二进制文件。网格中的微服务是一个具有版本化接口、针对其消费者进行契约测试（contract tests）的节点，并且其部署过程知道当该服务发布时应该对哪些下游服务进行灰度测试（canary）。运行没有网格的服务的团队会积累跨服务漂移导致的事故。运行没有图的提示词的团队会积累跨提示词漂移导致的回归。动态过程是完全相同的，改变的只是名词。

故障模式有三个跳步，且无人察觉​

典型的事故：一个 planner 的修改顺利落地。它自身的评估（假设叫 planner_quality.yaml）针对一组固定的用户查询运行，并评分计划是否合理。评估分数上升了 0.5 分。PR 在周一合并。

评估没有衡量到的是，新的 planner 生成的计划在步骤粒度分布上发生了变化。旧的 planner 每个任务生成四个中等粒度的步骤，而新的 planner 生成六个细粒度的步骤。Executor 逐字消耗这些步骤。六个细粒度的步骤意味着六次工具调用而不是四次，这意味着更多的上下文积累，这意味着当 executor 完成时，executor 的响应比以前更长且略显冗长。

Verifier 读取 executor 的响应。它的评分准则（rubric）是由一名八周前编写、此后已调岗到另一个项目的工程师编写的，该准则隐式地被调优为期望旧的、更简洁的响应风格。评分准则给冗长的响应打分较低，因为编写它的工程师发现冗长的响应更难评分，并不自觉地惩罚了它们。Verifier 的通过率下降了 3 个百分点。值班人员（on-call）在周三早上的仪表盘上看到了回归。第一反应是检查 verifier 本身，然后是 executor，接着是模型版本。Planner 是最后一个被怀疑的对象，因为 planner 自身的评估显示是正常的（green）。

这并非假设。任何运行多提示词智能体超过一个季度的团队都经历过这种事情。模式是一致的：症状出现在距离原因两个跳步（hops）的地方，原因孤立来看是无害的，而本可以将它们连接起来的工件——针对每条边的回归评估——并不存在。

提示词图谱产出物 (Prompt-Graph Artifact) 究竟包含什么​

解决这一问题的纪律始于一个单一的产出物：一个存在于仓库中的 prompt-graph.yaml（或等效文件）。它在每一次提示词 PR 中都会被审查，并命名提示词之间的每一条边。对于每个提示词，它列出了：

• 提示词的输入及其来源。不仅是“用户查询”，而是“规划器输出、执行器上一轮对话、文档索引的检索结果”。
• 提示词的消费者——每一个读取该提示词输出的其他提示词以及代码路径。
• 对每一条出向边进行评分的评估维度 (Eval surface)。不仅是“规划器是否生成了好的计划”，而是“规划器生成的计划是否能让执行器直接执行而无需再次请求澄清”。
• 交接的 Schema 或契约。下游提示词预期的形状，并至少包含一个示例。

这并不陌生。它就是一个更改了名词的服务网格清单 (service mesh manifest)。接口是版本化的，消费者是枚举的，契约是明确的，每条边的评估维度也都有命名。

这个产出物为你带来的价值（按价值排序）：PR 作者在合并前知道需要运行哪些下游评估；审查者知道该问什么；事后分析者拥有可以追溯的拓扑结构；新员工拥有了一张地图；团队也有了一个强制机制，不再将“微小的提示词调整”视为零爆炸半径的编辑。