2026 年 10 月 5 日

1 / 1

当“想出答案”越来越便宜，AI 的瓶颈可能转向把答案做出来

讨论更强 AI 时，一个很自然的假设是：如果模型可以更快写代码、设计实验、解决数学问题甚至提出新的研究方向，那么科技进步也会以接近同样的速度加快。OpenAI 10 月 4 日发布的《The eternal complement》讨论的正是这个假设中容易被略过的一环。两位作者没有尝试预测下一代模型能达到什么 benchmark，而是问了一个更基础的问题：知识生产究竟由多少“智能”之外的东西共同完成？

他们借用了经济学中的“互补品”概念。一个优秀的科学想法需要实验设备、技术人员、资金、组织、监管、供应链和制造能力才能转化成结果，因此前沿智力与执行能力实际上是互补投入。文章举了一个很直观的尺度变化：伽利略时代扩展人类观测能力需要的设备和组织相对简单，而詹姆斯·韦布空间望远镜耗资约 100 亿美元，由 14 个国家、约 300 个组织共同完成。现代科学问题本身越来越复杂，与此同时，把一个好问题真正变成实验和工程项目所需要的组织规模也在扩大。OpenAI

文章引用的研究生产率数据让这个问题更具体。斯坦福经济学家 Nicholas Bloom 等人的研究估计，为维持摩尔定律所需要的研究人员数量，相比 1970 年代早期已经增加超过 18 倍；从更大的经济尺度看，美国有效研究投入长期大幅增长，而单位研究投入产生的生产率增长却持续下降。OpenAI 的文章还引用美国国家科学基金会相关统计，指出技术人员队伍的增长速度快于科学家，以及现代科研对专门设备的依赖不断提高。作者由此提出一种解释：很多领域今天缺少的未必只是更聪明的研究者，还包括让研究者的想法得以执行的大量普通工作。OpenAI · Are Ideas Getting Harder to Find?

这使今天的生成式 AI 出现了一个很有意思的位置。代码生成、文献检索、数据处理、原型制作和文档工作，本来都是“有了想法以后”必须支付的执行成本。模型在这些任务上的进步意味着一个人可以调动过去需要小团队才能获得的能力。文章认为，在这一阶段，AI 更像一种扩大个人执行能力的基础设施：过去因为组织成本太高而无法尝试的电影、软件、研究问题或者小型产品，现在可能由更少的人完成。

如果这一趋势继续，稀缺资源会发生第一次转移。实现一个想法变便宜以后，“有什么值得实现”会变得更加重要。文章把这种能力概括为 taste，也就是从大量可能方向中识别哪些问题和作品值得投入资源。这个判断并不要求假定 AI 永远缺乏品味；它只是描述了当前阶段的一种相对价格变化：生成和执行候选方案的成本下降得比选择正确方向更快。OpenAI

更有意思的是第二阶段。假如未来模型不仅执行人的研究计划，也能提出大量高质量研究问题，今天的关系可能再次倒转。原来一个实验室有十个值得尝试的假设、资源只够验证两个；未来 AI 可能产生一万个同样值得验证的假设。即使分析和软件部分高度自动化，粒子加速器仍然只有一台，生物实验仍需要真实材料和时间，芯片仍需要晶圆厂生产，电网、机器人、矿山和建筑也不能以 token 的速度扩张。认知供给越丰富，物理世界反而越容易成为约束。

这也是这篇文章最值得保留的地方：它给“AI 加速科学”增加了一个比模型能力更完整的生产函数。模型解决问题的速度、实验吞吐量、机器人和自动化设备、能源、资本以及组织制度可能同时决定最终速度。只观察模型在数学、代码或科学 benchmark 上提高多少，很难直接推导现实科研生产率会提高多少。

这个框架也能解释为什么 agent 的发展越来越强调工具和环境。语言模型能够提出正确操作，并不意味着任务已经完成；数据库必须真的被修改，代码必须能够运行，采购和付款必须发生，实验设备必须执行指令，失败以后还需要恢复。最近的 agent 研究越来越把这些外部状态纳入评价，本质上是在测量“认知结果能否穿过执行链条”。例如 10 月 1 日发布的 Argo-Bench 构造了一个拥有 235 张表、约 75 亿行数据的企业数据仓库，让 agent 不只回答分析问题，还要做出封禁欺诈账户、分配骑手激励预算、补发薪资等操作；评分依据这些行动在模拟业务世界中造成的后果。14 个被测模型中，表现最强的模型也只有 34.8% 的任务达到 95 分以上。Argo-Bench 论文 · 项目页

把两件事放在一起看，可以得到一个相当具体的观察：随着模型推理能力继续提高，AI 系统的进步越来越可能取决于模型之外的执行系统——工具、权限、数据库、记忆、工作流、验证机制，以及最终与物理世界连接的设备。模型能够想到正确答案只是整个链条中的一个节点。

OpenAI 文章最终把这个问题推到了更长的时间尺度：即使未来机器同时拥有极强的创造能力和组织协调能力，物质世界仍然存在速度限制。工厂需要建设，能源需要生产，航天器必须飞过真实距离。作者甚至用光速作为这个思想实验的极端边界。这里已经明显属于关于长期未来的推演，而不是能够验证的近期预测；文章本身也没有给出 AI 何时会跨过这些阶段的时间表。OpenAI

因此，这篇文章对当下最有用的部分反而比较朴素：评价 AI 带来的生产率变化时，可以开始分别观察“产生方案”“选择方案”和“执行方案”的成本。过去几年最显眼的变化发生在前两者以及数字世界中的执行环节，而真正需要组织、设备、能源和物理操作的工作下降得慢得多。未来模型再提高一个数量级之后，这种差异可能比单纯比较两个模型谁更聪明，更能解释 AI 最终把现实世界推进了多快。

1 / 5

τ²-bench 的双控制环境：客服知道怎样修好问题，还要让用户真正完成操作

手机无法使用移动数据，客服可能需要检查账户状态、开通运营商侧的服务，再请用户关闭飞行模式、调整设备设置。前一部分可以由客服调用后台工具完成，后一部分却只能由用户在自己的手机上操作。即使客服知道正确解决方案，任务仍可能因说明含糊、步骤顺序错误或没有确认操作结果而失败。

τ²-bench 把这种控制权分散的情形纳入评测。它于 2025 年提出，在原有航空与零售客服任务之外引入电信领域：agent 和模拟用户各自拥有工具，能够观察并改变同一个环境的不同部分。模型因此既要诊断问题，也要通过对话协调用户行动。本期介绍的是这项已有工作的测量设计，论文中的早期模型结果也只作为解释设计的材料。τ²-bench 原始论文

可以用一个教学假设走完最小流程。用户说“到外地后手机上不了网”，运营商后台显示漫游服务关闭，手机侧也关闭了数据漫游。agent 能查询并修改前者，却不能直接操作后者。它需要先处理后台限制，再告诉用户打开设备上的数据漫游，最后请用户检查连接是否恢复。这个假设不是论文原始样本，用于说明两类动作如何共同决定结果。

如果评测允许 agent 同时调用两侧工具，它可以直接完成全部修改。若设备工具只属于用户，agent 必须把工具层面的解决步骤转化为用户能执行的说明，并根据用户反馈继续判断。两种测试面对相同的故障，测量的能力却已有变化：后一种增加了信息传递、控制权划分和行动确认。

这种变化也让观察变得不完整。agent 看得到运营商侧状态，却可能不知道手机当前设置；用户看得到设备表现，却不知道后台账户限制。任何一方都无法仅凭自己的局部观察判断全局问题已经解决。对话在这里承担了传递证据的作用：用户说“已经打开了”，agent 还需要确定打开的是哪个设置、是否生效，以及剩余症状是什么。

评测的运行轨迹由此具有两层含义。工具返回记录环境发生了什么，对话记录双方怎样交换信息。只有把两者对应起来，才能区分“agent 没有想到正确步骤”“想到了但没有说清楚”以及“用户没有按要求完成操作”。一份最终失败标签会把这些情况压在一起，轨迹分析才能进一步解释差别。

2 / 5

最终状态、参考动作与评分条件，分别约束了什么

τ²-bench 的电信任务通过程序构造。每个基础问题包含设置初始故障的方法、能够解决它的工具操作，以及检查目标状态的断言；多个基础问题再组合成复合任务。原论文的电信实验主要用环境断言判断是否成功，例如服务是否恢复连接。这使评分能够直接检查模拟环境，而不必仅根据结束语判断“问题已经解决”。任务生成与电信评分设计

不过，检查最终状态并不自动覆盖过程要求。仍以前面的教学假设为例：如果任务只验证手机最终联网，agent 通过未经授权的账户修改达到这一状态，也可能满足狭窄的结果条件。要同时评价授权、必要告知或禁止副作用，评分器必须明确检查这些对象。数据里出现了相关政策文字，不代表每条政策都已进入自动判分。

当前项目的评分文档进一步区分了参考动作和真正影响总分的条件。任务中的 actions 可以是一条生成目标数据库状态的参考路径；只有相应动作匹配条件被列入 reward_basis 时，参考动作才成为得分要求。数据库检查、环境断言、必要信息告知和自然语言断言，也分别由配置决定是否影响最终奖励。当前任务结构与评分文档

这个区别决定评测能否接受不同的正确解法。假设一项退款任务允许先查订单再查用户，也允许反过来，只要确认身份、满足政策并留下正确记录，两条路径都应有机会通过。如果评分器要求逐项复制一条参考轨迹，便可能把无害的顺序差异当成错误。反过来，若政策明确要求先获得确认再退款，只看最终退款状态又可能漏掉真正重要的过程违规。

因此，最终状态与轨迹检查各有用途。前者允许正确解法具有一定自由度，后者能够表达必须遵守的程序条件。增加轨迹检查时，需要区分哪些步骤具有实际必要性，哪些只是作者选择的一种实现方式；否则，测量可能从“任务完成得是否正确”滑向“是否复现参考脚本”。

版本也必须进入解释。原始论文定义的电信断言评测，与持续演进的仓库配置不能仅凭相同项目名称视为同一次实验。当前仓库已经包含后续的语音、知识检索与任务修正工作。复用历史分数时，应保留对应论文、任务集和评分实现；运行新版仓库所得成绩，需要按新版条件重新理解。项目当前范围与版本说明

3 / 5

三种运行设置怎样帮助定位失败，而不把差值当成纯能力分数

τ²-bench 原论文比较了三种设置。默认设置让 agent 与用户共同操作；No-User 设置把用户工具也交给 agent，由它独立解决问题；Oracle Plan 设置提前提供解决方案，但仍要求 agent 协调用户执行。这三种设置分别改变了控制权与规划信息，可以帮助观察任务困难来自哪里。原论文的消融实验

如果模型在 No-User 中经常成功，回到默认设置却频繁失败，说明把控制权分给用户后出现了额外困难。但不能把两个成功率相减，便称为模型的“纯沟通损失”：No-User 同时改变了信息呈现、操作权限和对话结构，差值是这组条件变化的总体影响。

Oracle Plan 也不是完全独立的沟通考试。提供正确步骤降低了规划负担，却没有消除执行中的判断。用户可能没有完成操作，也可能提供模糊反馈；agent 仍须识别当前处于哪一步、是否需要重述说明，以及何时检查结果。计划存在，并不保证执行状态已经正确。

一个更具体的教学假设是：默认设置中，agent 一直排查手机设置，遗漏后台漫游服务；No-User 中，它能够同时查询两侧状态并解决问题；Oracle Plan 中，它已经知道要开通服务和调整设备，却把两个步骤混在一句说明里，用户只完成其中一个。第一种失败偏向诊断覆盖不足，第三种偏向协调执行，最终状态检查则只能告诉我们两者都没有恢复连接。

这些设置适合提出有证据约束的解释，仍需要逐条轨迹支撑归因。若某模型在已知计划下提升，不能直接推出它的规划能力弱；它也可能只是更容易使用结构化提示。若给出更详细的流程反而降分，还需检查新增内容是否与已有计划冲突、是否改变上下文长度，以及模型具体遗漏了什么。

4 / 5

pass^k 为什么随着重复次数增加而下降

一次平均成功率不能说明同一任务能否稳定完成。τ-bench 因此提出 pass^k：关注同一任务独立运行 k 次全部成功的概率，再对任务求平均。它与代码生成中常见的 pass@k 方向相反；pass@k 关注 k 次中至少一次成功。两者在 k = 1 时一致，此后分别观察稳定完成与多次尝试发现解法的可能性。τ-bench 对两种指标的正式定义

用一个教学假设看清差别。某道任务运行四次，成功三次。如果从这四次中随机抽取两次，至少一次成功的组合有六组，pass@2 的样本估计为 100%；两次都成功的组合只有三组，pass^2 的估计为 50%。同一批运行记录，可以同时说明“尝试两次很容易找到一次成功”和“连续两次都正确还不够稳定”。

这两个数字都不代表生产请求可以免费重试。pass@2 假设我们能够识别哪次尝试成功，并利用它；若 agent 会修改真实记录，第二次尝试未必能从同一个干净状态重新开始。反复提交退款或重复创建工单，会改变任务本身。benchmark 在每次运行前重置环境，提供的是受控实验条件，现实重试还需要额外机制。

pass^k 也不能解释为“未来连续 k 次一定有这个保障”。它是基于有限样本、在独立试验假设下估计的稳定性指标。实际请求可能共享服务故障、账户状态或上游依赖，失败会相关；测试中的独立重置没有涵盖这些共同风险。

还有一层容易忽略：相同平均成功率，可以来自不同的任务分布。假设模型 A 对一半任务始终成功、另一半始终失败；模型 B 对每道任务都有 50% 的成功概率。两者平均成功率都是 50%。理想化条件下，A 的 pass^2 仍为 50%，B 则为 25%。前者的能力边界稳定但覆盖有限，后者覆盖看似更广，却对每个具体任务都不够可靠。

因此，重复指标需要与逐题成功次数一起阅读。某些任务从未成功，可能提示能力或任务定义的缺口；某些任务时好时坏，需要进一步检查对话变化、工具参数和执行顺序。一个较高的 pass^k 并不会自动说明模型覆盖了更多任务，它也可能主要来自一批稳定、容易的题。

5 / 5

模拟用户也是实验条件的一部分

双控制环境让用户工具返回可验证的状态，减少模拟用户凭空描述“已经重启”或“现在联网”的空间，但模拟用户仍由模型驱动。它可能误解指令、透露不该提前提供的信息，或执行与任务设定不一致的操作。换一个用户模型，便可能改变被测 agent 面对的困难。

这使实验同时包含被测模型、agent 实现、用户模拟器和环境规则。若一个客服模型更擅长与某种模拟用户交流，成绩可能提高；这种优势是否能够迁移到真人，需要另行验证。模拟中的用户配合程度、技术知识和表达方式，也不能直接当作真实用户群体的分布。

工具化的用户仍然比现实用户更受约束。真实的人可能找不到菜单、忽略一句话中的后半部分、担心费用，或误把一个设置当作另一个；评测环境则需要把允许观察和行动的范围编码清楚。τ²-bench 提供了研究这类协作的可控起点，能够测量指定条件下的完成情况，尚不能完整代表技术支持中的理解与解释质量。

读它的分数时，最终需要回到两个具体对象：环境到底恢复到了什么状态，以及双方经过怎样的交互达到或没有达到这一状态。前者给出可核查的结果，后者解释控制权分散以后新增的困难。把任务定义、实际评分条件、运行模式与逐题重复记录放在一起，才能判断一个客服 agent 是找不到方案，还是无法让方案在对话中被正确执行。