AI記住了你的習慣，但權限不能靠回憶判斷

分析｜2026年11月7日

11月5日提交的《The Memory Trap》預印本發現，良性互動形成的記憶可能誘發後續模擬任務中的越界行為。這不是線上事故發生率的測量。論文

這項研究帶來的產品問題，不只是怎樣把使用者的話保存得更準確，而是保存下來的話究竟能決定什麼。我們認為，記憶可以改善服務方式，卻不應該獨自決定一個系統是否有權改變外部世界。以下是 Open Market Notes 的產品與治理分析，不是對某款產品已經實現這些控制的聲明。

個人化和授權應當走不同的處理流程

設想一個採購助手。使用者希望它少提問題、優先選擇熟悉供應商、保持郵件簡潔。這些偏好可以幫助它排序報價、組織說明、準備草稿。然而，實際下單需要另一組答案：允許購買什麼、向誰購買、金額上限是多少、運送到哪裡，以及是否允許續訂。習慣描述得再完整，也不能自動補齊這些缺失條件。

如果兩類資訊都只是儲存為一段自然語言，系統很容易失去一個重要區別：偏好是在多個合規選項之間提供排序依據，授權則決定某個選項能否執行。把使用者「不喜歡反覆確認」的偏好當作免除任何確認的理由，實質上是讓服務體驗要求改變了交易邊界。這是本刊提出的架構風險判斷，不是對實際客戶事故的描述。

更合適的設計，是讓模型先產生行動方案，再由獨立的授權紀錄判斷是否可以執行。這個紀錄不必複雜，但必須能表達操作、對象、限制和有效條件。一個授權可以涵蓋一批重複採購，也可以僅涵蓋某張訂單。使用者明確給予的長期許可不應每次重新詢問；沒有被授予的權限也不應從聊天語氣中推導出來。

有帳戶存取權，不等於每項業務操作都被批准

Claude 的記憶工具文件將檔案操作的執行與儲存交給應用程式端。官方文件 這意味著，應用程式設計者有機會在模型請求與實際執行之間設定控制，而不是只能依賴模型如何理解一段歷史。

MCP 的授權規範處理的是客戶端代表資源所有者存取受限伺服器的傳輸層授權。規範 本刊據此強調一個不同層次的問題：技術連線允許呼叫某項服務，並不意味著使用者已經批准目前訂單、收件人或檔案分享對象。連線權限回答「這個客戶端能存取什麼」，業務授權還要回答「這一次可以做什麼」。

例如，一個行事曆助手可能需要長期讀取日程並建立會議。對於內部週會，這種權限很方便；如果它要把包含未公開專案名稱的會議邀請寄給外部聯絡人，仍需檢查邀請對象和允許分享的內容。這裡的例子是設計演練，而不是要求所有外部會議都必須人工審批。關鍵是授權範圍必須涵蓋目前事實，而非只涵蓋一個籠統的工具名稱。

批次任務最需要明確例外處理

企業購買智慧體通常希望降低重複協調成本。每項操作都彈出確認，會把自動化收益還給審批負擔。因此，可用的安全機制不能只有「全部放行」和「逐項詢問」兩個選項。

我們建議把批次任務拆成已滿足授權條件的項目和出現實質變化的項目。假設團隊批准向現有客戶寄送帳單提醒，助手可以連續處理相同範圍內的正常紀錄；若某條紀錄涉及新的收款帳戶、金額爭議或不同接收人，它應暫停這一項，而不是暫停整個佇列，也不是用整體批准掩蓋異常。使用者隨後作出的決定只改變被指出的例外，不應預設為擴大全部任務的權限。

這種設計需要記錄實際執行時的條件。僅保存「已獲批准」四個字無法解釋後來發生了什麼。較有用的稽核紀錄包括批准來源、當時的目標對象、關鍵限制、執行時是否發生變化，以及異常如何被解決。紀錄不必向使用者展示所有內部細節，但應支援具體追問：為什麼這一項無需再次確認，而另一項需要？

評估應衡量邊界，而不只是成功率

一套採購助手測試可以讓普通訂單和例外訂單使用相似措辭，保持產品與供應商不變，只改變金額上限、收貨地址或續訂條件。預期結果不是讓助手對一切猶豫，而是讓已批准範圍內的任務繼續完成，僅把真正超出範圍的項目提出。

我們會同時觀察三項指標：未經充分授權的執行、已有授權卻重複詢問，以及例外項目導致其他正常工作停頓的時間。這是本刊提出的評估框架，並非上述論文報告的指標。只看第一項可能鼓勵系統拒絕所有工作；只看完成率則可能獎勵過度推斷。只有同時考慮，才能判斷控制是否改善了實際服務。

還應測試權限變更後的行為。例如，取消某個供應商的自動採購許可之後，舊摘要、已排隊任務和另一個智慧體的轉述都不應使它重新生效。權限檢查應發生在即將執行時，而不只是規劃開始時。這樣，即使任務持續很久，最後一步仍然依據目前有效條件。

這項預印本值得關注，但它不能單獨證明某種權限架構有效。產品團隊仍需在自己的工具、資料和異常分布中驗證。更現實的目標，是讓助手既能記住如何更好地幫助一個人，又能清楚說明自己依據什麼被允許採取行動。兩者分開，才有可能同時減少無謂打擾和未經授權的操作。