Evals

评测 — 断言优先的 AI 评测

简介

评测会向 AI 提供输入，然后对其输出应用断言以衡量是否成功（Anthropic 的定义）。一个用例的结构为 {id, prompt, assert:[...]}。每条断言要么是确定性的（代码执行，快速且免费），要么由模型评分（由 LLM 评判）。每个用例会运行多次试验；我们报告 pass^k（所有试验均通过——这是对可靠性至关重要的 Agent 最诚实的指标）和 pass@k（任意一次试验通过）。所有流程都通过 Inference.ts 路由——按订阅计费，不提供 API 密钥调用路径，也没有外部依赖。

本方案以 Anthropic 当前的准则为基础——为 AI Agent 揭开评测的神秘面纱、定义成功标准／制定测试，以及 skill-creator 的 {text, passed, evidence} 断言约定。类型化断言层借鉴了 promptfoo 的设计，但由我们自行编写 TypeScript 实现。

时效性约定：“符合 Anthropic 的准则”是一个需要持续验证的主张，而非静态快照。在设计新的套件类或修改下方的 ## Doctrine 部分时，请重新获取 Demystifying-evals 文档，并指出其中哪些内容已超出本文所编码的准则。此操作仅供参考——报告差异，绝不自动采纳；URL 无法访问也不会阻止运行。

标准路径（v2）

工具	作用
Tools/Assertions.ts	确定性断言引擎：equals、contains、icontains、contains-all/any、regex、starts-with、ends-with、is-json、contains-json、max-length、min-length，每项都支持 not- 否定。同步执行，不调用模型。
Tools/Judge.ts	模型评分断言 llm-rubric（1–5 → 0–1，阈值）和 llm-assert（自然语言断言 → TRUE/FALSE/UNKNOWN）。强制使用结构化 JSON 判定，先给出理由再评分，使用独立的评判等级，并提供 Unknown→miss 兜底处理。
Tools/EvalRunner.ts	加载套件，针对每个用例运行待测 Agent（基于目标系统提示词进行单轮推理），应用断言，计算 pass^k/pass@k，并保存对话记录和 latest.json。
Tools/SuiteManager.ts	套件列表和饱和度跟踪。
Tools/FailureToTask.ts	将真实故障转换为用例（从 20–50 个真实故障开始构建）。

# Run a suite (USER-customization suites resolve before the skill's own)
bun run ${LIFEOS_SKILL_DIR}/Tools/EvalRunner.ts -s <suite> [-t trials] [--json]
# Sanity-check the assert engine / judge
bun run ${LIFEOS_SKILL_DIR}/Tools/Assertions.ts     # 16-case self-test
bun run ${LIFEOS_SKILL_DIR}/Tools/Judge.ts          # good-vs-bad discrimination

工作流路由

工作流	触发词	文件
RunEval	“运行评测”、“运行套件”、“评估这个”、“给输出评分”	Workflows/RunEval.md
CreateUseCase	“新建评测”、“创建套件”、“针对 X 的评测”、“我应该测试什么”	Workflows/CreateUseCase.md
CreateJudge	“编写评判器”、“llm-rubric”、“评分标准”、“评判提示词”	Workflows/CreateJudge.md
ComparePrompts	“比较提示词”、“哪个提示词更好”、“对这个提示词做 A/B 测试”	Workflows/ComparePrompts.md
CompareModels	“比较模型”、“哪个模型更好”、“更便宜的档位是否够用”	Workflows/CompareModels.md
ViewResults	“评测结果”、“得分如何”、“显示上次运行结果”、“饱和度”	Workflows/ViewResults.md
CreateScenario	“创建场景”、“多轮评测”、“场景测试”	Workflows/CreateScenario.md
RunScenario	“运行场景”、“运行多轮评测”	Workflows/RunScenario.md

套件／用例架构（断言优先）

name: my-suite
type: regression            # or capability
pass_threshold: 0.75
agent_level: medium         # agent-under-test inference level
judge_level: high           # judge != generator (Anthropic best practice)
trials: 3
# system_prompt: optional override; default = live system prompt + DA identity
cases:
  - id: descriptive_name
    prompt: "the user turn sent to the agent-under-test"
    assert:
      - type: not-contains       # deterministic
        value: "should work"
        weight: 1
      - type: llm-rubric         # model-graded, weighted for partial credit
        weight: 2
        value: "Does the output tie any done-claim to verification evidence?"
      - type: llm-assert
        weight: 1
        value: ["The output does not claim success without evidence"]
  - id: should_not_case          # balance: test should-do AND should-not
    negative: true
    prompt: "..."
    assert: [...]

与特定身份绑定的套件（例如 {{DA_NAME}} 的性情倾向）存放在 LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Evals/Suites/ 中——公开技能仅提供通用套件和示例。

Doctrine（来自 Anthropic — 编码，而非复述）

• 评估输出/结果，而非过程。 工具调用序列断言很脆弱，已降级为可选项；常规测试套件评估 Agent 产出的内容。旧版 core-behaviors 测试套件（按工具序列评分）仅作为这种反模式的示例保留——它是 v1 tasks: 文件，EvalRunner 无法运行，会将其报告为具名错误，而不是尝试运行。
• 能力从低起步（需要逐步提升）；回归目标约为 100%；通过能力测试用例后，将其纳入回归测试。
• 可靠性看 pass^k；只需成功一次时看 pass@k。
• 通过断言权重给予部分分数。应当做和不应当做的用例要保持平衡——单边评估会造成单边优化。
• **评判规范：**使用不同的评判模型，先推理再评分，强制采用结构化裁定，并提供 Unknown 兜底选项。
• 阅读记录前，绝不要相信分数——每次运行都会将完整的测试用例记录保存到 MEMORY/STATE/Evals-Results/<suite>/<run>/run.json。

与 Harness 集成

• 配置变更回归：hooks/ConfigEvalFire.hook.ts → LIFEOS/TOOLS/ConfigEvalOnChange.ts 会在定义行为的文件发生变化时，运行配置的处置测试套件（默认为可运行的 v2 测试套件 core-dispositions；可通过 LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Evals/config.json 中的 config_change_suite 覆盖——与身份绑定的测试套件位于该 USER 层，绝不放入公共树）；回归会通知 Pulse。非阻塞、按订阅计费，并经过防抖处理。
• **ISA / Algorithm：**评估测试套件是 ISA 主张证伪条件的实际形式（集成映射保存在维护者的机器上——即会话笔记，不随项目发布）。

Legacy（v1，已被取代）

v1 评分器栈（Graders/、TrialRunner.ts）和 @langwatch/scenario 路径（ScenarioRunner.ts、LifeosAgentAdapter.ts，按 API 计费）早于断言优先的重写。优先使用上面的 v2 路径。Scenario 路径会使用 ANTHROPIC_API_KEY 计费——不要将其用于主要工作。

注意事项

• **单次调用的被测 Agent 会讲述工具调用。**通过不提供工具的推理，将完整的 Agent 系统提示词传入时，Agent 会推迟作答并模拟工具使用，而不是直接回答——这会拉低“先给出答案”风格用例的表现。EvalRunner 会注入 [EVALUATION CONTEXT] no tools, answer directly 后缀来解决此问题；编写按输出评分的处置用例时，请保留它。
• judge_level 必须不同于 agent_level（Anthropic：评判者 ≠ 生成者）。默认 agent=medium，judge=high。
• **Unknown 计为未通过。**无法验证某项断言的评判者会返回 UNKNOWN，按失败计分——对回归而言较保守，对门槛检查而言则是正确做法。
• **确定性断言不花费资源；应优先使用。**只有代码检查无法捕捉的细微差别，才使用模型断言（llm-rubric/llm-assert）。
• **is-json 检查整个输出；contains-json 检查嵌入其中的片段。**不要对仅仅提到 JSON 的散文使用 is-json。

执行日志

完成任何工作流后，追加一条 JSONL 记录：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Evals","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl