AI Agent 产品画布
AI Agent 产品画布（Agent Product Canvas） 是面向 AI Agent（智能体）产品的专用分析框架。与传统的 AI 产品不同，Agent 具备自主决策、工具调用、长期记忆和环境交互能力，其产品设计需要额外关注能力边界、工具定义、记忆设计、安全边界和成本模型等特有维度。
一、Agent 产品的独特性
传统 AI 产品： 用户 → 输入 → AI → 输出 → 用户（单轮/多轮对话）
AI Agent： 用户 → 目标设定 → Agent → 规划 → 工具调用 → 推理 → 记忆 → 行动 → 结果
↑_____________________________________↓ (循环)Agent 产品与普通 AI 产品的关键区别：
| 维度 | 传统 AI 产品 | Agent 产品 |
|---|---|---|
| 交互模式 | 问答式 | 任务委派式 |
| 自主程度 | 被动响应 | 主动规划与执行 |
| 工具使用 | 无 | 调用 API、数据库、外部系统 |
| 记忆管理 | 单次对话 | 多轮、跨会话、长期记忆 |
| 状态管理 | 无状态 | 有状态，需维护执行上下文 |
| 错误处理 | 重试 / 道歉 | 回退、重新规划、人工介入 |
| 安全风险 | 较低 | 高（可执行操作） |
二、Agent 产品画布七模块
┌────────────────────────────────────────────────────┐
│ 1. 能力边界 │ 2. 工具定义 │ 3. 记忆设计 │
├────────────────────────────────────────────────────┤
│ 4. 规划与推理 │ 5. 安全边界 │ 6. 交互体验 │
├────────────────────────────────────────────────────┤
│ 7. 成本模型 │
└────────────────────────────────────────────────────┘模块 1：能力边界
核心问题：Agent 能做什么，不能做什么？边界如何定义？
| 子项 | 说明 | 示例 |
|---|---|---|
| 职责范围 | Agent 被授权的任务类型 | 仅处理工单流转，不参与财务审批 |
| 自主层级 | 全自动 vs 建议式 vs 需确认 | Level 1: 建议；Level 2: 低风险自动 + 高风险确认；Level 3: 全自动 |
| 拒绝策略 | 什么场景下 Agent 必须说"不" | 超出知识范围、需要物理操作、涉及法律决策 |
| 升级机制 | 无法处理时如何升级 | 转人工客服、通知管理员、保存上下文 |
| 约束条件 | 执行中的硬性限制 | 单次最多操作 5 步、必须获得确认才能执行写操作 |
设计原则：
- 先窄后宽：从狭窄、明确定义的能力开始，逐步扩展
- 能力透明：让用户清楚知道 Agent 能做什么，避免过高预期
- 预留升级路径：始终设计好"我不行"的应对策略
自主层级模型（参考）
| 层级 | 名称 | 描述 | 示例 |
|---|---|---|---|
| L0 | 无 AI | 纯规则/手动 | 传统表单 |
| L1 | AI 辅助 | AI 建议，人决策 | 智能搜索、推荐 |
| L2 | 半自动 | 低风险自主 + 高风险确认 | 客服 Agent（转人工前自主处理） |
| L3 | 有条件自动 | 在限定范围内全自动 | 代码审查 Agent |
| L4 | 高度自动 | 大部分场景自主，例外时求助 | 运维 Agent |
| L5 | 全自动 | 完全自主 | 理论目标，当前不可行 |
模块 2：工具定义
核心问题：Agent 有哪些工具可用？如何让 Agent 正确使用工具？
工具是 Agent 能力的延伸。没有工具的 Agent 只是对话机器人。
2.1 工具分类
| 工具类型 | 说明 | 示例 |
|---|---|---|
| 信息检索 | 从外部系统获取数据 | 搜索引擎、知识库查询、数据库读取 |
| 写操作 | 修改/创建数据 | 创建工单、发送邮件、更新记录 |
| 计算/分析 | 执行计算或数据分析 | 数学计算、数据聚合、统计 |
| 外部 API | 调用第三方服务 | 天气查询、翻译、支付 |
| 代码执行 | 运行代码获取结果 | Python 解释器、SQL 执行 |
| 多媒体生成 | 生成图像/音频/视频 | DALL·E、语音合成 |
2.2 工具定义规范
每个工具应明确定义以下内容：
工具名称：search_knowledge_base
描述：在内部知识库中搜索相关信息
输入参数：
- query (string, required): 搜索关键词
- top_k (integer, optional, default=5): 返回结果数量
输出格式：list[{"title": str, "content": str, "score": float}]
权限要求：只读
调用限制：每分钟最多 30 次
错误处理：超时则返回空列表2.3 工具设计原则
- 描述要精确：工具描述是 Agent 理解工具用途的唯一途径，越清晰越好
- 参数要严格：定义好必填/可选参数和格式约束
- 错误要优雅：工具调用失败时返回明确错误信息，让 Agent 能重新规划
- 最小权限：只给 Agent 完成工作所需的最少权限
- 调用限流：防止 Agent 在循环中无限调用工具造成经济损失
模块 3：记忆设计
核心问题：Agent 如何记住用户、上下文和历史？
Agent 的记忆分为三个层级：
3.1 记忆层级
| 层级 | 名称 | 存储方式 | 生命周期 | 示例 |
|---|---|---|---|---|
| 短期记忆 | 当前对话上下文 | In-Context (Token) | 单轮对话 | 用户当前的问题、工具调用结果 |
| 会话记忆 | 本次会话的所有交互 | 向量数据库 / KV 缓存 | 会话期间 | 之前的问题与回答、用户偏好 |
| 长期记忆 | 跨会话的用户画像 | 结构化数据库 | 永久 | 用户偏好、历史行为、重要事实 |
3.2 记忆设计要点
| 维度 | 说明 |
|---|---|
| 记忆粒度 | 记住到什么程度？关键事实 vs 全部记录 |
| 记忆检索 | 如何从长期记忆中提取相关信息？（语义搜索、时间排序） |
| 记忆更新 | 何时更新记忆？用户说"其实我不喜欢XX"时需要覆盖旧记忆 |
| 记忆遗忘 | 何时遗忘？记忆容量有限，需要摘要/压缩策略 |
| 记忆隐私 | 用户是否可以查看/删除自己的记忆？ |
3.3 记忆设计原则
- 用户可控：让用户知道 Agent 记住了什么，并能主动修改或删除
- 上下文窗口管理：当上下文过长时，使用摘要、滑动窗口或检索策略压缩
- 记忆冲突处理：当新信息与旧记忆冲突时，以新信息为准，但记录变更历史
- Session 隔离：不同用户的记忆严格隔离，不能交叉
模块 4：规划与推理
核心问题：Agent 如何拆解任务、制定计划并执行？
4.1 规划模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
| ReAct (Reason + Act) | 边推理边执行，观察结果再推理 | 大多数 Agent 场景 |
| Plan-and-Execute | 先制定完整计划，再逐步执行 | 长流程、低变化场景 |
| Tree-of-Thought | 同时探索多个推理路径 | 需深度推理的复杂问题 |
| Reflexion | 执行后自我反思并修正 | 代码生成、错误修复 |
| Multi-Agent | 多个 Agent 协作分工 | 复杂工作流 |
4.2 规划限制
- 最大迭代次数：避免无限循环（如 max 10 步后必须给出结果或求助）
- 超时控制：整个任务有超时上限
- 分支管理：Agent 规划多个并行路径时的协调机制
- 重试策略：工具调用失败后重试还是重新规划
4.3 设计原则
- 可见性：让用户能看到 Agent 的思考过程和执行进度
- 可干预：允许用户在 Agent 执行时中途修改或打断
- 容错性：Agent 出错后能自我修复或优雅降级
模块 5：安全边界
核心问题：如何防止 Agent 做不该做的事？
这是 Agent 产品最重要的模块。一个可以执行操作的 Agent，其安全风险远高于纯对话 AI。
5.1 安全防护层级
输入层 → 权限层 → 执行层 → 输出层 → 审计层
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│Prompt│→│角色 │→│工具 │→│内容 │→│日志 │
│注入 │ │权限 │ │校验 │ │过滤 │ │审计 │
│检测 │ │控制 │ │ │ │ │ │ │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘5.2 安全措施
| 措施 | 说明 | 实施建议 |
|---|---|---|
| Prompt 注入防护 | 防止恶意指令注入 | 输入清洗、指令分隔、权限降级 |
| 权限最小化 | Agent 只拥有完成任务的最低权限 | 只读优先，写操作需额外确认 |
| 操作确认 | 高危操作必须二次确认 | 删除数据、转账、发送消息给客户 |
| 速率限制 | 限制 Agent 调用频率和总量 | 按用户/按工具设定配额 |
| 人工闸门 | 关键节点必须人工审核 | 涉及金钱、法律、隐私的操作 |
| 沙箱执行 | 代码执行在隔离环境中 | 容器化、网络隔离、无持久化 |
| 操作回滚 | 重要操作可撤销 | 快照、事务、版本控制 |
| 内容过滤 | 输出内容合规检查 | 敏感词、合规性、版权检测 |
| 全量审计日志 | 记录所有决策和操作 | 不可篡改的日志 + 原因记录 |
5.3 红队测试清单
- [ ] Agent 能否被诱导执行未授权的操作？
- [ ] Agent 能否泄露其他用户的数据？
- [ ] Agent 能否被用来发起攻击（如 SQL 注入、命令注入）？
- [ ] Agent 在异常输入下是否会崩溃？
- [ ] Agent 能否绕过权限检查？
- [ ] Agent 是否会泄露系统 prompt 或内部工具定义？
模块 6：交互体验
核心问题：用户如何与 Agent 互动？交互设计上有哪些特殊考虑？
6.1 交互模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
| 聊天界面 | 自然语言对话 | 通用 Agent 入口 |
| 命令行 | 结构化输入 | 开发者工具 |
| GUI + Agent | 图形界面嵌入 Agent | 企业管理后台 |
| API 调用 | 程序化调用 | 嵌入其他系统 |
| 事件触发 | 系统事件自动触发 Agent | 监控告警、定时任务 |
6.2 交互设计要点
- 思考过程展示：显示 Agent 正在做什么（思考→调用工具→得到结果→下一步）
- 进度指示：长任务展示进度条或步骤清单
- 结果预览：执行前展示将要执行的操作，让用户确认
- 取消/修改：用户可以随时取消正在执行的任务
- 错误友好：Agent 出错时给出可理解的解释和下一步建议
- 个性化：根据用户的使用习惯调整交互风格和信息密度
6.3 设计原则
- 渐进式披露：先展示结论，用户需要时再展示思考过程
- 可控自主：用户可以调整 Agent 的自主程度（从全自动到每一步都确认）
- 反馈闭环：Agent 执行完操作后主动告知结果
模块 7：成本模型
核心问题：Agent 产品的成本构成和优化策略？
Agent 的成本比普通 AI 产品更复杂，因为每次任务涉及多步推理和工具调用。
7.1 成本构成
| 成本项 | 说明 | 估算因子 |
|---|---|---|
| 推理 Token | 每步推理的输入+输出 Token | 每步 ~500-2000 Token，任务 ~3-10 步 |
| 工具调用 | 调用外部 API 的费用 | 按调用次数和 API 定价 |
| 记忆存储 | 向量数据库 / 长期记忆存储 | 按存储量和检索频率 |
| 上下文管理 | 历史摘要、记忆压缩 | 摘要产生的额外 Token |
| 重试成本 | 失败重试产生的额外消耗 | 增加 ~20-50% 的 Token 消耗 |
| 监控与日志 | 审计日志、对话记录 | 按存储量和查询量 |
7.2 成本优化策略
- 模型级联：简单推理用小模型（如 DeepSeek-V2-Lite），复杂推理才用大模型（如 DeepSeek V3）
- 任务合并：将多个小任务合并为一个大任务，减少规划开销
- 缓存工具结果：相同参数的工具调用结果可缓存复用
- 限制最大步数：严格控制 Agent 的最大迭代次数
- 提前终止：当 Agent 已经获得足够信息时，允许提前结束
- 会话摘要：长对话定期做摘要压缩，减少上下文 Token
三、完整案例：企业 IT 运维 Agent
产品背景
为公司内部 IT 部门开发的运维 Agent，帮助工程师处理服务器监控、告警排查和自动化修复。
画布填写
| 模块 | 内容 |
|---|---|
| 能力边界 | L2 半自动：排查诊断自动，修复操作需人工确认；不涉及数据库变更和安全策略修改 |
| 工具定义 | ① query_prometheus(metric, time_range) ② list_pods(namespace) ③ tail_logs(pod_id, lines) ④ restart_service(service_name) → 需确认 ⑤ run_kubectl(command) → 只读 ⑥ escalate_to_human(summary) |
| 记忆设计 | 短期：当前告警上下文；会话：本次排查路径和发现；长期：过往同类问题的解决方案（RAG 检索） |
| 规划与推理 | ReAct 模式，最大 8 步，超时 5 分钟；诊断完成给出根因分析和修复建议 |
| 安全边界 | 写操作必须人工确认；kubectl 限制为只读命令；操作日志全量记录 90 天；支持操作回滚 |
| 交互体验 | Slack 集成（@ops-bot）+ Web Dashboard；实时展示排查进度和建议的操作；工程师点击确认或拒绝 |
| 成本模型 | 大模型推理 ~$200/月，工具 API 调用 ~$50/月，总计 ~$300/月；相比减少 80% 的初级工程师排查时间 |
实际效果
- 告警响应时间从平均 15 分钟降至 2 分钟
- 初级工程师 70% 的排查任务可由 Agent 辅助完成
- 误操作率降至 0（因为写操作需人工确认）
四、Agent 产品设计原则总结
| 原则 | 说明 |
|---|---|
| 🔒 安全第一 | Agent 能执行操作，安全是产品设计的基石，而非附加项 |
| 🎯 边界清晰 | 让 Agent 和用户都明确知道"能做什么、不能做什么" |
| 👁️ 过程透明 | Agent 的思考和执行过程对用户可见 |
| ✋ 人工可控 | 用户可以随时拦截、修改、取消 Agent 的操作 |
| 🔄 逐步扩展 | 从狭窄能力开始验证，安全后再扩展 |
| 💰 成本可知 | Agent 的每一步行动都有成本，需要监控和优化 |
| 📝 日志完备 | 所有决策和操作都记录在案，可追溯、可审计 |
| 🧠 记忆智能 | 记忆不是存储全部，而是记住关键的、遗忘冗余的 |
五、Agent 产品准备度检查清单
- [ ] 能力边界已明确定义并文档化
- [ ] 每个工具的描述清晰、参数完整、权限合理
- [ ] 记忆策略已设计（短期/会话/长期）
- [ ] 自主层级已确定，高风险操作有确认机制
- [ ] 安全防护覆盖输入层到审计层
- [ ] Prompt 注入防护已实施并通过红队测试
- [ ] 交互体验支持过程可见和人工干预
- [ ] 成本模型已估算并有优化策略
- [ ] 审计日志全量记录
- [ ] 有明确的升级和回退机制
参考资源： Anthropic Agent 设计指南、OpenAI Function Calling 最佳实践、LangChain Agent 架构、Microsoft AutoGen 多 Agent 框架、Google Agent 安全白皮书。