microsoft/ai-agent-evals：把 Agent 评测塞进 CI/CD，改动不达标就别上线
microsoft/ai-agent-evals：把 Agent 评测塞进 CI/CD，改动不达标就别上线
传统软件有单元测试守门，Agent 的"单元测试"长什么样？微软给了一个官方答案。
传统软件的 CI/CD 里，测试是守门员：单测不过、覆盖率不达标，代码就别想合并。但 Agent 应用一直缺这个环节——prompt 改几个字、换个模型版本、调个工具描述，质量是升是降全凭感觉，出了问题往往上线后才知道。
microsoft/ai-agent-evals 是微软官方给出的补位方案：一个 GitHub Action（105 stars，Python，MIT），在 CI/CD 管道里离线评估 Microsoft Foundry Agents。你提供测试查询数据集和 evaluator 列表，它调用你的 agent、收集延迟和 token 数据、跑评估、生成带统计检验的汇总报告——发布到生产之前发现问题。
这正好补上了我们之前写的《Agent 上生产四关》里"Eval 关"的 CI 化落地：评测不是上线前人工跑一次，而是每次 push 自动跑、和基线做统计对比。
本文提纲
- 它是什么：Agent 的"单元测试"守门员
- 六类 evaluator：从通用质量到自定义
- 怎么用：数据文件 + workflow 配置
- 统计显著性：区分"真的变好"和"随机波动"
- 多 agent 对比：A/B 测试 your agent
- 冷静看：它的适用边界
它是什么：Agent 的"单元测试"守门员
官方定位一句话：在 CI/CD 管道里对 Microsoft Foundry Agents 做离线评估，在发布更新到生产之前发现潜在问题、做改进。
工作流程全自动：给一份带测试查询的数据集和 evaluator 清单 → action 用这些查询实际调用你的 agent(s) → 收集性能数据（延迟、token 数）→ 运行评估 → 生成汇总报告，直接写进 GitHub Actions 的 summary 页。
关键特性：
- Agent 评估自动化：Foundry agents 的上线前评估嵌进 CI/CD
- 任意 evaluator：Foundry evaluator catalog 里的都能用
- 统计分析：结果带置信区间和显著性检验——判断变化是否有意义，而不是随机波动
注意它的定位：绑定 Microsoft Foundry 生态。agent 是 Foundry Agent Service 托管的（agent-id 格式 agent-name:version），评估器走 Foundry 的 evaluator catalog。如果你用 Foundry 建 Agent，这是现成的官方方案；如果是 LangGraph/自研 harness，思路可以借鉴但工具不能直接用。
六类 evaluator：从通用质量到自定义
评估器的覆盖面是这个 action 的核心价值，六大类：
| 类别 | 评估什么 | 典型场景 |
|---|---|---|
| Agent evaluators | agent 工作流的流程级和系统级表现 | 多步任务的完成质量 |
| RAG evaluators | RAG 系统的端到端和检索过程 | groundedness、检索相关性 |
| 风险与安全 evaluators | 回答中的风险和安全问题 | 暴力、自伤等内容安全 |
| 通用 evaluators | 通用质量 | coherence（连贯）、fluency（流畅） |
| OpenAI graders | 字符串检查、文本相似度、score/label 模型 | 精确匹配、语义相似打分 |
| 自定义 evaluators | Python 代码或 LLM-as-a-judge 模式 | 你的领域特有标准 |
这个分类和"Eval 三层论"（任务级指标 / LLM-as-a-judge / 规则检查）高度对应：内置的 risk&safety、RAG、通用质量是 LLM-judge 类；OpenAI graders 里的 string_check 是规则类；custom evaluators 让你接自己的任务级指标。一套 action 覆盖全部三层。
怎么用：数据文件 + workflow 配置
两步：准备数据文件，配 workflow。
第一步：写数据文件（JSON）
{
"name": "test-data",
"evaluators": [
"builtin.fluency",
"builtin.task_adherence",
"builtin.violence"
],
"data": [
{ "query": "Tell me about Tokyo disneyland" },
{ "query": "How do I install Python?" }
]
}结构字段：
| 字段 | 必需 | 说明 |
|---|---|---|
name |
✅ | 评估数据集名称 |
evaluators |
✅ | evaluator 名称列表（来自 Foundry portal 的 evaluator catalog） |
data |
✅ | 输入对象数组，query + 可选 ground_truth、context 等，自动映射到 evaluator |
openai_graders |
可选 | OpenAI 类评估器配置（label_model、score_model、string_check 等） |
evaluator_parameters |
可选 | evaluator 初始化参数（阈值、自定义设置） |
data_mapping |
可选 | 自定义字段映射（不提供则自动生成） |
官方 samples 目录给了六个示例数据文件，从最小集到全类型覆盖，含置信区间计算所需的数据量参考。
第二步：配 workflow
name: "AI Agent Evaluation"
on:
workflow_dispatch:
push:
branches:
- main
permissions:
id-token: write # 联邦凭据认证必需
contents: read
jobs:
run-action:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Azure login using Federated Credentials
uses: azure/login@v2
with:
client-id: ${{ vars.AZURE_CLIENT_ID }}
tenant-id: ${{ vars.AZURE_TENANT_ID }}
subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
- name: Run Evaluation
uses: microsoft/ai-agent-evals@v3-beta
with:
azure-ai-project-endpoint: ""
deployment-name: ""
agent-ids: ""
data-path: ${{ github.workspace }}/path/to/your/data-file 五个输入参数：
| 参数 | 必需 | 说明 |
|---|---|---|
azure-ai-project-endpoint |
✅ | Foundry Project 端点 |
deployment-name |
✅ | 用于评估的 Azure AI 模型部署名（judge 用的模型） |
data-path |
✅ | 评估数据文件路径 |
agent-ids |
✅ | 要评估的 agent，格式 agent-name:version，多个逗号分隔 |
baseline-agent-id |
可选 | 多 agent 对比时的基线（不填用第一个） |
认证走 Azure 联邦凭据（id-token: write），不用存密钥。当前版本 v3-beta；老版本 Foundry classic 用 v2-beta，Hub-based 项目用 v1-beta。
每次 push 到 main（或手动 dispatch）就会自动跑评估，报告出现在 Actions run 的 summary 页——含多 agent 对比的可视化。
统计显著性：区分"真的变好"和"随机波动"
这是这个 action 最值得学的细节。
LLM 输出是概率性的——同一个 agent 跑两遍评估，分数本来就会波动。没有统计检验的对比都在耍流氓：score 从 82.3 涨到 82.7，你是该开心还是该无视？
ai-agent-evals 的做法：
- 置信区间：评估结果带置信区间，告诉你分数的波动范围
- 显著性检验：多 agent 对比时输出统计检验结果，判断差异是不是随机变异造成的
- 数据量提示：官方示例特别说明 dataset.json 要"足够多的 queries 以支持置信区间计算和统计检验"——样本太小，统计检验就失效
这和我们在《Agent 上生产四关》里讲的"评测当闸门"是同一件事的工程化：闸门不能建立在感觉上，要建立在统计上。 把"变化 > 置信区间"作为合并 PR 的条件，评测才真正有了守门能力。
多 agent 对比：A/B 测试 your agent
agent-ids 支持多个 agent（逗号分隔），baseline-agent-id 指定基线——这就是 Agent 版的 A/B 测试：
agent-ids: "my-agent:1,my-agent:2"
baseline-agent-id: "my-agent:1"典型用法：prompt 或模型版本改动了，把 v1（基线）和 v2 一起评估，报告直接对比两者的各项指标 + 统计显著性。v2 显著更好才合并——Agent 版本的灰度验证在 CI 里完成。
这个模式对 prompt 管理尤其有价值：prompt 是 Agent 的"源代码"，但它没有类型系统、没有编译检查，改坏了很难发现。数据集 + CI 评测就是 prompt 的"回归测试"。
冷静看：它的适用边界
几句实在话。
绑定 Foundry 生态是最大的限制。 agent 必须是 Foundry Agent Service 托管的，评估器主要来自 Foundry catalog，部署模型是 Azure AI。如果你不在 Azure/Foundry 技术栈上，这个 action 用不了——同类需求可以看 LangSmith 的 CI 评测、promptfoo、或自建 eval pipeline。但即便不用，它的报告结构、统计检验、多 agent 对比设计都值得抄。
105 stars、pushed 停在 5 月：项目热度不高、版本还挂着 beta（v3-beta），API 可能变动。生产使用前先在小项目上验证。
离线评估的天花板仍在：数据集覆盖不到的场景它测不到，评测集本身的维护（补充真实流量 case）依然是人工活。CI 评测解决"改动不回归"，不解决"线上没问题"——后者还得靠在线 eval 和监控补位。
一句话总结：Agent 时代的"单测守门"正在成型——微软把它做进了 CI/CD，评测不过、上线免谈。 在 Foundry 生态里的团队可以直接用；不在的，把"数据集 + 统计检验 + 基线对比"这个模式带回去。
参考链接
- GitHub: microsoft/ai-agent-evals - 官方仓库，105 stars，Python，MIT
- Foundry Agent Service 文档 - agent 服务与版本管理
- Foundry Observability 概念 - 评估与可观测体系
- Foundry evaluator catalog - OpenAI graders 与评估器目录
- 我的 Agent 上生产四关 - Trace/Eval/Guardrail/Token 的标准框架
你们的 Agent 改动怎么验证质量？靠感觉还是靠评测集？评论区聊聊，觉得有用点个赞让更多做 Agent 工程的人看到。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
