用户问上次做了什么时，为什么先查运行档案

当用户问“上次到底做了什么”时，最容易出错的做法不是答不上来，而是立刻重探线上系统。如果助理没有先看运行档案，就很可能把“现在看到的状态”误说成“上次实际做过的事”，甚至为一个档案里本来就有答案的问题，重复触发桌面操作、网页检查或外部调用。

这也是 OmniGoAI 的 GoWork 为什么把 recall_run_details 这类运行档案能力放成一等工具。GoWork 不只是保存聊天记录，而是把命令、文件、错误、时间线和产物证据保留下来，让助理在用户追问“刚才那个任务”“上周那个 run”“上次你到底改了什么”时，先基于历史执行事实回答，再决定是否需要碰当前环境。

如果你已经看过为什么 AI 助理需要记忆、任务历史和回溯能力、失败后别重来：让 AI 助理从上次进度继续和聊天渠道上下文和运行上下文有什么区别，这篇文章继续回答一个更具体、但在真实协作里特别高频的问题：用户问的是“上次发生了什么”，为什么系统应该优先查运行档案，而不是先去重探线上系统？

先说结论：关于过去执行细节的问题，默认先查档，不默认重探

可以把这个原则记成一句话：

用户问的是过去那次执行“做过什么、改过什么、失败在哪”；
如果这些信息理论上属于历史 run；
那就先查运行档案，而不是先碰现在的系统。

原因很直接：运行档案回答的是历史事实，线上重探回答的是当前状态。 两者都重要，但不是同一个问题。

如果把顺序反过来，通常会带来三类偏差：

你把“现在看到的样子”错当成“上次做过的动作”；
你为了一句状态追问，又重复触发了一轮本来不该重跑的操作；
你明明已经有证据链，却因为没先读档案，反而把答案越答越不准。

为什么“线上重探”不能替代“档案回看”？

因为它们回答的问题根本不同。

运行档案回答的是历史执行事实

运行档案通常关心这些内容：

上次 run 的 trigger 是什么；
当时调用了哪些工具、命令和文件；
具体在哪一步失败或完成；
输出、报错、产物和时间线长什么样；
最后有没有留下截图、路径、artifact 或公开链接。

这些内容一旦丢掉，后面就只能靠猜。

线上重探回答的是当前现场状态

重探线上系统更适合回答这些问题：

现在这个服务是否还在线；
当前页面长什么样；
现在这份文件是否还存在；
当前平台是否已经登录；
刚才那篇内容现在是不是审核中。

这类信息当然有价值，但它只能说明“现在怎么样”，不能自动推回“上次到底发生了什么”。

一个典型误区：把“上次做了什么”和“现在是什么状态”混成一个问题

真人协作里，这两句话看起来很像，但实际上是两类请求：

“你上次到底跑了哪些命令？”
“你现在再去看看那个系统是什么状态。”

第一句明显是回溯，第二句明显是重探。真正麻烦的是下面这种混合表达：

“刚才那个任务怎么弄的？”
“上次为什么失败？”
“你去看一下你之前发给我的那张图。”
“那个任务当时做到哪一步了？”

这些问题表面上像是在继续对话，本质上却在要历史执行证据。如果系统没先识别这一层，就会很容易直接开新工具、看新页面、截新图，最后给出一个关于“现在”的回答，却没有回答“上次”。

为什么运行档案通常比聊天记录更适合回答这类问题？

因为聊天记录主要保存“说过什么”，不一定保存“做过什么”。

聊天文本也许能告诉你：

用户当时提了什么需求；
助手最后回了什么总结；
中途有没有让用户补充东西。

但如果你要回答这些问题：

究竟改过哪几个文件？
那次 shell 命令的 stderr 是什么？
桌面上看到的截图路径或 artifact ID 是多少？
是第 3 步失败，还是第 5 步失败？

单靠聊天记录往往不够。真正能支撑复盘的，还是运行档案里的工具结果、时间线、错误和产物。

这也是为什么为什么 AI 助理需要记忆、任务历史和回溯能力一文里强调：聊天记录、任务历史和运行回溯必须分层。你现在问“上次到底做了什么”，优先命中的本来就该是回溯层。

真实协作里，先查档案能避免哪些错误？

1. 避免把历史截图问题答成当前截图问题

在桌面自动化场景里，这个坑特别常见。

用户说“去看原来那张截图”，真正要的是历史证据。如果系统直接重截一张，就可能拿到一个已经变化过的界面，然后误以为自己已经完成了“回看”。

更稳的顺序应该是：

先查那次 run 有没有保存截图路径或 artifact；
有的话先 view_image 看原图；
只有历史图不存在、且用户目标明确要求看当前状态时，才重新截新图。

这里的关键不是“旧图一定更好”，而是用户问的是哪一层事实。

2. 避免为一句追问重复触发外部动作

如果用户只是问“上次那个发布任务怎么了”，最合理的第一步通常不是再点一次发布按钮、再重跑一遍构建，甚至也不是再去刷新平台后台，而是先查：

上次 run 的结论是什么；
发布命令是否真正执行过；
当时留下了哪些链接、记录 ID 或失败原因；
系统是否已经在报告里写过答案。

否则一条状态追问，很容易被误执行成一次新的发布动作。这不仅浪费，还可能触发重复内容、平台限频或二次副作用。

3. 避免让用户重复补已经存在的信息

很多追问之所以让人烦，不是因为系统不知道，而是因为系统本来能知道却没先看档案。

用户问“上次改了哪个仓库”“你前天那个 run 到底失败在哪”，如果档案里已经有：

run ID；
改过的文件；
命令；
错误信息；
关键截图或产物路径；

那再回头让用户重新描述一遍，本质上就是把系统该做的回溯工作又甩回给用户。

为什么这个原则对执行型 AI 特别重要？

因为执行型 AI 的风险不在“答错一段话”，而在“答错后又动手做错一遍”。

普通聊天机器人先猜再答，代价通常只是文本偏差；执行型 AI 如果在没查档案前就重新操作桌面、重新调用工具、重新碰线上环境，代价可能会变成：

重复发布；
覆盖新状态；
用当前结果污染历史判断；
让用户误以为系统已经核对过历史事实。

所以对执行型系统来说，“先查档案”不是保守，而是避免误动作的默认安全路径。

GoWork 为什么适合把这个原则做成系统能力？

因为 GoWork 的目标本来就不是单纯生成回答，而是维护一条可继续、可解释、可回溯的任务链。

这意味着它会把几层信息拆开：

聊天上下文：用户现在在问哪件事；
任务历史：最近有哪些相关任务、状态分别是什么；
运行档案：具体命令、文件、错误、截图和时间线；
当前执行权限：这轮到底是在查状态，还是应该继续动作。

有了这几层分工，系统才能先回答“历史上发生了什么”，再决定“当前要不要重探现场”。

这和聊天渠道上下文和运行上下文有什么区别里讲的是同一个底层原则：聊天上下文帮你理解用户在指什么，运行档案帮你确认那次执行到底做了什么。

什么时候才应该在查档之后再去重探线上系统？

先查档，不等于永远不重探。

真正稳的顺序通常是两段式：

先查历史档案，确定上次到底发生了什么；
如果用户还想知道现在状态，再在历史事实基础上重探当前现场。

下面几类情况尤其适合档案 + 重探连用：

1. 用户同时问“上次怎么了”和“现在怎么样”

例如：

“上次那个发布任务最后失败在哪？现在恢复了吗？”
“你之前说截图里有两个仓库名，现在那个页面还是这样吗？”

这种时候先查档案确定过去，再重探确认现在，才不会把两个时间点混掉。

2. 档案说明结果可能已经过期

比如档案里显示：

某条任务当时是 reviewing；
某平台当时登录失效；
某任务 24 小时后再重试。

这类信息天然会变，所以回答时可以先说清档案里的历史结论，再补一句“如果你要，我现在可以继续查当前状态”。

3. 用户明确要求继续动作

如果用户不是在问“上次”，而是在说：

“按上次那个失败点继续做”；
“你现在就去重新检查”；
“把上次停住的那一步接着跑完”；

那查档案就是为了给续跑找锚点，而不是为了停留在只读层。

一个简单判断：该先查档，还是先重探？

可以直接问自己 5 个问题：

用户问的是过去执行细节，还是当前现场状态？
这个答案理论上是否已经存在于某次 run 的档案里？
如果我现在重探，会不会改变现场或制造重复动作？
我当前拿到的是历史问题，还是需要最新观测值的问题？
如果不先读档，我会不会把“现在”误说成“上次”？

如果其中 3 个以上答案都指向历史执行，那默认应该先查运行档案。

常见问题

FAQ 1：查运行档案会不会比直接重探更慢？

不一定。对于“上次到底做了什么”这类问题，档案通常反而更快，因为答案已经在那里。重探更慢，而且可能答偏问题。

FAQ 2：聊天记录里不是也有摘要吗，为什么还要专门查运行档案？

因为摘要通常不够细。聊天记录更适合看结论和交流过程；运行档案更适合看命令、文件、错误、产物和时间线。

FAQ 3：什么时候不该停在查档，而该继续重探？

当用户明确要当前状态、当前环境已经可能变化，或者下一步就是基于上次失败点继续执行时，查档之后应该继续重探或续跑。

FAQ 4：GoWork 在这里最大的价值是什么？

不是“把更多日志塞给模型”，而是把聊天、任务、运行档案和后续动作分层，让助理先回答历史事实，再决定当前动作。这会让它更像一个会复盘的同事，而不是一个边猜边重试的输入框。

如果你已经遇到过：用户明明在问“上次到底发生了什么”，系统却直接又去碰线上环境、重跑桌面动作，最后还没答到点子上，那你缺的通常不是更会说话的模型，而是一条“先查档、再行动”的执行原则。想继续看 GoWork 怎样把这条链做完整，可以接着读为什么 AI 助理应该在聊天里回答“任务到哪了”、失败后别重来：让 AI 助理从上次进度继续，以及 GoWork 下载页。