微软 ASSERT：用自然语言给 AI Agent 写行为测试
微软开源的评估框架，把产品需求文档自动转化为可执行的 AI 行为测试。规范驱动 + OTel 追踪 + LLM 裁判，框架无关，本地优先。
翻译
原文来自 TechCrunch，作者 Ram Iyer，2026 年 6 月 2 日发布。
AI 研究人员和实验室在评估 AI 模型方面已经取得了长足进步——从安全性和合规性到谄媚行为和价值观对齐，方方面面都有所覆盖。但企业和开发者似乎面临着一个新的、更具体的需求：确保 AI 系统在特定的产品或服务中表现符合预期。
为了简化这一测试过程，微软在周二发布了 ASSERT，全称"自适应规范驱动评分与回归测试"（Adaptive Spec-driven Scoring for Evaluation and Regression Testing）。
微软表示，这个开源框架能让应用特定的 AI 行为评估变得简单——它使用 AI 将高级的自然语言描述（目标、策略或预期行为）转化为全面的、可评分的测试。
ASSERT 接收自然语言描述的 AI 模型预期行为和策略，将其转化为结构化的"可接受"与"不可接受"行为集合，生成问题场景和测试用例，对目标系统运行这些测试，然后对结果进行评分。它还能记录 AI 系统的执行路径，包括中间动作和工具调用，让开发者可以检视故障发生的位置。
开发者还可以提供系统上下文、工具和约束条件，进一步自定义评估的覆盖范围。
例如，开发者可以规定：一个文档研究 AI Agent 不应向公司外部人员发送电子邮件；它应将机密信息限于 C 级高管；并应结合先前上下文提供简洁摘要。ASSERT 将使用这些规则生成测试用例，持续检查系统是否遵守这些规则。
该框架填补了更广泛、更通用的评估无法覆盖的空白——当 AI 模型需要在特定应用或产品的上下文、策略和工具约束下运行时。
"我们学到的一件事是，评估对于做出好的决策至关重要。因为如果你不了解 AI 系统的行为，就很难知道它是否达到了你组织的标准……我们发现，如果你真的想要一个可信赖的系统，你应该评估更多特定于应用的维度。"
Sarah Bird, CPO of Responsible AI at MicrosoftBird 表示 ASSERT 可用于系统构建阶段、部署之后、甚至持续监控。
此次发布正值 AI 行业逐渐但广泛的转变之际。随着模型能力增强，研究人员正聚焦于可重复测试和回归检查——斯坦福的 HELM、MLCommons 的 AILuminate、以及 METR 等评估组织都在推出基准测试，衡量模型在不同条件下的行为表现。
深度解读
2026 年的 AI 行业有个尴尬现实：大家都在喊 eval，但大多数工具解决的是通用问题。没人帮你测"我的 AI Agent 在我的产品里会不会干蠢事"。
三个最致命的假设
① 自然语言规范能完整描述预期行为（但 NL 天然有歧义）
② LLM Judge 能可靠评分（但已证存在位置/冗长/自我偏好）
③ 自动生成的测试用例足够全面（但可能遗漏领域专家才知道的 edge case）
微软为什么要开源这个
短期：推动行业评估标准。长期：ASSERT 用 OTel 标准追踪 Agent 行为 → Azure AI Foundry 天然支持 OTel → 开发者习惯微软生态。跟 AWS 开源 Firecracker 同一逻辑。
文章没告诉你的
三重 API 调用成本（生成+推理+评分）、竞品对比（Promptfoo/DeepEval/Ragas 已成熟）、LLM-as-Judge 的循环依赖问题、覆盖率量化方法缺失。
运行时模型
ASSERT 实际上在跑什么——五步管线的完整拆解。
规范解析
把自然语言描述拆成"可接受行为"和"不可接受行为"的结构化分类。你的产品需求文档就是输入。
测试生成
基于分类生成单轮和多轮测试用例，覆盖正例和反例。支持你提供系统上下文、工具和约束来自定义。
推理执行
对目标系统运行测试——模型端点、Agent、多 Agent 系统。通过 LiteLLM 支持 100+ 模型端点。
轨迹捕获
OpenTelemetry/OpenInference 抓取中间步骤：工具调用、路由决策、模型调用、延迟。关键差异化。
LLM 裁判评分
用 LLM 根据 OTel 追踪证据给每次对话打分。评分可审查——能看到基于什么证据给了多少分。
本地产物
每步写 JSON/JSONL 文件到本地。内置 Viewer 可 side-by-side 对比、pin baseline、drill into breakdowns。
# Quick Start — 10 分钟从零到有评估报告
pip install -e ".[otel,langgraph]"
cp .env.example .env # 填你的模型 API key
assert-ai run --config examples/travel_planner_langgraph/eval_config.yaml
# 产物在 artifacts/results/ 下
# 打开内置 Viewer 查看评估报告手搓版 vs ASSERT
在 ASSERT 出现之前，你怎么手动做这件事？它到底省了什么？
| 你手动要做的事 | ASSERT 帮你做了什么 |
|---|---|
| 从产品需求文档里手动写 50 个测试 prompt | 用 LLM 自动生成，覆盖正例和反例 |
| 写 Python 脚本调 API 跑测试 | assert-ai run --config eval_config.yaml 一行搞定 |
| 自己设计评分标准，写评分 prompt | 内置 LLM Judge，基于你的规范自动评分 |
| 看着一堆 JSON 日志猜哪步出了问题 | OTel 追踪 + 本地 Viewer，可视化每步决策 |
| 每次改了 Agent 还要手动回归测试 | 产物可版本化，CI/CD 集成 |
| 场景 | 该用 ASSERT | 该用其他工具 |
|---|---|---|
| 你有清晰的产品规范/策略文档 | ✅ 规范驱动的测试生成是核心 | |
| 你需要测多 Agent 系统的复杂交互 | ✅ OTel 追踪是杀手锏 | |
| 你需要跟 CI/CD 集成做回归测试 | ✅ 本地 JSON 产物 + CLI | |
| 你只需要简单的 prompt 对比测试 | Promptfoo 更轻量 | |
| 你需要生产环境实时监控 | Braintrust / LangSmith 更适合 | |
| 你在做 RAG 质量评估 | Ragas 更专业 | |
| 你不想依赖 LLM 做评分 | DeepEval 提供传统指标 |
苏格拉底对话
用师生对话拆解核心争议——LLM 评估 LLM，到底靠不靠谱？
核心洞察
- 偏见可以被管理：面试官也是人，有偏见。关键是"偏见可不可以被量化和管理"。ASSERT 的 OTel 追踪让评分基于过程证据，不只是最终输出。
- 从 0 到有测试的门槛极低：你今天可能没有任何测试——ASSERT 让你在 10 分钟内从零变成有覆盖。覆盖率够不够是第二步。
- OTel 追踪是降维打击：大多数评估工具只看输入输出。ASSERT 能看到 Agent 内部决策——哪个工具被调了、延迟是多少。对调试复杂 Agent 行为是质的飞跃。
- 开源动机不纯 ≠ 工具不好：微软开源 ASSERT 培养了 OTel 标准习惯 → Azure 天然受益。但 AWS 开源 Firecracker 也是同一逻辑。
需要警惕的
- LLM-as-Judge 循环依赖：用 GPT-4 给 GPT-4 打分，你能信多少？学术界已证明存在位置偏差、冗长偏好、自我偏好。
- 规范质量决定测试质量："简洁"是多简洁？"机密信息"的边界在哪？NL 规范的歧义会传播到生成的测试用例。
- 三重 API 成本：生成测试 + 运行推理 + LLM 评分 = 三次 API 调用。复杂 Agent 系统的一次完整评估可能烧掉不少 token。
- 领域专家直觉不可替代：LLM 生成的测试可能覆盖常见情况，但漏掉只有真正用过产品的人才知道的 edge case。
个性化洞察
基于你的技术背景和当前项目，ASSERT 能怎么帮到你。
10 分钟接上你现有的 Agent 产品
你已经有 product spec 和 system prompt——那就是 ASSERT 需要的全部输入。pip install → 写个 YAML config → 看到第一份评估报告。比手动写测试 prompt 快一个数量级。
OTel 追踪 = 你的测试方法论
你作为 QA 出身，天然对"测试不能只看表面"有敏感度。ASSERT 的 trace-grounded judgment 本质上就是把你"不能只看输出，要看中间过程"的直觉工程化了。
Sandcastle 开发流加一步
在 /to-issues 之后、npm run sandcastle 之前，加一个 ASSERT 评估步骤。先把 system prompt 和 behavior spec 喂进去跑一遍，确保 Agent 行为符合预期再构建。
微软评估工具三件套
ASSERT（规范驱动）+ eval-recipes（基准测试）+ eval-guide（Copilot Studio 插件）。三个组合起来是一个完整的评估策略。值得持续跟踪。