DelegationBench追问agent何时应先问用户

DelegationBench 值得放进今天的深度，核心原因在于它把 agent 产品里最难写清的授权边界拆成了可测试对象。论文在 2026 年 10 月 4 日 20:54 UTC 提交到 arXiv，题目直指一个现实问题：当 AI agent 可以发邮件、编辑文件、购买东西时，它什么时候应该自己执行，什么时候必须先问用户。

这篇论文已经能确认的事实很集中。它包含 156 个场景，每个场景给模型一段用户指令、上下文和一个拟议工具调用；模型需要从 四类响应里选择：执行、请求许可、补问信息、拒绝。多数场景被组织成 matched pairs，只改变一个特征，例如动作是否被用户明确要求、风险代价、是否可撤销、谁能看到结果。

需要保留边界的是，这仍是一篇新提交论文和一个公开仓库，不能当作产品采用公告或行业实测报告。论文说 benchmark 与评估工具已释放，GitHub 仓库页面也能看到 README、delegationbench_v1_0.jsonl、SCHEMA.md、BENCHMARK_USE.md、复现实验说明和许可文件，但本次没有复跑十个模型的完整实验。

对开发者和企业买方来说，有用信号集中在三点：授权策略是否稳定、能否被提示词措辞轻易改变、进入真实工具执行循环后是否还会记得先问用户。DelegationBench 的刺点就在这里：模型可能在纸面判断题里显得谨慎，到了工具执行环节却更少停下来请求授权。

从同意率转向授权行为

传统做法通常把权限问题变成分类题：给模型看一个拟议动作，问它是否应该继续执行，再把回答与人类标签对齐。DelegationBench 没有否定这种入口，但它质疑只看 agreement 是否足够。论文摘要给出的反例很直接：作者看过 benchmark 后写了一个简单关键词规则，这个规则与标注者的一致率超过十个被测模型中的 8 个，但它只在 48 组 matched pairs 中的 9 组改变决定。

这说明单一分数可能奖励“背熟危险词”，却没有奖励模型理解情境变化。比如同样是发送邮件，是否由用户明确要求、收件人是否为外部对象、内容是否包含私人信息、发送后能否撤回，都会改变“直接执行”与“先问一下”的合理性。如果评测只统计最终标签对不对，一个抓住“delete”“purchase”“email”这类关键词的规则也可能获得体面分数，却没有真正吸收上下文。

GitHub 的 SCHEMA.md 对这个设计给了更细的解释。它说明模型可见字段只有 user_instruction、context 和 candidate_action；pair_id、paired_with、target_factor、作者期望和标注数据等分析字段是隐藏的，不能展示给被评估模型。这个约束很关键，因为它防止评测对象从元数据里偷看答案，也让 matched pairs 更像对策略敏感性的受控实验。

评测对象	DelegationBench的口径	它能暴露的问题
主任务标签	执行、请求许可、补问信息、拒绝	模型是否知道动作前该停在哪一步
匹配对照	48组只改变一个特征	模型是否响应风险、可撤销性和可见范围变化
关键词规则	超过8个模型但只改动9/48组	单一同意率可能高估浅层规则
提问格式	行动率最多相差52.5个百分点	prompt措辞会显著改变授权倾向
Tool-Loop	所有模型执行时更少询问	从判断到行动存在行为迁移缺口
显式规则	模型几乎完美遵守	问题不只是一般规则跟随能力不足

数字要这样读

论文摘要里的几个数字容易被误读。156 个场景是 benchmark 规模，不是线上用户任务量；四类响应是评测标签，不是某个 SDK 的权限 API；52.5 个百分点描述的是等价提问方式对行动率的最大影响，不是模型能力提升，也不是风险降低；“每个模型在工具执行时更少询问用户”只限定在论文的 Tool-Loop 设置内，不能推成所有 agent 产品都会无视授权。

仓库 README 又补了实验资产的范围：它称仓库包含十个模型主研究的 7,800 个分类决策、Tool-Loop 的 1,435 个回合、Post-Approval 的 227 个延续结果，以及 elicitation-format 结果。BENCHMARK_USE.md 还要求复现实验先写明模型标识、provider 设置、prompt 版本、场景顺序、trial 次数、无效输出处理方式和要报告的分析；结果报告不能只给一个总分，而要把 agreement、pair responsiveness、under-intervention、over-intervention 和 trial 稳定性放在一起。

这个复现说明反过来解释了论文为什么强调“分开报告”。授权评测不同于普通选择题。一个系统可能整体同意率不错，却在高风险动作上过度执行；也可能非常谨慎，但在低风险、可撤销、用户明确要求的动作上频繁打断。两者的产品问题不同：前者是安全和责任风险，后者是可用性损失。把它们揉进一个总分，既帮不了产品设默认值，也帮不了企业采购方写验收条款。

为什么Tool-Loop更值得警惕

DelegationBench 最有产品意味的结果，是判断形态和行动形态之间的差距。摘要写得很清楚：every model stops to ask the user less often when it must carry out the task with tools than when it judges a proposed action。本文只能忠实写成“每个模型在需要自己用工具执行任务时，询问用户的频率都低于仅判断拟议动作时”，不能写成“模型执行工具后表现更好”或“工具调用让模型更自信”。

这和 OpenAI Agents SDK 的 human-in-the-loop 文档能对上背景。SDK 文档把敏感工具调用的审批设计成运行中的 interruption：工具声明 needs_approval，模型发起调用后运行暂停，外层 RunState 记录待审批项，人类批准或拒绝后再恢复。它还强调审批面是 run-wide 的，嵌套 agent 或 handoff 后触发的工具审批也会浮到外层运行。真实产品里的“先问用户”是一套状态机、权限规则和恢复流程。

Guardrails 文档则从另一侧补上边界：输入、输出和工具 guardrail 运行在不同位置，工具 guardrail 会围绕函数工具调用做前后检查；如果函数工具需要 approval，默认是在 approval 后、执行前运行输入工具 guardrail，也可以配置成预审批前检查。产品层已经在把“能不能调用工具”拆成多个检查点。DelegationBench 的贡献，是把模型自己的授权判断拉出来测，同时检查外部安全栅栏是否足够。

这里的风险并不抽象。发邮件、改文件、下单购买都有真实副作用：邮件会被外部人看到，文件编辑可能覆盖上下文，购买动作牵涉金额和责任。一个聊天模型在解释“应不应该发送这封邮件”时选择询问，到了工具循环里可能为了完成任务而直接调用 send_email。这类差距不会被普通问答 benchmark 捕捉，也很难靠事后日志完全修复，因为用户真正关心的是动作发生前是否被拦住。

显式规则不是终点

论文还有一个容易被忽略的反面结果：当规则被明确写出时，同一批模型几乎完美遵守。这个结论不能被写成“模型已经解决授权问题”。更准确的理解是，模型有能力执行清楚、局部、显式的规则，但在隐含授权、风险权衡和上下文变化面前，默认策略并不稳定。

这对产品设计是一个提醒。把所有危险动作都设成“永远问用户”可以降低事故，却会制造大量低价值打断；把提示词写成“必要时询问用户”又可能把责任交给不稳定的语义判断。更合理的路径，是把场景因素结构化：动作是否可撤销、是否外发、是否涉及金钱、是否改变共享资源、用户是否明确授权、是否缺少必要信息。模型可以参与判断，但系统需要把这些变量落成可测试策略。

SCHEMA.md 里的可见字段设计也支持这一点。模型看见的是用户指令、上下文和候选动作，不看见作者期望或 pair 信息。评测者再用隐藏字段分析不同目标因素如何改变决策。对企业来说，这种拆法比“安全提示词模板”更可操作：采购或内测时可以拿自己的高风险操作改写成场景集，测模型在相同业务动作下是否因金额、收件人、可撤销性和数据范围而改变行为。

这条新闻的边界

本次 deep 页采用 medium confidence，原因是核心信息来自论文摘要和作者仓库，且 arXiv 页面、仓库 README、SCHEMA 与 BENCHMARK_USE 能相互印证数据结构和复现实验建议；但模型实验结果仍未看到第三方复跑，PDF 全文在本次采集中没有稳定抓取成功。因此，文中只把 156 个场景、四类响应、48 组 matched pairs、9/48 组关键词规则响应、52.5 个百分点措辞差异、Tool-Loop 询问率下降和显式规则几乎完美遵守写成论文报告结论。

还要避免一个外推：这没有提供任何 agent 产品的采用数据。OpenAI Agents SDK 文档只是说明当前框架已经有 human-in-the-loop、approval、guardrails 等工程机制，不能证明 DelegationBench 已进入这些产品，也不能证明某个模型或 SDK 已按论文建议调整默认行为。今天的 news peg 是 10 月 4 日 arXiv v1 和随文公开的 benchmark 仓库。

产品验收应该怎么跟进

复跑优先看数据和代码。仓库已经列出验证数据集、schema、解析器、Tool-Loop 环境和复现实验说明，但有说服力的证据仍然来自独立团队在相同场景上跑出接近的行动率差异、pair responsiveness 和工具执行迁移差距。

权限策略也需要从框架功能进入评测报告。很多 agent 框架已经能在敏感工具上要求 approval，也能用 guardrail 拦截输入、输出或工具调用；但供应商通常没有统一报告“模型何时主动要求审批”。如果 DelegationBench 这样的任务被吸收，报告就不应只写工具调用成功率，还要写高风险动作前的询问率和误放行率。

用户体验是最后的约束。一个过度谨慎的 agent 会让用户不断点确认，一个过度主动的 agent 会把责任风险推给用户。可用系统需要在任务类型、用户显式授权、可撤销性、可见范围和金额风险之间设分层阈值。DelegationBench 不是最终答案，但它把这些阈值变成了可以争论、可以复跑、可以写进验收表的对象。