Agent 评测与调试：评估与改进

传统的机器学习评测（如 ImageNet 准确率、GLUE 基准分数）之所以有效，是因为每个输入都有明确的标签，每个输出的好坏可以用一个数字衡量。但Agent 评测面临三个根本性挑战，使其远比单一模型评测复杂。第一个挑战：输出是多步行为序列，而非单一答案。 一个 Agent 可能在 35 小时内执行了 200+ 步操作——查询数据库、调用 API、生成报告、与用户交互——你无法用"准确率"这样的单一指标来衡量。即使最终任务完成，中间步骤的质量、效率和安全性同样重要。第二个挑战：环境状态会变化。 与静态测试集不同，Agent 操作的外部环境（数据库、API、文件系统）会随着时间变化。同样的 Agent 在上午和下午的同一测试中可能产生不同的结果，因为数据库内容变了、API 接口更新了、网络延迟不同。这要求评测方法具备可重复性和环境隔离能力。
第三个挑战：评测本身需要智能判断。 判断一个 Agent 是否"正确地"完成了复杂任务，往往需要另一个智能系统来评估——这就是所谓的"用 Agent 评测 Agent"的递归问题。评估者本身的质量和偏差会直接影响评测结果的可信度。

理解这三个挑战，是设计有效评测体系的前提。如果跳过对评测难度的认识，直接套用传统 ML 的指标，得到的结论可能比没有结论更危险。

Agent 评测需要覆盖五个相互关联但独立的维度。每个维度回答一个不同的问题，组合起来才能形成对 Agent 能力的完整画像。维度一：任务完成度（Task Completion）。 回答"Agent 是否达到了预期目标？"这是最直观的维度，但需要进一步拆解——完成度可以是二元的（完成/未完成），也可以是渐进的（0% 到 100% 完成）。对于复杂任务，建议采用部分完成评分法：定义任务的里程碑节点，每完成一个节点获得相应比例的分数。维度二：效率（Efficiency）。 回答"Agent 用了多少资源来完成任务？"资源包括 Token 消耗、API 调用次数、执行时间、内存占用等。效率维度往往被忽视，但在生产环境中，效率直接决定了经济可行性。一个能完成任务但消耗 10 倍资源的 Agent，在生产中不可持续。维度三：可靠性（Reliability）。 回答"Agent 在不同条件下表现有多稳定？"可靠性评测需要设计边界条件测试——异常输入、网络延迟、API 超时、并发请求等。可靠性是 Agent 从演示环境走向生产环境的关键门槛。维度四：安全性（Safety）。 回答"Agent 的行为是否在安全边界内？"安全性评测包括：是否执行了未授权操作、是否泄露了敏感信息、是否在被提示注入攻击时保持了行为一致性。安全性是所有维度的底线——即使其他维度满分，安全性不合格也是零分。
维度五：可解释性（Explainability）。 回答"你能理解 Agent 为什么做出某个决策吗？"可解释性不仅关乎调试效率，更关乎合规性和用户信任。一个完全黑盒的 Agent 在医疗、金融等高风险领域无法通过合规审查。

这五个维度不是并列关系，而是 有层次约束的：安全性是硬约束（必须达标），可靠性是准入门槛（必须及格），任务完成度是核心价值（越高越好），效率和可解释性是优化目标（在达标基础上不断提升）。

评测数据集的质量直接决定了评测结果的可信度。一个糟糕的数据集会产生误导性的分数，让你以为 Agent 表现优秀，实际上它只在特定测试集上过拟合。

数据集设计的核心原则是代表性和多样性。 代表性意味着数据分布应该反映 Agent 在实际生产环境中将遇到的真实情况——如果你的 Agent 主要用于处理用户查询，那么测试数据中 80% 应该是自然语言查询，而非结构化数据操作。多样性意味着数据应覆盖各种边界情况和极端场景，而非仅仅"常规路径"。数据集构建的最佳实践是分层采样法。 首先定义 Agent 的所有功能类别，然后在每个类别中采样一定比例的数据，确保每个类别都有足够的测试覆盖。分层比例应与预期使用频率一致——高频功能应有更多测试用例，低频但高风险的功能也不能被忽略。数据泄露是评测领域的头号杀手。 一旦 Agent 在训练或微调阶段接触过测试数据，评测结果就完全失去意义。防止数据泄露的措施包括：测试集完全独立于训练集、使用第三方基准（如 AgentBench、WebArena）、定期更换测试数据。数据标注质量同样关键。 对于需要人工评估的测试用例（如判断 Agent 回复是否"有帮助"），标注者之间的一致性系数（Kappa 系数）应至少达到 0.7，否则标注本身就不可靠。

人工评测虽然准确但成本高昂，无法应对 Agent 的迭代速度。自动化评测框架的目标是在保证质量的前提下，将评测周期从数天缩短到数分钟。
自动化评测的核心架构包含三个层次： 执行层、评估层和分析层。执行层负责运行 Agent 并收集输出——包括每一步的工具调用、中间状态、最终结果。评估层将 Agent 的实际输出与预期结果对比，计算各维度分数。分析层汇总多轮评测数据，生成趋势报告和异常告警。评估层是实现自动化的难点。 对于有明确预期输出的测试用例（如"查询数据库返回 3 条记录"），可以使用精确匹配或模糊匹配算法。对于开放性问题（如"分析这份报告"），需要借助LLM-as-a-Judge模式——用另一个 LLM 作为评估者，但这种方法本身存在评估者偏差的问题。降低 LLM-as-a-Judge 偏差的最佳实践是使用多评估者投票机制。 用 3-5 个不同的 LLM 对同一输出进行评估，取多数意见。评估者之间的分歧本身就提供了有价值的信息——如果某些输出在不同 LLM 之间评估结果不一致，说明该输出处于"灰色地带"，需要人工审查。自动化评测的另一个关键能力是回归检测。 每次 Agent 代码变更后，自动运行完整的评测集，检测是否有任何指标退化。退化阈值通常设置为历史平均值的 -5%，超过此阈值的变更应阻止部署。

当评测发现 Agent 表现不佳时，需要系统化的调试方法来定位和修复问题。Agent 调试不同于传统软件调试，因为错误的来源可能是模型、提示、工具、环境或它们的组合。
第一步：执行轨迹分析。 Agent 的每一步操作都应该被记录——包括输入、输出、工具调用、错误信息。通过分析执行轨迹，可以确定问题发生在哪个阶段。如果 Agent 在第一步就理解错了任务，那是提示工程问题；如果理解正确但工具调用参数错误，那是工具定义问题；如果工具返回正确但 Agent 解释错误，那是模型推理问题。第二步：隔离变量。 当问题定位到某个阶段后，需要逐一隔离变量来确认根因。如果怀疑是提示问题，保持工具和环境不变，只修改提示词再测试；如果怀疑是工具问题，保持提示和模型不变，替换工具的实现再测试。隔离变量的关键是每次只改变一个因素。
第三步：最小复现。 找到根因后，构造最小复现用例——用最少的输入数据、最简的工具配置、最直接的触发路径来复现问题。最小复现是修复问题的前提，也是防止回归的关键。第四步：渐进式修复与验证。 修复后不要立即部署到生产环境，而是在评测集中回归测试，确认没有引入新的退化。然后在小流量环境中验证，最后才全量部署。

评测结果需要以直观的方式呈现给开发者和决策者。仪表盘设计的核心原则是"一眼看清状态，三秒定位问题"。
Agent 评测仪表盘应该包含三个视图层： 概览层、详情层和趋势层。概览层展示当前 Agent 的总体评分和各维度分数，用红/黄/绿三色标识状态。详情层展示每个测试用例的具体结果，支持按类别、难度、状态过滤。趋势层展示指标随时间的变化，帮助识别退化趋势。关键指标的选择应该与业务目标对齐。 如果 Agent 用于客服场景，关键指标应该包括首次解决率、用户满意度、平均处理时间；如果用于代码生成，关键指标应该包括代码通过率、代码质量评分、生成时间。告警阈值的设计需要平衡敏感性和准确性。 阈值太敏感会产生大量误报，导致"告警疲劳"；阈值太宽松会漏掉真正的问题。建议采用动态阈值——基于历史数据的均值和标准差自动调整，而非固定数值。仪表盘的可操作性比美观更重要。 每个指标旁边都应该有"下一步"建议——如果任务完成度下降，建议查看哪些测试用例失败了；如果效率下降，建议检查哪个工具调用消耗了最多资源。不可操作的指标是装饰性的噪音。

评测本身不是目的，持续改进才是。一个完整的 Agent 改进流程应该形成闭环：评测发现问题 → 调试定位根因 → 修复问题 → 验证修复效果 → 部署到生产 → 生产数据反馈给评测集。改进流程的第一步是优先级排序。 不是所有发现的问题都需要立即修复——有些问题影响范围小、发生频率低，可以延后处理。建议使用风险矩阵法：以影响程度为横轴、发生频率为纵轴，将问题分为四个优先级区域。高影响高频率的问题必须立即修复（P0），高影响低频率的问题应该尽快修复（P1），低影响高频率的问题可以在下个迭代修复（P2），低影响低频率的问题可以暂缓（P3）。改进流程的第二步是修复验证。 每个修复都应该通过三个层次的验证：单元测试验证（修复是否生效）、回归测试验证（是否引入新的退化）、集成测试验证（在完整工作流中是否正常）。改进流程的第三步是知识库积累。 每个被修复的问题都应该记录到团队的"Agent 问题知识库"中，包括问题描述、根因分析、修复方案、预防措施。这个知识库的价值会随着时间增长——新成员可以通过查询历史问题快速上手，老成员可以避免重复踩坑。改进流程的最终目标是建立"自愈"能力。 当 Agent 在生产环境中遇到已知问题时，应该能自动触发修复逻辑或降级策略。例如，如果某个 API 经常超时，Agent 应该自动切换到备用 API 或启用缓存。这要求评测体系不仅发现问题，还要为问题预定义修复方案。

即使离线评测全绿，Agent 上线后仍然可能出现问题。生产环境的 Agent 监控是在线评估的核心，它弥补了离线评测的盲区。
生产监控与离线评测的根本区别在于数据来源。 离线评测使用预定义的测试集，生产监控使用真实用户交互数据。真实数据的特点是不可预知——用户可能以任何方式使用 Agent，提出评测集中从未出现过的问题，以评测集中未覆盖的顺序执行操作。生产监控的三个核心组件： 实时指标采集（Token 消耗、响应时间、错误率）、异常检测（行为模式偏离、安全约束触发）和反馈循环（用户评分、人工审核标注）。异常检测的关键是建立 Agent 行为的"正常基线"。 通过收集足够多的正常交互数据，可以学习到 Agent 的典型行为模式——平均调用多少工具、典型响应时间分布、常见的错误类型。当新交互偏离基线超过阈值时触发告警。反馈循环是将生产经验转化为评测资产的桥梁。 用户反馈（"这个回答没有帮助"）应该自动加入测试集，人工审核标注的问题应该自动更新评测权重。这样，评测体系会随着 Agent 的使用越来越精准。Agent 的灰度发布策略与监控紧密相关。 新版本的 Agent 应该先在小流量（如 1%）下运行，通过生产监控验证关键指标无退化后，才逐步扩大流量。灰度期间的监控数据是决定是否可以全量部署的关键依据。