一句话结论
真实用户的请求往往是残缺的，而现有智能体评测都假定指令已经写全；iPrefBench 把「欠指定请求」做成可执行的 iOS 评测环境，量化出移动智能体在「把动作做对」和「替这个特定用户把事办成」之间的落差：动作完成度最高 91.6%，完整任务成功率最高只有 47.7%。
方法要点
这篇论文的贡献不是模型，而是评测装置。拆开看是四层设计。
第一层：一个连贯的人物画像。 基准建立在一个人设之上，这个人设有 3,051 条历史活动事件。所有「该推断什么」的答案都埋在这些事件里，而不是让被测智能体去猜。
第二层：欠指定任务集。 共 130 个用户任务，横跨 26 个应用。任务描述刻意省略了与用户相关的必要条件——比如没说用哪个账号、哪个时间段、哪种偏好档位。
第三层：把省略项二分类。 这是整套设计里最关键的一刀：每个被省略的用户相关需求，在构造时就明确归入两类之一——「可由历史推断」或「只能问用户」。这条约束让评分不再依赖评审主观判断：该推断的没推断是错，该问的没问也是错，不该问却反复追问同样是错。
第四层：交互式模拟用户。 评测跑在可执行的 iOS 环境里，配一个可交互的模拟用户。智能体可以发起提问，模拟用户按人物设定回答。于是「问不问、问几次、问得对不对」都成了可测量行为，而不是离线打分。
两个评测维度由此确定：个性化任务完成度（是否为这个用户正确完成任务）与用户—智能体交互（是否在必要时才索取信息）。
智能体每步的决策可以概括成下面这段伪代码：
# iPrefBench 单任务评测循环（伪代码，按论文设计还原）
persona = load_persona(events=3051) # 3,051 条历史活动事件
task = sample_task(persona, n_apps=26) # 130 个欠指定任务之一
state, history = init_ios_env(task.app), []
while not state.done:
missing = find_underspecified(task, state) # 本步缺哪些用户相关条件
for m in missing:
if m.kind == "history_inferable":
value = infer(m, persona.events) # 必须自己推断，问用户算错
else: # m.kind == "ask_only"
value = sim_user.ask(m) # 必须问，且不应重复追问
state = state.apply(m, value)
score = (
action_completion(state), # 动作是否做对
personalized_success(state), # 是否为该用户办成
interaction_quality(history), # 提问是否必要、是否遗漏
)
值得注意的是最后一行：三项分开计分。这正是论文能得出「执行好、个性化差」这一结论的测量基础——如果只报一个总分，落差会被平均掉。
关键数字
论文评测了 7 个前沿智能体，报告的是其中最好表现者的上限值，未给出统一基线与逐项提升幅度：
| 数据集 | 指标 | 结果 | 对比 |
|---|---|---|---|
| iPrefBench（130 任务 / 26 应用） | 动作完成度 | 最高 91.6% | 论文未提供统一基线 |
| iPrefBench | 完整任务成功率（个性化完成） | 最高 47.7% | 同上，且为 7 个智能体中的最好成绩 |
| iPrefBench | 只能问用户的信息 | 失败集中于此：索取必要信息不足 | 定性结论，原文未给分项数值 |
读这张表只需看一件事：同一批智能体，把单步动作做对的比例能到九成以上，端到端替这个用户把事办成的比例不到五成。差的那部分不是操作能力，是「知道什么该自己推断、什么该开口问」。
论文自述的定位也很克制：它把这组结果表述为个性化智能体面临的一项挑战，而不是宣布某个方法胜出。全文 32 页、5 张图，篇幅主要花在环境与任务构造上。
局限与前提
单一人设。 整个基准建立在一个人物画像的 3,051 条事件上。这意味着分数衡量的是「在这一个用户身上表现如何」，而不是跨用户泛化能力。换一个消费习惯、语言或隐私偏好完全不同的用户，结论是否稳定，论文没有回答。
平台绑定。 评测环境是可执行的 iOS 环境，结论天然带平台属性。跨应用跳转、系统级权限弹窗这些行为在其他移动平台上的表现，不在覆盖范围内。
二分类是简化。 把每个省略项判成「可推断」或「只能问」，让评分变得客观，但现实里的边界常常模糊：一条两年前的订单记录，算足够支撑推断，还是该跟用户确认一次？基准给了确定答案，真实产品里没有。
只测「欠指定」。 任务被设计成指令残缺，但没有覆盖另一类失败：指令写全了，智能体却执行错。因此 47.7% 不能被读作「移动智能体的整体成功率」。
交互成本未计入。 论文把「是否索取必要信息」作为质量维度，但没有把提问次数换算成用户负担的代价，也没有报告延迟或调用成本。对一个要替用户办事的产品来说，这两项最终会决定它能不 能上线。
作者自陈的不足集中在一点： 智能体在「只能问用户」这类信息上系统性地失败，问得不够。论文没有给出改进方法，只把它留作后续工作。
能不能用
开源状态：论文摘要页未给出代码、数据集或权重的下载链接。 页面上出现的 Hugging Face 等条目是 arXiv 的通用第三方工具入口，不是本项目仓库。要判断能否直接复现，需要等作者放出制品或查看 PDF 正文中的链接一节——速读阶段不能替它下结论。
按论文已披露的信息，本地复现至少需要：
- 一个可执行的 iOS 运行环境，能跑起评测用到的 26 个应用；
- 人物画像数据，即那 3,051 条历史活动事件，以及由它派生出的偏好状态；
- 130 个欠指定任务及其「可推断 / 只能问」的标注（这是标注成本最高的一块，也是基准价值的核心）；
- 交互式模拟用户组件，负责在智能体提问时按人设作答；
- 被测智能体的屏幕操作与提问双通道接口，以及分开计分的评测器。
如果只想要结论而不想复现：可以直接借用它的评测思路——把「该推断的」和「该问的」在任务设计阶段就标注清楚，再分开计分。这套约束不依赖它的代码，自己搭小规模任务集也能落地，是这篇论文对工程团队最可直接挪用的一点。
参考来源
- iPrefBench 论文摘要与元信息（arXiv:2610.34735）：https://arxiv.org/abs/2610.34735
- iPrefBench 全文 HTML（ar5iv 镜像）：https://ar5iv.labs.arxiv.org/html/2610.34735