当AI开始"行动"而非"回答"，我们该如何评判它的表现？

这项由德克萨斯大学奥斯汀分校、卡内基梅隆大学、加州理工学院、斯坦福大学、伊利诺伊大学厄巴纳-香槟分校、微软研究院、西北大学和剑桥大学联合完成的研究，以预印本形式于2026年5月发表在arXiv平台，编号为arXiv:2605.17829。这是一篇立场声明性质的学术论文，呼吁整个AI评估领域进行系统性的方法论革新。

**一个被忽视的根本性问题**

假设你是一名厨师考官，负责评估一位厨师的厨艺水平。传统的考法是：给厨师一份食谱，让他做出一道菜，你尝一口，打个分，完事。这种方法简单、公平、易于比较。

然而现实中的厨师并非如此工作。他们需要在嘈杂的厨房里与备菜员沟通，根据食客的反馈临时调整口味，应对突发的食材短缺，还要在同时制作多道菜的情况下保持节奏。如果你只是尝最后那道菜的味道，你根本无法知道这位厨师是凭借高超技艺完成了任务，还是靠侥幸蒙混过关，或者他中途犯了严重失误却碰巧补救回来了。

这个困境，正是当前AI评估领域面临的核心矛盾。过去很长一段时间里，我们评判AI的方式就像那位只尝最后一道菜的考官——给AI一道题，看它交什么答案，打个分，排个榜。这种方式对于评判"AI能不能答题"非常有效，但对于评判"AI能不能工作"，它就捉襟见肘了。

随着大型语言模型被越来越多地部署为真正意义上的"行动者"——它们不再只是回答问题，而是操作电脑、浏览网页、调用各种工具、与用户持续对话、甚至与其他AI协作完成任务——旧有的评估框架已经开始出现严重的裂缝。这篇来自多所顶尖机构研究者的论文，正是试图从根本上重新思考：当AI开始在世界中"行动"，我们究竟应该怎样评判它？

**一、从"答题考场"到"实习岗位"：AI评估的历史演变**

回顾AI评估的发展历程，就像观察一个考试制度的逐步演进。最早期的阶段，研究者们设计了各种标准化测试——GLUE、SQuAD、MMLU……这些测试就像是标准化的纸笔考试，AI收到一道固定的题目，给出一个答案，对照标准答案打分。这套机制之所以能够流行并持续使用，有其深刻的道理：它让不同AI系统之间的横向比较成为可能，结果可复现，评分过程透明且客观。

第二阶段，随着代码生成和工具调用能力的出现，评估开始走向"可执行任务"——不只是看AI说了什么，还要看它生成的代码能不能跑起来，调用的工具有没有拿到正确结果。SWE-bench（评估AI能否解决GitHub上的真实软件问题）就是这一阶段的代表性成果。这相当于考试从纸笔答题升级为了"上机操作"。

第三阶段，也就是当前正在快速发展的阶段，是真正的"交互式评估"。WebArena让AI在真实的网页环境中完成任务；OSWorld让AI像人一样操作计算机桌面；SOTOPIA让AI在社交情境中与他人互动；τ-bench让AI在真实业务场景下与用户持续对话……这些评估的共同特点是：AI的每一个行动都会改变环境的状态，进而影响它接下来能做什么、看到什么。

然而，论文的作者们指出，尽管这第三阶段已经出现了很多很有价值的工作，但整个领域目前处于一种"各自为政"的混乱状态——不同的评估基准在记录什么样的交互过程、如何对这个过程打分、以及这个分数究竟能说明什么问题上，存在巨大的差异，而且这些差异往往没有被清晰地说明。大家都在做"交互评估"，但对于这件事该怎么做、做出来的结果意味着什么，却缺乏共同的语言和框架。

通过对大量学术界和工业界的评估报告进行系统性分析，研究团队发现了一个耐人寻味的现象：在来自OpenAI、Anthropic、Google DeepMind等前沿AI公司的43个评估基准中，交互式评估占据了相当显著的比例；而在360篇学术界的基准测试论文中，传统的以单次回复为核心的评估方式依然占据主导地位。这两个群体正在朝着不同方向优化，使用着不同的评估逻辑，服务于不同的目标——这本身就是一个需要解决的结构性问题。

**二、什么是真正的"交互评估"：一个精确的定义**

在提出解决方案之前，研究团队首先做了一件看似简单却至关重要的事：精确定义什么叫"交互评估"。

他们将整个评估过程抽象为一个映射关系：评估是一个自主运行的程序，它接受某种"证据"作为输入，输出某种"判断"。用数学语言写就是 E : X → Y，其中 X 是评估者能够看到的证据，E 是把证据转化为判断的过程，Y 是最终的评估结果（比如分数、排名、通过/失败的决定）。

在传统的"答题式评估"中，X 几乎就是AI给出的那一个最终答案，E 就是拿这个答案跟标准答案比对或者请评委打分，Y 就是一个正确率或者满意度分数。

交互式评估的关键改变在于，X 扩展成了AI在整个交互过程中留下的完整"轨迹"——它问了什么问题、调用了哪些工具、收到了什么反馈、做出了哪些修改、中途犯了什么错误、有没有从错误中恢复过来……而 E 也必须相应地升级，不再只是核对最终答案，而是要对整个过程进行多维度的评判。

基于这个框架，研究团队给出了交互评估的精确定义：当评估所接受的证据包含由"因果相关的交互"所产生的轨迹，并且评估程序将这些轨迹映射为关于系统整体表现的判断时，这才构成真正的交互评估。

这个定义有几个重要的边界条件，用来排除一些"看起来像交互但其实不是"的情况。多轮对话本身不够——如果后面的对话内容是提前写好的，不会因为AI之前说了什么而改变，那它只是"顺序执行"而非真正的交互。工具调用本身不够——如果调用工具只是一种内部计算，结果不会改变评估证据或系统状态，那它依然是单次回复评估的变体。思维链和自我反思本身不够——内部推理过程只有在被特定协议明确纳入评估证据时才有意义，交互必须涉及一个真实的外部循环，而且这个循环的走向部分取决于AI的行动。

用厨师考试的比喻来说：真正的交互评估，要求考官不只尝最后一道菜，还要全程记录厨师的每一个动作、每一次与帮厨的沟通、每一次根据食客反馈做出的调整，并基于这份完整记录作出综合判断。

**三、给交互评估画一张地图：两维度分类体系**

定义清楚之后，研究团队进一步提出了一个用于组织整个交互评估领域的分类框架。这个框架有两个维度，就像一张坐标轴，可以把现有的和未来的所有交互评估基准定位到这张地图上。

第一个维度是"证据来自哪里"，也就是AI跟什么东西发生了交互。目前主要存在四大类型。

第一类是工具与环境。AI在这里的互动对象是数字工具和可执行环境——网页、操作系统、文件系统、应用程序、游戏……WebArena、OSWorld、AndroidWorld、AppWorld、MineDojo等基准都属于这一类。AI的每一次点击、每一条命令，都会改变环境的状态，进而影响它接下来能观察到什么。这就好比评估一个汽车驾驶员的能力，路上遇到的每个情况都会因为之前的驾驶决策而改变。

第二类是用户。AI在这里需要与人类（或模拟人类）进行持续的交互，处理模糊的、不断变化的指令。τ-bench、ToolSandbox、IN3、RealWebAssist等基准属于这类。这里的评估不只关注任务有没有完成，还要看AI有没有真正理解用户意图、在信息不完整时有没有合理地寻求澄清、有没有在整个对话过程中保持与用户目标的一致。这就像评估一个客服代表的能力，不只是看他有没有解决问题，还要看他如何与客户沟通。

第三类是其他AI智能体。这里评估的是多个AI之间的协作、竞争、协商和涌现行为。SOTOPIA、MultiAgentBench、BattleAgentBench、CooperBench等属于这类。相关证据可能包括消息交换、角色分配、联合计划、冲突点以及对方的适应行为。这就像评估一个团队成员的协作能力，而不只是评估个人能力。

第四类是混合与动态系统，也是目前最稀缺、但未来最重要的类型。这类评估同时结合了工具、用户、多个智能体、持久化记忆以及变化的环境。MemoryArena（评估跨会话的持久记忆能力）、AI Gamestore、ARC-AGI-3等指向这个方向。这类评估要求AI不只是在单次任务中表现良好，而是在跨越时间的持续交互中保持可靠。现实中部署的AI助手恰恰就是这种混合动态系统，但目前针对它的评估工具严重不足。

第二个维度是"怎么评判这些轨迹"，也就是评估程序关注什么。研究团队识别出了几种不同的评判逻辑。

最基础的评判逻辑是任务成功率——最终状态有没有达到目标。网页任务完成了吗？代码问题解决了吗？这是必不可少的，但单独使用时严重不足，因为两个不同的执行过程可能达到同一个最终状态，却经历了完全不同的风险和代价。

更深入的评判逻辑是过程质量与效率——AI在达到目标的过程中用了多少步骤、选择了什么工具、编辑代码时有没有只修改必要的部分而不是大范围乱改、与用户沟通时有没有无谓的干扰……这些过程性指标之所以重要，是因为低质量的过程往往预示着部署后的脆弱性，即使最终结果侥幸成功，长期来看也难以可靠运行。

还有可恢复性与鲁棒性——当系统遇到错误时，它能不能发现问题、修正计划、在干扰下保持有效？失败在交互评估中不只是一个终点，而是一个可以被观察、被修复或者被放大的事件。能够在逆境中恢复的AI，和遇到第一个障碍就卡死的AI，理应得到不同的评分。

此外还有安全性、对齐程度与社交能力——当AI与用户或其他智能体交互时，它有没有尊重规范、诚实面对不确定性、避免操纵性或不安全的策略？这些特性在只看最终答案的评估中完全看不见，但对于判断一个交互系统是否值得信任却至关重要。

把这两个维度放在一起，就形成了一张二维地图。研究团队将大量现有的交互评估基准标注在这张地图上，立刻就呈现出了几个清晰的规律。

**四、地图上的空白地带：现有评估的系统性缺口**

这张二维地图最有价值的作用，是让人一眼就能看出哪些区域挤满了标注点，哪些区域几乎空白。

最明显的现象是"轨迹证据依然以结果为中心"。虽然很多现有的基准已经开始记录AI的交互轨迹，但它们在评判这些轨迹时，往往还是只关注最终是否成功。用厨师考试的比喻说，考官虽然全程录像了，但最后评分时还是只看那道菜味道好不好，根本没有去看录像。这意味着"收集轨迹"和"真正评估轨迹"之间，存在一个巨大的落差。可恢复性和鲁棒性的评估尤其稀缺，而这恰恰是交互评估最独特的优势之一——在单次回复评估中根本无法观察到的东西。

另一个问题是"评估程序被基准的技术底座所束缚"。工具与环境类基准通常只评估任务成功和过程效率；涉及多智能体的基准通常只评估安全性和社交能力；混合动态系统几乎在所有评估维度上都严重不足。这说明评估者们往往跟着基准的"形状"走——该基准最容易测什么就测什么，而不是先想清楚"我们最需要知道AI在什么方面的能力"，再反过来设计如何收集证据。

混合动态系统作为最接近真实部署场景的评估类型，目前是整张地图上最空旷的区域。这造成了一个令人担忧的错位：实际部署中，AI系统正越来越多地工作在持久状态、跨会话依赖、混合交互循环的环境里，但我们评估AI的工具，却没有能力测量这种环境下的性能。

除了这些全局性的空缺，研究团队还指出了交互评估在实践层面的三个具体问题。

其一是成本高昂。与传统评估不同，交互评估往往需要长时间的展开过程、有状态的环境、多次重复运行、人类或模拟的互动对象、轨迹存储以及轨迹级别的评判。这让评估变得昂贵且难以审查，对于资源有限的小型研究团队尤其不友好。

其二是人类验证严重不足。很多交互评估依赖于自动化评分或者"用AI来评AI"（即LLM-as-a-judge）的方式，即便被评估的行为涉及用户意图、社交适当性或者需要领域专家判断的专业知识。在这些情况下，人类参与的验证往往是必要的，而缺少这种验证，可以高效运行的评分系统可能看起来可靠，却无法捕捉到只有在真实用户交互中才会暴露的失败。

其三是实验协议难以复现。交互评估的分数高度依赖于具体的协议选择——工具的访问权限如何设置、AI能观察到什么、可以重试多少次、环境如何重置、使用了哪个版本的环境……这些细节的微小变化，可能彻底改变AI有什么机会可以利用、失败意味着什么，以及两条轨迹是否真的可以比较。没有精心设计的协议报告，后续研究可能看起来是在同一个基准上测试，实际上却是在截然不同的交互条件下运行。

**五、设计原则：如何做好交互评估**

基于以上分析，研究团队提出了一系列具体的设计原则。这些原则不是空泛的口号，而是针对现有问题的直接回应。

首先，必须明确说明被评估的是什么系统，以及轨迹证据能支持什么样的主张。只报告"模型名称"是不够的——工具包装器、记忆模块、检索系统、执行沙箱、用户模拟器、编排策略，这些都会影响性能。记录轨迹也不够——还必须说明这些轨迹究竟能支持关于任务成功、过程质量、可恢复性、安全性、效率、协调能力的哪些判断，以及哪些判断是它无法支持的。

其次，必须明确说明交互协议。轨迹证据只有在知道它是在什么条件下产生的情况下才能被正确解读。这包括初始状态的分布、允许的动作空间、可观察的范围、对方的行为方式、停止规则、随机性的来源、持久化设置以及重置条件。协议文档对于交互评估的意义，就相当于传统数据集的数据说明文档：没有它，分数可能反映的是交互设置上的隐藏差异，而不是系统能力的真实差异。

第三，要为干扰和修复场景进行专门设计。随着评估任务走向更复杂的动态环境，仅仅在干净的任务完成情况下测试已经不足以评估真正的交互能力。未来的评估基准应该专门测试系统在交互条件变化时能否保持有效——包括模糊信息、误导性反馈、部分失败、状态漂移以及对方策略的变化。这些条件不应被当作"对抗性附加功能"，而应被视为交互评估的核心内容，因为它们揭示了一个系统能否发现问题、修正策略、从错误中恢复，并在不断变化的条件下继续有效行动。

第四，要将结果、过程和风险分开报告。最终任务成功率依然重要，但不应该是唯一的指标，更不应该将其他信息都隐藏在一个综合分数里。当这些维度各自重要时，交互评估基准应当分别报告最终成功率和轨迹级别的属性，如动作成本、不安全行为、恢复行为。综合分数仍然可以作为系统排名的工具，但应被视为多个维度的摘要，而不是系统能力的唯一证据。

第五，要建立共享基础设施，但不要固化设计空间。整个领域需要可复用的评估环境、标准化的轨迹记录格式、轨迹查看工具、评估套件以及报告模板。与此同时，标准化不应导致所有评估基准都收敛为同一种狭窄格式。一个健康的生态系统应当在评估主张如何被明确和报告方面保持一致，同时在评估环境、交互基底、对方模型和轨迹评判程序方面保持多样性。

**六、旧问题的新面貌：交互评估中的风险**

任何评估体系都有被滥用的风险，交互评估也不例外。更重要的是，交互评估带来了一些传统评估中没有、或者在新的层面上更加严峻的风险。

过拟合、数据泄露和刷榜问题在交互评估中以新的形式出现。静态基准可能被记忆，交互基准可能被"政策性游戏化"。AI系统可能学会在基准的模拟器里策略性地行动，利用模拟器的规律性漏洞，避开有意义的探索，优化那些能讨好评分系统的表面轨迹特征，或者发现满足评分者却没有真正展示预期能力的捷径。应对措施必须在轨迹级别上起作用：使用私有的、程序化生成的任务，对不寻常的高效或不自然的轨迹进行审计，定期刷新评估套件，引入对抗性干扰。

分布偏移和基准脆弱性的问题在交互评估中比传统评估更加严峻。界面、时序、初始状态、工具行为或对方响应的微小变化，就可能改变轨迹本身。这种敏感性不应被当作噪音一笔带过——真实部署也会涉及变化的状态、不完整的指令和变化的对方。但评估必须能够区分能力缺失、政策脆弱性，还是仅仅是对部署相关变化的正常敏感性。报告应包括跨随机种子、环境、用户、干扰和状态初始化的方差，并说明失败反映的是哪种情况。

标准化与多样性之间的权衡是交互评估独有的风险。过度的标准化会把定义能力的交互模式范围收窄。一个健康的生态系统应当在评估主张如何被明确和报告方面标准化，但在环境、交互基底、对方模型和轨迹级别评判程序方面保持多样性。

仿真保真度与控制性之间的张力是另一个没有完美解答的问题。高保真环境能提供更丰富的关于情境行为的证据，但成本高、噪音大、难以控制。可控的模拟器提高了可重复性和可比性，但可能奖励利用模拟器特性的策略而非真正的交互能力。基准应当说明它忠实模拟了哪些部署条件、刻意抽象了哪些，以及它的保真度水平能和不能支持什么样的主张。

评估者和对方的依赖性风险随着用户模拟器、模型评委、人类专家和对方智能体成为标准化评估基础设施而逐渐浮现。分数可能会奖励对特定评估者或对方策略的适应，而非预期的能力本身。这带来了构建效度的风险：系统可能在某一评委、模拟器或专家组下表现良好，但在同样合理的替代方案下失败。未来的评估基准应当测试结论在评估者和对方变体之间是否稳定。

**七、一些值得深思的边界问题**

研究团队还专门讨论了几个容易引起混淆的边界问题，这些讨论让整个框架更加精确。

交互评估并不等同于智能体评估。并非所有号称在评估"智能体"的基准都需要交互评估——如果AI的动作不影响后续条件，或者只评判最终输出，那它本质上还是单次回复评估。反过来，一些并没有被描述为自主智能体的系统，如果其行为通过工具、网页环境、用户或其他外部循环展开，也可能需要交互评估。关键问题不是系统叫什么名字，而是评估需要什么证据来支持其主张。

轨迹级别的评估是依赖于主张的。这个框架并不主张所有评估都应该变成高保真的模拟，或者任务成功率应该被取代。任务成功率在预期主张涉及最终完成情况时依然不可或缺。问题出现在基准记录了轨迹，却只把它们当作最终成功标签的证据时。如果主张涉及过程质量、可恢复性、安全性、效率、协调能力或鲁棒性，那么评估程序就必须保留并评分相关的轨迹证据。设计挑战在于将交互评估的成本和保真度与主张相匹配。

**八、两个具体场景：框架如何落地**

为了让上述框架不至于停留在抽象层面，研究团队通过两个具体场景展示了如何将这套理念付诸实践。

第一个场景是代码智能体的评估。代码智能体在仓库级别的反馈循环中工作：检查文件、运行命令、观察测试失败或错误跟踪、编辑代码、根据反馈修改方案。因为这些动作会改变后续的观察结果和修复机会，相关证据是完整的交互轨迹，而不是单个最终补丁。

传统代码生成基准只对最终输出打分，但仓库级别的智能体提出了更广泛的主张。两个智能体可能都通过了隐藏测试，但一个依靠原理性诊断和局部编辑，另一个依靠脆弱的修改或可见测试的过度拟合。最终通过/失败的标签把这两条轨迹视为等价，尽管它们对调试能力、可维护性和部署可靠性支持着完全不同的主张。

在这个框架下，代码智能体评估的输入证据X应该包括仓库状态、问题文本、工具调用、文件编辑、测试执行、错误跟踪和最终补丁。评估程序E不只应该判断问题是否解决，还应该判断补丁是否局部且可维护、智能体是否利用测试和错误进行恢复，以及是否避免了附带损害。具体来说，代码智能体基准应当说明工具访问权限、测试访问权限、重试策略、仓库重置条件和日志格式，并且把最终解决率和轨迹级别的指标分开报告。

第二个场景是多智能体社交系统的评估。多智能体社交评估是一个交互设置，因为系统在一个社交反馈循环中与其他智能体互动，这些智能体的信念、策略和未来行为可能会因为它的动作而改变。被评估的智能体不只是产生一个孤立的话语，它沟通、谈判、协调、拒绝、适应对方的行为，并且可能随着互动的展开调整自己的策略。

单次回复评估可以评估一个孤立的话语，但社交智能体提出了关于协调、公平、沟通和鲁棒性的更广泛主张。比如，一个谈判智能体可能在某一轮做出合理而清晰的提议，却同时利用对方的让步、对待更强和更弱的对手有所不同，或者在不寻常的沟通风格下崩溃。这些特性需要来自完整互动轨迹的证据，而不只是孤立的回复。

在这个框架下，多智能体社交评估的输入证据X应该包括消息、角色分配、私有和共享信息、承诺、提案、拒绝、冲突点、对方行为和最终结果。评估程序E应该区分社交目标是否完成、智能体是否有效协调，以及沟通是否公平透明。具体来说，多智能体基准应该说明角色分配、信息不对称、对方行为、记忆、轮换规则、停止标准和隐藏目标或约束，并且把群体成功和轨迹级别指标分开报告。

**说到底，这篇论文在做什么？**

归根结底，这篇论文做的是一件在技术领域常常被忽视的基础性工作：在一个新范式还没有完全成形之前，提前建立起它的概念框架和设计原则。

研究团队观察到AI评估正在经历一场结构性转变。当AI不再只是一个"回答问题的系统"，而是变成一个"在时间中行动的系统"时，评估这个系统的标准和方法也必须随之改变。但目前这种改变正在以一种杂乱无章的方式发生：每个新的交互评估基准都在自己发明轮子，各自做出不透明的设计选择，导致不同基准之间的结果根本无法比较，也不清楚每个分数究竟在声称什么。

这篇论文呼吁把交互评估作为一门设计科学来对待——就像医学研究有严格的临床试验设计规范、工程研究有系统的测试协议一样，AI交互评估也需要明确的证据规范、协议文档标准和报告要求。这不是为了让评估变得更复杂，而是为了让它变得更可靠、更可解释、更有科学价值。

对于普通用户来说，这项研究的意义可能要等到几年后才会变得直观——当你的AI助手在长期使用过程中变得越来越可靠，在犯错后能够自我纠正，在你的意图不明确时能够合理追问，而不是给出一个看起来正确但实际上南辕北辙的答案……这背后，正是建立在更好的评估体系之上的更好的AI系统。

如果你对这套框架的完整技术细节感兴趣，可以通过arXiv编号2605.17829查阅原论文，获取包括分类体系、设计原则、具体场景和替代观点讨论在内的完整内容。

Q&A

Q1：交互评估和传统AI评估有什么本质区别？

A：传统AI评估只看AI给出的最终答案，就像只尝厨师做的最后一道菜。交互评估则记录并评判AI在整个工作过程中的完整轨迹——它调用了哪些工具、遇到错误后有没有恢复、与用户沟通时有没有真正理解需求。核心区别在于，AI的每个行动都会改变后续的状态和观察结果，最终答案已经不足以作为评判系统能力的全部证据。

Q2：为什么现有的交互评估基准存在问题？

A：现有的交互评估基准主要有三个问题：首先，很多基准虽然记录了交互轨迹，但评分时还是只看最终是否成功，没有真正利用过程信息；其次，不同基准的实验条件差异很大，比如工具访问权限、环境版本、重试次数等，导致不同基准的分数无法横向比较；第三，涉及用户交互和多智能体协作的评估严重依赖自动评分，缺乏必要的人类验证，可能遗漏真实使用中才会暴露的问题。

Q3：AI交互评估中的"可恢复性"具体指什么？

A：可恢复性指AI在遇到错误或意外情况后，能否主动发现问题、修改计划，并继续有效完成任务的能力。比如，代码智能体运行测试失败后，能不能根据错误信息定位真正的问题，而不是随机地多次乱改代码；或者在被误导性信息干扰时，能不能识别出异常并调整策略。这种能力在只看最终结果的评估中根本看不见，却对预测AI在真实部署中的可靠性至关重要。