用户为了让助手查找订单，登录了商家的账户。下一屏显示“已连接”。几分钟后，用户离开页面，以为退货已经安排好了。连接可能确实成功了，但用户理解的结果未必发生。这正是 Poppy 这份个人 Agent 协议新草案提出的产品问题。
10 月 9 日，Sierra 公开了草案，并宣布新增 35 家设计合作伙伴。它希望通过服务发现、会话、登录、网页、API 和企业自己的 Agent，让个人助手与企业服务相互连接。参与协议设计，不等于这些企业已经通过生产环境中的互通验收。连接在技术上有效，也不能证明用户理解了连接的后果。
对于正在做跨服务助手的小团队，今天值得改变的是一项具体实验：用户能否分清“允许查看账户”“允许修改账户”，以及“允许修改”和“修改已完成”？不必先采用整套协议，才能研究这个问题。
下面提供的是建议开展的研究方案，不是我们已经完成的实验报告。服务名称、界面、任务和样本人数都是研究设计材料，既不是客户观察，也不是 Poppy 对实现方的要求。
草案改变了什么，又不能证明什么
Poppy 的公开说明描述了一种贯穿 API 调用、网页浏览和对话的会话。同时，它区分短期会话令牌与登录后获得的持续账户访问能力；后者在企业允许的权限范围内保留，直到被撤销。因此，会话看起来连贯，并不意味着权限只覆盖当前这一件事。假如实际授予的权限更广、持续时间更长，界面却写“仅为这次退货连接”，就可能误导用户。
发布公告说，接下来一个月将举办设计工作坊，并公开参考实现。这是后续计划。页面上的示例展示了预期交互，没有提供任务完成率、用户理解的测量结果，或所有参与企业的服务保证。本文不认证草案的安全性，也没有复现公告中的演示。
10 月 9 日更新的 0.1 版规范明确提醒，稳定版之前可能发生不兼容的修改。第 4.4、4.9 节也说明了具体边界：企业负责落实通用或自定义权限范围；仅结束会话，不会影响 Account Token；退出登录后，已经发出的 Session Token 仍可能有效。我们下面的原型把“停止后续访问”简化成一个确定状态。真实产品的文案则必须反映令牌过期、撤销传播和企业实际检查的情况，不能因为按钮被点击，就承诺访问瞬间全部停止。
这里的作者推断是一条待验证的产品假设：当用户不再明显感知服务渠道的切换，也可能少了重新考虑授权范围的时刻。用户觉得自己一直在进行同一段顺畅的对话，底层却涉及不同的权限。这条假设也可能不成立；一致的会话反而可能帮助用户理解。实验设计应当允许这两种结果出现。
先写清自己的产品准备做什么。如果只读取账户资料，不要为了让研究显得重要，硬加一条购买流程。如果助手会提交变更，就把每次提交与访问账户的区别具体建模。研究记录中还要固定草案日期和原型版本，避免协议更新后，报告描述的对象与实际测试版本不再一致。
一条成功提示，可能混淆四种状态
团队讨论时先分清四个概念。登录让用户进入账户相关交互；访问授权规定助手能读取或修改什么；单次操作批准记录用户对某项具体变更的决定；操作完成则需要企业已接受或执行这项变更的证据。这四种区分服务于本研究，并不是 Poppy 强制规定的四个 API 状态。
OAuth 授权框架讨论的是第三方获得有限访问，以及由服务端定义的权限范围。实际授予的范围可以不同于申请的范围，响应需要说明差异。因此，用户看到的解释应该对应实际生效的访问能力，而不是简单复述助手最初的申请。拿到访问令牌，本身并不是拿到了订单操作的回执。
在本文虚构的退货服务中，原型允许读取一笔订单，并准备退货申请；真正提交还要经过另一次批准。最终结果可能是确认成功、被拒绝，或暂时无法确定。这些是我们为原型选择的产品规则。别的实现可以采用不同规则，不能把这里的设置称为“Poppy 的保证”。
我们关心的是：参与者能否解释谁有访问能力、能访问什么、持续多久，以及哪些事情已经发生。记住了商家名称，却把“读取订单”理解成“申请退款已经提交”，仍然没有理解关键边界。反过来，用户不喜欢授予权限，但完全理解后选择拒绝，也不应算成理解错误。偏好与理解是两种不同的结果。
具体场景：退货申请还没有提交
建立一个叫 Parcel Desk 的虚构助手服务，再建立一个叫 Oak Market 的虚构商家。参与者要了解一件夹克的退货方式、查看费用，并决定是否继续。订单、地址和账户资料全部使用合成数据。原型不向商家发送请求，不收费，也不索取真实登录凭据。
第一幕允许以访客身份查看退货政策。第二幕需要账户访问，才能找到订单。第三幕显示退货方案和虚构运费，记录用户对该方案的本地批准，但仍把提交放在另一个最终操作控件之后。第四幕在提交前提高运费：原批准失效，必须重新批准。第五幕在获得新批准并最终提交后，显示一笔尚未得到确认结果的请求。第六幕让用户在请求仍待处理时，停止后续账户访问。
这些场景分别暴露不同的误解。能浏览公开政策，不代表能访问账户。能访问账户，不代表已经提交。批准原费用，不代表也批准变化后的费用。请求待处理，不代表商家已经接受。停止后续访问，也不代表此前的外部操作被撤销。在任何参与者看到原型之前，先把这些事实写入标准答案表。
再设计一个结构相同的“预约上门服务”故事，替换表面细节，但保持权限边界一致。它同样需要预约提案、时间变化、提交结果不明，以及撤销访问的情节。这样才能尽量区分界面呈现的影响与故事本身的难度差异。招募前，请同事先检查两个故事是否真的等价。
保持权限不变，只比较呈现方式
为每个故事做两个都如实说明情况的版本。A 版用一个简短段落，交代服务名称、实际访问范围、持续时间、当前操作状态，以及停止访问的控件。B 版提供相同事实，但拆成有标签的几行：账户访问、当前操作、下一次批准、停止访问。任何版本都不能隐去决定性信息，也不能谎称任务已完成。
例如 A 版可以写：“已连接 Oak Market。Parcel Desk 可以读取这笔订单，直到你断开连接。退货申请已准备好，尚未提交。发送前请确认费用。”B 版把这些同样的信息分配到标签行和确认按钮周围。两版的控件、默认选项、字号、对比度和事实内容应保持一致，否则比较的就变成了“信息多与少”，而不是“信息如何组织”。
微软的人机 AI 交互指南研究提供了经过多个 AI 产品场景评估的设计资源。它支持我们把交互质量当成需要研究的设计问题，但不能证明本文的标签行一定优于段落。
开始研究前，把假设写下来：明确拆分状态，能减少用户误以为助手获准执行某个操作，以及过早判断任务完成的情况，同时不会明显妨碍本来应该进行的操作。什么叫“明显妨碍”，要根据自己的服务事先定义。不能看到哪版耗时较多之后，才倒过来挑一个合适的标准。这项研究测试的是呈现方式，不是模型优劣，也不能据此断言协议导致了用户困惑。
做一轮顺序平衡的探索研究
第一轮定性探索可以招募 12 名目标用户，让他们对助手的熟悉程度有所不同。12 人是本方案用于发现问题的安排，不是经过统计功效计算的样本量，也不是行业标准。记录招募条件与排除条件。不要用早已知道权限设计的同事替代真实目标用户，再把结果推广到客户群体。
将参与者分到四种安排，每种三人：先退货 A、后预约 B；先退货 B、后预约 A；先预约 A、后退货 B；先预约 B、后退货 A。研究前生成随机名单，按名单分配。这个安排平衡了故事、呈现版本与先后顺序，减少一种明显的干扰因素，但不能消除参与者从第一个故事中学到东西的影响。
不要让同一参与者看到同一故事的 A、B 两版，他们会记住之前的解释。在首次回答记录下来之前，也不要先讲授那四个状态概念。给出中性的任务，让参与者操作原型，再在决策位置暂停，询问他们认为接下来可以做什么，以及他们认为已经发生了什么。
每个阶段提问，本身可能让参与者更留意后续边界。这也是研究限制，需要记录。如果某种设计看起来值得继续验证，再找一批新的参与者，让他们先不中断地走完整个流程，最后再提问。后续研究测量的是另一种条件，不能把人数直接合并到前面分母中。受到提示与没有受到提示的体验，要分开报告。
研究录音或录像要先获得同意，评分文件不要包含参与者身份，全程使用合成交易。需要真实感的选择，不需要真实的资金风险。如果原型意外触及线上提交接口，立即停止该场研究，修好隔离之后才能继续。
询问后果预测，不要只问是否信任
每次暂停时，问：“接下来，助手不再询问你就能做什么？”以及“到现在为止，Oak Market 实际确认了什么？”然后让参与者演示自己会做的下一步。“我看不出来”也是有效回答，不要让他们为了显得懂产品而被迫猜测。
持续时间要单独问：“如果关闭窗口，明天回来，你觉得哪些访问能力还保留着？”停止访问也要单独问：“现在断开连接，刚才已经发送的申请会怎样？”这些问题测量的是对后果的理解，不是有没有认出 OAuth、JWT 等术语。熟悉技术词汇并不是我们想获得的产品结果。
所有版本使用同一套主持脚本。不要问“你知道这还没提交，对吧？”，也不要在评分环节称赞正确答案。这两种做法都在教参与者答题。记录完回答后，再问是什么界面信息让他们得出这个判断。这样既能给设计师提供修改线索，也不会把用户印象直接当成因果证据。
把偏好问题放在最后：哪版更清楚、哪版更费力、实际使用时愿意选哪版。用户信任一个界面，仍然可能预测错误；用户不太信任它，也可能做出正确判断。理解、行动和偏好分别记录，满意度就不会掩盖关键的权限错误。
可复用材料：权限边界理解评分表
下面的表格既是标准答案，也是标注计划。它只描述本文虚构的退货原型。真正使用之前，必须把事实替换成自己产品中已核实的行为。
| 场景 | 本原型的真实状态 | 中性提问 | 影响决策的错误 |
|---|---|---|---|
| 访客查政策 | 没有账户访问，也没有退货申请 | 它能看到哪些账户信息？ | 以为能读取个人订单 |
| 订单已连接 | 可读取这笔订单直到断开，尚无提交 | 不再批准一次，它还能做什么？ | 以为已经能提交退货 |
| 原费用已批准 | 仅在本地批准方案，申请还没发送 | 商家实际确认了什么？ | 把本地批准当成商家接受 |
| 费用变化 | 新费用需要重新批准 | 刚才的选择包含这笔新费用吗？ | 以为旧批准覆盖新条件 |
| 提交结果不明 | 请求已发出，尚无接受确认 | 你下一步会做什么？ | 当成已成功，或不检查就重复发送 |
| 停止访问 | 模拟环境已停止后续访问，待处理申请仍存在 | 哪些事情被撤销了？ | 以为断开连接撤销了已发送申请 |
每个回答保留参与者代号、分配组、故事、场景、原型版本、实际展示的信息、后果预测、演示的行动、所依据的界面信息和标注结果。再加上用时、求助次数，以及是否使用辅助技术。原始回答与标签一起保留，后来的审阅者才能质疑最初的解释。
按固定标准答案，把预测标为正确、错误或无法判断；把行动另外标为适当、不适当或未尝试。“无法判断”不自动算失败：当外部结果还没确认时，主动检查可能正是我们希望用户做的事。看不懂一个已经明确显示的权限，与合理地不确定外部操作结果，应分开报告。
正式研究前，请两名标注者独立判断几条虚构回答，再讨论差异。研究过程中，事先规定第二位标注者要独立检查多少记录；只要文字允许，就不向其显示呈现版本。如果参与者提到界面特征，让标注者猜出了版本，要承认只能做到部分盲评。分歧依据原型实际行为解决，不以设计师偏好的措辞为准；仍不能解决的案例继续保留。
统计错误，也要守住小样本的结论边界
主要探索指标是：每种呈现方式下，有多少人至少出现一次有实际后果的权限或完成状态误判。还要按具体边界展示次数，因为某种设计可能让用户更理解完成状态，却让他们更误解访问持续时间。每人都贡献了两种呈现方式的观察，这是配对、重复测量，不是两组互相独立的 12 人。
报告原始人数与分母。“A 版中，12 人有 3 人以为获得读取权限后就能提交”，读者可以理解；“25% 的客户不懂 Agent”，则超出了研究范围。也不能把六个场景乘以十二个人，再说研究了 72 名独立用户。同一个人的重复回答和学习效应都需要考虑。
也要观察用户本来想继续，却被界面阻碍的情况。但首先记录他们是否愿意继续，以及停止的原因。只有参与者已经明确表达继续意向，却因理解错误或操作障碍受阻，才计为“误停”。理解后主动拒绝是另一种结果，不是可用性错误；原因不明的停止暂不分类。用户操作时间与工作人员解释时间也要分开记录。避免代价很高的误操作，值得多花一些时间；一个让用户转去求助的快速界面，总耗时未必更少。
先决定如何使用这轮小样本研究。可行的探索规则是：发现严重且能复现的误解，就修改相关界面；检查另一种呈现是否避免了同一错误；再请新参与者验证修订。不要仅因为某版错误人数少，就宣布它胜出。要做正式比较，需要另行规划样本、希望识别的效果大小，以及能处理同一参与者多次观察的分析方法。
撤销访问与无障碍要分别检查
停止访问尤其容易写出过度承诺。OAuth 令牌撤销规范讨论令牌失效、可能的传播延迟，以及令牌和授权之间的关系。它没有提供撤销一笔已被商家接受的购买的机制。生产系统必须验证真正的停止行为，我们的模拟界面只能说明本文设定的行为。
OAuth 安全最佳实践要求限制令牌权限和适用的资源服务。文案再清楚，也无法补救实际权限过大，或资源服务端不落实限制的问题。工程检查与用户理解研究是两道独立门槛，通过其中一道，不能抵消另一道的失败。
不要只改善视觉排版，却让键盘或屏幕阅读器用户更难走完流程。W3C 的状态消息说明讨论如何让辅助技术获取相关更新，而不必强行移动焦点；无障碍身份验证说明讨论认知负担，以及密码管理器等辅助方式。这些是设计约束，几场用户访谈并不能证明产品符合全部标准。
W3C 也解释了涉及法律、资金或数据的错误预防，包括在适用场景中提供检查、更正或撤销的机会。可据此审视批准操作的时刻，但不能因为有一个确认按钮，就推断所有交易都能撤销。用目标用户真正需要的交互方式检查最终界面，没有覆盖的方式应写成未检查，不能记作通过。
能发现哪些失败，又不能证明什么
值得观察的往往是普通设计细节：商家标志让人以为服务关系已核实；“继续”让人以为是最终批准；成功颜色让准备阶段看起来像已完成；断开连接让人以为是在撤销操作；对话太长，让最新的权限变化难以找到。这些都是待观察的假设，并不是本次运行记录下来的用户行为。
研究能在受控故事中发现误导性标签、缺失的状态区别，以及不恰当的下一步。它无法证明令牌正确绑定了资源服务，无法证明企业后端落实了每一项权限，也无法证明 Agent 不会执行恶意指令。它不能给出生产故障发生率，不能覆盖授权所涉及的所有法律要求。报告应主动限定在真正测量到的范围。
它也不能回答用户遇到真实航班取消、挤在通勤车厢里，或使用数月以后，会怎么操作。招募人群、语言、残障辅助需求和任务后果，都会改变结果的含义。如果产品要本地化，应该为对应用户重写任务描述并重新做理解测试。英文研究结果不能证明中文的“已连接”也传达了同样含义。
还要防止研究方法本身失败：故意把 A 版写得含糊，B 版当然容易显得更好。两版都必须如实、可信，而且都是团队真的可能发布的候选方案。如果一版缺少必要信息，比较前先补齐。靠削弱对照版本得到的优势，不能支持真实发布决策。
连接更多服务之前，先决定改哪里
让研究结果支持一个范围明确的决定。如果用户把账户访问当成可以提交，修改这个转换位置，并让真正提交保留明确检查步骤。如果用户理解批准，却误读待处理结果，修改结果展示和后续操作控件。如果把断开连接当成撤销，就单独解释待处理操作；确实有取消路径时，把它展示出来。
决策记录应写明研究人群、任务、原型版本、被误解的边界、支持判断的原始回答、修改后的界面，以及仍未测试的部分。还要说明后端权限检查是否经过独立验证。让用户看懂界面，只是确保产品能安全地代表用户行动的一项条件。
这个方法适合已有具体跨服务任务、并能控制原型的小团队。对于没有账户委托访问的纯只读问答工具，价值相对有限；对于金融或医疗等高后果操作，它也不适合作为唯一验收方法。这些产品需要比本文探索研究更深入的领域工作。
Poppy 的及时性，在于它尝试让个人助手与企业之间的关系更连贯。Build Lab 今天能提供的是一套检查用户是否理解这种连贯关系的方法。在接上第二种交互渠道之前，先确认用户还能说清：助手获准做什么，哪一步需要另一个决定，以及企业实际已经完成了什么。