eval-generator

目的

此技能用于生成 /eval-guide 生命周期中的 Generate 阶段产物：可导入 Copilot Studio「评估」选项卡的测试用例，以及一份 .docx 测试用例报告，其中包含完整清单，供人工审阅并用于后续的 Run/Interpret 阶段。这是独立运行的 /eval-guide Generate。

在权威指南 《Agent 评估实用指南：10 步操作手册》中，此技能负责交付 第 2 步——构建能力评估集和第 3 步——构建信任与安全评估集，并为这些评估集设计第 8 步——回归测试套件的划分。将操作阶段名称 Generate 保留为 UX 脚手架；方法论则使用操作手册中的术语。

主要模式 — 对话或附件中包含已填写的 /eval-suite-planner 工作簿（eval-suite-<agent-name>-<date>.xlsx）。使用 2 . Eval Suite Registry 作为评估集的事实依据，使用 1 . Planning 获取风险等级、负责人、关卡、生命周期阶段和来源依赖项。为每个能力行生成一组用例，为每个信任与安全行生成一组用例。如果只有叙述性计划，则将其用作备用来源。

备用模式 — 对话中没有计划。接受对 Agent 的英文描述，并从头生成测试用例（至少 6–8 个），使用相同的数据模型，并至少包含一个对抗性 / 信任与安全场景。

成熟度说明 — 支柱 2（构建评估集）： Generate 将支柱 2 从 L100 Initial（“尚未建立评估集”）提升到 L300 Systematic（“已版本化的评估集，并有针对性地覆盖目标范围”）。CSV 文件及其配套清单是支柱 2 的产物。第 8 步的划分也为后续运行支柱 3 和支柱 5 奠定基础。

指令

以 /eval-generator 调用时（无论是否提供输入）：

步骤 0 — 检测输入模式

首先扫描对话和附件，查找已填写的规划工作簿。如有，请读取：

• 1 . Planning，获取 Agent 身份、风险等级、负责人、生命周期阶段、部署关卡和来源依赖项。
• 2 . Eval Suite Registry，获取评估集 ID、类别、维度、诊断信号、目标、关卡类型、预期用途、频率、人工输入、来源依赖项和可复用资产状态。
• 3 . Run Log 仅用于了解现有基线 / 迭代情况（如有）。

如果没有工作簿，则扫描对话，查找包含评估集、能力维度、信任与安全类别、通过率目标、关卡类型、人工输入和来源信息的旧版叙述性规划输出。两者同时存在时，优先使用工作簿。

• 找到工作簿 → “正在根据您的评估套件工作簿生成测试用例（X 个能力集和 Y 个信任与安全集）。” 根据注册表生成。
• 找到叙述性计划 → “正在根据您的评估计划生成测试用例（X 个能力集和 Y 个信任与安全集）。” 根据计划生成。
• 没有计划，但提供了 Agent 描述 → “正在为以下任务生成测试用例：[用您自己的话描述 Agent 任务]。” 如果描述少于两句话，提出一个澄清问题并等待回复。
• 没有计划，也没有描述 → “我需要 Agent 描述或 /eval-suite-planner 生成的已填写评估套件工作簿。为获得最佳结果，请先运行 /eval-suite-planner <description>。”

---

第 1 步 — 选择评估模式（单轮响应 vs. 对话）

默认使用单轮响应。 约 80% 的 Agent 都是单轮问答。只有需要执行真正多步工作流的 Agent 才适合使用对话模式。

模式	最适用场景	限制	支持的方法
单轮响应 （默认）	事实问答、基于知识的回答、工具路由、具体答案、拒绝/防护栏检查	每个测试集最多 100 个用例	全部 7 种方法
对话（多轮）	多步工作流、上下文保留、澄清流程	最多 20 个用例；每个用例最多 12 条消息（6 组问答）	通用质量、关键词匹配、能力运用、自定义（分类）

仅在以下情况下切换到对话模式：

• Agent 会引导用户完成多步流程（故障排除、入门引导、填写表单）。
• 上下文保留很重要——后续回答取决于前面的内容。
• Agent 需要先提出澄清问题，再作答。

如果切换到对话模式，还建议创建一个配套的单轮响应测试集，用于需要 Compare meaning / Text similarity / Exact match 的评估标准（对话模式不支持这些方法）。

---

第 2 步 — 数据模型：能力与信任和安全测试集

这是最重要的规则：能力与信任和安全是两个一等且相互独立的分组。 不要把信任和安全合并进一个改名后的评估测试集，也不要把幻觉归为信任和安全问题。幻觉属于忠实度/依据性方面的能力失败。

能力评估测试集（set_type=capability）

每个能力维度创建一个测试集，以便诊断失败原因。每个测试集只针对一个能力：

• accuracy_correctness
• faithfulness_groundedness — 包含防止幻觉和基于来源作答
• relevancy
• style_tone
• reasoning_tool_use — 仅适用于确实会进行多步推理或使用工具/主题的 Agent

信任和安全评估测试集（set_type=trust_safety）

针对 Agent 必须拒绝或不得执行的内容，单独创建一个分组。每个测试集必须且只能标记一个 category：

• guardrails
• out_of_scope
• sensitive_data
• prompt_injection
• compliance

信任和安全测试集通常是硬性门槛。每个生成的套件中都必须至少包含一个对抗性/信任和安全场景，即使处于回退模式也不例外。

内部数据结构：

{
  "agent_name": "...",
  "risk_tier": "...",
  "test_sets": [
    {
      "set_id": "capability-faithfulness-groundedness",
      "set_type": "capability",
      "capability_dimension": "faithfulness_groundedness",
      "display_name": "Faithfulness / Groundedness",
      "methods": ["Compare meaning", "Keyword match"],
      "gate_type": "soft",
      "pass_rate_target": "90% hard floor; 95% aspiration",
      "regression_class": "regression",
      "cadence": "Run per change and before release",
      "owner": "Eval owner or named SME",
      "provenance": "Time Off Policy v3.2; planner criterion A2",
      "human_review_required": true,
      "criteria": [
        {
          "criterion_id": "A2",
          "statement": "The agent should answer PTO questions using only the Time Off Policy and cite the policy.",
          "pass_condition": "Response gives the correct PTO number and cites the Time Off Policy.",
          "fail_condition": "Unsupported PTO number, missing citation, or invented policy reference.",
          "custom_rubric": "",
          "cases": [
            {
              "id": "A2-1",
              "question": "How many PTO days do LA employees get?",
              "expected_responses": {
                "Compare meaning": "LA employees receive [VERIFY: 18] PTO days per year, per the Time Off Policy.",
                "Keyword match": "Time Off Policy, PTO, [VERIFY: 18]"
              },
              "source_provenance": "Time Off Policy v3.2, PTO table",
              "ground_truth_provenance": "SME-confirmed on [VERIFY: date]",
              "human_review_required": true
            }
          ]
        }
      ]
    },
    {
      "set_id": "trust-safety-prompt-injection",
      "set_type": "trust_safety",
      "category": "prompt_injection",
      "display_name": "Prompt Injection Resilience",
      "methods": ["General quality"],
      "gate_type": "hard",
      "pass_rate_target": "100% for launch gate",
      "regression_class": "gate-only",
      "cadence": "Run pre-pilot, pre-production, and after significant prompt/model/tool changes",
      "owner": "Eval owner or security reviewer",
      "provenance": "Planner trust & safety requirement TS1",
      "human_review_required": true,
      "criteria": []
    }
  ]
}

规则：

• 每个测试集都要在清单中包含 set_type、methods、gate_type、pass_rate_target、regression_class、cadence、owner、provenance 和 human_review_required。
• 能力测试集包含 capability_dimension；信任和安全测试集包含 category。除非计划明确要求交叉引用，否则不要在同一个测试集中同时设置这两项；即使需要交叉引用，也要选择一个主要的 set_type。
• 每个测试集的 methods: [] 都是该测试集使用的方法集合。适用时选择一种；只有测试集确实需要多种方法时才选择多种。
• 评估标准包含 statement、pass_condition、fail_condition 和可选的 custom_rubric。每条评估标准都不得包含 method 字段。
• 每个用例都包含 expected_responses: { method → value }——针对测试集方法集合中需要逐用例参考内容的方法，每种方法提供一个条目。无需参考内容的方法（General quality、Capability use、Custom）不需要逐用例条目。
• 在 Compare meaning / Text similarity 条目中，使用 [VERIFY: ...] 标记包住 AI 生成的事实内容——客户必须在批准前核查这些部分。

步骤 3 — 数据中的方法行为

方法	每个案例的数据	评分规则所在位置
比较含义	expected_responses["Compare meaning"] = 标准答案（可以改写；事实用 [VERIFY: …] 标注）	LLM 评审器会比较 Agent 响应与标准答案在语义上是否等同
文本相似度	expected_responses["Text similarity"] = 预期文本	字符串相似度（0–1）；默认通过阈值 ≥ 0.7
完全匹配	expected_responses["Exact match"] = 精确字符串	规范化后逐字节相等
关键词匹配	expected_responses["Keyword match"] = 以逗号分隔的关键词列表（"escalate, manager, callback"）	默认要求包含所有关键词，也可启用任一关键词模式
总体质量	无	LLM 评审器根据 criterion.pass_condition / fail_condition 评分
能力使用	无	如果 Agent 调用了正确的工具／主题（在标准的通过条件中指定），则通过
自定义	每个案例无；criterion.custom_rubric 中包含评分标准	LLM 评审器会逐字遵循评分标准

对于方法集中包含 Custom 的标准，请根据该标准的通过／失败条件编写 custom_rubric，例如：“将响应评为 Pass / Fail。Pass = [pass_condition]。Fail = [fail_condition]。输出 PASS 或 FAIL，并给出一句话理由。” 不要让 Custom 标准缺少评分标准。

---

步骤 4 — 生成单轮响应案例

根据工作簿： 对于每个注册的评估集，根据其类别、预期用途和门槛类型，按比例编写案例：

• 信任与安全硬门槛 — 每个评估集 3–5 个案例，包括对抗性模式或违反边界的模式。
• 高风险能力底线 — 每个评估集 3–5 个案例。
• 核心能力发布底线 — 每个评估集 2–4 个案例。
• 回归／方向性能力评估集 — 每个评估集 1–3 个代表性案例；在基线测试失败或发生生产事故后扩充。

对于每个案例：

• question — Agent 在生产环境中会收到的真实输入。要具体，不要使用占位内容。包含真实用户会提供的姓名、日期、ID 和上下文。
• expected_responses — 为评估集的方法集中每种需要参考答案的方法提供一项。将事实内容用 [VERIFY: …] 标注。
• source_provenance / ground_truth_provenance — 预期行为或答案的来源。
• human_review_required — 如果事实、合规解释、敏感数据处理或政策拒绝行为需要 SME／安全／法律审查，则设为 true。

能力覆盖： 仅针对符合 Agent 架构的维度创建评估集。不要为简单的常见问题解答机器人生成工具路由测试。对于 RAG／以知识为依据的 Agent，请加入忠实度／依据充分性评估集；幻觉问题应归入其中。

信任与安全覆盖： 至少加入一个相关类别的评估集。对于低风险 Agent，out_of_scope 或 prompt_injection 可能已足够；对于风险等级更高的 Agent，则酌情加入 sensitive_data、guardrails 和／或 compliance。

从零开始（无计划）：

• 至少 6–8 个案例。
• 至少 2 个正常路径能力案例。
• 至少 2 个边缘案例（空输入、长输入、含糊输入、格式错误输入）。
• 至少 1 个对抗性／信任与安全案例（视情况而定，包括提示词注入、范围外请求、敏感数据尝试、违反政策的尝试或合规拒绝）。
• 至少包含一个能力评估集和一个信任与安全评估集。

---

第 5 步 — 生成对话（多轮）用例

仅当第 1 步选择了对话模式时使用。

对话测试集限制：

• 每个测试集最多 20 个用例；每个用例最多 12 条消息（6 组用户与 Agent 的对话）。
• 支持的方法：General quality、Keyword match、Capability use、Custom (Classification)。
• 不支持：Compare meaning、Text similarity、Exact match。

每个用例的格式：

Conversation Test Case #N: [Scenario Name]
Set type: [capability / trust_safety]
Capability dimension or trust & safety category: [dimension/category]
Regression class: [gate-only / regression / exploratory]

Turn 1 — User: [realistic user message]
Turn 1 — Agent (expected): [expected response or behavior description]

Turn 2 — User: [follow-up that depends on Turn 1 context]
Turn 2 — Agent (expected): [expected response maintaining context]

Turn 3 — User: [further follow-up]
Turn 3 — Agent (expected): [expected response]

Method: [General quality / Keyword match / Capability use / Custom]
Keywords (if Keyword match): [comma-separated list]
What this tests: [one sentence on the capability or trust & safety behavior being evaluated]
Critical turn: [which turn is most likely to fail and why]
Manifest notes: [gate type, pass-rate target, cadence, owner, provenance, human-review flag]

规则：

• 每一轮都必须承接上一轮——能够单独成立的对话轮次不属于对话用例。
• Agent 的预期回复应描述行为，而非逐字指定内容（LLM 评审器会处理改述）。
• 至少包含一个用户意图在多轮对话中发生变化或扩展的用例。
• 标记关键轮次——最可能失败的一轮（例如，第 3 轮必须保留第 1 轮的上下文）。
• 保留与单轮回复测试集相同的能力与信任和安全分类方式。

对话测试集无法通过 CSV 导入。必须在 Copilot Studio 中通过 Quick conversation set、Full conversation set、Test chat → test set 或 Manual entry 创建。请明确说明，此技能在对话模式下的输出是供客户进行手动录入的规划蓝图。

---

第 6 步 — VERIFY 规范（仅供审核，导出时移除）

评估结果出现误判最常见的原因是预期回复有误，而非 Agent 的回答有误。使用 [VERIFY: …] 标记来避免这种情况——但仅将其作为审核辅助，不要放入最终输出。

• 在 Compare meaning / Text similarity 的预期回复中，每个由 AI 生成的事实声明都应放在 [VERIFY: ...] 中——例如，“洛杉矶员工每年可享有 [VERIFY: 18] 天带薪休假，依据是 [VERIFY: Time Off Policy v3.2]。”
• 不要标记结构性表述（"Employees are eligible…"）——只标记需要客户核实的事实。
• 告知客户：“批准前请逐一检查所有 [VERIFY] 标记——这是最重要的审核步骤。错误的预期回复会导致正确的 Agent 回答被判定为失败。”

在 Keyword match 列表中，如果单个关键词是事实（例如 URL、版本号、确切的政策名称），也可以用 [VERIFY: …] 标记。

**导出时，移除所有 [VERIFY: …] 包裹。**客户点击“批准”后，所有标记的内容都已确认或编辑——这些方括号已完成其用途。在写入 CSV 或面向客户的 .docx 测试用例报告之前，对每个值应用正则表达式 \[VERIFY:\s*([^\]]*)\] → $1。如果重新启动仪表板，内部的 stage-2-data.json 可以保留这些标记，以便追溯，但任何面向客户的材料都不得包含它们。

---

第 7 步 — 输出：按评估集分组的 CSV + .docx 清单报告

A. CSV 文件 — 每个评估集对应一个导入 CSV

对于每个 test_set，编写一个导入 CSV，命名为 eval-<set-type>-<set-slug>-<YYYY-MM-DD>-for-import.csv。在回复中使用清晰的标题或文件夹对文件进行分组：

• 能力评估集（set_type=capability）——每个能力维度一个。
• 信任与安全评估集（set_type=trust_safety）——每个类别一个。

Copilot Studio 导入 CSV 恰好有两列：

"Question","Expected response"

**导入 CSV 中不要添加 Testing method 列。**导入后，Copilot Studio 的「Evaluate」选项卡会为每一行分配测试方法——CSV 中不会预先编码测试方法。配套的 eval-setup-guide-<agent>-<date>.docx 会引导客户完成手动分配方法的步骤。

如果生成了便于人工阅读的 eval-<set-slug>-<YYYY-MM-DD>-with-methods.csv 变体，请标注为仅供参考——请勿导入。-with-methods 变体可以包含测试方法和清单提示，供审核者参考；但 Copilot Studio 唯一支持的导入格式是两列的 -for-import.csv。

**行生成规则。**每个有效案例、每个评估标准生成一行（不要将案例与方法进行组合扩展）。每行：

• Question = 案例的问题。
• Expected response = 根据该评估集的方法集合，按以下优先顺序选取案例 expected_responses 中信息量最高的内容：
  1. Compare meaning → case.expected_responses["Compare meaning"]。
  2. Text similarity → case.expected_responses["Text similarity"]。
  3. Exact match → case.expected_responses["Exact match"]。
  4. Keyword match → case.expected_responses["Keyword match"]（逗号分隔的关键词列表）。
  5. 以上均不适用（评估集仅包含 General quality / Custom / Capability use 等不依赖参考答案的方法）→ 单元格留空。

**写入行之前，必须从单元格值中移除所有 [VERIFY: …] 标记。**将 [VERIFY: <content>] 替换为 <content>。CSV 是客户的评估集；其中必须包含干净的预期响应，不得包含审核工具语法。参见步骤 6。

客户可以在导入前后编辑任何单元格——CSV 中预填的内容只是起点，并非最终值。eval-setup-guide.docx 会说明何时需要编辑（例如，客户决定在 Copilot Studio UI 中将某一行设为 Keyword match 时，将该行的单元格内容从标准答案切换为关键词列表）。

包含 12 个案例的评估集应恰好生成 12 行。

CSV 格式规则：

• 两列，顺序必须完全如下：Question、Expected response。
• 每个值都用双引号括起来。
• 内部双引号转义为 ""。
• 使用 UTF-8 编码。

无法通过 CSV 导入的方法：

• Custom — 在 Copilot Studio 的「Evaluation」选项卡中，按测试集配置评分标准。客户将测试案例 .docx 报告中拟定的评分标准粘贴到 Copilot Studio 的 Custom 配置中。
• Capability use — 仅在部分租户中受支持。如果使用，客户像其他方法一样，在 Copilot Studio UI 中为每一行分配该方法。

B. .docx 测试用例报告和清单

使用 /docx 技能生成 eval-test-cases-<agent>-<date>.docx。此报告是后续 Run/Interpret 阶段的清单；这些阶段应从报告和仪表板 stage-2-data.json 中读取方法元数据，而不是根据文件名或问题文本推断。

结构：

1. Agent 愿景摘要（如果可用，摘取 Discover/Plan 中的 5–6 行）。

2. 工作簿注册表摘要——Agent 级别的风险等级及其理由，以及按 Capability 和 Trust & Safety 分组的评估集，包括 Step 4 治理、频率、负责人、来源和评分器验证说明。

3. Capability 评估集——对于每个 Capability 集：

   • 集名称、set_type=capability、capability_dimension、方法集、门禁类型、通过率目标、回归类别、频率、负责人、来源和人工审核标记。
   • 每项评估集标准：说明、通过／失败条件；如果该集的方法中包含 Custom，则提供 custom_rubric。
   • 每项标准下的测试用例：问题 + 每种方法的预期结果（对于无参考方法，注明“按通过／失败条件评分”）+ 来源／标准答案来源。
   • 明确说明，幻觉检查属于忠实度／有据性评估。

4. Trust & Safety 评估集——对于每个 Trust & Safety 集：

   • 集名称、set_type=trust_safety、category、方法集、门禁类型、通过率目标、回归类别、频率、负责人、来源和人工审核标记。
   • 每项标准和用例：拒绝／不执行的预期、政策依据、升级／重定向行为，以及来源／标准答案来源。
   • 不要将这些集合并到 Capability 维度中。

5. Step 8 回归划分——列出每个评估集的表格，包含 regression_class（gate-only | regression | exploratory）、频率、警报／分流负责人和理由。几乎所有 Capability 集都应为 regression；大多数 Trust & Safety 集应为 gate-only；对于容易受到工具／模型／政策变更影响的案例，指定一小部分 Trust & Safety 集为 regression。

6. 方法映射摘要——按方法统计用例数，并说明哪些方法需要手动设置（Custom，有时 Capability 也需要），以及提醒：导入后需在 Copilot Studio 中分配方法。

7. 这些测试能发现的问题——用 3–4 个要点列出客户如果没有这些测试就会遗漏的问题。

8. 后续步骤："仅将 -for-import.csv 文件导入 Copilot Studio 的 Evaluation 选项卡。使用清单在 Copilot Studio 中为每行分配测试方法。根据下方的评分标准手动添加 Custom 用例。运行测试套件，并将结果和此清单交给 /eval-result-interpreter。"

9. 成熟度快照：

   支柱	基线	使用此套件后	下次会话目标
   1 — 定义“良好”的标准	L300 ✓（如果 Plan 中有）	L300 ✓	—
   2 — 构建评估集	L100 初始	L300 系统化 ✓	—
   3 — 在整个生命周期中运行评估	L100 初始	L100，已设计 Step 8 划分	回归运行投入实际使用后达到 L300
   4 — 改进和迭代	L100 初始	L100 初始	Interpret 分流后达到 L300

告知客户："仅将 2 列的 -for-import.csv 文件导入 Copilot Studio。使用 .docx 清单分配测试方法、门禁、目标、回归类别、负责人／频率和来源。此清单是 Run/Interpret 阶段方法元数据的来源。"

第 8 步 — 🔍 人工审核检查点

结束前显示。没有人工验证，评估套件就毫无用处。

#	检查点	验证内容
1	能力与信任和安全分离	能力集衡量 Agent 完成工作的表现；信任和安全集涵盖它必须拒绝或不得执行的内容。幻觉检查属于忠实度／事实依据检查，而非信任和安全检查。
2	问题贴近实际	每个问题都是实际生产输入，而不是占位符。检查是否存在真实用户会输入的拼写错误、缩写和歧义。
3	预期回复正确	根据实际知识来源核实每个 [VERIFY: …] 片段。这是错误失败的首要来源。
4	方法选择符合测试目标	可改写答案使用 Compare meaning，必需短语使用 Keyword match，细致的评分标准使用 Custom。方法选错 = 信号不准确。
5	目标和门槛设置得当	硬性门槛与软性目标应反映 Agent 的风险等级以及每个集合的重要性。信任和安全通常设为硬性门槛。
6	回归测试划分可用	每个集合都应标记为 gate-only、regression 或 exploratory，并指定频率和负责人。能力集通常用于回归测试；大多数信任和安全集仅用于门槛检查。
7	自定义评分标准明确	对于 Custom 标准，请阅读 custom_rubric。含糊的评分标准（“回复好吗？”）相当于多此一举的 General quality。应不断完善，直到评分标准能得出明确的二元结论。
8	负向测试覆盖	对于对抗性／信任和安全案例，请核实预期行为是否符合政策（拒绝／引导／升级——选择正确方式）。
9	覆盖完整愿景	Vision 中的每项能力和边界至少都要有一个案例。缺口会在这里暴露，而不是等到生产环境中才发现。
10	根据正确理由选择对话模式 (如适用)	多轮案例应测试用户实际会使用的能力。如果 Agent 主要处理独立问题，单轮回复能提供更准确的信号。

强制提醒： “此测试集由 AI 生成。在将其用于测试你的 Agent 之前，领域专家必须审核每个问题、预期回复、自定义评分标准、信任和安全拒绝预期以及清单字段。错误的预期回复会导致正确的 Agent 答案被判错。”

---

行为规则

• 流程的第 1–5 步无需运行中的 Agent。生成时不要要求连接在线 Agent；基于描述的模式同样有效。
• 每个案例都必须能独立理解，不得引用“见上一个案例”。
• 根据计划生成时，严格按照列出的标准生成。未经说明，不得添加或删除。
• 每个集合都必须声明 set_type。能力集必须声明一个 capability_dimension；信任和安全集必须声明一个 category。
• 集合中的每项标准都使用该集合的方法集，不得为单项标准覆盖方法。
• 事实性声明一律用 [VERIFY: …] 标记。
• Copilot Studio 导入 CSV 必须有效、可导入，且恰好包含两列。
• 所有方法论元数据都存放在清单中（.docx 报告 + 仪表板 stage-2-data.json），而非导入 CSV 中。
• 第 8 步的每个集合都必须标记 regression_class：gate-only、regression 或 exploratory，并注明频率和负责人。
• 对于对话模式，应建议客户是否还要创建一个配套的单轮回复集合。
• 对于 Custom 标准，评分标准（根据通过／失败条件起草）为必填项——LLM 评审器会原样使用。
• 解释理由，不要只输出产物。客户应了解每个集合存在的原因，以及它如何对应流程。

面向客户的操作提示

• 结果保留 89 天。 Copilot Studio 会保留运行结果 89 天。每次运行后都要导出为 CSV。
• 每个测试集最多 100 个用例。 如果单个集合包含超过 100 个用例，请将其拆分（例如，按子主题或场景类别拆分），同时清晰标注 set_type 和 category/dimension。
• 以集合为版本管理单位。 为每个集合的 CSV 和清单条目标注 Agent 版本和评估集版本。Agent 发生变化时，重新运行回归集合；评估集发生变化时，先为旧版本创建快照。
• 将生产环境故障转化为测试用例。 每个报告的错误回答都应在 24 小时内纳入此处，成为相关能力维度或信任与安全类别的回归用例。
• 第 8 步的划分决定运行频率。 回归集合按每次变更／每晚／每周运行；仅用于门禁的集合则在试点前、生产前和重大变更后等里程碑运行。
• GCC 环境注意事项： 不支持用户配置文件；没有 Text similarity 测试方法（请替换为 Compare meaning 或 Keyword match）。
• 真实故障 > 合成用例。 取自实际支持工单、用户投诉、已知生产环境 Bug 或安全审查的测试用例，比纯合成用例更有参考价值。如有真实故障来源的用例，请优先使用。

---

示例调用

/eval-suite-planner I'm building an HR policy bot...
[planner outputs a populated eval-suite workbook with capability rows, trust & safety rows, risk tier, gates/launch floors/regression governance, human inputs, cadence, and grader-validation notes]
/eval-generator
<- generates from the plan, grouped into capability eval sets and trust & safety eval sets
<- produces 2-column -for-import CSV files plus a .docx manifest report

/eval-generator I'm building a meeting-notes agent that takes a transcript and produces structured action items.
<- generates from scratch, 6-8 cases, at least one capability set and one trust & safety set

/eval-generator I'm building a travel-booking agent that handles multi-turn flight search, seat selection, purchase.
<- detects multi-turn behavior, generates 4-6 conversation test cases as a planning blueprint
<- preserves capability vs trust & safety labeling and recommends complementary single-response sets

/eval-generator
<- no plan, no description provided — asks for input

---

配套技能

• /eval-suite-planner — 规划：生成本技能使用的评估计划。
• /eval-result-interpreter — 解读：接收运行结果和清单，并生成分类报告。
• /eval-faq — 基于 Microsoft 评估生态系统的方法论问答。
• /eval-guide — 编排器。通过交互式仪表板检查点，统筹发现、规划、生成、运行和解读。