agent_product_design全部约 80 分钟
1B
从对话框到主动服务：Agent 产品到底改变了什么
参考：来源 G · 趋势 1/2/3 · 去除产品宣传后的通用设计原则
学完你能做到
- 理解指令式计算和意图式计算的区别
- 掌握事件驱动、主动服务、智能交接和自主等级
- 设计人在 Agent 系统中的监督职责
从“告诉电脑每一步”到“告诉电脑想要的结果”
先建立直觉
传统软件像自动售货机：你必须按正确顺序选择、付款、取货。Agent 更像受监督的助理：你说明结果和边界，它决定中间要查什么、问什么、做什么。
主动服务：问题发生以后，不必等用户来投诉
报告给出的物流案例可以抽象成一条通用链路：系统发现配送失败，Agent 核验原因、查询可用时段、准备补偿方案、通知客户，并在复杂或情绪化场景中交给人工。
真正的产品变化不是回复更像人，而是服务从“等用户描述问题”变成“根据可信事件主动发现、准备解决方案并获得授权”。
| 步骤 | Agent 可以做什么 | 必须由系统约束什么 |
|---|---|---|
| 发现 | 读取事件并判断是否值得处理 | 事件来源、重复事件去重、触发频率 |
| 核验 | 跨系统收集原因和当前状态 | 数据权限、证据新鲜度、来源记录 |
| 准备 | 提出改期、补偿或解决方案 | 金额上限、允许动作、业务规则 |
| 执行 | 调用工具修改状态 | 授权、幂等、事务与审计 |
| 沟通 | 用合适语气通知用户 | 隐私、渠道、不可承诺事项 |
| 交接 | 把复杂问题升级给人 | 完整交接包和明确接管责任 |
智能交接：不是丢下一句“请联系人工”
自主程度不是开关，而是一架梯子
| 等级 | 系统权限 | 适合场景 |
|---|---|---|
| L0 · 回答 | 只能生成内容，不能行动 | 解释、总结、写作 |
| L1 · 建议 | 分析并推荐下一步 | 决策支持 |
| L2 · 准备 | 准备工具参数，等待人批准 | 邮件、付款、发布 |
| L3 · 低风险自动执行 | 在规则内自动做可逆动作 | 分类、建草稿、查询 |
| L4 · 受限连续执行 | 在预算、时间和权限边界内循环 | 研究、排障、运营流程 |
| L5 · 异常时升级 | 大部分自主，仅异常找人 | 成熟且可充分观测的低风险流程 |
产品设计要逐级获得自主权：先证明低等级可靠，再扩大权限，而不是 demo 成功后直接全自动。
人的工作没有消失，而是从操作转向监督
- 委托：识别哪些任务值得交给 Agent，哪些必须保留给人。
- 定目标：写清想得到的结果、截止时间和完成标准。
- 定策略：提供业务优先级、伦理判断和例外处理原则。
- 验质量：检查证据、准确性、语气和真实业务后果。
案例推演：从“回答物流问题”到“主动解决物流异常”
聊天客服能回答“包裹到哪了”；主动服务 Agent 则持续观察物流事件，在延误发生后判断影响、准备补偿方案，并在授权范围内联系用户。
本节追问：产品价值从一次回答变成结果负责后，体验和责任怎样变化？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。
| 阶段 | 本步要做的决定 | 什么算证据 | 最常见的失败 |
|---|---|---|---|
| 定义结果 | 目标从“给答案”改为“异常被发现并妥善处理” | 有完成标准和服务时限 | 只统计聊天轮数和字数 |
| 持续触发 | 由物流事件而非用户提问启动任务 | 触发源、去重和时效规则明确 | 每个状态更新都重复发消息 |
| 渐进授权 | 先建议，再代拟，最后只在低风险范围自动执行 | 每级授权对应动作与金额上限 | 一次性给出全部账户权限 |
| 结果回告 | 向用户说明发生了什么、做了什么、还需什么 | 通知包含证据、动作和撤销路径 | 后台做了动作却没有可见反馈 |
阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。
常见误解
在聊天页面加一个“自动处理”按钮就称为 Agent 产品
实际上
可观察症状：没有后台状态、事件触发和责任闭环。
更可靠的修复：围绕用户结果重画触发—决策—行动—确认—跟进旅程。
案例工作坊 · 建议真正动手完成
25 分钟- 写出物流 Agent 的触发事件和完成定义。
- 设计建议、代拟、自动执行三档授权。
- 为误判延误设计撤销与申诉路径。
查看参考答案
Agent 产品不只是新的交互外壳，而是把软件从“等用户操作”变成“围绕目标持续观察并行动”。因此必须同时设计授权、通知、撤销和责任。
迁移检查：换一个场景还会不会
主动服务最重要的新产品对象是什么？
产品判断
一个客服 Agent 发现订单异常后自动给用户退款。最先要补的设计是什么？