xAI 设计 Grok Bot：为持久化智能体重构交互界面
Designing Grok Bot for a world of persistent agents
xAI 发布设计文章，介绍 Grok Bot 如何为超越单次会话的持久化智能体设计界面。产品以 Bot 为主要对象而非会话，Bot 拥有身份、记忆、自己的计算机和工具；头像动效呈现空闲、工作、等待、阻塞、思考、完成等状态；工作区提供状态、预览、接管三级访问。
xAI 官方复盘 Grok Bot 的界面设计决策，读者可以了解持久化智能体产品在组织方式和交互上的取舍思路。
我们如何为那些能跨越单次会话持续存在的智能体设计 Grok Bot——从聊天记录到 Bot 花名册、在线状态、Bot 自己的计算机，以及无需提示词即可启动的工作。
当我们开始设计 Grok Bot 时，一个核心问题是：界面应当如何塑造用户与智能体之间的关系。大多数 AI 界面都围绕用户操作的聊天会话来组织。每次会话从设置开始，在用户的注视下展开，并在对话停止时结束。
我们希望为一个能跨越任何单次会话持续存在、并能独立承担责任的智能体而设计。这意味着要重新思考界面的一些基本对象和信号，包括侧边栏中应该放什么、智能体如何展示进度，以及它的工作应在何时变得可见。
Kenny
晚上 7:34
周五全员大会的演示文稿需要你确认。
Justin
已起草 8 封引荐邮件——在 CRM 里等你发送。
Luke
晚上 7:34
收件箱里有 3 封。有两封今天需要回复。
网站上线
上午 11:18
John：staging 环境的 checkout 没问题了，关了 3 个 bug。
John
昨天
复现了 checkout 崩溃。详细记录在工单里。
Keith
Acme 那边有点动摇。草拟了一份周四的跟进沟通。
Tyler
上午 9:04
收到 14 张收据。还差你周二那笔 Uber 的。
Manuel
下午 2:20
发布帖已上线。前 200 次曝光。
Jenny
周二
SoMa 有 3 处房源。Folsom 那套两居室就是它了。
Chang
上午 10:12
已找到 3 个。跳过了你 ATS 中已有的一个。
插件
Peng Zheng
Kenny
上午 9:41
嘿，今天的设计同步会主要有哪些要点？
团队把大部分时间都花在了评审新的引导流程上。
讨论最多的是空状态。Sarah 觉得目前的插画与新的品牌方向不符，在场的大多数人都表示认同。关于进度指示器应该放在页眉还是侧边栏，也来回争论了很久。
不过整体氛围还是积极的。大多数人认为这个流程已经接近可以提交更广泛评审的程度了。
有人提到 Q3 路线图吗？
提到了，而且提了两次。Marcus 说路线图评审现在预计在 8 月第一周进行，Priya 问引导流程的工作会在这之前还是之后落地。会上没有确定具体日期。
给 Kenny 发消息
Kenny 的屏幕
例行任务
晨间简报
每天上午 8:00
收件箱清理
工作日晚上 6:00
每周团队更新
已暂停
重新思考基本概念
AI 产品在短时间内积累了大量词汇。对话、会话、模型、上下文窗口、记忆、系统提示词、项目、技能、连接器、智能体、工具、沙箱、权限和自动化，都描述了这些系统中真实存在的组成部分。
但把每一个都作为独立的产品概念暴露出来，会让用户需要理解超出其必要范围的东西。我们首先问的是：一个人要与智能体协作，究竟需要哪些概念？
我们反复回到五个：
- Bot 是持久存在的智能体，拥有自己的身份、记忆、运行时和工具。
- 对话 是与 Bot 协作的对话式界面。
- 提示词为 Bot 提供上下文或指令。它们可以一次性使用、保存为技能，或作为例程自动触发。
- 工具让 Bot 通过软件、API、连接器、shell 或计算机操作来获取信息并采取行动。
- 产物是 Bot 创建或修改的文档、设计、代码、数据及其他持久性输出。
其他一切都可以留在界面之下，直到用户有理由去关注它。接下来的问题是，这五个对象中哪一个应该用来组织产品。
从聊天记录到 Bot 花名册
聊天是一次性的。我们开启一段对话来解决问题。它被挤到侧边栏下方。一周后，我们又开启另一段。你很少会翻到最近五条之外。
当交互的单位是一个问题时，这种行为完全合理。但当交互另一侧的对象本应了解你、记住之前的工作并随时间推移承担责任时，这就变得奇怪了。
因此，Grok Bot 中的主要对象是 Bot，而非对话。一个 Bot 有名字。它有头像和头衔。它记得与你的对话。它有自己的计算机和工具。当你明天回来时，你回到的是同一个 Bot。
Project Acme
起草一封在周五通话后给 Acme 的跟进邮件
重写定价单页材料
在安全审查中我应该问些什么？
根据我的通话记录构建一张支持者关系图
用刁钻的反对意见来演练演示
帮我比较这三份竞品演示文稿
显示更多
Kenny
晚上 7:34
需要你确认周五全员大会的演示文稿。
Justin
已起草 8 封引荐邮件——在 CRM 里等你发送。
John
昨天
复现了结账崩溃。报告已写在工单里。
Keith
Acme 有些摇摆不定。起草了一份周四的签到。
存在感即界面
一旦 Bot 变成一种需要长期维护、而非启动一次会话就结束的东西，Bot 在产品中的呈现方式就必须同时回答三个问题：
- 这是谁？
- 他们在做什么？
- 我需要了解多少？
这是谁
名册只有在能被快速扫视时才有用。随着名册不断增长，我们不希望人们每次打开产品时都得把每个名字读一遍。他们应该几乎凭余光就能从头像认出某个 Bot。
Bot 头像视觉风格探索
与此同时，我们希望头像保持足够的一致性，让人读起来像是一套体系。我们研究了插画、动画、游戏和界面设计中的角色系统，探索了从首字母缩写和 emoji，到像素艺术、水彩、黏土拟态、Noritake 风格线稿、剪影和 identicon 的各种方向。
大多数方案都只更好地解决了问题的一侧。水彩和黏土风格赋予单个 Bot 充足的个性，但在侧边栏尺寸下承载了过多细节。更简单的系统在界面中显得更自然，但往往让各个 Bot 看起来千篇一律、可以互换。
我们最终确定的系统保持基础构造一致，采用简单的形状和富有表现力的眼睛，然后通过受控的变化和配饰引入区分度。每个 Bot 都能一眼被认出，同时又不显得来自另一个视觉世界。
它们在做什么
一旦头像成为 Bot 的身份标识，它自然也就成了展示状态的理想位置。一个 Bot 可能处于空闲、思考、工作、等待、受阻或完成状态。我们本可以用单独的指示器来表示每种状态，但那会给用户增加另一层需要解读的 UI。
于是，我们探索了头像本身能承载多少生命周期信息。
静止时，Bot 平静而略带好奇。当任务到来时，它会确认任务。工作开始时，它进入状态。当它在等待或需要帮助时，它的动作会再次变化，然后在工作完成后归于平静。现在，头像既能展示 Bot 在做什么，也能展示它是哪个 Bot。
空闲 工作中 等待中 受阻 思考中 完成
头像动效系统
我需要了解多少
一个相关的设计问题是，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 的电脑自己的时间感，让它感觉与用户的桌面彼此独立。
动态壁纸
这更像是与一位同事协作，而不是操作一台远程机器。你能看出他们正在工作，在需要了解背景时瞥一眼他们的屏幕，并在有事情需要你帮忙时坐下来处理。
信息的形态
早期版本的 Grok Bot 几乎对每一个请求都用散文来回应。它会描述一份五天天气预报，而不是直接展示出来；它会叙述一组任务，而不是把它们排布成一块看板。用户随后不得不重新组织答案。这促使我们把回应的形式视为答案的一部分。
为支持这一点，我们在 Grok Bot 中内置了行内卡片和小组件。Bot 可以在散文适合所呈现信息时用散文作答，在不适合时使用结构化 UI。
新邮件
准备发送
发件人 peng@grokbot.app
收件人 sarah@acme.com
主题 将周五的设计评审改到下午 2 点
嗨，Sarah，
我们能把周五的设计评审从上午 11 点改到下午 2 点吗？临时来了个客户电话，我不想让我们的讨论太赶。
谢谢，
Peng
发送邮件 丢弃
内联聊天组件
同样的原则也适用于操作。当 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 更难获得与其工作相关的信息。
因此，在 Grok Bot 中，能力和上下文遵循不同的边界。工具和技能位于账户层级，因为许多 Bot 可能都需要浏览网页、处理文档或发送电子邮件。记忆和例程归属于 Bot，因为它们反映了该特定角色随时间推移所知道和所做的事情。换句话说，能力可以广泛共享，而上下文则保留在需要它的角色那里。
有些工作会跨越这些角色边界。群聊为某个项目或团队提供共享上下文，同时让每个 Bot 保留其专属记忆。设计师、工程师、PM 和数据科学家可以在同一个对话中协作，互相交接工作，并共享项目所需的信息。
我们曾考虑添加仪表盘、任务分配面板和显式交接控制来管理这些群组。但每一种都会给用户带来更多的协调工作。于是，我们让负责协调的 Bot 处理日常路由，并在需要判断的决策时引入用户。
持续运转的工作
大多数智能体会话始于用户发送一条提示词。这使得即便是持久化的 Bot 也在等待有人来激活它。Routines 让用户可以为 Bot 赋予一项常驻职责，按计划或响应事件运行，例如关注某个行业或每天早上准备一份简报。用户只需定义一次工作内容，Routine 会在需要时激活 Bot。
我们最初将 Routines 视为次要配置。随着它们对自主工作变得越来越重要，我们将其移入了 Bot 的主界面。对话记录展示运行了什么，并为用户提供了一个查看结果或处理异常的地方。
每天上午 8:00
工作日每天上午 8:00
每周一上午 9:00
每月 1 日上午 8:00
每 30 分钟
工作日 · 上午 9:00
在 grokbot 中创建 Issue
所有项目中的任意 Issue 事件
在 grokbot 上触发 Incident
grokbot 上的任意 Incident 事件
在 grokbot 中打开 PR
在 spacexai 中合并 PR
在 acme 中关闭 PR
向 main 推送新提交
grokbot 中 PR 的检查失败
在 grokbot 中添加 bug 标签
在 ops 中包含 /fix 的评论
在 grokbot 中审查通过
在 grokbot 中解决讨论串
工作流 deploy.yml 失败
当 webhook 收到 POST 请求时
#grokbot 中的新消息
在#ops 中添加了 Reaction:eyes:
已创建与 dev 匹配的频道
#design 中的新消息
在 Roadmap 中创建了 Issue
Issue 状态 →In Review in Core
Team Core 周期结束时
Issue 状态 →Done in Design
Design team 中的新消息
在 Design team 中创建了频道
这也改变了对话的角色。一条提示词可以开启一个会话，但一个日程、一个事件或另一个 Bot 同样可以。随着时间推移，越来越多的工作可能完全在用户不在场的情况下启动。
正在消失的界面
到项目结束时，大量设计工作都涉及做减法。我们移除了窗口和面板控件、computer-view 选项以及 agent 元数据。我们还设定了实际限制：每个账户大约 50 个 Bot，每个群聊 6 个。每一个决定都回到同一个问题：这是帮助某人完成委派，还是又给他们多了一件要管理的事？
随着模型不断进步，操作 AI 与向同事委派任务之间的界限一直在移动。Grok Bot 反映了我们认为这条界限今天所处的位置。从最早的探索到正式发布，设计 Grok Bot 的过程始终围绕找到这条界限，并帮助界面随之改变。当智能体承担起更多责任时，界面对人的要求就应该更少。
来源：xAI：News（网页） · x.ai