为什么任务状态不能只看会话摘要

先说结论：会话摘要只能回答“这段对话大致在做什么”，不能单独回答“这条任务现在真实做到哪一步”。 在执行型 AI 助理里，真正可靠的状态判断至少要同时看四层信息：runtime 当前状态、recent events、等待原因，以及最近一次已经落地的执行证据。只看 conversation summary，最容易把“上一次讲过的话”误当成“此刻仍然成立的执行事实”。

这也是 OmniGoAI 的 GoWork 为什么把会话层、运行层和任务层拆开。GoWork 不是普通聊天机器人；它既要回消息，也要真的执行任务。一旦系统既要聊天、又要排队、又要跑桌面和定时任务，状态就不可能只靠一个摘要字段来表达。 你需要知道：当前有没有 active run，它是在 running、queued、waiting 还是 done；最近两三步到底做到了什么；如果停住，是在等用户、等审批、等资源，还是外部系统没响应。

如果你已经看过用户只问“现在到哪了”时，为什么不该重跑任务、长任务为什么要分轮续跑和用户问上次到底做了什么时，为什么应该先查运行档案而不是重探线上系统，这篇文章继续回答一个更底层、也更容易被误判的问题：为什么任务状态不能只看 conversation summary，runtime 状态、recent events 和真实执行之间到底是什么关系？

先记住一句话：摘要是导航，不是判决书

最实用的判断方式是：

1. conversation summary 负责告诉你“这个会话最近围绕什么主题”；
2. runtime status 负责告诉你“当前执行有没有在跑、卡住还是结束”；
3. recent events 负责告诉你“最近几步具体发生了什么”；
4. 执行证据负责回答“哪些结果已经真的落地”。

这四层缺一不可，但它们的职责完全不同。会话摘要适合帮系统找上下文，不适合单独拿来判断执行真相。

为什么 conversation summary 不够？

因为它天然是压缩后的聊天视角，而不是逐步更新的执行事实。

会话摘要通常擅长保留这些信息：

• 这段对话的目标大概是什么；
• 最近提到过哪些任务或对象；
• 当前有没有一个主线主题；
• 用户和 assistant 最后一次大致聊到哪里。

这些信息对于“理解上下文”很有用，但它回答不了下面这些更关键的问题：

• 当前 run 还在不在跑；
• 最后一个成功步骤是什么；
• 现在是 waiting on user、waiting on approval 还是 waiting on resource；
• 刚才那条错误是不是已经被后续重试覆盖；
• 这个结果是口头计划，还是已经真的执行完。

换句话说，conversation summary 更像目录页，不像流水账，更不像证据链。

runtime 状态回答的，是“任务生命体征”

如果说会话摘要像导航栏，那 runtime 状态更像监护仪。

它最核心的价值，不是复述任务内容，而是告诉你：

1. 当前有没有活跃执行；
2. 这条执行是 queued、running、waiting、completed 还是 failed；
3. 是否存在 pending approval、pending clarification 或外部阻塞；
4. 当前这轮执行属于哪个 run / task / session。

这层信息很重要，因为很多误判都发生在这里：

• conversation summary 还在说“正在发布”，但 run 其实早就 failed；
• 摘要里看起来像“还没开始”，但任务其实已经 queued，正在等桌面资源；
• 用户以为 assistant 卡住了，实际上系统正在等他的澄清或审批；
• 一段旧摘要还在描述上一轮状态，但这一轮已经被 continuation 接力到新阶段。

所以当用户问“现在到哪了”时，第一件事通常不是读会话摘要，而是先确认 runtime 的真实生命体征。

recent events 回答的，是“最近两三步到底发生了什么”

runtime 状态能告诉你“活着没有”，但不一定告诉你“刚才做了什么”。这时 recent events 才是最贴近现场的一层。

recent events 通常会暴露出：

• 最近完成了哪一步；
• 当前步骤的标题或摘要；
• 最后一条用户可见进展；
• 最近一次错误、重试、跳过或等待；
• 任务为什么停在这里。

例如，单看状态你可能只知道：

• running
• waiting
• queued

但 recent events 往往能把它翻译成用户听得懂的话：

1. 中文稿和英文稿已经写完；
2. npm run build 还在跑；
3. 官网部署已完成，现在在提交 IndexNow；
4. 桌面资源正被另一条 run 占用，所以 OmniPost 发布排队中；
5. 正在等用户补平台登录。

状态枚举是骨架，recent events 才是肌肉。 没有 recent events，你知道任务“还活着”；有了 recent events，你才知道它活得怎么样。

真实执行证据解决的是最后一跳：结果到底有没有落地

再往下一层，就是证据。

执行系统里最危险的误判，不是完全不知道，而是把下面这些状态误当成“已经完成”：

• 说了“下一步会部署”，但还没部署；
• 命令启动了，但产物还没验证；
• 平台返回 success，但公开链接还没拿到；
• 桌面点过按钮了，但页面其实还停留在草稿态；
• 摘要里写了“已完成”，但对应文件、commit、recordId 或页面状态根本没核验。

所以真实状态判断最后一定要落到证据层，例如：

• 目标文件确实存在；
• 构建产物确实生成；
• 命令日志明确 exit 0；
• 公开 URL 可访问；
• 任务记录里确实出现了本轮的 recordId、commit hash 或 run history。

这也是为什么 GoWork 强调：不要用一句摘要去替代已经存在的执行证据。 摘要可以概括结果，但不能代替结果本身。

一个典型误判：把“最近聊到哪”当成“任务做到哪”

这类错非常常见，尤其在长任务或多轮任务里。

比如用户上一轮和 assistant 聊到：

1. 准备部署官网；
2. 随后发布到四个平台；
3. 最后更新日志并提交 Git。

如果你只看 conversation summary，很可能会觉得“当前任务在部署阶段”。

但真实情况可能是：

• 部署已经完成，现在 actually 在等 OmniPost；
• 官网和收录都做完了，卡在平台登录；
• 部署失败了，后续步骤根本没开始；
• 上一轮只是在计划这些步骤，这一轮还没真正执行。

summary 记住的是谈话中的主线，不是每一步是否真的发生过。 这也是它不能单独当执行状态来源的根本原因。

为什么长任务里 summary 更容易失真？

因为长任务天然会跨阶段，而摘要会倾向于保留“高层主题”，丢掉“阶段边界”。

一条长任务往往会经历：

1. 理解需求；
2. 制定计划；
3. 执行前半段；
4. 遇到错误并修复；
5. continuation 交接；
6. 执行后半段；
7. 总结结果。

对于这种任务，conversation summary 往往保留下来的，是“这是一次内容发布任务”或“这是一次桌面排障任务”。但用户问的不是主题，而是：

• 现在是不是已经进入第 5 步；
• 哪些东西已经 verified；
• 是否还在等待我；
• 这个 run 是不是已经切到下一轮 continuation。

这些信息都属于执行阶段事实，不属于聊天主题摘要。

为什么 recent events 比 summary 更适合回答“刚才做到哪了”？

因为 recent events 天生就是按时间顺序贴近当前状态的。

当用户问“现在到哪了”“刚才那个跑得怎么样”“还差哪一步”时，真正需要的是近因，而不是总览。recent events 的优势有四个：

1. 更近：它离当前状态更近，不容易把旧上下文误当现状；
2. 更细：它能说明最近完成了什么、还没做什么；
3. 更安全：它通常是只读的，不会为了查状态而重新触发工具；
4. 更可解释：它能直接组织成用户能理解的进度播报。

这也是为什么在 GoWork 里，状态查询通常先看 recent events，而不是先去重跑命令、重开页面或者只看 summary 字段。

什么时候 summary 仍然有价值？

有，而且很重要。只是它不该被误用。

conversation summary 在这些场景特别有用：

1. 快速恢复对话主题

例如系统刚接到一条新消息，需要先知道：这段对话是围绕内容流水线、桌面安装，还是定时提醒展开的。此时摘要很高效。

2. 给用户一个高层回顾

例如“这段时间我们主要在做官网发布和 OmniPost 分发闭环”，这种高层概括适合摘要，不适合 recent events。

3. 帮系统选择下一步该读哪一层证据

如果摘要表明当前对话主线是“内容流水线”，系统就知道下一步该去看 active run、recent events、构建日志和发布记录，而不是去查完全无关的页面。

所以 summary 不是没用，而是它的用途是定向，不是定案。

一个更可靠的状态判断顺序

如果你要设计或使用执行型 AI 助理，下面这个顺序最稳：

1. 先看 runtime 状态：有没有 active run，当前是 running、queued、waiting 还是 done；
2. 再看 recent events：最近完成了哪一步，为什么停在这里；
3. 再看等待原因和挂起项：是不是在等审批、澄清、资源或用户输入；
4. 最后按需下钻到证据层：日志、文件、页面、run history、recordId、commit。

conversation summary 可以放在最前面做方向感，但不能替代上面四步。最危险的做法恰恰是：

1. 只看 summary；
2. 直接给用户下结论；
3. 甚至顺手再触发一次动作去“验证”。

这样既容易答错，也容易带来多余副作用。

在并发任务里，为什么只看 summary 更危险？

因为一个会话里可能同时存在多个 run，而 summary 往往只保留“主线印象”。

比如当前会话可能同时发生：

• 一条桌面安装任务正在 running；
• 一条代码修复任务刚刚 completed；
• 一条状态查询消息刚刚插进来；
• 另一条定时任务还在后台等待下一次触发。

这时如果只看 summary，很容易把“最近聊得最多的那个任务”当成“当前正在执行的那个任务”。而 runtime / recent events 至少能帮助你区分：

• 哪条 run 还活着；
• 哪条 run 已经结束；
• 用户这句追问到底指向哪个最近活跃对象；
• 当前是否有资源冲突或等待原因。

并发一出现，summary 的压缩优势就会迅速变成歧义来源。

最后落地成一句规则

如果用户问的是“现在到哪了”，不要把答案建立在 conversation summary 一层上。

更稳的做法是：

1. 用 summary 快速确认上下文主题；
2. 用 runtime status 判断执行生命体征；
3. 用 recent events 还原最近进展；
4. 用证据层核实关键结果是否落地。

对于执行型 AI 来说，summary 负责“知道在聊什么”，runtime 和 events 负责“知道正在发生什么”，证据层负责“知道什么已经真的发生过”。 把这三层混成一层，用户看到的就不再是状态，而是猜测。

常见问题

1. conversation summary 完全没用吗？

不是。它对恢复上下文、识别主线主题、生成高层回顾都很有价值。问题不在于 summary 没用，而在于把它错当成实时状态真相。

2. 用户只问一句“到哪了”，最先该看什么？

通常先看 active run 的 runtime 状态和 recent events。因为用户要的是当前进度，而不是整段会话的主题概括。

3. recent events 和运行档案有什么区别？

recent events 更偏“现在和刚才”，适合回答当前进度；运行档案更偏“完整历史”，适合用户追问上次到底做了什么、哪一步怎么失败的。

4. 什么时候需要下钻到证据层？

当你要确认某个关键结果是否真的落地时，比如文件是否生成、页面是否已发布、命令是否 exit 0、commit hash 是否存在。这些都不能只靠摘要或状态枚举判断。

5. 为什么这和产品信任直接相关？

因为用户能明显感受到你是在汇报真实状态，还是在根据摘要猜状态。前者让系统像一个可靠的执行助手，后者则会把“状态问答”变成一种不稳定的印象管理。

如果你正在搭建一个既能聊天、又能排队执行任务的 AI 助理，GoWork 的做法是把“会话理解”和“运行状态”明确拆开：先用 summary 找方向，再用 runtime、recent events 和真实证据给答案。想把这种模式接进钉钉、飞书、Telegram 或你自己的工作流，可以从 GoWork 开始：https://omnigoai.com/zh/download/gowork/