传统代码基准通常把全部输入一次性交给模型。模型读题、生成程序，评测器运行测试并给出通过或失败。真实 Agent 却经常面对另一种世界：信息并不完整，它必须先提出正确的问题，根据返回结果更新判断，还要在有限调用预算内完成任务。
InteractBench 把竞技编程里的交互题整理成一个可离线复现的评测集。322 道题来自 Codeforces、AtCoder、IOI 和 ICPC，每道题都配有本地交互器。生成的程序不能偷看隐藏输入，只能按协议多轮查询，再提交最终答案。
#静态代码正确，不等于会交互
交互题同时要求三种能力。
第一是信息获取策略。程序要决定问什么，才能用有限查询逐步缩小未知空间。第二是动态状态维护：每次响应都会改变内部判断，早期的小错误可能在后续轮次不断放大。第三是协议执行，包括输出格式、及时刷新缓冲区、终止条件和查询次数。
这与普通“运行测试—修改代码”的 Coding Agent 也不完全相同。InteractBench 要求模型一次生成自包含程序，之后由程序与裁判交互；评测的不是开发循环，而是模型能否把在线策略正确编码进程序。
#可靠交互器本身就是工程难题
直接调用在线裁判会受到网络、平台权限和题目变化影响，也难以记录细粒度失败。研究团队因此为每道题构造本地测试生成器与交互器，并让两个隔离进程通过标准输入输出通信。
为了减少模拟裁判写错，构建流程采用“提出—验证—裁决”循环：两个模型生成候选测试与交互器，用拥有官方判定的程序池进行执行验证，失败时由另一个模型根据轨迹提出修正。循环最多三轮，仍然模糊的题交给有竞赛经验的人类专家；322 道题中有 31 道需要专家介入。
每道题使用固定种子的 100 个测试用例，运行器还会检查协议和查询预算，并记录完整交互轨迹。这使评测不只返回通过率，还能区分程序究竟在哪里坏掉。
#前沿模型仍没有解决交互题
论文测试了 16 种模型配置，每道题采样 10 个解答，报告 pass@1 与 pass@5。整体最强的是 Gemini-3-Pro-Preview，pass@1 为 55.4%，pass@5 为 75.2%；GPT-5.2 分别为 54.2% 和 70.5%。
难度上升后差距迅速扩大。最强模型在简单题上的 pass@5 达到 96.1%，在困难题上只有 59.7%。GPT-5.2 的困难题 pass@1 为 34.0%，pass@5 为 49.2%。多采样能修复一部分实现脆弱性，却无法抹平能力缺口。
显式推理有明显帮助。DeepSeek-V3.2-Thinking 的整体 pass@5 是 51.3%，非推理版本为 26.2%。但较小模型即使开启推理，在困难题上仍可能接近零，说明“多想一会儿”不能替代足够的算法能力和状态控制。
#错误不只来自算法
评测把失败分成错误答案、协议错误、查询超限、死锁或等待、编译错误、运行错误与资源超限。
多数模型最常见的仍是错误答案，说明主要瓶颈是部分可观察条件下的算法与状态推理。但交互特有的失败并不少见。Gemini-3-Pro-Preview 的失败中，协议错误占 12.0%，查询超限占 11.9%；GPT-5.2 分别为 15.8% 和 10.1%。强模型往往能进入正确交互循环，却会把查询预算花光。
GPT-OSS-120B 则有 40.1% 的失败属于等待或死锁。定性分析发现，它有时把交互题误解为普通输入输出题，在没有发出查询时就等待隐藏输入。这不是算法答案算错，而是根本没有建立正确的执行心智模型。
分类结果还显示，图问题最难。即便最强模型，图类 pass@1 也低于 50%。这类题必须在隐藏结构上反复查询，并持续维护关系与不变量，更容易放大状态更新错误。
#对 Agent 评测的启发
InteractBench 的价值不只是增加一组代码题，而是展示了如何测量“信息尚未揭示”时的能力。许多现实 Agent 任务都属于这一类：先查数据库再决定下一步，先读页面再选择操作，先调用工具确认资源状态，再执行不可逆动作。
如果评测预先把所有相关信息塞进提示词，它会绕过查询规划；如果只看最终答案，它会掩盖协议违规和预算浪费；如果没有可执行交互器，就难以复现每一步状态。
这项研究仍有限：交互竞赛题数量比静态题少，实验采用零样本生成程序，也没有覆盖持续修改代码的开发型 Agent。它更像一块精确切片，而非完整的软件工程评测。但这块切片指出了一个清晰方向：下一代 Agent 基准需要把未知信息、交互协议、状态演进和调用预算放进同一个可运行环境里。