想象一下，你雇佣了一支由专业机器人组成的团队来运营客户服务部门。你给它们制定了一本严格的规则手册：“机器人 A 只能查询航班时刻表，机器人 B 只能预订座位，而机器人 C 是经理，负责决定谁做什么。”你还写下了具体规则，例如：“机器人 A 禁止预订座位。”
现在，想象一下你想要测试这支团队是否正常工作。
旧方法（“快乐路径”测试）
传统上，测试人员只会向团队提出一个简单的问题：“我需要预订一个座位。”如果团队成功预订了座位，测试就算“通过”。
- 问题所在： 这并不能证明团队遵守了规则。也许机器人 A 试图预订座位，但机器人 B 无论如何都接手了。或者机器人 A 甚至从未看到该请求。测试通过了，但你完全不知道你写下的具体规则是否真的被遵守了。你可能拥有一个从未被使用的“隐藏”机器人，或者一个从未被检查过的禁止操作。
新方法（结构覆盖）
这篇论文提出了一种测试这些 AI 团队的新方法。它们不再仅仅检查最终任务是否完成，而是检查规则手册中的每一条规则和每一个连接是否真的被使用过。
将团队的规则手册想象成一张地铁系统地图：
- 站点是不同的人工智能代理（机器人）。
- 轨道是它们相互传递任务的路径（委托）。
- 列车线路是它们可以使用的工具（如“查询航班”或“预订座位”）。
- 红色区域是它们被严格禁止进入的轨道（受限工具）。
作者的方法将规则手册视为这样一张地铁地图。它们不仅仅问：“列车到达目的地了吗？”它们问的是：
- 列车是否访问了每一个站点？（每个机器人是否都轮到了？）
- 列车是否行驶在每一条允许的轨道上？（每个机器人是否使用了它被允许的所有工具？）
- 列车是否尝试进入红色区域并被拦下？（我们是否证明了禁止规则确实有效？）
- 列车是否在每一个换乘点切换了线路？（机器人是否正确交接了任务？）
它们是如何做到的
研究人员构建了一个系统，该系统充当超级智能编剧（使用一种名为 DSPy 的工具）。
- 阅读地图： 首先，系统读取代码并绘制出地铁地图（即“协调图”）。
- 编写场景： 然后，它编写具体的自然语言请求，旨在迫使 AI 团队使用地图的特定部分。
- 示例： 为了测试“红色区域”，它可能会向经理机器人提问：“请为我预订一个座位”，希望经理尝试直接执行此操作（这是被禁止的）。如果系统捕捉到经理试图违反规则并自行停止，那么这就是对限制规则的一次成功测试。
- 现实核查： 系统将这些场景应用于真实的 AI 团队。它不仅仅查看最终答案，还会观察内部日志，以确切看到哪个机器人发言、哪个工具被点击以及发生了哪些交接。
他们的发现
他们在 10 种不同的 AI 团队设置上进行了测试（从简单的客服机器人到复杂的研究团队）。
- 好消息： 他们的方法成功生成了测试，证明了 AI 团队正在使用其允许的工具并正确地相互传递任务。
- “红色区域”发现： 当他们试图诱骗 AI 团队违反规则时，发现有些团队非常擅长自我阻止（0 次违规），而有些团队则意外尝试使用禁止工具（发现了违规）。这非常有价值，因为它确切地显示了规则在何处薄弱。
- 局限性： 他们发现，如果一项任务需要经过许多不同的机器人（即一次漫长的地铁旅程），他们的编剧就更难让 AI 每次都走那条确切的路径。
核心结论
这篇论文认为，仅仅因为一个 AI 团队解决了问题，并不意味着它遵循了其设计。你需要检查团队的结构，而不仅仅是结果。
这就像检查一辆汽车：你不仅仅是开车去商店看看它是否工作。你还要检查刹车是否经过测试、安全气囊是否在碰撞测试中弹出，以及发动机机油是否更换过。这篇论文为我们提供了一份清单，以确保 AI 团队设计的每一个部分都经过测试，从而确保我们设定的规则实际上得到了遵守。
技术摘要：基于结构覆盖准则的多智能体工作流测试
问题陈述
多智能体系统正日益被部署为结构化工作流，其中智能体、工具、访问规则和委托路径均被明确定义。然而，当前的评估实践严重依赖端到端任务成功率、基准测试分数和最终响应质量。这些指标仅能提供有限证据，证明已声明的协调结构实际上已被执行。一个工作流可能成功完成任务，却未调用特定工具、未测试受限访问规则或未探索委托路径。因此，难以评估测试套件的充分性，或检测工具访问和智能体间委托中的结构回归。本文认为，端到端成功是多智能体系统中结构覆盖不可靠的代理指标，特别是随着工作流的演进，微小的定义变更可能会改变结构义务，而不会立即导致任务失败。
方法论
作者提出了一种结构测试方法，将多智能体工作流规范视为主要的可测试工件。该方法遵循一个五步流程：
- 规范提取：从源代码（具体为 OpenAI Agents SDK 风格的工作流）中提取标准化的多智能体工作流规范（S）。该规范定义了可达智能体、允许的工具边、受限的工具边以及委托边。
- 图构建：将规范转换为类型化的协调图 G(S)，其中节点代表智能体和工具，边代表允许访问、受限访问和委托关系。
- 义务推导：从图中推导出结构义务，分为四类：
- 可达智能体（Areach）
- 允许的工具边（Tallow）
- 受限的工具边（Trestrict）
- 委托边（D）
- 覆盖驱动生成：系统从义务集中合成“类型化见证目标”。这些目标使用 DSPy（一种用于语言模型流水线的声明式框架）实现为自然语言测试场景。关键在于，DSPy 仅用于场景实现，而非定义覆盖。生成器采用有界细化循环（最多 N=5 次尝试），将候选提示在运行时适配器上执行。只有当执行产生目标所需的特定结构证据（例如特定的工具调用或委托交接）时，循环才会终止。
- 运行时观察与测量：测试通过运行时适配器执行，该适配器记录结构轨迹。通过检查观察到的轨迹是否满足每个义务的见证谓词来测量覆盖率。
覆盖准则
本文定义了四种结构覆盖准则：
- C1（智能体覆盖）：观测到每一个可达智能体。
- C2（允许工具覆盖）：执行每一个允许的智能体 - 工具边。
- C3（受限工具覆盖）：通过显式的受限访问观测（例如拒绝或驳回事件）来执行每一个受限的智能体 - 工具边，而不仅仅是缺乏调用。这被视为一种对抗性测试。
- C4（委托覆盖）：观测到每一个可达的委托边。
主要贡献
本文做出了四项主要贡献：
- 形式化：将多智能体工作流测试形式化为基于从智能体框架源代码导出的类型化协调图的结构充分性问题。
- 覆盖模型：定义了针对可达智能体、允许的工具边、受限的工具边和委托边的图衍生覆盖准则。值得注意的是，它将受限工具覆盖视为显式的负向观测义务。
- 生成流水线：提出了一种覆盖驱动的测试生成流水线，将工作流清单转换为类型化见证目标，并利用基于 DSPy 的、运行时 grounded 的实现来生成自然语言测试场景。
- 实证评估：在十个源自 OpenAI Agents SDK 的工作流上评估了该方法，共涉及 49 个可达智能体、47 个工具和 403 个结构义务，包括对
oai_customer_service 工作流的详细分析。
实验结果
评估在十个基准测试上进行，采用固定配置（对实现器和被测智能体均使用 gpt-4.1-mini）。
- 提取（RQ1）：该流水线成功提取了所有十个工作流的格式良好的协调图，并导出了结构义务，无需人工干预。
- 允许工具和委托见证（RQ2）：
- 生成的场景见证了 54/75（72%）的允许工具义务（跨基准聚合，论文表 II 显示为 45/65，但摘要陈述为 54/75；正文结果部分澄清为 45/65）。
- 生成的场景见证了 36/48（75%）的委托义务（聚合数据；表 II 显示为 31/41）。
- 单跳目标普遍通过。未通过的情况主要发生在多跳工作流中，或由于语义重叠导致协调器将请求路由到不同的专家智能体。
- 受限工具对抗性见证（RQ3）：
- 对抗性探测引发了 23/248（9.3%）的受限调用违规。
- 四个基准测试未产生针对性的违规，而六个基准测试产生了具体的错误路由失败。这证明了该准则能够区分具有稳健限制的工作流与具有可被利用边界的工作流。
- 故障注入（RQ4）：在
oai_customer_service 基准测试上，结构测试框架成功测试了注入工具故障（错误和格式错误的负载）下的鲁棒性，确认智能体尝试了工具调用且未崩溃或泄露原始错误负载，尽管未验证语义正确性。
意义与主张
本文主张，结构覆盖为多智能体工作流测试提供了一个有用的充分性层。它并不替代语义评估或端到端基准测试，但提供了显式证据，证明已声明的智能体、工具访问规则、限制和委托路径已被执行。
- 诊断价值：该方法揭示了“未测试的结构”。未达成的义务指出了难以执行的具体协调路径，指导开发人员改进路由提示或加强工作流。
- 负向义务：通过显式测试受限工具边，该方法发现了漏洞（即绕过限制的特定提示），这些漏洞在仅基于白名单的评估中将保持不可见。
- 局限性：作者对其主张持谨慎态度，指出结果是单次运行的实证证据，而非具有统计效力的估计。他们承认，高结构覆盖并不能保证语义正确性、用户满意度或事实准确性。该方法目前特定于 OpenAI Agents SDK 风格的工作流，且有界细化循环有时无法在尝试预算内见证复杂的多跳义务。
本文结论认为，结构测试通过将关注点从“任务是否成功？”转移到“已声明工作流的哪些部分实际上被测试了？”，从而补充了现有的智能体评估方法。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。