聊天渠道上下文和运行上下文有什么区别

很多团队第一次把 AI 接进钉钉、飞书、Telegram 或网页会话时，直觉上会把“上下文”当成一回事：既然助理就在这个聊天里，那它执行任务时拿到的上下文，不就是这段聊天本身吗？ 实际上并不是。对一个真正要做事的 AI 助理来说，至少有两层上下文必须分开看：聊天渠道上下文（chat/channel context） 和 运行上下文（runtime context）。

这也是 OmniGoAI 的 GoWork 在设计上特别强调的一点。GoWork 不只是把模型挂到某个聊天入口，而是把会话、任务、运行记录和工具执行拆成不同层，再在需要时重新连起来。如果你把聊天上下文和运行上下文混在一起，轻则答非所问，重则会把状态查错、任务接错、甚至在错误的任务上继续执行。

如果你已经看过为什么 AI 助理应该在聊天里回答“任务到哪了” 和失败后别重来：让 AI 助理从上次进度继续，这篇文章会补上一个更底层、但更决定系统是否靠谱的问题：聊天里的“你刚才说过什么”，和执行时的“我这次到底带着哪些状态在做事”，到底差在哪里？

先说结论：聊天上下文负责“对上人”，运行上下文负责“对上事”

最短的定义可以这样记：

聊天渠道上下文：回答“这句话是谁、在哪个会话、以什么入口发给我的”；
运行上下文：回答“我这一轮执行，绑定的是哪条任务、哪些工具结果、哪些中间状态和哪些可继续的记录”。

前者偏向沟通入口，后者偏向执行现场。两者会相互关联，但绝不能简单视为同一份数据。

如果只保留聊天上下文，助理通常能做到这些事：

记住你们刚才在聊什么；
识别这是钉钉、飞书还是网页会话；
理解“刚才那个”“这个聊天里那个任务”这类指代；
决定结果该回到哪个会话里。

但只有运行上下文，系统才能进一步知道：

本轮是用户手动触发，还是定时任务唤醒；
现在绑定的是哪一个任务 ID、哪一个执行轮次；
上一阶段已经做完并验证了什么；
哪些工具输出、本地文件、运行档案是本轮能直接依赖的；
这次回复应该继续执行、只汇报状态，还是等待澄清。

所以，聊天上下文决定“往哪说”，运行上下文决定“按什么事实做”。

为什么很多 AI 产品会把这两层混掉？

因为对只会对话的机器人来说，聊天记录往往已经够用。

如果系统的主要职责只是回答问题、总结消息、生成文案，那么把最近几轮对话拼起来丢给模型，往往就能工作得还不错。问题在于，一旦 AI 开始执行任务，聊天文本就不再覆盖全部真相。

举几个常见场景：

你在聊天里说“帮我继续刚才那个发布任务”；
系统后台还有一个定时巡检任务刚刚被唤醒；
另一个长任务昨天失败在第 5 步，今天准备续跑；
当前会话里最近其实有两个相似主题的任务都在运行过。

只看聊天记录，模型很可能知道你提到了“发布任务”，却不知道你究竟指的是哪条任务记录、上次失败卡在哪、当前还有没有别的运行在占资源。这正是聊天上下文的边界：它擅长理解语言，不足以单独定义执行现实。

什么算“聊天渠道上下文”？

聊天渠道上下文最核心的是“人和入口”。它通常至少包含下面几类信息：

1. 会话身份

例如：

当前 conversation ID 是什么；
这是网页会话、钉钉、飞书还是 Telegram；
这是当前会话里的提问，还是别的会话被动投递回来的结果。

这类信息决定了助理该把谁的话视为同一条对话线程，也决定了结果回传的默认落点。

2. 最近对话语义

例如：

用户刚才是在问状态，还是在下新指令；
“刚才那个”“继续上面的”具体在指什么；
这轮提到的对象是当前聊天里的任务，还是历史任务。

这是会话协作的基础，没有它，系统就很难把自然语言映射到正确对象。

3. 渠道约束

不同入口还有不同能力边界。例如：

Web 会话能渲染结构化表单；
IM 渠道可能只能发纯文本，不能回表单；
定时任务专属沙箱会话里，结果会自动投递，不能再额外调用外发通道；
某些渠道支持图片，某些不支持。

这些都是“在这个入口里怎么协作”的问题，依然属于聊天渠道上下文。

什么算“运行上下文”？

运行上下文的核心不是“刚才说了什么”，而是“这一次执行站在哪个现场”。

1. 当前绑定的任务与轮次

运行上下文会回答：

本轮是否由某个 scheduled task 唤醒；
当前 assistant run / task run 的 ID 是什么；
这是一次新执行，还是延续上个阶段；
这次应该继续已有计划，还是从头开始。

这决定了助理是在普通对话，还是在一条已有任务链的某个节点里工作。

2. 已产生的工具事实

真正的执行不是靠“我记得刚才好像看过”推进的，而是靠当前可依赖的事实推进。比如：

本轮已经读取过哪些文件；
哪个 shell 命令已经执行并返回了什么；
哪个定时任务 ID 已经给出；
哪些失败是实际工具报错，哪些只是猜测。

这些内容很多不会自然地完整出现在聊天文本里，但却直接影响下一步能不能安全继续。

3. 计划、步骤状态与验证节点

运行上下文还应该知道：

当前计划一共有几步；
哪一步 in_progress，哪一步 verified；
哪些结果已完成但未验证，不能直接作为后续依赖；
如果本轮被截断，下次该从哪里续跑。

这正是执行型 AI 和“会聊天的模型”拉开差距的地方。聊天上下文知道你们在聊什么，运行上下文知道事情做到哪了。

4. 本轮的环境与权限边界

例如：

当前工作目录在哪里；
使用的是哪台主机、哪个 shell；
auto-approve 是否开启；
哪些资源正被别的任务占用；
这次是否已经预授权正式发布或其他高影响动作。

这些信息不是对话语义，却决定了这次执行能不能直接做、该不该问、该怎么验证。

一个简单例子：同一句“继续刚才那个”，为什么两层上下文缺一不可？

假设用户在聊天里说：“继续刚才那个。”

如果只有聊天渠道上下文，系统也许能知道：

这句话来自当前会话；
用户大概率指的是最近提到的某个任务；
这不是在闲聊，而像是在延续之前的话题。

但如果没有运行上下文，系统仍然缺几个关键事实：

最近那个任务到底是 completed、failed 还是 waiting；
它上次卡在哪一步；
有没有可直接复用的运行档案；
现在应该“继续执行”，还是先汇报现状；
当前会话最近是否同时收到了多个任务通知。

反过来，如果只有运行上下文、没有聊天渠道上下文，系统也会出问题：它可能知道有三个未完成任务，却不知道用户现在说的“刚才那个”指的是哪一个，也不知道结果应该回到哪个聊天入口里。

所以这类高频指令，本质上依赖两层映射同时成立：

聊天上下文负责把语言指代到候选对象；
运行上下文负责在候选对象里确定真实可继续的位置。

为什么定时任务最能暴露这两个概念的差别？

因为定时任务经常不是在用户当前发言时启动的。

比如每天 8 点，一个内容流水线任务被唤醒。此时：

它可能运行在一个专属的任务沙箱会话里；
用户并没有实时发消息，但系统仍要知道结果该回投到哪个通知目标；
本轮有明确的任务 ID、重复方式、历史记录和停止规则；
这轮执行还带着“不要再外发消息、最终回复会自动投递”的专门约束。

这些约束明显不是普通聊天记录里能自然推断出来的，它们属于运行上下文。但最后产物又必须准确地回到用户所在的聊天渠道，这又依赖聊天渠道上下文。

也就是说，定时任务的可用性，本质上建立在“后台运行上下文”和“前台会话上下文”被正确桥接。

为什么说把两层上下文混掉，最容易导致三类错误？

1. 把状态问询误当成重新执行

用户只是问“到哪了”，系统却因为只看聊天里的动作词，直接又跑了一遍桌面操作或发布流程。这通常是因为它理解了对话语义，却没有读取当前运行上下文里的真实状态。

2. 把一个任务的运行事实答到另一个任务上

尤其在并行任务里，这个问题特别常见。聊天里提到的主题相似，模型如果只靠最近对话猜，很容易把 A 任务的状态讲成 B 任务的状态。

3. 在错误的权限边界上继续动作

例如，本轮明明已经被预授权正式发布，系统却反复要求确认；或者反过来，本轮并没有发布授权，却因为聊天里有过类似说法就直接对外操作。这类问题往往来自没有把“这一轮执行的授权边界”单独放在运行上下文里管理。

一个实用判断：什么时候该优先看聊天上下文，什么时候该优先看运行上下文？

可以用一个很简单的经验法则：

先看聊天上下文的情况

当问题主要是“用户现在在说哪件事、想表达什么”时，先看聊天上下文，例如：

“刚才那个任务呢？”
“这里的提醒是发到当前会话吗？”
“你说的上面那个，是指哪个任务？”
“这个渠道能不能发图片？”

先看运行上下文的情况

当问题主要是“这次执行到底站在哪个现场、该依据什么事实继续”时，先看运行上下文，例如：

“上次失败卡在哪一步？”
“这个定时任务要不要取消？”
“现在还能不能继续发布？”
“这轮是不是已经预授权正式发布？”
“刚才这个任务为什么没通知我？”

真正可靠的系统不是二选一，而是知道先用哪一层定界，再让另一层补全。

为什么执行型 AI 必须把两层上下文分层设计？

因为只有分层，系统才不会在三个方向上同时失真：

对人失真：不知道谁在说、结果该回给谁；
对事失真：不知道当前任务到底做到哪了；
对边界失真：不知道这轮是否允许继续、停止或对外动作。

而一个真正能协作的 AI 助理，必须同时满足这三点：

在聊天里听得懂；
在执行时对得上真实任务；
在回传时回得对地方、说得对状态。

这也是为什么 GoWork 这类系统更像“聊天入口 + 任务系统 + 运行档案 + 调度器”的组合，而不是单纯给聊天机器人多塞一点历史消息。

常见问题

FAQ 1：聊天上下文不就是运行上下文的一部分吗？

可以相关，但不能等同。聊天上下文更多描述“谁、在哪个入口、刚才说了什么”；运行上下文更多描述“本轮任务是谁、做到哪里、带着哪些已验证事实继续”。执行型系统通常要把两者显式分层。

FAQ 2：为什么只保留聊天记录还不够？

因为聊天记录主要解决语言理解，不足以单独承载任务状态、运行档案、工具结果、权限边界和续跑锚点。任务一旦进入执行阶段，仅靠聊天文本很容易答错状态或做错动作。

FAQ 3：什么时候最容易暴露两种上下文的区别？

并行任务、定时任务、失败续跑、以及“继续刚才那个”“上次那个发布怎么样了”这类指代型请求，最容易暴露差别。因为这些场景既依赖会话指代，又依赖真实运行状态。

FAQ 4：GoWork 在这里最大的不同是什么？

不是简单“记住更多聊天内容”，而是把会话、任务、运行和交付分层管理，再在需要时重新连起来。所以它更有机会既听懂用户现在在说什么，也知道这次执行真正站在哪个现场。

如果你已经发现：团队最难处理的问题不再是“模型会不会回答”，而是“它到底在替谁处理哪条任务、做到哪一步、结果该回哪儿”，那你需要的就不是单一上下文的聊天机器人，而是一套把聊天渠道上下文和运行上下文都当成一等公民的执行系统。想继续往下看，可以接着读为什么 AI 助理应该在聊天里回答“任务到哪了”、失败后别重来：让 AI 助理从上次进度继续和 GoWork 下载页。