第29章 Agent评估体系：成功率、成本、延迟怎么监控？

29.1 为什么需要评估体系？

很多团队做Agent产品，上线后就"凭感觉"判断好不好——用户没投诉就是好的，有人用就是成功的。但这种方式有很大问题：

没有评估体系的痛点：

• 不知道���果好不好：用户沉默不代表满意，可能是用了一次觉得不好就再也不来了
• 不知道问题在哪：用户投诉了，但不知道是哪一步出了问题（理解错了？工具调用失败？回答不准确？）
• 优化没有方向：想改进但不知道改什么，改了也不知道有没有变好
• 成本不可控：大模型调用费用越来越高，但不知道花在了哪里、值不值
• 无法量化价值：跟老板/投资人说"效果很好"，但拿不出数据支撑
• 回归风险：每次更新Prompt或模型，可能引入新问题，但没有测试发现

评估体系的价值：

• 量化效果：用数据说话，知道Agent到底好不好，好到什么程度
• 定位问题：快速发现哪类任务、哪个环节出了问题，精准优化
• 指导优化：基于数据决定优化方向，用A/B测试验证优化效果
• 控制成本：知道成本构成，找到降本空间，优化性价比
• 保障质量：每次更新前做回归测试，确保不引入新问题
• 证明价值：用数据向老板、投资人、客户证明产品价值

29.2 评估维度全景图

Agent的评估是多维度的，不能只看一个指标。一个完整的评估体系应该覆盖以下维度：

不同阶段关注的重点不同：

• 早期（MVP验证）：重点看效果质量（任务成功率、用户满意度），验证产品价值
• 成长期（优化迭代）：增加效率性能和成本经济，优化性价比
• 成熟期（规模化）：增加可靠性、安全性、用户体验，保障稳定运营

29.3 效果质量评估

效果质量是最核心的评估维度，回答"Agent做得好不好"这个问题。

29.3.1 任务成功率（Task Success Rate）

定义：Agent成功完成用户任务的比例。

计算方式：
任务成功率 = 成功完成的任务数 / 总任务数 × 100%

怎么判断"成功"？

• 客观标准：任务有明确的完成标准（如"订机票"= 成功出票、"查天气"= 返回了正确的天气信息）
• 用户反馈：用户明确表示满意或问题解决（如"对，就是这个"、"谢谢，搞定了"）
• 人工标注：人工审核任务记录，判断是否成功完成（适合复杂任务）
• 自动判断：用规则或模型自动判断（如检查是否调用了正确的工具、返回结果是否包含关键信息）

细分维度：

• 按任务类型：查天气成功率、订机票成功率、写文章成功率...
• 按难度：简单任务成功率、复杂任务成功率
• 按用户群体：新用户成功率、老用户成功率

目标参考：

• 简单任务（问答、查询）：>90%
• 中等任务（多步操作、内容创作）：>75%
• 复杂任务（多Agent协作、长流程）：>60%

29.3.2 回答准确率（Answer Accuracy）

定义：Agent回答的内容中，事实准确、没有错误的比例。

评估方法：

• 人工评估：标注人员逐条检查回答，判断是否有事实错误、幻觉、遗漏。这是最准确但成本最高的方法。
• 自动评估：用大模型作为评委（LLM-as-Judge），让另一个大模型评估回答的准确性。成本低、可扩展，但需要校准。
• 基准测试：用有标准答案的测试集（如问答对），自动比对回答和标准答案的一致性。
• 事实核查：对回答中的事实性声明，自动检索验证是否正确。

错误类型分类：

• 幻觉（Hallucination）：编造不存在的事实、数据、引用
• 事实错误：回答的信息不正确（如天气数据错了、政策内容错了）
• 理解错误：误解了用户的问题，答非所问
• 遗漏：应该包含的关键信息没有包含
• 逻辑错误：推理过程有问题，结论不成立

29.3.3 用户满意度（User Satisfaction）

定义：用户对Agent回答和服务的满意程度。

评估方法：

• 显性反馈：用户主动点赞/点踩、评分、写评论。直接但覆盖率低（只有少数用户会反馈）。
• 隐性反馈：从用户行为推断满意度——用户是否继续追问？是否重新提问？是否使用了Agent的建议？是否完成了任务？
• 问卷调查：定期向用户发送满意度问卷（CSAT、NPS）。样本量小但信息丰富。
• 用户访谈：深度访谈典型用户，了解使用体验和痛点。定性但深入。

关键指标：

• CSAT（客户满意度评分）：1-5分或1-10分，"您对本次服务满意吗？"
• NPS（净推荐值）："您有多大可能向朋友推荐我们的产品？"0-10分，NPS = 推荐者% - 贬损者%
• 点赞率：点赞数 / 总回答数
• 点踩率：点踩数 / 总回答数（越低越好）
• 任务完成后用户沉默率：完成任务后用户没有继续追问的比例（沉默通常表示满意）

29.3.4 错误率与失败分析

定义：Agent出现错误或失败的比例，以及错误的类型分布。

失败原因分类：

• 理解失败：没有正确理解用户意图（占比通常最高，约30%-40%）
• 规划失败：任务分解错误、步骤不合理
• 工具调用失败：选错工具、参数错误、工具执行失败
• 记忆失败：忘记了之前的信息、检索不到相关记忆
• 生成失败：回答内容有错误、格式不对、不完整
• 系统失败：API超时、网络错误、服务不可用

分析方法：

• 定期（每周/每月）抽样分析失败案例，分类统计
• 找出Top N失败原因，优先解决
• 对每个失败原因，分析根因，制定改进措施
• 跟踪改进效果，看失败率是否下降

29.4 效率性能评估

效率性能回答"Agent做得快不快"这个问题。

29.4.1 端到端延迟（End-to-End Latency）

定义：从用户发送请求到Agent返回最终结果的总时间。

构成：

端到端延迟 = 网络传输时间 + 大模型推理时间 + 工具调用时间 + 记忆检索时间 + 整合处理时间

关键指标：

• P50（中位数）：一半的请求在这个时间内完成，代表典型体验
• P90/P95/P99：90%/95%/99%的请求在这个时间内完成，代表长尾体验（用户最容易抱怨的就是慢的那几次）
• 平均值：所有请求的平均时间（容易被极端值影响，参考价值有限）

目标参考：

• 简单问答：P50 < 3秒，P95 < 8秒
• 多步任务（2-3次工具调用）：P50 < 10秒，P95 < 30秒
• 复杂任务（多Agent、长流程）：P50 < 30秒，P95 < 90秒

优化方向：

• 用更快的模型（如GPT-4o比GPT-4快）
• 减少工具调用次数（能一次搞定的不要分多次）
• 并行调用无依赖的工具
• 流式输出（Streaming），让用户先看到部分结果
• 缓存常用查询结果
• 优化记忆检索速度（用更快的向量数据库、减少检索量）

29.4.2 首字响应时间（Time to First Token）

定义：从用户发送请求到Agent返回第一个字（token）的时间。

为什么重要：用户感知的"快不快"很大程度上取决于首字响应时间。如果3秒内看到第一个字，用户会觉得"很快"；如果10秒还没反应，用户会觉得"卡死了"，即使最终结果很快出来。

优化方法：

• 流式输出（Streaming）：大模型生成一个字就返回一个字，不需要等全部生成完
• 减少首字前的处理：把记忆检索、工具调用等耗时操作放在流式输出之后，或并行处理
• 用更快的模型
• 预热（Warm-up）：保持模型连接，避免冷启动

29.4.3 工具调用性能

定义：Agent调用外部工具的性能指标。

关键指标：

• 工具调用次数：平均每个任务调用多少次工具（反映任务复杂度和规划效率）
• 工具调用成功率：工具调用成功的比例（排除参数错误、工具故障）
• 工具调用延迟：每次工具调用的平均时间和P95时间
• 工具选择准确率：选择了正确工具的比例（选错工具会浪费时间和成本）
• 重试率：工具调用失败后重试的比例（反映稳定性）

29.4.4 吞吐量（Throughput）

定义：系统单位时间内能处理的请求数或任务数。

关键指标：

• QPS（Queries Per Second）：每秒处理的请求数
• 并发用户数：同时在线的用户数
• 日/月活跃用户数（DAU/MAU）
• 系统最大承载量：不降级的情况下能支撑的最大并发

29.5 成本经济评估

成本经济回答"花了多少钱、值不值"这个问题。

29.5.1 成本构成

总成本 = 大模型调用费用 + 工具调用费用 + 基础设施费用 + 运维人力费用

大模型调用费用（通常占比最高，60%-80%）：

• 输入token费用：Prompt、对话历史、工具返回结果等输入的token数 × 单价
• 输出token费用：Agent生成的回答、工具调用请求等输出的token数 × 单价
• 不同模型单价不同：GPT-4o > GPT-4o-mini，Claude Opus > Claude Sonnet > Claude Haiku
• 注意：输入token通常比输出token便宜，但输入量通常远大于输出量（尤其是长对话和RAG）

工具调用费用：

• 搜索API（如Google Search、Bing Search）：按次计费
• 数据库查询：按查询量或存储量计费
• 第三方服务（如天气API、地图API）：按次或按月计费
• 向量数据库：按存储量和查询量计费

基础设施费用：

• 服务器/云主机：应用服务器、数据库服务器
• 存储：对象存储、数据库存储
• 网络：带宽、CDN
• 监控和日志服务

29.5.2 关键成本指标

单次任务成本（Cost Per Task）：
完成一个用户任务的平均成本 = 总成本 / 总任务数
这是最重要的成本指标，直接决定商业模式是否成立。

单次对话成本（Cost Per Conversation）：
一次完整对话（多轮）的平均成本。

每千次查询成本（Cost Per 1K Queries）：
标准化的成本指标，方便和行业对比。

Token消耗量：

• 平均每个任务消耗多少输入token、输出token
• 输入/输出token比例（通常输入远大于输出，因为对话历史和工具返回结果都算输入）
• Token消耗趋势：是否在增长？增长原因是什么？

成本转化率（Cost Conversion Rate）：
每花1元成本带来的收入或价值。
例如：单次任务成本0.5元，用户付费5元/月，平均每月用20次，成本转化率 = 5 / (0.5×20) = 0.5（收入是成本的2倍）。

29.5.3 成本优化策略

1. 模型分级使用
不同任务用不同模型：

• 简单任务（分类、格式整理、简单问答）→ 用小模型（GPT-4o-mini、Claude Haiku），成本低10-20倍
• 复杂任务（深度分析、创意写作、复杂推理）→ 用大模型（GPT-4o、Claude Opus），保证质量
• 用小模型做路由（判断任务类型），再分配给合适的模型

2. 减少Token消耗

• 优化Prompt，去掉冗余内容
• 对话历史做摘要压缩，只保留关键信息
• 工具返回结果精简，只保留关键字段
• RAG检索只返回Top-K最相关的内容，不要返回太多
• 设置最大输出token限制，避免生成过长内容

3. 减少工具调用

• 优化任务规划，减少不必要的工具调用
• 能一次批量查询的不要分多次
• 缓存常用查询结果（如天气、汇率等变化不频繁的数据）
• 用规则判断替代大模型判断（如简单的分类、格式转换）

4. 批量处理

• 把多个用户的请求批量处理，提高GPU利用率
• 非实时任务（如报告生成、数据分析）用异步批量处理，用更便宜的批量API

5. 成本监控与告警

• 实时监控成本，设置预算告警（如日成本超过阈值告警）
• 分析成本构成，找到最大的成本项，针对性优化
• 按用户、任务类型、模型维度分析成本，找到高成本低价值的部分
• 设置单用户/单任务成本上限，防止异常消耗（如死循环）

29.6 离线评估 vs 在线评估

评估分为离线评估（上线前）和在线评估（上线后），两者结合才能形成完整的评估闭环。

29.6.1 离线评估（Offline Evaluation）

定义：在上线前，用测试数据集在离线环境中评估Agent的效果。

方法：

• 测试集评估：构建有标准答案的测试集（如1000条典型用户问题+标准答案），自动跑测试集，计算准确率、成功率等指标
• 基准测试（Benchmark）：用行业公开的基准测试���（如MMLU、GSM8K、AgentBench）评估模型和Agent的能力
• 回归测试：每次更新Prompt、模型、工具后，重新跑测试集，确保关键指标不下降（不引入回归）
• 人工评估：标注人员对测试集的输出做质量评分，评估更细致的维度（如逻辑性、有用性、安全性）
• 红队测试（Red Teaming）：专门构造恶意、边界、异常的输入，测试Agent的安全性和鲁棒性

优点：

• 成本低，可重复，可自动化
• 上线前发现问题，不影响真实用户
• 可对比不同版本的效果，指导决策

缺点：

• 测试集不能完全覆盖真实用户的多样性
• 离线指标好不等于线上效果好（可能过拟合测试集）
• 复杂任务的标准答案难以定义

最佳实践：

• 测试集要覆盖典型场景、边界场景、异常场景，定期更新（加入新发现的失败案例）
• 每次上线前必须跑回归测试，关键指标不能下降
• 测试集规模：早期100-500条，成长期500-2000条，成熟期2000+条
• 测试集要标注难度和类型，分维度评估

29.6.2 在线评估（Online Evaluation）

定义：Agent上线后，在真实用户环境中评估效果。

方法：

• A/B测试：将用户随机分成两组，A组用旧版本，B组用新版本，对比两组的核心指标（成功率、满意度、留存率等），统计显著性后决定是否全量发布
• 灰度发布：先让小比例用户（如5%）使用新版本，观察指标和错误率，没问题再逐步扩大比例
• 埋点监控：在关键环节埋点，实时监控用户行为和系统状态（如工具调用次数、成功率、延迟、成本）
• 用户反馈：收集用户的点赞/点踩、评分、评论、投诉，分析满意度和问题
• 用户访谈：定期访谈典型用户，深入了解使用体验和痛点
• 留存分析：分析用户的次日留存、7日留存、30日留存，评估产品粘性

A/B测试的注意事项：

• 样本量要足够大，确保统计显著性（通常需要几千到几万次曝光）
• 实验时间要足够长（至少1-2周，覆盖工作日和周末）
• 只改变一个变量，否则不知道是什么导致了变化
• 关注多个指标，不能只看一个（如成功率提升了但成本也大幅上升，需要综合判断）
• 注意辛普森悖论：整体指标上升但分群体下降，需要分维度分析

29.6.3 离线+在线的评估闭环

1. 离线评估（上线前）
   ↓ 构建测试集 → 跑回归测试 → 人工抽检 → 红队测试
   ↓ 通过？→ 不通过则修改，重新评估
   ↓
2. 灰度发布（小流量上线）
   ↓ 5%用户 → 监控核心指标和错误率 → 没问题？
   ↓
3. A/B测试（对比验证）
   ↓ 随机分组 → 对比核心指标 → 统计显著性
   ↓ 新版本更好？→ 全量发布；否则回滚
   ↓
4. 全量发布 + 持续监控
   ↓ 实时监控指标 → 定期分析失败案例 → 发现优化点
   ↓
5. 优化迭代 → 回到第1步（离线评估新版本）

29.7 可观测性：日志、追踪、指标

可观测性（Observability）是评估体系的基础设施——没有它，你无法收集评估数据，无法定位问题。

29.7.1 三大支柱

1. 日志（Logs）
记录离散事件的详细信息。
Agent需要记录的日志：

• 用户请求日志：用户ID、时间、输入内容、会话ID
• 大模型调用日志：模型名称、输入token数、输出token数、耗时、费用、返回结果
• 工具调用日志：工具名称、参数、返回结果、耗时、成功/失败
• 记忆检索日志：查询内容、检索到的记忆、相似度、耗时
• 错误日志：错误类型、错误信息、堆栈、上下文

2. 指标（Metrics）
可聚合的数值型数据，用于监控趋势和告警。
关键指标：

• 请求量：QPS、日请求量、并发数
• 延迟：P50/P90/P95/P99延迟、首字响应时间
• 错误率：HTTP错误率、工具调用失败率、任务失败率
• 成本：日/月费用、单次任务成本、token消耗量
• 质量：任务成功率、用户满意度、点赞/点踩率
• 系统：CPU使用率、内存使用率、队列长度

3. 追踪（Traces）
记录一个请求从开始到结束的完整调用链路，每个环节的耗时和状态。
Agent的追踪链路示例：

用户请求（总耗时25秒）
├── 意图理解（2秒）
│   └── 大模型调用（2秒，输入500token，输出50token）
├── 记忆检索（1秒）
│   └── 向量数据库查询（1秒，返回3条记忆）
├── 任务规划（3秒）
│   └── 大模型调用（3秒，输入1000token，输出200token）
├── 工具调用1：天气查询（2秒）
├── 工具调用2：航班查询（5秒）
├── 结果整合（4秒）
│   └── 大模型调用（4秒，输入2000token，输出800token）
└── 返回用户

29.7.2 可观测性工具

选型建议：

• 用LangChain → LangSmith（集成最好，功能最全）
• 数据敏感/私有化 → LangFuse（开源，可私有化）
• 快速接入/小团队 → Helicone（最简单，一行代码）
• 已有企业监控体系 → Datadog/New Relic（和现有体系集成）

29.8 实战：搭建一个Agent评估仪表盘

让我们通过一个实战案例，看看如何设计和实现一个Agent评估仪表盘。

29.8.1 场景定义

目标：为一个客服Agent搭建评估仪表盘，让产品经理和运营人员能实时监控Agent的效果、成本、性能，快速发现问题。

29.8.2 仪表盘设计

顶部：核心指标卡片（KPI Cards）

┌─────────────┬─────────────┬─────────────┬─────────────┐
│  日任务量    │  任务成功率  │  用户满意度  │  日成本      │
│  12,345     │  82.5%      │  4.2/5      │  ¥1,234     │
│  ↑12% vs上周│  ↑3.2%      │  ↑0.1       │  ↓5% vs上周 │
└─────────────┴─────────────┴─────────────┴─────────────┘

第一行：趋势图

• 任务成功率趋势（近30天，按天）
• 用户满意度趋势（近30天，按天）
• 日成本趋势（近30天，按天）
• P95延迟趋势（近30天，按天）

第二行：分维度分析

• 按任务类型的成功率和成本（柱状图）：查订单、退换货、产品咨询、投诉...
• 失败原因分布（饼图）：理解失败35%、工具调用失败25%、回答错误20%、系统失败10%、其他10%
• 模型使用分布（堆叠图）：GPT-4o 60%、GPT-4o-mini 40%
• 用户满意度分布（柱状图）：5星45%、4星30%、3星15%、2星5%、1星5%

第三行：实时监控和告警

• 实时请求量（每秒更新）
• 当前错误率（超过阈值红色告警）
• 当前P95延迟（超过阈值红色告警）
• 最近的失败案例列表（可点击查看详情）

第四行：详细数据表格

• 最近的任务列表：时间、用户ID、任务类型、状态（成功/失败）、耗时、成本、用户评分
• 可筛选：按任务类型、状态、时间范围、用户ID
• 可排序：按耗时、成本、评分
• 可点击查看详情：完整对话记录、工具调用链路、大模型输入输出

29.8.3 数据采集

埋点设计：

每次用户请求，记录：
{
  "request_id": "req_001",
  "session_id": "sess_001",
  "user_id": "user_001",
  "timestamp": "2024-10-15T10:30:00",
  "user_input": "我的订单怎么还没到？",
  "task_type": "查订单",  // 意图分类
  "status": "success",    // success/failed
  "total_latency_ms": 8500,
  "total_cost": 0.035,
  "input_tokens": 1200,
  "output_tokens": 350,
  "model_used": "gpt-4o",
  "tool_calls": [
    {"name": "query_order", "params": {...}, "result": "...", "latency_ms": 1500, "success": true}
  ],
  "memory_retrieved": 3,
  "user_rating": 5,       // 用户评分（如果有）
  "user_feedback": "很满意",  // 用户文字反馈（如果有）
  "failure_reason": null,  // 如果失败，记录原因
  "conversation_history": [...]  // 完整对话记录（用于详细分析）
}

数据存储：

• 原始日志：对象存储（如S3），保存完整的请求记录和对话历史，用于详细分析和回溯
• 聚合指标：时序数据库（如Prometheus、InfluxDB），保存按天/小时聚合的指标，用于趋势图和实时监控
• 关系型数据：MySQL/PostgreSQL，保存任务列表、用户信息、配置等，用于详细数据表格和筛选

29.8.4 告警规则

29.8.5 定期分析机制

每日（自动化）：

• 生成日报：核心指标、异常告警、Top失败案例
• 发送到团队飞书群

每周（人工+自动化）：

• 生成周报：周度趋势、分维度分析、Top 10失败案例、优化建议
• 团队周会讨论：复盘问题，制定下周优化计划
• 抽样分析50个失败案例，分类统计根因

每月（深度分析）：

• 生成月度报告：月度趋势、用户增长、成本分析、质量改进、ROI分析
• 向管理层汇报：产品价值、进展、问题、计划
• 更新测试集：加入本月新发现的失败案例和典型场景
• 评估优化效果：本月做的优化哪些有效、哪些无效

29.9 产品经理视角：怎么定义Agent的成功指标

1. 不要只看技术指标，要关注业务价值
很多产品经理容易陷入技术指标（准确率、延迟、token数），但老板和投资人关心的是业务价值：用户增长、留存、收入、成本、ROI。技术指标是手段，业务价值才是目的。
例如：任务成功率从80%提升到85%，带来了什么业务价值？（留存率提升了多少？收入增加了多少？人工客服成本降低了多少？）

2. 定义北极星指标（North Star Metric）
每个产品应该有一个最核心的指标，代表产品的核心价值。
Agent产品的北极星指标可能是：

• 客服Agent：用户问题自助解决率（不需要人工介入的比例）
• 内容创作Agent：用户完成创作的数量和质量
• 个人助手Agent：周活跃用户数和人均使用次数
• 数据分析Agent：用户通过Agent完成的分析任务数

3. 建立指标体系，分层管理

北极星指标（1个）
    ↓
核心业务指标（3-5个）：用户增长、留存、收入、成本、满意度
    ↓
过程指标（10-20个）：任务成功率、完成率、延迟、错误率、工具调用次数...
    ↓
详细指标（50+个）：分任务类型、分用户群体、分模型、分时间段...

4. 指标要可执行、可改进
每个指标都应该能回答"这个指标不好时，我们能做什么来改进？"。如果一个指标变差了，但团队不知道怎么改进，那这个指标就没有指导意义。
例如："任务成功率"变差了 → 可以分析失败原因，针对性优化（理解失败→优化Prompt和意图分类；工具调用失败→优化工具和参数）。

5. 注意指标的副作用和博弈
任何指标都可能被博弈，导致副作用。
例如：

• 只看"任务成功率" → Agent可能拒绝处理难的任务，只做简单的，成功率就高了
• 只看"用户满意度" → Agent可能一味迎合用户，说用户想听的，而不是正确的
• 只看"成本" → 可能用最差的模型，导致质量下降
• 只看"响应速度" → 可能仓促回答，不做深度分析

6. 从第一天就开始埋点和评估
很多团队觉得"早期用户少，不需要评估"，等用户多了再做。这是错误的——从第一个用户开始就应该埋点和评估，因为：

• 早期数据是基线，没有基线就不知道后来是变好还是变差
• 早期用户少，可以深度分析每个用户的使用情况，发现产品问题
• 评估体系需要时间建设，早做早受益
• 早期的失败案例最宝贵，能指导产品方向

7. 评估不是一次性的，是持续的闭环
评估不是"做一次评估报告就完了"，而是持续的循环：监控→发现问题→分析根因→优化改进→验证效果→继续监控。
产品经理要把评估融入日常工作，每���看数据、分析失败案例、制定优化计划，而不是等到出了问题才看。

29.10 本章小结

评估体系是Agent产品的"仪表盘"和"体检报告"，没有它，你不知道Agent好不好、哪里有问题、怎么改进。

六大评估维度：

• 效果质量：任务成功率、回答准确率、用户满意度、错误率与失败分析
• 效率性能：端到端延迟（P50/P95/P99）、首字响应时间、工具调用性能、吞吐量
• 成本经济：单次任务成本、token消耗量、成本转化率、成本优化策略
• 可靠性：系统可用性、故障率、平均恢复时间、超时率
• 安全性：安全事件数、越权操作数、敏感信息泄露率、合规达标率
• 用户体验：留存率、复购率、NPS、完成任务所需轮次

离线+在线评估闭环：

• 离线评估：测试集、基准测试、回归测试、人工评估、红队测试（上线前）
• 在线评估：A/B测试、灰度发布、埋点监控、用户反馈、留存分析（上线后）
• 形成闭环：离线评估→灰度发布→A/B测试→全量发布→持续监控→优化迭代

可观测性三大支柱：日志（离散事件详情）、指标（可聚合数值）、追踪（完整调用链路）。工具选择：LangSmith（LangChain生态）、LangFuse（开源私有化）、Helicone（简单快速）、Datadog（企业级）。

产品经理视角：

• 不要只看技术指标，要关注业务价值
• 定义北极星指标，建立分层指标体系
• 指标要可执行、可改进
• 注意指标的副作用和博弈，多指标平衡
• 从第一天就开始埋点和评估
• 评估是持续的闭环，不是一次性的

评估体系是AI产品经理的核心能力之一——没有数据驱动的评估，就没有持续优化的方向，产品只能凭感觉迭代。掌握评估体系的设计、指标选择、工具使用、闭环机制，能让你用数据说话，用数据驱动产品增长。下一章我们会进入实战：设计一个制造业生产异常处理Agent，把前面学的所有知识综合运用起来。

📝 本章练习（5题）

答案与解析请在 互动学习看板 中作答查看。

📚 AI产品经理实战训练营 课程目录（44 章）

1. 第1章 AI产品经理是做什么的？和传统PM有什么区别？
2. 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
3. 第3章 零经验转行AI产品经理的3条路径
4. 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
5. 第5章 AI产品经理能力模型：你需要掌握哪些技能？
6. 第6章 实战：拆解3个你每天在用的AI产品
7. 第7章 大模型是什么？用大白话讲清楚
8. 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
9. 第9章 Prompt入门：写好提示词的5个原则
10. 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
11. 第11章 结构化输出：让大模型返回JSON、表格、代码
12. 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
13. 第13章 大模型的"幻觉"问题：产品经理怎么应对？
14. 第14章 实战：为一个智能客服设计完整Prompt体系
15. 第15章 RAG是什么？为什么企业都在做知识库？
16. 第16章 RAG工作原理：文档→分块→向量→检索→生成
17. 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
18. 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
19. 第19章 Reranker重排序：让检索结果更精准
20. 第20章 查询改写与混合检索：提升召回率的实战技巧
21. 第21章 知识库运营：文档治理、更新机制、效果监控
22. 第22章 实战：从零搭建一个企业知识库（完整流程）
23. 第23章 Agent是什么？和聊天机器人有什么区别？
24. 第24章 Agent核心能力：感知、规划、工具调用、记忆
25. 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
26. 第26章 工具调用（Function Calling）原理与实战
27. 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
28. 第28章 多Agent协作：多个智能体怎么分工配合？
29. 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
30. 第30章 实战：设计一个制造业生产异常处理Agent
31. 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
32. 第32章 AI产品竞品分析：怎么调研和拆解竞品？
33. 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
34. 第34章 AI产品原型设计：对话流、状态机、异常处理
35. 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
36. 第36章 AI项目管理：从需求到上线的全流程管控
37. 第37章 实战项目1：从零搭建制造业AI智能质检系统
38. 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
39. 第39章 AI产品经理简历优化：让HR一眼看中你
40. 第40章 项目经验包装：把普通项目讲成亮眼案例
41. 第41章 AI产品经理面试常见问题：提前准备，从容应对
42. 第42章 案例分析面试：用结构化思维征服面试官
43. 第43章 薪资谈判：拿到你应得的报酬
44. 第44章 入职前3个月：快速站稳脚跟，建立信任