从人机交互到人机智能体交互：Palantir 设计师的协作设计模式

摘要

Palantir 的三位产品设计师 Emily、Lita 与 Philip 在 DevCon 6 上拆解了 AI 时代最棘手的设计课题：人机智能体协作。当智能体以人类设计师十倍的速度工作、智能体还能孵化出子智能体时，熟悉的聊天框界面范式即将整体改变。他们的核心论断是：这个时代的设计本质上是关于信任——用户必须理解智能体如何得出决策，否则一切界面都只是包装。

演讲总结了三个现场常见的 UX 错误与对应模式：第一，用户看不懂智能体的决策过程——解决方案是明确标注「这份内容由 LLM 生成」、用多智能体推理面板替代冗长的思维链；第二，人机工作流彼此割裂——聊天框脱离主工作流、方案要靠复制粘贴搬运，解决方案是把智能体工作流嵌进用户正在工作的地方，并给用户多个方案选择；第三，纯文本响应是死胡同——要用来源、本体引用、代码片段与可折叠的推理链把响应「喂饱」。

彩蛋部分直指 AI 生成应用的「同质化脸」：靛蓝粉紫渐变、玻璃拟态、表情符号图标。解法不是禁止 AI 写代码，而是三件套——共享 OSDK 组件库、把设计主张编码成智能体可读的 DesignMD、以及可复用的智能体技能（agent skills）。

正文

一、信任时代的设计：为什么 AI 时代的 UX 全是信任

过去几年，AI 设计模式随着智能体越来越强大而快速变化。在座每个人都记得为人机交互（human-computer interaction）原则设计用户界面，但现在要做的是「人机智能体交互」（human-computer-agent）原则——智能体以人类设计师十倍的速度工作。Emily 开场先给了个参照系：今天那个谦逊的聊天机器人界面——大家最熟悉、最舒适的 AI 交互方式。但正如当天 keynote 里的 Agent Engine、编排器（orchestrator）、持久化函数（durable functions），我们面对的是「智能体孵化智能体、与用户并肩工作」的界面复杂性——整个界面范式即将改变。

作为构建者与设计师，我们的工作是帮用户熟悉这项快速变化的技术——无论是交互式智能体还是长时运行（long-running）的智能体。接下来要谈的现场常见 UX 错误，单独看可能很小、很明显，但正如今天反复听到的：在这个 AI 时代设计，一切关乎信任。大量 UX 原则本质上是为用户建立信任，让他们确信我们理解他们的工作流、理解智能体将如何与他们并肩工作。

二、错误一与错误二：隐藏的决策链、割裂的人机工作流

错误一：很多用户根本不理解智能体是怎么得出决策的。 案例是某卫生机构的应用：构建者写了一批逻辑函数来生成疫情暴发调查（outbreak investigations），帮助用户监测并对潜在疫情做决策。这个界面的问题：用户不确定这条 AI 响应是智能体生成的还是人写的；思维链（chain of thought）组件密度过高，界面里到底发生了什么很难懂；更危险的是「危险的信息遮蔽」——界面展示了 AI 生成了数据报告、智能体在决策，但人类其实也在中间审批调查、从 LLM 输出中做决策——这些在应用里完全没显示。

修复模式：绝对要在界面中标注工作是智能体还是用户产生的。第一处改动是简单明了的英文文字指示——「这份数据报告由 LLM 生成」，简单却极有帮助。第二处是构建一个新组件替代单一思维链：把多个智能体（本例中多个逻辑函数）与人类动作放进同一个面板。设计团队花了大量时间思考分析师如何「快速理解发生了什么」，而不是暴露完整 LLM 推理；用户一眼看到谁参与了决策——是人还是智能体——想深究时可以点开小卡片看更多推理。随着系统越发复杂，他们还迭代了展示复杂系统的模式：左侧是表示编排器智能体的节点布局——负责触达更广的智能体网络，技术型用户喜欢这种粒度，能看清智能体链在哪里调用了别的智能体；右侧则是多智能体的时间线简图——看清「派生了什么、输出了什么」。记住：智能体输出仍然是非确定性的，要为用户提供理解决策如何做出的途径。

错误二：人类与智能体的工作流彼此分离。 案例是一个管理法律协议的 AI 应用：智能体聊天功能被孤立在主工作流之外——聊天一旦脱离主工作流，就没有用户正在做什么的上下文；聊天里生成行动计划后，用户要手动复制粘贴到中间的输入框——「这感觉就是个坏掉的工作流」；而且后续每次迭代都只能回到聊天面板里重复这个坏流程。

反例是给一家顶级律所构建的基金设立引擎（fund formation engine）：律师们要在极大的时间压力下审阅、起草复杂的基金协议。亮点依次是：智能体状态显示它正在当前任务上下文中工作，下方行项目能看出它在做什么——响应还没到，用户已在回路里，信任已经建立；用户得到多个方案供选择，而不是单一 AI 响应——把「接下来发生什么」的控制权交给用户；悬停建议时出现小标记，说明这来自智能体而非人类——推进前用户必须审阅；智能体不仅给提案，还展示为什么这样组织响应、附上原始来源，用户可以直接查证、做知情决策；最后，用户可以在批准前对智能体方案做最终编辑。两个加分细节：智能体主动请用户补充上下文以提升输出质量——「当智能体提问而不是假设时，就把人留在了回路里」；拿不准时，智能体可以只填一半、请人来审。核心教训：与其让智能体和人分开工作，不如把智能体工作流集成到用户正在做的工作里。

三、错误三：纯文本响应是死胡同——用平台丰富响应

错误三：纯 Markdown 文本响应是死胡同。 案例是跑智能体分析的应用：智能体响应是一大块文本——没有资源引用、没有来源、没有本体，几乎不可读，而且无法交互，不能带你去看智能体在平台里如何做出决策。他们试过为聊天响应做可视化概览，但没测试这种规模的复杂度——圆点彼此重叠，随聊天复杂度增长无法扩展。

修复：用来源、本体与引用丰富响应。重新设计的面板把具体资源直接渲染在文本里：对应的子智能体作为活实体链接、知识节点用 ID 引用、本体里的引用在聊天中有专门的视觉处理；组件可折叠，用户可以窥探智能体思维链——从提示词到响应的所有事件的详细拆解；还能拿到过程中生成的确切代码片段与工件，而不会一上来就淹没用户。给一位高管展示时，他立刻理解了：LLM 响应不是凭空编的，底层真的在跑代码。另一个相似例子：文本块下方列出来源清单，让用户交叉核对原始材料、确保决策质量。记住：如果你的智能体响应只是生成原始文本，想想如何用平台本身的丰富性去充实它。

四、彩蛋：让应用看起来不像 AI 垃圾——组件库、DesignMD 与技能

最后一个彩蛋是 UI 修复：如何让应用看起来不像「AI 垃圾」（AI slop）。网页编程改变了谁能构建——人人都能做出能用的产品，但模型越擅长把东西做得光鲜，就越擅长把东西做得千篇一律，用户已经注意到了。Philip 一眼识别 AI 生成应用的三个标志：调色板（靛蓝、粉、紫渐变铺满背景、按钮甚至页眉）；玻璃拟态（glassmorphism）无处不在；用 emoji 代替真正的图标设计——「你能看出没人认真设计过真正的图标系统」；还有与内容无关的布局：在数据密集的领域选了极低信息密度的布局。

单看一个应用，这些小毛病好修；真正崩坏发生在管理多人团队、多产品时——每个人都在无共享护栏地网页编程，不一致随之而来：跨 10 到 20 个应用，主色每个产品都不一样、导航栏有时在顶部有时在侧边，用户每次打开不同工具都要重新学一遍界面；更糟的是，同一个表格组件被五个人做出五个略有差异的版本——五倍维护、五倍 bug、代码库越来越难维护。

解法不是砍掉让网页编程伟大的速度，而是三件套，全都「与智能体协作而非对抗」：第一，共享 OSDK 组件库——年初开始收集跨产品反复出现的组件（对象表格、过滤器列表、多文件类型查看器、动作表单），智能体不必从零重造，还支持主题化、懂你的本体、测试更充分。第二，DesignMD——一个把真实设计主张编码成智能体可读格式的 Markdown 文件：字体、间距、颜色、品牌，还能直接从 OSDK 组件库的 Storybook 里改色导出。第三，智能体技能（agent skills）——可复用的小包流程，工作流智能体需要时直接调用而不用即兴发挥；Palantir 已备好大量有观点的设计技能起步，技能可以作为 Foundry 资源创建，AI FDE 支持使用、创建与编辑——提到与技能相关的事，它就会加载并开始使用。总结：用共享组件库起步、用 DesignMD 保证好看与品牌一致、再用智能体技能把这套风格推广到你的另外 10 到 20 个产品——覆盖信任与归属、鼓励协作、丰富响应、UI 修复四个人机智能体设计主题。一起设计和构建一个更好的人机智能体协作世界。