ContractBench: Can LLM Agents Preserve Observation Contracts?¶
会议: NeurIPS 2026 Evaluations & Datasets
arXiv: 2605.17281
领域: LLM Agent
关键词: 观察契约、时间有效性、字节完整性、工具使用、程序化评测
一句话总结¶
ContractBench 用虚拟时钟、字节校验和 HTTP 轨迹验证评测智能体是否遵守工具产物的跨步骤契约,在本文 38 个模型变体的实验快照中,最高成功率为 77.8%,且规模或版本升级并不保证可靠性提高。
研究背景与动机¶
工具调用正确,不代表整个工作流可靠。智能体可以理解用户需求、选对 API,也能生成语法有效的调用,但如果它把预签名 URL 当成普通文本重新组织,或等到临时令牌过期才提交,下游服务仍会拒绝请求。这里的问题不只是答案是否真实,而是外部系统曾交付一个带使用条件的产物,智能体必须在之后的行动中保留这些条件。OAuth state、会话令牌、ETag 和签名请求都体现了这种跨步骤依赖。
已有智能体基准主要关注任务终态、工具选择或领域政策是否满足,对中间产物的处理常缺少独立的诊断维度。TicToc 已研究缓存信息变旧后的工具重调用,但它不能替代字节级传递检查:刷新一个过期 URL 可以修复时效,却无法阻止工具接口把新 URL 截断;反过来,原样保存令牌也不会自动产生合理的截止时间规划。真实工具链又会在接口限长、换行、URL 重编码或显示文本转换处改变产物,使失败同时涉及模型决策与执行框架。
ContractBench 因而把这些条件做成可执行的评测对象,而不是让另一个语言模型判断智能体的解释是否可信。参数化任务、可控时间和服务器日志使作者能够分别施加时间与完整性压力,并用错误标签定位失败发生在哪一类约束上。核心 idea:把工具返回的中间产物视为必须同时满足时间有效性与字节完整性的观察契约,直接验证后续 HTTP 行动是否履约,而不是只评估智能体是否会调用工具。
方法详解¶
整体框架¶
ContractBench 是评测基准,不提出新的神经网络,也没有待优化的训练损失。输入是一个任务说明和可交互的模拟 API;智能体通过工具与服务器交互,接收临时 URL、令牌或协议状态,再在后续请求中使用这些产物。输出由隐藏的程序验证器根据 HTTP 请求日志给出,包括成功标志、主要失败标签、错误细节和轨迹元数据。
整个设计由观察契约形式化、双轴任务与可控扰动、程序化验证与失败归因、重复评测与标签反馈四部分组成。前两部分定义智能体必须保持什么、评测怎样施压;后两部分定义怎样确认它真正保持了约束,以及失败信息是否能帮助下一次尝试。这里不画网络结构图,以免把评测组件误表述成模型架构。
每个任务包含 TOML 元数据、智能体可见的 Markdown 指令、FastAPI 服务器和 pytest 验证器。元数据固定难度、任务类别与预算;服务器返回交互结果并记录事件;验证器读日志计算奖励。智能体只看到指令和服务器 HTTP 响应,不能读取隐藏元数据或验证规则。这种可见性划分让得分依赖实际行为,而不是对测试脚本的复述。
关键设计¶
1. 观察契约形式化:把及时使用和原样传递分开检查
作者将观察契约写成 \(C=(o,t_{\text{issue}},\tau,\pi)\):\(o\) 是工具交付的产物,\(t_{\text{issue}}\) 是签发时刻,\(\tau\) 是存活时间,\(\pi\) 是完整性判定函数。一个后续提交不仅要在允许的时间内到达,也要满足产物的完整性条件;语义相近、肉眼相似都不能代替这个条件。Definition 2.1 的有效窗口是 \(W(C)=[t_{\text{issue}},t_{\text{issue}}+\tau)\),实现中的默认完整性检查则比较提交内容与原始内容的 SHA-256 摘要。下面将两项判定合写,保留它们相互独立这一核心机制。
这里 \(h(o)\) 是原始产物的摘要,\(o'\) 和 \(t'\) 是实际提交内容与提交时间。整个轨迹合规要求每个必需契约都满足,而非用成功的步骤抵消一次违约。论文的正交性命题只是说,原则上可以出现及时且完整、过期但完整、及时但被改变、过期且被改变四种情况,不是说两个轴在数据上的失败概率统计独立。该抽象也允许 HMAC、ETag 等确定性谓词;基准用摘要比较强调的是产物传递保真,并不意味着所有真实 API 的协议校验都等同于字节哈希。另需保留原文边界差异:Definition 2.1 和附录 F 使用严格小于到期时刻,图 2 与第 3.2 节却写成包含端点的 \(t_{\text{fetch}}\leq t_{\text{issue}}+\tau\),本文没有消除这一不一致。
2. 双轴任务与可控扰动:让时间规划和传递保真分别暴露
33 个任务由参数化模板生成,改变 TTL、限流窗口、令牌长度等难度因素,并用一个种子控制资源顺序、产物内容与时间抖动。任务组织为低双轴压力的 Q1、时间主导的 Q2、完整性主导的 Q3 和同时施压的 Q4;正文称 24/33 个任务属于 Q4,意图是覆盖实际中既会过期又绑定签名的产物。任务涉及 OAuth/auth、签名请求、状态链、资源管理和多服务流程,而不是只测试复制一条短字符串。需要注意,附录 D 的逐项目录可数出 Q2 为 5 项、Q3 为 5 项、Q4 为 23 项,没有单列 Q1;因此正文的 24 项分布不能当作已由目录核实的准确计数。
为了区分模型忘记约束与工具链改变产物,作者还复现五种确定性传递扰动:限长截断、插入换行、URL 重编码、查询参数重排、显示文本与真实链接不一致。它们是执行路径中的评测压力,不是智能体需要绕过的安全机制。例如,工具接口只能接受 200 个字符而原始签名查询串长 256 个字符时,即使模型想直接转交,也可能送出残缺内容;附录 H 用服务器端保存完整产物、执行时解析短句柄说明一种框架级修复方向。时间压力则要求智能体识别维护窗口、限流退避和资源截止时间,不能靠重复发送相同请求恢复。两类压力并列的价值,是避免把时间上的修复误判成完整性上的修复。
3. 程序化验证与失败归因:只承认 HTTP 轨迹中的履约行为
FastAPI 服务器在虚拟时钟上记录按时间排序的请求事件,pytest 验证器据此产生二元结果。有效性看模拟环境中的时间、版本或窗口条件,完整性看实际到达服务器的内容和协议条件;智能体最终说“已成功”不参与裁判。虚拟时钟将环境时间从网络延迟与模型响应速度中分离,保证相同任务实例的检查规则可复现。实验同时有每回合 600 秒的真实墙钟超时,以及各任务规定的步骤和虚拟时间预算;600 秒不是产物 TTL,也不是模拟时钟的推进规则。
诊断体系共有 15 个标签,其中 4 个属于有效性失败、9 个属于完整性失败、2 个是元标签 SUCCESS 与 OTHER,所以不能把它称为 15 种纯失败。有效性标签涵盖过期、限流、维护不可用和版本冲突;完整性组不仅包括 MUTATED_TOKEN、SIGNATURE_MISMATCH、WRONG_HASH,还包括遗漏约束、错误值、补偿失败等协议结果。它因此是实用的宽口径归因体系,而不只是字节变更的分类表。一次回合可以出现多个事件,最终按照最严重规则留下一个主要标签;成功流程的状态事件不计入失败分布。这样便于比较模型,但单一标签会隐藏多种失败共现,而且附录 K 所展示的严重性表只列出部分标签,不能从该表补造完整权重。
4. 重复评测与标签反馈:区分会调用、会履约和会从错误恢复
作者为每个任务提供在同一虚拟时钟上运行的参考解,要求其通过验证器后才纳入基准。33 个参考解在每任务 10 个种子的网格上均通过,共 330 个 oracle 回合;它们是任务可解性和验证器回归测试的证据,不是模型能力上界的估计。模型主榜则明确使用每任务 3 次 rollout、33 个任务、每模型 99 个回合,温度为 0,并记录固定模型标识。第 3.1 节另写“每模型每任务 10 个种子”,与主榜协议不一致;这里将 330 个参考解回合与 99 个模型回合分别报告,不把两者合成不存在的统一设置。
主要指标成功率 SR 是主要标签为 SUCCESS 的回合占比;单任务通过率是同一模型在该任务 3 次运行的平均奖励,失败标签分布则只对失败回合统计主要标签。最后,作者选择 42 个 GPT-5.1 失败回合做配对重试,分别不加提示、加入原始正确标签、加入来自不同轴的错误标签,以区分“再试一次”与“收到正确诊断”的效果。这个干预只是推理时上下文反馈,没有更新模型权重;把标签用于强化学习后训练仍是未来工作。42 个配对失败是重试实验的样本,不能当作 GPT-5.1 主榜的失败总数,因为 48/99 成功对应 51 个失败。
以上协议刻意把不同层面的可靠性拆开:能生成有效工具调用不等于能完成协议入口,进入协议也不等于能持续保持契约,收到错误标签更不保证失效的产物已经可恢复。本文的贡献主要是把这些层面做成可观察、可诊断的评测,而非提供一个保证成功的智能体算法。
实验关键数据¶
主实验¶
下表摘录正文表 3 和附录表 10,均以每模型 99 个回合为分母。它是缓存论文版本的实验快照,不代表当前在线模型榜单;未把不同提供商或模型版本的结果扩展为普遍能力结论。
| 模型变体 | 成功回合 / 99 | SR(%) | 主要观察 |
|---|---|---|---|
| Claude Opus 4.6 | 77 | 77.8 | 本文最高,仍低于 80% |
| GPT-5.2 | 74 | 74.8 | 正文表 3;附录表 10 写 74.7 |
| GPT-5 | 70 | 70.7 | 高于后续 GPT-5.1 |
| GPT-5.1 | 48 | 48.5 | 版本升级出现回退 |
| GPT-4o | 23 | 23.2 | GPT 版本比较的较低起点 |
| Qwen3.5-397B-A17B | 70 | 70.7 | 与 GPT-5 同分 |
| Qwen3.5-27B | 64 | 64.6 | 主榜;其他段落存在冲突 |
| Qwen3.5-9B Instruct | 56 | 56.6 | 4B 到 9B 出现能力跃迁 |
| Qwen3.5-4B Instruct | 0 | 0.0 | 未进入成功契约轨迹 |
| Qwen3.5-9B Base | 0 | 0.0 | Base 与 Instruct 差距含协议入口因素 |
Qwen3.5-27B 的 64.6% 来自主榜,但第 5 节写 76.5%,附录表 12 的均值又写 0.62。三处不能直接统一,本笔记以明确的成功计数说明所用主榜口径,并保留差异。
消融实验¶
论文没有新模型的模块移除消融;最接近机制对照的是标签反馈重试实验。下表对应同一组 42 个 GPT-5.1 失败回合,不与主榜 SR 混用。
| 重试条件 | 成功回合 / 42 | 重试成功率(%) | 相对无提示 |
|---|---|---|---|
| 无提示 | 6 | 14.3 | 基准 |
| 错误标签提示 | 5 | 11.9 | -2.4 个百分点 |
| 正确标签提示 | 8 | 19.0 | +4.8 个百分点 |
正确标签相对错误标签多恢复 3 个回合,差距为 +7.1 个百分点;这不是相对无提示的提升,也不是整个 99 回合榜单提高了 7.1 个百分点。样本较小,论文没有在该表提供显著性检验或置信区间。
附录 S 的分标签计数进一步限定了“哪些错误可恢复”,而不是支持所有失败都受益于标签。
| 原始失败标签 | 配对回合数 | 无提示成功 | 正确标签成功 | 错误标签成功 |
|---|---|---|---|---|
| WRONG_VALUE | 19 | 3 | 4 | 2 |
| MISSING_CONSTRAINT | 1 | 0 | 1 | 0 |
| EXPIRED_BEFORE_USE | 9 | 2 | 2 | 1 |
| RATE_LIMITED | 1 | 0 | 0 | 1 |
| 其他低频标签 | 12 | 1 | 1 | 1 |
| 总计 | 42 | 6 | 8 | 5 |
关键发现¶
- 时间与完整性不能互相替代:附录 P 报告 GPT-5 到 GPT-5.1 的完整性平均奖励从 0.80 降到 0.47,下降 0.33;有效性与混合任务分别下降 0.25 与 0.20。回退更集中于完整性,但不是其他轴完全没有下降。
- Qwen 3.5 的跃迁不只是工具调用格式变好。作者观察到 4B 已会发出有效调用,却在早期失败后停止;9B 以上开始表现出等待、退避和调整策略,说明中途克制是重要诊断线索。
- 参考解可解不意味着模型稳定。附录 L 的 25 模型、2,259 回合、733 个重复单元子集中,86.6% 的模型—任务单元完全一致,另有 13.4% 存在差异;这限定的是该子集,不是 38 模型全部结果。
- 多轮保留 8,192 字节 URL 的 multi-turn-recall 在本文模型队列中全部失败。它支持研究上下文外产物存储,却不能证明任何框架或未来模型都无法解决。
- 正确标签也不保证恢复已经失效的资源。EXPIRED_BEFORE_USE 的 9 个配对回合中,正确提示与无提示都只恢复 2 个;单个 RATE_LIMITED 回合甚至只有错误标签条件成功,不宜用一个样本推导普遍策略。
亮点与洞察¶
- “中间输出是契约”比“中间输出是信息”更贴近可靠执行。它将不可改写的产物和可概括的解释区分开,适合迁移到长期运行的 API 智能体。
- 直接读取 HTTP 行动日志,让自然语言自述无法替代验证。固定模拟环境又使一次模型升级后的可靠性回退可以成为回归测试对象,而不是只看总任务分数。
- 正确与错误标签的配对对照比只展示重试改善更有解释力。它说明诊断内容有方向性,同时揭示过期、退避等问题可能需要执行框架保护,而非更长的自我反思。
局限与展望¶
- 虚拟时钟换取复现性,却省略真实网络延迟、抖动和 API 状态变化。生产可靠性仍需真实时间与故障条件下的测试。
- Base 模型缺少聊天模板或工具调用格式,0% 得分混合了协议入口失败与契约能力不足。因此 Base/Instruct 对比不能单独识别后训练对契约保持本身的因果贡献。
- 模型规模、后训练与提供商执行栈没有完全受控。GPT 版本回退的观察成立于本文设置,但将其进一步归因于特定训练目标或迎合行为,仍需要更直接的干预证据。
- 原文存在端点、种子/rollout、任务象限计数、局部结果与主榜不一致。另有文字声称单任务奖励 0.80,与 3 次二元 rollout 的均值粒度不符;不据此补造精确的逆缩放表。
- 33 个模板与 Q4 主导的分布不能代表全部生产 API,且没有人类基线。oracle 证明的是预定路径可解,不是任务覆盖性或人类使用难度。
- 可检验的后续方向是让 TTL、版本和退避窗口机器可读,并通过受控实验分别评估产物句柄存储、时间调度与退避中间件。应比较双轴错误变化,而不只报告总成功率。
相关工作与启发¶
- vs TicToc:TicToc 关注工具信息过时与重调用,ContractBench 增加主动截止时间规划和独立的完整性轴。两者互补,不能把字节错误归成信息陈旧。
- vs SWE-bench / Terminal-Bench:这些基准关注代码或终端任务完成,ContractBench 将外部 API 产物的后续使用作为主要评测对象。其诊断更细,但不覆盖一般软件工程能力。
- vs τ-bench / ToolBench:领域政策与工具使用评测不等同于中间产物的时间和字节约束。契约测试适合作为额外回归套件,而不是取代现有基准。
- vs Reflexion / Self-Refine:本文使用服务器产生的确定性错误标签而非模型自我批评,并加入错误标签对照。启发是把可恢复错误和需要框架介入的错误分开,再选择反馈或执行保护。
评分¶
- 新颖性: 4/5,将跨步骤产物约束明确拆成两个可程序验证的轴。
- 实验充分度: 3/5,模型覆盖较广,但重复次数少、重试样本小且数值口径有冲突。
- 写作质量: 3/5,问题定义清晰,协议和附录的多处不一致影响复现判断。
- 价值: 4/5,可用于智能体版本回归诊断与可靠执行框架设计。