追問之前先回憶什么時候該讀記憶什么時候才該向用戶補問題很多執行型 AI 助理看起來“信息不夠”時第一反應都是繼續追問用戶。但真正穩定的系統默認順序其實應該反過來先 recall再 clarification。也就是說如果答案很可能已經存在于記憶、歷史任務、運行檔案或當前上下文里系統應該先把這些來源查一遍只有在它已經檢查過這些來源之后仍然缺少繼續執行所需的信息時追問才是正確動作。為什么“先回憶”比“先追問”更重要系統“現在沒想起來”不等于“系統從來不知道”。真實協作里很多看起來像“缺信息”的情況其實只是還沒做檢索用戶以前已經說過系統以前已經做過某次 run 留下了鏈接、截圖、日志或文件當前上下文里已經有明確線索只是還沒被讀取。如果這些答案本來就在系統可達范圍內直接追問用戶就會把本該由系統完成的檢索工作重新甩給用戶。哪些信息最適合先 recall1. 長期偏好和約定比如默認語言、默認工作目錄、常用輸出格式、用戶明確說過“以后都這樣”的規則。這類內容一旦存過就不該在每次任務里重新問一遍。2. 用戶以前給過的穩定事實比如某個倉庫路徑、某個平臺要發到哪個賬號、某個對象對應哪條規則。這類信息通常不是當前任務的新決策而是歷史上已經存在的事實。3. 上一次執行已經產出的結果比如剛才發布生成的鏈接、上次失敗在哪一步、截圖保存在哪里、某個 run 改了哪些文件。遇到這類問題時更穩的動作通常是查任務歷史或運行檔案而不是直接問用戶。什么時候 clarification 才是正確下一步真正應該追問的通常是下面三類1. 缺的是新的決策例如這次要發正式版還是草稿兩個平臺只能選一個時優先哪個統計范圍按 7 天還是 30 天。這些不是舊記憶而是當前任務的新選擇。2. 缺的是只有用戶知道的外部信息例如登錄驗證碼、新憑據、只有用戶知道的日期、人數或預算。系統再怎么 recall也拿不到這類答案。3. 缺的是會導致結果實質不同的關鍵字段例如具體日期、時間、發布平臺、發布模式、要修改哪一個任務。填錯這些字段結果就不是同一件事了。一個關鍵邊界缺的是答案還是缺的是“定位答案的鑰匙”這是判斷 recall 還是 clarification 很好用的方法。如果缺的是答案本身而且答案很可能已經存在例如默認語言、上次 run 改了哪些文件、項目默認路徑那就優先 recall。如果缺的是定位答案的鑰匙例如“那個任務”到底指哪個、“這個平臺”到底是知乎還是掘金、“繼續剛才那個”是續跑還是新開那就優先 clarification。因為系統連該去哪份記憶里找都還不知道。為什么很多無效追問本質上是檢索失敗像“上次那個”“按之前那個規則來”“繼續剛才那個”表面上像用戶沒說清楚實際上常常只是系統還沒做檢索。例如“上次那個”可能能通過最近通知定位到具體任務“之前那個規則”可能已經是 standing memory“繼續剛才那個”可能能從 recent run 或 run archive 里找到明確對象。如果本來可以通過檢索解決卻直接升級成 clarification用戶會明顯感覺自己在替系統當數據庫。一個更穩的執行順序在執行型系統里遇到“信息似乎不夠”時更穩的順序通常是先看當前上下文再看 standing memory / memory index再查任務歷史與運行檔案最后只對真正缺失的關鍵字段做 clarification。這樣問出來的問題會更少也更準。因為系統補問的是“最后缺的那個點”而不是把整塊檢索工作推回給用戶。FAQFAQ 1只要有記憶就一定不能追問嗎不是。記憶只是起點不保證答案仍然有效也不保證已經足夠當前任務繼續執行。FAQ 2memory index 里只有標題沒有正文算已經查過了嗎不算。標題只是線索不是答案本身。只要還有相關線索沒讀就不該直接說“不知道”。FAQ 3什么問題最不該直接追問用戶最不該直接追問的通常是用戶以前已經明確給過、而且系統本來可以通過記憶、運行檔案或近期上下文自己查到的內容。本文首發于 OmniGoAI 官網https://omnigoai.com/zh/blog/gowork-pending-clarification-vs-memory-recall/ ——OmniPost把內容一鍵分發到 30 平臺。