Grok Bot 架构解析：长期任务如何执行、恢复与交付

原创 yzddMr6 2026-09-07 09:04 浙江

用户把几份资料交给 Grok Bot，让它整理成报告，随后关掉了桌面应用。只要工作仍在使用云端能力，任务就可以继续。

这件事决定了系统的基本形态。负责推进任务的程序要留在云端，读到一半的资料、运行中的工具和已经形成的结果要有地方保存。桌面重新上线时，用户需要看到原来的进度，而不是重新提交一次请求。

Grok Bot 把这些职责放进了一台持久 Linux 云电脑。代码称它为 box，驻留其中的服务叫 Host。围绕这个运行主体，系统再处理上下文、工具、恢复和授权。它们怎样配合，比单独看某个模型循环更能解释这个产品。

分析基于 Grok Bot 0.18.0 的重建代码样本。业务例子用于说明机制；源码范围及需要保留的实现限制列在文末。

1. 任务留在云端

1.1 用户离线，工作仍有运行位置

资料整理会经历多次文件读取、模型推理和工具执行。浏览器可能还保留着一个下载页面，终端里有正在处理的数据。把执行放在用户桌面，就要面对设备休眠、应用退出和用户切换机器；把它放在云端，桌面便可以退回到查看和控制的位置。

Host 的部署入口位于云电脑内，Agent 的主要执行流程也在这里。后端提供推理、对象存储和托管连接器，桌面应用负责展示消息、处理用户操作，以及提供本机能力。

这个划分让云端工作可以脱离窗口存活。用户关闭应用，不会因此撤掉 Agent 正在使用的云端文件系统。代价是一次本来可以在本机完成的工作，被分布到多个位置：连接会断，状态需要同步，访问本机时还得经过反向请求。

因此，离线继续有一个具体范围。云电脑里的文件处理可以继续，访问用户电脑上的文件、请求本机认证器等操作，则需要可用的本机连接。前者得到稳定运行环境，后者保留用户设备的参与。

两类能力共存在同一个任务里，决定了它有时继续计算，有时停下来等待。

1.2 Agent 的寿命长于一次对话

Grok Bot 为 Agent 保存档案、记忆、自动化配置和对话记录。一轮工作结束，这个角色仍然存在。用户下次可以继续给它派活，后台事件也可以再次触发它。这使持久环境有了明确归属。整理报告留下的文件属于 Agent 的工作环境，定时任务知道该唤醒谁，历史记录也能沿稳定标识找回。如果所有资源只附着在一次临时调用上，新增定时检查、后台回复和跨会话记忆时，就需要反复解决“这些东西归谁管”。

当然，稳定身份本身不会让工作连续。运行时还必须保存足够的状态，让下一次执行接得上。Grok Bot 使用 Turn 表达一次执行轮次：它可能从用户消息开始，也可能由后台结果或自动化触发，内部再包含多次模型与工具调用。

以资料整理为例，用户要求生成报告，模型读取文件并调用脚本，是一个连续推进的过程。若后续要等外部结果，等待结束可以成为下一次输入。相同的执行入口由此服务多种触发源，提示词装配、工具选择和持久化便有了公共落点。

这也解释了为什么 Host 需要长期管理服务、任务和状态。它承担的是 Agent 的工作过程，桌面展示的是其中对用户有意义的部分。

2. 上下文与工具，按任务装配

把模型循环搬到云端，还不足以处理这些工作。模型每次推理时，需要知道当前任务、已有进度和可用能力；当它提出一个动作，系统又要决定到哪里执行、是否允许，以及结果怎样保存。

Grok Bot 将通用 Agent 引擎与 Host Runner 分开。引擎处理模型动作和会话状态，Runner 装配产品需要的环境、工具和回调。这个边界让宿主能够在模型提出动作与实际执行之间介入。

2.1 一次 Turn 连接引擎与产品

如果把审批逻辑分别写进文件工具、浏览器和连接器，每个工具都要理解用户是否改变了要求、当前有没有等待中的决定、执行结束后如何交付。规则很快会出现差异。

Runner 提供了共享这些约束的位置，各工具仍负责自己的参数和资源检查。资料读取、网页操作可以采用不同执行器，但不必各自重建一套任务生命周期。

一个 Turn 的主要推进关系如下，错误终止等分支由相应控制器处理。

这层装配也会带来复杂度。主 Agent、专用子 Agent、共享房间和自动化的条件不同，同一个引擎接入后仍要选择工具范围和交付规则。把产品规则集中起来，减少了重复实现，也让 Runner 成为需要重点检查组合条件的地方。

控制权在这里分开了：模型提出下一步，宿主保留执行前的检查机会。模型产生一次输出之后，动作仍要经过运行时才能落到真实环境。

2.2 提示词也有更新成本

资料整理刚开始时，模型需要任务要求、环境信息和文件位置。读完几份资料后，又会多出工具结果、阶段判断和用户补充。所有内容都保留在当前请求里，上下文很快会增长；每轮重新组织全部背景，则可能降低前缀缓存的复用。Grok Bot 为不同内容安排不同的装配方式。Host 组织角色、时区、记忆等产品背景，通用引擎另行组织工作区、规则和技能信息。相关提示词组件负责生成消息与结构标签，让不同内容能够按条件出现。

这种组织方式的好处，是更新责任更清楚。用户刚发来的补充需要及时进入上下文，角色档案却没必要因为多读了一份文件而重写。

在启用记忆和档案快照的相应路径里，同一个 Compaction Epoch，也就是上下文压缩代次内，已有快照可以复用；传入的代次变化时再重新生成。这是一种用背景信息的更新频率换取前缀稳定性的设计。

背景更新因此可以稍后发生。例如 Bot 刚把报表偏好写入记忆文件，这条信息已经保存，但系统提示里的记忆块未必立即重建。最新对话仍可带着这条偏好继续工作，背景快照则按自己的条件更新。保存记忆和重新装配提示词有了各自的时机。

对更长的任务，系统还需要压缩旧上下文。低频信息也可能影响后续工作：用户禁止修改的文件、尚未完成的计划，以及最初要求的准确措辞，都可能在概括时丢失。摘要机制因此保留计划、任务项、转录路径等继续工作的线索，相关提示词还要求保留用户的安全约束。

完整记录留在磁盘上，摘要负责帮助模型继续工作。

这给上下文窗口设定了合理职责。模型不必每轮重读所有资料，但遇到含糊的旧决定时，应沿记录回查；压缩出的几段文字无需承担永久保存全部事实的任务。

2.3 先收窄工具，再检查执行

上下文告诉模型现在处于什么环境，工具列表则告诉它可以选择哪些动作。

给每个角色同一张工具全集，接入时很方便。问题是模型会看见当前不可用的能力：云电脑尚未连接，Shell 仍摆在列表里；共享房间里有外部参与者，本机文件工具也同样可见。即便执行时最终被拒绝，模型仍可能为这些动作生成计划和参数。Grok Bot 在装配工具时读取 Runner 身份、资源可达性和策略，再过滤本轮能力。共享房间会经过额外白名单，Computer 和 Browser 则按专用子 Agent 类型开放。

共享房间是一个很直观的例子。其他参与者的内容会进入模型上下文，但这不构成用户允许访问自己电脑的新授权。把本机工具从该场景的可见列表里移除，可以提前减少越界选择，而不必每次等模型发起调用后再报错。

专用操作子 Agent 的安排也有实际价值。主 Agent 可以负责组织报告和交付，具体网页操作放到相应子任务里处理；大量截图与点击过程不必都堆进主会话。工具范围随角色改变，同一个引擎就能服务不同工作方式。

执行检查仍然保留。工具出现在列表时资源可达，真正调用时连接可能已经断开；本机许可也可能被撤销。装配收窄选择空间，执行器落实本次请求的权限，两者处理不同时间点的问题。

同样，隐藏一个专用工具并不等于消除了所有等价能力。若开放的 Shell 可以接触相同资源，最终边界仍要看 Shell 的权限。这一点在安全分析中尤其重要。

维护成本则集中在场景组合上。新增工具时，要决定它是否适合共享房间、普通子任务、专用操作子任务以及不同资源状态。动态装配用更复杂的条件管理，换来了更贴合当前任务的模型接口。具体过滤入口是 source/host/runner/tools/turn-toolset.ts。

2.4 生成答案与交付结果

经过读取、计算和检查，模型终于写出了报告。用户收到它了吗？

在 Grok Bot 中，还不一定。

普通 Assistant 文本主要属于内部过程，面向用户的回复通过 SendMessage 发送，表情回应另有入口。这个约定允许模型执行许多步骤，却只向用户发送必要的确认、进度和成果。如果每段中间叙述都成为聊天气泡，长任务的消息流会很难阅读。

它也引入了新的故障：模型认为自己已经回答，结果却留在内部输出里。

因此系统除了提示词约定，还设置开场和交付相关提醒，并跟踪已受理消息对应的确认义务。开头说“开始处理”不能代替最后交付报告；旧执行迟到的输出，也不能随意冲销新的交付义务。

这个机制的意义很具体。它把“模型输出了文字”与“用户看到了结果”分开检查，使后台执行可以保持安静，又不会把遗漏交付轻易当成正常结束。例行任务若允许静默且没有新内容，可以不发消息；用户刚交办的报告则需要回到原交互里完成交付。

至此，模型调用结束、Turn 结束和成果送达已经有了不同含义。一旦其中某步中断，恢复逻辑首先要弄清楚的是：到底哪部分已经发生。

3. 工作暂停之后，进度从哪里恢复

资料整理只做了一半，Host 需要重启；或者任务已经结束，用户过了几天才回来追问。两种情况都需要历史，但需要的历史并不相同。

运行时关心执行到了哪里，用户关心收到了什么，模型还可能需要找回某段原话。Grok Bot 为这些用途保留不同的数据表示。

3.1 不同用途，需要不同记录

Agent Store 保存模型会话状态与检查点，产品转录记录用户消息、审批和活动，历史镜像提供可检索的会话内容，对象存储承接同步数据与快照。

这些表示各有写入路径。它们围绕同一任务协作，但不能把全部产品消息都看成模型会话状态的单向副本。例如审批卡有自己的产品交互，模型恢复则需要知道上一段执行状态。发生部分写入失败时，修复对象取决于哪一份数据已经推进。

为什么不只保存一份聊天记录？

因为访问方式不同。界面需要排序、分页和稳定条目，模型回查历史需要定位关键词，恢复执行还需要结构化会话状态。强行用一种格式满足所有用途，通常要把额外索引、转换和恢复逻辑集中到同一层。分开保存，让各自的读取方式直接一些，代价是写入之间需要协调。

用户问“报告里为什么排除了第二家供应商”，就不需要恢复一次旧进程。模型可以根据提供的转录路径搜索名称，读取附近记录，再回答当时的依据。这样不必每轮都把过去数周的对话重新装进上下文。

这个检索入口保留的是回查机会。镜像有自己的记录范围，不是所有工具输出的永久副本；重要结论仍要找到对应原文。它与摘要相配合，才使长期会话不必持续膨胀。

3.2 把并发写入收敛到明确位置

桌面可以有多个，普通私有转录的写入却由 Host 组织。客户端提交请求，由运行主体安排状态变化，客户端再消费更新。

这项选择简化了同步：各端不用独立修改并合并一份模型执行状态，主要任务变成接收权威写入的结果，以及断线后补齐缺失部分。Host 因而成为重要的协调点；客户端拥有历史副本，并不意味着它能在 Host 失联时继续生成同等权威的执行状态。

重复记录和迟到更新还要分别处理。

数据库中的逻辑条目使用唯一标识，重复插入可以由约束吸收。桌面重连后收到快照和迟到增量，则需要副本协议里的代次、序号与覆盖范围：快照已经包含的更新无需再次应用，旧进程代次的序号也不能直接拿来比较新状态。前者解决重复落盘，后者解决更新顺序，它们不是同一套算法。

共享房间引入多个参与者，情况就不同了。服务端标识和顺序需要参与协调，私有转录的单写者假设不能原样套用。这个差异说明，简化来自对写入位置的约束，而非系统不再需要处理分布式一致性。

模型会话中的 Blob 又采用另一种办法：按内容寻址。同样内容可以复用节点，新的检查点引用已有内容并增加变化部分，减少整份长会话重复写入与传输。这适合不断追加的历史，也把根引用管理和数据回收留给存储层承担。

3.3 超时之后，先判断掌握了什么证据

用户提交资料整理任务，界面转了一会儿，最后显示超时。任务可能没到服务器，也可能已经受理，只是响应丢在回程中。

这时再点一次“发送”，会不会产生第二份任务？

Grok Bot 用请求标识 clientNonce 和输入摘要跟踪受理记录。原记录仍在时，同一标识可以定位到它；标识相同、内容却不同，则不能当成正常重复。麻烦出在没有查到记录的时候。

账本会淘汰旧记录，也可能经历损坏或持久化降级。直接把查不到解释成“从来没受理过”，就把证据缺失变成了否定事实。代码因此保留 unknown-durability，与确实没有记录分开。

这个第三态并不决定全部后续行为。账本负责报告手里的证据，上层负责重发策略；当前样本的普通准入函数在未找到记录时仍可能允许分发。它的价值是让调用方有机会识别不确定性，不能据此声称所有重复请求都会被安全拒绝。

同样，accepted 只代表受理，不能当成报告已经完成。

把这两个区别保留下来，用户界面和恢复逻辑才能给出准确说明：是没查到任务，还是记录不完整；是已接受工作，还是已经交付结果。对只能回答文本的程序，重复请求主要增加成本；对能够发送文件、修改外部系统的 Agent，误判还可能重复产生业务动作。

另有一条产品补偿路径处理崩溃后缺失的最新消息：确认义务相关提示会要求模型在无法确定内容时请用户重发，禁止靠猜测补齐任务。系统把自己缺少证据的地方暴露出来，交由人恢复上下文。

3.4 检查点之外，还有真实副作用

受理账本解决“同一请求是否来过”，检查点解决“执行已经推进到哪里”。两者都不能让外部世界自动回滚。

Runner 提交检查点时，会协调会话状态与转录镜像。相关路径先准备镜像，再写 Agent Store；Store 失败可以撤销镜像准备，Store 成功后镜像提交失败，则抛出专门的部分提交错误。因为会话状态已经推进，再按普通失败从头重试，就可能产生不同后果。这是一处分界很清楚的设计：失败发生在提交前还是提交后，决定了恢复方式。把两个结果都包装成“保存失败”，上层就失去了做正确判断所需的信息。

重试判定还会检查错误类型、取消状态、流式输出信号和恢复检查点。流式事件包括内部过程，不能直接等同于用户已收到成果；自动化等路径也有单独的重试策略。重试之前，系统需要先判断这次执行尝试是否具备恢复条件。

可以在资料整理任务后再增加一个动作：把报告提交到外部系统。外部提交已经成功，本地记录却失败，此时恢复检查点不等于撤销提交。下一步应确认外部结果或使用目标服务提供的幂等机制，盲目重做可能造成重复记录。

检查点提供恢复依据，不是撤销按钮。

Host 升级会利用持久化回调中的检查点边界协调停止，云电脑重建则依赖同步数据与快照恢复环境。两者都试图让暂停的位置更明确，但恢复到某个快照，只能带回该快照覆盖的内容；最近未同步的文件、已经失效的网站会话仍需单独处理。

因此一个任务能否继续，最终要看它的进度记录与真实环境是否还能对应。即使都能对应，剩下的动作也未必仍获准执行。用户可能改了要求，目标文件可能变了，原先批准的访问也可能已经撤销。

4. 自主执行的边界

资料整理最初只是读文件、生成报告。准备把成果交出去时，任务开始触及用户账号和外部服务。系统此时要确定下一步所需的授权：可以交付到哪里，能够使用哪些账号，用户此前的要求是否覆盖这项操作。

Grok Bot 在不同位置设置不同约束：工具装配控制模型能选择什么，Auto-review 判断动作风险，本机执行器核对本机许可，凭证本身再限制外部账号能做什么。

4.1 审查必须跟上动作

用户说“整理资料”，通常不足以授权后来出现的任意上传动作。长任务中的具体操作可能过一段时间才确定，因此审查要靠近执行入口，才能看到即将发生的事情。

在启用强制审查的相关路径上，Auto-review 收集动作信息，按判断结果放行、阻止或请求用户决定。图中保留主要批准流程，其他终止情况由相应策略处理。

审查质量首先取决于能看见多少语义。npm run deploy 只给出了脚本名称，点击坐标也没有解释按钮用途。Grok Bot 会为可识别的 Shell 目标补充脚本内容；Computer、Browser 的相应强制模式则要求点击或拖拽提供目的描述。

这是工具接口与审查共同设计的地方。接口如果只提供坐标，分类器再复杂也缺少业务含义；补充描述以后，它才有条件判断动作与任务是否相符。描述来自模型，仍需结合实际参数理解，不能把模型说的目的当成用户授权。

批准以后，目标还可能变化。报告任务等待用户决定期间，脚本从“生成文件”改成“生成后上传”，命令名称完全相同，但副作用已经不同。Shell 审查中的内容绑定与执行前复核，就是为了检查这种变化。它覆盖的是识别、读取并绑定的目标，未把所有脚本依赖和网络响应锁定成一项事务。

等待期间也有约束。存在待审批动作时，受同一控制器检查保护的新副作用入口会被阻止，避免用户还在看决定卡片，另一个工具已经开始操作。

这个等待范围属于运行器与相关执行入口。云电脑上的其他独立进程并不会因此全部冻结。

Auto-review 提供的是前置风险判断，可靠性同时取决于启用模式、覆盖入口和分类器表现。它能减少危险动作直接执行的机会，仍需要本机权限、凭证范围和网络策略配合。

4.2 本机保留独立批准权

访问用户电脑，还有一道不同的判断。

本机执行器先读取本机权限设置。禁止模式直接拒绝，始终允许模式按设置放行，逐次询问模式才要求请求携带批准编号，并与本机记录对应。

这条链路的关键，是批准事实留在被保护的机器上。云端只带来一个编号，本机独立读取记录并核对它是否覆盖本次动作。编号格式正确、请求来自同一个 Agent，都不足以代替这次核对。比如用户同意读取工作区的一份日志，随后请求换成另一个目标。在询问模式下，新请求仍须符合本机批准记录的覆盖条件。云端仅声明“用户已经同意”，不会自动获得新的范围。

执行端因此拥有与请求方不同的判断依据。如果批准仅保存在云端，请求方和解释批准的一方很容易落到同一信任范围里；把最终许可检查留在本机，使云端不能单方面制造本地记录。

这种保护强度由用户选择的模式决定。始终允许代表更宽的本机许可，并不会每次都经过询问模式的记录检查。

权限变化也要到达执行端，所以本机记录、撤销和在途请求仍需要管理。这里的额外状态很有必要：一个几分钟前获得的批准，在用户改变方向后未必还适用于当前动作。让模型记住“刚才好像批准过”，无法代替这些具体记录。

4.3 凭证在哪里，风险就在哪里

本机权限保护本机访问，报告要使用的第三方账号却可能在别处。云电脑里的浏览器带着网站会话，Shell 可能读取环境密钥，HTTP/SSE 连接器又由后端代调用。

几种能力看起来都是工具，凭证暴露方式却不同。

环境变量适配 CLI 的成本很低。用户配置一个 Token，工具按已有方式读取它，就能访问服务。但桌面保存时的加密不再保护已经注入云端进程的可读值。运行环境一旦能读取密钥，就要按密钥实际权限评估影响。

只读 Token 与可以修改资源的 Token，可以用相同方式注入，风险范围却完全不同。

后端代调用减少了工具进程直接持有 OAuth 值的需要，但信任也转移到后端及连接器。哪一种适合产品，要看任务的自主程度、外部服务能力和凭证管理成本。单独一句“凭证已加密”，不足以说明这些边界。

工具执行位置还不等于数据最终位置。本机读取文件可以省去复制整个工作区，但返回文本仍可能进入模型上下文。执行图和数据流必须一起看，才能判断用户资料由谁处理。

Grok Bot 的 Redaction 处理的是另一部分：接入分类系统的数据，在进入日志等受控用途时，按分类和用途决定是否脱敏。未分类字段与凭证类字段采用保守处理，包装类型也能帮助阻止意外的隐式序列化。这把部分检查从日志调用点移到数据接口，使字段新增和流转更容易审查。

它保护的是受控出口。模型处理私有代码时仍可能需要原文，代码也存在明确的不安全解封路径。由此，“日志里没有密钥”和“Agent 无法把密钥发出去”必须分开评价，后一个问题还要看可用工具与网络能力。

4.4 外部内容进入之后

现在把资料来源也纳入考虑。报告可能依据网页、文件和连接器返回的内容，其中夹杂的指令如果被模型误采纳，就可能改变后续动作。

下面是一条条件性风险路径，表示各道防线介入的位置，不代表已经复现的漏洞。

本机审批不会直接覆盖完全发生在云电脑里的操作。Redaction 可以约束日志等用途，也不会自动拦截任意网络请求。Auto-review 若启用并覆盖动作，有机会在执行前阻止它；即便模型被错误内容影响，工具权限、凭证范围和网络策略仍可能阻止后续步骤。这些机制各自有价值，不能用其中一项的存在代替对整条路径的判断。

另一个需要区分的地方是角色与资源隔离。两个 Bot 有不同身份、上下文和工具列表，并不自动拥有两个隔离的文件系统。同一云电脑中的资源共享让工作交接方便，也扩大了可接触的数据范围；专用 Read 工具上的保护，还要结合 Shell 等其他入口一起评估。

对这类长期环境，比反复要求模型“注意安全”更有效的改进方向，是减少一次误操作可以动用的权限。范围较小的凭证、任务级授权、受控代调用和出站限制，都能缩小影响面，代价是接入与运维更复杂。这些是由能力结构推导的设计方向，不意味着样本已证明生产环境完全没有相应策略。

5. 总结与评价：长期 Agent 的工程取舍

Grok Bot 把一个通常由用户持续监督的工作过程，变成了可以暂时离开、稍后回来接续的任务。评价这类产品，除了看模型能否完成某次操作，还要看用户离开之后，系统怎样保存进度、处理变化，以及把未完成的决定交还给人。全文涉及的执行、状态和权限，最终都服务于这种持续委托关系。

这套架构的长处，是给模型之外的系统留下了明确责任。模型负责理解任务和提出动作，运行时负责组织执行、保存恢复依据并检查许可。即便模型犯错或进程中断，系统仍有机会根据记录判断发生了什么。相比依赖一段提示词要求模型始终正确，这样的分工更便于定位问题，也为后续改进留下了具体落点。

它付出的代价同样来自长期性。环境保留下来，文件、登录态和凭证也会累积；入口和执行位置增多，授权与状态的组合随之复杂。Grok Bot 采用持久云电脑、统一执行入口和分层控制，为工作连续性提供支持，但工具范围与审查判断仍需和实际资源权限保持一致。因而，这份架构展示了持续执行的工程基础，距离用户可以放心交出多大权限，还需要运行效果与完整部署策略来回答。

对同类项目，更有参考价值的方向是把自主范围做得清楚：哪些工作可以独立推进，哪些变化需要重新确认，发生不确定状态时如何恢复或交还用户。回到开头的资料整理任务，用户重新打开应用时，应当得到一份已经交付的报告，或者一个明确说明停在哪里的任务。能持续兑现这种预期，才是长期 Agent 值得托付的基础。

跳转微信打开