我们在用 AI 执行长任务时，经常会遇到这样的情况：
你让 AI 帮客户成功团队排查续约风险：“找出高危客户、分析原因、生成挽回方案，再分派给对应负责人”。
Agent 回复：“开始处理。”
然后界面安静了十几分钟。
你不知道它查到哪一步、跳过了谁，也不知道发邮件、改 CRM 这些动作会不会被直接执行。
十几分钟后，它只给出一句：“已识别 8 家高危客户。”
但是这个数据是怎么来的，并不清楚，因此也不敢轻易相信。
当 AI 开始自己规划、调用工具、连续执行时，对话气泡已经不够用了。
这就是 Agentic UI 要解决的问题。
接下来，将通过先拆开 Agentic UI 的几个设计原则，再用一个完整的续约风险排查案例，把任务计划、执行状态、人在回路和结果呈现这条链路走一遍。
01
Agentic UI 的核心：任务执行生命周期
“Agentic”来自 agent。
它意味着 AI 不只是回答一个问题，而是能围绕目标持续规划、调用工具、执行动作，再根据结果调整下一步。
所以 Agentic UI 关注的，也不再只是一次次消息，而是一个任务从开始到结束，怎么被理解、执行、接管和审查。
GUI 围绕对象和操作组织，Chat 围绕消息组织，Agentic UI 围绕的是任务执行生命周期：
它准备做什么？现在做到哪？为什么这么判断？什么时候需要你出手？
并不是所有 AI 功能都值得做成这套东西。
链路越长、执行时间越久、外部动作越难撤销、结果越需要审查，就越需要 Agentic UI。
写文案、改一句代码、生成一张图，Chat 往往就够了。硬套任务计划、审批节点和状态机，只会把简单的事搞复杂。
02
三条设计原则：看得见、拦得住、收得回来
Agentic UI 真正要解决的，是三件事：认知过载、黑盒焦虑、失控恐惧。
对应到设计上，是三条原则。
1. 透明度：看得见
用户要知道 Agent 现在在做什么、为什么这么判断、计划有没有发生变化。
不是把所有日志都摊开，而是让重要信息在需要的时候被看见。
2. 人在回路：拦得住、改得动
关键动作不能只有“Agent 自己做”或者“完全不让它做”两个极端。
什么时候轮到人，能改什么，能批准到什么粒度，都需要界面明确表达。
3. 可逆容错：错了能收回来
Agent 随时可能会出错。
接口会超时，数据会缺失，判断会偏。
所以失败以后，应该尽量局部重试、局部修改，而不是整条链路推倒重来。
如果只能先做好一件事，先解决透明度。
用户连“它现在在干什么”都看不见，再精密的回滚机制也很难建立信任。
03
四个核心模块：一条任务链路怎么落到界面上
把一次 Agent 任务拆开，基本会经过四个阶段：
任务计划：开工前，我们说的是同一件事吗？
执行状态：进行中，它现在在哪？
人在回路：关键节点，现在轮到谁？
结果呈现：交付后，我凭什么信，然后能干什么？
这四个模块下面，又分别对应一组关键界面组件。
1. 任务计划
关键组件包括：
意图确认卡、参数编辑、风险声明、耗时预估、计划变更提示。
它解决的是：别让一个方向理解错了的 Agent，安静地跑完 13 分钟。
2. 执行状态
关键组件包括：
步骤轨道、工具调用、状态标签、真实进度、原始调用折叠。
它解决的是：别让执行过程变成黑盒。
3. 人在回路
关键组件包括：
授权卡、部分批准、局部重试、参数覆盖、影响范围提示。
它解决的是：关键时刻，把决策权交还给人。
4. 结果呈现
关键组件包括：
结果工作台、证据来源、置信度、变更对比、后续操作。
它解决的是：结果出来以后，用户凭什么信，又能继续做什么。
缺了计划，十几分钟可能白跑；缺了状态，就是黑盒；缺了接管，就是失控；缺了结果审查，东西出来了也没人敢用。
界面不会一上来就变成“三栏工作台”，
一种更合适的结构是：对话流做主轴，结果工作台按需浮出。
用户进来还是 Chat。
Agent 在对话流里理解需求、确认计划，然后开始执行；工具调用、异常提示、授权卡片都继续出现在同一条流里。
任务跑完，右侧工作台再浮出，占据主要空间，左侧对话流收窄成副轨。
工作台的出现，本身就在告诉用户：执行结束了，现在轮到你看结果。
执行过程留在流里，结果产物进入工作台，两者天然分开。
04
案例：从任务执行到结果审查，来完成一次体验设计拆解
任务：续约风险排查
找出未来 30 天内到期、且健康度明显下滑的客户，判断流失原因，生成挽回方案，并把高优先级客户分派给对应负责人。
这个案例几乎踩中了 Agentic UI 最难处理的几种情况：
链路长：检索客户、计算健康度、归因分析、生成策略、分派任务。
异步：整个流程要跑十几分钟。
存在高影响动作：发客户邮件、修改 CRM 等级、给同事派单。
结果必须审查：为什么判断这家客户会流失？置信度多高？没有证据，没人敢照着执行。
而且它一定会出错：CRM 超时、数据缺失、权限不足。
这些不是边缘情况，恰恰是 Agentic UI 必须正面设计的东西。
下面就沿着前面的四个模块，把这条任务完整走一遍。
4.1
任务计划：别让 Agent 一听懂就开跑
用户说完需求，Agent 先回一张意图确认卡：
到期时间窗口、健康度下滑阈值、是否包含试用期客户、数据来源，再列出五个步骤和预计耗时。
口径没对齐，10几分钟之后才发现，前面全白跑。
1. 真正要提前说清楚的，是风险
卡片底部明确声明：
修改客户等级、发送挽回邮件、创建同事任务，这几类动作不会自动执行，到了对应步骤会单独申请授权。
授权的心理安全感来自可预期，而不只是权限本身。
不提前说，用户会担心 Agent 会不会直接把邮件发出去，接下来十几分钟也会一直盯着。
2. 可编辑，不等于什么都能编辑
原型里只有“健康度下滑阈值”可编辑，其他参数只读。
因为只有这一项合理范围足够宽，而且直接影响结果。
如果所有字段都能改，这张卡很快就会退化成配置后台。
意图确认不是配置中心。
3. “预计 多长时间”不是装饰
这几个字直接决定用户是继续守着，还是切出去干别的。
你做了一个能后台跑 10几 分钟的 Agent，却设计了一个必须前台盯 10几 分钟的界面，那异步能力等于白做。
4. 计划变了，也要告诉用户
运行到第三步，Agent 发现 12 家客户已经进入续签流程，于是临时增加一个剔除步骤。
对话流里应该明确提示：
“发现 12 家客户已进入续签流程，已新增排除步骤。”
计划变了，本身就是用户需要知情的信息。
4.2
执行状态：用户需要的不是百分比，而是进展感
任务开始后，界面首先要回答一个问题：
它现在进行到哪了？
最简单的做法，是先用步骤轨道告诉用户当前处在哪个阶段，再把关键执行过程逐步追加出来。
这里最容易踩两个坑：一个是假进度，一个是信息太多。
1. 不知道进度，不能假装知道
很多产品习惯给长任务加一根百分比进度条。
但 Agent 执行过程中，往往连最终要处理多少数据、会不会临时增加步骤都不知道。
进度条撒的谎，会在它卡在 99% 时被全部索回。
更好的方式，是把进展拆成三层：
a. 阶段推进：告诉用户现在走到第几步。
b. 真实分子分母：只有能准确统计时，才显示“正在计算 68 / 165”。
c. 活跃状态：无法估算剩余时间时，只告诉用户“仍在执行中”。
诚实的模糊，比精确的谎言更让人安心。
2. 执行过程要看得懂，也要查得清
Agent 真正在后台执行的，是一连串工具调用。
但用户需要看到的，不应该是一屏参数和接口名称，而是这些调用对任务意味着什么：
“检索到 30 天内到期的活跃客户 214 家”“已排除试用期客户 37 家”“发现 12 家客户已在续签流程中，已自动剔除”
默认层先翻译成业务语言，让人一眼知道发生了什么。
需要排查时，再展开原始调用：
fetch_crm_accounts(status=active, expiry_lt=30d) → 214 rows不是把技术信息删掉，而是把它放到第二层。
普通用户关心结果发生了什么，工程师关心系统到底调用了什么。
两种信息都需要，只是不应该同时抢占注意力。
3. 状态设计真正要回答的是：现在轮到谁
执行状态不只是告诉用户“系统正在做什么”，还要告诉他：
我现在要不要介入？
可以把几个常见状态理解成不同的用户预期：
Thinking：它在处理，你可以等。Executing：它正在执行，你可以先离开。Waiting for Approval：它停下了，现在轮到你。Retrying：它在自己恢复，暂时不用处理。Blocked：它解决不了了，需要你介入。
状态设计真正要传递的，不是“系统在干嘛”，而是“现在轮到谁”。
否则，再多状态标签也只是系统信息，不是用户体验。
4.3
人在回路：什么时候需要用户确认
Agentic UI 不是每一步都要用户确认。
确认太频繁，用户很快就会形成“闭眼点批准”的习惯，最后人在回路只剩一个形式上的按钮。
更合理的做法，是根据可逆性、影响范围和风险决定什么时候需要人介入：
- 读取 CRM、查埋点等低风险只读动作，可以静默执行；
- 修改客户等级、创建内部任务等可撤销动作，需要确认；
- 发客户邮件、删除数据、触发付款等难撤销动作，需要更强的交互拦截。
人在回路的重点，不是让人参与得更多，而是在关键节点把决策权交还给人。
1. 决策要放在证据旁边
到了“准备发送挽回邮件”这一步，对话流里直接出现授权卡，展示邮件内容、收件人、判断依据和影响范围。
比起单独弹一个“是否批准”的模态框，这种方式能保留上下文，让用户知道 Agent 为什么走到这一步。
授权应该和判断依据放在一起。
2. 授权粒度要和决策粒度一致
8 家高危客户里，有 3 家置信度低于 70%。
如果只有“全部批准”和“全部拒绝”，用户要么放行 3 家没把握的，要么连 5 家有把握的也一起拦住。
所以这里需要第三种选择：仅发送高置信度的 5 家。
门禁的粒度，应该匹配决策的粒度。
真实业务很少只有“全做”和“全不做”，界面也不应该把复杂判断压成二选一。
3. 重试前，先说清楚边界
8 条分派请求里，有 3 条因为接口超时失败。
这时候只放一个“重试”按钮是不够的。用户真正担心的是：已经成功的 5 条会不会被再次执行？
所以界面要明确提示：
“仅重试失败的 3 条，已成功的 5 条不受影响。”重试的关键，是让用户知道会重做什么、不会重做什么。
4. 允许修改，也要让影响可见
用户把健康度阈值从 15% 调到 25%。
旁边应该实时显示：
“观察层客户：23 家 → 14 家”
并明确说明：
“只重新计算受影响的步骤，已完成的数据检索不会重跑。”
用户不敢改，很多时候不是因为不会改，而是不知道改完会发生什么。
真正可用的人工干预，不只是允许修改，而是让修改后的影响提前可见。
4.4
结果呈现：让结果可审查，也可继续行动
任务完成后，Agent 提示：
“任务完成，共耗时 13 分 04 秒。结果已在右侧工作台展开。”
工作台成为新的视觉重心，对话流收窄为副轨。
1. 结果不能只剩一段总结
10几分钟的执行，不应该最后只压成一句“识别出 8 家高危客户”。
工作台需要把结果分层展示：
高危 8 家、观察 14 家、健康 155 家。每条客户都能继续展开，看背后的判断依据：
近 14 天登录 0 次——来源：产品埋点。3 张 P1 工单未闭环——来源：工单系统。季度用量环比下降 68%——来源：CRM。
每条证据都应该标明来源。
因为用户看到结果后的第一反应往往是：为什么？
来源标注让结论可以被核对，而不是只能被接受。
2. 置信度要真正影响建议
置信度不是一个展示数字，而应该直接影响界面给出的建议。
比如“星野科技”的置信度只有 61%，这时候就不适合继续给出“建议 48 小时内电话触达”这样的明确动作。
更合理的做法是提示：
“置信度偏低，请人工复核后再决定是否触达。”
高置信度，可以直接给出下一步建议；低置信度，则应该优先展示证据，并把决定权交给用户。
如果不同置信度最后都导向同一个动作，那这个置信度就失去了意义。
3. 结果页要承接下一步操作
结果出来之后，用户通常不会停在“看完”这一步。
他还要决定：要不要采纳、要不要导出、要不要继续调整。
所以工作台除了展示结果，还应该直接承接下一步操作，比如：
采纳并归档、导出、继续微调。如果这次任务还实际修改了数据，可以再提供“变更对比”，让用户看清楚系统到底改了什么。
对话也不用在结果出来后结束。用户可以继续追问：
“星野科技为什么置信度这么低？”工作台同步定位到对应记录，再继续解释。
结果页不是任务的终点，而是后续判断和操作的入口。
05
复盘: 一次任务之外，还要留下可复用的东西
前面讨论的，都是一次任务怎么被理解、执行、接管和审查。
但如果任务结束后，规则和人工干预全部消失，下一次还是从零开始。
单次结果解决这一次，可复用资产决定下一次。
真正值得沉淀的有三样：
技能。 把筛选口径、归因规则、门禁策略保存成 renewal-risk-scan，让同类任务下次可以直接复用。比调用次数更值得看的指标是接管率：一条技能总要人救场，说明它还不够可靠。
运行记录。 把谁改了参数、批准了什么、Agent 为什么改变计划完整保留下来，方便回放和追溯。尤其涉及客户、资金和业务数据时，这不是普通日志，而是责任链。
交互模式。 把状态怎么分、门禁怎么分级、什么置信度能给动作建议沉淀成规范，直接成为下一个 Agent 产品的设计起点。
06
不一定都需要做 Agentic UI
Agentic UI 不是越完整越好，先看任务本身值不值得。
简单任务，不需要。
如果三步就能跑完、一分钟出结果、错了重来也没什么成本，硬加确认、审批和状态机，只会让流程变重。
多任务并行时，不能只靠对话流。
当五个 Agent 同时运行，用户面对的问题已经不是“这个任务到哪了”，而是“我现在该先看哪个”。这时候更需要任务收件箱，让等待授权、Blocked 的任务优先浮上来。
即使需要 Agentic UI，也不能把所有信息和确认都堆出来。
执行日志太多，会变成信息过载。
几十条调用全部平铺，用户一样抓不住重点。更合适的方式是按阶段折叠成摘要，需要排查时再展开。
确认太频繁，会让人在回路失效。
如果每隔几十秒就弹一次确认，用户很快就会形成“直接批准”的习惯，人工审核最后只剩形式。
Agentic UI 的重点，不是把过程展示得越多越好，而是在真正需要的时候，让用户看到、判断和介入。
写在最后
过去我们设计的是“人怎么使用工具”。
现在要设计的是：人怎么和一个会自己干活、自己做判断、也会犯错的执行者共事。
所以 Agentic UI 设计的，不只是状态和卡片，而是在分配三样东西：
知情权、决策权和责任。
任务计划让人知道它准备怎么做；执行状态让人知道它正在做什么；人在回路把关键决策权还给人；结果审查和运行记录把责任链留下来。
最后落到界面上，就是四件事：
看得见、拦得住、改得动、查得清。
模型再聪明，如果界面没把过程呈现出来，也没在关键时刻把决策权还给人，
那长时间的沉默，会让用户失去耐心和信任。
产品设计原型真正要考虑的，不是画几个漂亮的状态标签。
而是人和 AI 之间那条责任边界。
相关文章
