「帮我整理一下昨天的销售数据，生成一份分析报告发我邮箱。」这句话放在传统CRM里，用户得先被一堆筛选条件、按钮和导出选项劝退。但在AI Agent产品里，它只是一个完整的需求描述。问题也随之而来：用户敢不敢把一件事彻底委托给一个看不见状态、摸不清能力、可能中途犯错的系统？这恰恰是AI Agent交互设计要解决的核心命题。
我做AI产品有段时间了，从最基础的聊天机器人，到能自主调用工具、串联多个子任务的Agent系统都碰过。一个很深的体会是：AI Agent的交互设计和传统软件交互设计，根本不是同一个物种。传统软件的核心交互是「指令—响应」，用户点按钮、填表单，系统执行确定的结果；AI Agent的核心交互是「委托—信任」，用户给目标、给资源、给边界，Agent自己拆解任务、挑选工具、执行动作、交付结果。对象变了，路径变了，连用户出错的姿势都变了。
这篇我们不聊大模型原理，也不写LangGraph源码教程，就单纯从产品视角聊聊：AI Agent的交互设计到底该怎么想、怎么做、怎么验证。适合正在把Agent产品化的产品经理、交互设计师，也适合天天写代码但想补产品视角的工程师。
1. 交互对象变了：从「软件工具」到「AI同事」
1.1 传统界面里的菜单，本质是一张能力清单
传统软件交互设计有个根深蒂固的根基，叫功能可见性。打开Word能看到工具栏，打开Excel能看到单元格区域，打开一个后台管理系统的第一件事是看侧边栏菜单。为什么？因为软件功能是有限且确定的，设计者可以把所有能力铺在界面上，用户按图索骥，大不了挨个点一遍。
Agent打破了这个基础。一个Agent背后可能挂了十几个工具，连着不同的数据源，还能自己决定调用顺序。你不可能把所有工具平铺到一个界面上，就算铺了用户也看不懂——一个叫「数据库查询」的按钮和一个叫「生成图表」的按钮之间，隔着用户根本不知道的一长串推理。
这就带来第一个产品视角的转变：Agent产品的交互设计，第一件事不是设计界面的视觉元素，而是设计「能力表达的路径」。用户从哪里知道它能做什么？不能做什么？做到什么程度？别小看这个问题，大量Agent产品翻车就翻在用户不敢开口。
我见过一个内部数据Agent，团队花了两周把各种数据分析能力都接好了，结果上线一周用户最高频的问题是「你能干嘛」。这不是用户偷懒，是产品没有把能力翻译成用户可以理解的语言，只留下了一个孤零零的输入框。
1.2 认知负荷没有消失，只是从用户手上搬到了Agent手上
传统设计理论反复强调「不要让用户思考」，所以会有路径引导、表单校验、按钮置灰、空状态提示。Agent产品里，「怎么做」这件事确实由Agent承担了——它做任务拆解、工具选择、异常重试。但交互设计面临的挑战反而更大了。
为什么更大了？因为用户虽然不用再思考操作路径，却被迫在另一个层面思考：我该用这句话表达目标吗？它听懂了没？它干到一半跑偏了怎么办？结果半对半错怎么改？原本分散在每个操作步骤上的认知负荷消失了，但被重新压缩成三个更重的瞬间——下指令前、执行中、验收时。
从产品经理的视角，得完成一次切换：我们要设计的其实不是用户的操作流程，而是用户的「委托流程」和「监督流程」。委托端，要让用户低成本说清目标；监督端，要让用户随时知道Agent在干嘛、干得对不对、需不需要介入。这两个流程设计的好坏，直接决定用户是把Agent当成靠谱的助手，还是当成一个需要时刻盯着的定时炸弹。
1.3 用户心智模型：用户会把Agent当「人」来相处
有个现象值得产品经理注意：用户跟Agent对话时，不自觉地就会把它当人对待。说「请」、道谢、甚至不耐烦。心智模型决定了用户对Agent的期待和行为模式。
如果用户把Agent当工具，他会要求每次输出完全一致，不能接受一点偏差；如果用户把Agent当「数字同事」，他对试错的容忍度会高一些，但同时对「别人犯错」的愤怒感也会更强——因为他对同事的期待不止是准确，还有负责。
产品设计在这里必须选边站。我实测下来的经验是：把Agent塑造成一个有名字、有头像、有固定语气、会解释自己行为的角色，用户上手更快，信任建立更顺。但这也会抬高用户的期待，一旦Agent在低层次错误上翻车，比如把日期算错了，用户的挫败感会远高于「工具出错」。所谓交互设计，某种意义上也是在管理这层期待落差。
2. 意图书写：用户「开口」的第一句话，产品得为它铺路
2.1 空白输入框是最难设计的界面
不管Agent背后多复杂，产品形态上大概率逃不过一个输入框。ChatGPT验证了这种形态的低门槛，但也把一个问题甩给所有Agent产品：用户面对空白输入框时，根本不知道该说什么。
传统搜索框好歹还有个placeholder提示「搜索你想要的」，但Agent的能力范围词不达意，用户写浅了怕它听不懂，写深了怕自己不会，写具体了又怕漏掉关键条件。这个不确定性会让用户迟迟不开口。
产品上能做的事很明确——别让用户从零开始造句：
第一，输入框下方常驻「能力引导卡片」，列出这个Agent最擅长的3到5类任务，比如财务Agent就放「生成月度经营分析」「核对供应商账单」「预测回款风险」；
第二，引导卡片可点击，点进去自动带入一段带空位的任务模板，用户只需要把具体时间、范围、对象替换进去；
第三，做一个「官方示例库」，像短视频App的搜索热词一样，让用户看到别人是怎么让Agent干活的。
这招的效果极其明显。把「凭空想一句话」降维成「填空」，用户的首次输入成功率至少能翻一倍。别觉得这设计蠢，真实用户比设计师想象的更不知道自己要什么。
2.2 澄清设计：一次问完，还是边做边问？
用户开口之后，信息往往不完整。「帮我把数据整理一下」，哪个数据、哪个口径、哪个时间范围、什么格式？Agent交互里最忌讳的就是猜错还硬做——一次瞎猜能把前面建立的全部信任清零。
但澄清也不能变成审问。我见过一些Agent产品，用户说一句，它「为了更好地帮助您」连环问五个问题。用户直接跑了。产品设计上，澄清要分级，不能一刀切：
所谓低信息需求，是指Agent凭默认配置就能做出一个「基本可用」的结果。比如「帮我写一份周报」，时间默认本周，风格默认简洁，结构默认三段式。这时候正确的交互是直接做，做完了在结果顶部标注一句「我按本周、简洁风格生成，如需要调整告诉我」。
中信息需求，要给选项而不是开放填空。问「用折线图还是柱状图」比问「您想用什么图表类型」好一千倍。选项式澄清把回答成本降到了最低，用户随手点一下就行。
高信息需求，才值得结构化追问，比如发送邮件给谁、定时任务设置在几点、删除范围覆盖哪些数据。这类信息没有默认值，或者默认值风险太高，必须问清楚。
一条核心原则：每个澄清问题都要自带默认答案。如果一个澄清问题的答案是开放填空，等于把认知负荷又丢回给了用户，那Agent就白替用户思考了。
2.3 把用户偏好变成可管理的上下文资产
多轮交互里，用户会自然暴露偏好。「用折线图吧」「别发邮件了，发企业微信」「对齐上个月的格式」。如果这些偏好只活在单次会话里，用户每次都要重新说一遍，那Agent跟普通脚本有什么区别？
产品交互层面要做的事，是让偏好变成用户可感知、可管理的资产。交互落地上，可以在会话侧边栏放一块「Agent了解到的你的偏好」，列出「图表偏好：折线图」「汇报对象：李总」「输出格式：PDF」这些条目。每条后面带个删除按钮，用户觉得系统理解错了可以随时移除。
这个设计最微妙的地方在于：它把「Agent懂我」这个原本玄学的东西，翻译成了用户可以控制的工具。我不需要知道Agent是怎么学的，但我能看到它学到的结论，并且我有权力纠正或删除。这种可控感比任何算法先进程度的宣传都管用。
3. 执行过程可见性：别让用户对着一个加载转圈干等
3.1 黑盒焦虑是怎么来的
Agent执行一个复杂任务，可能需要几十秒甚至几分钟。如果界面上只有一个转圈的loading，用户的体验是崩溃的。这不是耐心的问题，是人类天生对不确定性等待的容忍度极低——等待不可怕，可怕的是不知道要等多久、不知道等来的是什么、不知道过程是否在正常推进。
产品设计上有一个我反复验证过的结论：用户真正想要的不是「快」，而是「有进度感、有掌控感」。哪怕实际耗时没有缩短，只要用户能看到Agent正在按步骤做，焦虑感就会大幅下降。
3.2 把扁平loading改成结构化任务流
好消息是每个Agent在执行复杂任务时，天然可以拆解成多个子任务。产品上要做的，只是把这个拆解过程用「任务流卡片」的形式呈现出来。
举一个周报Agent的例子。用户输入「生成上周销售周报」，界面上立刻展开一张任务流卡片：
读取销售数据源 → 清洗并校验字段 → 计算核心指标 → 生成图表 → 撰写分析结论 → 等待确认发送
这里有两条交互细节，都是踩过坑才明白的：
第一，任务流卡片默认只展示主干，3到5步为宜。子步骤再多也折叠进「详情」里，不然信息过载，用户根本盯不过来。大多数用户只关心一件事：现在到哪了。
第二，每个已完成步骤要支持点击查看「结果快照」。比如「计算核心指标」完成后，允许用户点进去先看到中间数字。这样用户不用等整套流程跑完，就能提前验收，发现问题还能及时叫停。如果所有结果最后一次性憋出来，发现方向错了，前面的时间全白等。
3.3 决策点插话：什么该问，什么不该问
Agent执行过程中一定会碰到分支决策。产品和交互设计要做的，是定义清楚哪些决策Agent可以自主，哪些必须让用户参与。
我的分级策略如下，可以直接抄作业：
- 无感知级：低风险、可回滚，比如读取资料、画图、生成草稿，Agent自己干，只在结果里汇报；
- 轻确认级：会产生外部副作用，比如发消息、发邮件、调外部接口，执行前必须弹出确认卡片；
- 强制确认级：不可逆或高成本，比如删除数据、覆盖文件、触发付费接口，不只是确认，还要二次输入原因。
产品功能上，建议把这几级做成用户可调的「运行权限」开关：只读模式、确认模式、全权模式。用户处理低风险任务时切到全权模式，图个爽快；处理关键任务时切到确认模式，求个安心。
这套设计既是产品能力，也是交互屏障。它给用户的潜台词是：「我不会乱来，而且乱来的边界由你定。」
4. 容错设计：Agent出错之后，交互才真正开始
4.1 Agent的错误类型比传统软件复杂得多
传统软件的错误是可枚举的：字段校验失败、404、超时、库存不足。每一种错误都有明确的错误码和与之对应的提示文案。Agent的错误就野了：它可能误解了用户的意思、调错了工具参数、生成一半对一半错的内容，甚至特别自信地给出一个编造的数字。
产品视角应对错误，第一步是把错误分类，而不是笼统处理。我习惯把Agent错误分成三类：
- 意图理解错误：用户说A，Agent听成B。这类错误应该死在澄清阶段，如果没拦住，用户会在结果里发现「牛头不对马嘴」；
- 工具执行错误：数据源连不上、字段名写错、接口超时。这类错误有明确的技术根因，适合展示重试或让用户换参数；
- 内容质量错误：任务做完了，但结果半对半错。比如报告里大部分数据对，某一页的分析完全跑偏。这类错误最麻烦，用户需要的是局部修改能力，而不是整篇重来。
每种错误类型对应完全不同的交互策略，不能一个「抱歉出错了」的弹窗覆盖所有。
4.2 撤销和回滚，是Agent产品的生命线
一个能自主执行多步骤的Agent，最危险的事情是什么？做了不可逆的操作。如果产品让这类事情发生，信任崩塌是瞬间的。
交互设计层面必须同时做到三件事：
一是完整的操作历史列表。按照时间倒序记录「什么Agent在什么时间做了什么操作」，用户可以随时查阅。这既是透明化，也是事后追责的依据。
二是快照回滚能力。对文件、数据状态做版本备份，用户发现不对可以一键回到上一步。没有快照的Agent产品，本质上是在让用户裸奔。
三是不可逆操作的前置强提示。删除数据、对外发布、覆盖文件，这类操作要给出醒目的红条提示，甚至要求用户输入「确认执行」四个字。
我身边有过一个真实案例：一个运营Agent误解了「做活动」的意图，自动把商品折扣调到了三折。万幸当时产品里所有价格修改都是「待确认」状态，运营人员在确认页拦了下来。这个惨痛教训之后，凡是对外发布类操作，我们一律设置为强制确认级，不允许任何授权模式绕过。
4.3 失败信息要结构化，让用户一起参与诊断
Agent失败的时候，最常见的交互就是一个弹窗「抱歉，我出错了」。这是最糟糕的失败设计，它把用户完全排除在诊断过程之外。用户不知道Agent错在哪，不知道自己还能做什么，只能重来一遍——重来的结果很可能是再次失败。
更好的做法，是把失败信息结构化，给用户三个层面的信息：
- 尝试了什么：展示已经执行的子任务列表，标记出失败的那一步；
- 为什么失败：把工具返回的错误信息翻译成人类能看懂的话，不要把「KeyError: 'ctr_rate'」直接怼给用户；
- 下一步可以做什么：明确给出2到3个补救选项。
举一个我设计过的失败反馈示例：
「我在第3步生成图表时失败了，原因是数据源里的『转化率』字段为空。你可以：1）补充该字段后重试；2）暂时改用『点击率』字段生成；3）查看原始数据，确认字段是否命名有误。」
这种设计把「失败」从终点变成了路径。用户看到的是：这个Agent知道自己在哪一步失败、失败原因是什么、还有路可走。这种感觉比「永远不失败」更真实，也更能建立长期的信任。
5. 多Agent与业务流程编排：交互设计从单点扩展到团队
5.1 用户面前该站一个Agent，还是一群Agent？
技术层面，用LangGraph、Dify这类框架编排multi-agent已经很成熟，让一个「规划Agent」拆任务，再分派给多个「执行Agent」，最后汇总给用户。但产品层面必须回答一个交互问题：用户看到的是一个Agent，还是多个角色分工的Agent群？
我的建议是：默认统一入口，只有角色感知能显著降低理解成本时才暴露多Agent。原因是用户认知带宽有限，跟一个Agent建立信任已经很费力了，眼前突然站着五个Agent，用户会陷入「该找谁」的迷惑。
但也有例外。当一个复杂任务天然由不同角色协作时，把分工展示出来反而清晰。比如一个「数据分析Agent」负责取数，「风险审核Agent」负责校验规则，「报告撰写Agent」负责输出文案。让用户看到这三个角色各司其职，比看到一个「超级Agent」内部切换状态要直观得多。
交互细节上有一条要注意：给用户看的Agent角色名，不要用技术层命名，要用业务语言。叫「风控审核员」不叫「guardrail_agent」，叫「数据专员」不叫「database_agent」。
5.2 任务编排的交互语言：向项目管理工具取经
多Agent协作时，用户脑子里最需要的画面是一个「指挥室视图」：这次任务分成几个环节，总负责人是哪个Agent，每个环节现在什么状态，有没有环节卡住了，需不需要我提供信息。
这些需求听上去很熟悉——就是项目管理工具那套交互语言。不用重新发明，直接借鉴：
任务列表要展示每个子任务的负责人（哪个Agent）、状态（等待中、执行中、已完成、需人工介入）、耗时。某个Agent卡住超过一定时间，要有醒目的超时提醒，同时自动尝试降级方案或通知用户。
用户不需要理解内部的编排逻辑，只需要像看团队看板一样知道一件事：现在整体进度怎么样，我要不要再给点信息。
5.3 权限边界与责任归属，是多Agent不可回避的交互命题
Agent一旦多了，「边界感」就必须通过交互设计传达清楚。每个Agent能访问哪些数据、能调用哪些工具、由谁授权，产品至少要做到用户可查。
对内场景，我给每个Agent设计了一个「数字工牌」——点击Agent的头像或名字，弹窗里显示它的数据权限范围、可用工具列表、操作记录。用户看到这个Agent只有只读权限，就能放心交给它分析大量内部数据。
对外场景更关键，涉及责任归属。交互设计上至少要明确：任何会产生外部影响的操作，最终提交人都必须是用户本人。系统里要记录「由XX用户确认后提交」，而不是「Agent自动提交」。这个设计不光是安全底线，也是让用户在多Agent场景下保持掌控感的关键——他始终是最终的签字人，别的Agent只是干活的人。
6. Agent交互设计的度量：用数据验证「好不好用」
6.1 传统产品指标不够用，要加Agent场景特有维度
传统产品都在看任务完成率、转化率、停留时长、次日留存。Agent产品这些指标依然有用，但不够。还有一些新指标更能反映Agent交互设计的真实水平：
| 指标名称 | 定义 | 说明 |
|---|---|---|
| 一次成功尝试率 | 用户首次描述需求后，未经澄清和纠正就成功完成任务的占比 | 衡量意图书写设计质量，太低说明入口引导差 |
| 平均澄清轮数 | 单个任务完成过程中，平均进行几次澄清追问 | 太高说明引导差，太低说明Agent可能猜得武断 |
| 人工接管率 | 用户主动停止、修改、回滚任务的次数占比 | 过高说明过程透明度和信任度不足 |
| 局部采纳率 | 用户只采纳Agent结果的某一部分的比例 | 偏高说明结果有可用价值但不够贴合需求 |
| 工具重试率 | Agent内部调用工具的失败重试次数 | 持续偏高说明数据连接或配置有问题 |
| 用户放弃率 | 任务开始后中途放弃的比例 | 对应过程设计和等待体验的失败 |
这套指标不是一次全上，而是根据产品阶段逐步补齐。早期产品先盯死「一次成功尝试率」和「人工接管率」，这两个直接反映用户敢不敢用、信不信。
6.2 从会话日志中读出用户的崩溃现场
指标只能告诉你「有问题」，不能告诉你「问题在哪」。要找出问题，最笨也最有效的方法是：定期抽读用户与Agent的完整会话日志。
我每周会抽200条左右的会话记录，专门标注「崩溃点」。重点看这几类信号：
用户连续两次改写同一个问题，说明第一版理解方向错了；用户说出「不是」「不对」「我说的是」这类纠正词，说明澄清机制失效；用户反复点击停止生成，说明过程反馈不足，等不下去了；用户直接要求「重做」，说明结果与预期偏差大到无法局部修改。
这些信号看起来琐碎，但每一次都能指向一个具体的交互设计缺陷。比如连续改写问题集中出现，往往是任务入口引导不够；反复停止生成，往往是没有按3.2节设计任务流卡片。
6.3 建立Agent交互健康度看板
把上面这些指标挂到同一个看板上，按三个观察层组织：
- 意图层：一次成功尝试率、平均澄清轮数、用户放弃率，反映的是「用户说得清说不清」；
- 过程层：人工接管率、停止生成率、平均等待时长，反映的是「用户盯得住盯不住」；
- 结果层：局部采纳率、工具重试率、用户投诉率，反映的是「结果靠得住靠不住」。
每周对比一次变化。一个健康的Agent产品，趋势通常是：意图层指标逐步稳定，过程层的接管率随时间下降——因为用户对Agent越来越信任，干预越来越少；结果层指标则跟着功能迭代波动。
把数据定为周级节奏，能帮助产品和设计团队在「感觉用户好像不喜欢」和「数据证明用户在这里流失」之间，快速达成共识。
7. 在真实产品里沉淀下来的五条交互设计原则
7.1 先给「最小可用答案」，不要憋大招
Agent产品很容易做重。用户问一个数据分析问题，产品恨不得生成二十页完整报告，用户干等半分钟。更好的交互节奏是：先给一个「基本够用」的答案——几句摘要、一组关键数字、一张简单图表，让用户先看到价值。用户说「展开」，再逐步深入细节。
这种做法的好处有两个：等待粒度变细，用户感觉快；如果方向不对，用户看一眼就跑偏了，还来得及止损，不会出现「等了很久结果全错」的崩溃场景。
7.2 能力边界要明示，不要藏着掖着
Agent产品的能力边界是最有价值的引导信息。开场引导语、帮助中心、权限列表，都应该写明「我可以做A、B、C，目前做不到D」。别怕这句话显得功能弱，实际上用户对限制的容忍度远高于对意外的容忍度。
我做过一个真实改动：在一个数据Agent的欢迎语里加了一句「我不会删除任何数据源，所有写操作都需你确认」。结果一周内，主动使用率提升了近20%。用户看到一个被明确约束的Agent，反而敢放手用它去做更多的数据分析。
7.3 让用户待在「监督位」，而不是「求人位」
用户和Agent对话时，最危险的心理状态是「求人办事」——提心吊胆，不敢打断，不敢追问。交互设计要主动打破这种状态。
具体做法不复杂：Agent执行过程中，停止按钮、修改任务按钮、查看当前进度按钮都必须常驻可见；用户随时开口打断，Agent要能停下来重新理解。设计上每出现一个不确定状态，旁边就要给一个「可选操作」。时间长了，用户会形成一种感觉：我控制着它，而不是它在拖着走。
7.4 每一次成功交互，都是下一次的上下文
单次任务的成功不应该成为孤例。用户在这轮对话里确认过的格式偏好、纠正过的错误表达、用过的任务模板，都应该沉淀成产品级记忆。下一次用户执行类似任务时，Agent可以主动问一句：「上次你用折线图加周维度展示，这次继续吗？」
追问的成本极低，但对体验的提升是质的。用户会感觉到这个Agent「记得我」，而不是一个来一次就失忆的机器。偏好条目管理仍然参考2.3节的方法，让用户随时能看到、能删除。
7.5 交互复杂度跟着能力扩张走，别一口气全上
最后一条，大量Agent产品不是死于技术不行，而是死于「一上来就想解决所有问题」。产品视角最稳妥的路线是：先打通一条完整工具链——一个明确目的、两个核心工具、三次以内的请求交互——把这条链路上的对话、澄清、执行反馈、容错完全打磨顺畅，再横向扩张。
交互设计上要守住一个原则：每一次能力扩张，都必须是用户看得懂的能力扩张。新增一个工具按钮很容易，但要让用户理解这个按钮什么时候有用、用了会有什么效果，难度是指数上升的。收敛住扩张冲动，把一条链路的体验打磨到极致，比铺开一个庞大的Agent矩阵更能赢得用户。
说实话，Agent的交互设计到现在也没有一套放之四海而皆准的标准答案，我每个版本都会推翻自己上个月的某些判断。但有一条体会一直很坚定，想留给同行：用户最终喜欢的，永远不是最聪明、能力最强的Agent，而是那个「我看得懂、管得住、信得过」的Agent。这不是一句口号，而是所有交互设计决策的出发点。
