谷歌演示Agents CLI评估循环：四条用例的示范揭示汇总分数的盲区

谷歌开发者博客于 2026 年 10 月 28 日发布了一篇 Agents CLI 评估命令的演示文章。Agents CLI 是用于构建 AI 智能体的工具。文章用一个小型示例智能体，演示运行测试用例、给结果打分、比较不同运行、再根据差异采取行动的循环。核心提醒是：汇总分数可能误导，团队应查看逐条用例的结果。文中的评分比较来自四条用例的示范，不是真实产品的基准测试；另有谷歌自述的独立研究数据。

eval 命名空间有五个命令，各负其责。eval generate 让智能体跑一组用例；eval grade 给生成的轨迹打分；eval compare 把两次结果并排比较；eval analyze 把失败归类成主题；eval optimize 自动改进智能体的提示词。作者把整个做法叫作“爬山”：修改智能体，重跑用例，分数升了就保留，降了就回退。

演示使用 Agents CLI v1.8.0 自带的 LangChain 模板。一个自定义的评审指标由 gemini-3.8-flash 驱动，按准确性、相关性和清晰度给每个回答打 1 到 5 分。作者把默认只有一条的数据集扩成四条：一句问候、两个天气问题和一个离题问题。基线平均分为 4.0（满分 5），标准差 1.41。作者认为这种差异是健康的，因为一路 5.0 要么说明智能体完美，要么说明数据集太简单、看不出差别。

接着他们植入一个现实中的错误：开发者把厨师人设误贴进天气智能体的系统提示词。代码检查、单元测试和类型检查都通过，智能体也能运行。平均分降到 2.75。逐条比较显示损失落在哪里：问候在语气上丢了 1 分，离题问题因超出范围丢了 2 分，sf_weather 这一条丢了 2 分，因为智能体不再调用天气工具，而是编造数值。作者的观点是，只有在上下文中给行为打分的端到端评估，才能发现这类故障。

第二个实验把智能体的模型从 gemini-3.8-flash 换成 gemini-2.5-flash。按文中所印，平均分同样从 4.00 降到 2.75，但逐条情况不同：较便宜的模型在问候和一个天气问题上与原来相同，另一个天气问题丢了 1 分，明显的下降来自离题问题，它以“事件尚未发生”之类的含糊说法拒绝回答。作者提醒，为一个模型调好的提示词换到另一个模型上可能损失能力，评审模型也必须保持不变，比较才公平。

文章还谈到调度和局限。Agents CLI 不带调度器，团队可以用 cron 或 Cloud Scheduler 每晚运行 generate 和 grade，再加一个脚本，在平均分下降超过阈值时以非零状态退出。eval optimize 通过 GEPA 框架用于 ADK 项目，不支持 LangChain 扩展。它只改提示词，并且可能因迎合指标措辞而过拟合地抬高分数，所以要由人审查候选方案。谷歌还报告了自己的一项对照研究：使用该工具的编码智能体运行的评估是对照组的四倍，但评估之后修改智能体的频率与对照组差不多。这是谷歌自己的说法，文中没有给出数据。

作者总结的经验有五条。第一，先用小而有代表性的数据集：四个用例一分钟内就能跑完，每次改动都会运行；三百个用例要跑一小时，最多成为发布门槛，更可能被搁置。第二，保存结果文件而不只是分数，因为分数是摘要，结果文件才是证据，几周后出现回退时才能用 eval compare 找到具体用例。第三，把数据集与期望分开，两者演变节奏不同，都应纳入版本控制。第四，对汇总指标保持怀疑，模型替换实验就是例子。第五，更多评估不会自动带来更多修复，质量来自对评估结果采取行动。

文章给出的告警脚本很简单：把每次运行的平均分与基线（上一次运行，或已提交的已知良好结果）比较，下降超过阈值就以非零状态退出，再由 cron、Cloud Scheduler 或 GitHub Actions 步骤据此发出警报。文章还说，夜间运行的数据集可以比日常内循环的大，通常是几十到几百个用例，因为它一天只运行一次；这样也能发现模型厂商悄悄升级所带来的行为变化。

实际的结论比较朴素：每天的数据集小到每次改动都能跑，保存完整结果文件而不只是分数，在相信平均分之前先看逐条差异。工具无法替团队判断哪些用例重要，这一判断仍须由团队自己给出。