追问之前先回忆：什么时候该读记忆，什么时候才该向用户补问题

追问之前先回忆什么时候该读记忆什么时候才该向用户补问题很多执行型 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 平台。