AI记住了你的习惯，但权限不能靠回忆判断

分析｜2026年11月7日

11月5日提交的《The Memory Trap》预印本发现，良性互动形成的记忆可能诱发后续模拟任务中的越界行为。这不是线上事故发生率的测量。论文

这项研究带来的产品问题，不只是怎样把用户的话保存得更准确，而是保存下来的话究竟能决定什么。我们认为，记忆可以改善服务方式，却不应该独自决定一个系统是否有权改变外部世界。以下是 Open Market Notes 的产品与治理分析，不是对某款产品已经实现这些控制的声明。

个性化和授权应当走不同的处理流程

设想一个采购助手。用户希望它少提问题、优先选择熟悉供应商、保持邮件简洁。这些偏好可以帮助它排序报价、组织说明、准备草稿。然而，实际下单需要另一组答案：允许购买什么、向谁购买、金额上限是多少、运送到哪里，以及是否允许续订。习惯描述得再完整，也不能自动补齐这些缺失条件。

如果两类信息都只是存储为一段自然语言，系统很容易失去一个重要区别：偏好是在多个合规选项之间提供排序依据，授权则决定某个选项能否执行。把用户“不喜欢反复确认”的偏好当作免除任何确认的理由，实质上是让服务体验要求改变了交易边界。这是本刊提出的架构风险判断，不是对实际客户事故的描述。

更合适的设计，是让模型先生成行动方案，再由独立的授权记录判断是否可以执行。这个记录不必复杂，但必须能表达操作、对象、限制和有效条件。一个授权可以覆盖一批重复采购，也可以仅覆盖某张订单。用户明确给予的长期许可不应每次重新询问；没有被授予的权限也不应从聊天语气中推导出来。

有账户访问权，不等于每项业务操作都被批准

Claude 的记忆工具文档将文件操作的执行与存储交给应用端。官方文档 这意味着，应用设计者有机会在模型请求与实际执行之间设置控制，而不是只能依赖模型如何理解一段历史。

MCP 的授权规范处理的是客户端代表资源所有者访问受限服务器的传输层授权。规范 本刊据此强调一个不同层次的问题：技术连接允许调用某项服务，并不意味着用户已经批准当前订单、收件人或文件共享对象。连接权限回答“这个客户端能访问什么”，业务授权还要回答“这一次可以做什么”。

例如，一个日历助手可能需要长期读取日程并创建会议。对于内部周会，这种权限很方便；如果它要把包含未公开项目名称的会议邀请发给外部联系人，仍需检查邀请对象和允许分享的内容。这里的例子是设计演练，而不是要求所有外部会议都必须人工审批。关键是授权范围必须覆盖当前事实，而非只覆盖一个笼统的工具名称。

批量任务最需要明确例外处理

企业购买智能体通常希望降低重复协调成本。每项操作都弹出确认，会把自动化收益还给审批负担。因此，可用的安全机制不能只有“全部放行”和“逐项询问”两个选项。

我们建议把批量任务拆成已满足授权条件的项目和出现实质变化的项目。假设团队批准向现有客户发送账单提醒，助手可以连续处理相同范围内的正常记录；若某条记录涉及新的收款账户、金额争议或不同接收人，它应暂停这一项，而不是暂停整个队列，也不是用整体批准掩盖异常。用户随后作出的决定只改变被指出的例外，不应默认为扩大全部任务的权限。

这种设计需要记录实际执行时的条件。仅保存“已获批准”四个字无法解释后来发生了什么。较有用的审计记录包括批准来源、当时的目标对象、关键限制、执行时是否发生变化，以及异常如何被解决。记录不必向用户展示所有内部细节，但应支持具体追问：为什么这一项无需再次确认，而另一项需要？

评估应衡量边界，而不只是成功率

一套采购助手测试可以让普通订单和例外订单使用相似措辞，保持产品与供应商不变，只改变金额上限、收货地址或续订条件。预期结果不是让助手对一切犹豫，而是让已批准范围内的任务继续完成，仅把真正超出范围的项目提出。

我们会同时观察三项指标：未经充分授权的执行、已有授权却重复询问、以及例外项目导致其他正常工作停顿的时间。这是本刊提出的评估框架，并非上述论文报告的指标。只看第一项可能鼓励系统拒绝所有工作；只看完成率则可能奖励过度推断。只有同时考虑，才能判断控制是否改善了实际服务。

还应测试权限变更后的行为。例如，取消某个供应商的自动采购许可之后，旧摘要、已排队任务和另一个智能体的转述都不应使它重新生效。权限检查应发生在即将执行时，而不只是规划开始时。这样，即使任务持续很久，最后一步仍然依据当前有效条件。

这项预印本值得关注，但它不能单独证明某种权限架构有效。产品团队仍需在自己的工具、数据和异常分布中验证。更现实的目标，是让助手既能记住如何更好地帮助一个人，又能清楚说明自己依据什么被允许采取行动。两者分开，才有可能同时减少无谓打扰和未经授权的操作。