如何评估和监控 AI Agent？为什么不能只看最终答案？

简化版

Agent 评估要结果和过程一起看：既看最终任务是否成功，也看工具选择、参数、状态变化、步骤效率、安全违规、成本、延迟。为什么不能只看最终答案——答案可能碰巧正确但过程危险（越权/走了不该走的动作），也可能回答一般却已正确完成外部操作。所以需要轨迹追踪（Trace）、分层指标、可重复测试环境、线上监控。

详细版

评估分四层：最终结果、单步工具调用、完整执行轨迹、系统运行指标。优先用确定性规则验证可计算结果（数据库状态、测试是否通过、引用是否存在），主观质量再用人工或模型评分并校准一致性。

测试集要覆盖正常任务、边界、工具故障、Prompt Injection、不可逆操作，且与单次模型调用/Workflow 基线比较。线上记录 Trace，监控成功率、循环率、重试率、人工接管率、token 与工具成本、高风险策略拦截。

完整版教学

一、为什么不能只看最终答案（两个反例）

反例1：最终答案文字正确，但过程中它【越权删除了一条记录】→ 答案对，过程危险
反例2：回答平平，但它已【正确提交了退款、更新了工单】→ 答案一般，任务其实成功
→ 只看最终文本，既抓不住安全问题，也判不出真实完成度

所以 Agent 评估必须过程 + 结果一起看，这是它区别于普通 QA 评估的根本。

二、四层评估指标

层	看什么
任务结果	可验证的成功状态（工单字段更新、代码过测试、事实可追溯）
工具调用	选择是否正确、参数是否合法、结果是否被正确使用、有无重复/无效调用
执行轨迹	依赖顺序、计划修订、终止原因、是否绕过审批
系统运行	成功率、循环率、重试率、人工接管率、token/工具成本、延迟

关键认知：高质量轨迹不是”步骤最多”，而是”以足够证据和较低成本安全完成目标”。

三、把”成功”定义成可验证状态

✗ 只用文本相似度判断"完成没" → 判不准
✓ 定义可验证的成功状态：
   工单的 status 字段=已解决？ 代码通过指定单元测试？ 报告中的事实可追溯到来源？
同时记录【部分完成】和【失败类型】，避免一个总分掩盖严重安全问题

四、评分器怎么选（安全门不能被平均分抵消）

能确定就用确定性评分器：代码/Schema/数据库查询/单元测试
开放式表达：带量规的人工评审 或 LLM-as-a-Judge（要人工样本校准）
  ⚠️ 防评分器看到会泄露答案或被注入的内容

记忆钩子：安全门槛不应被平均质量分抵消——一个平均分很高但有 1% 越权操作的 Agent，不能上线。安全和成本是独立的”门”，不是可以用质量分平均掉的。

五、离线测试集与线上可观测

离线测试集：来自真实任务分布，加入罕见高风险案例、工具超时、权限不足、过期记忆、冲突证据、间接注入。固定模型/Prompt/工具版本/随机配置，保存执行产物才能回归比较。涉及写操作用沙箱、模拟服务或可回滚测试账户。

线上 Trace：关联一次任务里的模型调用、工具调用、检索、审批、状态迁移，记录版本、耗时、token、错误码、费用。日志要访问控制和脱敏（不记明文密钥/不必要 PII）。告警关注：循环突增、工具拒绝率变化、成本异常、高风险动作激增。运行记录和步骤记录的表怎么设计，见「Agent 的 Run / Step 运行记录表怎么设计？」。

六、随机轨迹怎样做统计比较

同一个 Agent 即使输入相同，也可能因为采样、检索排序或工具状态走出不同轨迹。固定 Seed 只能帮助复现部分路径，不能代表线上分布；核心任务应重复运行，并按任务计算成功率、严重失败率和成本分布，而不是拿一次演示决定上线。

例如基线在 200 个任务上成功 164 个，成功率为 82%；候选版本成功 176 个，表面提升到 88%。但若候选出现 2 次未确认写操作，而发布门禁规定高危越权必须为 0，那么它仍不能发布；质量均值不能抵消安全失败。

baseline_success = 164 / 200 = 82%
candidate_success = 176 / 200 = 88%
candidate_critical_violation = 2 > 0  -> 阻止发布

对非确定性任务还应报告 Bootstrap 置信区间或多次运行分布，并保存成败轨迹做配对比较。若候选只在少数简单任务上节省成本，却让长任务的 P95 步数和循环率恶化，总体平均值同样会误导决策。

七、常见误区与追问

• 误区：Agent 评估看最终答案对错就够。 答案对可能过程越权，答案平可能已完成操作，必须过程+结果一起看。
• 误区：步骤越多、越”努力”的轨迹越好。 高质量轨迹是”足够证据+低成本+安全完成”，不是步骤最多。
• 误区：用文本相似度判断任务是否完成。 要定义可验证成功状态（DB 字段/测试通过/事实可追溯）。
• 误区：平均质量分高就能上线。 安全门是独立的，1% 越权也不能上，不被平均分抵消。
• 误区：直接用生产环境测写操作。 用沙箱/模拟服务/可回滚测试账户，别在真实系统上跑。
• 追问：为什么不能只看最终答案？ 答案正确可能过程危险（越权），答案一般可能已成功完成外部操作。
• 追问：Agent 评估分哪几层？ 任务结果、工具调用、执行轨迹、系统运行指标。
• 追问：离线测试集要覆盖什么？ 正常+边界+工具故障+权限不足+过期记忆+冲突证据+间接注入+不可逆操作。
• 追问：线上要监控哪些信号？ 成功率、循环率、重试率、人工接管率、token/工具成本、高风险拦截，告警关注循环突增/成本异常/高风险动作激增。

八、加强记忆

Agent 评估记「结果和过程一起看」：用确定性成功条件验证终点（DB 字段/测试通过/事实可追溯，别用文本相似度）、用 Trace 检查工具选择和状态迁移、用安全/成本/延迟指标约束整条执行链。核心认知钉死：不能只看最终答案（对≠过程安全、平≠没完成）、高质量轨迹是”足够证据+低成本+安全完成”不是步骤最多、安全门独立不被平均分抵消、写操作用沙箱测。四层指标（结果/工具/轨迹/系统），离线覆盖高风险和注入案例，线上 Trace 全链路 + 脱敏 + 异常告警。

项目实战落地

项目里怎么做的

《AI Agentic RAG高级企业知识库平台》的 Agentic 问答转几轮由模型决定，所以观测做成了「看形状 → 看每一步 → 看原始数据」三层：

• 三个数字看运行形状：运行列表把总步数、检索次数、改写次数并排放，扫一眼就能分出几类：5 步 / 检索 1 / 改写 0 是一次命中；11 步 / 检索 3 / 改写 2 是改写两轮才找到；10 步 / 检索 3 / 改写 3 是重试到上限、多半走了兜底；7 步 / 检索 1 / 改写 0 是生成后被判无支撑、重新生成过；
• 时间线看每一步：按步骤序号正序展示，时间戳位置放的是「第 N 步 · 节点名」而不是时间；节点按类别着色：检索绿色、相关性评分和幻觉校验橙色、兜底红色，其余蓝色；
• 判断类步骤两样都记：相关性评分和幻觉校验既记模型的原始回复，也记解析后的结论，解析出错时一眼能看出是解析的问题还是模型的问题；
• 步骤记摘要，工具日志记全文：检索这一步在步骤表里只记「返回 5 条」，完整的五段片段在工具调用日志里，步骤上留了工具编码，两边按运行 ID 能对上。

为什么这样取舍

• 用数字而不是逐条看答案：同一个知识库里大量出现「改写多轮」「重试到上限」这两类，说明检索策略需要调，这比逐条看答案质量高效得多。
• 时间戳不放时间：一次运行几秒钟就跑完，几个步骤的时间戳几乎一样，步骤序号和节点名才是排查要看的东西。
• 两张表分工：一次运行里怀疑检索有问题，先在时间线上定位是第几步判了不相关，再按运行 ID 去工具日志看三次检索各召回了什么，就能分清是检索的问题还是判断 Prompt 的问题。

面试官还会追问

• 幻觉校验节点的步骤入参为什么只记答案长度，不记答案全文？
• 一次运行跑完了但一次检索都没发生，系统会怎么处理这个答案？
• Agentic 模式为什么不做逐字流式输出？作为补偿，前端能看到什么？

学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。