评测与回归

Agent 评测不能只看最终回答是否像样。你需要同时评估路径、工具使用、成本和失败恢复。

评测维度

维度	问题
正确性	结论是否事实正确？
完整性	是否覆盖关键约束？
工具使用	是否调用了正确工具？
可复现性	失败后是否能回放？
成本	token、时间、外部 API 成本是否可接受？
安全性	是否越权或执行高危动作？

评测样例

agent-eval.ts

export type AgentEvalCase = {
  id: string;
  task: string;
  fixtures: Record<string, unknown>;
  expectedSignals: string[];
  forbiddenActions: string[];
};

export const cases: AgentEvalCase[] = [
  {
    id: "research-framework-compare",
    task: "比较 LangGraph 和 Mastra 的适用场景",
    fixtures: {},
    expectedSignals: ["状态机", "TypeScript", "人工接管"],
    forbiddenActions: ["编造 benchmark"],
  },
];

回归流程

固定模型版本、工具版本和输入数据。
运行核心评测集。
保存 trace 和摘要指标。
对失败样例做归因。
只在通过阈值后发布。

样例设计

Agent 评测样例不应只包含“正常成功路径”。建议至少覆盖：

样例类型	目的
Happy path	确认基础能力没有退化
Missing information	确认信息不足时会提问或停止
Tool failure	确认工具失败后能重试、降级或报告
Permission boundary	确认高风险动作会请求确认
Long context	确认关键约束不会在长任务后半段丢失
Adversarial input	确认 prompt injection 或恶意指令不会越权
Regression bug	确认历史故障不会再次出现

每个样例都要写清楚成功信号和禁止动作。只写“回答应该好”无法自动回归。

指标与阈值

指标	建议用法
pass_rate	端到端通过率，适合作发布闸门
critical_failures	高风险失败数量，通常应为 0
tool_precision	调用的工具是否必要且正确
schema_pass_rate	结构化输出是否符合接口
evidence_coverage	结论是否引用了足够证据
cost_per_case	每个样例平均成本
latency_p95	交互任务的尾延迟

阈值应按任务类型设定。客服问答、代码修改、研究报告、生产运维不应使用同一套门槛。

自动评测与人工评审

方式	适合	不适合
规则评测	JSON schema、禁止动作、命令结果、测试通过	开放式质量判断
LLM-as-Judge	摘要质量、引用完整性、回答风格	高风险合规结论的唯一依据
人工评审	新任务类型、主观质量、安全复盘	高频回归闸门
轨迹回放	工具链、长任务、失败恢复	只看最终文本的简单问答

最稳妥的组合是：规则评测守底线，LLM-as-Judge 辅助开放式判断，人工评审发现新型错误，trace 用于归因。

发布闸门

模型、提示词、工具 schema 或上下文策略变化时，发布前至少检查：

核心样例通过率不下降。
高风险样例没有新增 critical failure。
成本和延迟在可接受范围内。
历史失败样例没有复发。
失败 trace 已被归类，并决定是修复、接受还是延期。

如果某次变更“主观感觉更聪明”，但评测集、trace 和人工评审都没有证明，就不应直接替换线上策略。

人工评审

自动评测适合做回归闸门，人工评审适合发现新型错误。尤其是研究型、法律、医疗、金融、运维类 Agent，不应该只依赖模型自评。

参考来源

OpenAI Evals Repository：构建和复用模型评测样例的开源参考。
LlamaIndex Evaluation Documentation：RAG 与问答评测维度参考。
NIST AI Risk Management Framework：高风险 AI 系统治理和风险管理参考。