原截图为什么该先 view_image

当用户说“你看一下刚才那张截图”“按上一次的截图继续”时，正确动作通常不是再截一张，而是先 view_image 回看原图。原因很简单：新截图记录的是现在，原截图记录的是当时。如果你把“当前状态”误当成“历史证据”，排障、回溯、审批判断都可能跑偏。对 GoWork 这类在聊天里持续执行任务的助理来说，view_image 不是可有可无的附件查看器，而是保住上下文真实性的关键一步。

更直接地说：用户让你看“原来的截图”，通常是在让你回答一个关于过去时刻的问题，而不是让你重新观察当前页面。此时先读原图，才能保证后续判断基于同一份证据，而不是被后来变化的界面、弹窗、网络状态或滚动位置误导。

在 GoWork 的桌面任务里，这个区别尤其重要。因为很多界面都是会变的：倒计时会跳动，通知会消失，按钮会换状态，列表会自动刷新，甚至同一个窗口一分钟后就不是原来的内容了。GoWork 的价值之一，就是在这种多轮协作里保留任务过程和证据链，而不是每轮都把现场重新覆盖掉。

为什么新截图不能替代旧截图

先重新截图，看起来像“信息更新了”，但它并不能回答用户关于原图的问题。典型风险有三个：

1. 证据时点变了：用户问的是“刚才那个报错写了什么”，而你重截时报错框已经消失。
2. 画面位置变了：窗口可能被拖动、滚动、切页，新的截图已经不是同一视角。
3. 状态被后续动作改写：你或别的任务可能已经点击过按钮，导致页面进入新状态。

所以，只要问题里带有“原来的”“刚才那张”“上一次的”“历史截图”这类指向词，优先回看原图，通常比重新观察当前桌面更可靠。

view_image 适合解决哪些问题

view_image 最适合处理三类场景。

1. 历史取证

用户要你判断某一时刻屏幕上到底出现过什么内容，比如错误文案、审批弹窗、金额、订单号、下载按钮是否存在。这类问题的核心不是“现在屏幕怎样”，而是“当时截图里怎样”。

2. 多轮任务续跑

长任务被打断后，下一轮经常只留下“继续看上面的截图”“按刚才那个报错处理”。这时先回看原图，可以把上一轮已捕获的信息重新带回上下文，而不是盲目重试同一操作。类似地，GoWork 在回答“任务到哪了”或“刚才失败在哪里”时，也应优先利用既有证据与任务历史。这个思路和我们在另一篇文章里讲的任务续跑原则一致：不要把失败后的重来，当成对真实进度的尊重。相关背景可参考：https://omnigoai.com/zh/blog/gowork-follow-up-after-failure/ 。

3. 向用户解释判断依据

如果你要说“我看到这里有 4031 限频”“我看到按钮是灰的”“我看到标题已经改了”，最好能明确这些判断来自哪一张图。先 view_image 再描述，能让你的结论更可追溯，也更容易被用户信任。

什么情况下应该重新截图

这并不意味着新截图永远不该拍。正确顺序通常是：

1. 先看原图，确认历史证据；
2. 再判断是否需要新截图补充当前状态。

以下情况适合补一张新图：

• 用户明确问“现在变成什么样了”；
• 你已经从原图定位出问题，接下来要验证是否修复；
• 原图分辨率不够、关键区域被遮挡，需要新截图补充观察；
• 用户同时关心“当时是什么”和“现在变成什么”。

关键不是能不能重截，而是不要让新截图抢走原图的角色。

在桌面自动化里，为什么这一步会影响后续动作

很多桌面任务不仅要“看图”，还要据此继续点击、输入或判断下一步。如果你没先确认原图里的信息，就直接操作当前界面，常见后果包括：

• 对已经变化的窗口做错误点击；
• 把一次偶发弹窗误判成稳定问题，或反过来漏掉瞬时异常；
• 在用户问责时拿不出“你当时到底看到了什么”的依据；
• 把原本可以靠历史截图回答的问题，错误升级成重新探测现场的问题。

这也是为什么 GoWork 在处理多步任务时，需要把计划、运行历史和证据保留下来，而不只是记一个模糊摘要。否则一旦界面变化，助理就只能靠猜。关于多步任务为什么要保留结构化计划，也可以参考：https://omnigoai.com/zh/blog/gowork-update-plan-cross-run-persistence/ 。

一个实用判断法：先问自己“用户问的是过去还是现在”

如果你不确定该不该先 view_image，可以用一个很简单的判断法：

• 用户问的是过去那个时刻发生了什么 → 先 view_image
• 用户问的是现在当前界面是什么状态 → 先重新观察或截图
• 两者都问了 → 先 view_image，再补新截图

这个顺序能减少很多“证据错位”的低级错误。尤其在定时任务、排障回溯、审批核验这类场景里，回答错时点，往往比回答少一点信息更危险。

给 agent 设计流程时，应该把 view_image 放在哪一步

一个更稳的流程通常是：

1. 识别用户是否在指代已有截图；
2. 若是，先读取原图并转写关键文字；
3. 基于原图给出判断或决定下一步；
4. 只有在需要确认当前状态时，再截新图。

这里“转写关键文字”也很重要。因为截图本身未必会在后续每一轮都自动保留到上下文里，但你从图里读出的报错码、按钮文案、时间戳、账号名，往往才是后续判断真正依赖的事实。

常见问题

用户说“看刚才那个截图”时，能不能直接重截一张更清楚的？

不建议直接替代。你可以在看完原图后，再补一张更清楚的新图，但不能把新图当成原图的证据。否则你回答的就不再是用户的问题。

如果原图里的信息已经过时了，还有必要看吗？

有。即使它已经过时，它仍然是解释“为什么当时做出那个判断”的证据。很多排障问题需要同时知道“当时看到什么”和“现在变成什么”。

view_image 和重新截图可以一起用吗？

可以，而且很多时候就该一起用。顺序上先回看历史图，再决定是否拍新图，通常最稳。

这种做法只适用于桌面任务吗？

不只适用于桌面任务。凡是涉及历史截图、运行回溯、审批留痕、用户指代“上一个证据”的场景，都适用这个原则。

如果你在做桌面自动化、任务回溯或多轮排障，GoWork 更适合的做法不是“每次都重新看现场”，而是把历史证据、计划和执行过程一起保留下来，再决定下一步。你可以从 OmniGoAI 官网下载 GoWork：https://omnigoai.com/zh/download/gowork/ 。