刚开始设计 Grok Bot 时，我们面对的核心问题之一是：界面应该如何塑造用户与智能体之间的关系？多数 AI 界面围绕由用户操作的聊天会话展开。每段会话都从设置开始，在用户的注视下推进，并随着对话停止而结束。
我们想设计一种能持续存在、超越任何单次会话，并能独立承担责任的智能体。这意味着重新思考界面中的一些基本对象和信号：侧边栏应该放什么，智能体如何展示进展，以及它的工作何时应该对用户可见。
重新思考基础概念
AI 产品在很短的时间里积累了大量术语。聊天、会话、模型、上下文窗口、记忆、系统提示词、项目、技能、连接器、智能体、工具、沙箱、权限和自动化，都描述了这些系统真实存在的组成部分。
但如果把每一项都作为独立的产品概念呈现，就要求用户理解超出实际需要的东西。我们首先问的是：一个人与智能体协作，究竟需要理解哪些概念？
我们反复回到以下五个概念：
- 机器人（Bots）是持续存在的智能体，拥有自己的身份、记忆、运行环境和工具。
- 聊天（Chats）是与机器人协作的对话界面。
- 提示词（Prompts）为机器人提供上下文或指令。它们可以只使用一次，也可以保存为技能（Skills），或者通过例行任务（Routines）自动触发。
- 工具（Tools）让机器人通过软件、API、连接器、Shell 或电脑操作来获取信息并采取行动。
- 产物（Artifacts）是机器人创建或修改的文档、设计、代码、数据以及其他可长期保留的成果。
其余内容都可以留在界面之下，直到用户有理由关心它们。接下来的问题是：应该围绕这五种对象中的哪一种来组织产品？
从聊天历史转向机器人名册
聊天是用过即走的。我们为了处理一个问题开启对话，之后它逐渐被挤到侧边栏下方。一周后，我们又开启另一段对话。很少有人会翻到最近五段对话之外。
当交互单位是一个问题时，这种行为完全合理。但如果交互另一端的对象应该了解你、记得以前的工作，并长期承担责任，这种方式就显得奇怪了。
因此，Grok Bot 的主要对象是机器人，而非对话。机器人有名字、头像和职务；它记得与你的交流，拥有自己的电脑和工具。明天再回来，你面对的仍是同一个机器人。
让存在感成为界面
当机器人变成一种需要长期保持关系的对象，而不只是启动的一段会话时，它在产品中的呈现方式就必须同时回答三个问题：
- 它是谁？
- 它正在做什么？
- 我需要知道多少？
它是谁？
名册只有能让人快速扫读才有价值。随着名册变长，我们不希望用户每次打开产品都必须逐个阅读名字。用户应该几乎只凭余光，就能从头像辨认出某个机器人。
与此同时，我们也希望头像足够一致，让人能看出它们属于同一个系统。我们研究了插画、动画、游戏和界面设计中的角色体系，探索了从姓名首字母、表情符号，到像素艺术、水彩、黏土风格、Noritake 式线条插画、剪影和身份识别图案等各种方向。
大多数方案都更擅长解决问题的一面，而难以兼顾另一面。水彩和黏土风格赋予每个机器人鲜明的个性，但在侧边栏那么小的尺寸下，细节过多。更简单的体系能更自然地融入界面，却常让机器人看起来彼此没有区别。
最终采用的体系保持基本构造一致，使用简单的形状和富有表现力的眼睛，再通过受控的变化与配饰体现差异。每个机器人都能让人一眼认出，同时又不会像来自不同的视觉世界。
它正在做什么？
当头像成为机器人的身份标识时，它也自然成为展示状态的位置。机器人可能处于空闲、思考、工作、等待、受阻或完成状态。我们原本可以为每种状态设置单独的指示器，但那会给用户增加一层需要理解的界面信息。
于是，我们探索头像本身能够承载多少生命周期信息。
空闲时，机器人平静而略带好奇；任务到来时，它会做出回应；开始工作时，它进入忙碌状态；等待或需要帮助时，它的动作再次变化；工作完成后，它又平静下来。头像现在既能表明这是哪个机器人，也能表达它正在做什么。
我需要知道多少？
另一个相关的设计问题是，应该展示多少执行过程。一种方案是使用常见的“三个动态圆点”，但它提供的信息太少，用户难以判断机器人是在工作，还是卡住了。
我们也尝试过用简短文字描述机器人当前的动作。但当用户能看到其中一步时，他们就会想看其他步骤。用户研究表明，人们索取这些细节，主要是想确认机器人仍在工作，而且方向正确。
在最终设计中，头像的动作先提供一层安心感，表明机器人仍在活动。如果用户想进一步确认它正在做什么，可以悬停查看当前动作。
那是它的电脑，不是你的
每个机器人都有自己的电脑，可以用来浏览网页、处理文件和运行软件。这带来了另一个界面问题：这台电脑应该多显眼？用户又该在什么时候能够控制它？
我们探索了四种布局：
- 悬浮窗口：电脑很容易打开，但会遮住对话。
- 并排显示：工作过程始终可见，也会鼓励用户一直盯着看。
- 模态窗口：方便随时查看，但把机器人的工作空间变成了一次临时打断。
- 全屏显示：给电脑足够的空间，却完全挤走了对话。
我们越突出这台电脑，产品就越是在鼓励用户监督它。我们决定，它应该始终是机器人的工作空间，而界面则根据用户的需要提供不同程度的访问方式。
最终设计分为三个层级，让用户可以进入机器人的工作空间，又不至于被拖进具体操作中：
- 状态：电脑运行时，标题栏图标变为紫色。
- 预览：打开后显示一个固定的侧边面板，用户不离开对话也能关注工作进展。
- 接管：机器人需要帮助时，用户可以全屏打开电脑，接手控制，然后再交还给它。
我们还设计了随一天时间变化的壁纸，早晨更明亮，夜晚更暗。这个细节赋予机器人的电脑自己的时间感，也让人感觉它与你的桌面相互独立。
这更接近与同事协作的体验，而不是操作一台远程机器。你知道它在工作，需要了解情况时可以瞥一眼屏幕，遇到需要帮助的事情时再坐下来接手。
信息的形态
早期版本的 Grok Bot 几乎对所有请求都用文字作答。它会描述五天天气预报，而不是直接展示；会叙述一组任务，而不是把任务摆到看板上。用户随后还得重新组织答案。这促使我们把回应的形式也视为答案的一部分。
为此，我们在 Grok Bot 中加入了内联卡片和小组件。适合文字表达的信息，机器人可以用文字回答；不适合时，就使用结构化界面。
同样的原则也适用于行动。当机器人创建例行任务、更改设置，或给另一个机器人发消息时，这个事件可以直接出现在对话记录中。如果有更多内容需要检查，用户可以打开查看。
最终形成的是一种混合式对话记录：交流、系统事件、交互对象和可视化内容共享同一条时间线。
组织智能
当用户创建多个机器人后，产品还必须组织它们之间的协作。我们需要决定哪些上下文归属于哪个角色，在工作交叉时机器人应如何共享上下文，以及如何协调它们，同时不让用户变成任务调度员。
随着用户创建更多机器人，我们看到一种答案自然浮现：有人创建了一个“幕僚长”机器人，负责协调多个专业机器人。这样，用户只需向一个机器人交代方向，而不必逐一检查并亲自分派每项任务。
赋予机器人不同角色，也迫使我们决定每个角色应该知道什么。法律机器人可能需要了解某场持续争议的来龙去脉，财务机器人则可能需要多年的财务记录。把这些历史合并成一大块记忆，反而更难为每个机器人提供与其工作相关的信息。
因此，在 Grok Bot 中，能力与上下文有着不同的边界。工具和技能属于账户层级，因为许多机器人都可能需要浏览网页、处理文档或发送邮件。记忆与例行任务则属于具体机器人，因为它们反映的是该角色长期知道什么、做什么。换句话说，能力可以广泛共享，而上下文留在需要它的角色那里。
有些工作会跨越这些角色边界。群聊为项目或团队提供共享上下文，同时允许各机器人保留自己的专业记忆。设计师、工程师、产品经理和数据科学家可以在同一段对话中协作，彼此交接工作，并共享项目所需的信息。
我们考虑过增加仪表盘、任务分配看板和明确的交接控件来管理这些群组。但每增加一种，就给用户增加一份协调工作。最终，我们让协调型机器人处理日常任务分派，只在决策需要判断时才请用户参与。
让工作持续推进
多数智能体会话始于用户发送提示词。即使是持续存在的机器人，也因此要等着别人来启动它。例行任务让用户可以交给机器人一项长期职责，按时间表或响应事件执行，例如关注某个行业，或每天早晨准备简报。用户只需定义一次工作，例行任务便会在需要时激活机器人。
起初，我们把例行任务视为次要设置。随着它对自主工作越来越重要，我们将它移入机器人的主界面。对话记录会展示哪些任务已经运行，也给用户留下检查结果或处理异常的位置。
这也改变了对话的作用。提示词可以开启会话，时间表、事件或另一个机器人同样可以。随着时间推移，越来越多的工作可能在用户完全不在场时启动。
逐渐消失的界面
到了项目后期，很大一部分设计工作都在做减法。我们移除了窗口和面板控件、电脑视图选项以及智能体元数据。我们还设定了实际使用上限：每个账户大约 50 个机器人，每个群聊 6 个。每个决定都回到同一个问题：它是在帮助用户委派工作，还是又给了用户一件需要管理的事情？
随着模型能力提升，“操作一个 AI”和“把工作委派给同事”之间的界线不断变化。Grok Bot 体现了我们对这条界线当下位置的判断。从最早的探索到正式发布，Grok Bot 的设计一直是在寻找这条界线，并帮助界面随之变化。当智能体承担更多责任时，界面就应该对人提出更少要求。
原文标题：Designing Grok Bot for a world of persistent agents
原文发布日期：2026 年 9 月 3 日
原文链接：https://x.ai/news/designing-grok-bot
配图与视频均取自原文演示。头像、生命周期、执行进展及卡片切换以高清静音循环视频呈现，壁纸保留原文的静态对照展示；完整点击交互请前往原文体验。
0 条评论，48 次阅读