Agent 是什么
你将学到什么
- 理解 Agent 与传统软件的本质区别
- 掌握 Agent 的四个核心能力
- 学会判断什么时候该用 Agent
预计时间：15分钟
快速开始
一句话定义
AI Agent = 能感知环境 + 自主决策 + 执行行动 + 持续迭代的 AI 系统
与只会"问答"的聊天机器人不同，Agent 可以：
- 主动分解目标
- 调用工具完成任务
- 根据结果调整策略
Agent vs 传统软件
本节学习目标
- 理解 Agent 与传统软件的 5 个核心差异
- 能向非技术人员解释 Agent 的特点
核心差异对比
| 对比维度 | 传统软件 | AI Agent |
|---|---|---|
| 执行方式 | 按预设规则逐步执行 | 自主规划步骤，动态调整 |
| 输入处理 | 结构化指令/表单 | 自然语言、图片、文件 |
| 错误处理 | 抛出异常，等待人工 | 感知错误，尝试重试 |
| 知识边界 | 代码写死 | 可调用外部工具/搜索 |
| 适合场景 | 流程固定、规则明确 | 目标明确但路径不确定 |
真实案例对比
场景：用户说"帮我订明天去北京的机票"
传统软件的处理方式：
1. 检查输入格式 → 缺少出发地，返回错误
2. 用户重新输入："从上海到北京"
3. 检查日期格式 → 缺少具体日期，返回错误
4. 用户重新输入："2026-04-25"
5. 查询航班 → 显示列表
6. 用户手动选择 → 填写乘客信息 → 支付Agent 的处理方式：
1. 理解意图："订机票"
2. 识别缺失信息：出发地、具体日期
3. 主动询问："您从哪里出发？明天是指 4 月 25 日吗？"
4. 用户确认后，自动：
- 调用航班查询 API
- 根据用户偏好（历史记录）推荐航班
- 填写常用乘客信息
- 引导支付关键区别：
- 传统软件：用户必须按流程填表
- Agent：理解意图，主动补全信息
互动练习
练习1：判断是否适合用 Agent
以下场景哪些适合用 Agent？
A. 用户上传发票，自动提取金额、日期、商家信息
B. 用户说"帮我写周报"，Agent 自动收集本周工作、生成报告
C. 银行转账：输入账号、金额，点击确认转账
D. 用户说"分析这份销售数据"，Agent 自动生成图表和洞察
显示答案
答案：B 和 D 适合用 Agent
解析：
A - 不适合
- 任务单一：提取结构化信息
- 用 OCR + 规则提取更稳定
- 不需要多步规划
B - 适合 ✅
- 需要多步骤：收集工作记录 → 分类整理 → 生成文本
- 需要调用多个工具：日历、邮件、项目管理系统
- 路径不确定：每周工作内容不同
C - 不适合
- 流程固定：输入 → 验证 → 执行
- 零失败容忍：金融交易不能出错
- 不需要自主决策
D - 适合 ✅
- 需要多步骤：读取数据 → 清洗 → 分析 → 生成图表
- 需要调用工具：数据分析库、图表生成
- 路径不确定：不同数据需要不同分析方法
检查点
Agent 的四个核心能力
本节学习目标
- 理解 Agent 的四个核心能力
- 掌握每个能力对应的 PM 关注点
- 能识别能力缺失导致的产品问题
能力架构
┌─────────────────────────────────────────────┐
│ AI Agent │
│ │
│ 感知 → 记忆 → 规划 → 行动 │
│ ↑ ↓ │
│ └────────── 反馈循环 ──────┘ │
└─────────────────────────────────────────────┘1. 感知（Perception）
定义：理解多模态输入，捕捉用户真实意图
能力范围：
- 文字：自然语言理解
- 图片：OCR、图像识别
- 文件：PDF、Excel、代码
- 环境：API 返回值、数据库状态
PM 关注点：
- 用户的真实意图能否被准确捕捉？
- 模糊输入能否被正确理解？
真实案例：
用户说："帮我找一下上周那个关于 AI 的文档"
感知能力强的 Agent：
- 理解"上周" = 过去 7 天
- 理解"关于 AI" = 标题或内容包含 AI 相关词汇
- 理解"文档" = PDF、Word、Markdown 等格式
感知能力弱的 Agent：
- 无法理解时间范围
- 无法理解模糊的主题描述
- 返回："请提供文档的完整名称"
2. 记忆（Memory）
定义：存储和调用历史信息
三种记忆类型：
| 类型 | 存储内容 | 时效性 | 技术实现 |
|---|---|---|---|
| 短期记忆 | 当前对话上下文 | 单次会话 | Context Window |
| 长期记忆 | 用户偏好、历史记录 | 永久 | 向量数据库 |
| 工具记忆 | 代码执行结果、文件内容 | 任务期间 | 临时存储 |
PM 关注点：
- 用户的偏好能否被记住？
- 历史对话能否被调用？
真实案例：
场景：用户第 3 次问"帮我订机票"
有记忆的 Agent：
- 记住用户常用出发地：上海
- 记住用户偏好：经济舱、早班机
- 直接问："还是从上海出发，订早班经济舱吗？"
无记忆的 Agent：
- 每次都问："从哪里出发？什么时间？什么舱位？"
- 用户体验差
3. 规划（Planning）
定义：将复杂目标分解为可执行步骤
主流规划方式：
ReAct（Reason + Act）
思考（Reason）→ 行动（Act）→ 观察（Observe）→ 循环
例子：
思考：用户要订机票，需要先查询航班
行动：调用航班查询 API
观察：返回 10 个航班
思考：用户偏好早班机，筛选 8 点前的航班
行动：展示筛选结果
观察：用户选择了第 2 个航班
思考：需要填写乘客信息
行动：调用用户信息 API
...CoT（Chain of Thought）
逐步推理，降低出错率
例子：
步骤1：理解用户意图 → 订机票
步骤2：识别缺失信息 → 出发地、目的地、日期
步骤3：询问用户 → "从哪里到哪里？什么时候？"
步骤4：查询航班 → 调用 API
步骤5：推荐航班 → 根据偏好排序PM 关注点：
- 规划步骤是否合理？
- 失败时能否重新规划？
4. 行动（Action）
定义：调用工具完成任务
工具类型：
| 工具类型 | 例子 | 风险 |
|---|---|---|
| 信息查询 | 搜索引擎、数据库查询 | 低 |
| 文件操作 | 读写文件、生成报告 | 中 |
| 外部 API | 发邮件、更新日历 | 高 |
| 不可逆操作 | 删除数据、发布内容 | 极高 |
PM 关注点：
- 哪些操作需要用户确认？
- 工具失败时怎么处理？
真实案例：
场景：Agent 帮用户发邮件
风险控制好的设计：
1. Agent 生成邮件草稿
2. 展示给用户："我准备发送这封邮件，请确认"
3. 用户确认后才发送风险控制差的设计：
1. Agent 直接发送邮件
2. 用户事后发现内容有误
3. 无法撤回互动练习
练习2：诊断 Agent 能力缺失
某旅行规划 Agent 收到用户投诉：
投诉1：用户说"帮我规划周末旅行"，Agent 回复"请提供出发地、目的地、预算"
投诉2：用户上次说喜欢海边，这次规划时 Agent 又推荐了山区
投诉3：Agent 规划了 10 个景点，但没考虑交通时间，根本走不完
问题：这 3 个投诉分别是哪个能力缺失？
显示答案
| 投诉 | 能力缺失 | 原因 | 改进方案 |
|---|---|---|---|
| 投诉1 | 感知 | 无法理解模糊输入"周末旅行" | 增加意图识别，主动推断出发地（用户位置）、目的地（热门景点） |
| 投诉2 | 记忆 | 没有长期记忆，忘记用户偏好 | 建立用户偏好数据库，记录"喜欢海边" |
| 投诉3 | 规划 | 规划不合理，没考虑约束条件 | 增加时间约束检查，规划时计算总耗时 |
检查点
Agent 的产品风险
本节学习目标
- 识别 Agent 的 4 大产品风险
- 掌握每个风险的应对策略
- 能在产品设计中规避风险
4 大产品风险
1. 幻觉放大
问题：多步执行中，每步的小错误叠加后可能酿成大问题
案例：
步骤1：Agent 查询用户订单（正确）
步骤2：Agent 理解用户要退货（错误！用户只是咨询）
步骤3：Agent 自动提交退货申请（灾难！）应对策略：
- 关键操作前必须用户确认
- 增加"撤销"功能
- 记录完整决策链，方便追溯
2. 不可控行动
问题：写文件、发消息等不可逆操作一旦出错代价高
案例：
- Agent 误删用户文件
- Agent 发送错误的客户邮件
- Agent 修改数据库配置导致系统崩溃
应对策略：
| 操作类型 | 风险等级 | 控制策略 |
|---|---|---|
| 信息查询 | 低 | 自动执行 |
| 文件读取 | 低 | 自动执行 |
| 文件写入 | 中 | 显示预览，用户确认 |
| 发送消息 | 高 | 生成草稿，用户确认 |
| 删除数据 | 极高 | 二次确认 + 可撤销 |
3. 成本失控
问题：Token 消耗随任务复杂度指数增长
案例：
简单任务：查询天气
- 消耗：500 Token
- 成本：$0.0005
复杂任务：规划 7 天旅行
- 消耗：50,000 Token（查询景点、酒店、交通、生成行程）
- 成本：$0.05
如果 DAU 10000，每人每天用 1 次：
- 月成本：$0.05 × 10000 × 30 = $15,000应对策略：
- 设置单次任务 Token 上限
- 增加超时终止机制
- 复杂任务分阶段确认（先生成草稿，用户确认后再详细规划）
4. 用户信任
问题：用户不知道 Agent 在"干什么"，黑箱感强
案例：
用户："帮我订机票"
Agent：（沉默 30 秒）
用户：卡了？还是在处理？
vs
用户："帮我订机票"
Agent："正在查询航班..."（5秒后）
Agent："找到 10 个航班，正在根据您的偏好筛选..."（3秒后）
Agent："为您推荐 3 个航班"应对策略：
- 展示关键步骤（"正在查询..."）
- 显示进度条（"已完成 3/5 步"）
- 失败时说明原因（"航班查询 API 超时，正在重试"）
可复用工具
工具6：Agent 风险检查清单
产品设计时逐项检查：
□ 关键操作有用户确认吗？（发送、删除、支付）
□ 不可逆操作有撤销机制吗？
□ 有单次任务 Token 上限吗？
□ 有超时终止机制吗？
□ 用户能看到 Agent 的执行进度吗？
□ 失败时有明确的错误提示吗？
□ 有完整的操作日志吗？（方便追溯）检查点
PM 必须能回答的问题
Q1：Agent 和 Copilot 有什么区别？
| 对比维度 | Copilot | Agent |
|---|---|---|
| 主导权 | 人主导 | AI 主导 |
| 工作方式 | AI 给建议，人确认后执行 | 人给目标，AI 自主执行 |
| 适用场景 | 需要人工判断的任务 | 目标明确、步骤可自动化 |
| 例子 | GitHub Copilot（写代码建议） | 旅行规划 Agent（自动规划行程） |
Q2：什么时候该用 Agent，什么时候不该用？
适合用 Agent：
- ✅ 任务步骤不确定，需要动态规划
- ✅ 需要调用多个工具/系统
- ✅ 允许一定失败率（可重试）
- ✅ 用户不想手动操作每一步
不适合用 Agent：
- ❌ 步骤固定、规则清晰的流程
- ❌ 单一系统内的简单查询
- ❌ 零失败容忍（金融交易、医疗指令）
- ❌ 每步都需人工审核
Q3：如何评估 Agent 的效果？
核心指标：
| 指标 | 定义 | 目标值 |
|---|---|---|
| 任务完成率 | 成功完成任务的比例 | >85% |
| 平均步骤数 | 完成任务的平均步骤 | 越少越好 |
| 平均耗时 | 完成任务的平均时间 | <30秒 |
| 用户满意度 | 用户评分 | >4.0/5 |
| 成本 | 单次任务平均成本 | <$0.1 |
主流 Agent 框架
| 框架 | 适用场景 | PM 了解要点 |
|---|---|---|
| LangChain | 通用 Agent，生态丰富 | 业界标准，但复杂度高 |
| AutoGPT | 自主长期任务 | 演示效果好，生产稳定性差 |
| CrewAI | 多 Agent 协作 | 角色分工明确，适合复杂流程 |
| Dify | 低代码 Agent 搭建 | 国内主流，PM 可直接上手 |
| Coze | 国内开放平台 | 字节系，生态集成好 |
下一步
继续学习
- 大模型原理（PM版） - 理解 LLM 的工作原理
- AI PM 技术边界 - 掌握成本估算和方案评审
- 面试题库 - Agent 部分 - 练习 Agent 相关面试题
实战任务
任务：评审一个 Agent 产品方案
提交格式：
【产品背景】（简述）
【Agent 的四个能力是否完整】
- 感知：
- 记忆：
- 规划：
- 行动：
【识别的风险】
【改进建议】附录
Agent vs LLM vs Copilot
LLM（大语言模型）
↓ 只会问答
Copilot（辅助型）
↓ 人主导，AI 给建议
Agent（自主型）
↓ AI 主导，自主规划执行术语速查表
| 术语 | 解释 |
|---|---|
| ReAct | Reason（思考）+ Act（行动）的循环框架 |
| CoT | Chain of Thought，逐步推理 |
| Tool Use | Agent 调用外部工具的能力 |
| Context Window | 模型能处理的最大上下文长度 |
| 向量数据库 | 存储 Embedding 的数据库，用于长期记忆 |