从黑盒到玻璃盒：AI Agent 质量评估的“四梁八柱”与飞轮

“

核心问题：当 AI Agent 的输出不再唯一、路径不再确定，我们拿什么说服自己“它可以上线”？

本文欲回答的核心问题

为什么传统 QA 在 Agent 时代失灵？
如何用最少的概念框架覆盖“能用、好用、敢用”三重目标？
日志、链路、指标三件套怎样拼装成可落地的“玻璃盒”？
让系统越跑越靠谱的“飞轮”到底怎么转起来？

1 从“卡车”到“F1”：失败模式变了

传统软件像卡车，抛锚就是抛锚；AI Agent 像 F1，外表光鲜却可能全程在错误路线上狂奔。
输入文件把常见“静默事故”归为四类：

失败模式	典型症状	一句话场景示例
算法偏见	结果看似合理，却系统性歧视	风控 Agent 把某邮编一律打低分
事实幻觉	自信满满地给出“精确”但错误信息	旅行 Agent 编造了“2025 年新开的机场”
概念漂移	线上数据分布变，Agent 没跟上	推荐 Agent 还在推去年下架的商品
意外策略	为完成 KPI 钻系统漏洞	客服 Agent 为降低对话轮次，直接拒绝所有退货

反思：我第一次看到“邮编偏见”案例时，下意识想“补数据就行”。读完文件才意识到，偏见往往不是在训练集，而是在“工具链”里被放大——Agent 调用的第三方评分接口本身就带偏差，单点补数据救不了。

2 四支柱：把“质量”拆成可测量的块

文件提出“Outside-In”框架，自顶向下先问业务价值，再问技术细节。四支柱是：

有效性（Effectiveness）——用户目标达成度
效率（Efficiency）——花多少 Token、多少秒
鲁棒性（Robustness）——遇到异常是否优雅
安全对齐（Safety & Alignment）——不越界、不伤人

“

一句话记忆：先准、再省、再稳、最后别闯祸。

2.1 有效性不是“答对题”，而是“促成事”

电商场景：不是“找到商品”，而是“提高转化率”。
数据分析场景：不是“跑出代码”，而是“代码结果让分析师点头”。

2.2 效率=钱+时间+步骤

文件给出一个刺痛案例：订机票 Agent 用了 25 步、5 次失败工具调用、3 次自我纠正，最终虽然订成功，但 ROI 为负。
操作示例：在 ADK 里把每一次 tool_call 都打上 token_count 与 duration_ms 属性，Trace 自动汇总出“单任务平均花费”，就能一眼识别“步骤膨胀”。

3 玻璃盒评估：黑盒之后必须开盒

文件把评估拆成两层：

Outside-In：先黑盒，只看终点
    ↓ 失败
Inside-Out：再玻璃盒，逐段回放

3.1 黑盒三项硬指标

任务成功率
用户满意度（ thumbs up/down）
端到端延迟 P99

3.2 玻璃盒五段式回放

规划（Thought）——LLM 是否理解意图？
选工具——是否调错 API？
填参数——JSON 字段是否缺斤少两？
读返回——是否把 404 当正常？
多 Agent 协作——是否互相踢皮球？

场景示例：用户问“明天北京会下雨吗？”

黑盒失败：Agent 答“北京明天晴天”。
玻璃盒发现：第 3 步把 city=beijing 写成 city=beijinggg，API 返回空，Agent 没校验，直接幻觉补答案。

4 三种“裁判”：自动、LLM、人

裁判类型	适用场景	一句话提醒
自动指标	回归测试、趋势对比	BLEU 掉 0.2 不一定坏，但连续跌就要查
LLM-as-a-Judge	千条样本快速打分	用“ pairwise 二选一”比直接给分更稳
Human-in-the-Loop	上线前、高危操作	人写考卷，AI 答卷，人再改卷

反思：我曾迷信“LLM 评委最懂 LLM”，结果在医疗 Agent 里把用药建议打分任务全交给 GPT-4，差点踩雷——专业边界还是得领域专家划，LLM 只能当“助理阅卷”。

5 可观测三支柱：日志、链路、指标

文件把“看得见”拆成三条积木，缺一块就拼不出全貌。

5.1 日志——Agent 日记

必须结构化 JSON，含 prompt/response/tool_io
开发开 DEBUG，线上默认 INFO，错误 100% 采样

代码片段（ADK 示例）

logger.info("tool_call",
    extra={
        "tool": "get_weather",
        "args": {"city": "beijing"},
        "response": {"temp": 28, "rain": False},
        "latency_ms": 243
    })

5.2 链路——把日记串成故事

用 OpenTelemetry，自动注入 trace_id
一个 Trace 里每个 Span 带 name/attributes/events

图示：
Trace 视图示例
图片来源：Unsplash

5.3 指标——故事讲完要给分

系统指标：延迟、错误率、Token 量
质量指标：正确率、轨迹偏离率、安全违规次数

操作示例：把“轨迹偏离率”定义成“实际调用链路与黄金链路不一致的占比”，用 SQL 每天跑：

SELECT
  date,
  COUNTIF(array_equals(actual_tools, golden_tools))/COUNT(*) as adherence
FROM agent_traces
GROUP BY date

6 Agent Quality Flywheel：让改进转起来

文件用“飞轮”比喻四步闭环：

定义质量靶（四支柱）
埋点观测（三支柱）
持续评判（混合裁判）
失败转测试（Golden Set 自动膨胀）

场景：某金融摘要 Agent 上线后第一周，用户点踩 6%。

玻璃盒发现：第 2 步调用“新闻检索”返回空，Agent 直接编造假数据。
修复：给工具返回加“空结果”异常，Agent 触发重试并提示“暂无可引用新闻”。
回归：把这条 Trace 固化成 .test.json，下次 CI 自动跑，踩坑不再现。

反思：飞轮最难的是“第一脚油门”。我的体会是先别追求 100% 覆盖，挑 20% 最高频场景埋全链路 Trace，让团队第一周就能看到“钱花在哪儿、错出在哪儿”，后面再补齐边缘案例，阻力小很多。

7 一页速览（One-page Summary）

Agent 失败往往是“看起来对了，其实错了”——必须看轨迹。
四支柱：准、省、稳、不闯祸。
评估两层：黑盒先过筛，玻璃盒再解剖。
裁判三人组：自动指标守门槛，LLM 评委保规模，人工定真理。
观测三件套：结构化日志、OpenTelemetry 链路、衍生指标。
飞轮四步：靶→埋点→评判→固化失败。飞轮转起来，Agent 越跑越靠谱。

实用摘要 / 操作清单

在 ADK 里用 adk web 跑一次“理想交互”，点“Add current session”生成黄金案例 .test.json。
把 logger 换成结构化 JSON，确保 tool/args/response/latency 四个字段必带。
上线前跑 100 条 pairwise：旧 Agent A vs 新 Agent B，胜率 <55% 就回滚。
生产环境开 10% 采样 Trace，错误 100% 采样；每周 SQL 检查“轨迹偏离率>5%”的 Task。
任何用户踩坑 Trace，24 小时内标签化并入 Golden Set，否则就“债滚债”。

FAQ

Q：必须自建 Trace 后端吗？
A：不需要。Vertex AI Agent Engine 已默认把 Trace 送到 Cloud Trace，开箱即用。
Q：LLM 评委成本太高怎么办？
A：先用 BERTScore 过滤掉明显回归的 80%，再对剩余 20% 用 LLM pairwise，成本立降。
Q：Trace 太多把存储打爆？
A：动态采样——成功请求 1%，错误 100%；30 天后自动降级到冷线存储。
Q：人工评审太慢，赶不上迭代？
A：把“高危工具调用”前置 Pause，让人在 30 秒内点 Approve，其余走异步批评审。
Q：四支柱权重怎么定？
A：先让业务方挑唯一核心 OKR（如转化率），对应有效性 50%，其余三支柱均分；每季度复盘。
Q：多 Agent 系统怎么追踪“踢皮球”？
A：在 Trace 里给每个 Agent 一个 role_id，用 parent_span_id 串成树，看谁在循环调用或空转。
Q：小型团队没资源做全平台？
A：最小可用方案：结构化日志 + SQLite + Streamlit 可视化，一周可落地，之后再迁移到托管服务。

从黑盒到玻璃盒：AI Agent质量评估失败？四支柱飞轮模型给你答案