如何在 CI 流水线中用 LLM 评测拦截问题 PR

在 AI Agent 工程化落地过程中，提示词的版本管理往往是最容易被忽视的风险点。修改一行系统提示词，模型的输出行为可能发生根本性变化，而这种变化在代码审查阶段几乎不可见。常规 CI 流水线擅长捕捉语法错误、单元测试失败和类型不匹配，却对「模型说了什么」完全失明。将 LLM 评测引入 CI，本质上是把模型行为测试与代码测试放在同等地位——提示词改动触发评测，评测失败阻断合并，与单元测试的工作方式完全一致。

构建有效门控的前提是三件事同时就位。第一，建立固定且受版本控制的评测集。Anthropic 的 Agent 评测指南建议从真实失败案例中提取 20 到 50 个简单任务作为起始集，评测集本身只能通过经过审查的 PR 来修改。第二，确定评分方法与通过阈值。评分方法将单条回答判定为通过或失败，阈值则作用于整次运行的整体通过率。第三，确保运行结果足够稳定可信。门控应当拦截真实的行为回归，而非随机噪声——通过多次采样取多数投票可以在所有模型上有效降低结果波动。

触发策略的设计直接决定门控的可靠性。评测任务应当仅在可能影响 Agent 行为的文件发生变更时运行，包括系统提示词、Agent 逻辑、工具 Schema、评测集本身以及评测脚本和工作流文件。这里有一个关键细节：路径过滤器必须放在 Job 层级而非 Workflow 层级。若将过滤条件配置在 on.pull_request.paths，当工作流被跳过时，GitHub 会将关联检查保持在「Pending」状态，导致要求该检查的 PR 永久无法合并；而 Job 层级的跳过则会被 GitHub 标记为通过，允许无关 PR 正常合并。

评测脚本的核心逻辑是：对每条测试用例调用模型，检查输出是否包含必须出现的字符串、是否不包含禁止出现的字符串，统计通过率，低于阈值则以非零状态退出。评测集以 JSON 文件形式与提示词文件并排存放于同一仓库，每条用例包含输入内容、mustMention 字段（必须出现的关键词或关键词组合）以及 mustNotMention 字段（禁止出现的内容）。这种结构使得提示词修改与对应测试用例的修改可以在同一个 PR 中完成，审查者能够同时看到两者的变化。

阈值的设定不应凭直觉拍定，而应通过实测得出。在未做任何改动的分支上多次运行评测脚本，观察通过率的自然波动范围，将阈值设定在该范围下界略低的位置。temperature 和 seed 参数仅对在 supported_parameters 中明确列出这两个参数的模型有效，不能作为通用的稳定性手段。多数投票策略则适用于所有模型：对同一输入采样多次，以多数结果作为最终判定，可以显著降低单次随机性对评测结论的干扰，使阈值更具参考价值。

将评测门控纳入 GitHub Actions 的必要条件检查（Required Status Check）后，整个流程形成闭环：提示词变更提交 PR，路径过滤器识别相关文件，评测 Job 自动触发，脚本调用 OpenRouter 完成评分，通过率不达标则 Job 失败，PR 无法合并。这套机制将 LLM 行为质量从依赖人工审查的软约束，升级为与代码质量同等强度的硬约束，是 AI Agent 工程化成熟度的重要标志。

要点

• 路径过滤器必须配置在 Job 层级而非 Workflow 层级，否则工作流跳过时会导致必要检查永久挂起或静默放行，两种情况都会使门控失效
• 评测阈值应通过在未改动分支上多次运行来实测得出，而非主观设定，以避免将正常的模型输出波动误判为行为回归
• 评测集文件应与提示词文件存放在同一仓库，且只能通过经过审查的 PR 修改，确保测试覆盖与提示词变更同步演进
• 多数投票采样策略适用于所有模型，是降低评测结果随机性的通用手段，temperature 和 seed 参数仅对部分模型有效
• changes 检测 Job 本身也应被设为必要检查，防止该 Job 失败时评测 Job 被静默跳过、PR 在未经评测的情况下通过