提示词契约测试：多智能体团队如何协同而不互相破坏

当两个微服务在API假设上出现偏差时，集成测试会在上线前捕获问题。当两个智能体在提示词假设上出现偏差时，你只会在客户收到自相矛盾的答案——或者整条流水线因级联故障崩溃——时才会发现。多智能体AI系统在生产环境中的失败率高达41%–87%。这些失败中超过三分之一并非模型质量问题，而是协调故障：某个智能体改变了输出格式，另一个智能体仍然期望旧的数据结构，而没有人为此写过测试。

根本问题在于，智能体之间通过隐式契约进行通信。一个研究型智能体——在某人的心智模型中——约定返回带有 sources 数组的JSON对象。编排型智能体依赖这个结构。没有人把它写下来，没有人测试它。六周后，研究型智能体的提示词被优化为返回排名列表而非 sources 数组，编排型智能体就悄无声息地丢失了一半输入。

提示词契约测试将消费者驱动契约测试的理念——在微服务领域已通过Pact等工具广为人知——应用于LLM智能体之间的接口。核心思想很简单：下游消费者定义所需，上游提供者承诺交付，自动化检查在任何变更上线前强制执行这一协议。

多智能体协调为何在规模化时失败

2025年的一项失败分类研究分析了生产级多智能体系统中超过1600条执行轨迹，发现三类失败。规格问题——角色定义模糊、任务边界不清——占失败的41.8%。协调失败——智能体对共享上下文的理解不一致——占36.9%。其余21.3%是验证缺口：系统单独运行正常，但在接缝处崩溃。

可靠性数学残酷无情。若五个智能体各自的成功率为95%，系统级可靠性复合后约为77%。听起来还可以接受，直到你每天运行数千条流水线。而且95%已经是乐观估计——与其他智能体而非人类交互的智能体往往表现更差，因为它们失去了耐心的人类在循环中提供的纠错机制。

失败并非随机分布，而是集中在智能体边界处：一个智能体的输出成为另一个智能体输入的节点。这正是软件系统在API契约和模式校验成为标准实践之前曾经失败的地方。解决方案相同——必须让接口显式化并对其进行测试——但当接口是自然语言提示词而非带类型的函数签名时，实现方式有所不同。

什么是提示词契约

提示词契约是一种机器可读的规范，描述一个智能体将产生什么，以及另一个智能体需要什么。可以将其视为智能体间通信的OpenAPI规范。

研究型智能体输出的最小契约可能规定：

• 输出必须是JSON对象
• 必须包含至少一项的 sources 数组
• 每个来源必须有 url（字符串）、relevance_score（0–1的浮点数）和 excerpt（字符串，最多500字符）
• 必须包含不超过200词的 summary 字符串
• 任何字符串字段中不得包含原始HTML标签

消费型智能体——编排器——根据其实际需要定义此契约。生产型智能体——研究员——负责满足它。这是消费者驱动的倒置：消费者对需求具有权威性，而非提供者。

当研究型智能体的提示词发生变化时，自动化测试会在变更部署前将其输出与契约进行比对。如果新提示词产生 ranked_results 数组而非 sources 数组，契约检查就会失败。拥有研究型智能体的团队会在拥有编排器的团队之前得知这一破坏性变更。

JSON Schema层

实际实现通常使用JSON Schema作为结构化输出契约的执行机制。JSON Schema是声明式的、与语言无关的，并且受大多数LLM API的结构化输出功能支持。

Promptfoo、LangSmith和Arize Phoenix等工具都可以自动将智能体输出与模式进行评估。但模式本身并不是需要深思熟虑的地方。真正需要思考的是定义合规测试套件：一组规范输入与期望输出属性的配对，正确的实现应当满足这些配对。

客户支持智能体的合规测试可能规定，给定一个包含订单号的退款请求，智能体必须：

1. 将订单号提取到结构化字段中
2. 将 action_required 设置为 true
3. 在不查询的情况下不承诺具体的退款时间
4. 不与同一上下文中先前的合规检查结果相矛盾

这些不是传统意义上的单元测试——你无法对LLM输出进行精确的字符串等值断言。它们是行为契约：无论模型选择何种具体措辞，这些属性都必须成立。评估框架结合使用JSON Schema验证（用于结构）和LLM-as-judge评分（用于语义属性）。

实践中的消费者驱动流程

该工作流程与Pact在微服务中的工作方式相似，但针对LLM的不确定性进行了调整。

消费者团队——调用另一个智能体的智能体——首先编写契约。这包括他们将发送的示例输入以及他们要求响应中具备的属性。他们将其提交到共享契约库或PactFlow之类的代理服务。

提供者团队——被调用的智能体——在其CI流水线中针对消费者的测试用例运行其智能体。如果提供者当前的提示词满足所有消费者契约，流水线通过。如果提示词变更破坏了契约，流水线在部署前失败。

这颠覆了通常的对话。提供者不再说"这是我们的输出，你来适应"，而是消费者说"这是我们的需要，请确保你提供"。提供者团队可以进行任何内部变更——优化提示词措辞、切换模型、添加思维链步骤——只要可观测的契约保持满足。

2024年底标准化、现已被各大AI提供商采纳的模型上下文协议（MCP）在工具层将这一模式正式化。MCP定义了智能体如何向彼此公开工具，其中带类型的参数在所有消费者引用的模式中一次性定义。MCP中的工具定义是机器可读的契约：名称、描述、输入模式和期望的输出格式。任何实现该工具的智能体都必须满足该模式。

像API变更一样对提示词变更进行版本管理

未版本化的提示词等同于未版本化的REST API：任何变更都可能造成破坏，且没有机制来发出信号。做好这件事的团队会以与API变更相同的规范对待提示词变更。

语义版本化的映射关系良好：补丁版本更改措辞但不影响输出结构；次要版本添加消费者可忽略的可选输出字段；主要版本更改必需的输出结构或删除字段。任何主要版本的升级都会触发契约重新协商流程——提供者团队通知所有已知消费者，消费者更新其契约和测试，旧版本继续服务流量直到所有消费者完成迁移。

LangSmith和Lilypad等工具现已支持自动提示词版本管理，不仅捕获提示词文本，还关联评估结果和模型配置。每个版本都有相关的测试套件结果，因此你不仅能看到变更了什么，还能看到变更是否破坏了任何内容。

彩虹部署处理了更新长期运行流水线的操作挑战。当智能体更新部署时，新旧两个版本同时运行。流量逐渐转移——新版本10%，然后25%，然后50%，最后100%——每一步都可以回滚。更新部署时正在处理中的智能体继续在旧版本上运行，不受中断。这种模式对于单次运行跨越数分钟或数小时的研究或数据处理流水线尤为重要。

没人预算的安全角度

在任何契约测试策略中，跨智能体边界的提示词注入都值得单独占据一席之地。OWASP的2025年LLM应用十大风险将提示词注入排在首位，73%的生产LLM应用目前存在漏洞。

在多智能体系统中，攻击面比单智能体部署更大。恶意行为者不需要直接攻破编排器——他们可以将指令注入某个子智能体处理的数据，然后通过流水线传播。一个智能体的工具输出成为另一个智能体的上下文，而精心构造的工具输出可以重定向下游智能体的行为。

契约测试的等价物是对抗性测试套件：提供者必须处理已知的注入模式而不破坏其行为契约。Promptfoo包含一个漏洞扫描器，可自动生成注入、越狱和PII泄露测试用例。这些应在每次提示词更新时与功能性契约测试一起运行。

构建协调基础设施

做好这件事的团队有一些共同的结构性选择。

他们维护一个独立于任何单个智能体代码库的契约库。契约由消费者拥有，但对提供者可见。契约变更需经过审查流程，而非单方面编辑。

他们在两侧的CI中运行契约测试：当消费者更改其契约时，提供者的流水线针对新期望重新运行。当提供者更新其提示词时，所有已知消费者的契约重新运行。

他们专门对协调进行监控。汇总的智能体成功率掩盖了失败发生的位置。使用结构化字段记录每次智能体间调用——调用智能体、目标智能体、契约版本、验证结果——让你能够识别哪些边界最常出现故障。

他们在契约中构建了明确的降级处理。契约不仅应规定成功响应的样子，还应规定失败时的处理方式：错误响应的结构、是否允许重试、当提供者返回不符合契约的响应时消费型智能体该怎么做。

MAST失败分类研究发现41.8%的失败是规格问题而非执行问题——这指向了最重要的投入：在编写提示词之前先写规格。先定义契约、再实现智能体以满足契约的团队，始终优于先实现、再非正式记录的团队。2025年的一项研究发现，针对规格不明确的智能体任务采用交互式测试驱动工作流，在模糊输入上的性能提升了74%。在实现前规定预期行为的规范，对多智能体协调与传统TDD一样带来相同的收益。

未来走向

提示词契约测试仍处于早期阶段。工具链正在成熟但尚未整合——团队将JSON Schema验证、评估框架、版本管理工具和部署基础设施从不同产品拼凑在一起。与Pact为REST API提供的相媲美的完整技术栈尚不存在。

监管的顺风是真实的。联邦机构于2026年初开始要求模型卡和评估产物。企业采购越来越多地要求提供系统性评估的证据。这种外部压力正在推动团队将以前隐式留下的内容正式化——提示词契约是自然产生的产物。

MCP的行业广泛采用意味着工具层现在有了标准化的契约格式。下一个逻辑延伸是对智能体间提示词接口进行同等标准化：一种版本化的、机器可读的规范，捕获行为期望，而不仅仅是参数模式。一些团队已经在构建看起来像这样的内部工具。这是将软件工程规范应用于智能体协调的自然终点。

底层洞见并不新鲜——它比LLM早几十年。分布式系统在边界处失败。使边界可靠的方法是使其显式化、对其进行版本管理，并持续测试。LLM的不确定性为测试层增加了复杂性，但不会改变架构原则。