Async-RBench：评测大语言模型智能体中的异步任务执行（附录）

Async-RBench：评测大语言模型智能体中的异步任务执行（附录）

下文是同一篇论文的附录 A、B、C，接在正文与参考文献之后。数字、案例名和评分点按原文翻译，没有删节。

附录 A 任务集构建与场景规格

A.1 任务来源与构建过程

候选任务来自 Terminal-Bench、Gaia2、OSWorld、SWE-bench 和 MultiAgentBench（Merrill et al., 2026; Froger et al., 2026; Xie et al., 2024; Jimenez et al., 2024; Zhu et al., 2025a），覆盖终端交互、桌面应用、软件工程和多智能体协作。来源任务提供原始目标、初始环境和接纳标准，我们据此设计子智能体工作流、结果版本关系和释放条件。

构建从固定来源版本、任务标识和初始环境开始，并检查任务是否有明确目标、可执行工作流和可验证的最终状态。随后一个大语言模型智能体标记子智能体结果可能影响的决策点；它的建议只用于筛查。研究者检查信息依赖，以识别可以委托的工作，以及新结果可能影响的计划、产物或检查，并确定场景标签和评分要求。他们接着设计子智能体工作流、结果内容、版本关系、释放条件和事件时间线，并撰写事件响应契约（ERC）。人工复核检查来源证据、新结果的有效性、其任务后果与评分要求是否一致；只有在事件之后必须修订、保留或重新验证哪些工作已经清楚时，候选才成为可执行实例。图 7 概括这一过程，附录 A.5 描述执行接纳。

图 7：任务构建与接纳。大语言模型智能体的筛查进入由人主导的场景与 ERC 设计和复核；组装好的实例随后在两种交付模式下接受执行检查，并配有参考解或等价解以及无效变体。

A.2 任务构成与汇总

构建集含 47 个任务，评测集含 200 个任务，二者没有重叠。评测集覆盖八个场景，每个 25 个任务，以及五个原始来源，每个 40 个任务。其 200 个任务包含 621 个初始子任务：36.5% 的任务以两个子智能体开始，20.0% 以三个开始，43.5% 以四个或更多开始；52.0% 被评为中等，48.0% 为困难。

评测对任务等权，不再加场景权重。因为八个场景的任务数相同，在完整覆盖下对场景均值取平均，等价于对全部任务取平均；每个场景贡献总体结果的八分之一。构建集不进入任何被报告的结果。

A.3 抽样人工复核与验证器接纳

构建期间的人工复核检查任务要求是否清楚、必需输入是否可用、评分条件是否与任务目标匹配。沿用把自动轨迹评测器与专家判断对照的工作（Lù et al., 2025），我们也审计验证器。我们从评测集随机抽取 405 条运行记录。审计者检查任务要求、初始状态、被呈现的结果、轨迹、工具输出和最终产物；模型自称完成本身从不被当作成功证据。若审计者判断某产物有效而验证器拒绝它，则该验证器决定计为误拒；相反情形计为漏检违规。在初始审计中，人类判断与自动决定的项级一致率为 96.6%。每一处分歧都追溯到外部基础设施故障；样本中没有发现任务设计问题。我们随后在全部模型、模式和重复上筛查所有运行记录中的同类异常，修复环境，并重跑全部受影响的运行。重跑通过了运行有效性检查并替换了受影响的记录，而可归因于模型的任务失败予以保留。这些结论适用于被审计的样本和版本；它们并不确立验证器没有误拒或漏检。

A.4 异步场景分类

八个场景按结果有效性、信息完整性、任务依赖和执行调度组织。每个实例有一个主要场景标签，并可能要求修订、保留、避免被禁止的改动，以及重新验证。标签描述主要的事件关系；任务证据和依赖决定具体的响应要求。

#### 结果有效性。

在延迟权威中，主智能体先用临时信息推进，随后到达一个取代或纠正它的结果，因而必须修订受影响的工作。在过时与顺序中，较新状态已经生效之后才呈现较旧的结果；主智能体必须识别版本关系，并避免回滚有效状态。在冲突结果中，来自有效工作流的输出支持不同结论；主智能体必须用来源、范围和任务约束来消解它们。重复与重放要求对重复结果做幂等处理，避免重复写入、重复提交或不必要的重建。

#### 信息完整性。

部分到完整先呈现局部证据或中间产物，后呈现完整结果。主智能体必须把临时信息与完成证据区分开，并在完整结果到达后完成整合与验证。在子智能体失败中，子智能体未能完成所指派的工作、报告失败，或拒绝继续执行。主智能体必须恢复受影响的子任务，同时保留其他子智能体已完成的有效工作。

#### 任务依赖与执行调度。

范围与依赖要求主智能体把范围、依赖关系或接纳条件的变化传播到相关产物和检查，同时保留无关工作。资源掉队者把被延迟的关键结果与变化中的资源约束合在一起。主智能体必须用任务依赖在等待、取消、重新指派和继续执行之间选择，同时保留有效的已完成状态。

一个事件可以施加多项响应要求。例如，迟到的权威结果可能要求修订一个依赖文件、保留未受影响的测试结果，并在更新后的状态上重跑相关检查。因此 ERC 把场景关系翻译成具体的修订范围、保留要求和验证证据。

A.5 案例规格与执行接纳

每个实例包含公开的任务信息和私有的评测信息，如表 5 所概括。主智能体可以使用任务要求、初始环境、可用工具和已被呈现的子智能体结果。场景标签、期望响应和验证器内部状态对受评测系统保密。

表 5：案例成分与信息边界。公开的版本与依赖证据来自任务或已被呈现的结果；评测方保留完整的受影响范围、响应要求和评分证据。

附录 B 八个场景的代表性案例

本附录为八个场景各呈现一次被记录的运行。每张图保留任务、子智能体结果和主智能体后续动作中的相关节录。E 标识轨迹事件，[...] 标记省略，虚线框标出下文讨论的证据。图中 “Main agent” 表示主智能体，“Subagent” 表示子智能体。replayed 和 replay_of_completion_id 等字段来自评测方的交付记录，框架把它们与呈现给主智能体的结果分开记录。分析限于所示记录：子智能体报告和主智能体的最终响应描述其执行，但并不独立地确立任务成功。

B.1 延迟权威：选择部署后端

任务要求根据适用于最终部署的配置文件，选择并行后端、配置文件版本和 world size。一个子智能体先返回权威的配置文件 v2，建议流水线并行且 world size 为二；稍后的一份候选实现报告仍引用 v1。主智能体随后把 v2 写入部署配置和批处理谱系记录。必须把到达时间与配置文件的适用性区分开：较晚的报告不一定为部署提供更新的依据。

B.2 过时与顺序：修复 Bottle 头注入

仓库被清理并重写之后，一个子智能体报告新的分支修订标识。一份补丁报告稍后到达，但仍把重写前的修订作为其测试依据。主智能体随后运行一次本地头部检查，覆盖回车、换行和空字符；所示命令成功退出。顺序可能误导：新收到的报告可能依赖过时的代码状态。旧修订上的测试结果不能直接代替对当前仓库的检查。

B.3 冲突结果：恢复并移除 Git 密钥

仓库扫描器对一个密钥返回不同发现。对工作树和 ref 可达历史的扫描没有匹配，而对象数据库报告在一个不可达对象中定位到目标。这些表面上冲突的结果覆盖不同的仓库范围。随后的恢复使用对象数据库的发现，清理报告记录了 reflog 过期和垃圾回收。主智能体需要检查每个扫描器覆盖哪些仓库状态，而不是仅仅因为报告写着「找到」或「没找到」就在报告之间选择。

图 8：（a）延迟权威：部署后端选择。（b）过时与顺序：Bottle 头注入。

图 9：（a）冲突结果：Git 密钥恢复。（b）重复与重放：OfficeTaskScheduler。

B.4 重复与重放：构建 OfficeTaskScheduler

同一次完成在首次交付之后再次出现，重放保留原来的完成标识。主智能体最初拒绝该结果，后来接受它；这一变化发生在重放之前。重放到达后，主智能体又记录了一次接受。因此该图确立的是重复交付和确认，而不是重放改变了决定或造成了重复执行。评估这一响应需要分别检查完成的身份、已有决定，以及任何实际副作用。

B.5 部分到完整：修复 SymPy 量纲推断

主智能体最初加入指数函数的特殊情形，以处理对无量纲指数的错误拒绝。一份更完整的报告随后说明：修复必须保留量纲参数的含义，并检查其他函数的量纲约束。主智能体据此修订通用函数分支。然而稍后的报告警告，不要把这一规范化扩展到任意用户定义函数。轨迹保留了这些相继的范围变化：附加信息先扩大最初的修复，再进一步限制它应当适用的位置。

B.6 子智能体失败：构建 MultiServe 配送应用

没有实际应用上下文时，一个子智能体构造了按区域和优先级给订单分组的配送实现。主智能体拒绝这一结果，同时接受另外三个子智能体的结果。其最终响应把拒绝归因于与实际餐厅、订单和骑手接口不匹配，并陈述主智能体自己实现了相应的物流逻辑。这里的失败指不可用的子任务结果，而不是崩溃的子智能体进程。恢复关乎替换该结果，同时保留其他已完成的工作。

B.7 范围与依赖：修复 Pylint 正则解析

任务处理正则量词中的逗号被误当成列表分隔符、从而错误拆分 foo{1,3} 这类输入的问题。主智能体检查若干含有量词逗号和普通分隔逗号的输入。后续报告考察普通列表解析和配置加载路径是否受影响，并提供相应测试用例。因为相关逻辑服务多个配置入口，修复不能只让目标表达式工作：它还必须保留其他调用方所期望的解析行为。

B.8 资源掉队者：修复 Matplotlib 图形的 pickle

案例配置把并发额度设为一个槽位；轨迹显示一个被扣住的结果，随后是交付截止。返回的报告称已有的 pickle 测试通过，但也指出它们不覆盖调用 align_labels() 之后的图形。稍后的针对性检查报告不可 pickle 的弱引用对象，此后主智能体改变相关分组对象保存和恢复其状态的方式。重要的问题是被延迟的结果增加了什么证据：已有测试通过，并不能确立任务的特定调用路径是工作的。

图 10：（a）部分到完整：SymPy 量纲推断。（b）子智能体失败：MultiServe 配送应用。

图 11：（a）范围与依赖：Pylint 正则解析。（b）资源掉队者：Matplotlib 图形的 pickle。

附录 C 执行细节与成本分析

本附录描述结果交付、执行限制、运行核算和成本分析。第 3.2 节定义指标，附录 B 给出八个场景的例子。

C.1 结果交付与信息边界

子智能体结果在结果网关按其内容、文件和结构对照公开提交要求检查之后，进入交付队列。框架在一次主智能体调用中记录每次呈现的载荷和时间。这确立的是主智能体已收到；仅完成或进入队列并不算收到。重放交付被分开记录。

两种模式都并发执行子智能体。批量交付等待全部必需工作流通过成功、失败、超时、取消或提交被拒而终止，再按稳定顺序一起呈现结果。异步交付在主智能体继续工作的同时，每次主智能体调用至多加入一个新结果。每个结果获得一个处理窗口，至少一次、默认至多四次主智能体响应；更晚的交付等到窗口关闭。该窗口控制更晚的结果何时交付；关闭窗口并不结束事件评分。若被扣住的结果在最长持有时间内未满足释放条件，控制器仍释放它并记录回退原因；附录 C.3 中的运行就是这种情形。

评分以呈现前的状态为基线，并跟随运行直到终止。过程分使用这一区间上的动作、产物变化和验证记录；结果分使用终止时相关的已保存状态。窗口关闭后的修补因此可以满足最终状态要求，而稍后的损坏可以降低结果分。若某个评分点在整个响应期间禁止一种副作用，随后的修补并不抹去该违规。实际终止时间就是证据截止，无论运行正常结束、提前停止，还是达到执行限制。评测方事后可以检查已保存的产物，但不得修改它们，也不得提供本应由参与者执行的验证。

主智能体与子智能体的工作区相互隔离；子智能体产物需要被显式整合进主智能体的工作区。私有的事件角色、受影响范围、验证命令和答案保持隐藏。通过公开提交检查的结果仍可能在语义上是错的，并需要主智能体判断。来源轨迹只用于构建和来源追溯，不用作参与者输入、参考答案或动作匹配目标。

C.2 执行预算、终止与异常

两种模式都把主智能体限制为 100 次响应，每次子智能体执行限制为 40 次。一次响应不论其工具调用多少都计为一步。工作流容量、恢复委托、并发和时间限制由配置固定。主智能体与全部子智能体共享 5,000,000 token 的紧急截止；常规调用不预留 token 配额。我们记录主智能体、子智能体和总用量；相等的上限不必产生相等的成本。

主智能体的第一次 finish 调用终止运行。尚未呈现的结果、仍开着的响应窗口、缺失的提交和过时的验证会被记录，但不阻止终止。不带工具调用的响应被标为不完整的主智能体停止或子智能体未提交。终止原因与分数是分开的；未评分的运行仍可供复核。

DRS 由第 3.2 节定义的适用 ERC 要求计算。因主智能体提前终止而未被呈现的规定事件，按该规则记零，并且不从分母中移除。评分器导入和补丁应用缺陷被分开检查，而不直接归因于模型。重跑替换已有位置，而不增加分母；未经复核的记录不是零分。

任务成功由任务级接纳标准决定。若任务级标准仍然满足，违反 ERC 特有的过程要求可以降低 DRS 而不改变任务成功。失败运行的 token 用量予以保留，不完整用量按下界报告。补充运行（Frozen、Oracle、Full-rebuild）分开报告，从不替换主实验分数。

C.3 DRS 演算示例

我们给 GPT-5.6 Terra 的一次运行（重复 1）评分，案例是改编自 MultiAgentBench 的范围与依赖。任务要求团队撰写一份五问研究计划，主题是开放的、免查找的视觉词元化与自回归图像生成。该案例的释放条件把目标结果放在另外三个子智能体结果和一份临时计划之后；在这次运行中，控制器的最长持有回退在其中至少一个结果交付之前就释放了它。目标结果把码本效率、吞吐量和峰值内存要求加入计划的范围。ERC 要求主智能体整合新范围，同时保留原来的研究前提和质量目标。它没有声明被禁止的改动，因此 F 是不适用，而不是记为零。表 6 列出六个评分点。

表 6：演算示例的评分点。分量分数是其评分点的加权平均；F 不适用。

最终计划保留重建与生成指标，并加入吞吐量与峰值内存评估，因此 \(\sigma(C)=\sigma(R)=1\)，\(Q=1\)。因为任务要求的是一份书面计划，描述未来实验是所要求产物的一部分，运行这些实验并非必需；V 关乎检查修订后的计划，而没有记录到实质的事件后检查，因此 \(\sigma(V)=0\)。过程分 \(P=(1+1+0)/3=2/3\)，\(\mathrm{DRS}=100\cdot(2/3+1)/2\approx 83.3\)。C1 与 O1–O3 从不同角度考察相关内容：C1 问响应是否做出了所要求的改动，而 O1–O3 问最终产物是否满足该事件的要求，因此一次运行可以做出改动却仍未通过结果，或只通过事后修补才达到结果。V1 根据事件后轨迹判定，其中最终断言或状态旗标不算检查；轨迹中没有对修订后计划的实质复核。该示例说明为何过程与结果要分开评分：正确的最终产物并不能确立所要求的验证已经执行。

C.4 运行的纳入、排除与重跑

每个智能体在全部 200 个任务上、每种交付模式各评测三次，因而每个智能体每种模式有 600 次计划运行，每个场景 75 次。所有可以被有效评分的运行都纳入：任务失败、产生错误结果或耗尽预算都按正常规则评分，低分从不构成排除或重跑的理由。因有记录的基础设施故障而无法评分的尝试，以相同任务、模型、模式、重复序号和配置重跑。每个实验单元恰好贡献一个有效分数：重跑替换它们所重复的尝试，从不在多个有效尝试中选取最好的。分数先在每个任务内对重复取平均，再对任务等权平均。缺失分数从不被填成零，任何不完整的汇总都报告所纳入的任务数和运行数。批量运行与异步运行按任务和重复序号配对，成对分析只使用两种模式都有有效分数的对。

C.5 成本构成与响应质量

我们把主智能体与子智能体的消耗分开，并把每个系统在 Async 下的执行成本与其 DRS 比较。成本包括提供方报告的输入与输出 token，以及主智能体和全部子智能体上已完成的模型调用，并保留失败运行所报告的消耗。我们保留两种交付都有完整成本记录的成对重复，在每个案例内分别对两种模式的重复取平均，并对案例等权；DRS 取值来自表 3。主智能体份额是其平均 token 消耗除以平均总 token 消耗。图 12 中的经验累积分布使用同样的案例均值，中位数和第 90 百分位数也由此计算。缺失的成本记录不被填成零，未返回的用量也不作估计。

成本增加贯穿整个分布。九个智能体中的八个在异步交付下平均消耗更多 token；Gemini 3 Flash High 是例外，下降 2.3%。图 12 表明增加并不局限于少数昂贵案例。Terra 与 GLM5.3 Flash 的中位数分别从 0.17M 和 0.89M 升到 0.23M 和 1.29M token。Qwen3.5 27B 的中位数几乎不变，但其第 90 百分位数从 2.67M 升到 2.97M，因此其增加集中在昂贵案例。均值成本的变化因此可以反映分布上不同的变化。

图 12：批量与异步交付下的案例级 token 成本，为主智能体与全部子智能体之和。点标记中位数。

额外消耗大多发生在主智能体。图 5 显示九个智能体在异步交付下的主智能体平均 token 消耗都更高；主智能体占总消耗的份额在每个智能体上也增加。对 Terra，主智能体消耗增加 100.2%，子智能体消耗几乎不变；对 GLM5.3 Flash，主智能体消耗增加 68.6%，子智能体消耗只增加 0.7%。Gemini 的总消耗下降 2.3%，但其主智能体消耗仍增加 17.1%；减少来自子智能体消耗下降 16.8%。总费用的变化因此可能掩盖主智能体与子智能体消耗的不同变化，使主智能体成为进一步分析异步执行成本的重要焦点。

相近的执行成本对应不同的响应质量。图 13 显示 Sonnet 与 DeepSeek 平均消耗 1.67M 和 1.66M token，但 DRS 分别为 45.1 和 30.6。模型调用呈现类似形态：Sonnet、Qwen3.7 Plus 和 GLM5.3 Flash 平均 75.9–77.1 次调用，DRS 分别为 45.1、38.2 和 33.4。因此仅执行成本并不能解释智能体之间响应质量的差异。这些比较使用不同智能体的平均成本与分数；它们并不表明改变某个固定智能体的执行预算会如何影响其分数。

图 5 与图 13 共同促使人们做受控比较：固定模型与任务，改变主智能体的响应频率、上下文管理和修订策略，以检验能否在保持事件响应质量的同时降低其执行成本。

图 14：异步结果到达后的代表性问题。每个面板显示一次独立运行中的消息、动作和证据；事件编号给出顺序。面板中 “Main” 表示主智能体，“Subagent” 表示子智能体。验证示例显示的是代码风险，而不是失败分支的一次被观察到的执行。仅有时间顺序并不能表明中断造成了该错误。