Agent 产品设计:从能用到想用

3888 字
19 分钟
Agent 产品设计:从能用到想用

2026-08-13 Agent 产品设计:从”能用”到”想用”#

📅 学习日期:2026-08-13 | 📚 来源:AI Agent 知识库 | 📝 综合文章数:5 篇

为什么选这个主题#

之前 15 篇笔记全部从技术视角切入 Agent——架构、记忆、评估、安全、RAG……但 Agent 的成功最终取决于用户是否愿意用、是否持续用。今天换一个视角:从产品设计和用户体验出发,看 Agent 如何从”能用”的技术系统变成”想用”的产品。8-07 HITL 关注的是”人怎么介入技术流程”,今天关注的是”人怎么体验 Agent 产品”——前者是技术实现,后者是产品本质。

核心要点#

要点 1:12-Factor Agent——企业级 Agent 的设计宪法#

12-Factor Agent 将企业级 Agent 设计原则分为四组,构建了一套从顶层框架到哲学思考的完整体系:

顶层设计框架(原则 1-3):

  • 工作范式从”回答”转向”执行”:LLM 核心工作不再是直接回答问题,而是组织协调工具来解决问题。价值从”聊天”飞跃到”执行”。
  • 思考与行动分离:Agent 只生成”工具调用意图”(结构化输出),独立工具执行器负责解析、路由、调用与返回。二者通过 JSON Schema 通信,降低耦合、独立进化。
  • 人机协同反转:从”人类驱动 AI 响应”转为”AI 驱动,人类响应”——Agent 主动调用”人类工具”求助,人类变为”按需审批者”。

上下文管理(原则 4-6):

  • 提示词是”一等公民”:外部化存储、版本控制、模块化、A/B 测试,拒绝框架黑盒封装。
  • 上下文仲裁而非 FIFO 懒政:按业务定义信息重要性等级,采用优先保留、摘要提炼、外部记忆体等策略,而非简单截断最早的信息。
  • 错误压缩:将冗长堆栈转为紧凑友好信息(类型/原因/参数/建议),让 Agent 从错误中学习并自我纠正。

核心工作链路(原则 7-9):

  • 统一执行状态与业务状态:合并为”全局状态”,外部持久化,赋予断点续传、容错恢复、可观测性。
  • 任务全生命周期 API:POST /tasks(启动)、/pause、/resume、/cancel,将 Agent 从实验室推向生产。
  • 有限状态机:用代码显式定义状态枚举与处理器,拒绝框架预置链黑盒,掌握控制权与清晰度。

哲学思考(原则 10-12):

  • 多个小而专注的 Agent:按业务域拆分专家 Agent,通过标准契约协作,构建高内聚低耦合的”智能组织”。
  • 从任何地方触发:Agent 是可被调用的服务而非访问目的地,打破交互孤岛。
  • 无状态归约器:Agent 核心为纯函数 (currentState, action) => newState,状态全外部化,获得极致弹性与容错。

要点 2:饿了么实战——AI 驱动的任务体验设计#

饿了么设计团队用”对话式交互+任务编排”重构了商家开店流程,是 Agent 产品设计最鲜活的实战案例之一。

传统痛点:商家注册后进入”开店任务列表”(9 个必做+5 个选做),面临三大问题——

  • 心理迷茫:任务列表繁杂,不知从哪个开始
  • 任务困难:对规则/运营不熟,卡在细节(如头像审核驳回)
  • 进度阻塞:中途疑问无及时解答,进度受阻

AI 重构方案:

  • 对话式交互框架:AI 通过自然语言与目标驱动,模拟线下”询问-反馈-确认-继续”流程,AI 主导执行、商家辅助决策。
  • 意图识别:分析商家真实语料,整理典型问题及关键词,为 AI 制定多轮追问路径(意图澄清),细化提问粒度,降低表达门槛。
  • 回复结构定义:明确型问题”直接给结论”,建议型问题”结论先行+思路阐述+输出方案+高频问推荐”,保障体验稳定。
  • 任务编排:为 AI 植入任务规划逻辑与阻塞处理策略——审核驳回时,从”僵硬催促”改为”帮改图过审+传达过审技巧+换任务先做其他”,避免用户流失。

效果:接入 AI 开店后,进线咨询量大幅下降,建店转化率大幅提升。

设计团队的角色变化:设计师不再仅做界面(UI),而是深度参与 AI 底层交互逻辑——意图确认、信息反馈结构、任务规划思路与阻塞处理。这是从”界面设计师”到”体验架构师”的跃迁。

要点 3:人机交互的范式跃迁——从”翻译层塌缩”到”认知共生”#

智能体时代人机交互的演进,本质上是一场”翻译层”不断塌缩的进程——每一次范式革命,都出现更强大的”翻译器”,将人类意图更直接地转化为机器行动。

三大场景的统一演进逻辑:

场景传统范式智能体范式交互特征
桌面CLI/GUILUI/智能体心跳机制、长期在线、异步执行、人在回路
移动GUI/TUINUI/智能体流程找人、入口无形化、泛在化
XRGUI 移植SMUI/智能体共生服务随人而动、自然语言+空间多模态

核心范式转变:

  • 从”人类适配机器”的确定性规则 → “机器服务人类”的意图理解与主动协同
  • 从”请求-响应”单向指令 → “长期伴随”双向建构
  • 人类角色从”执行者”升维为”目标架构师、价值校正者、系统编排者”
  • 交互入口趋于”无形化”——用户陈述意图,系统调度网络

终极方向:认知共生——人机心智深度融合,交互界面趋于消失。预计 2026 年全球 AI Agent 市场破 780 亿美元,企业级占比超 70%。

要点 4:上下文工程——Agent 的”灵魂”与产品的”护城河”#

上下文工程为 Agent 构建包含即时指令、短期记忆、长期知识和环境感知的”世界观和记忆系统”,它决定了 Agent 能力的上限。

核心公式:模型决定下限,上下文决定上限。

上下文的四层结构:

  • 即时指令(Prompt):你刚刚下达的具体任务
  • 短期记忆(State):当前任务的直接上下文(“今天会议”是哪个会议?)
  • 长期知识(Knowledge/RAG):“相关同事”是谁?公司会议室预定流程?
  • 环境感知(Environment):现在是下班时间吗?我是谁?我的偏好?

AI PM 的四大设计战场:

  1. 定义记忆边界:Session 级记忆(客服问答)、用户级记忆(个人助手偏好)、全局知识(RAG 系统设计)——三层边界不同,设计策略不同。
  2. 动态多模态输入:用户画像 + 环境信息 + 多模态输入。电商 Agent 如果能知道”用户 A,女性,30 岁,上海,正在手机 App 浏览羊毛大衣,晚上 10 点”,推荐精准度远超”猜你喜欢”。
  3. 遗忘机制:时效性遗忘(一周前的感冒药搜索降权)、用户主动控制(查看/删除记忆)、任务结束即焚毁(财务数据)。
  4. 人-机-环境协同:手机 Agent 知道日历,收到会议邀请邮件时自动检查是否有空,给出”接受”或”建议其他时间”的快捷按钮——不是等指令,而是基于环境上下文主动服务。

关键洞察:未来大模型性能趋同、API 成本趋降,真正的竞争优势在于你为 Agent 构建了多么深刻、独特且高效的上下文理解系统。上下文是 AI 产品的”护城河”。

要点 5:OpenClaw——从”请求-响应”到”长期伴随”的架构支撑#

OpenClaw 提供了从交互模式到技术架构的完整实现方案,展示了”伴随式交互”如何被工程化落地。

交互范式转变:

  • 传统:请求-响应,用户发起明确指令,系统给封闭答案
  • OpenClaw:长期伴随式——主动、持久、异步;无感化入口(嵌入微信/WhatsApp);人在回路;目标驱动协作

Agent OS 三大设计原则:

  • 控制与执行分离:网关(Gateway)作为统一控制平面,负责连接管理、鉴权、路由、安全门控;执行交由下层
  • 模块化可插拔:Agent、Tool、Skill/Plugin、Node 等标准化对象,像乐高积木般组装扩展
  • 赋予 AI 行动能力:AI 对本地环境(终端、文件系统、浏览器)完整访问权,从”回答问题”升级为”现场执行”

使能模块:

  • 心跳(Heartbeat):每 30 秒读取 heartbeat.md 唤醒 Agent 检查待办,变被动为主动”后台巡逻”
  • 记忆(Memory):双层存储(Markdown 冷备 + SQLite 热召回)+ 混合检索(70% 语义 + 30% 关键词)
  • 灵魂文件(SOUL.md):可编辑 Markdown 定义 AI 个性、风格与准则,启动加载,人格可定制可分享
  • 技能自生长:Agent 可主动封装新 SKILL.md,实现能力自我演进

安全纵深防御:从 ClawHavoc 事件后分化出 NanoClaw(Docker 硬隔离)、ZeroClaw(Rust 重构+原生沙箱),企业级演进为 RBAC 权限、全链路审计、强制人工复核断点。云-边-端三级协同(云端训练调度、边缘推理执行、终端感知)。

分歧与讨论#

“无状态归约器” vs “有状态伴随体”:

12-Factor Agent 的原则 12 主张 Agent 是”无状态的归约器”——(currentState, action) => newState,状态全外部化。但 OpenClaw 的”长期伴随式”交互恰恰需要 Agent 维持持久的”人格”和”记忆”——灵魂文件(SOUL.md)和心跳机制都是有状态的。这两种设计哲学是否矛盾?

可能的解释是:无状态是架构层面的选择(弹性、容错),有状态是产品层面的需求(连续性、信任感)。工程上通过外部化状态(Redis/SQLite)实现”架构无状态 + 产品有状态”的统一。但这里有一个张力——外部化状态的管理成本和一致性保障,本身就是一个复杂系统工程。

“AI 主导执行”的信任边界:

饿了么的案例中,AI 主导执行、商家辅助决策。12-Factor Agent 的原则 3 也说”AI 驱动,人类响应”。但当 AI 的决策出错时,用户可能已经处于被动位置——不知道 AI 在做什么、为什么这么做。主动性和可控性之间的平衡是 Agent 产品设计最核心的张力。

“认知共生”的理想与现实:

人机交互演进报告描绘了”认知共生”的美好图景——交互界面趋于消失。但”界面消失”意味着用户失去对 AI 行为的可视性。在安全敏感场景(医疗、金融、汽车),“看得见”比”看不见”更重要。认知共生与安全审计之间存在根本矛盾。

与已学内容的联系#

  • 8-07 HITL:今天的”人机协同反转”(原则 3)是 HITL 的产品化表达——8-07 关注技术实现(怎么介入),今天关注产品体验(怎么让用户自然地介入)。OpenClaw 的”人在回路”是 HITL 的具体工程化。
  • 7-24 记忆系统:上下文工程的”记忆边界”是 7-24 记忆系统的产品化设计——三层边界(Session/用户/全局)对应 7-24 的参数化/上下文/外部记忆分类。
  • 7-28 Context Engineering:今天的”上下文工程”是 7-28 的产品经理视角——7-28 关注 KV 缓存、注意力操控等技术细节,今天关注”怎么设计上下文让产品更好用”。
  • 7-23 架构演进:12-Factor Agent 的”无状态归约器”和”多小 Agent”是 7-23 架构演进的产品化落地——从技术架构到产品架构的统一。
  • 8-10 异步架构:原则 8 的”任务全生命周期 API”(pause/resume/cancel)是 8-10 异步架构的产品接口层——异步是技术实现,生命周期管理是产品体验。
  • 8-12 RAG:上下文工程中的”长期知识(RAG)“是 8-12 的产品化应用——RAG 是技术,“怎么让 Agent 用好 RAG 的知识”是产品设计。

💡 思考题#

  1. 12-Factor Agent 主张”无状态归约器”,但长期伴随式交互需要”有状态人格”。如果用户对 Agent 产生了情感依赖(如”我的 AI 助手很懂我”),但底层是无状态设计,如何保证跨实例、跨升级的”人格一致性”?这种一致性是产品承诺还是工程幻觉?
  2. 饿了么的案例中,AI 主导执行、商家辅助决策。如果商家对 AI 的建议产生”盲目信任”(因为 AI 好像总是对的),当 AI 出错时后果更严重。产品设计上如何避免”过度信任”陷阱?
  3. “认知共生”意味着交互界面趋于消失,但”界面消失”是否意味着”可控性消失”?在什么场景下,“看得见的界面”比”无形的智能”更优?
  4. 上下文工程被视为 AI 产品的”护城河”,但用户的上下文数据(偏好、历史、行为)也是隐私敏感信息。如何设计”上下文护城河”同时不侵犯用户隐私?遗忘机制是否足够?

🎯 行动项#

  1. 用 12-Factor Agent 原则审计一个 Agent 产品:选一个你正在使用或开发的 Agent 产品,逐条对照 12 项原则,找出违反最多的是哪几条,思考修复成本和收益。
  2. 设计一个”遗忘机制”:为你的 Agent 定义三类遗忘规则(时效性遗忘、用户主动控制、任务结束即焚毁),画出遗忘决策流程图,标注触发条件和数据流向。

参考文章#

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

Agent 产品设计:从能用到想用
https://www.zgf.me/posts/2026-08-13-agent-产品设计从_能用_到_想/
作者
赵某人
发布于
2026-08-13
许可协议
CC BY-NC-SA 4.0

评论区

Profile Image of the Author
赵某人
俯视泥土,仰望星辰
公告
欢迎来到我的博客!这是一则示例公告。
分类
标签
最新动态
站点统计
文章
28
分类
1
标签
58
总字数
129,420
运行时长
0 天
最后活动
0 天前
站点信息
构建平台
Local
博客版本
Firefly v6.14.5
文章许可
CC BY-NC-SA 4.0