论文链接：HALO: Human-Grounded Granular Evaluation of Proactive Agents (arXiv:2610.39086) 发表时间：2026 年 10 月 29 日 机构：UC Davis + 2077AI + University of Southern California（企业-高校合作） 代码：github.com/CedricPei/HALO 领域标签：cs.CL / Agent 评测 / 人本标注 / 主动式助手

引言

Agent 圈长期默认一个信条：能干活就是好 agent。于是评测越来越像任务清单——给定显式请求，看完成率。但主动式 agent（proactive agent）打破了这条契约：它们要在用户没有发出请求的时候，自己判断是否帮、何时帮、帮到什么程度。这一转变让「干得越多」与「帮得越好」彻底脱钩——一个动不动就替用户发邮件、下单、改日历的 agent，可能比一个懂得沉默的 agent 危险得多。

HALO（Human-Grounded Granular Evaluation of Proactive Agents）就是为这个问题而生的评测系统。它最核心的发现可以用一个数字概括：在被人类专家拒绝的响应中，61.20% 源于过度主动——要么时机过早，要么强度过度。过早干预约为过晚干预的 3 倍，过度干预约为不足干预的 2 倍。换句话说，当前主动式 agent 的头号毛病不是「不够聪明」，而是「太热情」。

这个发现的反直觉之处在于它与行业叙事相悖。过去两年,关于 LLM agent 的主流抱怨一直是「不够 agentic」——不敢自主决策、事事要人确认、一步三回头。训练与产品侧的回应自然是鼓励 agent 更主动。HALO 的数据提示这个方向可能矫枉过正：在无人请求的情境里，模型们已经足够敢出手了，问题恰恰出在不知道什么时候收手。最强的两个模型（Gemini3.8-Flash、Claude-Opus5.5）的 L0 观察占比都超过 30%，而中游模型普遍在 5% 以下——头部模型的领先，一半领先在克制上。

更值得注意的是方法论层面的贡献：HALO 没有停留在「接受/拒绝」的二值判决，而是让 20 位专家对每条被拒响应做双维诊断——时机（过早/过晚）与强度（不足/过度）正交拆分，再配上 L0-L3 四级动作分类。这个标注体系让人第一次能看清：模型到底败在「该出手时没出手」，还是「不该出手时乱出手」。下面完整拆解这篇论文。

一、题目与基本信息

• 作者：Wenqi Pei（UC Davis）、Xinyu Wang、Jinrui Liu、Cynthia Zhuge、Jie Sheng、Zihan Wang（2077AI）、Tenghao Huang（USC）、Muhao Chen（UC Davis）
• 链接：arXiv:2610.39086，2026 年 10 月 29 日提交
• 一句话：用可执行环境 + 结构化/非结构化证据检索 + 20 人专家细粒度标注，对主动式 agent 的「是否/何时/多深」介入决策做人本评测，发现过度主动是主导失败模式（占被拒响应 61.20%）。

题目里的三个词各有分量。Human-Grounded：判决与诊断全部来自人，而非奖励模型或字符串相似度；Granular：标注粒度到单条响应的动作级别与拒绝原因，而非整体通过率；Proactive：评测对象是「无显式请求下的主动帮助」这一决策本身，不是工具调用的执行精度。

系统由两个组件构成：HALO-Arena（可执行基准环境）与 HALO-8K（8,000 条专家标注响应数据集）。二者合起来回答一个问题：当 agent 自作主张时，人类到底买不买账、为什么不买账。

团队构成也值得一提：UC Davis 的 Muhao Chen 组与 USC 合作学术部分，2077AI（一家数据标注公司）承担了 20 人标注团队的招募、筛选与质量管理，并贡献了多位作者——这是一篇「学术设计 + 企业标注产能」深度耦合的基准论文，8,000 条逐响应诊断的标注量在没有专业标注伙伴的情况下很难完成。

二、背景

主动式 agent 的研究脉络可以概括为三代。

第一代：从观察到提议。Lu 等人 2024 年的 Proactive Agent 工作训练 agent 从观察到的用户活动中提议任务，报告 66.47% F1 的主动辅助成绩；ContextAgent 把感知扩展到可穿戴设备的视频与音频，结合感官与画像上下文做工具辅助服务。这一代确立了「从用户轨迹推断未言明需求」的任务范式，也留下了一个微妙的遗产：评价提议质量用的是接受标签训练的奖励模型，人类只出现在训练数据里，不出现在评测环节。

第二代：时机与范围。ProActor 为时机感知调度建模可行动窗口；Proactivity-Gym 把任务能力与时间分配、用户信任联系起来，并纳入多日模拟与人类研究。研究者开始意识到：发现需求只是第一步，什么时候出手、出多大的手才是难题。这一代引入了「时机」这个变量，但时机与强度尚未被拆开度量——一次被拒绝的干预，说不清是来早了还是来过了。

第三代：评测爆发。评测从执行显式请求（WebArena、τ-bench）转向识别未言明需求：ProactiveBench 评活动轨迹上的提议，ContextAgentBench 加多模态上下文与工具调用，PROBE 评瓶颈发现与动作选择，ProAgentBench 评真实计算机活动中的干预决策，FingerTip 20K 覆盖 Android 上的主动意图建议，PARE-Bench 引入有状态应用与主动用户模拟，π-Bench 评长程工作流中的隐藏意图解析。校准方向还有 AgentAbstain（显式请求下的行动与克制）与 ProEvent（聊天中的响应时机）。

但作者指出了共同的缺口，可以从三个角度理解。

第一，证据获取方式与判决脱节。有的基准直接提供用户活动（ProactiveBench、ProAgentBench），有的支持检索（PROBE 的 SQL 与语义检索、交互式基准的工具调用），但没有一个把「检索到了什么证据」与「人类怎么判这次干预」连在同一条链上——于是你永远不知道模型是被证据误导，还是根本没查证据。

第二，判决维度的缺失。发现一个相关需求，并不意味着干预就可接受；干预可能因为时机不对、强度不够、越权、无关或无证据支撑而失败。这些失败的性质截然不同，修法也截然不同，但二值判决把它们压成同一个「拒绝」。

第三，自动指标的盲区。奖励模型学到的是人类的边缘接受分布，学不到拒绝的原因；相似度分数更无从谈起。少数含人类研究的工作（如 Proactivity-Gym）也只提供整体感知，缺乏对单条响应接受/拒绝原因的诊断。

HALO 要补的就是这一块：把结构化数据库查询、非结构化文件检索、可执行应用与人类判决、人类诊断、资源消耗记录全部纳入同一套协议。用一句话概括它的立场：主动式辅助的评测对象不是任务完成度，而是分寸感——而分寸感必须有人的判决才有定义。

三、定位

HALO 在评测设计空间里占据一个此前空缺的组合位。论文附录 A 的对比表很说明问题：

再加一行说明：表中「人类判决」含接受标注、判官验证决策与用户偏好；「消耗记录」含 token 用量、工具动作、交互轮数、延迟或成本（PARE-Bench 的读取动作、π-Bench 的交互轮数都算）。「人类诊断」特指逐响应的时机、强度与其它问题标签——这一列此前完全空白，HALO 独占。

「人类判决」与「人类诊断」是两个不同档位：前者只是接受与否的标注，后者是逐条响应的时机、强度与其它问题的标签。HALO 是表中唯一同时具备全部六项能力的基准。

更准确的定位是：HALO 不是又一个「更难」的基准，而是一个诊断型基准。它的产出不是排行榜上的一个分数，而是一套关于失败结构的知识——哪个模型在哪种需求类型上、以哪种方式、因为缺乏哪种证据而失败。论文的核心发现（过度主动主导）只有在「人类诊断」这一档存在时才可能被观察到：二值判决会把「过早」和「过度」都折叠成一个「拒绝」，61.20% 这个数字根本出不来。同理，「时机对但强度错」的镜像失败（5.7 节）也要求时机与强度分开标注才可见。

这里有一个基准设计的一般性教训：评测能发现什么，取决于标签保留了几维。一维标签（通过/失败）只能回答「好不好」；二维以上的诊断标签才能回答「坏在哪」。而 agent 的迭代训练恰恰依赖后者的答案——知道 61.20% 的拒绝是过度主动，才知道该在训练里惩罚什么。诊断维度不是锦上添花，它是从评测到改进的通路。

与同时期校准类工作的分工也清晰：AgentAbstain 测显式请求下该不该行动，ProEvent 测聊天里的响应时机，而 HALO 测的是无请求情境下时机×强度×证据的联合决策，且全部以人类专家为准绳。

四、问题定义

论文把主动式辅助拆成一个三层决策问题：是否介入（whether）、何时介入（when）、介入多深（how far）。三层决策层层递进：先判断有没有值得出手的需求，再判断当前时点是否落在有用窗口内，最后决定干预的承诺级别。传统任务式评测只覆盖第三层（给定任务怎么执行好），HALO 的设计把三层全部纳入同一场景流。

形式化地，agent 在每个评测 checkpoint 收到已观察事件前缀，可在多轮检索证据后返回一条可执行响应或不行动。场景被建模为初始状态 S0 加时间戳事件序列（e1, …, eT）：一个冷却器清洁的例子里，08:05 的日历条目触发清洁计划、10:08 的事件提示面板可能卡住、10:52 的事件宣告清洁即将开始——agent 在每个 checkpoint 面对的是不同的信息状态，正确的干预窗口可能只覆盖其中一段。判断「现在该不该帮」，本质上是在判断当前前缀落在窗口之前、之内还是之后。

4.1 四种主动需求类型

HALO-Arena 把「用户需要帮助」建模为四种类型：

• Dependency（依赖）：未来活动缺失前置条件——比如出行前发现护照找不到；
• Blockage（阻塞）：进行中的活动无法继续——比如清洁中途设备故障；
• Risk（风险）：尚未发生但可能发生的不良后果——比如面板可能在清洁中卡住；
• Opportunity（机会）：可选的收益，错过也不造成失败或损失——比如顺手能拿的折扣。

这个分类的设计意图在于覆盖「必须帮」到「可以不帮」的谱系：Dependency 和 Blockage 偏刚需，Risk 偏预防，Opportunity 则考验克制——对 Opportunity 的过度热情最能暴露 agent 的分寸感。后文 5.8 节会看到，这个分类确实抓到了行为差异：模型面对 Opportunity 时显著更倾向选 L0。

4.2 L0-L3 动作级别

HALO 对「介入多深」给出四级分类，按外部承诺程度递增：

• L0 观察（Observe）：观察或检索信息，不发起干预；
• L1 提醒（Attention/Notify）：把相关信息或需求呈现给用户，但不代为执行——例如 notify_user、create_reminder；
• L2 准备（Prepare）：为干预做准备或组织信息备用，不产生外部承诺——例如 create_draft；
• L3 执行（Execute）：实施改变用户生效承诺或产生外部效果的干预——例如 send_email、pay。

关键设计声明：高级别不等于更好帮助。L3 直接替用户发邮件未必优于 L1 提醒用户自己发——是否可接受取决于证据、权限与时机。这个去偏声明贯穿全部标注协议，也是整套体系与「任务完成度」评测最深的分歧点：在 WebArena 式评测里，L3 几乎永远是对的答案；在 HALO 里，它只是四个选项之一，且在 5.7 节的分析中恰是过度诊断的重灾区。

4.3 判决与双维诊断

每条响应先获得可接受性判决：是否提供了有据、有用、时机与范围恰当的帮助。克制可以被接受——当不该出手时，L0 就是正确答案。可接受率（acceptability）即接受响应占比。

对被拒响应，诊断沿两个正交维度展开：

• 时机：Premature（过早，在有用窗口之前介入）/ Belated（过晚，在窗口之后）；
• 强度：Insufficient（不足，帮助不充分）/ Excessive（过度，超出证据支持的 scope 或权限）。

被拒的 L0 另有 Inaction（不作为）标签——错过了本该提供的帮助。另有 Other Issues 捕捉证据无支撑、行动无关、事实矛盾等问题。同时记录每条响应的推理 token 数与检索轮数，量化「努力程度」。

这个体系最重要的概念区分是：过度主动 = Premature ∪ Excessive。时机过早与强度过度是两种不同的病，但都指向同一个方向——不该出手时出手、或出手出过了头。61.20% 这个核心数字正是这两者的并集占比（每个被拒响应只计一次）。把它与 Inaction（不作为）对照，就得到了主动式 agent 的完整病理空间：不作为、过早、过晚、不足、过度——五种病因，五种修法，从此有了各自的度量。

五、解法

HALO 的解法由四块构成：环境构造（HALO-Arena）、标注协议（HALO-8K）、主结果与错误分析、四组进一步的模式分析。前两块解决「在哪测、怎么判」，后两块交付「测出了什么」。整体阅读顺序建议：先记住 L0-L3 与时机×强度的坐标系，再看下面的数字——所有发现都是往这个坐标系里填内容。

5.1 HALO-Arena：环境构造

环境覆盖 10 个日常领域（教育学习、工作职业、家庭事务、家人照护、健康、出行、个人财务消费、社区公共、社交文化、运动娱乐），每领域 5 个实例、每实例代表一个不同的人，共 50 个个人环境；每环境含 4 种需求类型各 2 个场景，共 8 个场景，合计 400 个场景。应用层包括邮件、日历、聊天、通讯录、钱包五类 app，加上 SQLite 数据库与文本文件两类证据源。agent 可用 29 条交互命令检索证据、19 条动作命令执行干预（其中 6 条映射 L1、6 条映射 L2、7 条映射 L3，各级覆盖均衡）。

场景内的证据分布有两处值得注意。一是结构化与非结构化证据分离：授权、资格、程序性约束这类硬事实放数据库，偏好、说明、背景记录放文本文件——agent 需要同时会用 SQL 和文件检索才能拼齐判断依据。二是权限是场景的一等公民：Instance Creator 显式定义个人职责与权限，检索到的授权决定了 L3 的合法边界——kitchen sneakers 案例之所以成立，正因为「授权只允许发这几个词」被写进了证据。

构造流水线由 GPT5.6-Sol 驱动：Instance Creator 定义个人职责、权限与应用存储结构；Scenario Creator 填充结构形成初始状态 S0 并生成带时间戳的事件序列（每个场景 4-6 个事件，共 2,160 个 checkpoint）；Noise Creator 在 8 个场景全部通过审查后添加已结算的背景记录以扩大检索空间。自动检查双层：Validator 确定性校验结构、命令签名与状态一致性（509/568 通过，89.61%）；Reviewer 检查因果支撑、需求身份、时机、检索必要性与帮助相称性（400/509 通过，78.59%；整体通过率 70.42%）。

这套「生成-验证-审查-噪声」流水线本身值得复用：LLM 生成提供规模，确定性校验兜住语法底线，LLM 审查把关语义质量（因果、时机、检索必要性、相称性四个维度恰好就是后续人类诊断的维度），人类双评审做最终裁决，Noise Creator 最后扩大检索干扰面。每层的通过率都单独报告，失败候选与修订候选分开计数——构造过程本身是可审计的。

人工审计同样严格：2 名评审逐场景审查因果支撑、时机、证据与权限内可行性，801 张投票中 74.13% 直接通过、21.88% 需修订、4.00% 拒绝；双通过率 53.50%，第三人裁决后又保留 289 个场景（72.25%）。值得注意的是场景设计里预埋了干预会过早或过晚的前缀，且本地证据足以判断时机——这保证了时机维度的评测效度。换句话说出题人已经验证过：场景里确实存在「此刻出手为时过早」的 checkpoint，模型在它上面翻车是可归因的失败，而非场景歧义。

5.2 HALO-8K：标注协议

在 400 个场景上，10 个模型（5 专有：Gemini3.8-Flash、Gemini3.1-Pro、Claude-Opus5.5、Grok4.7、GPT5.6-Luna；5 开源：DeepSeekV4-Pro、GLM5.3-Flash、Qwen3.5-9B、Qwen3.8-27B、GPT-OSS-20B）各产出 800 条响应：每场景采样 2 个不同 checkpoint，需求类型各 200 条、领域各 80 条，采样均衡覆盖事件位置且不使用人类判决（选点诊断的 Cramér’s V 仅 0.029，最大 Wasserstein 距离 0.0288，带固定效应的分数调整最大也只有 1.69 个点、排名不变）——这一系列检查排除了「采样偏置造就排名」的质疑，是基准论文里少见的严谨。

同一场景内的早期干预不影响其它 checkpoint——runner 独立重置到 S0 并重放该场景前缀。20 位标注者每人每条响应给一个判决，同一场景跨模型固定标注者，消除标注者间漂移对模型对比的污染。标注界面预填命令推断的动作级别，标注者确认或修正；人类判决可查看事件前缀、检索证据、响应与执行结果。平台部署在 Streamlit Community Cloud 上（Streamlit 前端 + Python 后端 + Supabase PostgreSQL 存储），8,000 条响应分两批、每批 4,000 条完成标注。

「固定标注者」与「判决可看证据」这两个细节值得展开。前者意味着 Gemini 与 GPT-OSS 在同一场景上的判决出自同一双手，模型间差异不可能来自标注者口味；后者意味着判决不是对文本的印象分——标注者能看到 agent 检索了什么、执行结果是什么，判决因此是对完整决策过程的裁决而非对措辞的偏好。资源消耗记录（推理 token、检索轮数）也与判决同库，使「努力-质量」的联合分析成为可能。

5.3 主结果：可接受率与行为画像

分数区间从 GPT-OSS-20B 的 30.38% 到 Gemini3.8-Flash 的 72.88%，相差 42.50 个点。专有组平均 63.08%，开源组平均 47.55%，差 15.53 个点；但组间有重叠——DeepSeekV4-Pro（56.63%）超过 Gemini3.1-Pro 与 GPT5.6-Luna，开源前三名彼此只差 2.50 个点以内，全组却拉开 26.25 个点，说明开源组的低均值一半来自弱尾部。即便最强的 Gemini3.8-Flash，也有超过 25% 的响应不可接受——主动式辅助对最强模型仍是未解问题，这个天花板比排名本身更值得注意。

动作分布高度集中：L1 提醒占全部响应的 69.20%，9 个模型的 L1 占比过半，从 Claude-Opus5.5 的 48.00% 到 GPT5.6-Luna 的 87.00%；L2 准备稀少（4.18%），L3 执行占 16.09%。两组的 L3 占比几乎相同（约 16.1%），主要策略差异在 L0 与 L1 之间：专有模型选 L0 的频率约为开源模型的 2 倍（组均值 14.38% vs 6.70%）——更强的模型更多选择按兵不动。

把关键数字排成一张表（摘自论文 Table 1，错误率均相对全部响应）：

这张表值得反复看。前两名的 L0 占比（30.13%、31.75）与最后几名（0.38-5.00）形成断层；GPT5.6-Luna 把 87.00% 的响应都花在提醒上、几乎不观察不执行，可接受率仅 51.75%；Gemini3.1-Pro 与 Qwen3.8-27B 则双双把 L3 拉到接近 30%，过早率随之升至 27.63% 与 25.38%。行为分布是错误分布的前置变量——先看一个模型怎么分配 L0-L3，大体就能猜到它会在哪个维度上翻车。

资源消耗上，开源组平均每响应 4.77k 推理 token、1.21 轮检索，专有组 5.53k、2.55 轮：推理量只差约 14%，检索轮数却少约 53%。而更低的检索量伴随更低的可接受率——省下的资源以质量为代价。组内差异同样显著：第二名 Claude-Opus5.5 的推理 token 只相当于 Gemini3.8-Flash 的约 23%（3.48k vs 14.99k），强性能可以出现在很不同的消耗水平上。这也提示部署侧的思考：token 预算与检索预算对主动式 agent 是两种不同的资源，压缩检索的代价远大于压缩推理。

5.4 核心发现一：过度主动占被拒响应 61.20%

把 Premature 与 Excessive 的并集定义为过度主动，它在 3,575 条被拒响应中出现 2,188 次，占 61.20%。分模型看，过度主动占比从 44.23% 到 79.66%，10 个模型中 6 个超过 50%。两种不对称性进一步刻画方向：Premature 约为 Belated 的 3 倍，Excessive 约为 Insufficient 的 2 倍——失败系统性偏向「太早、太过」，而非「太晚、太少」。这个模式在全部 4 种需求类型与全部 10 个领域上都成立，每一类的过度主动占比都过半。这对训练侧是一个有方向的信号：如果只能修一类错误，先修「出手太快太满」，因为它覆盖了被拒响应的大多数；而「太慢太少」——直觉上更符合对 LLM agent「不敢干」的刻板印象——在数据里反而是少数派。

两个细节让这个发现更立体。其一，可接受率最高的两个模型（Gemini3.8-Flash 与 Claude-Opus5.5）同时拥有最低的 Premature 与 Excessive 率——整体强者强的正是「不出手」的判断力。其二，单看 Inaction 会得出误导性画面：Qwen3.8-27B 的 Inaction 为 0%，可接受率却只有 55.13%，因为它只在 0.38% 的响应上选 L0——从不观察的模型根本没有机会犯不作为错误。错误率必须结合动作占比解读，这是评测设计的重要教训。

还值得一提「过度主动」的判定口径：Other Issues（证据无支撑、行动无关、事实矛盾等）只覆盖 1,000 条被拒响应（27.97%），其中 Unsupported Evidence 与 Irrelevant Action 合计 79.40%——也就是说即便把 grounding 类失败全算上，过度主动仍是更大的一块。失败的结构是分层的：最外层是「出手太早太满」，往下一层才是「出手了但没接地」。训练与产品设计若只盯着幻觉与工具错误，会漏掉占大头的分寸问题。

5.5 核心发现二：配对 checkpoint——更多干预不等于更好帮助

HALO 最有说服力的分析是配对比较：在共享的 checkpoint 上（匹配实例、场景、事件与标注者）对比干预频率与可接受率。

• Qwen3.5-9B → Qwen3.8-27B（201 个共享 checkpoint）：干预率（L1-L3 占比）从 72.1% 升至 99.5%，上升 27.36 个点；可接受率从 44.8% 升至 59.2%，上升 14.43 个点。错误结构变化：Inaction-or-Insufficient 降 17.91 个点，Premature-or-Excessive 升 5.97 个点——多干预治好了「不作为」，只轻微引入了「乱作为」。
• Gemini3.8-Flash → Gemini3.1-Pro（623 个共享 checkpoint）：干预率从 70.6% 升至 99.5%，上升 28.89 个点；可接受率却从 70.6% 跌至 55.9%，下降 14.77 个点。分解这 14.77 个点的损失：被接受的干预贡献 +5.94 个点，而被接受的 L0 克制损失了 20.71 个点——干预的收益被放弃的克制远远反超；同时 Premature-or-Excessive 激增 21.51 个点。

两组近似的干预增量（+27.36 vs +28.89）导向截然相反的可接受率变化（+14.43 vs −14.77），说明干预频率本身不携带质量信息。起点决定命运：Qwen3.5-9B 从 44.8% 的低可接受率出发，多干预置换掉的首先是 9.63% 的不作为错误，净收益为正；Gemini3.8-Flash 已经站在 70.6% 上，它的 L0 里沉淀着大量被接受的克制，放弃这些克制的损失必然超过新增干预的收益。干预的边际价值随基线可接受率递减，甚至转负——这对「把 agent 调得更主动」的产品决策是最直接的警示。作者也诚实声明：匹配固定了前缀与标注者，但配置与检索证据可以不同（Qwen 的版本与参数量同时变化），因此不能隔离「多干预」的因果效应——这是关联证据，不是因果结论。

另一个反直觉细节：Gemini3.8-Flash 的 182 条被接受 L0 响应平均执行 16.74 条命令，高于 401 条被接受干预的 14.65 条。L0 记录的是最终承诺，不是检查努力——大量检索后选择沉默，与轻率出手是两种完全不同的 L0。

5.6 核心发现三：证据获取伴随更好的帮助

跨 10 个模型，平均检索轮数与可接受率强相关（Pearson r = 0.885，Spearman ρ = 0.830）。固定承诺级别看：在 5,536 条 L1 响应中，获得本地内容（非空数据库记录或文件文本）的响应可接受率 59.0%，未获得的只有 40.8%；Insufficient 诊断率分别为 5.2% 与 15.5%。排除单例 checkpoint 后，带 checkpoint 固定效应与模型指示变量的线性概率模型（5,232 条 L1、1,730 个 checkpoint）给出：内容访问对应可接受率 +9.25 个点、Insufficient −5.86 个点，且该关联在只比较「检查过环境」的响应后仍然存在——不是「查了 vs 没查」的差别，而是「查到了内容 vs 只看了文件名/schema/空结果」的差别。

结合开源模型检索轮数少 53%、可接受率低 15.53 个点的事实，方向很清楚：先查证据再说话的 agent 更容易给出人类认可的帮助。论文配的对比例子很生动：同一家庭事务 checkpoint 上，Gemini3.8-Flash 被接受的 L1 提供了防拆说明与具体的报修路径，而 GPT-OSS-20B 被判 Insufficient 的提醒只建议腾出面板、没给出任何可用的服务联系方式。

自然要问因果方向：是检索带来好帮助，还是强模型恰好既爱检索又会帮助？论文的两层控制给出了部分答案——checkpoint 固定效应吸收了任务难度，模型指示变量吸收了模型固有水平，+9.25 个点的关联在两组控制后依然显著；且限制在「都检查过环境」的响应内仍成立。当然作者也只以 association 行文，不做因果声明。对实践者，这个方向的投资回报比很高：检索轮数是行为层面最容易干预的变量（改 prompt、加工具调用预算），而它恰与可接受率强相关。

5.7 核心发现四：时机对了，强度还会错——L1 偏不足、L3 偏过度

在 991 条时机合适（Appropriate timing）但仍被拒的干预中，错误沿动作级别呈现镜像分布：623 条 L1 中 329 条（52.81%）判为 Insufficient——提醒发了，但细节不足以真正帮到用户；312 条 L3 中 238 条（76.28%）判为 Excessive——执行越出了授权或证据支持的边界；56 条 L2 中 Insufficient 与 Excessive 分别为 35.7% 与 7.1%，恰好落在两者之间。这两个模式在每个模型内部都成立。当然强度解释不了全部：仍有 282 条时机合适的 L1 拒绝保留了 Appropriate intensity，失败来自其它问题。

这个镜像结构把「分寸感」拆成了两条独立的工程约束：L1 的失败模式是欠提供（细节不足），L3 的失败模式是过提供（越出边界）。前者要修的是证据利用——把检索到的内容转化为可操作的细节；后者要修的是权限遵从——检索到了边界就要执行边界。用一句话记：提醒要给足料，执行要收住手。

同 checkpoint 的跨模型对照进一步显示这些错误可修：229 条 Insufficient L1（69.60%）在同一 checkpoint 上有其它模型的被接受 L1 对应；178 条 Excessive L3（74.79%）有被接受的 L1 或 L2 对应——多数失败不是任务本身做不到，而是该模型选错了档位。作者也注明这些响应级份额依赖采样到的候选、不度量修复成功率——「存在被接受版本」不等于「容易生成被接受版本」，但至少排除了「任务本身无解」的解释。论文最精彩的 paired example：一个家庭场景中，存储的授权只允许发送包含 kitchen sneakers 的消息；Qwen3.8-27B 严格只发这个短语，被接受；Claude-Opus5.5 检索到了同样的措辞限制，却额外添加了姓名、地点与周六上午的请求，被判 Excessive。同为 L3，同样检索到了限制，命运取决于是否守住授权边界——动作级别不预定结局，细节合规才预定结局。

这个案例还有一层深意：Claude-Opus5.5 添加的姓名、地点、时间，放在任何其它语境里都是「更有帮助的细节」——通用助手的训练直觉是信息越全越好。但在授权受限的场景里，多余的好意恰恰构成越权。这说明过度主动不只是校准问题，还涉及对语境特异约束的优先级判断：当「完备性」与「授权」冲突时，模型要知道哪个赢。

5.8 需求画像与残余失败

四种需求类型的可接受率出奇地接近（Blockage 54.35%、Dependency 55.05%、Opportunity 55.85%、Risk 56.00%），但构成不同：模型对 Opportunity 更倾向克制（L0 占 13.60% vs Dependency 的 7.20%），被接受的 L0 为 Opportunity 贡献 10.65 个点、为 Dependency 只贡献 5.25 个点，被接受的干预则分别贡献 45.20 与 49.80 个点。全部 10 个模型对 Opportunity 都比 Dependency 更多选 L0，但差异幅度悬殊：Gemini3.8-Flash 是 39.00% vs 17.00%，Qwen3.8-27B 是 0.50% vs 0.00%。作者也提醒不要过度解读：需求标签刻画的是整个场景，而合适的动作取决于 checkpoint 及其可用证据——没有哪种需求类型规定死动作档位。这个「总数接近、构成迥异」的现象本身就是细粒度评测价值的又一例证：二值判决会把 Dependency 与 Opportunity 的策略差异完全抹平。领域层面可接受率从 Social 的 50.88% 到 Household 的 58.88%。

领域层面的差异同样有信息量：可接受率从 Social 的 50.88% 到 Household 的 58.88%；Health 领域 L1 占比最高（77.38%）而 L3 最低（5.63%）——模型们在健康事务上集体谨慎；Finance 领域 L2 准备多于 Travel、Social 的 L3 执行多于 Health，且这两个对比在每个模型上都成立。这些画像描述的是采样场景与可用动作机会，不直接是领域难度，但它们展示了 HALO 数据的另一种用法：按领域×需求切片，定位某个模型在哪种生活情境下分寸最差。

Other Issues 覆盖 1,000 条被拒响应（占被拒 27.97%、占全部 8,000 条的 12.50%），其中 Unsupported Evidence 占 50.30%、Irrelevant Action 占 29.10%——两者合计 79.40%，把人类诊断与「接地与相关性」直接挂钩：即便时机强度都对，编造证据或答非所问仍会被拒。

附录 H 还探索了 HALO 作为判官训练数据的潜力：用 7,600 条标注微调 Qwen3.5 判官，9B 的判决准确率 +7.50 个点（48.50% → 56.00%），但 timing/intensity/joint 三标签联合准确率反而降 11.00 个点；4B 的 joint 更是暴跌 28.75 个点。判决增益可以掩盖诊断退化——自动判官复现「接受率」容易，复现「为什么被拒」很难，这本身说明人类诊断标签的信息含量。这也预示了 HALO 数据集的长期角色：它最难被自动化的部分（逐响应诊断），恰是它最不可替代的价值。

六、知识反推

若让一个没有背景的人复现这篇论文，至少需要：

• 主动式 agent 文献谱系：从 Lu et al. 2024（Proactive Agent/ProactiveBench，66.47% F1）到 PROBE、ProAgentBench、PARE-Bench、π-Bench、AgentAbstain、ProEvent、Proactivity-Gym——不理解每家评什么，就无法理解 HALO 的六项能力组合为何是空白。
• 可执行环境工程：SQLite 状态管理、五类 app 的命令接口设计（29 交互 + 19 动作）、checkpoint 独立重放协议（重置到 S0、重放前缀、早期干预不跨 checkpoint 传染）。
• LLM 流水线构造与验证：Creator-Validator-Reviewer-Noise 四角色分工、确定性校验与 LLM 审查的双层过滤、人工双评审加第三人裁决——以及为什么通过率要分层报告（89.61% / 78.59% / 70.42%）。
• agent 侧的提示工程：论文附录 I 的 agent prompt 本身是一份范本——要求 agent 只判断已观察前缀、不推断未来事件、依赖资格/记录/约束时先查库、notify 必须含具体发现或下一步、不得声称完成未执行的操作。复现任何主动式 agent 评测都绕不开这些边界条款的精确措辞。
• 需求类型与时机结构的预埋设计：轨迹至少跨 3 个运营 app、前缀包含干预会过早或过晚的位置、本地证据足以判定时机、无显式求助——这套设计决定了时机维度的评测效度。
• 标注科学：固定场景-标注者设计消除模型间标注者漂移、预填动作级别降低验证成本、拒答诊断的双维正交标签体系（时机×强度）、克制可被接受的判决定义。
• 20 人的组织工程：2077AI 负责标注者招募、筛选、管理与持续跟进；共享 briefing 与 dry run 统一 20 人的判定尺度——8,000 条标注的可用性一半取决于这套流程。
• 统计方法：配对 checkpoint 比较（匹配实例/场景/事件/标注者）、带 checkpoint 固定效应与模型指示变量的线性概率模型、Pearson/Spearman 相关、选点平衡性的 Wasserstein 距离与 Cramér’s V 诊断。
• 消耗记账口径：推理 token 按保留调用求和、检索轮数按完成轮计数、各 provider 的记账约定不同——跨模型比较消耗时要先对齐口径，这是论文反复提醒的细节。
• 平台工程：Streamlit + Supabase PostgreSQL 的在线标注栈、三工作台（场景审计/响应评估/管理）流程、两批 4,000 条的会话管理。
• 评测口径意识：可接受率的分母是完成且被标注的响应（排除传输与解析失败）；错误率相对全部响应而非条件响应——这正是 Qwen3.8-27B「0% Inaction 陷阱」的来源。

七、通用灵感

• 把「是否被接受」升级为「为什么被拒」：二值指标压缩掉了失败的结构信息。任何 agent 评测都可以问：我的拒绝标签能不能拆成正交维度？HALO 证明时机×强度的二维拆分足以定位一个此前不可见的主导失败模式。
• 干预频率不是质量指标：+28.89 个点的干预可以对应 −14.77 个点的可接受率。产品指标里「agent 主动做了 N 件事」这类计数应当与「该做而没做」和「不该做而做了」成对出现，否则会系统性奖励过度主动。
• 干预的边际价值随基线递减：低基线模型多干预净赚 14.43 个点，高基线模型多干预净亏 14.77 个点。「把 agent 调得更主动」这个通用配方有明确的适用区间——先看你的模型 L0 选得够不够多，再决定往哪边调。
• 克制是被计分的动作：L0 与 L1-L3 同为一等动作级别，该沉默时沉默计入可接受率。把「不行动」纳入评分体系，是主动式系统区别于工具式系统的评测前提。
• 错误率的分母陷阱：从不选 L0 的模型 Inaction 恒为零。任何「错误率」都必须连同行为分布一起读，否则会得出荒谬结论。
• 判官微调的表面增益陷阱：判决准确率 +7.50 的同一模型，联合诊断准确率 −11.00。用自动判官替换人类标注前，先检查它是否真的学会了诊断维度，而不只是学会了判决边缘分布。
• L0 记录承诺而非努力：被接受的 L0 平均命令数（16.74）高于被接受的干预（14.65）——大量检索后选择不出手，与偷懒不查是两种 L0。日志系统应区分「查过然后沉默」与「直接沉默」。
• 提醒的天花板是证据，执行的天花板是授权：时机合适仍被拒的干预里，L1 有 52.81% 败于细节不足，L3 有 76.28% 败于越界。两个档位的失败模式镜像对称，修法也应对称：给提醒加检索、给执行加边界检查。
• 同一档位、两种命运：kitchen sneakers 案例里，同是 L3、同样检索到授权限制，守边界的被接受、越边界的被判过度。合规性检查应内建到动作生成，而非事后过滤。
• 「检索到了」有梯度之分：文件名/schema/空结果不算内容访问；59.0% vs 40.8% 的可接受率差距画在「查到实质内容」这条线上。检索的评测与日志都应区分「发起检索」与「获得内容」。
• 场景设计预埋诊断信号：HALO 的轨迹前缀特意包含干预过早/过晚的位置，且本地证据足以判定时机——评测环境不是中性舞台，它的构造决定了能观测到什么。设计自己的评测时，先问我要观测的失败模式有没有被环境显式支持。
• 构造流程可审计是基准可信的前提：分层通过率（89.61% / 78.59% / 70.42%）、双评审加裁决、修订候选单独计数——HALO 的场景质量论证不靠声明靠记录。自己做数据合成时，这套审计链是最值得抄的部分。

八、与既有评测的对话

HALO 与既有基准的关系不是替代，而是补上缺失的观测维度。逐家的对比如下。

对 PROBE：PROBE 同样支持 SQL 与语义文档检索，但依赖自动动作分数；HALO 把检索到的证据与人类判决直接关联——同一个「检索」能力，PROBE 度量选对动作，HALO 度量检索是否转化为人类认可的帮助（5.6 节的 +9.25 个点即此关联的量化）。

对 ProAgentBench / PARE-Bench / π-Bench：三者覆盖了真实计算机活动、有状态应用与长程工作流，环境交互性更强，但判决均为自动指标；HALO 放弃了真实环境，换来逐响应的人类诊断。二者的取舍本质是环境保真度对失败可解释性——HALO 的选择回答了「为什么被拒」，它们的回答了「在真实界面上行不行」。理想 future 是把 HALO 的诊断协议移植到真实环境基准上：动作分级与双维诊断不依赖模拟环境，理论上可以直接套在 ProAgentBench 的轨迹上——缺的只是标注预算。

对 AgentAbstain / ProEvent：这两个校准基准分别处理显式请求下的克制与聊天时机，HALO 把克制与时机统一进无请求情境，并新增了强度维度。三者合起来，「行动-克制-时机-强度」的校准评测版图才完整。特别值得对比的是 AgentAbstain 的「克制」与 HALO 的 L0：前者是显式请求下的拒答（用户要你做，你判断不该做），后者是无请求下的沉默（用户没开口，你判断不必开口）——两种克制的认知负担不同，前者要顶住指令压力，后者要在没有触发信号的情况下维持判断。HALO 的数据表明后者更难：连最强的模型也有超过 25% 的响应不可接受。

对 Proactivity-Gym：同样含人类研究，但 Proactivity-Gym 关注多日模拟中的时间分配与信任的整体感知；HALO 的 20 人逐条标注换来了可复用的诊断数据集（8,000 条）而非一次性用户研究。HALO 的判官微调实验（判决涨、诊断跌）恰好暗示：这类数据集的价值主要在诊断标签，而诊断标签恰恰最难自动化。

合起来看，HALO 在评测光谱上选的位置是「环境简单、判决深」：构造环境牺牲了真实感，但让 20 人逐条诊断 8,000 条响应成为可能——换成真实桌面环境，这个标注成本会爆炸。深度与广度的权衡里，HALO 押注深度。

诚实的边界也该说：HALO 的场景是构造的，需求分布是设计的，不代表真实使用中各类需求与失败的自然频率；checkpoint 评测省略了用户响应与重复干预的累积效应——真实用户会在 agent 第三次打扰时关掉它，这个动态 HALO 测不到；20 位标注者背景相近，判决无法代表全部用户偏好。这三条 Limitations 都是论文自己写明的。

把这些边界记在心里，HALO 的正确用法是当作诊断仪器而非成绩单：它告诉你一类失败存在且占比很高，为后续的机理研究与训练干预提供了坐标，但把它的数字外推到真实部署时需要重新校准。

九、开放问题

• 过度主动的分布外推：61.20% 是构造场景上的数字。真实使用中，当用户真的可以关掉 agent 时，过度主动的代价会被放大还是被容忍？需要带真实用户反馈的在线研究。
• 判决与价值的分离：HALO 的可接受性判的是「有据、有用、时机与范围恰当」，不排 usefulness 序。一个过度保守的 agent（全部 L0、只在该出手时出手）与一个恰到好处的 agent 在可接受率上可能同分，但用户体验天差地别——判决之外是否需要效用维度？
• 个性化与判决普适性：论文自己承认 20 位标注者背景相近，边界案例对某些用户有用、对另一些构成打扰。可接受率作为单一标量是否应被偏好分布取代？同一个「周六上午来修厨房鞋柜」的请求，独居者觉得贴心、合租者觉得越权——判决的个性化建模可能是下一个基准的分水岭。
• 多轮交互与用户反馈：checkpoint 是单轮的——agent 出手后用户的反应（采纳、忽略、抱怨）不会进入后续决策。真实分寸感是闭环的：上次提醒被无视，这次的措辞与时机都该变。把用户模拟器接入 HALO 式诊断是自然延伸，PARE-Bench 的主动用户模拟恰好可以对接。
• 同级别内的异质性：L0-L3 按外部承诺分级，但同级动作的可逆性与用户负担不同（发邮件 vs 支付都是 L3）。承诺分级之上是否需要成本分级？论文在 Limitations 里明确承认这一粒度损失：聚合可接受率无法完整刻画收益、负担与干预风险之间的权衡。
• 诊断的自动化：谁能复现人类的时机×强度诊断？附录 H 的 LoRA 实验是警钟——判决可学、诊断难学。判官模型的评测是否应该强制报告逐维度准确率而非单一判决准确率？
• 从诊断到校准：HALO 证明了过度主动可测，但如何治？时机窗口的显式建模、授权边界的硬约束、检索-干预的因果链路验证，都是开放方向。一个更基础的问题是：过度主动究竟是预训练分布的偏置（示范数据里 agent 总在行动），还是奖励设计的产物（行动才有反馈、沉默没有分数）？HALO 的数据为回答这类因果问题提供了素材。
• 跨档位选择的显式建模：5.7 节的跨模型对照显示 69.60% 的 Insufficient L1 在同 checkpoint 有被接受的 L1 版本、74.79% 的 Excessive L3 有被接受的降档版本——失败多数是「档位选择」而非「能力」问题。这暗示一条改进路径：让模型在生成前显式推理「为什么是这个档位」，正如 HALO 的 agent prompt 已经要求内部判断不外露。
• 被接受者的排序：HALO 不给可接受响应排 usefulness 序，可接受与最优帮助之间还有一段未刻画的空间。两个都被判接受的提醒，一个救了急、一个不痛不痒，在当前分数体系里等价。
• 累积效应与长期信任：checkpoint 评测把每次干预当作孤立事件。真实场景里，用户的耐心是存量——第一次过早提醒被原谅，第五次就可能关闭权限。Proactivity-Gym 已开始建模信任，把「干预历史」纳入判决是两个方向的天然合流点。

十、结语前的速览

如果只带走五个数字，建议是这五个：72.88 / 56.63（专有与开源的可接受率天花板）、61.20（被拒响应中过度主动占比）、3 倍 / 2 倍（过早对过晚、过度对不足的不对称）、+28.89 → −14.77（配对 checkpoint 上干预增加可接受率反降）、52.81 / 76.28（时机合适仍被拒时 L1 不足与 L3 过度的镜像）。

它们分别回答了：现在什么水平、败在哪、偏向哪、干预该不该加、两类干预各自的病根。带着这五个数字去读原文的 Table 1 与 Figure 4-7，效率最高。

结语

HALO 的价值不在 400 个场景或 8,000 条标注本身，而在它把 agent 评测的问题从「做得对不对」推进到「分寸拿捏得准不准」。61.20% 这个数字应当让所有做主动式助手的产品团队停下来想一想：当前 agent 的瓶颈大概率不是能力不足，而是出手太勤、太满。最强的模型与中游模型的差距，一半不在「会做什么」，而在「什么时候选择什么都不做」。

L0-L3 的动作分级、时机×强度的双维诊断、把克制计分的判决定义，这三样东西任何一个都可独立迁移到自家评测体系里。迁移的成本不高——HALO 的标注协议（预填级别、双维诊断、固定标注者）本身就是一份操作手册——而收益是把「可接受率」从一个黑箱数字变成一张病理切片：你的 agent 是过早、过度、不足还是不作为，从此各有各的处方。

更深一层的启示关于评测哲学：当你只能测一个数，你会优化那个数；当 HALO 把拒绝拆成过早/过晚/不足/过度四种病因，「提高可接受率」就不再是调一个旋钮，而是回答一组关于分寸的问题。主动式 agent 要真正进入日常生活，需要的正是这种能看见分寸的评测——毕竟，最好的管家从来不是最勤快的那个，而是最知道什么时候该退到一边的那个。