拆开 Grok Bot：长期 Agent、异步协作与分层记忆是怎么实现的

AIAgentGrokArchitecture

TL;DR：Grok Bot 的 Agent 是带身份、长期状态、记忆、工具和运行队列的 Bot。多个 Bot 既能通过异步消息分工，也能进入同一个 Group 轮流讨论；协调主要由 Host 的确定性调度完成，不需要额外的 Supervisor 模型。它的上下文不会无限追加，而是把近期对话、摘要、记忆和可检索 transcript 分层管理。Plugin、Skill 与 MCP 则分别负责能力分发、操作方法和真实系统连接。

一、Grok Bot 是什么：从代码 Agent 到长期在线的 Bot

SpaceXAI 在 2026 年 8 月 11 日发布 Grok Bot early beta，把它描述为一组全天在线的 AI 队友。它们可以操作云端电脑、使用企业工具、处理定时任务，也能在需要授权或判断时把人拉回来。官方发布页列出的场景覆盖销售跟进、发票处理、办公运营和 Bug 修复，产品边界已经超过代码生成。

Grok Build 与 Grok Bot 面向不同工作方式。Grok Build 是终端 coding agent，围绕代码库和 Shell 展开；Grok Bot 的基本单位则是长期存在的 Bot，它可以持续接收聊天消息、定时任务、其他 Bot 的消息和连接器事件。Cursor 与 SpaceXAI 随后把 Grok 4.6 同时放进 Cursor 与 Grok Build，也把长任务和工具调用列为主要方向。

Grok Bot 的代码血缘来自 Cursor Sand Runtime。0.18.0 发布包仍使用 com.anysphere.sand Bundle ID，协议和运行库中能看到 Cursor Agent、Cursor Dashboard、Cursor Plugin 与 Cursor MCP 的大量共享代码。本文采用的源码是 grok-bot-0.18-reconstructed[4]：它根据公开发布包恢复出可读 TypeScript，并非 Anysphere 原始 monorepo。仓库后来加入的 Router、Codex/Claude/OpenRouter 和本地 Docker 实验不作为 Grok Bot 原生设计证据。

二、Agent 架构：一个长期 Bot，加上一套按需工具

Grok Bot 的 Agent 是一个"长期运行的工作账户"，而不是套了工具的聊天窗口。一个 Bot 至少包含四样东西：稳定身份、自己的会话状态、可持续更新的记忆，以及一条不会同时写乱状态的运行队列。模型只是每个 Turn 中负责判断的部分，Bot 本身并不会随着一次回答结束而消失。

桌面应用是控制面。Renderer 接收消息和显示状态，Electron Main 处理账号、授权、本机能力与窗口，Coordinator 维持连接；真正的 Agent 循环运行在 Sand Host。Host 负责加载 Bot 状态、组织本轮上下文、提供合适的工具、执行模型请求，再把结果和新状态写回。

Agent 架构概念图

一次普通 Turn 大致经历：

plaintext
用户消息或外部事件
  ↓
加载这个 Bot 的身份、会话、记忆和未完成工作
  ↓
拼出本轮上下文，并按运行类型选择工具
  ↓
模型决定回复、调用工具、派生 Subagent 或联系其他 Bot
  ↓
工具结果回到当前 Turn，最终回复写入 transcript
  ↓
更新会话状态、记忆和后台任务

这套架构最有意思的地方是"按需选择工具"。主 Bot、普通 Subagent、Computer Use Subagent 和 Browser Use Subagent 看到的工具集合并不相同。GUI 操作被放进专用 Subagent，MCP 工具在连接成功后才进入当前 Turn。普通本地 Group 成员仍可使用自己的完整工具；只有跨用户 shared room 才会拿掉私有连接器和大部分状态能力。这样既减少工具 schema 对上下文的占用，也避免共享给其他用户的房间继承 Bot 私聊权限。

核心工具按职责分组

能力核心工具解决的问题
对用户交付SendMessage、ReactToMessage把结果真正发到聊天界面；普通 assistant 文本只是内部草稿
执行工作Shell、Read、WebSearch、WebFetch操作远端工作区、读取文件和查询网络信息
操作界面Screenshot、Browser/Computer Use Subagent处理没有稳定 API、需要登录态或必须点击网页的任务
连接真实系统MCP tools调用 Slack、GitHub、Notion 等服务，并处理账号授权
拆分任务Task、CheckSubagent、MessageSubagent、StopSubagent把一次复杂任务放进独立上下文，允许后台运行、纠偏和中止
多 Bot 协作SendToAgent、CreateAgent、UpdateAgent联系长期存在的其他 Bot，或创建新的专门角色

还有两类能力不适合简单列成工具。update_state 负责修改 Bot 自己的记忆、身份、定时任务和工作流；Cloud Agent 则把代码任务交给独立云端环境。它们分别解决"长期状态怎么变"和"长时间代码工作在哪里跑"。

Skill、MCP 与 Plugin 的关系

这三个概念经常混在一起，其实分工很清楚。Skill 是操作方法，告诉 Bot 在某类任务里应该遵循什么步骤；MCP 是工具协议，让 Bot 调用 Slack、GitHub、Notion 等真实系统；Plugin 是分发包，把 Skill、MCP 配置、版本和安装信息组织起来。

Grok Bot 没有独立的 Plugin 格式，它复用了 Cursor/Claude 兼容的 Plugin 包。共享解析器能识别 Skills、Agents、Commands、Rules、Hooks 和 MCP servers，但在 Grok Bot Host 的明确落地路径中，最完整的是 Plugin Skills 与 MCP：Skill 被转成所有 Bot 可见的 Workflow，MCP server 则由账号级连接管理器负责发现、授权和调用。现有源码不足以证明 Plugin 里的 Rules、Hooks、Commands 和 Agents 都会原样成为 Grok Bot 的一等能力。

多个 Bot 共用一个持续存在的 SandBox，包括文件系统、/workspace 和进程环境；各自分配 GUI 窗口和窗口所有权。Session 状态与窗口操作分开，工作区保持共享。这使 Bot 之间可以通过文件交换工件，也意味着一个 Bot 的误删或进程干扰可能影响另一个 Bot。

三、多个 Agent 如何协调：异步私聊与 Group 是两套机制

Grok Bot 没有一个固定的 Supervisor Agent。长期 Bot 彼此是平级关系，谁负责协调取决于用户把任务交给谁。系统提供两条协作路径：SendToAgent 用于定向分工，Group 用于公开讨论。

SendToAgent：像发消息，不像调用函数

用户让 Researcher 找 Bot A 和 Bot B 辩论时，运行中确实有三个 Agent。Researcher 会分别给 A、B 发送任务，发送动作立即返回"已投递"，不会把对方的答案同步带回来。A、B 各自在自己的 Session 中工作，回复稍后以新消息进入 Researcher 的会话，并再次唤醒 Researcher。

plaintext
用户 ──辩题──> Researcher
                 ├── 消息：站 A 方 ──> Bot A
                 └── 消息：站 B 方 ──> Bot B
     <── A 的稍后回复
     <── B 的稍后回复
     │
     └── 在自己的新 Turn 中比较和总结

不同 Bot 有不同运行队列，因此 A、B 可以并行。单个 Bot 内部则保持串行：用户消息优先，其次是其他 Bot 发来的消息，最后才是定时任务等后台工作。如果同一个 Bot 同时收到多个请求，系统不会让两次模型运行并发写入同一份状态。

Researcher 也没有等待所有结果的硬性屏障。第一份回复先到时，它可能先给出阶段性判断；第二份回复到达后，再进入一个新 Turn 完成综合。是否等待、怎样裁判、要不要继续追问另一方，都是 Researcher 根据当前对话自行决定。它更像一个被临时指定的主持人，而不是框架中的特殊 Agent 类型。

Group：协调者是代码，不是第四个 Agent

Group 从新聊天的多收件人选择中产生。用户把两个或更多 Bot 加进 To:，发送第一条消息后，系统创建一个独立 Group 会话。Group 有自己的公开时间线，但成员继续使用各自原来的身份和 Session。

Group 协作概念图

Group 的协调由 Host 中的固定调度逻辑完成。它先读取 mention：@Name 只选择被点名成员，@everyone 或没有 mention 时选择全体成员；然后让成员一个接一个地运行。每个成员看到 Group 的新消息，决定发言或跳过，只有正式调用 SendMessage 的内容才进入公开时间线。

为了避免几个 Bot 无限客套或互相追问，Group 有明确上限：最多 6 名成员，一次用户消息最多推动 3 轮、10 条公开回复，每个成员单次最多发 2 条；一整轮无人发言就结束。这里没有隐藏的 Researcher。如果 Researcher 也在 Group 中，它只是一个普通成员；真正负责选人、轮转和停止的是 Host 代码。

维度SendToAgent 私聊协作Group 协作
谁决定下一步收件 Bot 和临时协调者Host 先轮转，成员再决定是否发言
能否并行不同 Bot 可以并行成员按顺序运行
共享什么只共享显式消息和附件共享 Group 公开时间线
是否复制私聊不复制不复制
适合场景分工、委派、结果回收讨论、互相回应、公开交接

四、记忆与上下文：隔离私聊，但不把 Agent 困在信息孤岛

Grok Bot 的上下文设计不是"把历史越堆越长"。它把信息分成三层：当前对话负责眼前任务，Memory 保存可长期复用的事实，共享工作区保存文件和执行结果。不同层的共享范围不同，这比简单说"每个 Agent 完全隔离"更准确。

三种 Memory 范围

Memory 范围谁能看到适合保存什么
Agent memory当前 Bot角色经验、用户对这个 Bot 的偏好、长期职责
User memory同一用户下的多个 Bot用户身份、通用偏好、跨任务都需要知道的事实
Project memory加入同一 Project 的 Bot项目约定、共同决策、持续更新的项目背景

每个 Bot 的私聊 transcript 仍然独立。Bot A 不会因为与 Bot B 同属一个用户，就自动看到 B 的完整聊天。但某条事实如果被写入 user memory，或写入共同 project memory，就能在后续 Turn 中进入其他 Bot 的上下文。共享的是经过提炼的事实，不是原始私聊。

Memory 既可以由 Bot 显式写入，也会在 Turn 结束后尝试从用户消息和最终回复中提取可复用事实。稳定偏好进入长期 profile，带时间性的内容进入日志；提取失败不会影响这次回复。它保存的是未来还可能用到的信息，而不是把每句话都当成记忆。

一次 Turn 只拿当前需要的信息

系统为每轮请求组装四类上下文。第一类是稳定身份，包括 Bot 的名称、职责和用户信息；第二类是长期状态，包括 Memory、定时任务和启用的 Skills；第三类是当前会话，包括历史摘要、最近消息和这次上传的文件；第四类是能力描述，包括当前可用工具、MCP 状态和远程电脑信息。

这些内容不会全部固定塞进 system prompt。MCP 工具要在本轮连接成功后才加入，Browser/Computer 工具主要放在专用 Subagent；跨用户 shared-room member 还会去掉私有连接器和大部分状态能力。上下文因此会随运行类型变化，而不是所有 Agent 共用一份巨大 prompt。

压缩后的历史怎么读

底层会话有两种视图。聊天界面使用按时间排列的事件记录，方便搜索、未读和消息展示；模型运行状态则以内容寻址的结构保存，对话 Turn、摘要、Todo 和 Subagent 状态可以分别更新。两者分开后，界面历史、模型当前上下文和大块任务状态不必绑在同一段 JSON 里反复重写。

会话接近上下文窗口上限时，Grok Bot 会把较早对话压成摘要，保留最近的消息和正在进行的工作。完整可见对话仍镜像为 JSONL transcript，Agent 在需要精确路径、错误信息或旧决策时，可以先搜索关键词，再读取附近的一小段。三种历史各有用途：摘要负责让当前 Turn 连续，Memory 负责跨任务复用事实，JSONL transcript 负责找回被摘要省略的细节。

另一个细节是"压缩周期冻结"。同一个长上下文周期内，已注入的 Memory 和 Bot profile 会保持稳定；如果身份或记忆发生变化，系统先用隐藏更新通知模型，到下一次压缩后再折回稳定上下文。这样可以避免模型在一段长任务中突然面对一份悄悄改写过的身份说明。

长期 Agent 要记住用户，但每次请求不能装下所有过去；多个 Agent 要隔离私聊，也要交换结论和工件。Grok Bot 为此组合了私有 Session、分层 Memory、可检索 transcript、共享 Group 时间线和共享工作区。

参考资料

评论

登录后参与评论 登录

加载中…

返回博客列表