企业官网建设流程全解析

聊天渠道上下文和运行上下文有什么区别？执行型 AI 助理一定要分开看

很多团队把 AI 接进钉钉、飞书、Telegram 或网页会话之后，都会默认把“上下文”理解成同一件事：助理就在聊天里，那它执行任务时拿到的上下文，不就是这段聊天吗？

如果 AI 只是负责对话，这种理解问题不大；但如果 AI 要真正执行任务，这就是一个会不断出错的前提。聊天渠道上下文，和运行上下文，是两层必须分开管理的东西。

前者解决“它在和谁、在哪个入口协作”；后者解决“它这一轮到底绑定了哪条任务、哪些状态和哪些执行边界”。这也是 GoWork 这类执行型 AI 助理，和普通聊天机器人的关键差别之一。

一句话结论：聊天上下文对人，运行上下文对事

可以这样记：

• 聊天渠道上下文：回答“谁在当前会话里说了什么，结果该回到哪里”；
• 运行上下文：回答“这次执行绑定的是哪条任务、做到哪一步、哪些事实已经成立”。

很多系统会把两层混掉，是因为只做问答时，聊天记录常常已经够用。但当 AI 开始执行任务，聊天文本就不再等于全部真相。

聊天渠道上下文，主要处理 3 件事

1. 识别当前会话和入口

比如：

• 当前是网页会话，还是钉钉 / 飞书 / Telegram；
• 当前 conversation 是哪个；
• 这条消息来自用户实时输入，还是任务结果回投。

这决定了系统该把谁的话视为同一条线程，也决定了结果默认回到哪里。

2. 解析聊天里的自然指代

真实协作里，用户很少每次都说完整对象，更常见的是：

• “刚才那个任务呢？”
• “继续上面的。”
• “这里的提醒是发到当前会话吗？”

这类表达首先依赖聊天上下文去做指代解析。

3. 理解渠道本身的交互限制

不同渠道支持的能力不同：

• Web 会话可以渲染结构化表单；
• IM 渠道通常只能用自然语言追问；
• 定时任务专属沙箱会话会自动投递最终结果；
• 有些渠道支持图片，有些不支持。

这些都属于“在这个入口里怎么协作”的问题。

运行上下文，主要处理 4 件事

1. 确认这次执行绑定了哪条任务

运行上下文会告诉系统：

• 本轮是不是由定时任务唤醒；
• 当前 task run / assistant run 的 ID 是什么；
• 这是一次新执行，还是延续上轮；
• 当前计划推进到了哪一步。

没有这层信息，系统只能理解语言，不能确认执行现场。

2. 确认哪些事实已经成立

执行型 AI 不能靠“我记得刚才做过”继续，而必须基于事实：

• 哪些文件已经读过；
• 哪个命令已经跑过，输出了什么；
• 哪个任务 ID 已经拿到；
• 哪些错误是真实工具报错，哪些只是推测。

这些事实未必都直接出现在聊天记录里，但会直接影响下一步是否安全。

3. 确认当前做到哪一步、哪些结果已验证

这是运行上下文最关键的一层。

一个成熟的执行系统必须区分：

• 哪一步正在执行；
• 哪一步已经完成；
• 哪一步已经验证；
• 哪些结果还不能被后续步骤直接依赖。

否则用户说“继续刚才那个”，系统根本不知道应该从哪里接。

4. 确认本轮环境和权限边界

例如：

• 当前工作目录在哪里；
• 用的是哪台主机、哪个 shell；
• auto-approve 是否开启；
• 当前是否已预授权正式发布；
• 有没有别的任务正在占用关键资源。

这些信息不是聊天语义，但直接决定这轮执行能不能继续、要不要问、该怎么核验。

为什么“继续刚才那个”最能暴露差别？

假设用户只说一句：“继续刚才那个。”

如果系统只有聊天渠道上下文，它最多能知道：

• 这句话来自当前会话；
• 用户大概率指的是最近提过的某个任务；
• 这是延续语气，不是新开需求。

但它仍然不知道：

• 那个任务现在是 running、waiting 还是 failed；
• 上次到底卡在哪一步；
• 有没有已验证的结果可以复用；
• 现在应该继续执行，还是先汇报状态。

反过来，如果只有运行上下文，系统可能知道当前有多条未完成任务，却仍然不知道用户说的“刚才那个”究竟是哪一个。

所以这类高频表达，本质上依赖两层上下文一起工作：

1. 聊天上下文先做语言指代；
2. 运行上下文再把指代落到真实任务状态和可继续位置。

为什么定时任务更依赖两层分开？

因为定时任务往往不是在用户发消息时启动的。

以一个每天 8 点触发的内容流水线任务为例：

• 它运行在任务专属的沙箱会话里；
• 用户并没有实时输入消息；
• 但系统仍然要知道结果该投递到哪个通知目标；
• 同时，这一轮又带着明确的任务 ID、重复方式和执行约束。

这类信息显然不只是聊天记录能自然推出的，它属于运行上下文；而最后结果能准确回到用户所在入口，又离不开聊天渠道上下文。

把两层上下文混掉，最容易出现 3 类错误

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

用户只是问“到哪了”，系统却因为只抓到了聊天里的动作词，又重跑了一遍桌面操作或发布流程。

2. 把一个任务的状态答成另一个任务的状态

并行任务一多，这种问题会非常常见。主题相似时，只靠最近对话猜，很容易答错对象。

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

比如本轮明明已经被预授权正式发布，系统却反复要求确认；或者反过来，本轮没有授权，却因为聊天里出现过类似表述就直接对外操作。

一个实用判断：什么时候优先看哪一层？

优先看聊天渠道上下文

当问题核心是“用户现在在说哪件事”时：

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

优先看运行上下文

当问题核心是“这轮执行到底站在哪个现场”时：

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

常见问题

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

两者相关，但不能等同。聊天上下文主要描述“谁在说、在哪个入口、刚才表达了什么”；运行上下文主要描述“本轮任务是谁、做到哪、哪些已验证事实成立”。

2. 为什么只保留聊天记录不够？

因为聊天记录主要解决语言理解，不足以单独承载任务状态、工具结果、计划步骤、验证节点和权限边界。一旦 AI 真正开始执行任务，仅靠聊天文本很容易答错状态或做错动作。

3. 哪些场景最容易暴露差别？

并行任务、定时任务、失败续跑，以及“继续刚才那个”“上次那个发布怎么样了”这类指代型请求，最容易暴露两层上下文的边界。

本文首发于 OmniGoAI 官网：https://omnigoai.com/zh/blog/gowork-channel-vs-runtime-context/ ——OmniPost，把内容一键分发到 30+ 平台。