Eval驱动开发：如何科学测试你的AI技能与Agent

为什么AI工具需要"评估"（Evals）

在Firebase After Hours第27期节目中，Google资深工程师JF（拥有13年Google从业经历，其中近年专注于Evals与AI方向）分享了一个核心观点：如果你正在开发AI工具、编写Agent技能（Skill）或搭建MCP服务器，请务必认真测试它——而不是在终端跑五次然后说"看起来还行"。

这里的测试，指的是像传统软件工程那样引入严谨方法：单元测试、端到端集成测试的思路同样适用于AI集成。区别在于，大语言模型（LLM）本质上是非确定性的。传统软件里，输入2+2永远等于4，测试结果可复现；而问LLM"天空为什么是蓝色"，可能有14种不同表述的答案都是对的。如何为这种"不确定"的输出打分，正是Eval要解决的核心问题。

评估结果的合理范围

从字符串匹配到"LLM当裁判"

JF把测试方法分成了几个层次。

优先用确定性测试

如果任务本身可以确定性验证——比如让Agent生成代码——那就用传统方法：能不能编译？能不能通过linter？能不能跑通预先写好的单元测试？这是"黄金标准"，快速且可靠。对于iOS开发这类场景，甚至可以直接用grep检查关键字符串，比如检查代码用的是新的@Observable还是已废弃的@Published，既便宜又快，还完全确定。

开放式问题：让LLM来当裁判

当问题变得开放（生成一段文本、回答某个问题），事情就复杂了。一个直接的思路是字符串相似度匹配，设定阈值判断是否"够接近"。但更进一步的做法是LLM as a judge——用另一个模型来评判第一个模型的输出。

JF强调，直接让裁判LLM做"这个回答好不好"这种主观判断是不靠谱的。真正有效的技巧是约束问题：把评判拆解成一组明确的是非题（true/false）。比如把"这是个好回答吗"改写成一份rubric（评分标准）：我期待的答案包含这5个要点，逐一问是否为真。这样不仅答案清晰，还能算出量化指标——比如"5个要点命中3个，正确率60%"。

实操上，这些事实（facts）以JSON数组的形式一次性发给裁判模型，让它对每个返回布尔值，既省token又可靠。JF提到一个关键细节：这些facts绝不能提供给被测Agent本身，否则就等于把"标准答案"直接给了它，Agent会走捷径"作弊"。

好的技能应提供真正的增值

LLM as a Judge 是近年AI评估领域的主流范式之一，由斯坦福等机构的研究推动普及。其核心思想是：既然人类语言的质量判断本身就依赖语言理解能力，那么用一个足够强的语言模型来充当"评审员"，理论上比硬编码规则更灵活。但这个方法有一个经典陷阱——位置偏见（position bias）：裁判模型往往倾向于给对话中排在前面或较长的答案打高分，与内容质量无关。因此业界发展出了"对换顺序后取平均"、"多裁判投票"等缓解手段。JF提出的"拆成是非题"本质上是从源头规避主观性偏差：把模糊的"好不好"转化为可验证的客观事实列表，让裁判模型只需做事实核查而非价值判断，大幅降低了偏见介入的空间。

编写可靠Eval的实战技巧

JF结合团队开发Google Agent Skills的经验，总结了几条被验证有效的原则：

遵循RFC语言规范：在评判提示中使用must/must not/should等明确措辞，尽量消除歧义，让任何判断都不留解释空间。
问题保持原子化：不要在一个问题里塞两件事。"它是JSON吗，且包含metadata字段吗"应该拆成两个独立的是非题，各自都能轻松验证。
多次运行取统计值：因为非确定性的存在，同一个Eval应该跑6到10次，观察正确率的分布区间（如50%、60%、60%、50%），从而得出更可信的准确度数字，还能计算标准差与误差。
区分"初始提示"与"评判提示"的详略：初始提示应贴近真实用户会怎么问，不必过度规定（有时"Agent会不会主动选用这个技能"本身就是评估目标）；而评判提示则要尽可能详尽、去歧义。

JF还透露了一个反直觉的发现：在95%甚至更高的情况下，Flash或Flash-Lite这类较小模型作为裁判给出的评分是一致的。也就是说，评判环节往往不需要昂贵的Pro大模型，前提是你把评分rubric打磨扎实，并用人工去校验裁判（人工先标注期望的true/false序列，再看模型是否给出相同结果）。

评判环节的可靠性

谁需要Evals：不只是模型厂商

很多人以为Eval只属于做模型和做Agent技能的厂商，但JF指出它对普通开发者同样有价值。

一个典型场景是衡量技能是否值得占用上下文窗口。如今开发环境里可能装了大量Skill和MCP服务器，它们即便闲置也在消耗token。跑一组快速Eval——开启技能 vs 关闭技能的对比测试——就能知道：前沿模型是不是已经自己会了？如果基线（baseline）准确率已超过90%，再叠加技能可能收益甚微，甚至可能误导模型。

节目中的现场演示恰好印证了这点：由于测试环境没装gcloud，带技能的版本因为技能指引它反复尝试运行命令，反而消耗了远超基线的token；而基线模型"知道自己没这个工具"，直接改用其他资源作答。这就为如何优化技能设计提供了直接反馈。

另一个反直觉的发现是：网络搜索有时比本地技能更优。因为Eval测试的是"用户目标/journey"而非"技能本身"，Agent可能觉得web search更省事就绕过了你的技能。这时你得到的反馈是：也许该调整技能的名称、描述或内容，好让Agent真正愿意调用它。团队甚至把"技能是否被实际使用"作为一项独立指标来追踪——方法是查看Agent的trajectory（执行轨迹日志），看它是否激活并读取了技能文件。

上下文窗口（Context Window） 是指大语言模型在单次推理中能处理的最大文本长度，通常以token数量衡量（1个英文单词约等于1-2个token，1个汉字约等于1-2个token）。每次调用模型时，塞入上下文的所有内容——系统提示、工具描述、对话历史——都会被计费并消耗推理时间。MCP服务器或Agent技能的描述文本，即便从未被实际调用，只要被加载进上下文就会持续"占座"。当开发环境集成了几十个工具时，这种隐性成本会快速累积，也可能因为"噪音"过多干扰模型的工具选择判断。这正是JF强调用Eval来量化"技能是否真正带来增益"而非凭感觉取舍的现实动机。

工具选型与维护成本的现实考量

关于测试框架（harness），JF推荐了几个选择：他本人常用Inspect AI，此外LangChain、Harbor都支持，而使用Genkit或ADK（Agent Development Kit）的开发者，框架内已内置Eval功能。这些harness负责处理沙箱隔离（可用Podman、Kubernetes扩展）、多provider API接入等复杂工作，剥开外壳后本质都是：跑Agent→给提示→拿回答→评估回答。他建议多试几个，选一个"对味"的。

如何判断新旧模型的界限

节目也坦诚讨论了两个现实难题。一是组合爆炸：模型×任务×Agent的排列组合会迅速失控，因此必须聚焦——想升级模型就只比新旧两个模型，想换提示就固定其他变量。二是维护成本：模型在快速进化（节目当天Gemini 3.8 Flash刚发布，3.7 Flash才发布几周），今天的"新模型"很快会变成"旧模型"，Eval的prompt和facts需要持续更新。JF的建议是盯住趋势，一旦发现准确率普遍走高，就应该把测试做得更难，才能持续获得有用信号。

对于个人开发者，JF也给出了平衡建议：投入产出要看你打算测哪些Agent和模型、你的用户是谁。如果只是自用，把手工写的技能丢进不同Agent里跑一遍、观察各家推理差异，本身就是件很有意思的事，而harness让这种"跨Agent探索"变得轻松许多。

Inspect AI 是由英国AI安全研究所（UK AI Safety Institute）开源的LLM评估框架，设计目标是让研究人员和开发者能够系统性地测试模型在各类任务上的表现，包括安全性、事实准确性和指令遵循能力。它提供了任务（Task）与求解器（Solver）的抽象层，支持将评估流水线模块化组装，并内置多种评分器（Scorer）。Genkit 是Google推出的面向JavaScript/TypeScript开发者的AI应用开发框架，内置了流程追踪和Eval集成；ADK（Agent Development Kit） 则是Google面向Python生态的Agent构建工具包，同样将Eval视为一等公民内置其中。相比于自行搭建测试脚本，这些框架的核心价值在于处理了Provider切换、并发运行、结果聚合等繁琐工程细节。

结语：让每一个token都算数

JF最后的呼吁很直接：动手写Evals，别再靠在终端里瞎跑来测试。 用严谨的方法去测试你构建的AI工具和Agent，遵循业界沉淀下来的最佳实践——简单事实、原子化问题、客观无判断、只评估你要求的东西、校准可信的裁判——让你花掉的每一个token都产出真正有用的信号。这正是Eval驱动开发（Eval-Driven Development）的意义所在。