Agent 能跑起来了，但"跑得好不好"没人说得清——这是很多 Agent 开发者的现状。8 月 18 日 Google AI 官方发布了一篇实操文章《设计 AI 评测：先求清晰，再谈可视化》，用 Inspect AI 等开源框架评测 agent 技能（skill），从评测矩阵、评分器设计到可视化分析完整跑了一遍。这篇把它的方法拆开讲，重点说清三个问题：评测矩阵怎么展开、评分怎么设计、先清晰后可视化是什么意思。

一、Agent 评测和模型评测差在哪

模型评测是"喂一个问题，对一对标准答案"，eval 通常只有模型 × 样本两个维度。Agent 评测要回答的是"给这个 agent 加一个技能后，任务完成得更好吗"，所以维度多了一倍：模型（solver）× 技能条件 × 样本 × 周期（epoch）。原文的做法是对同一组问题，分别测"有技能"和"没技能"两种条件，再对比 准确率、耗时、token 消耗 三个指标。

Google 的实测结果很直观：从 gemini-3.5-flash-lite 切到 gemini-3.6-flash，4 个评测任务里 3 个准确率最高提升 45%，但 gcloud 技能略有下降；而加技能在所有情况下都会增加耗时。也就是说，评测结论不一定是"加了技能就更好"——这正是需要评测的原因。

二、评测栈：Inspect AI、Harbor、Inspect Viz 各管什么

• Inspect AI：AISI（英国 AI 安全研究所）开源的评测编排框架，负责定义任务、跑 eval、记录日志，是本文主角。
• Harbor：另一个评估 agent 技能的开源框架，和 Inspect AI 二选一即可。
• Inspect SWE：跑在隔离 Docker 沙盒里，用来测"技能对回答同一问题的帮助程度"。
• Inspect Viz：把单条日志检查升级成聚合记分板的可视化工具（原文预告第二部分使用）。

三、评测矩阵怎么展开

原文的评测脚本优先考虑三个架构维度：外部配置（问题集、系统提示词放外部文件）、配额管理（solver 限速、grader 配额解耦）、多维评估（同一任务多指标）。跑起来后 Inspect AI 会生成 model × skill × sample × epoch 的评测矩阵，一条命令扫完所有组合。

四、评分怎么设计：multi_scorer 与 custom_reducer

这是全文最值得抄的部分。Agent 的答案是开放式的，不能简单判对错，Google 的做法分两步：

1. multi_scorer：把评分标准拆成一条条二元事实（Fact），用 model_graded_qa 让 grader 模型逐条判 C（正确）/ I（不正确），产出 0~1 分。
2. custom_reducer：把所有事实分数取算术平均，再套 mean² 曲线化。

曲线化的效果：原始 5/6 ≈ 0.8333，mean² 后变成 0.65——让"答对大部分但漏了关键点"的答案被明显拉低，最正确的答案才冒出来。

注意 grader 和被评模型是分开的：原文 grader 用 gemini-3.1-flash-lite，被评的 solver 是 3.5-flash-lite / 3.6-flash。让评分模型与被评模型分离，是避免"自己给自己打分"的基本功。

五、最小示例：一条命令跑起来

原文给出的评测命令（核心参数，入口命令即 inspect eval）：

inspect eval skills-eval.py \
  --model google/gemini-3.5-flash-lite,google/gemini-3.6-flash \
  --time-limit 300 \
  --epochs 2 \
  --max-tasks 4 \
  -T web_access=false

参数逐条说明：

• skills-eval.py：评测脚本，定义评测矩阵和评分器；
• –model：被评测的 solver 模型列表，逗号分隔，Inspect 会为每个模型各跑一遍矩阵；
• –time-limit 300：单个任务 300 秒超时，防止 agent 卡死拖垮整次评测；
• –epochs 2：每个样本跑 2 个周期，平滑随机性；
• –max-tasks 4：最多并行 4 个任务，控制 API 配额；
• -T web_access=false：把任务参数设为 false，测纯技能、不混入联网搜索，省 token。

跑完用 inspect view 在浏览器里打开日志：Transcript 标签页看系统提示词注入和技能是否真的被激活（防止"测了个寂寞"），Scoring 标签页看每条 Fact 的评分明细和 scored_samples 的分布。

六、先清晰、后可视化

原文标题就是方法论：先求清晰，再谈可视化。评测规模小的时候，inspect view 的单条日志深挖（微观）+ 按模型、技能条件分组对比（宏观）就够了；只有当模型数量、技能域多到"肉眼对比"不科学时，才上结构化矩阵概览和可视化工具（inspect viz、Google Sheets、Data Studio）做 cohort 分析、给决策者看。原文有一句话点破了顺序：

没有前期的清晰分析，可视化更像艺术而非科学。

七、可观测性的另一面：成本与用量

评测回答"好不好"，可观测性还要回答"贵不贵"。同一天（8 月 17 日）OpenRouter 上线 Activity 仪表盘和 beta Analytics API，可以按智能体、模型、请求维度看支出、token 量、缓存命中率，还能下钻到单条请求日志。给 Agent 应用做成本归因（哪个 agent 烧钱最多）会越来越刚需，建议和评测一起纳入 Agent 应用的观测体系。

结尾：评测是 Agent 迭代的度量衡

给 Agent 开发学习者的落地路径：先拿 Inspect AI 搭一个最小评测（一个任务、两个模型、两个周期），用 multi_scorer + custom_reducer 定好评分，再用 inspect view 逐条看失败样本；等评测规模大了再谈可视化。评测不是发布前的仪式，而是 Agent 迭代的度量衡——没有它，你永远不知道"加这个技能"到底有没有用。

来源说明：

• AI HOT《设计 AI 评测：先求清晰，再谈可视化》：https://aihot.virxact.com/items/cmsycmgww0rkrroz0nfma0z05 （原文：https://dev.to/googleai/designing-ai-evals-clarity-now-and-visualization-next-4eii ，Google AI · DEV 作者专属，2026-08-18）
• AI HOT《OpenRouter 推出 Activity 仪表盘与 Analytics API》：https://aihot.virxact.com/items/cmsx7ffrz049uromm6en3if02 （原文：https://openrouter.ai/blog/announcements/activity-dashboard ，OpenRouter Announcements，2026-08-17）
• 文中评测框架版本（inspect-ai v0.3.247、inspect-swe v0.2.66 等）取自原文，截至发文未验证最新版本，以官方文档为准（inspect.aisi.org.uk、github.com/harbor-framework/harbor）。