如何为 AI 智能体设计 GUI

智能体的标准界面是命令行或侧边栏。两者本质上都是一份日志：用户输入，智能体回复，每次工具调用都被记录。通常智能体在视野之外工作，而人则审阅返回的结果。每一次往返都拉大了智能体所做之事与人所理解之事之间的差距。对于长任务而言，这种差距就成了极限，人只能选择信任结果，或试图重建过程。

另一种选择是更视觉化的方式。即，智能体在用户的文档中、在用户身旁工作，这样它的工作可以在运行过程中被引导。视觉表演与有洞察力的可视化之间只有一线之隔。一般来说，在视野之外工作能完成更多事情；而在视野之内工作能让用户保持方向感，并能在过程中教会他们。我们的目标是找到摩擦的“最佳平衡点”，在用户对齐与工作产出之间取得恰当的平衡。

1. 空间解析型智能体

这类智能体像同事一样在文档中工作。它有一个光标和一个名字，会移动到正在处理的段落，它的编辑以修订痕迹的形式在你眼前出现。同样，它会避开他人已认领或锁定的部分。

这让编辑更加直观可感。在侧边栏中，智能体的工作是事后阅读的一份报告。而在文档中，你能看到它出现在所应用的位置，这让引导（打断和修改指令）更加直觉化。

与此相契合的是由用户控制的红线（已批准的差异）这一概念。同样，摩擦更多。但每一个被接受或拒绝的更改都保留在版本控制中，这段历史之后可以反馈给智能体，使其更接近用户想要的结果，Cursor 对此已有很好的阐述。^[1]

此外，通过在文档本身中工作，我们获得了更好的空间解析度，即“指向”能力。HN 上最近的一篇帖子（屏幕上的大箭头）让编码智能体可以在屏幕上的任何内容之上画出一个大箭头、一个方框或一行文字。^[2] 这或许是一种视觉引导，可以用来向用户展示软件的使用方法（即，我该怎么做这个？）。正如多智能体设计围绕人类协作原则展开一样，人们可以通过例如用记号笔高亮某物来交流，那么 LLM 为什么不行呢？

同样，我们尝试过同时使用三个光标。对大多数用户来说，实时消费时这信息量太大了。通过让智能体的操作可回放（例如通过视频产物）、可分离（例如单独查看每个光标的轨迹）以及可还原（通过版本控制），我们解决了大部分这类问题。本质上，当摘要对用户可操作时，它们就始终是可读的。

光标始终可以只是智能体侧边栏的一个附加项，由用户选择启用，以便更轻松地协作和引导。也就是说：智能体照常工作（同样的提示词 > 工具调用直到完成），但它会发出一个可选择跟随的光标。我们只是改变了用户关注和输入反馈的位置，而非改变智能体的工作方式。

2. 人与人之间的沟通

大多数真正的工作是共享的。同样，大多数智能体对话是单个用户私有的。

问题就变成了，什么才是有效的多人协作？是几个人使用私密对话来编辑共享的底层代码库吗？我们将其拆解为几个概念。

• 组织。公司按照已有的方式共享文档：面向整个公司，作为编辑者或查看者（某种 RBAC）。
• 项目。文档、事实和决策归属于一个项目，智能体与项目上的人员从同一处读取。
• 共享对话。如果工作由智能体驱动，而人们并未可靠地提交相关信息（例如在 git 提交中），那么智能体对话就成为一种工作产物，可以从中检索细节。
• 实时协作。同事们在文档中互相看见，认领章节，将其锁定以防 AI 介入，并回放草稿的形成过程。

• 锚定到文本的评论。评论双向解决了指向问题。它锚定到它所针对的文字上，因此人可以就“这个”提问，而智能体知道“这个”是什么。评论也是一种提示：在其中提及智能体，智能体就会读取该讨论串并在原地回复，即问题被提出的地方。智能体可以用十几条单独的评论来回答，每条针对其相关的段落，而不是一条冗长的回复。在画布上留下评论让智能体去拾取，感觉比在侧边栏中输入更自然。但这也增加了摩擦，需要更多点击。

• 评论中的图形。上述功能的扩展。评论是人们已经讨论文档的地方，所以智能体也应属于那里。一条评论可以携带图表、时间线或流程图，从文档自身的图形中绘制为实时产物，而不是作为图片粘贴。

评论和共享对话正在解决已知的问题：作者身份、位置，而且每个人都已经知道如何使用它们。我们已经看到诸如 Claude Tags 之类的组织工作流工具因此发展起来。唯一美中不足的是，要确保这些多样的前端表示使用相同的底层智能体框架和版本控制系统（这样一切都能获得同等程度的支持）。

3. 智能体之间的通信

智能体之间的两种通信模式经得起考验。

自上而下。协调者拆分工作，专家执行，最后通过一次检查读取全部内容。

推送。智能体在工作时也需要互相发送东西：一个发现、一个更正、一条变更的指令。这些消息应当是持久且有序的：接收方智能体会被告知消息来自另一个会话，而队友不能代表用户批准权限提示。^[3]

智能体之间的自由形式对话正是信息泄露和漂移的地方，阅读它就像阅读原始工具调用一样乏味。

人应该能看到智能体写入的共享记录：按章节划分的看板，例如两个智能体存在分歧的段落会被标记为有争议（因为语义差异）。你也可以自动解决这些冲突。大多数编程工具的做法是暴露问题并询问：你更倾向于 A/B/C？如果用户没有明确表达偏好，就选择一个由智能体中介的方案。这同样是一种选择性加入的摩擦。

智能体相互交互的网络“基本上是一种干扰”，因此我们组织工作以尽量减少智能体之间摩擦的概率（通过 DAG 等）。多个智能体贡献智能（通过读操作），而写操作保持单线程，这似乎是有用的。^[4] 类似地，Anthropic 建议大多数工作使用三到五名队友，并警告说两名队友编辑同一文件会导致覆盖。^[3] 我们在六月对文档得出了同样的结论：读操作可以并行，但写操作保持同步。^[5]

4. 知识图谱

用 3D 可视化数据听起来很吸引人。语义向量在概念上非常酷。但作为一种阅读文档的方式，它是我们做过的最没用的界面，原因有四。

一次呈现所有内容等于什么都没回答。智能体太混乱，无法点亮一条推理“路径”。一份简短报告很容易变成一百多个节点。

深度的代价大于收益。第三维以遮挡为代价换取空间：节点遮挡节点、标签相互碰撞等。在力导向布局中，节点所处的位置毫无意义，所以没人能知道什么东西在哪里——而语义聚类会掩盖其他更重要的结构信息。

答案通常是一个列表。更好的图会围绕问题重新排列自身。答案分成若干列，从左到右读起来像一条因果链。

知识图谱作为智能体的工作数据非常出色，但作为读者的视图则很差。智能体可以利用链接在修改某个章节之前检查什么依赖于它。人需要的是图中回答其问题的那部分，并经过排列使位置具有意义，下方附有文本。奥卡姆剃刀。

引述

一些匿名用户关于这个问题的引述：

• “把引导和做事分开。教我怎么做”之类的东西。“引导型智能体”而不是“做事型智能体”。”
• “看起来这是一种相当有用的方式，可以帮助婴儿使用桌面电脑” > “你见过用户吗？”
• “我觉得这在我几年前学习使用 Blender 并向 LLM 求助执行某些操作时会非常方便，比如‘如何显示我网格中所有顶点的法线？’”
• “通过向智能体发送更多消息来撤销它的错误很笨拙，而受跟踪的更改可以一键拒绝。”
• “我们人类在纸上也能做到这一点。我们可以指向某个东西，我们可以用记号笔高亮某个东西。为什么不也给 LLM 这些能力呢？”

结论

• 画出人必须核对的内容，而不是智能体已知的内容。知识图谱是智能体的数据。读者需要的是能回答问题的部分，其排列方式要让位置本身有意义，而文字只需一次点击即可获取。
• 把智能体的工作放在人们已经在交流的地方：共享对话、固定在文本上的评论，以及评审。
• 工作流是个愚蠢的术语，但越来越相关。AI 持续完善知识库。工作流必须持久且可引用。隐性示例是一系列 markdown 文件（编码语言描述，LLM 的终极货币）。或者，为了在任务上获得更高的可复现性，使用确定性程序，按规范修改，然后用回归门进行测试。

参考文献

1. Jacob Jackson、Ben Trapani、Nathan Wang 和 Wanqi Zhu，《通过实时 RL 改进 Composer》（Cursor，2026 年 3 月 26 日）<cursor.com/blog/real-time-rl-for-composer>
2. Franz Enzenhofer，《屏幕上的大箭头》（GitHub，访问于 2026 年 10 月 9 日）<github.com/franzenzenhofer/big-arrow-on-the-screen>
3. Anthropic，《编排 Claude Code 会话团队》（Claude Code Docs，访问于 2026 年 10 月 9 日）<code.claude.com/docs/en/agent-teams>
4. Walden Yan，《多智能体：实际有效的部分》（Cognition，2026 年 4 月 22 日）<cognition.com/blog/multi-agents-working>
5. Alan Yahya，《面向复杂任务的多智能体系统》（Lexifina，2026 年 6 月 25 日）<lexifina.com/blog/multi-agent-systems-for-complex-tasks>