前置阅读：Agent 技术架构层面的基础知识请参考 AI 智能体架构设计 与 Agent 工作流编排设计。本文聚焦于产品设计与用户体验维度。
1. 从工具思维到 Agent 思维：产品范式的根本性迁移
1.1 三代 AI 产品的演进路径
第一代：命令式工具 第二代：对话式助手 第三代：自主式 Agent
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 用户输入命令 │ │ 用户描述需求 │ │ 用户设定目标 │
│ ↓ │ │ ↓ │ │ ↓ │
│ 工具执行 │ │ LLM 理解 │ │ Agent 自主 │
│ ↓ │ │ ↓ │ │ 规划行动 │
│ 返回结果 │ │ 返回回答 │ │ 循环迭代 │
│ │ │ │ │ ↓ │
│ 确定性输出 │ │ 概率性输出 │ │ 达成目标 │
└──────────────┘ └──────────────┘ └──────────────┘
关键差异对比：
| 维度 | 工具（Tool） | 对话助手（Chatbot） | Agent |
|---|---|---|---|
| 用户输入 | 精确指令 | 自然语言描述 | 目标声明 |
| 系统行为 | 确定性执行 | 单次响应 | 自主规划 + 多步执行 |
| 状态管理 | 无状态 | 会话级状态 | 跨会话长期记忆 |
| 错误处理 | 立即抛错 | 道歉并放弃 | 重试、回退、替代方案 |
| 用户心智模型 | “我告诉它怎么做” | “我问它一个问题” | “我委托它一件事” |
| 信任要求 | 低（结果可预测） | 中（需要验证） | 高（需要接受不确定性） |
| 适用任务 | 计算、查询 | 问答、撰写 | 研究、决策、执行 |
1.2 产品经理的范式迁移清单
从传统软件产品过渡到 Agent 产品，产品经理需要在以下维度重构思维：
- 从流程确定性到目标导向：不再设计每一步的精确路径，而是定义清晰的目标边界和成功标准
- 从错误预防到错误恢复：Agent 必然犯错，设计重点转向检测、修复和优雅降级
- 从即时反馈到异步授权：用户可能需要等待分钟甚至小时，重点是建立进度感知机制
- 从功能完整性到自主度校准：在"完全手动"和"完全自动"之间找到产品定位
2. Agent 解剖学：五大组件的产品设计要点
┌─────────────────────────────────────────────┐
│ 用户目标输入 │
└─────────────────────────────────────────────┘
↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 感知层 │→│ 记忆层 │→│ 推理层 │→│ 行动层 │→│ 评估层 │
│ Perception │ │ Memory │ │ Reasoning │ │ Action │ │ Evaluation │
│ │ │ │ │ │ │ │ │ │
│ • 输入解析 │ │ • 短期记忆 │ │ • 意图识别 │ │ • 工具调用 │ │ • 结果校验 │
│ • 环境感知 │ │ • 长期记忆 │ │ • 任务分解 │ │ • 代码执行 │ │ • 自我反思 │
│ • 多模态融合 │ │ • 向量检索 │ │ • 路径规划 │ │ • API 调用 │ │ • 质量评分 │
│ • 上下文构建 │ │ • 实体追踪 │ │ • 动态调整 │ │ • 输出生成 │ │ • 终止判断 │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
2.1 感知层（Perception）的 UX 设计
核心挑战：用户输入往往模糊、不完整甚至含糊不清。Agent 不能简单拒绝，而应主动澄清。
用户输入："帮我订张机票"
↓
Agent 感知层处理：
├── 意图识别 → flight_booking (置信度 0.95)
├── 实体提取 → origin: ?, destination: ?, date: ?, class: ?
├── 缺失检测 → 3 个必需参数缺失
└── 澄清策略 → 按重要性依次询问
Agent 回复："
📍 为您预订航班。我还需要确认几个信息：
1. 出发城市和目的地是哪里？
2. 计划出行日期？
3. 偏好舱位（经济/商务）？
"
感知层设计原则：
| 原则 | 说明 | 示例 |
|---|---|---|
| 渐进式澄清 | 不要一次性问所有缺失信息 | 先问最重要的 1-2 个 |
| 智能默认值 | 基于上下文推断合理默认值 | “明天同一时间” → 自动推断日期 |
| 歧义显式化 | 当有多种理解时，主动列出 | “您说的’北京’是指北京首都机场(PEK)还是大兴机场(PKX)？” |
| 容错解析 | 容忍口语化、错别字、缩写 | “后天” → 日期计算；“魔都” → 上海 |
2.2 推理层（Reasoning）的可视化设计
用户需要看到 Agent “在想什么”——这是建立信任的关键。
Agent 思考过程（向用户展示）：
🎯 目标：为团队 10 人预订下周去杭州团建的酒店
🧩 任务分解：
├── [✓] 确认出行日期：2026-08-25 至 2026-08-26
├── [✓] 确认预算范围：每晚 ¥500-800/间
├── [→] 搜索符合条件的酒店（执行中...）
├── [ ] 对比评分、位置、设施
├── [ ] 检查团体预订政策
└── [ ] 生成推荐列表
📊 当前进度：2/5 完成，预计剩余 2 分钟
2.3 行动层（Action）的边界设计
高危险操作分级表：
| 危险等级 | 操作类型 | 产品策略 |
|---|---|---|
| 🔴 极高 | 资金转账、合同签署、数据删除 | 必须人工审批（HITL） |
| 🟠 高 | 权限变更、邮件群发、代码部署 | 双重确认 + 撤销窗口 |
| 🟡 中 | 日程修改、联系人更新、文件移动 | 操作前摘要 + 即时撤销 |
| 🟢 低 | 搜索查询、信息展示、草稿生成 | 全自动，无需确认 |
3. 四种交互体验模式
3.1 聊天模式（Chat）
用户 ←→ Agent
↓（每轮一问一答）
回复
特征：回合制、即时响应、用户主导节奏
适用场景：问答、咨询、简单任务
设计要点：保持上下文连贯、支持多轮澄清、历史记录可回溯
3.2 副驾驶模式（Copilot）
用户工作界面
└── [Copilot 侧边栏/浮层]
└── 实时感知用户行为
├── 代码编辑器 → 智能补全/重构建议
├── 文档工具 → 实时润色/格式调整
└── 设计软件 → 组件推荐/布局优化
特征：嵌入式、感知上下文、建议而非替代
适用场景：编程、写作、设计、数据分析
设计要点：不打断心流、建议可一键采纳/忽略、渐进式增强
3.3 自主模式（Autonomous）
用户："调研竞品 A、B、C 的定价策略，周五前给我报告"
↓
Agent 接收目标 ────────────────────────────────────────→ 周五交付
│
├── 周一：搜索竞品官网、爬取定价页面
├── 周二：整理数据、识别定价模型
├── 周三：分析策略差异、发现洞察
├── 周四：撰写报告、生成可视化
└── 周五：提交最终报告（附数据源链接）
│
└── 执行期间：每日进度摘要推送给用户
特征：目标驱动、异步执行、最小化交互
适用场景：研究、监控、数据处理、定时任务
设计要点：进度透明、关键节点通知、随时可暂停/修改指令
3.4 混合模式（Hybrid）
简单任务? ──→ 聊天模式（即时处理）
│
└── 否
│
用户在场? ──→ 副驾驶模式（协作处理）
│
└── 否
│
时间充裕? ──→ 自主模式（异步委托）
│
└── 否
│
混合模式（先确认关键决策，再自主执行）
特征：模式间无缝切换、动态降级与升级
适用场景：通用平台型产品
设计要点：模式切换的显式信号、状态保留、权限继承
3.5 交互模式选型矩阵
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 客服问答 | Chat | 需要即时确认和多轮澄清 |
| IDE 编程 | Copilot | 不能离开编辑器上下文 |
| 每日数据报表 | Autonomous | 定时触发、无需交互 |
| 合同审查 | Hybrid | Agent 标注重点，人类做最终决策 |
| 竞品调研 | Hybrid / Autonomous | 耗时长，适合异步 |
| 旅行规划 | Chat → Hybrid | 先澄清偏好，再批量执行预订 |
4. 记忆系统设计：让 Agent “记得住”
4.1 四层记忆架构
Agent 记忆金字塔
┌─────────────────────────────┐
│ 语义记忆（Semantic） │ ← 持久事实：知识库、用户画像
│ 跨会话/跨任务 │ 实现：向量数据库 + 知识图谱
├─────────────────────────────┤
│ 情景记忆（Episodic） │ ← 具体经历："上次订机票的偏好"
│ 跨会话 │ 实现：结构化事件日志
├─────────────────────────────┤
│ 短期记忆（Short-term） │ ← 当前对话上下文
│ 单会话内 │ 实现：滑动窗口 + 摘要压缩
├─────────────────────────────┤
│ 工作记忆（Working） │ ← 当前推理步骤
│ 单轮内 │ 实现：Chain-of-Thought 状态
└─────────────────────────────┘
4.2 产品层面的记忆设计决策
class AgentMemoryDesign:
"""Agent 记忆系统的产品设计参数。"""
# ─── 短期记忆 ───
short_term = {
"max_messages": 20, # 保留最近 N 轮对话
"compression_threshold": 10, # 超过后触发摘要压缩
"compression_ratio": 0.3, # 压缩后保留 30% 长度
"retention_policy": "fifo", # 先进先出，可配置为重要性加权
}
# ─── 长期记忆（向量检索） ───
long_term = {
"vector_db": "chroma", # Pinecone / Qdrant / Weaviate
"embedding_model": "text-embedding-3-large",
"retrieval_k": 5, # 每次检索召回 top-K
"relevance_threshold": 0.75, # 低于此值不注入上下文
"auto_index": True, # 对话结束是否自动入库
}
# ─── 情景记忆 ───
episodic = {
"event_schema": { # 结构化记录每次关键交互
"event_type": "flight_booking",
"timestamp": "2026-08-10T14:30:00Z",
"user_intent": "上海到北京",
"preferences": {"airline": "东航", "seat": "靠窗"},
"outcome": "success",
},
"recency_decay": 0.95, # 旧记忆的权重衰减
}
# ─── 语义记忆 ───
semantic = {
"knowledge_graph": True, # 实体关系图谱
"user_profile": { # 用户画像维度
"professional_domain": "软件工程师",
"communication_style": "直接简洁",
"preferred_tools": ["代码", "数据"],
"risk_tolerance": "中等", # 影响自主决策边界
},
}
4.3 记忆遗忘与隐私设计
| 记忆类型 | 保留期限 | 用户控制 | 隐私要求 |
|---|---|---|---|
| 工作记忆 | 即时丢弃 | 无 | 无 |
| 短期记忆 | 会话结束 | 可清除 | 会话级加密 |
| 情景记忆 | 用户设定（默认 90 天） | 可删除单条/全部 | AES-256 + 访问日志 |
| 语义记忆 | 用户账户生命周期 | 可导出/删除 | GDPR/CCPA 合规 |
5. Agent 可靠性工程：容错与恢复
5.1 错误分类与对应策略
Agent 执行错误处理流程
错误发生
│
├── 工具调用失败 ───────────────────┐
│ ├── 网络超时 → 指数退避重试 │
│ ├── API 限流 → 队列排队 + 降频 │
│ ├── 参数错误 → 自动修正 Schema │
│ └── 服务宕机 → 切换备用工具 │
│ │
├── 推理错误 ───────────────────────┤
│ ├── 幻觉/虚构 → 多源验证 │→ 全部失败 → 人类介入
│ ├── 逻辑矛盾 → 自检 + 重新推理 │
│ └── 循环推理 → 强制终止 + 报告 │
│ │
└── 评估错误 ───────────────────────┘
├── 结果不达标 → 迭代改进
└── 无法判断是否达标 → 降级给人类
5.2 可靠性层级设计
| 层级 | 策略 | 实现方式 | 用户体验 |
|---|---|---|---|
| L1：预防 | 输入校验、Schema 约束 | Pydantic 模型、Prompt 硬化 | 从来不出错 |
| L2：检测 | 结果验证、一致性检查 | 多 Agent 投票、单元测试 | 发现后质疑 |
| L3：恢复 | 重试、替代方案、回滚 | 断路器、备份工具 | 慢一点但成功 |
| L4：降级 | 简化任务、移交人类 | HITL 触发器 | “这部分我需要您确认” |
| L5：止损 | 终止执行、报告状态 | 安全边界检查 | “我遇到了困难，已暂停” |
5.3 断路器模式（Circuit Breaker）
from enum import Enum
class CircuitState(Enum):
CLOSED = "closed" # 正常执行
OPEN = "open" # 熔断中，拒绝调用
HALF_OPEN = "half_open" # 试探性恢复
class AgentCircuitBreaker:
"""Agent 工具调用的断路器实现。"""
def __init__(self, failure_threshold=5, recovery_timeout=60):
self.failure_threshold = failure_threshold # 连续失败 N 次熔断
self.recovery_timeout = recovery_timeout # 熔断后等待秒数
self.failure_count = 0
self.state = CircuitState.CLOSED
self.last_failure_time = None
def call(self, tool_func, *args, **kwargs):
if self.state == CircuitState.OPEN:
if self._should_attempt_reset():
self.state = CircuitState.HALF_OPEN
else:
raise ToolUnavailable("工具暂时不可用，正在等待恢复...")
try:
result = tool_func(*args, **kwargs)
self._on_success()
return result
except Exception as e:
self._on_failure()
raise
def _on_failure(self):
self.failure_count += 1
self.last_failure_time = time.time()
if self.failure_count >= self.failure_threshold:
self.state = CircuitState.OPEN
def _on_success(self):
self.failure_count = 0
self.state = CircuitState.CLOSED
def _should_attempt_reset(self):
return (time.time() - self.last_failure_time) > self.recovery_timeout
6. 多智能体编排的 UX 设计
6.1 用户视角的多 Agent 模型
用户不需要理解"多智能体系统"——他们需要的是问题的完整解决。
用户感知层（单一入口）
│
└── "我只需要和一个助手对话"
│
├── 旅行规划 Agent（主控）
│ ├── 航班 Agent → 查询 Skyscanner API
│ ├── 酒店 Agent → 查询 Booking.com API
│ └── 行程 Agent → 生成日程表
│
└── 用户只收到：「您的东京 5 日游方案已准备好」
编排层（对用户透明）：
- Agent 间通信协议：结构化 JSON
- 冲突解决：Manager Agent 仲裁
- 数据共享：共享上下文（只暴露必要信息）
6.2 冲突解决的可视化
当多个 Agent 产生冲突时，向用户展示决策过程而非中间争议：
❌ 错误展示方式：
"航班 Agent 推荐 8:00 起飞，酒店 Agent 要求 10:00 后才能入住，
行程 Agent 认为应该第一天直接游玩..."
✅ 正确展示方式：
"已为您协调最优方案：
• 航班：9:30 起飞（兼顾价格和酒店入住时间）
• 酒店：提前办理行李寄存，14:00 正式入住
• 行程：到达后直接前往浅草寺（无需等待入住）"
6.3 多 Agent 编排 UX 反模式
| 反模式 | 问题 | 正确做法 |
|---|---|---|
| Agent 电话会议 | 让用户看到 Agent 之间的内部讨论 | 只展示最终结论和关键决策点 |
| 责任不明确 | 出错后不知道找哪个 Agent | 对外统一入口，内部责任追踪 |
| 信息过载 | 多个 Agent 同时推送通知 | 由 Manager Agent 汇总后统一推送 |
| 状态不一致 | 不同 Agent 对同一事实理解不同 | 共享黑板模式 + 事实确认机制 |
7. 信任与透明：可解释性设计
7.1 三层可解释性模型
┌─────────────────────────────────────────────────────────────┐
│ 第一层：执行透明（Process Transparency） │
│ "Agent 现在在做什么？" │
│ 展示：当前步骤、预计剩余时间、已完成的子任务 │
├─────────────────────────────────────────────────────────────┤
│ 第二层：决策透明（Decision Transparency） │
│ "Agent 为什么做这个选择？" │
│ 展示：决策依据、对比方案、排除原因、信息来源 │
├─────────────────────────────────────────────────────────────┤
│ 第三层：能力透明（Capability Transparency） │
│ "Agent 擅长什么、不擅长什么？" │
│ 展示：置信度分数、能力边界、已知局限、何时需要人类 │
└─────────────────────────────────────────────────────────────┘
7.2 置信度可视化设计
Agent 回答的可信度指示器
✅ 高置信度 (0.85-1.0)
━━━━━━━━━━━ 85%
"这是基于官方文档和最新 API 响应的结论"
⚠️ 中等置信度 (0.60-0.84)
━━━━━━━ 62%
"结合多个来源推断，建议人工核对关键数据"
❌ 低置信度 (< 0.60)
━━━ 45%
"信息不完整，强烈建议人工确认后再使用"
7.3 审计追踪设计
每个 Agent 决策都必须留痕：
@dataclass
class AgentDecisionLog:
"""Agent 决策的完整审计日志。"""
decision_id: str # UUID
timestamp: datetime # 决策时间
agent_id: str # 执行 Agent 标识
user_query: str # 用户原始输入
reasoning_steps: List[dict] # 推理过程（Thought → Action → Observation）
tools_called: List[dict] # 调用的工具及参数
raw_outputs: List[str] # 工具原始返回
final_output: str # 最终输出
confidence_score: float # 置信度 (0-1)
human_approved: bool # 是否经过人工审批
approver_id: Optional[str] # 审批人
revision_history: List[dict] # 修改历史
def to_human_readable(self) -> str:
"""生成供人类阅读的审计摘要。"""
return f"""
📋 决策 #{self.decision_id} 审计摘要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🕐 时间：{self.timestamp}
🤖 Agent：{self.agent_id}
❓ 输入：{self.user_query}
📊 置信度：{self.confidence_score * 100:.0f}%
🔄 推理步数：{len(self.reasoning_steps)}
🔧 调用工具：{[t['name'] for t in self.tools_called]}
✅ 审批状态：{'已审批' if self.human_approved else '自动执行'}
"""
8. 四大设计模式的产品应用
8.1 模式选型决策树
任务特征分析
│
├── 确定性高 / 步骤明确？ ──→ Plan-and-Solve
│ （如：数据报表生成、标准流程执行）
│
├── 需要自主探索 / 工具灵活调用？ ──→ ReAct
│ （如：研究调查、问题排查）
│
├── 需要持续改进 / 有明确质量标准？ ──→ Reflexion
│ （如：写作润色、代码审查）
│
└── 需要多步依赖推理 / 状态追踪？ ──→ DEPS
（如：复杂决策分析、系统诊断）
8.2 ReAct 模式产品体验
ReAct 循环的可视化展示
用户："分析 Q2 销售额下滑的原因"
┌────────────────────────────────────────────────────┐
│ 循环 1: 数据获取 │
│ 🧠 Thought: 需要先获取 Q2 销售数据 │
│ 🔧 Action: query_sales_db(quarter="Q2", year=2026) │
│ 📊 Observation: Q2 销售额 ¥1.2M，同比 -15% │
└────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────┐
│ 循环 2: 竞品分析 │
│ 🧠 Thought: 需要对比竞品同期表现 │
│ 🔧 Action: search_competitor_news(quarter="Q2") │
│ 📊 Observation: 竞品 A 降价 20%，竞品 B 推出新功能 │
└────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────┐
│ 循环 3: 综合分析 │
│ 🧠 Thought: 结合数据和竞品信息，给出分析结论 │
│ ✅ 任务完成 │
└────────────────────────────────────────────────────┘
8.3 Plan-and-Solve 模式产品体验
Plan-and-Solve 的进度追踪界面
🎯 任务：编写 Python 数据分析报告
计划（预先生成，用户可调整）：
☐ 1. 读取 sales_q2.csv ────────── 预计 1 min
☐ 2. 清洗和预处理数据 ────────── 预计 2 min
☐ 3. 计算关键指标（同比/环比）── 预计 2 min
☐ 4. 生成可视化图表 ──────────── 预计 3 min
☐ 5. 撰写分析结论 ────────────── 预计 3 min
☐ 6. 导出 PDF 报告 ───────────── 预计 1 min
[用户可拖放调整顺序] [跳过某步骤] [添加自定义步骤]
8.3 Reflexion 模式产品体验
Reflexion 的自我改进展示
初稿生成 ✅ ──────────────────────────────────→
│
↓
🪞 自我审查：
• "第二段论据不够充分，需要补充数据"
• "结论部分应增加行动建议"
• "整体可读性评分：6.5/10"
│
↓
修改迭代（第 1 轮）✅ ────────────────────────→
│
↓
🪞 自我审查：
• "数据引用准确，但图表可以更清晰"
• "可读性评分：8/10 → 达标"
│
↓
输出终稿 ✅
8.4 DEPS 模式产品体验
DEPS = Describe, Explain, Plan, Select
用户："帮我选一个适合的云服务方案"
[D]escribe: 用户画像提取
→ 团队规模 15 人，月预算 ¥5000，峰值 QPS 2000
[E]xplain: 约束条件显式化
→ 必须支持自动扩缩容
→ 必须在国内有节点
→ 需要 CDN 和对象存储
[P]lan: 生成候选方案
├── 方案 A：阿里云 ECS + OSS + CDN
├── 方案 B：腾讯云 CVM + COS + CDN
└── 方案 C：AWS 中国区
[S]elect: 多维度评分
┌──────────┬─────┬─────┬─────┐
│ 维度 │ A │ B │ C │
├──────────┼─────┼─────┼─────┤
│ 成本符合 │ ✅ │ ✅ │ ❌ │
│ 性能达标 │ ✅ │ ✅ │ ✅ │
│ 技术支持 │ ⭐⭐⭐ │ ⭐⭐ │ ⭐⭐ │
│ 生态整合 │ ⭐⭐⭐ │ ⭐⭐⭐ │ ⭐⭐ │
│ 综合推荐 │ ★ │ │ │
└──────────┴─────┴─────┴─────┘
9. Agent 成功度量体系
9.1 自主度光谱模型
自主度 0% ───────────────────────────────────────→ 100%
手动模式 辅助模式 协作模式 监护模式 自主模式
(0-20%) (21-40%) (41-60%) (61-80%) (81-100%)
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
用户输入 Agent Agent & 用户 Agent 自主 Agent 完全
每步指令 提供建议 共同决策 执行 自治
人类只在
异常时介入
产品演进路径建议：
初期 → 辅助模式（建立信任）
中期 → 协作模式（渐进授权）
长期 → 监护模式（效率最优）
9.2 评估维度矩阵
| 维度 | 指标 | 测量方式 | 目标值 |
|---|---|---|---|
| 任务完成度 | 目标达成率 | 用户确认 / 自动校验 | > 90% |
| 效率 | 平均步数 | 完成任务的推理步数 | 比人类快 3x |
| 成本 | Token 消耗 | 每次任务 API 费用 | < ¥0.5 |
| 体验 | NPS 评分 | 用户满意度调查 | > 50 |
| 信任 | 人工接管率 | 用户主动介入比例 | < 15% |
| 安全 | 错误率 | 幻觉 / 工具调用失败 | < 2% |
| 可用性 | 首响时间 | 用户输入到首次反馈 | < 3s |
| 持久性 | 长任务完成率 | 跨会话任务完成比例 | > 85% |
9.3 产品评估量规
AGENT_PRODUCT_SCORECARD = {
"自主性 (Autonomy)": {
"description": "Agent 独立完成任务的深度",
"1 分": "完全手动，每个步骤需要用户明确指令",
"3 分": "可处理简单子任务，复杂决策需要确认",
"5 分": "能独立完成多步任务，只在高风险点请求确认",
"7 分": "高度自主，仅在异常或边界情况通知用户",
},
"可靠性 (Reliability)": {
"description": "任务成功完成的一致性和可预测性",
"1 分": "经常失败，用户无法依赖",
"3 分": "70% 成功率，有明显的不稳定因素",
"5 分": "90% 成功率，错误可预期和解释",
"7 分": "95%+ 成功率，完善的容错和恢复机制",
},
"透明性 (Transparency)": {
"description": "用户理解 Agent 行为的容易程度",
"1 分": "黑盒，无法知道 Agent 在做什么",
"3 分": "部分可见，但难以关联到决策逻辑",
"5 分": "可查看推理过程和关键决策点",
"7 分": "多层次透明（过程 + 决策 + 能力边界）",
},
"可控性 (Controllability)": {
"description": "用户对 Agent 行为的干预能力",
"1 分": "无法中断或修改 Agent 行为",
"3 分": "可以终止，但无法修改进行中任务",
"5 分": "可在关键节点暂停、修改和恢复",
"7 分": "随时可调整策略、撤销操作、重定向目标",
},
"适配性 (Adaptability)": {
"description": "Agent 学习和适应用户需求的能力",
"1 分": "无记忆，每次从零开始",
"3 分": "记住会话内上下文",
"5 分": "跨会话记忆用户偏好",
"7 分": "主动发现模式、预测需求、优化策略",
},
}
# 评分标准：
# 28-35 分 = 产品级可用（可发布）
# 20-27 分 = 原型验证（内测阶段）
# < 20 分 = 需要重新设计核心架构
10. 经典案例深度分析
10.1 Devin：自主编程 Agent 的产品设计
Devin 产品架构（Cognition Labs）
用户输入："创建一个展示股票数据的 React Dashboard"
│
▼
┌─────────────────────────────────────┐
│ Planner Agent │
│ • 分解为：组件设计、数据获取、样式、部署
│ • 生成执行计划（可编辑） │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 自主执行循环 │
│ ├── Code Agent → 编写 React 组件 │
│ ├── Test Agent → 运行测试套件 │
│ ├── Debug Agent → 修复失败用例 │
│ └── Deploy Agent → 推送到 Vercel │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 进度仪表板（面向用户） │
│ • 实时代码编辑器预览 │
│ • 执行日志（可点击展开详情） │
│ • 测试通过/失败状态 │
│ • [暂停] [修改需求] [确认完成] │
└─────────────────────────────────────┘
Devin 的关键产品设计决策：
| 决策 | 设计 | 效果 |
|---|---|---|
| 沙箱隔离 | 每个任务独立的 Docker 环境 | 安全 + 可复现 |
| 浏览器集成 | Agent 可像人类一样浏览网页 | 获取实时信息 |
| 计划可编辑 | 用户可在执行前修改分解步骤 | 保留控制权 |
| 状态可视化 | 实时展示 Agent 的屏幕操作 | 建立信任 |
10.2 AutoGPT 的演进：从炫技到实用
AutoGPT 发展脉络
v0.1 (2023.03) v0.4+ (2024-2025)
├── 完全自主（无限循环） ├── 可控自主（边界限制）
├── 记忆：纯文本文件 ├── 记忆：向量数据库 + 摘要
├── 角色：硬编码系统提示 ├── 角色：用户可配置 Persona
├── 无错误恢复 ├── 多层级容错 + HITL
├── 成本：单次 $10+ ├── 成本：预算上限 + 降级模型
└── 体验：不可预测、不可控 └── 体验：可配置、可审计
关键教训：
1. 完全自主不等于好体验 → 可控的自主才是产品
2. 无限循环 = 无限账单 → 必须设消费上限
3. 黑盒执行 = 用户恐慌 → 推理过程必须可见
10.3 Claude Computer Use：安全边界的产品设计
Claude 3.5 Sonnet 的 Computer Use 功能允许 Agent 直接控制操作系统——这是产品设计中安全与能力平衡的典范。
Claude Computer Use 安全设计
能力层：
├── 截图识别（感知当前屏幕）
├── 鼠标移动和点击
├── 键盘输入
└── 命令行执行
安全护栏：
├── 操作前确认（高风险操作弹窗）
├── 沙箱浏览器（隔离网络环境）
├── API 限制（敏感系统调用拦截）
├── 超时保护（长时间无响应自动终止）
└── 隐私默认（不上传个人文件到云端）
UX 设计：
├── 实时屏幕录制（用户可以看到 Claude 在做什么）
├── 操作日志（每一步都可回溯）
├── [立即打断] 按钮（随时人工接管）
└── 置信度降级（不确定时主动询问用户）
11. 伦理考量与安全护栏
11.1 Agent 伦理设计原则
┌─────────────────────────────────────────────────────┐
│ Agent 伦理设计五原则 │
├─────────────────────────────────────────────────────┤
│ 1. 人类最终决策权（Human Oversight） │
│ 永远保留人类对关键决策的否决权 │
├─────────────────────────────────────────────────────┤
│ 2. 能力诚实（Capability Honesty） │
│ Agent 必须坦陈自己的局限，不冒充人类或专家 │
├─────────────────────────────────────────────────────┤
│ 3. 数据主权（Data Sovereignty） │
│ 用户数据属于用户，Agent 只是临时处理者 │
├─────────────────────────────────────────────────────┤
│ 4. 可追溯性（Accountability） │
│ 每个行动都有明确的责任归属和审计记录 │
├─────────────────────────────────────────────────────┤
│ 5. 无害原则（Non-maleficence） │
│ 设计时优先考虑最坏情况，防止意外伤害 │
└─────────────────────────────────────────────────────┘
11.2 产品级安全护栏设计
class AgentSafetyGuardrails:
"""Agent 产品安全护栏配置模板。"""
INPUT_GUARDS = {
"prompt_injection_detection": True,
"jailbreak_filter": True,
"pii_detection": True, # 检测用户输入是否包含敏感信息
"instruction_override_check": True,
"max_input_length": 10000,
}
REASONING_GUARDS = {
"max_reasoning_steps": 50, # 防止无限思考
"loop_detection": True, # 检测循环推理
"contradiction_check": True, # 自检逻辑一致性
"cost_budget_per_task": 5.0, # 单次任务费用上限（美元）
}
ACTION_GUARDS = {
"dangerous_operation_list": [
"DELETE", "DROP", "TRUNCATE", # 数据库
"rm -rf", "format", # 系统
"transfer", "withdraw", # 金融
],
"require_approval_for": [
"资金操作 > ¥1000",
"数据导出 > 100 条",
"权限等级变更",
"外部 API 密钥操作",
],
"rate_limit_per_minute": 30,
}
OUTPUT_GUARDS = {
"harmful_content_filter": True,
"misinformation_flag": True, # 对不确定信息标注
"cite_sources": True, # 要求引用来源
"confidence_threshold": 0.6, # 低于此值须标注
}
PRIVACY_GUARDS = {
"data_minimization": True, # 只收集必要数据
"retention_limit_days": 90,
"user_deletion_right": True, # 支持用户删除数据
"third_party_sharing_opt_in": True, # 默认不共享
}
11.3 伤害情景分析与预防
| 风险情景 | 可能后果 | 产品设计对策 |
|---|---|---|
| Agent 生成错误医疗建议 | 用户健康受损 | 医疗场景强制免责声明 + 医生审核 |
| Agent 自主修改生产配置 | 服务宕机 | 生产环境只读模式 + 变更工单 |
| Agent 泄露对话隐私 | 数据泄露 | 端到端加密 + 本地优先处理 |
| Agent 被钓鱼攻击 | 凭证窃取 | 输入过滤 + 操作审批 |
| Agent 产生偏见输出 | 歧视 | 多样化训练 + 偏见检测 + 反馈机制 |
12. 总结：Agent 产品设计的核心框架
AI Agent 产品设计框架（AIDA-P 模型）
A - Autonomy（自主度校准）
└── 根据任务复杂度、风险等级、用户信任度动态调整
I - Interpretability（可解释性）
└── 过程透明 + 决策透明 + 能力透明三层设计
D - Dependability（可靠性）
└── 预防 → 检测 → 恢复 → 降级 → 止损 五层容错
A - Adaptability（适配性）
└── 短期记忆 → 长期记忆 → 情景记忆 → 语义记忆 四级进化
P - Protection（安全保护）
└── 输入护栏 + 推理护栏 + 行动护栏 + 输出护栏 + 隐私护栏
12.1 产品路线图建议
| 阶段 | 时间 | 重点 | 里程碑 |
|---|---|---|---|
| MVP | 1-2 月 | 单一模式（Chat）、3-5 个工具、无记忆 | 任务完成率 > 70% |
| 增强 | 3-4 月 | 加入 Copilot 模式、短期记忆、审批流 | 人工接管率 < 30% |
| 成熟 | 5-8 月 | 混合模式、长期记忆、多 Agent 编排 | NPS > 40 |
| 自主 | 9-12 月 | 自主模式、情景记忆、预测性行动 | 监护模式可用 |
📂 相关专题：
- AI 智能体架构设计 — 五大核心组件技术实现
- Agent 工作流编排设计 — LangGraph + Temporal 实战
- 人机协作模式 — HITL 审批与审计设计
- 多智能体协作 — CrewAI / AutoGen / LangGraph 对比
- Agent 框架深度对比 — LangChain / LlamaIndex / CrewAI / AutoGen
FAQ
Q: Agent 产品和传统 SaaS 产品最大的设计差异是什么？
A: 传统 SaaS 是确定性流程（用户操作 A→系统响应 B），Agent 产品是概率性目标达成（用户说目标→系统自主找路径）。最大的差异在于：用户不再控制每一步，而是授权 Agent 在边界内自主决策——这要求产品设计师更多关注"信任建立"、“进度感知"和"容错恢复”，而非传统的"流程优化"。
Q: 如何决定 Agent 的自主度应该设置多高？
A: 参考 风险 × 成本 × 用户信任 三维模型：高风险操作（资金、数据删除）→ 低自主度（必须审批）；低成本试错场景（草稿生成、搜索）→ 高自主度；新用户 → 低自主度（先建立信任），老用户 → 渐进提高。没有统一答案，需要根据用户反馈数据动态调整。
Q: Agent 产品如何衡量用户信任度？
A: 间接指标组合：1）人工接管率（越低越好，但不等于越高越好——可能说明 Agent 太保守）；2）用户是否开启"自动执行"开关（从审批模式切换到自动模式的比例）；3）任务完成后的"满意度评分"；4）长任务的中途放弃率。最佳实践是建立一个 Dashboard 持续追踪这些指标。
Q: 多 Agent 编排的产品设计需要避免哪些坑？
A: 三大坑：1）不要把内部编排暴露给用户——用户看到 3 个 Agent 在"讨论"会感到困惑和焦虑；2）不要设置单点故障——Manager Agent 挂掉后，系统要有降级方案；3）不要忽视通信成本——Agent 之间的 LLM 调用开销可能超过直接调用工具的经济成本。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。