Agent技能评估，如果还停留在“看一次演示就当验证”，那你的系统离翻车只差一个边缘案例的距离。单次demo永远只展示最漂亮的路径，掩盖了失败分支、边界情况和随机性。真正靠谱的做法，是把评测拆成模型基线、技能条件与多维事实打分，让同一套脚本反复跑，让数字告诉你增量在哪里。开源评测框架Inspect AI和Harbor正是为此而生，配合Google Sheets和Data Studio，你能把评估结果变成团队所有人都看得懂的趋势图。
为什么你不能再用“感觉”评估Agent
单次演示的欺骗性
你见过哪个agent演示会挑自己失败的场景？没有。演示稿是精心排演的，模型参数可能调过、路径可能固化，甚至那一次成功只是运气。真正上线之后，用户的问题千奇百怪，一个不经意的措辞变化就能让agent跑到沟里。没有量化的评估，你根本不知道它有多脆弱。举个例子，一个能准确回答“今天天气”的agent，在“明天早上出门要不要带伞”面前可能直接哑火。你靠demo发现不了这种问题，因为demo不会问。产品经理拍着胸脯说“我看了演示，没问题”，可上线第一周就被用户投诉——这故事在每家做agent的公司都反复上演。
可复现的脚本和基线
要解决“感觉”问题，你得把评估变成代码。Inspect AI允许你设计可重复的评测任务：给定输入，调用你的agent，拿到输出，再用评分器打分。Harbor则负责把这些任务和结果管理起来，每次运行都留下记录。更关键的是，你需要一个基线——比如一个最简单的提示词模型——拿它当“对照组”。你的agent和基线跑同一套脚本，分数差就是它真实带来的增量。这才是评估的意义：不是看绝对分数，而是看相对提升。Inspect AI支持多种模型后端，你可以用同一个任务去测不同的模型，或者测你自己的微调版本，横向对比一目了然。
拆解评估框架：Inspect AI 与 Harbor 的分工
Inspect AI 解决“怎么测”
Inspect AI 是一个面向AI评估的开源框架，用Python编写测试逻辑。你可以定义任务（task）、求解器（solver）和评分器（scorer）。比如，让agent完成一次带工具调用的多步任务，然后检查它是否选择了正确的工具、参数是否完整、最终答案是否合理。评分器可以是简单的字符串匹配，也可以让另一个模型当裁判（LLM-as-judge），或者混合使用。这些评测脚本和代码一样，可以放进Git仓库，接受review，一次次迭代。它把“评估”从一个模糊的愿望变成了一堆可运行的测试。我见过最离谱的场景是，团队用十页文档描述评估标准，却没有一行实际代码。Inspect AI逼你把标准变成函数，这比任何文档都诚实。
Harbor 解决“测完怎么办”
Harbor 是另一个开源项目，它把评估数据和运行结果集中起来。你不需要在日志里翻找上一次运行了哪个版本，Harbor会记录每一次尝试的配置、数据集和分数。团队共享同一个Harbor实例，不同成员可以提交各自的评测结果，互相比较。这解决了一个真实痛点：每个人都在自己的脚本里跑评测，但没法汇总。Harbor让评估结果成为团队资产，而不是某个人的私货。它还能导出结果，方便你接入数据仓库或者BI工具，和现有的业务指标放在一起看。
别忘了技能条件
总分是最容易骗人的。一个agent可能在“指令遵循”上得了90分，却在“工具选择”上只有40分。如果你只看总分，会觉得它还不错；可一旦上线，工具选错就是灾难。所以，评估必须按技能维度拆分。Inspect AI可以针对不同条件分别编写评分器，Harbor则能展示每个维度的分数分布。这就是“多维事实打分”——不给你一个模糊的平均分，而是告诉你它在哪个能力上强、哪个能力上弱。你的决策应该基于这些事实，而不是一个漂亮的数字。举个实际场景：某agent在“多轮连贯性”上得分一直很高，但“工具参数抽取”经常出错。如果不拆开看，你根本不知道优化重点在哪；拆开之后，你可以立刻调取失败样本，发现是参数类型没有做校验。
从原始分数到可视化决策
一杯茶的时间上手 Google Sheets
评估结果通常输出为CSV文件，扔进Google Sheets就能实时协作。你可以用透视表快速计算不同技能维度的平均值，用条件格式把低于阈值的单元格标成红色。它不炫酷，但胜在零学习成本。团队里的非工程师也能看懂，也能参与讨论。这很重要——评估不是算法工程师一个人的事，产品经理和运营都应该有发言权。你可以建一张“技能健康度”看板，每天更新一次，哪个指标飘红，对应负责人就会主动去查。这种透明度是在用机制对抗“差不多就行”的浮躁。
Data Studio 把趋势画出来
Google Sheets适合“看今天”，Data Studio（现在叫Looker Studio）适合“看变化”。连接数据源后，拖拽就能生成折线图、柱状图、热力图。你可以把x轴设为运行次数，y轴设为工具调用准确率，观察它是否随代码改动而波动。还可以按agent版本、模型类型、数据源筛选，快速定位是哪个改动带来了性能回归。可视化让抽象的数字变成具体的形状——跌下去的曲线，一眼就懂。你还能把周度评测结果做成自动发送的报表，让每个人周五下午都收到一封邮件，附上最新趋势。这样，评估就不是“项目结束时的报告”，而是日常呼吸的节奏。
图表只是检索引擎
图表告诉你“发生了什么”，但不告诉你“为什么”。当准确率下跌，你必须回到具体案例里，去看agent输出的日志、工具调用的参数、评分器的打分依据。可视化最大的价值，是帮你更快地找到值得深挖的样本。如果只是做一张好看的仪表盘，没有人跟进问题，那它不过是又一处自我安慰。我见过太多团队，Dashboard做得很漂亮，但里面每一个指标都无人认领。记住：图是起点，不是终点。真正的功夫在于顺着图表往下钻，直到你看见那个让模型犯错的句子。
落地实操：一套可复用的评估工作流
先写下你的agent应该会什么
别急着写测试用例，先想清楚你的agent的核心技能清单。比如“能够从网页中提取订单号”“能够在信息不足时主动追问”“能够在多轮对话后保持上下文一致”。每一项都要具体、可观测。不要写“理解用户意图”这种无法验证的话。每一条技能，都要能转化为至少一个评测指标。这个清单不仅是你写测试的输入，也是团队对齐预期的工具。如果你们对“会什么”都争论不休，那评估标准就更不可能达成一致。可以先花一个下午，让工程师和产品经理坐下来，把技能清单写下来，再逐个定义“通过”意味着什么。
写用例，别怕麻烦
用Inspect AI定义任务时，从一小批用例开始，逐步扩充。每个用例包含输入、预期行为、评分方法。对于需要多步推理的场景，可以写一个“轨迹检查器”，验证中间步骤是否合理。评分器要兼顾多个维度：结果正确性、过程规范性、效率、资源消耗等。你不需要一次性做到完美，但至少要覆盖happy path和几个典型失败路径。Harbor可以帮你组织这些用例，按技能和难度打标签，方便后续筛选。请记住，测试用例不是一次性资产，它们会随你的产品一起成长。每周都应该从线上日志里挑几个新的失败案例，变成测试集里的新成员。
把评估塞进CI
没有自动化的评估，迟早会被遗忘。把评测脚本挂到CI流水线上，每次push都自动运行。如果分数低于阈值，构建就失败。这样，任何改动都必须通过评估才能合并。Harbor可以自动记录每次CI运行的结果，并生成对比报告。你会在小问题变成大麻烦之前拦住它。这就像给代码库装了一个健康监控器，每次心跳都测量一次。对于小团队，可以用GitHub Actions或GitLab CI跑一个轻量级的定时任务；如果你的评估集很大，那就跑在独立的算力池里。关键是，评估必须成为开发流程的一部分，而不是事后补的工作。
别让评估成为下一个形式主义
测试集也会过时
评估系统运行几个月后，你会遇到新的问题：评测用例开始老化。agent可能已经“背”下了测试答案，不能反映真实能力；或者产品需求变了，旧用例不再代表用户场景。所以，定期从真实用户日志中抽取失败案例，补充进评测集。让测试集和你一起进化。不要为了保持分数好看而拒绝添加新用例——那不是评估，那是粉饰。你还可以用版本号来管理评测集，就像管理代码库一样，每一次变更都留痕。当召回率下降时，你能回溯到底是哪个新用例导致的，而不是对着一个黑盒发愁。
让评估成为团队语言
最后，我想说的是：Inspect AI和Harbor本身只是工具，真正有价值的是它们所推动的思维转变。当团队开始说“工具选择准确率下降了8个点”“长上下文理解相比基线提升了12%”而不是“我感觉它变聪明了”，你们就通向了更可信的决策。开源框架让这种语言有了共同的语法，而Google Sheets和Data Studio让这种语言有了可视化表达。别让评估变成又一层繁琐的流程——把它变成你理解和改进agent的方式。一旦你习惯了用数字说话，你会在所有技术讨论里都不自觉地追问：“你的证据呢？”这才是这套方法论送给你最珍贵的礼物。
