第 10 章 智能体评估和优化迭代

重要学习目标
  1. 理解 智能体评估的目的与常见失效模式，掌握离线评估与在线评估的边界
  2. 理解 评估集、评分 Rubric 与基准线的构建方法，形成可重复的评估流程
  3. 应用 设计任务级评估方案，构建涵盖主任务与难例的评测集
  4. 应用 使用评估结果驱动提示与 Skill 的迭代优化，形成闭环改进
  5. 分析 评估结果中的偏差来源，区分模型问题与流程问题
  6. 评价 评测成本与质量收益的权衡，选择适合金融场景的评估强度

第 10 章知识结构思维导图

一个金融研报生成智能体，准确率 70% 和 90% 的差别是什么？70% 意味着每 10 份报告有 3 份需要人工重写，90% 才能真正节省人力。但智能体的表现不止看准确率——速度、成本、稳定性同样重要。如何建立一套科学的评估体系，让智能体从「能用」变成「好用」？

本章介绍智能体评估（Agent Evals）的完整框架，从评测集构建到评分标准设计，从优化迭代到监控回归，帮助你建立可重复、可量化的质量保障体系。

10.1 智能体评估（Agent Evals）

智能体评估是衡量 AI 系统性能、优化设计决策、确保可靠性的关键环节。评估不只是技术验证，更是业务价值实现的保障。

10.1.1 评估目的与常见失败模式

为什么要评估智能体

评估主要解决三个问题：

性能度量 量化智能体在特定任务上的表现，包括准确性、效率、成本等维度。比如金融研报生成任务，我们需要看报告的事实准确性、分析深度、生成速度以及 API 调用成本。

迭代优化 通过系统化评估发现瓶颈，指导改进方向。评估结果能直接回答：应该优化提示词、增加工具、调整流程编排，还是升级模型？

风险控制 在生产环境部署前发现潜在失效模式，建立护栏机制。金融场景尤其需要关注合规性、数据安全、输出一致性等风险点。

重要核心概念

评估贯穿智能体开发全流程，形成「构建 → 评估 → 优化」的迭代闭环。成功的智能体系统并非依赖复杂框架，而是通过持续评估找到适合特定场景的简单方案。

智能体的常见失效模式

理解智能体如何失败，是设计有效评估的前提。失效模式可分为三大类：

规划失败

规划失败主要体现在两个方面：

注记工具使用错误与目标偏离

工具使用错误：无效工具调用（尝试调用不存在或未授权的工具）、参数错误（工具存在但参数格式、类型或数量不正确）。

目标偏离：任务未完成（智能体声称完成任务，但实际遗漏关键要求）、违反约束（输出违反明确限制条件）。

金融场景中常见的例子：投资组合建议智能体在生成建议时忽略了用户明确要求的风险承受能力评估环节；为保守型投资者推荐了高风险衍生品；在生成财务预测时跳过了必要的假设说明。

工具失败

工具本身逻辑正确，但返回结果不符合预期：

  • 数据源问题：API 返回过时数据、缺失字段、格式变化
  • 计算错误：财务指标计算公式错误，导致 ROE、PE 等关键数据失真
  • 权限限制：第三方服务限流、认证失效

评估时需要独立测试每个工具，确保调用过程可追溯。

效率问题

智能体虽然完成任务，但成本或时间不可接受：

  • 步骤冗余：为查询一个简单数据调用 10 次 API
  • 成本失控：频繁使用高成本模型处理简单任务
  • 延迟过高：实时交易场景下，决策延迟超过市场窗口期
警告注意

金融场景对效率格外敏感。一个股票推荐智能体，如果单次推荐耗时超过 30 秒或成本超过 5 元，即使推荐质量再高，也难以商业化。

序号 知识点 重要度
10.1.1 评估目的与常见失败模式 ★★★

10.1.2 离线评估与在线评估边界

智能体评估分为离线评估和在线评估两种模式，需要根据开发阶段和风险承受能力选择合适方法。

离线评估

离线评估就是在测试环境中，用预先准备的测试集检验智能体。这和软件工程的单元测试和集成测试思路一样。

核心优势：

  • 可控性强：测试环境隔离，不影响真实用户
  • 可重复性：相同测试集可多次运行，便于对比不同版本
  • 成本可控：可以限制测试规模，避免大规模 API 调用

典型应用场景：

  • 新功能上线前验证：测试新增的财务分析工具是否正常工作
  • 模型切换评估：对比不同模型在研报生成任务上的表现
  • Prompt 优化实验：测试不同 System Prompt 对输出质量的影响

局限性：

  • 测试集覆盖有限，无法穷尽真实场景
  • 难以模拟复杂的用户交互和上下文依赖
  • 可能存在过拟合：智能体在测试集上表现好，实际应用中失效

在线评估

在线评估是在生产环境中对真实用户交互进行评估，通过监控、日志分析、用户反馈收集数据。

核心优势：

  • 真实性：反映实际使用场景和用户行为
  • 全面性：捕获测试集未覆盖的边缘情况
  • 持续性：长期监控性能变化，发现数据漂移

典型应用场景：

  • A/B 测试：部分用户使用新版智能体，对比转化率、满意度
  • 性能监控：跟踪响应时间、错误率、成本等运营指标
  • 用户反馈分析：收集点赞、差评、改写请求等隐性评估信号

风险与挑战：

  • 失败影响真实用户：可能导致客户流失、声誉损失
  • 难以控制变量：用户行为、市场环境随时变化
  • 评估成本高：需要投入监控系统、人工审核等资源

两种评估的对比

维度 离线评估 在线评估
环境 测试环境 生产环境
数据 预构建测试集 真实用户交互
优势 可控、可重复、成本低 真实、全面、持续
劣势 覆盖有限、可能过拟合 影响用户、难控变量
适用阶段 开发、迭代、上线前 灰度、生产、长期监控

两种评估的协同策略

最佳实践是将离线评估作为质量门禁，在线评估作为持续优化手段。具体采用三阶段推进：

  1. 离线验证：在测试集上达到性能阈值（如准确率 > 85%）才能进入下一阶段
  2. 小范围灰度：5%-10% 真实流量，密切监控关键指标
  3. 全量上线：离线和在线指标稳定后，逐步扩大覆盖范围
提示教学提示

某券商开发智能投顾系统的评估策略：离线阶段构建 500 个历史咨询案例的黄金数据集，要求智能体在投资建议准确性、合规性检查上达到 95% 通过率；灰度阶段选择 100 位内部测试用户，每天人工审核所有对话，发现 3 个高频失效模式并修复；全量上线后部署实时监控大盘，设置报警规则（如单日投诉率超过 0.5% 自动回滚）。

序号 知识点 重要度
10.1.2 离线评估与在线评估边界 ★★★

离线评估与在线评估对比

10.1.3 评测集构建方法

高质量评估集是可靠评估的基础。评估集需要兼顾代表性、多样性、可维护性。

黄金数据集的定义

黄金数据集（Golden Dataset）是经过专家标注、高质量验证的输入-输出对集合，作为评估 LLM 应用的基准。

与训练集的区别：

  • 训练集用于模型学习，黄金数据集用于质量验证
  • 黄金数据集不注入 LLM Prompt，而是作为评估标准
  • 数据质量要求更高，需要领域专家参与标注

每条黄金数据包含：

  • 输入（Input） 用户查询或任务描述
  • 预期输出（Expected Output） 理想回答或操作序列
  • 上下文（Context） 可选，用于需要 RAG 的场景
  • 评估维度（Criteria） 该条数据重点考察的能力

数据收集策略

人工收集：从真实业务场景中挑选代表性案例，优先覆盖高频场景（占用户查询量 80% 的典型需求）、边缘情况（容易出错的复杂查询）、失效案例（历史上智能体表现不佳的问题）。

LLM 辅助生成：用 LLM 批量生成测试数据，再由人工筛选验证。LLM 生成数据容易缺乏多样性，需要人工介入调整提示词、引入不同风格，避免测试集太干净，与真实用户输入脱节。

合成数据增强：对已有数据进行变换扩充，包括改写输入（相同语义不同表达）、增加噪声（模拟拼写错误、口语化表达）、调整难度（从简单问题派生复杂变体）。

评估数据分层

一个完善的评估数据集应该包含三个层次：

正常样本（Normal Cases） 符合任务常见输入分布的样本，占评估集的 60-70%。覆盖典型场景的主要变体，保持与真实生产环境的分布一致性。

边缘样本（Edge Cases） 处于任务边界或极端情况的样本，占评估集的 20-30%。识别方法包括等价类划分、极值测试、组合测试。例如：信息不完整、矛盾信息、超长/超短文本、中英混杂、专业术语密集。

对抗样本（Adversarial Cases） 故意设计用来欺骗智能体的样本，占评估集的 5-10%。设计策略包括语义混淆、格式攻击、逻辑陷阱。例如：负面词汇配合正面解读、双重否定、HTML 标签残留。

以 1000 个样本为例的推荐构成：

类型 数量 细分
正常样本 650 简单正面 200、简单负面 200、中性 150、复杂混合 100
边缘样本 280 信息不完整 60、矛盾信息 60、极端长度 40、中英混杂 40、专业术语密集 40、多事件嵌套 40
对抗样本 70 语义混淆 30、格式攻击 20、逻辑陷阱 20

金融场景评估集设计

以投资建议评估集为例：

输入 预期输出 评估维度
我有 10 万元闲钱，风险承受能力中等，请推荐投资组合 应包含：风险评估、资产配置比例、具体产品推荐、风险提示 完整性、合规性
茅台股票现在可以买吗？ 应包含：当前价格、估值分析（PE/PB）、行业地位、风险提示。不应包含：保证收益的表述 准确性、合规性
帮我计算如果我在 2020 年买入 1 万元沪深 300 指数基金，现在值多少钱？ 正确计算区间收益率，考虑分红再投资，需要调用历史数据工具 准确性、工具使用

数据集规模建议

  • 初期原型：50-100 条覆盖核心场景
  • 功能开发：200-500 条细分到各模块
  • 生产部署前：1000+ 条，包含极端情况
序号 知识点 重要度
10.1.3 评测集构建方法 ★★

评测数据三层结构

10.1.4 评分 Rubric 设计

评分标准（Scoring Rubric）将抽象的质量概念转化为可量化的评估规则，是评估体系的核心。

评分标准的设计原则

明确性 每个评分档位有清晰定义，避免模糊表述。差评例子：回答质量不错（无法指导评估）。好评例子：回答准确引用了招股说明书原文，计算公式无误，未包含主观推测。

可操作性 评估者（无论是人还是 LLM）能根据标准独立完成评分，减少主观差异。

层次性 设置多个档位（通常 3-5 档），拉开区分度。

常见评分标准类型

二元评分 通过/不通过，适用于刚性要求。示例：合规性检查——1 分表示输出包含保证收益、稳赚不赔等违规表述，0 分表示无违规内容。

等级评分 1-5 分或 1-10 分，评估质量程度。以财务分析深度为例：

  • 5 分：完整计算 5 个以上关键指标，有同业对比，结论有理有据
  • 4 分：计算 3-5 个指标，结论基本合理
  • 3 分：提及指标但未计算或计算错误
  • 2 分：分析肤浅，仅描述财报数字
  • 1 分：未进行财务分析

加权评分 不同维度赋予不同权重，计算综合得分。以研报评估为例：准确性（权重 0.4）、完整性（权重 0.3）、可读性（权重 0.2）、及时性（权重 0.1）。最终得分 = 0.4 × 准确性 + 0.3 × 完整性 + 0.2 × 可读性 + 0.1 × 及时性。

多维度评分框架

高质量智能体需要从多个角度评估。RAG 系统专用指标包括：

  • 忠实度（Faithfulness） 生成内容是否忠于检索到的原始文档，避免幻觉
  • 答案相关性（Answer Relevancy） 回答是否直接针对用户问题
  • 上下文精确度（Context Precision） 检索到的文档是否都与问题相关
  • 上下文召回率（Context Recall） 是否检索到了回答问题所需的全部关键信息

通用评估维度包括：

  • 准确性（Accuracy） 事实性陈述是否正确
  • 完整性（Completeness） 是否遗漏用户要求的内容
  • 连贯性（Coherence） 逻辑是否流畅，前后是否矛盾
  • 合规性（Compliance） 是否符合行业规范、法律法规
  • 效率（Efficiency） 完成任务的步数、时间、成本

金融场景评分案例

股票分析报告评分标准：

{
  "准确性": {
    "描述": "财务数据和计算是否准确无误",
    "评分规则": {
      "5": "所有数据有明确来源引用，计算公式正确，交叉验证通过",
      "4": "关键数据准确，个别次要数据存在小误差（<2%）",
      "3": "主要数据正确但缺少来源引用，或存在明显计算错误（2%-5%）",
      "2": "多处数据错误（>5%）或数据时效性差（超过 1 个季度）",
      "1": "严重错误，如使用错误股票代码、混淆单位等"
    }
  },
  "合规性": {
    "描述": "是否符合证券监管要求",
    "评分规则": {
      "Pass": "无以下违规内容：(1)保证收益承诺 (2)诱导交易 (3)虚假宣传 (4)内幕信息",
      "Fail": "包含任一违规内容，需人工复审"
    }
  },
  "完整性": {
    "描述": "必需章节和风险提示是否齐全",
    "评分规则": {
      "5": "包含公司概况、财务分析、估值、风险提示 4 个章节，风险提示具体明确",
      "3": "缺少 1-2 个章节，或风险提示过于笼统",
      "1": "缺少 3 个及以上章节，或完全没有风险提示"
    }
  }
}

权重配置：准确性 50%，合规性一票否决（Fail 则整体不通过），完整性 50%。

序号 知识点 重要度
10.1.4 评分 Rubric 设计 ★★

10.2 评估设计与指标（Eval Design & Metrics）

评估智能体的第一步是明确定义什么叫「成功」。本节介绍如何设计任务成功标准、评测数据分层策略、结构化评分指标以及人工抽检校准方法。

10.2.1 任务成功标准定义

任务成功标准（Task Success Criteria）需要具备这些特点：

可量化性（Quantifiable） 标准必须可以用具体数字衡量，而非模糊的定性描述。例如：客服智能体的成功标准是「90% 的查询无需人工介入即可解决」，而非「大部分问题能解决」。

任务特异性（Task-Specific） 不同任务需要不同的成功定义。金融研报生成的成功标准可能是：报告包含所有必需章节 + 数据准确性 > 95% + 无抄袭。交易信号生成的成功标准可能是：信号及时性 < 1 秒 + 历史回测夏普比率 > 1.5。

二元可判定性（Binary Decidability） 对于任何一个任务实例，必须能明确判断「成功」或「失败」。避免灰色地带，如果需要多级评分，应设置清晰的阈值。

成功标准的分层设计

根据任务复杂度，可以采用分层成功标准：

Level 1: 最小可行标准 智能体完成了任务的核心目标。例如：情感分析智能体正确识别出文本的主导情感。

Level 2: 质量标准 在完成任务的基础上，满足特定质量指标。例如：情感分析不仅正确，且置信度 > 0.8。

Level 3: 优化标准 在质量达标的基础上，满足效率、成本等优化目标。例如：情感分析在 100ms 内完成，且 API 调用成本 < $0.001。

注记知识卡片

以财报问答智能体为例说明成功标准的分层设计。任务：回答「公司 2023 年净利润同比增长率是多少？」。Level 1：返回了一个数值型答案。Level 2：答案与财报原文数据一致（允许 ±0.1% 误差）。Level 3：答案附带数据来源（财报页码/表格编号）。失败情形包括：返回空值/错误类型、数值偏差 > 0.1%、引用了错误的时间周期（如 2022 年数据）。

序号 知识点 重要度
10.2.1 任务成功标准定义 ★★★

10.2.2 评测数据分层策略

前一节已介绍正常样本、边缘样本、对抗样本的分层方法。本节深入探讨如何系统化地识别和设计各类样本。

正常样本设计原则

正常样本应覆盖典型场景的主要变体，保持与真实生产环境的分布一致性。以股票新闻情感分析为例：

  • 公司 Q3 营收同比增长 15%，超出市场预期（正面）
  • 受原材料价格上涨影响，毛利率环比下降 2%（负面）
  • 公司发布年度报告，维持去年盈利水平（中性）
  • 管理层在电话会议上表示对下季度持谨慎乐观态度（中性偏正）

边缘样本识别方法

边缘样本的识别可以采用三种策略：等价类划分（将输入空间分成若干等价类，测试每个类的边界值）、极值测试（测试数值型输入的最大/最小值）、组合测试（测试多个条件同时出现的极端组合）。

注记边缘样本设计实例：金融新闻情感分析
  • 信息不完整：公司宣布重大资产重组，交易对价待定
  • 矛盾信息：CEO 突然离职，但公司表示运营不受影响
  • 量价背离：股价今日涨停，成交量萎缩至日均的 20%
  • 多层嵌套：公司发布澄清公告，否认媒体报道的并购传闻
  • 中英混杂：Due to regulatory changes, Q4 EBITDA impact TBD
  • 极端长度：超长新闻（3000+ 字，含 10+ 个独立事件）或超短新闻（仅 15 字）

对抗样本设计策略

对抗样本的设计策略包括语义混淆（使用容易误导模型的表述）、格式攻击（异常格式、特殊字符、编码问题）、逻辑陷阱（表面一致但实际矛盾的信息）。

金融新闻情感分析的对抗样本示例：

  • 公司亏损扩大，但这正是战略转型期的预期表现（负面词汇 + 正面解读）
  • 利润大幅增长，主要来自一次性资产处置收益（正面结果 + 不可持续性）
  • 公司业绩符合预期，但预期本身已下调 30%（双重否定）
  • 公司 NOT 面临 NOT 破产风险（双重否定的否定）

数据版本管理

评估集不是一次性工程，需要随业务发展动态调整：

  • 定期补充：每月从线上日志中筛选新的失效案例加入测试集
  • 版本管理：用 Git 管理评估集，记录变更原因
  • 性能追踪：记录智能体在每个版本评估集上的得分曲线，识别退化
序号 知识点 重要度
10.2.2 评测数据分层策略 ★★★

10.2.3 结构化评分指标设计

评分维度选择原则

  • 少而精：聚焦 4-6 个核心维度，避免评分负担过重
  • 正交性：各维度之间尽量独立，减少重复评估
  • 可观察：每个维度都有明确的判断依据

通用评分维度（适用于大多数文本生成任务）包括准确性（内容是否符合事实）、完整性（是否涵盖所有必需信息）、相关性（是否紧扣问题，无多余内容）、流畅性（语言是否自然、通顺）。

评分等级设计

Likert 量表（5 分制）的设计示例：

  • 5 分 - 优秀（Excellent）：全面超出预期，无明显改进空间
  • 4 分 - 良好（Good）：满足所有核心要求，存在微小瑕疵
  • 3 分 - 合格（Acceptable）：满足最低要求，但有明显改进空间
  • 2 分 - 不合格（Poor）：部分满足要求，但存在重大缺陷
  • 1 分 - 失败（Failed）：完全未满足要求或产生严重错误

金融智能体评分示例：财报摘要生成

任务：为上市公司季报生成 200 字摘要。

评分维度与标准：

  1. 准确性（权重 40%）
    • 5 分：所有关键数据（营收/利润/同比）准确无误
    • 4 分：关键数据准确，次要数据有 1 处小误差（<2%）
    • 3 分：关键数据准确，次要数据有 2 处误差
    • 2 分：关键数据有 1 处明显错误
    • 1 分：关键数据有 ≥2 处错误或重大事实错误
  2. 完整性（权重 30%）
    • 5 分：涵盖营收、利润、现金流、重大事项全部 4 项
    • 4 分：涵盖 3 项核心指标
    • 3 分：涵盖 2 项核心指标（必须包含营收或利润）
    • 2 分：仅涵盖 1 项核心指标
    • 1 分：未涵盖任何核心指标
  3. 简洁性（权重 20%）
    • 5 分：长度 180-220 字，无冗余信息
    • 4 分：长度 160-250 字，信息紧凑
    • 3 分：长度 250-300 字或 140-160 字，略有冗余或遗漏
    • 2 分：长度 >300 字或 <140 字
    • 1 分：长度严重超标（>400 字）或过短（<100 字）
  4. 专业性（权重 10%）
    • 5 分：术语使用准确，符合财报披露规范
    • 4 分：术语基本准确，有 1-2 处不够专业的表述
    • 3 分：术语基本正确，但表述偏口语化
    • 2 分：有明显的术语误用
    • 1 分：多处术语错误或使用不当

综合得分 = Σ(维度得分 × 权重)

序号 知识点 重要度
10.2.3 结构化评分指标设计 ★★

10.2.4 人工抽检与一致性校准

为什么需要人工抽检

即使有了结构化评分指标，自动化评估仍可能存在盲区：

  • 边界案例的判断：自动规则难以处理似是而非的输出
  • 主观质量评估：如专业性、流畅性等维度需要人类判断
  • 评估系统本身的校准：确保评分标准与实际业务价值对齐

抽检策略设计

采用分层抽样（Stratified Sampling），目标是用 10% 的人工成本覆盖 90% 的风险。

抽检优先级设计：

  1. 高优先级（100% 抽检）
    • 自动评分在边界值的样本（如得分 2.8-3.2）
    • 不同评估方法结果冲突的样本
    • 新类型任务的前 50 个样本
  2. 中优先级（30% 抽检）
    • 随机抽样的正常样本
    • 所有边缘样本
  3. 低优先级（5% 抽检）
    • 自动评分极高（>4.5）或极低（<2.0）的样本

时间分布：新系统上线初期每天抽检 50-100 个样本，稳定期每周抽检 30-50 个样本，每季度对 5-10% 的全量数据进行人工复核。

评分者间一致性（Inter-Rater Reliability）

不同评分者对同一输出的打分可能存在差异，需要通过评分校准（Calibration）解决。

Step 1: 建立黄金标准集

选择 100 个代表性样本（覆盖各难度层级），由 3-5 位领域专家独立评分，召开校准会议讨论分歧样本达成共识，形成黄金标准集，每个样本有明确的标准答案和评分理由。

Step 2: 评分者训练

新评分者先对黄金标准集打分，计算与标准答案的一致性（Cohen’s Kappa）：

  • Kappa > 0.8：可独立评分
  • Kappa 0.6-0.8：需要监督式评分
  • Kappa < 0.6：需要重新培训

定期（如每月）用新的黄金标准样本测试评分者。

Step 3: 一致性监控

对 20% 的抽检样本进行双盲评分（两位评分者独立打分），计算一致性指标：

  • 完全一致率：两位评分者给出完全相同的分数
  • ±1 一致率：两位评分者的分数差距 ≤1 分

若一致率下降（完全一致率 < 60% 或 ±1 一致率 < 85%），需要召开校准会议或更新评分指南。若两位评分者分数差距 ≥2 分，交由第三位评分者裁决。

注记知识卡片

Cohen’s Kappa 系数是衡量两个评分者之间一致性的统计指标，取值范围从 -1 到 1。0 表示一致性与随机一致没有区别，1 表示完全一致。在实践中，0.6-0.8 被认为是实质性一致，0.8 以上被认为是几乎完全一致。

序号 知识点 重要度
10.2.4 人工抽检与一致性校准 ★★

10.3 优化迭代（Learning & Adaptation）

评估的最终目的是指导改进。本节介绍如何用评估结果驱动提示、流程与工具的持续改进。

10.3.1 经验积累与知识沉淀

智能体在运行过程中会产生大量交互数据和执行结果，这些都是宝贵的经验来源。有效的经验积累机制能够帮助智能体避免重复错误、沉淀最佳实践、加速学习过程、提升决策质量。

经验文档化

将经验转化为可共享的知识资产，采用结构化记录：

  • 问题描述 明确记录遇到的具体问题和场景
  • 解决方案 详细说明采取的措施和调整策略
  • 效果评估 量化改进前后的性能指标
  • 适用范围 标注解决方案的适用条件和限制

案例库建设

建立分类清晰的案例库，包括：

  • 成功案例（最佳实践）
  • 失败案例（教训总结）
  • 边界案例（特殊情况处理）
  • 对比案例（不同方案比较）

使用 lessons_learned.md

在项目中创建专门的经验积累文件，记录每次迭代的发现。建议采用统一模板：

# 智能体优化经验总结

## [日期]：[简短标题]

| 要素 | 内容 |
|------|------|
| 问题 | [具体描述遇到的问题] |
| 根因 | [分析问题产生的原因] |
| 方案 | [采取的解决措施] |
| 效果 | [量化的改进结果] |
| 关联 | [相关测试案例或文件] |

---

## 2026-01-18：情感分析准确率提升

| 要素 | 内容 |
|------|------|
| 问题 | 智能体在处理含有转折词的句子时，情感判断准确率只有 65% |
| 根因 | 原提示词过于简单，没有说明如何处理「虽然...但是」结构 |
| 方案 | 新提示词：分析文本情感，注意转折词后的内容往往是关键观点 |
| 效果 | 准确率从 65% 提升到 88% |
| 关联 | test_cases/sentiment_analysis.md 案例 #5-8 |
序号 知识点 重要度
10.3.1 经验积累与知识沉淀 ★★★

10.3.2 版本迭代策略

语义化版本控制

采用语义化版本号（Semantic Versioning）管理提示词和 Skill 的演进。版本号格式：X.Y.Z

  • 主版本号（X） 重大结构性变更，可能不向后兼容。示例：完全重构提示词框架，改变智能体的核心工作方式
  • 次版本号（Y） 新增功能或上下文参数，保持向后兼容。示例：添加新的评估标准，引入额外的输入参数
  • 修订号（Z） 小修复和微调，如错别字纠正、措辞优化

版本号使用示例：

v1.0.0 → v1.0.1  修复提示词中的错别字
v1.0.1 → v1.1.0  添加新的输出格式要求
v1.1.0 → v2.0.0  完全重构提示词结构

版本管理最佳实践

将提示词视为代码管理：

  • 使用 Git 等版本控制系统追踪所有变更
  • 维护清晰的变更日志（Changelog）
  • 记录每次修改的作者和时间戳
  • 支持快速回滚到先前版本

Git 提交规范示例：

git commit -m "feat(sentiment): 增加转折词处理逻辑"
git commit -m "fix(sentiment): 修正中性情感误判问题"
git commit -m "test(sentiment): 新增 5 个转折句测试案例"

渐进式迭代原则

采用小步快跑策略：

  • 每次只改动一个关键要素
  • 快速验证改动效果
  • 避免多个变量同时变化导致难以定位问题根源

通常需要多轮 Plan-Do-Check 循环才能达到预期效果，不要期望一次改动就完美解决问题。

提示教学提示

A/B 测试是验证优化效果的黄金标准。设计原则包括：单一变量控制（一次测试只改变一个关键因素）、样本代表性（确保测试数据覆盖真实使用场景）、统计显著性（收集足够样本量以支持结论）、时间窗口控制（避免特定时段的偏差影响结果）。

序号 知识点 重要度
10.3.2 版本迭代策略 ★★★

10.3.3 失败样例分析与修正

失败分析框架

有效的失败分析应遵循三个阶段：

识别（Identify） 理解和识别模型错误及公平性问题：我的智能体有哪些类型的错误？错误在哪些领域最为普遍？错误模式是否具有系统性？

诊断（Diagnose） 探索错误背后的深层原因：这些错误的根本原因是什么？是数据质量问题还是提示词设计缺陷？是否存在未被充分考虑的边界情况？

缓解（Mitigate） 采取有针对性的改进措施：如何改进智能体以避免类似错误？需要调整哪些组件（提示词、工具、流程）？改进措施的优先级如何排序？

常见失败原因分类

  • 数据质量问题 训练数据存在偏差或不完整、输入数据格式不符合预期、缺少关键上下文信息
  • 提示词设计缺陷 指令表述模糊不清、缺少必要的约束条件、示例选择不当
  • 系统集成问题 微服务间的交互异常、异步操作的时序问题、网络延迟或连接中断
  • 外部依赖故障 API 服务不可用、第三方模型性能下降、资源配额限制

失败案例文档化

采用结构化记录模板：

## 失败案例 #ID

**发生时间**：2026-01-18

**任务类型**：研究报告生成

**失败现象**：
输出报告缺少结论部分，格式不完整。

**根因分析**：
提示词中未明确要求生成结论，智能体在内容较长时容易截断。

**修复方案**：
1. 在提示词中显式添加「必须包含结论部分」的要求
2. 增加输出完整性检查机制
3. 设置分段生成策略，避免单次输出过长

**修复效果**：
应用修复后，在 50 个测试案例中，结论缺失率从 30% 降至 0%。

**适用范围**：
所有长文本生成任务
序号 知识点 重要度
10.3.3 失败样例分析与修正 ★★

10.3.4 迭代效果验证

PDCA 持续改进循环

Plan-Do-Check-Act（PDCA）循环是持续改进的经典框架，特别适用于智能体系统的优化迭代。

Plan（计划） - 识别改进目标：基于用户反馈、性能监控确定优化方向 - 制定行动计划：明确要调整的组件、预期效果和验证方法 - 设定成功标准：定义量化的评估指标和阈值

Do（执行） - 小规模试点：先在受控环境或小比例流量中测试变更 - 充分记录过程：捕获所有相关数据，包括成功和失败的结果 - 团队协作：确保参与人员理解变更目标和执行方法

Check（检查） - 数据分析：对比变更前后的性能指标 - 差距识别：分析实际效果与预期目标的偏差 - 根因探索：如果效果不佳，深入调查原因

Act（行动） - 标准化推广：如果测试成功，将改进措施应用到生产环境 - 调整优化：如果效果未达预期，根据检查结果调整方案 - 进入下一循环：持续迭代，追求更高水平的性能

迭代效果验证方法

验证改进效果需要：

  1. 基线对比：保存改进前的性能指标作为基线
  2. 同等条件测试：在相同测试集上对比新旧版本
  3. 统计显著性检验：确保差异不是随机波动
  4. 回归检查：确保新功能没有破坏已有能力
警告注意

迭代验证的关键原则是每次只改一个变量。如果同时修改了提示词和数据源，当结果变化时，无法确定是哪个因素起了作用。这会导致调试困难，甚至可能引入新问题而不自知。

序号 知识点 重要度
10.3.4 迭代效果验证 ★★

PDCA 持续改进循环

10.4 评估监控与回归（Evaluation & Monitoring）

智能体系统的监控与回归测试是确保生产环境质量的关键机制。不同于传统软件会抛出明确错误，大语言模型智能体容易出现「静默退化」——输出看起来合理，实际质量已经下降。

10.4.1 自动化回归测试

回归测试的必要性

回归测试确保新版本不会破坏已有功能。LLM 系统的回归测试需要特别设计，因为 LLM 输出并非确定性的，难以用传统的字符串匹配验证。

测试流程

  1. 基线建立 用当前稳定版本运行全部测试用例，记录输出和指标
  2. 变更测试 每次修改提示词、模型或参数后重新运行
  3. 对比分析 将新结果与基线对比，识别退化
  4. 质量门禁 只有通过回归测试才允许部署

LLM-as-Judge 评估

LLM-as-Judge（大模型评判法）是用一个 LLM（通常是更强大的模型）来评判另一个 LLM 的输出质量。这类似让一位资深分析师审核初级分析师的报告。

它的优势在于：可扩展性（比人工评估快数百倍）、一致性（相同输入总是得到相同评分）、灵活性（可快速调整评估维度）。

警告LLM 评审的常见偏见
  • 位置偏见：在多选项比较中倾向于选择特定位置的选项
  • 冗长偏见：倾向于给更长的输出更高分数
  • 自我偏好：评估自己生成的内容时倾向于给出更高分
  • 形式偏见：倾向于给使用正式语言的输出更高分

缓解方法：随机打乱选项顺序、在评分标准中明确简洁性维度、使用不同模型作为评判者、采用盲测设计。

提示词版本控制与测试

提示词的微小改动可能导致输出巨变，必须严格控制。每个版本都应该：

  • 记录修改原因和预期改进
  • 在标准测试集上运行完整评估
  • 与前一版本进行 A/B 对比
  • 生产环境小流量灰度验证
序号 知识点 重要度
10.4.1 自动化回归测试 ★★★

10.4.2 日志记录与趋势监控

多层次监控架构

现代 LLM 智能体监控系统采用四层架构，从数据输入到最终输出全程跟踪。

1. 数据流监控层

监控输入数据质量（用户查询的完整性、格式合规性）、Token 消耗追踪（每次请求的输入/输出 token 数量）、数据敏感性检测（自动识别可能包含 PII 的内容）。

2. 模型响应监控层

注记关键监控指标
  • 响应质量评估（准确性、相关性、上下文一致性）
  • 生成特征追踪（输出长度、结构化程度、语义连贯性）
  • 异常模式识别（幻觉、拒绝回答、格式错误）

3. 系统性能监控层

监控延迟指标（首 token 时间、总响应时间）、资源利用（CPU、GPU、内存使用率）、吞吐量（每秒请求数、并发处理能力）。

4. 实时分析层

提供即时异常检测（响应时间激增、错误率突增）、趋势分析（性能退化趋势、成本增长轨迹）、自动预警（超过阈值自动触发告警）。

核心监控指标

指标类型 具体指标 说明
性能指标 延迟（Latency） P50/P95/P99 响应时间
吞吐量（Throughput） 每分钟处理请求数
错误率（Error Rate） 失败请求占比
质量指标 准确性（Accuracy） 答案正确率
一致性（Consistency） 相同输入的输出稳定性
幻觉率（Hallucination Rate） 虚构内容比例
业务指标 用户满意度 点赞/点踩比率
任务完成率 成功解决用户问题的比例
成本指标 Token 成本 API 调用费用
缓存命中率 通过缓存节省的成本

结构化日志设计

日志需要记录完整的请求-响应信息，便于后续分析和问题排查。

字段说明：
- timestamp: 请求时间戳（UTC 格式）
- request_id: 唯一请求标识，用于链路追踪
- agent: 智能体类型
- model: 使用的模型
- input.query: 用户查询内容
- input.context_length: 上下文 token 数
- output.token_count: 输出 token 数
- output.finish_reason: 结束原因（stop=正常/length=截断/error=错误）
- metrics.latency_ms: 响应延迟（毫秒）
- metrics.cost_usd: 本次调用成本
- metrics.quality_score: 自动质量评分
- metadata.prompt_version: 当前提示词版本号
{
  "timestamp": "2026-01-18T14:35:22Z",
  "request_id": "req-abc123",
  "agent": "financial_qa",
  "model": "claude-3.5-sonnet",
  "input": {
    "query": "如何评估一家公司的估值？",
    "context_length": 1200
  },
  "output": {
    "response": "...",
    "token_count": 350,
    "finish_reason": "stop"
  },
  "metrics": {
    "latency_ms": 520,
    "cost_usd": 0.015,
    "quality_score": 8.5
  },
  "metadata": {
    "prompt_version": "v2.3",
    "retrieval_docs": 5,
    "cache_hit": false
  }
}
序号 知识点 重要度
10.4.2 日志记录与趋势监控 ★★

多层次监控架构

10.4.3 基准线对比方法

建立性能基线

性能基线是评估改进效果的参照物。基线应包含多个维度：

生产基线配置

模型基线：
- 主模型：Claude 3.5 Sonnet
- 备用模型：GPT-4
- 切换条件：主模型延迟 > 3s 或错误率 > 5%

性能基线（过去30天 P95）：
- 端到端延迟：850ms
- 首 token 时间：180ms
- 吞吐量：120 req/min

质量基线（周平均）：
- 用户满意度：4.2/5.0
- 任务完成率：87%
- 幻觉检出率：3.1%

成本基线（每日）：
- API 调用费用：$145
- 平均单次成本：$0.012

A/B 测试框架

同时运行两个版本，科学对比效果。

ab_test_config = {
    # 实验标识：用于追踪和区分不同实验
    "experiment_id": "prompt-v2.4-test",

    # 流量分配：将用户随机分为两组
    "traffic_split": {
        "control": 0.5,    # 50% 用户使用 v2.3（对照组）
        "treatment": 0.5   # 50% 用户使用 v2.4（实验组）
    },

    # 实验时长：至少运行 7 天以覆盖周内/周末差异
    "duration_days": 7,

    # 主要指标：实验成功的核心判断依据
    "primary_metric": "task_completion_rate",

    # 次要指标：观察是否有意外副作用
    "secondary_metrics": ["latency_p95", "cost_per_request"],

    # 最小样本量：保证统计显著性
    "minimum_sample_size": 1000
}

使用统计显著性检验（如 t 检验）判断差异是否显著。只有 p 值 < 0.05 时，才能认为实验组与对照组存在显著差异。

模型漂移监测

模型性能会随时间退化，需要持续监测：

  • 输入分布漂移：用户查询的主题分布是否改变？新出现的查询类型占比？
  • 输出分布漂移：模型生成的答案长度是否异常？特定词汇的使用频率是否变化？
  • 概念漂移：输入-输出关系是否改变？

监测方法包括 KS 检验检测分布差异、监测新类别占比、定期人工审核样本。

序号 知识点 重要度
10.4.3 基准线对比方法 ★★

10.4.4 质量门禁设置

质量门禁的定义

质量门禁是一组标准，只有达到这些标准才能进入下一阶段（如从开发到生产）。

持续评估管道

将回归测试集成到 CI/CD 流程：

代码提交
    ↓
自动触发评估
    ↓
[阶段1] 快速冒烟测试（10个核心用例，2分钟）
    ↓ 通过
[阶段2] 完整回归测试（200+用例，15分钟）
    ↓ 通过
[阶段3] 性能基准测试（延迟、成本、吞吐量）
    ↓ 通过
质量门禁检查
    ↓ 达标
灰度发布（5%流量）
    ↓ 监控24小时
全量发布

质量门禁配置示例

quality_gates:
  regression_test:
    threshold: 0.95  # 至少95%的测试用例不能退化
    critical_tests_pass_rate: 1.0  # 核心用例必须100%通过

  performance:
    p95_latency_increase: 0.15  # P95延迟增长不超过15%
    cost_per_request_increase: 0.20  # 单次成本增长不超过20%

  quality:
    min_accuracy: 0.82  # 最低准确率
    max_hallucination_rate: 0.05  # 幻觉率上限5%

分层告警机制

不同严重程度触发不同响应：

  • Critical（P0） 系统不可用或核心功能失效，错误率 > 50%、延迟 > 10 秒。触发：立即通知值班工程师，自动启动应急预案
  • High（P1） 性能显著下降但系统仍可用，幻觉率 > 15%、成本激增 > 3 倍。触发：30 分钟内通知负责人，记录详细日志
  • Medium（P2） 轻微退化或趋势性问题，准确率下降 5-10%。触发：每日汇总邮件，纳入下次迭代优化
  • Low（P3） 信息性通知，新用例类型出现。触发：记录到日志，定期回顾
序号 知识点 重要度
10.4.4 质量门禁设置 ★★

评估工作流与质量门禁

10.5 Claude Code Agent 评估与迭代优化实践

本节介绍如何在 Claude Code 中实践智能体评估与优化的具体配置与应用。

10.5.1 评估框架搭建

使用 CLAUDE.md 记录评估标准

CLAUDE.md 不仅用于指导智能体行为，还可以记录评估标准和经验教训。建议在 CLAUDE.md 中维护三类信息：

  1. 质量检查清单：任务输出的必需要素和加分项
  2. 常见问题库：已发现的问题、根因和解决方案
  3. 评估阈值：各指标的合格线和目标线
## 评估标准

### 数据分析任务质量检查

**必须满足**：数据来源清晰标注、计算过程有明确步骤、结论有数据支撑

**加分项**：提供可视化图表、给出置信区间、指出数据局限性

### 常见问题

**问题**：智能体给出过于绝对的结论
**解决**：在提示词中加入「如果数据不足，说明局限性」

创建评估 Skill

在 .claude/skills/eval-sentiment/ 目录下创建评估技能：

---
name: eval-sentiment
description: 评估情感分析任务的准确性
version: 1.0.0
---

# 情感分析评估技能

## 目的

自动测试智能体在情感分析任务中的表现，对比实际输出与期望标准。

## 使用方法

调用此技能时，智能体会：

1. 读取测试数据集
2. 对每个测试案例执行情感分析
3. 对比结果与期望输出
4. 生成评估报告

## 评估标准

每个测试案例检查：
- 情感分类准确性（正面/负面/中性）
- 关键实体识别完整性
- 是否避免越界行为（如给出投资建议）

## 输出格式

评估报告包含：
- 测试通过率
- 失败案例详情
- 改进建议

组织测试集

参考资料及素材/
└── evaluation/
    ├── test_cases/
    │   ├── sentiment_analysis.md    # 情感分析测试集
    │   ├── data_extraction.md       # 数据提取测试集
    │   └── report_generation.md     # 报告生成测试集
    └── evaluation_results/
        └── 2026-01-18_test_run.md   # 按日期记录测试结果

10.5.2 评估设计实践

评测数据分层实现

在 Claude Code 中批量测试时，可以使用以下工作流：

> 帮我评估情感分类模型在测试集上的表现

智能体步骤：
1. 读取测试集数据（CSV 格式）
2. 调用分类提示词生成预测结果
3. 计算 Precision、Recall、F1 等指标
4. 生成混淆矩阵可视化
5. 输出详细的分类报告
6. 分析错误案例，识别常见误分类模式

人工抽检实践

设计人工抽检时，按照优先级分层：

  1. 自动评分在边界值（2.8-3.2 分）的样本：100% 抽检
  2. 边缘样本和对抗样本：30% 抽检
  3. 正常样本：10% 抽检

10.5.3 优化迭代配置

lessons_learned.md 经验积累

在项目根目录创建经验积累文件，记录每次迭代发现。使用 10.3.1 节的标准化模板：

# 智能体优化经验总结

## 2026-01-18：情感分析准确率提升

| 要素 | 内容 |
|------|------|
| 问题 | 智能体在处理含有转折词的句子时，情感判断准确率只有 65% |
| 根因 | 原提示词过于简单，没有说明如何处理「虽然...但是」结构 |
| 方案 | 新提示词：分析文本情感，注意转折词后的内容往往是关键观点 |
| 效果 | 准确率从 65% 提升到 88% |
| 关联 | test_cases/sentiment_analysis.md 案例 #5-8 |

---

## 2026-01-15：避免幻觉输出

| 要素 | 内容 |
|------|------|
| 问题 | 智能体在数据不足时会编造数字 |
| 根因 | 提示词未明确数据不足时的处理方式 |
| 方案 | 在提示词中加入：如果数据不足，明确说明局限性，不要编造 |
| 效果 | 幻觉案例从 5/20 降低到 0/20 |
| 关联 | test_cases/hallucination_check.md |

Prompt/Skill 版本迭代

使用 Git 管理提示词版本：

git commit -m "feat(sentiment): 增加转折词处理逻辑"
git commit -m "fix(sentiment): 修正中性情感误判问题"
git commit -m "test(sentiment): 新增 5 个转折句测试案例"

在 Skill 文件中标注版本号：

---
name: sentiment-analyzer
version: 2.1.0
---

10.5.4 监控与回归实践

创建回归测试 Skill

---
name: eval-regression
description: 回归测试：确保修改不破坏现有功能
---

# 回归测试技能

## 目的

在修改提示词或 Skill 后，自动运行所有测试集，确保：
- 所有历史测试案例通过
- 性能指标未显著下降

## 触发时机

- 提交代码前
- 部署到生产前

## 测试流程

1. 读取 test_cases/ 下所有测试集
2. 依次执行
3. 生成通过/失败报告
4. 如有失败案例，提供详细对比

部署前检查清单

创建 deploy-checklist.md：

# 部署前质量检查

## 必须全部通过

- [ ] 回归测试通过率 ≥ 95%
- [ ] 无 P0 级 Bug
- [ ] 提示词已版本化并提交
- [ ] CLAUDE.md 更新到位
- [ ] 敏感信息扫描通过

## 执行方式

在 Claude Code 中运行：
> 执行部署前检查清单

智能体会：
1. 运行回归测试
2. 扫描代码中是否有硬编码的 API 密钥
3. 检查 CLAUDE.md 是否包含最新经验
4. 生成检查报告
提示教学提示

将回归测试集成到 Git 工作流中。在 .git/hooks/pre-commit 中添加脚本，在提交前自动运行测试。如果测试失败，阻止提交。这样可以确保每次提交都经过验证，避免引入回归问题。

配套案例

案例 10A：舆情分类评测集构建（智能体评估）

要素 说明
演示模式 智能体评估（Agent Evals）
案例简述 为舆情分类任务构建 50 条标注样例，定义评分 Rubric 与一致性规则，运行评估并发现误判集中类型。
经济学映射 市场信息质量评估——用可复验标准衡量信息质量
应用衔接 第 11 章金融舆情分析系统的质量控制流程复用此评估框架

案例背景

某证券公司需要开发一个智能体，自动分析财经新闻的情感倾向，辅助投资决策。智能体需要将新闻分类为积极、消极、中性三类，准确率要求达到 85% 以上。

第一阶段：初始评测集构建

数据来源选择：

  • 权威财经媒体（60%）：财联社快讯、新浪财经头条、东方财富网要闻
  • 上市公司公告（30%）：业绩预告、重大事项公告、股东增减持公告
  • 分析师报告（10%）：投资评级、目标价调整

标注规范：

  • 标注类别定义明确（积极：业绩增长超预期；消极：业绩下滑、监管处罚；中性：常规信息发布）
  • 3 名金融分析师独立标注，采用多数投票机制
  • 一致性要求：至少 2/3 标注者同意

第二阶段：迭代优化

基线测试（v1.0 提示词）结果：准确率 68%，中性类 F1 仅 0.52。

错误分析发现三类问题：

  1. 转折句误判（16 例）：公司营收虽增长 15%，但低于市场预期 → 被误判为积极
  2. 中性事件过度解读（12 例）：公司计划在下月发布新产品 → 被误判为积极
  3. 隐含风险识别不足（8 例）：公司董事长因个人原因辞职 → 被误判为中性

优化措施：

  • v2.0：在提示词中强调转折词处理、区分事实陈述和实际影响
  • v3.0：引入少样本示例（3 个典型案例）

最终结果：准确率从 68% 提升至 87%，通过质量门禁。

关键经验

  • 错误分析是优化的关键，比盲目调整提示词更有效
  • 测试集要覆盖边界情况，定期扩充
  • 少样本示例能显著提升复杂场景的理解

案例 10B：研报生成迭代优化（优化迭代）

要素 说明
演示模式 优化迭代（Learning & Adaptation）
案例简述 记录研报生成中的常见缺陷，写入 lessons_learned.md 并迭代提示模板，形成稳定输出风格。
经济学映射 动态学习——通过经验积累降低信息不对称
应用衔接 第 13 章研报生成的质量迭代采用相同闭环机制

案例背景

某资产管理公司需要智能体自动生成行业研究报告，覆盖基本面分析、市场情绪、风险提示和投资建议四个维度。

版本演进

v1.0（基线版） 问题：缺数据、结构乱、不专业。总分 2.7/10。

v2.0（模板版） 改进：引入结构化模板。问题：数据编造（50%）、行业差异化不足。总分 6.9/10。

v3.0（数据源版） 改进：集成真实数据源 + 行业模板 + 推理步骤。总分 8.6/10。

多维度评分矩阵

维度 权重 v1.0 v2.0 v3.0
基本面分析 30% 2.3 7.1 8.9
市场情绪分析 20% 2.8 6.5 8.3
风险识别 25% 3.1 7.8 8.7
投资建议 25% 2.5 6.2 8.5

从版本演进可以看出：v2.0 引入模板后各维度均有显著提升（+4 分左右），v3.0 集成真实数据源后进一步优化 1-2 分。总分从不及格（2.7）提升至优秀（8.6）。基本面分析提升最大（+6.6 分），说明数据来源是准确性的核心。

关键改进点

  1. 结构化模板是基础：强制要求必需章节，确保完整性
  2. 真实数据源不可替代：v3.0 强制使用真实输入，数据编造率从 50% 降至 0%
  3. 行业差异化体现专业性：周期性行业侧重供需周期，成长性行业侧重技术路线
  4. 推理步骤提升建议质量：投资建议评级分布从 80% 持有变为合理分布

用户反馈驱动持续改进

收集用户反馈后识别的高频问题：

  1. 风险提示过于笼统（18 次提及）→ 下一版本增加风险优先级排序
  2. 缺少可比公司分析（12 次提及）→ 增加竞品对比表格
  3. 投资建议缺少时间维度（10 次提及）→ 明确短/中/长期配置建议

经验教训

  • 数据驱动决策：所有优化都应基于真实数据和用户反馈
  • 小步迭代验证：不要试图一次性解决所有问题
  • 版本管理严格：对每次变更都要有明确记录和可回溯能力
  • 用户价值优先：技术指标的改进最终要转化为用户体验的提升

本章小结

本章介绍了智能体评估和优化迭代的完整框架，核心要点如下：

  1. 评估贯穿全流程：从原型到生产，持续评估驱动迭代。离线评估作为质量门禁，在线评估作为持续优化手段。

  2. 评测集构建三层结构：正常样本（60-70%）保证基准，边缘样本（20-30%）测试鲁棒性，对抗样本（5-10%）挖掘盲区。

  3. 评分标准设计原则：明确性（每个档位有清晰定义）、可操作性（评估者能独立完成评分）、层次性（3-5 档拉开区分度）。

  4. 优化迭代方法论：采用 PDCA 循环，小步快跑，每次只改一个变量。版本化管理提示词，记录经验教训。

  5. 监控与回归保障质量：建立多层次监控体系，设置质量门禁和分层告警，定期进行回归测试和漂移检测。

  6. 金融场景特殊考量：事实准确性优先，合规性一票否决，对延迟和成本敏感，需要可解释的推理过程。

智能体评估不是一次性工程，而是持续的质量保障过程。通过系统化的评估体系，可以有效提升金融 AI 系统的可靠性和实用性，为实际业务创造价值。