xAI 设计 Grok Bot：为持久化智能体重构交互界面

我们如何设计 Grok Bot，让智能体能够超越单次会话而持续存在——从聊天记录到 Bot 名册、在线状态、Bot 专属的计算机，以及无需提示词即可启动的工作。

当我们开始设计 Grok Bot 时，核心问题之一是界面应如何塑造用户与智能体之间的关系。大多数 AI 界面都围绕用户操作的聊天会话展开。每个会话从设置开始，在用户的注视下展开，并在对话停止时结束。

我们希望设计一个能够超越任何单次会话而持续存在、并能独立承担责任的智能体。这意味着需要重新思考界面的一些基本对象和信号，包括侧边栏中应该放什么、智能体如何展示进度，以及它的工作何时应该变得可见。

Kenny

晚上 7:34

周五全员大会的演示文稿需要你确认。

Justin

8 份介绍草稿已写好——存放在 CRM 里，等你发送。

Luke

晚上 7:34

收件箱还有 3 封邮件。其中两封今天需要回复。

网站上线

上午 11:18

John：结账流程在预发布环境上已经干净了，关了 3 个 bug。

John

昨天

复现了结账崩溃的问题。详细说明写在工单里了。

Keith

Acme 那边有点摇摆不定。我起草了一份周四的同步沟通。

Tyler

上午 9:04

收到 14 张收据了。还缺你周二打 Uber 的那张。

Manuel

下午 2:20

发布帖已经上线了。前 200 次曝光。

Jenny

周二

SoMa 那边有 3 个地方。Folsom 那套两居室就是目标。

Chang

上午 10:12

来源：xAI：新闻（网页）

插件

彭正

肯尼

上午 9：41

嘿，今天的设计同步会主要有哪些收获？

团队大部分时间都在审阅新的引导流程。

最大的讨论围绕空状态展开。莎拉觉得现有的插图不符合新的品牌方向，在场大多数人也都认同。关于进度指示器应该放在页头还是侧边栏，大家也进行了长时间的来回讨论。

不过整体氛围是积极的。大多数人认为这个流程已经接近可以进入更大范围评审的阶段。

有人提到 Q3 路线图了吗？

提到了，出现了两次。马库斯说路线图评审现在预计在八月的第一周进行，普丽娅问引导工作会在那之前还是之后落地。会议上没有确定具体日期。

给肯尼发消息

肯尼的屏幕

日常任务

早间简报

每天上午 8:00

收件箱清理

工作日傍晚 6:00

每周团队动态

已暂停

重新思考基础概念

AI 产品在短时间内积累了大量词汇。聊天、会话、模型、上下文窗口、记忆、系统提示词、项目、技能、连接器、智能体、工具、沙盒、权限和自动化，这些都描述了这些系统中真实存在的组成部分。

但把每一个都作为独立的产品概念呈现出来，是在要求用户理解超出他们实际需要的内容。我们一开始问的是：一个人要与智能体协作，究竟需要哪些概念。

我们反复得出的答案始终是五个：

Bot（机器人）是拥有自身身份、记忆、运行时和工具的持久化智能体。

Chat（聊天）是与 Bot 协作的对话式界面。

Prompt（提示词）为 Bot 提供上下文或指令。它们可以一次性使用、保存为技能（Skills），或作为例行程序（Routines）自动触发。

工具让 Bot 能够获取信息，并通过软件、API、连接器、shell 或计算机使用来采取行动。

工件（Artifacts）是 Bot 创建或修改的文档、设计、代码、数据以及其他持久性输出。

其他一切都可以保留在界面之下，直到用户有理由去关注它们。接下来的问题是，这五个对象中哪一个应该作为组织产品的核心。

从聊天历史到 Bot 列表

聊天是即用即弃的。我们开启一段对话是为了解决一个问题。它被推到侧边栏的下方。一周后，我们又开启另一段对话。你很少会回头翻看最近五条以外的内容。

当交互的单位是一个问题时，这种行为完全合理。但当交互的另一端本应认识你、记住之前的工作并长期承担责任时，这种行为就变得奇怪了。

因此，Grok Bot 中的主要对象是 Bot，而不是对话。一个 Bot 有名字，有头像和标题。它记得与你的对话。它有自己的计算机和工具。当你明天回来时，你回到的是同一个 Bot。

Acme 项目

根据周五通话内容起草一份给 Acme 的跟进邮件

重写定价一页纸

安全审查中我应该问些什么？

根据我的通话笔记构建一份支持者地图

用刁钻反对意见来演练演示

帮我对比这三份竞品方案

显示更多

Kenny

晚上 7:34

周五全员大会的演示文稿需要你确认。

Justin

8 封引荐邮件草稿已写好——放在 CRM 里，等你发送。

John

昨天

已复现结账崩溃问题。详细说明已写入工单。

Keith

Acme 那边在动摇。已起草周四的跟进沟通。

在场感即界面

一旦 Bot 从“你启动的一次会话”变成“你需要长期维护的东西”，Bot 在产品中的呈现方式就必须同时回答三个问题：

这是谁？

它们在做什么？

我需要了解多少？

这是谁

一份名单只有在能被快速扫读时才真正有用。随着名单不断变长，我们不希望用户每次打开产品都要逐一阅读每个名字。他们应该几乎仅凭余光就能从头像辨认出某个 Bot。

Kenny Kuh 与 Peng Zheng 对 Bot 头像视觉风格的探索

与此同时，我们希望头像之间保持足够的统一性，让人能看出它们是同一套体系。我们研究了插画、动画、游戏和界面设计中的角色体系，探索了从首字母、表情符号到像素画、水彩、黏土风格、Noritake 式线条画、剪影和 identicon 等各种方向。

大多数方案都只在一方面做得更好。水彩和黏土风格让单个 Bot 个性十足，但在侧边栏的尺寸下细节过多。更简洁的体系在界面中更自然，但往往让各个 Bot 看起来大同小异。

我们最终采用的系统保持了基本构造的一致性，使用简洁的造型和富有表现力的眼睛，再通过受控的变化和配饰来体现差异。每个 Bot 都能一眼被认出，同时又不会让人觉得它们来自不同的视觉世界。

它们在做什么

一旦头像成为 Bot 的身份标识，它自然也成为展示状态的最佳位置。一个 Bot 可能处于空闲、思考、工作、等待、受阻或完成等状态。我们本可以用独立的指示器来表示每种状态，但那会为用户增加一层需要解读的 UI。

相反，我们探索了头像本身能承载多少生命周期信息。

静止时，Bot 显得平静且略带好奇。当任务到来时，它会确认收到任务。工作开始时，它会进入运转状态。当它等待或需要帮助时，动作会再次变化，任务完成后则恢复平静。现在，头像既能显示 Bot 在做什么，也能表明它是哪个 Bot。

空闲 工作 等待 受阻 思考 完成

头像动作系统由 Benji Taylor 设计

我需要了解多少信息

一个相关的设计问题是，Bot 的执行过程需要展示多少。一种做法是标准的“三个动画点”，但那提供的信息太少，用户很难判断 Bot 是在工作还是卡住了。

正在搜索网络

环境就绪 387ms

已编辑 math.ts +14−10

已运行定向测试 npm test

已运行类型检查 npm run

短暂思考

已搜索代码“toFixed”

已读取 AGENTS.md

已编辑 math.test.ts +6−2

已运行完整测试套件 212 项通过

已提交修复：clamp NaN

环境就绪 387ms

已编辑 math.ts +14−10

已运行定向测试 npm test

已运行类型检查 npm run

短暂思考

已搜索代码“toFixed”

已读取 AGENTS.md

已编辑 math.test.ts，+6 −2

运行完整测试套件，212 项全部通过

已提交修复：对 NaN 进行钳制处理

我们还尝试过用一段简短的文字描述来展示 Bot 当前正在执行的操作，但一旦用户能看到某一步，他们就想看到其余所有步骤。用户调研显示，他们之所以要求看到这些细节，主要是为了确认 Bot 仍在正常工作、没有偏离方向。

在最终设计中，头像的动态首先提供了第一层安心感——表明 Bot 正处于活跃状态。如果用户想查看它正在做什么，只需悬停即可看到其当前操作。

那是它们的电脑，不是你的

每个 Bot 都拥有自己的电脑，可以用它来浏览网页、处理文件和运行软件。这又带来了另一个界面问题：这台电脑应该有多大程度的可见性？用户又应该在什么时候能够控制它？

我们探索了四种布局方案：

悬浮窗口：让电脑易于触达，但会遮挡对话内容。

并排显示：让工作过程持续可见，鼓励用户观看。

模态窗口：便于随时查看进度，但把 Bot 的工作区当作了一种临时打断。

全屏：给了电脑充足的空间，却完全挤掉了对话。

我们把电脑做得越显眼，产品就越倾向于引导用户去监督它。我们决定，它应该仍然是 Bot 的工作空间，界面则根据用户的需要提供不同层级的访问权限。

最终设计包含三个层级，让用户可以进入 Bot 的工作空间，却不必被卷入操作之中：

状态：电脑处于活动状态时，标题栏图标会变为紫色。

预览：打开后会展开一个固定的侧边面板，用户无需离开对话即可跟进工作进度。

接管：当 Bot 需要帮助时，用户可以全屏打开电脑、接管控制，然后再交还回去。

我们还设计了随时间变化的动态壁纸——清晨更明亮，夜晚更深沉。这一细节让 Bot 的电脑有了自己的时间感，也让它与用户的桌面区分开来。

动态壁纸由 Kenny Kuh 和 Luke Barker 设计。

这更像是与同事协作，而不是操作一台远程机器。你能看出对方正在工作，需要上下文时瞥一眼他们的屏幕，遇到需要你帮忙的事情时再坐下来接手。

信息的形态

早期版本的 Grok Bot 几乎对所有请求都用散文式文字来回应。它用文字描述五天的天气预报，而不是直接展示天气图；用叙述的方式罗列任务，而不是以看板形式呈现。用户随后不得不重新整理这些回答。这让我们意识到，回答的形式本身就是答案的一部分。

为了支持这一理念，我们在 Grok Bot 中构建了内联卡片和小组件。当散文式文字适合承载信息时，Bot 可以用文字回答；当不适合时，则使用结构化界面。

新邮件

准备发送

发件人：peng@grokbot.app

收件人：sarah@acme.com

主题：将周五的设计评审改到下午 2 点

嗨，Sarah，

我们能否把周五的设计评审从上午 11 点改到下午 2 点？临时有一个客户电话会议，我不想让我们的讨论太仓促。

谢谢，

Peng

发送邮件 放弃

Peng Zheng 的内联聊天小组件

同样的原则也适用于操作。当 Bot 创建 Routine、更改设置或向另一个 Bot 发送消息时，该事件可以直接出现在记录中。当有更多内容需要查看时，用户可以将其打开。

上午 9:41

早上好！你能帮我跟每个人确认一下情况吗？

正在处理——现在联系团队获取状态

与 Kenny Tyler 和 Jenny 的 6 条消息

一切顺利：Kenny 已上线落地页，Tyler 已发送本月发票，Jenny 已预订下周的面试。没有阻塞问题。

太棒了，你能每天早上都这样做吗？

已创建 Routine：晨间简报

搞定，你的晨间简报每天 9:00 会准时送达

其结果是形成一种异构记录，对话、系统事件、交互式对象和可视化内容共享同一条时间线。

组织智能

一旦用户创建了多个 Bot，产品还需要组织这些 Bot 如何协同工作。我们需要决定哪些上下文应归属于哪个角色，当 Bot 的工作范围重叠时它们应如何共享上下文，以及如何协调它们而不让用户变成调度员。

随着用户创建更多 Bot，我们看到一个答案逐渐浮现。有人设置了一个 Chief of Staff Bot 来负责协调多个专家 Bot。他们只需向一个 Bot 下达指令，而无需逐一检查每个 Bot 并亲自为每项任务分配路由。

赋予 Bot 不同的角色也迫使我们决定每个角色应该知道什么。一个法律 Bot 可能需要正在进行的纠纷的历史记录，而一个财务 Bot 可能需要多年的财务记录。将这些历史合并到一个大内存中，反而会让为每个 Bot 提供与其工作相关的信息变得更加困难。

因此，在 Grok Bot 中，能力与上下文的边界是不同的。工具和技能位于账户层面，因为许多 Bot 可能都需要浏览网页、处理文档或发送电子邮件。而记忆和例行任务则归属于 Bot 本身，因为它们反映的是该特定角色随时间推移所知道和做的事情。换句话说，能力可以广泛共享，而上下文则保留在需要它的角色手中。

有些工作会跨越这些角色边界。群聊为项目或团队提供共享上下文，同时允许每个 Bot 保留其专业化的记忆。设计师、工程师、产品经理和数据科学家可以在同一个对话中协作，互相交接工作，并共享项目所需的信息。

我们曾考虑添加仪表盘、任务分配板和显式交接控制来管理这些群组。每一种方案都会给用户带来更多的协调工作。相反，由协调型 Bot 处理常规路由，只在需要判断力做决策时才把用户拉进来。

持续推进的工作

大多数智能体会话始于用户发送提示词。这样一来，即使是常驻的 Bot 也要等待有人来激活它。Routines（例行任务）让用户能给 Bot 一项长期职责，按计划或响应事件运行，例如关注某个行业或每天早上准备简报。用户只需定义一次工作内容，Routine 就会在需要时激活 Bot。

我们最初把 Routines 当作次要配置。随着它们对自主工作越来越重要，我们将其移入了 Bot 的主界面。会话记录会显示运行了什么，并给用户一个查看结果或处理异常的地方。

每天早上 8:00

工作日早上 8:00

每周一早上 9:00

每月 1 日早上 8:00

每 30 分钟

工作日 · 9:00 AM

已在 grokbot 中创建 issue

在所有项目中提交 Issue

grokbot 上触发事件

grokbot 上的任意事件

grokbot 中开启 PR

spacexai 中合并 PR

acme 中关闭 PR

推送到 main 分支

grokbot 中 PR 的检查失败

grokbot 中添加 bug 标签

ops 中包含 /fix 的评论

grokbot 中审核通过

grokbot 中线程已解决

deploy.yml 工作流失败

当 webhook 收到 POST 请求时

#grokbot 中的新消息

#ops 中添加 :eyes: 表情回应

创建匹配 dev 的频道

#design 中的新消息

已在路线图中创建问题

问题状态 → 核心团队中进入审核

核心团队周期结束时

问题状态 → 设计团队中已完成

设计团队中有新消息

在设计团队中创建了频道

这也改变了对话的角色。提示词可以开启一个会话，但定时任务、事件或其他 Bot 同样可以。随着时间推移，越来越多的工作可能根本不需要用户在场就能开始。

逐渐消失的界面

到项目后期，大量设计工作都在做减法。我们去掉了窗口和面板控件、电脑视图选项以及智能体元数据。我们还设定了实际限制：每个账户约 50 个 Bot，每个群聊最多 6 个。每一个决定都回归到同一个问题：这是帮助用户完成委派，还是又给他们添了一件需要管理的事？

随着模型不断进步，操作 AI 与向同事委派任务之间的界限也在不断移动。Grok Bot 反映的是我们认为这条界限目前所处的位置。从最初探索到正式发布，设计 Grok Bot 的过程始终是在寻找这条界限，并帮助界面随之演变。当智能体承担更多责任时，界面应当对用户提出更少的要求。