评估任务解剖与真实轨迹

一条评估任务由哪四个部分组成？

• 参照: τ²-bench（Sierra 开源项目）telecom 领域的任务文件 data/tau2/domains/telecom/tasks_small.json;
• ticket: 提供给 Agent 的工单，含用户初始诉求与验收口径（如 “测速结果为 excellent 才算解决，不换套餐，必要时可充值 2.0 GB”）;
• user_scenario: 提供给用户模拟器的行为规范，分 known_info（已知信息）、unknown_info（未知信息）、task_instructions（行为指令）三栏;
• initial_state: 运行前把两侧状态重置到同一起点的初始化动作，以 env_type 区分 user 侧与 assistant 侧;
• evaluation_criteria: 评分标准，含 actions、env_assertions、communicate_info、nl_assertions 四项检查与 reward_basis 聚合规则;

为什么要把用户的认知边界显式建模？

• 做法: known_info 只放用户真正知悉的信息（姓名、号码、所在国家），真正的故障原因（飞行模式开启、数据漫游关闭）留在未知侧;
• 效果: Agent 无法靠常识推测故障，只能通过提问和引导用户查询来获取;
• 名称: 渐进式信息透露（Progressive Information Disclosure）;
• 关键点: 靠把用户知识范围建模为独立字段来实现，而不是靠 “不要一次说完” 一句提示词约束模拟器;
• 对照: 多数基准在任务开始时即给出完整需求，而真实用户的初始表述往往只是 “我上不了网”;
• 结论: 把需求澄清到可执行的程度，本身就是 Agent 必须具备的能力;
• 反例: τ-bench 初版任务指令过于笼统，模型无需真正澄清需求，凭常识推测一套流程也能通过;

用户模拟器为什么需要事实锚定？

• 三类约束: 情绪设定（首次修复失败后表现出轻度不满）、验收口径（仅当测速 excellent 才算解决）、事实锚定（Grounding）;
• 事实锚定: 关于设备状态的任何回答都必须以工具返回结果为依据，不得编造工具调用结果;
• 缺失后果: 模拟用户会顺应 Agent 的引导确认问题已解决，评估退化为两个模型之间的相互确认;
• 可复现性: 情绪、耐心上限与事实锚定共同作用，使模拟器在接近真实用户的同时仍保持可复现;

双控（Dual-Control）环境解决了什么问题？

• 定义: 模拟用户拥有一套独立工具集，如 check_status_bar、toggle_airplane_mode、reseat_sim_card、run_speed_test;
• 信息划分: 飞行模式与漫游开关属于用户侧，运营商侧的 enable_roaming 属于 Agent 侧;
• 故障形态: 运营商侧漫游已开通、用户设备侧却处于关闭状态，Agent 查询数据库只能得到 “配置正常”;
• 新增验证维度: 用户改变状态后 Agent 必须重新调用工具才能获知结果，验证因此覆盖 “Agent 是否真的读到了用户侧的操作结果”;
• 演进来源: 此前评估中只有 Agent 能改变环境，而技术支持场景中相当一部分动作本应由用户在自有设备上完成;

评分标准覆盖哪四个维度？

检查项	检验对象	示例
env_assertions	终态	移动数据可用、测速 ≥200 Mbps 且评级 excellent
actions	关键动作是否发生	toggle_airplane_mode、toggle_roaming
communicate_info	必要信息是否已告知用户	必须主动说明的内容清单
nl_assertions	自然语言断言	答复内容层面的约束

• 聚合: reward_basis 决定最终奖励由哪些维度构成，本例只取 ENV_ASSERTION;
• 粒度: 每个任务可以只检查其中一个或多个维度的结果;

二元奖励的固有代价是什么？

• 现象: 满分轨迹中 Agent 违反了政策 “You should only make one tool call at a time”——第 4 条消息同时发出 get_customer_by_phone 与 get_customer_by_name 两个调用;
• 原因: 本题 reward_basis 只考虑最终状态，验证器未因此判错;
• 代价: 以过程颗粒度换取跨模型可比的单一数字;
• 生产需求: 不仅判定对错，还要指出问题出在哪里，需要 失败归因;

真实轨迹暴露了哪两类典型失败？

• 成功轨迹: 前十余轮账户识别（曾仅凭 L1001 一条线路的结果断言号码不存在）→ 用户侧查状态栏 → 关闭飞行模式并开启漫游 → 测速 275 Mbps、评级 Excellent → 两条 env_assertions 通过，reward = 1.0;
• 关键转折: 发出状态工具调用的是用户而非 Agent，Agent 必须读到用户侧结果才能推进;
• 失败轨迹一 判断未修正: 用户号码为 555-123-2002，Agent 却选定 L1001 线路并以其 3.2/5 GB 用量为依据推进；get_details_by_id(L1001) 明确返回该线路号码为 555-123-2001，Agent 读取后未修正判断，此后在无关排查上消耗数十条消息，最终转接人工;
• 失败轨迹二 部分完成: 引导用户关闭了省流模式且被环境验证，但线路选择错误使所需的 2 GB 充值未执行，三条终态断言全部失败;
• 共性根因: 修正判断所需的证据已进入上下文，Agent 未据此回溯，与 AndroidWorld 静默失败形态一致，见 失败归因;
• 结构含义: 这条任务已经把一个评估集必须回答的问题摆全——什么算成功、任务从何而来、由谁验证、分数如何转化为决策;