设想你让 AI 助手加载一份销售文件，删除重复订单，再按地区计算营收。前两步看上去平平无奇，第三步给出了一张颇有说服力的表格。然而，假如助手去重时针对的是重复客户，把这些客户的记录都删掉了，重复订单却没有得到正确处理，那么即使算术毫无差错，答案呈现的业务情况也已经失真。

这个假设中的错误，可以帮助我们理解 CIBench。这是一项代码解释器基准，由上海人工智能实验室和上海科技大学的研究人员开发。它关注的独特问题在于任务的连续性：下一条指令要承接此前操作留下的结果，助手还能否继续解决问题？论文最早发表于 2024 年 7 月，本文依据的是同年 11 月 6 日的修订版。[2]

会话会留下记忆

相关机构在论文发表前就已介绍过这项基准。上海人工智能实验室于 2024 年 1 月 30 日发布 OpenCompass 2.0 公告，将 CIBench 列入专项评测。中文公告介绍，这项测试在多轮对话中考察意图识别、编程、工具使用和推理能力。[1] 相比检查助手能否给出一段看起来合理的 Python 代码，这套评测提出了更高要求。

较早的一项基准有助于说明这项变化。2022 年 11 月推出的 DS-1000 从 Stack Overflow 取材，收集了覆盖七个 Python 库的 1,000 道数据科学编程题。其评测既检查程序的功能表现，也在题目有要求时检查解法的写法限制。[3] 这些测试各有价值：程序即使返回了预期值，仍会出现未按指令使用指定操作的情况。

CIBench 则在交互式 IPython 会话中加入了前后相连的问题。[2] 回到销售分析的例子，差别就很具体了。单独一道去重题，可以给模型一张干净的表，让它删除相应的行。持续进行的会话还要沿用助手实际处理出来的那张表。下一项请求到来时，助手此前的操作已经改变了它要面对的数据。

公开的提示词明确写出了这一点：执行结果会持续保留，智能体必须使用解释器，提交的代码也应仅针对当前步骤。配套配置采用 ReAct 风格的智能体，接入模型与 IPython 解释器，并设置 max_turn=3。[4] 交互轮数由此有了明确上限，尝试过程受到这一预算约束。

两种历史记录，两种能力问题

CIBench 的端到端模式承接模型自己此前完成的工作。oracle 模式则把参考代码和推理过程放入后续问题的上下文，以近似模拟外部协助。[2] 这里的 oracle 指一种评测条件；助手自身可靠性的提高，仍需要独立证据。

再看前面假设的销售分析。一次运行在删错数据行之后，进入按地区计算营收的步骤；另一次运行进入同一步骤时，历史记录里已有正确的准备过程。第二次若给出更好的答案，就为“助手在前期上下文正确时能够完成后续操作”这一解释提供了有用证据。至于助手能否发现并修正自己在准备数据时犯下的错误，这个问题仍待检验。

这种区分也能避免误判。模型最后的答案出错，仅凭这一点，还不足以判定它缺乏完成最后一步操作的能力。另一种解释是，输入已经被前面的操作破坏，后续计算本身却是正确的。同样，收到参考历史记录后完成任务，也只能证明助手在这一条件下的表现；它能否独立生成那份历史记录，仍需另行考察。

从这一角度看，两种模式让协助发生的位置清楚可见，也区分了两类合理的产品：一类协助分析人员，在其监督下工作；另一类受托完成整个任务序列。两者都能发挥作用，但各自的分数回答着不同问题，报告应在结果旁注明所用模式。

代码跑通，只是第一道检查

论文将工具调用、代码无报错运行与输出评估分开处理。它评估数值答案，用 ROUGE 评估结构化文本，并以视觉输出与参考图像之间的结构相似性来衡量图像结果。[2] 每项指标照见的都是工作中的不同部分。

在销售分析中，执行成功只说明解释器接受并运行了代码。助手是否正确界定了“重复”，还需要单独检查。即使按地区绘制的图表十分美观，也会掩盖这一步的判断。因此，执行得分与分析正确性之间，还隔着一层实质性的核验。

输出指标也需要解读。措辞相近，或图表外观相似，证明的是结果在所选指标下的相似程度。读者仍要了解，用户要求的计算量、分组方式和数据变换是否得到保留。在实际评测中，可以在分数之外抽查一部分完整交互记录，沿着数据首次加载到最终输出的全过程逐步核对。

CIBench 的作者也承认若干限制，包括仅覆盖 Python，以及在评估模型训练等含有随机性的任务时存在局限。[2] 把基准结果用于新的工作流程时，这些限制同样需要纳入考虑。可复现的表格变换与带有随机性的训练运行，对“正确输出”的判定有着不同要求。

分数旁还应交代什么

仓库的安装说明要求准备 OpenCompass、下载 CIBench 数据集，并另行运行脚本，收集数据集依赖的底层数据源。说明中还区分了保存的评测结果与输出图像。[4] 因而，最终平均分之外，这项基准还留下了多种可供检查的产物。

比较中国模型系列在这项任务上的表现时，一份有用的证据材料应写明模型检查点或带日期的 API 版本、数据集划分与语言、智能体提示词、解释器环境、交互预算，以及评测模式。凡涉及延迟或吞吐量，还应一并列出硬件与推理服务配置。这些是本文对后续比较提出的报告要求，本文并未实际测量这些结果。

本文解读的是 2024 年的一项评测设计，讨论范围止于此，并未对 2026 年的模型重新排名。它留下的启示，可以继续用于考察下一次模型发布：助手完成分析时，要追问分析笔记本在整个过程中经历了什么。当记录清楚交代了正确的历史由谁提供，最终答案就有了更多可供判断的依据。

来源

1. 上海人工智能实验室，《OpenCompass 2.0 评测体系发布》（2024 年 1 月 30 日；中文官方公告，介绍 CIBench 多轮评测的考察范围）。
2. Chuyu Zhang 等，《CIBench: Evaluating Your LLMs with a Code Interpreter Plugin》，arXiv 第 3 版（2024 年 11 月 6 日；涉及作者所属机构、连续会话、评测模式、指标与局限）。
3. Yuhang Lai 等，《DS-1000: A Natural and Reliable Benchmark for Data Science Code Generation》（2022 年 11 月 18 日；涉及题目构建，以及功能与代码形式的评估）。
4. OpenCompass 团队，CIBench 官方仓库（README 安装说明，以及公开的 cibench_eval/prompts.py 和 eval_cibench_hf.py 文件；查阅于 2026 年 10 月 26 日）。
5. 上海科技大学，《校园航拍，2022 年 8 月》（发布于 2022 年 10 月 18 日；官方图库，本文照片来源）。