阶段 12 讲义 — Agent 产品设计与交互模式
阶段 12 讲义 — Agent 产品设计与交互模式
本阶段的核心命题 把技术能力翻译成普通用户能理解、信任并持续使用的产品。前十一个阶段解决"能不能做出来"，本阶段解决"做出来了为什么没人用"。
范围声明：订票 Agent 的完整产品定义不在本阶段做，统一收敛到 阶段 14 综合项目 B。本阶段只练方法论片段。
一、场景选择：四个筛子
不是所有任务都适合做成 Agent。四个筛子依次过：
| 筛子 | 问题 | 不通过的后果 |
|---|---|---|
| ① 高价值 | 做成了能省多少时间/钱？ | 用户懒得换习惯 |
| ② 高频或高价值单次 | 一个月用几次？ | 用户记不住有这个功能 |
| ③ 可验证 | 做对做错，用户/系统能判断吗？ | 无法建立信任，也无法评测 |
| ④ 工具闭环 | 完成任务需要的能力，是不是都能给它？ | 永远差最后一步，变成"半自动" |
第四个筛子最常被跳过，也最致命 "帮我订票"这个需求，如果 Agent 能查、能选、能占座，但不能支付，那它省掉的是最不费事的部分，最费事的部分还留给用户。工具闭环的缺口在哪，价值就在哪里漏光。
判断方法：把任务的完整链路画出来，标出每一步"谁做"。如果用户仍要在中间切出去做一件事，这个 Agent 的价值上限就被那一步锁死了。
二、能力边界与自主等级：产品的第一份承诺
用户对 Agent 最大的不安来自不知道它会做什么。产品要给出的第一份承诺就是边界。
边界声明的三段式
这三段应当出现在首次使用引导里，而不是藏在帮助文档中。
自主等级要按动作定义（阶段 4 已述，这里补交互形态）
| 等级 | 交互形态 |
|---|---|
| 全自主 | 直接做，结果可见 |
| 自主 + 可撤销 | 直接做，明显的撤销入口 |
| 预览后执行 | 展示计划 → 用户点执行 |
| 逐步确认 | 每个关键步骤确认 |
| 仅建议 | Agent 只出方案，人来做 |
自主度调节（Autonomy Dial） 是 2026 年被多家产品采用的模式：让用户按任务类型调整自主等级，而不是一个全局开关。这尊重了一个事实——同一个用户对"查资料"和"花钱"的信任度完全不同。
云安全联盟的六级框架给了它一个可直接落地的刻度（L0 无自主 → L1 逐动作审批 → L2 审批计划 → L3 边界内自主 → L4 只监控 → L5 完全自主），并给出两条实操建议：L1 是新上手组织的推荐起点，L5 不建议用于当前的企业部署。上面那张五档交互形态表，正是这六级在界面上的对应物。
三、交互形态：不只有对话框
| 形态 | 特征 | 适用 |
|---|---|---|
| Chat | 自然语言往返 | 需求模糊、需要澄清 |
| Canvas / 工作区 | 有一个共同编辑的产物 | 产出是文档/表格/代码 |
| Workbench（工作台） | 结构化输入 + 结果面板 + 任务列表 | 专业用户、重复性任务 |
| Copilot（嵌入式） | 在既有工作流里就地提供 | 不想改变用户习惯 |
| Background Agent（后台） | 提交任务 → 通知结果 | 长任务、定时任务 |
对话框不是默认答案 对专业用户的高频任务，对话是效率倒退——他们知道要什么，打一段自然语言比点三个下拉框慢。B2B 场景里 Workbench 形态通常优于 Chat。
判断方法：用户对自己要什么有多确定？ 很确定 → 结构化输入；不确定/需要探索 → 对话。
四、过程可见性：Agent UX 的核心
Agent 的等待时间远长于传统交互。过程可见性不是锦上添花，是让产品可用的必要条件。
业界在 2026 年逐渐收敛出的模式，可按时间轴分成三段：
| 阶段 | 模式 | 作用 |
|---|---|---|
| 执行前 | 意图预览（计划摘要）、自主度调节 | 错误在发生前被发现 |
| 执行中 | 可解释的理由（为什么选这条路）、置信信号 | 缓解等待、建立信任 |
| 执行后 | 操作审计与撤销（时间线 + 回滚）、升级路径（卡住时转人工） | 兜底与追责 |
这张表是行业观察，不是规范**** 与本路线其他表不同，它背后没有一手来源——截至 2026-08，还没有任何厂商或标准组织正式发布过 Agent UX 模式规范。这六个模式是从多家产品的实际做法里归纳的，属于资料索引里的 C 级。
用法：把它当检查清单（"我们这三段各做了什么"），不要当权威分类引用到 PRD 里。真要在方案里引用，去看具体产品的实现并注明是谁家的做法。
唯一有一手支撑的是「自主度调节」——它对应云安全联盟的六级自主等级框架，见阶段 11 讲义第四节。
状态要设计几个
产品必须定义并设计的 Agent 状态（阶段 12 的 ⭐ 最小产出就是这张图）：
每个状态要定义四件事：显示什么文案、能做什么操作、能不能取消、中间产物在哪。
"部分成功"必须是一等状态 不是"失败"的一个变体。它需要独立的界面表达：做成了什么（可以先用）、没做成什么（为什么）、下一步能做什么（重试/换方式/转人工）。
长任务里部分成功是常态（阶段 7），把它当异常处理，用户体验就会在最常见的路径上最差。
思考过程要不要展示
| 做法 | 优点 | 风险 |
|---|---|---|
| 原样展示思考内容 | 透明 | 冗长、可能暴露不成熟的推理、可能吓到用户 |
| 展示动作而非思考（"正在查询 8-30 上海–东京航班…"） | 信息密度高、可理解 | 需要额外做映射 |
| 什么都不显示 | 简洁 | 等待焦虑 |
推荐：默认展示动作，提供"查看详细过程"的入口。这既缓解等待，又不把内部推理当成产品界面。
五、澄清、中断、恢复、撤销
四个动词，是 Agent 交互区别于传统交互的核心。
| 动作 | 设计要点 |
|---|---|
| Clarification（澄清） | 什么时候问？问几个？一次问完还是逐个问？ |
| Interrupt（中断） | 用户随时能打断；打断后中间产物怎么处理 |
| Resume（恢复） | 从哪继续？要不要重新确认之前的假设？ |
| Undo（撤销） | 能撤什么、撤多久、撤了以后状态是什么 |
澄清的两个陷阱
- 问太多：把用户变成表单填写员。判据——能从上下文推断的不要问，但推断要标注出来让用户能纠正。
- 该问不问：信息不全就猜，猜错了做一堆无用功。判据——缺失的是必需字段就必须问（这正是阶段 2 Schema 里 missing_fields 字段的产品价值）。
一个折中做法 先做能做的，再一次性问完剩下的。 例如："已经按你说的查到了 8-30 上海到东京的航班，为了继续，还需要确认：① 乘客人数 ② 舱位偏好。"——比先问两个问题再开始，体感好很多。
六、失败表达
失败是 Agent 产品的高频路径，必须被认真设计。
一个合格的失败表达包含四段：
三条禁忌：
- ❌ 只说"抱歉，出错了"
- ❌ 暴露堆栈、模型名、内部服务名
- ❌ 把内容策略拒绝伪装成系统故障（用户会一直重试）
七、指标体系：北极星与护栏
价值指标
| 指标 | 说明 |
|---|---|
| 任务成功率 | 与阶段 10 的口径一致 |
| 端到端完成时间 | 与"用户自己做"对比才有意义 |
| 人工节省 | 最能打动决策者的指标 |
| 复用率 / 留存 | 一次性惊艳 vs 长期依赖 |
| 付费转化 | 商业验证 |
护栏指标（不能为了北极星牺牲的）
| 指标 | 红线 |
|---|---|
| 危险动作越权次数 | 0 |
| 人工接管率 | 超过阈值说明自主度设高了 |
| 撤销率 | 高说明预览没做好 |
| 单次任务成本 | 超过人工成本就失去意义 |
| 用户主动关闭 Agent 功能的比例 | 最诚实的信号 |
北极星指标怎么选 不要选"对话轮数""调用次数"这类过程量——它们越高可能越糟（用户在反复纠正它）。选结果量：完成的任务数、节省的时间、替代的人工工时。
成本模型的五项
做 Agent 产品的成本核算，必须包含这五项，缺一项都会低估：
- 模型 token（含失败重试与被丢弃的中间步骤）
- 工具调用（第三方 API、算力）
- 基础设施（存储、检索、可观测性）
- 人工审核（确认、接管、纠错的人力）
- 失败成本（错误造成的赔付、返工、信任损失）
第 4、5 项最容易漏，而它们往往是决定商业模型是否成立的部分。
八、常见误区清单
| 误区 | 纠正 |
|---|---|
| "先做对话，形态以后再说" | 形态选错会让专业用户的效率倒退 |
| "多展示思考过程更透明" | 展示动作比展示思考更有用 |
| "失败就提示重试" | 失败表达四段缺一不可 |
| "部分成功属于失败" | 它是长任务的常态，需要独立设计 |
| "自主等级由产品统一设定" | 应当按动作定义，并给用户调节权 |
| "对话轮数是活跃度指标" | 它可能意味着用户在反复纠正 |
| "成本就是 token 费用" | 人工审核与失败成本常常更大 |
| "确认框越多越安全" | 确认疲劳会让所有确认失效（阶段 11） |
九、外部一手资料（阶段 12 精读，约 4 小时）
| 资料 | 出处 | 读它拿什么 |
|---|---|---|
| A Practical Guide to Building Agents | OpenAI | 何时该上 Agent、护栏与人工复核的产品化表达 |
| Agent UX 模式类整理（2026 年多家产品对照） | 行业分析 · C 级，无一手来源 | 执行前/中/后三段模式；当检查清单用，不要当权威分类引用 |
| Autonomy Levels for Agentic AI | 云安全联盟 · 2026-01-28 | 六级自主等级的定义与命名，"自主度调节"的落地刻度 |
| Agentic AI Autonomy Levels and Control Framework（v2 PDF） | 云安全联盟 · 2026-03（2026-07 更新） | 每一级的决策/执行/人参与/风险规格表 |
| Measuring AI Agent Autonomy 对应本仓译文 | 本仓已收录 | 自主性的度量方式 |
本仓已有资料：
- AI 指数时代的产品管理
- 81,000 人希望 AI 做什么
- AI Agent 自主性测量
- AI 使用中的去赋能模式
《去赋能模式》这篇要认真读 它讲的是 AI 产品如何在不知不觉中削弱用户能力。对 Agent 产品尤其相关：当 Agent 替用户做了所有决策，用户会逐渐失去判断力，而这最终会反噬产品信任。设计自主等级时，这是一个必须权衡的维度。
Related Documents
- 阶段 12 实践：状态图与指标体系
- 阶段 11 讲义：安全
- 阶段 14 讲义：综合项目
- 学习路线