龙哥导读： Apple Research这篇不是在比谁更会“聊天”，而是在逼智能体面对真实手机交互的硬骨头：用户会不会接受、何时插手、能不能跨应用干活。PARE把这件事做成了可评测、可复现的框架，结果也挺扎心：最强模型成功率也只有四成多。
原论文信息如下：
论文标题:
Proactive Agent Research Environment Simulating Active Users to Evaluate Proactive Assistants
发表日期:
2026年04月
发表单位:
University of California, Santa Barbara; Apple, USA; University of Washington; Independent Researcher, USA
原文链接:
https://arxiv.org/pdf/2604.00842
项目链接:
https://github.com/deepakn97/pare
模拟用户交互：主动助手评估新框架
图1：PARE框架整体架构概览。左边是用户代理，右边是主动助手，中间是共享的事件驱动环境。关键点不在“会不会聊天”，而在“能不能像真实用户一样被环境约束住”。主动助手这类系统，最难的地方不是生成一句像样的建议，而是判断什么时候该插手、插手之后会不会把人带沟里、以及跨应用执行到底能不能真的完成。如果评测环境本身还是“用户站着不动等助手喂答案”，那测出来的分数大概率只是模型嘴皮子利索，不代表它真能帮人干活。这篇 Apple Research 相关工作做的事情很直接：把“主动助手”从纸面概念拉回真实交互环境，做成一个可运行、可评测、可复现的研究框架。PARE（Proactive Agent Research Environment，主动智能体研究环境）的核心思路，是让用户不再是被动接受指令的木偶，而是一个会在手机界面里一步步点、搜、切、填的活用户。这样一来，助手到底有没有看懂上下文、有没有猜对目标、有没有选对出手时机，就不再是“嘴上说说”。如果把传统评测比作“老师出题、学生答题”，那主动助手评测更像“老师在旁边看你做饭，偶尔提醒你别把锅烧糊了”。问题是，老师也得知道你现在在切菜还是在找盐。PARE要解决的，就是这种带状态、带时序、带多应用切换的真实复杂性。
核心创新：非对称FSM模拟真实用户行为
图2：发送消息的工具调用链对比。左边是普通代理框架，直接调用接口就完事；右边是 PARE，用户必须按屏幕状态一步步导航。差别很大，前者像“后台直连”，后者像“真机点点点”。PARE 最聪明的地方，不是又造了一个更花哨的环境，而是把用户和助手的权限故意做成不对称。这很符合现实：普通用户在手机上只能看到当前屏幕能做什么，想发消息、建日程、搜联系人，都得一层层翻；但助手如果拿到后台权限，可以直接调用接口，像“开外挂”一样跨应用执行。为了把这种差异建模清楚，PARE 用的是有限状态机，英文是 Finite State Machine，FSM，有限状态机。简单说，应用不是一个“扁平工具列表”，而是一张张屏幕组成的状态图：当前处于哪个页面、能点哪些按钮、填完表单后会跳到哪里，都要按规则走。用户代理在每个应用里只能看到当前状态下允许的工具，必须通过导航动作逐步逼近目标；助手则面对扁平 API，能更快获取信息并执行任务。这个公式表达的是：用户在时刻 t 的动作，不是凭空冒出来的，而是由上一轮观察、上一轮自己做过的动作，以及当前环境事件共同决定。说白了，用户不是“等着被安排”，而是会被消息、提醒、上下文不断推着走。这套设计的价值在于，它把“主动助手”最容易被忽略的现实约束补上了：用户看到的信息有限，能做的动作有限，助手却能更全局地观察和执行。如果不做这个区分，很多所谓“主动”其实只是模型在假装懂人心，环境一复杂就露馅。图7：邮件应用的用户状态转移示意。助手可以直接调用发送接口，但用户必须经历“打开写信—设置收件人—添加附件—发送”这一串状态迁移。这个差别看着琐碎，实际上就是“真实交互”和“API 直通车”的分水岭。
观察-执行架构：既能察言观色，又能先斩后奏
PARE 里的主动助手不是一个单一模型硬扛到底，而是拆成了两个阶段：观察（Observe）和执行（Execute）。这个设计很像现实里的靠谱秘书：先盯着现场情况，等确认机会合适了再出手，而不是一上来就冲上去把用户的事全包了。观察阶段只允许读信息，外加两个控制动作：继续等待，或者向用户发起建议。也就是说，助手在这个阶段的任务不是“立刻把事做完”，而是先判断有没有值得插手的机会。用户如果接受建议，助手才进入执行阶段，拿到跨应用的完整 API，开始真正干活。这个结构的好处很明显：把“是否该提议”和“如何执行”拆开，能减少模型一边胡乱提案、一边又执行失败的尴尬。这个公式描述的是助手在时刻 t 如何生成提议：输入包括自己过去的观察、自己过去的动作、用户过去的动作，以及当前环境事件。换句话说，助手不是“看一眼当前屏幕就拍脑袋”，而是要把前后文一起吃进去，才敢决定要不要开口。用户是否接受提议，也不是随便点头。PARE 把接受动作建模成一个显式的决策：只有当用户认为这个方案真的能帮助完成自己的目标，才会接受。被接受后，助手的动作集合才真正落地到环境中。这个机制看似简单，实际上很关键，因为主动助手最怕的不是不会做，而是“太爱帮忙，帮到用户烦”。这条式子表达的是：一旦用户接受提议，助手动作集合就会更新，把提议里的动作并进去。PARE 的评测逻辑因此不只是看“提案像不像样”，还要看“提案最后有没有真的把目标推进”。这套观察-执行架构还有一个很现实的好处：能把主动助手拆成“会不会看”和“会不会做”两种能力分别考。前者对应目标推断、插手时机和上下文理解，后者对应跨应用编排和工具调用链。很多模型前半段看着聪明，后半段一执行就掉链子；PARE 把这件事拆开后，问题会暴露得更清楚。
PARE 还专门测试了两类扰动：一类是工具失败，另一类是环境噪声，也就是那些没啥用但会疯狂冒出来的通知、邮件、提醒。这个设计很像真实手机生活：真正影响助手表现的，从来不是“题目本身”，而是题目周围那堆乱七八糟的信息。图3：工具失败概率变化下的提议率、接受率与执行成功率。整体看，提议和接受相对稳定，但执行成功会受到工具失败的直接影响，说明“会提案”不等于“会收尾”。图4：环境噪声变化下的提议率、接受率与执行成功率。噪声越大，部分模型越容易分心，尤其是中小模型；而更强模型在噪声下仍能保持相对稳定的表现。结果说明，主动助手的难点不是单纯的语言理解，而是在不确定、受干扰、跨应用、会失败的环境里保持判断力。这也是为什么作者强调边缘部署和隐私边界：主动助手必须持续观察用户行为，如果还动不动把数据全上传，产品层面就先把用户吓跑了。从工程角度看，这篇工作最像一把尺子，而不是一套“立刻能商用”的成品。它把主动助手的关键问题拆得很细：环境怎么建、用户怎么模拟、提议怎么评、执行怎么验。对后续研究来说，这种基础设施比单篇模型论文更值钱，因为没有统一评测，大家只能各吹各的。
Deepak Nathani, Cheng Zhang, Chang Huan, Jiaming Shan, Yinfei Yang, Alkesh Patel, Zhe Gan, William Yang Wang, Michael Saxon, Xin Eric Wang. Proactive Agent Research Environment Simulating Active Users to Evaluate Proactive Assistants. arXiv:2604.00842, 2026.项目主页：https://github.com/deepakn97/pare原文链接：https://arxiv.org/pdf/2604.00842
