ARE-scaling up agent environments and evaluations
ARE：一个用于可扩展地创建环境、集成合成或真实应用程序以及执行代理编排的研究平台。
提供简单的abstractions来构建复杂多样的环境，每个环境有自己的规则、工具、内容和验证器，弥合模型开发和现实世界部署之间的差距。
实现方式：
提出用于模拟和验证的abstractions，以促进创建多样化的环境和任务，以及集成现有环境和任务支持agent和其环境从同步转变为异步，从而解锁新的任务和能力，例如处理时间。ARE支持真实应用程序的连接，例如，通过模型上下文协议（MCP）集成，从而使模型开发、评估和生产部署保持一致。除了RL之外，ARE还能够生成高质量的SFT轨迹。
Giaa2：用于评估agent的新方法
由1120个可验证、带注释的场景组成，这些场景发生在模拟智能手机的移动环境中，其中包含电子邮件、消息、日历等应用程序及其相关内容，类似于AppWorld 或ToolSandbox；
能力：搜索、执行、代理处理歧义和噪声、适应动态环境、与其他代理协作以及在时间约束下运行
特点：异步运行
Giaa2 不同于大多数Agent Benchmark地方：
因为agent和environment异步运行，所以两者之间有更深入、真实的交互；环境时间流逝独立于agent是否执行任务，环境状态会不断更新随机或计划事件，例如吸纳用户或者agent消息的回复。验证系统：适用于强化学习，agent的写入操作 VS 带注释的oracle写入操作，并且对每个write aciton，通过软性（LLM评判）或硬性（完全匹配）比较（取决于参数类型）来评估参数，这些参数可以被视为评分标准。
1 ARE
1.1 ARE Foundations
五个核心概念协同工作：
Apps
与数据源交互的带状态的API接口；
与数据源交互的工具集合：
Environments
包括Apps及其数据、定义系统行为的管理规则；
工具集合：数据源交互的。例如，电子邮件应用程序包含诸如 send_email 和 delete_email 等工具扩展
Events
在Environment中发生的任何事情；
Notifications
来自环境的消息，用于通知Agent关于事件的信息
Scenarios
在环境中发生的一组初始状态和计划事件、验证机制
2.1 Mobile
它是一个 Gaia2 Benchmark的运行载体，本质是 “模拟智能手机的完整虚拟场景”，包含 12 类常用 App（如消息、邮件、日历、购物等）和 101 个工具
环境规则：明确 “怎么交互、怎么结束”
交互模式：采用 “回合制”，一个回合从智能体收到用户指令 / 环境事件开始，到智能体向用户反馈（完成任务或请求进一步输入）结束。异步运行：回合内环境时间会持续流逝，智能体思考、操作的时间会直接消耗模拟时间（比如智能体反应太慢，会错过日程）。终止条件：三种情况会结束场景
成功完成：智能体反馈任务完成，且无后续用户指令。约束失败：超出模拟时间、操作步数或回合数限制。验证失败：每回合结束后，智能体的操作未通过验证（比如没按要求发邮件）。
环境填充：给Mobile“装真实数据”
数据生成：用 Llama 3.3 70B Instruct 生成合成数据，确保所有 App 的数据连贯（比如联系人的邮箱能直接用于发邮件，日历事件和用户描述一致）。生成逻辑：按 “应用依赖图” 生成，以 “用户人设”（比如 “退休法国物理教授”“中国职业运动员”）为核心，衍生出联系人、邮件、日程等数据。数据规模：每个 “虚拟用户宇宙”（不同人设对应的手机数据）约有 800K tokens 的结构化数据，保证场景的丰富性和真实性。
场景创建：怎么设计评估任务
创建方式：通过 ARE 的标注界面，以 “写操作事件图” 为核心标注场景（比如 “给 A 发邮件→在日历加会议” 的步骤）。验证逻辑：场景的正确解是 “唯一的写操作序列”（比如必须发某封邮件、改某个联系人信息），读操作（比如查邮箱、看日历）不强制验证（只要最终写操作正确即可）。
Mobile 只是示例，ARE 的抽象设计能轻松复现其他现有基准，比如：
把 τ-bench（工具交互基准）、BFCLv3（函数调用基准）直接迁移到 ARE 中，无需大幅修改。支持通过 MCP 协议集成外部基准，保证评估的可重复性。
3.1 ARE 验证
专门判断智能体的操作是否真的完成了任务，解决传统验证方式 “判断模糊、易被钻空子、不支持复杂场景” 的问题，同时适配强化学习训练需求，确保评估结果精准可靠。
验证器的核心就是：通过比对Agent的操作和 “标准答案（oracle 动作）”，给出 “通过 / 失败” 的结论，而且能支持复杂的多轮、异步场景，还能避免智能体 “耍小聪明” 钻规则漏洞。
核心验证机制（2.3.1）：怎么判断 “做对了”
验证器只关注智能体的 “写操作”（比如发邮件、改日程、删联系人），不纠结 “读操作”（比如查邮箱、看日历）—— 因为读操作可以有多种方式，但最终要落地到准确的写操作才叫完成任务。
工具名匹配（入门检查）：先确认智能体用的工具和标准答案一致。比如标准答案是用 “邮件 App 发消息”，智能体用了 “购物 App 发消息”，直接判失败。一致性：
硬检查（精确匹配）：对需要 “丝毫不差” 的参数做严格比对。比如标准答案是 “回复邮件 ID=123 的邮件”，智能体回复了 ID=456 的，硬检查就过不了。软检查（语义匹配）：对不需要逐字一致的内容做灵活判断。比如标准答案是 “提醒明天 10 点开会”，智能体说 “明天上午 10 点记得参会”，通过 LLM（大模型裁判）判断语义等效，就视为通过。
因果 + 时间检查（逻辑匹配）：确保智能体的操作符合 “先后顺序” 和 “时间要求”。比如标准答案是 “先订车，再发邮件通知”，智能体先发邮件再订车，因果检查失败；又比如要求 “订车后 5 分钟发通知”，智能体隔了 1 小时才发，时间检查不通过。多轮场景（比如 “先问朋友时间，再改日程”）会在每轮结束后都验证，避免智能体 “跑偏了还继续做”，确保每一步都符合要求。
验证验证器：这个 “裁判” 靠谱吗？（2.3.2）
为了避免 “裁判自己出错”，研究者专门测试了验证器的准确性：
单元测试：故意修改标准答案（比如改参数、换顺序），看验证器能不能识别出 “错误”，确保它能应对预期内的情况。
真实轨迹测试
：用 450 条人工标注了 “成功 / 失败” 的智能体操作轨迹，对比ARE Verifier和 “纯 LLM 裁判”In-context Verifier（直接让大模型看操作判结果）的表现：
ARE 验证器：一致性 98%、精确率 99%、召回率 95%（几乎不会误判、漏判）；纯 LLM 裁判：一致性 72%、精确率 53%（容易把错的判对）。
跨模型测试：用 Llama 3.3、Gemini 2.5 Pro、Claude Sonnet 3.7 分别当 “LLM 裁判”，发现都能达到满意的精确率，说明验证器的设计不依赖特定模型，通用性强。
2 Gaia2
Description and Setup
Gaia2是依托 ARE 平台和 Mobile 环境构建的通用智能体评估基准，核心目标是突破传统基准 “仅侧重搜索 / 执行” 的局限，全面衡量智能体在真实世界中所需的综合能力（如适应变化、时间管理、协作等），让评估更贴近实际部署场景。
构成：
场景规模：共 1120 个可验证场景，拆分三类 ——800 个核心场景（覆盖 7 类能力）、160 个精简版（Gaia2-mini，用于快速低成本评估）、320 个增强场景（基于 mini 扩展，提升评估维度）。运行载体：所有场景都在 2.2 部分介绍的 “Mobile 环境” 中运行，依托 12 类手机 App 和 101 个工具，模拟真实智能手机使用场景。组织方式：场景按 “能力维度” 分成不同 “split”（即评估模块），每个 split 聚焦一种核心能力（如搜索、时间管理、协作等），方便针对性测试。
独特性：
动态环境事件：场景执行中会异步触发环境变化（如好友突然回复消息、系统推送通知），测试智能体 “适应突发情况” 的能力 —— 这是传统静态基准（环境暂停等待智能体操作）没有的。持续时间维度：环境中时间会持续流逝，很多场景明确要求 “在规定时间内完成”，而传统基准大多忽略时间约束。智能体协作支持：部分场景将手机 App 替换为 “自主子智能体”（如购物 App 变成能沟通的 “导购智能体”），测试主智能体的 “任务分解、状态共享、协作沟通” 能力 —— 传统基准多是单智能体独立完成任务。
Agent能力评估
1. 搜索能力（Search）：多源找信息，整合出答案
测试目标：考察智能体从多个 App 中收集、整合信息的能力（只需要最终给出正确答案，中间查信息的方式不限制）。通俗说明：就像 “多本字典查答案”，需要跨 App 找数据、做简单计算或判断，最后把结果告诉用户。具体例子：“我把有过 1 对 1 聊天的联系人算作朋友，多数朋友住哪个城市？若有平局，按字母顺序选第一个。”（需要跨 “联系人 App” 和 “聊天 App” 统计数据，还要处理平局情况）。
2. 执行能力（Execution）：多步做操作，按序完成
测试目标：考察智能体执行多个 “写操作” 的能力，操作可能需要按特定顺序进行，有时需要先查信息再动手。通俗说明：类似 “按步骤办事”，重点是 “做对操作、做好顺序”，比如批量修改数据、完成一系列提交动作。具体例子：“把所有 24 岁及以下的联系人年龄加 1 岁”（需要先读联系人年龄→筛选符合条件的人→逐个修改，是 “读 + 多次写” 的组合）。
3. 适应能力（Adaptability）：应对突发变化，调整计划
测试目标：考察智能体在任务执行中，应对环境变化（如他人回复、操作结果变更）并调整策略的能力。通俗说明：就像 “计划赶不上变化”，比如发了邮件后收到对方的新要求，需要修改之前的安排。具体例子：“帮我和朋友 Kaida 约看房源，若她回复建议其他房源或时间，就按她的要求重新安排”（需要先发起邀约→监控朋友回复→根据新信息调整计划）。
4. 时间管理能力（Time）：把握时间窗口，按时行动
测试目标：考察智能体的时间敏感度，能否在规定时间内行动、监控时间相关事件（如超时触发操作）。通俗说明：类似 “赶截止日期”，任务有明确的时间约束，不能拖延，还要主动监控时间变化。具体例子：“给今天要见面的同事发消息，问谁来订车；3 分钟没回复，就按默认地址订车”（需要计时→监控消息回复→超时触发订车操作）。
5. 模糊性处理能力（Ambiguity）：识别矛盾 / 歧义，主动澄清
测试目标：考察智能体能否发现任务中的矛盾、歧义或缺失信息，不盲目执行，而是主动向用户确认。通俗说明：就像 “遇到模糊指令不瞎做”，比如任务要求冲突、信息不全时，要及时问清楚，而不是硬着头皮做。具体例子：“10 月 16 日到 21 日，每天下午 6 点安排 1 小时瑜伽课，有冲突请告诉我”（若已有日程冲突，智能体需要识别矛盾并提醒用户，而不是直接覆盖或忽略）。
6. Agent2Agent能力：与其他智能体沟通，共同完成任务
测试目标：考察智能体与 “子智能体”（原本的 App 被替换成自主智能体）协作的能力，包括分工、沟通、共享状态。通俗说明：类似 “和同事配合做事”，不能直接用工具，要通过自然语言和其他智能体沟通，让对方帮忙完成子任务。具体例子：之前的 “查朋友住的城市” 任务，但 “联系人 App” 和 “聊天 App” 被替换成子智能体，主智能体需要发消息问子智能体 “有哪些 1 对 1 聊天的联系人”“这些人的城市是什么”，再整合答案。
7. 抗干扰能力：应对环境干扰，专注完成任务
测试目标：考察智能体在环境有噪音（如工具报错、无关事件）时的稳定性，能否不受干扰、坚持完成核心任务。通俗说明：就像 “在嘈杂环境中干活”，比如工具突然报错、收到无关消息，智能体需要忽略干扰或处理异常，不半途而废。具体例子：之前的 “适应能力” 任务，但过程中会随机出现工具执行失败、收到无关消息（如广告、他人闲聊），智能体需要排除干扰，继续完成订房源的核心任务。
图 9 在 Agent2Agent 场景中，Gaia2 场景中比例为“r”的应用程序被具有访问相应 API 和/或工具权限的自主代理所取代。主代理（由用户实例化）可以通过通道与应用程序Agent通信，但不能直接使用它们的工具或查看它们的工具调用输出。现在，代理必须发送消息才能协调行动、共享状态、设置子目标并协作解决用户任务。默认情况下，Gaia2 在完整的 Agent2Agent（“r = 1”）设置下评估 LLM。
Data Collection
一、场景创建的核心原则
人工创建场景时，必须遵循 4 个关键原则，避免场景无效或评估模糊：
单能力聚焦：每个场景只针对一种核心能力（比如只测 “适应能力”，不额外掺杂 “抗干扰”），这样开发者能精准知道模型的强弱项，不会出现 “多个能力混在一起，不知道哪里错了” 的情况。难度校准：场景难度要 “对模型有挑战，但人类能轻松完成”—— 因为人类觉得难的任务，模型未必难，反之亦然，所以要通过内部模型测试调整难度，避免太简单（模型全过）或太离谱（模型全挂）。易验证、无歧义：智能体的回复（给用户 / 联系人的消息）要简短、中性、容易解析，方便 LLM 裁判判断对错；同时要避开敏感话题和个人隐私信息，避免合规问题。贴合真实使用：场景逻辑要符合手机日常操作习惯（比如发邮件前要先查联系人邮箱），不能设计脱离实际的 “奇葩任务”（比如让日历 App 发购物链接）。
二、质量保证（QA）流程：避免标注错误
创建场景是复杂活，容易出现逻辑漏洞（比如任务矛盾）或标注失误，所以要通过 “人工协作 + 自动化检查” 双重把关：
人工 QA：多人交叉验证（4 步流程）
步骤 1：标注者 A 创建场景（包括用户指令、标准答案的操作步骤图）；步骤 2：标注者 B 看不到 A 的答案，只看用户指令，独立做出自己的标准答案，若觉得指令模糊，可修改指令；步骤 3：标注者 C 和 B 一样，独立做标准答案（看不到 A、B 的结果）；步骤 4：标注者 D 对比 A、B、C 的 3 个答案，确认是否一致 —— 一致就通过，不一致就修改指令（让任务更明确）或直接废弃场景。
自动化检查：减少人为疏忽
预 QA（标注时实时检查）：用 ARE 的图形编辑器，强制场景符合 Mobile 环境的规则（比如每个回合必须以 “给用户发消息” 结束），不符合就不让保存，从源头避免低级错误；后 QA（标注后测试）：用模型跑场景，看成功率 ——100% 成功率说明场景太简单，0% 成功率说明场景设计有问题（比如任务不可能完成），都会被重新调整或删除。
三、核心目标
这部分所有工作的最终目的，是产出 “高质量、可信赖、能精准评估能力” 的场景：
避免 “差场景” 影响评估结果（比如场景逻辑矛盾，模型再强也做不对，导致误判）；保证场景的一致性（不同标注者创建的同类型场景，难度和逻辑相近）；降低标注成本（通过流程和工具，减少重复返工）。
暂无评论内容