Agent 迭代如何避免按下葫芦浮起瓢：一套可量化的智能体评测工程实践

当智能助手开始承担查询资源配置、估算扩容成本、排查访问故障这类真实任务时，一个工程难题随之浮现：为了让 Agent 更好用，团队会不断修改提示词、技能、命令行工具和底层执行框架，而这些模块环环相扣，改一处往往牵动全局——今天修好了 A 场景，明天可能就破坏了原本正常的 B 场景。如果上线前只靠人工随意测几句，或只看回答是否通顺，既难以判断改动是否产生副作用，也难以在出问题时定位卡在哪一步。本文拆解一套让改进有迹可循的评测工程实践。

多维评测：任务、行为与安全的全覆盖

评测体系的设计起点，是看清一句简单提问背后同时考验着什么。以云盘扩容询价为例，Agent 需先调用只读工具查清现有容量、类型和计费方式，再核对扩容上限规则，并调用询价接口计算差价；遇到用户未提供云盘 ID 时要主动追问，工具查不到数据时不能编造价格，涉及修改配置的操作需先识别风险并请用户确认，删除资源、越权访问这类高危请求则直接拒绝。因此评测集既关注用户通常如何提问，也关注底层会调用哪些技能和工具，还专门放入故意不提供资源 ID、模拟工具报错、要求越权删除资源等边界难题。

LLM 与 Code 双评估器分工协作

当评测同时考察任务完成、数据真实与操作安全时，只看回答是否通顺远远不够——Agent 可能回答流畅，却忽略已知参数、不查询真实配置，表面不错实则未完成任务。为此评测采用双评估器结合：LLM 评估器围绕任务理解、事实依据、任务完成度、能力边界与操作安全、表达清晰度五个维度评估语义与过程质量；Code 评估器通过代码与正则规则直接检查空回答、运行报错、工具调用约束等可程序化验证的行为。同时定期用人工标注样本校对打分结果，持续提升自动评估与业务判断的一致性。

离线回归：让每次改动有据可查

从多年的产业实践经验来看，评测工程能否落地，关键在于把实验流程工程化、把运行轨迹资产化。团队将代码、提示词、技能和工具打包为待测版本，评测工作台负责版本与基线管理、实验分片调度、红线判定与版本对比；云端隔离沙箱并发运行完整的 Agent 流程，让它实际走完理解问题、选择技能、调用工具、生成回答的全过程；日志与观测平台负责调用链分析、LLM 多维打分及线上会话质量分析。任务自动保留评测集快照、评估器版本和评分配置，使结果可追溯；沙箱运行与评估打分相互独立，调整评分规则时可直接基于已保存结果重评，无需重跑。安全红线与核心完成度实行一票否决制。以一轮包含 124 道用例的回归实验为例，综合得分由 88.7 提升至 95.1，任务完成度由 55.4 提升至 92.2，改动效果一目了然。

从一次失分到通用修复的问题闭环

评测报告的价值在于把分数差异转化为研发改进。在扩容询价题的旧版本中，Agent 忽略已有的云盘 ID，未主动调用工具查询配置，而是把问题抛回用户，该题被判未通过、任务完成度 0 分。通过单题评分详情与 Trace 调用链归因，团队定位到问题源于 Skill 拆解指引缺失，随即在对应 Skill 中补齐调用链路要求。修复后重新回归，新版 Agent 依次完成边界判断、执行计划、读取扩容规则、实查云盘现有配置、调用询价接口估算费用差额，在不触发任何写操作的前提下给出完整结论，该题任务完成度提升至 100 分。更重要的是修复纪律：必须修改通用的 Skill 逻辑、工具接口或补充知识库，不能针对某道题写死提示词，并用不同问法的变体题和线上真实对话交叉验证，避免背题应试。同时，经确认的线上异常会话与典型工单，经筛选、去重、隐私脱敏和业务复核后回流至评测集，进入下一轮回归实验，形成持续进化的质量闭环。

衡量一个智能体的质量，关键看它能否基于真实状态做出判断、选对工具与执行路径，并严格遵守权限与安全边界。把业务要求沉淀为可重复执行的评测用例、可回溯的运行轨迹和可对比的版本实验，Agent 的每一次改进才能真正有迹可循。