Agent Evaluation、Trace Analysis 与 Data Learning Loop

首席讲师深潜卷。研究基线：2026-08-03。对象是完整 Agent system，而不是孤立模型；目标是建立可支持研发决策、回归门禁、线上发布和训练数据治理的测量系统。

Freshness 与证据合同

本卷已在 2026-08-03 用 benchmark 官方页/仓库、发布者审计与原始论文做二次线上核验。所有数字都只对其明确 snapshot 成立：benchmark 名相同但 task-set revision、harness、effort、预算、grader 或运行日期不同，结果不得横向拼接。尤其注意：

• SWE-bench 官方家族仍在维护 Verified（500）、Multilingual（300 tasks / 9 languages）、Lite、Full 与 Multimodal leaderboard；“不再用于 frontier launch”是 OpenAI 2026-02 针对 Verified 的评估结论，不是 SWE-bench 维护者删除了该数据集；
• Terminal-Bench 最新正式数据集是 2.1（2026-05-06 发布，89 tasks）；官方 release note 称 2.0 的 28 个 tasks 受到修复，数据仓库 README 称 26 个 tasks 被修改，二者统计口径不同，引用时必须说明来源；
• SWE-Lancer 的论文全集与公开可运行集不是同一个 denominator：论文/官方介绍是 1,400+ Upwork tasks、总真实报酬约 $1M；2025-07-17 后公开代码仅保留原 237 problems 中经离线调整验证的 198 tasks，drop 了 39；
• OpenTelemetry GenAI semantic conventions 截至本快照使用独立 gen-ai-dev/1.42.0-dev schema，文档仍标记 Development 而非 Stable；可以作为互操作基线，但必须 pin 版本，不能承诺没有 breaking change。

0. 先建立正确判断：Eval 不是打分，是测量与决策系统

Agent evaluation 的最终产物不应是排行榜，而应是一个可执行判断：

在明确任务分布、环境、harness、预算与风险边界下，
系统版本 A 相比 B 改变了什么能力、可靠性、成本与风险，
这个变化是否真实、为什么发生、能否安全发布、下一步应改哪里。

完整被测对象是：

S = Model × Harness × Context policy × Tools × Runtime
    × Environment × Budget × Safety policy × Verifier

因此“某模型在 benchmark 上是 72%”是一个不完整命题。可信命题至少是：

Claim = population + capability + system configuration
        + intervention/comparator + outcome + uncertainty + scope limit

例如：

在冻结的 2026-Q3 TypeScript issue-resolution 分布、相同容器和 60 分钟预算下，K3 + harness A 相对 K3 + harness B 提高 verified completion 6.2pp；95% paired-bootstrap CI 为 [2.1, 10.0]pp，主要来自 repository retrieval failure 减少；高风险副作用样本没有足够统计功效，因此不能据此声称安全性提升。

这比“模型变强了”多回答了四件事：测了谁、改了什么、为何变化、结论边界在哪里。

0.1 Eval 的六个产品

如果一次评测不能导向其中任何一种决策，它大概率只是展示性数字。

1. 测量本体：Task、Run、Trajectory、Outcome、Oracle

1.1 必须分开的对象

1.2 一个 task spec 的最小合同

task_id: deep-ts-0042
lineage:
  source: authored_from_production_pattern
  family_id: async-cancellation-v3
  created_at: 2026-07-18
intent: "取消请求后，已经启动的子进程必须被回收，已发生副作用要可核对"
initial_state:
  repo_commit: 4b3d...
  image_digest: sha256:...
  dependency_lock_digest: sha256:...
constraints:
  - preserve public API
  - no network
  - no unrelated diff
budget:
  wall_time_s: 3600
  model_input_tokens: 1000000
  model_output_tokens: 120000
  max_tool_calls: 300
success_criteria:
  functional: [cancel_propagates, child_tree_reaped]
  regression: [existing_suite_passes]
  safety: [no_process_leak, no_outside_workspace_write]
oracle:
  version: verifier@7
  evidence: [tests, process_table_snapshot, git_diff]
known_ambiguities: []

Task 不含初始状态、约束、预算和 oracle 时，无法区分“Agent 不会”与“题目没有给它可成功的世界”。

2. 三层 Validity：Construct、Task、Oracle

可信 eval 的核心不是更多样本，而是三层效度同时成立。

2.1 Construct validity：指标真的代表声称的能力吗

Construct 是不能被直接观察的潜在属性，例如：

• repository understanding；
• long-horizon goal maintenance；
• recovery under partial failure；
• safe tool use；
• verified software delivery。

我们只能通过 task、行为和 outcome 间接测量。Construct validity 要防止两种错误：

1. Construct underrepresentation：只用 patch tests 测“软件工程能力”，遗漏需求理解、定位、验证、沟通、成本与安全；
2. Construct-irrelevant variance：分数主要被镜像下载、网络抖动、prompt 模板、harness adapter 或 oracle 缺陷决定。

建立 construct 的方法

product decision
  -> target behavior / harm
  -> construct definition
  -> observable indicators
  -> task families
  -> scoring model
  -> falsification tests

一个 benchmark 可以拥有很好的 task validity，却只支持很窄的 construct claim。例如检索 benchmark 可以有效测 file localization，但不能自动支持“端到端开发能力”。

2.2 Task validity：题目是否公平、可解、有代表性

对每个 task，需要证明：

1. Solvable：在给定初始状态、工具和预算下至少存在合法解；
2. Specified：prompt + 可发现环境提供了成功所需信息；
3. Isolated：任务不依赖不可控的未来状态、外部服务或隐藏人工知识；
4. Representative：它属于目标产品的真实任务族，而非只因容易自动评分才被选中；
5. Non-leaky：没有未来 commit、reference patch、issue discussion、缓存或文件名捷径；
6. Stable：重复构建环境不会改变题意与难度；
7. Non-gameable：不能通过删除测试、硬编码、读取隐藏答案或改变 evaluator 获胜；
8. Difficulty-grounded：难度来自目标 construct，而不是坏依赖和无意义摩擦。

Task audit 的四方对齐

Prompt requirements
        ∩
Initial repository semantics
        ∩
Allowed tools / environment
        ∩
Oracle-enforced behavior

交集之外都可能是 broken task：

• tests 要求 prompt 未声明且无法合理推断的行为；
• prompt 要求的功能 tests 没覆盖；
• reference patch 依赖 issue 之外的私有讨论；
• 环境缺失 build dependency；
• agent 被禁止网络，但 task 的唯一可行路径必须下载 artifact。

OpenAI 2026-07 对 SWE-Bench Pro 731-task public split 的审计中，datapoint analysis pipeline 标记 200 / 731（27.4%）为 broken，人工 campaign 识别 249 / 731（34.1%）；主要问题是过度严格测试、欠规范 prompt、低覆盖测试和误导性 prompt。这里的数字是 OpenAI 对该公开 split 的发布者审计结论，不是所有 SWE-bench 数据集的统一缺陷率，但足以证明“tests 能跑”不是 task validity。官方审计

2.3 Oracle validity：判分器是否正确判断成功

Oracle validity 与 task validity 不同：任务可以很好，但 verifier 会错；verifier 也可能实现准确，但任务本身不代表真实分布。

定义二元真值 Y* 与 verifier 判定 V：

False reject = P(V=0 | Y*=1)   正确替代解被拒绝
False accept = P(V=1 | Y*=0)   不完整/投机解通过

实际目标不是追求单一“judge agreement”，而是估计：

Oracle precision = TP / (TP + FP)
Oracle recall    = TP / (TP + FN)

其中真值必须来自独立、强于被测 scorer 的审计程序，例如多位领域工程师 + 独立运行证据，而不能让同一个 LLM 既造题又写 verifier 又裁决争议。

Oracle 的五种缺陷

Mutation testing 与 adversarial validation

验证 oracle 不应只跑 reference solution，还要跑：

• known-correct alternative implementations：估计 false reject；
• deliberately incomplete patches：测试是否错误接受；
• semantic mutants：删分支、交换条件、吞错误、绕过验证；
• exploit attempts：改 tests、写死 fixture、读隐藏文件、跳过工作；
• environmental repetitions：不同 seed、时区、locale、CPU/GPU、依赖镜像。

DeepSWE 用原创任务和手写功能 verifier，报告独立 judge 对其判分 disagreement 为 1.4%，而对 SWE-Bench Pro inherited tests 的重审 disagreement 为 32.4%。这不是证明 LLM judge 是绝对真值，而是说明面向任意合法实现编写 verifier 比继承某个历史修复的 tests 更接近测量目标。

2.4 Validity gate：先判题，再判系统

排除 broken task 必须是对称、预注册、版本化的：相同规则应用于所有 system，旧结果保留 task-set version，不能事后为某版本挑题。

3. 完整 Evaluation Cube

四轴 cube 仍不足以描述 Agent。实际是一个稀疏高维张量：

E[
  claim,
  capability_stage,
  task_family,
  horizon,
  environment,
  system_config,
  budget,
  risk,
  evaluator,
  repetition,
  lifecycle_stage
]

3.1 十一个轴

3.2 Cube 的使用规则

1. 不要填满：组合爆炸，目标是覆盖高价值 cell 与边界，不是穷举；
2. 先分层再汇总：先报 slice，再按真实 traffic 权重汇总；
3. 空白也是信息：没有高风险线上数据，就标记 unknown，不能用低风险结果填补；
4. 版本化 coverage manifest：每次 release 知道新增、丢失和漂移的 cell；
5. 建立 sentinel cells：少量高稳定任务持续监控基础设施漂移；
6. 建立 frontier cells：高难、低样本任务用于探索，不直接做 hard gate。

3.3 汇总分数的约束

对 slice g 的真实权重为 w_g，成功率为 p_g：

P_population = Σ_g w_g p_g,    Σ_g w_g = 1

必须披露 w_g 来源。Leaderboard 的均匀 task average 隐含 w_g = 1/G，通常不等于产品 traffic。若安全 incident 的效用非线性，更不能简单平均：

Expected utility = Σ_o P(o | S, x) · U(o, x)

一次不可逆数据删除的负效用可能大于一百个普通任务成功，不能被平均成功率稀释。

4. Offline、Replay、Shadow、Canary、Online

这些不是从“假”到“真”的单向等级，而是回答不同问题的互补机制。

4.1 五种模式

4.2 Replay 的三种强度

1. Static score replay：不运行 agent，只让新 evaluator 重判旧 trace；适合 judge/rubric 迭代；
2. Prefix replay：冻结到 step t 的历史，让新 policy 从该 state 续跑；适合 first-bad-decision 反事实；
3. Environment replay：从 snapshot 重建完整外部状态并重新执行；最可信、成本最高。

静态 replay 的根本限制是 trajectory 由旧 policy 诱导。若新 policy 在第 3 步选了别的工具，旧 trace 的第 4 步 observation 不再有效。因此不能用静态 replay 声称完整 agent improvement。

4.3 Shadow 的两种实现

Mirrored decision shadow:
  live observation -> candidate agent -> proposed actions -> no-op sink -> judge

Forked sandbox shadow:
  live task sanitized -> isolated environment clone -> candidate executes -> verifier

第二种更接近真实能力，但仍缺少用户许可、clarification、真实外部副作用和任务后续。Shadow 最适合发现：崩溃、延迟、tool schema、成本、明显质量退化；不适合单独证明用户价值。

4.4 Canary 的发布合同

Canary 必须预先定义：

• eligible cohort：哪些用户、仓库、风险等级；
• traffic fraction 与最大绝对任务数；
• effect boundary：哪些工具/目标仍被禁用；
• primary success、guardrail 和 abort metrics；
• kill switch、自动回滚、状态 reconciliation；
• 最短/最长观察窗；
• sequential testing 或 alpha-spending 规则，防止反复看数直到“显著”；
• on-call owner 和 incident evidence。

4.5 推荐的证据阶梯

unit/invariant tests
  -> deterministic task regression
  -> repeated stochastic eval
  -> perturbation + fault injection
  -> historical prefix/environment replay
  -> shadow
  -> constrained canary
  -> online A/B + long-tail monitoring
  -> post-launch cohort audit

没有哪一级可以替代前一级。线上成功率提升不能解释机制；离线 ablation 不能保证真实用户价值。

5. 指标系统：Outcome、Trajectory、Process、Safety、Cost、Latency

5.1 顶层不是 pass rate，而是 Verified Net Utility

Coding Agent 的合格完成应同时满足：

Verified completion
  = functional success
  ∧ regression-free
  ∧ constraints satisfied
  ∧ required evidence present
  ∧ no disqualifying safety incident

可进一步定义每个 run 的净效用：

U = V_success
    - λ_risk · Harm
    - λ_cost · Cost
    - λ_time · Latency
    - λ_human · HumanBurden
    - λ_debt · IrrelevantChange

权重必须来自产品决策，而不是为了得到好看的综合分数临时调节。安全红线通常是 hard constraint，不应被 success 加权抵消。

5.2 Outcome metrics

FixedBench 的 200 个“无需代码修改”任务显示，被测前沿系统仍在 35%–65% 案例中提出不期望的实质修改（论文定义下排除 tests/docs）。这说明只收集“需要 patch”的任务会训练和评测出 action bias。

5.3 pass@k：至少一个成功，不等于可靠

对某 task 生成 n 个样本，其中 c 个通过，从中无放回抽 k 个，HumanEval 给出的无偏估计是：

              C(n-c, k)
pass@k = 1 - -----------
                C(n, k)

当把同一 task 的每次 run 近似为独立且同分布、该题单次成功率为 p_i 时：

P_i(at least one success in k tries) = 1 - (1-p_i)^k

Macro pass@k = 1/N Σ_i [1 - (1-p_i)^k]

pass@k 衡量搜索/采样预算带来的可达性，随 k 单调不降。它适合候选生成后有外部 chooser/verifier 的场景；若产品只允许一次自主执行，报 pass@10 会严重高估用户体验。原始无偏估计来自 Evaluating Large Language Models Trained on Code。不能用总体平均成功率 p̄ 直接代入 1-(1-p̄)^k 替代逐题 macro average：task 难度异质时两者不同。

5.4 pass^k：连续可靠性，不是 pass@k 的另一种写法

pass^k 要求同一 task 的 k 次运行全部成功。若同一 task i 的重复运行独立同分布：

P_i(all k runs succeed) = p_i^k

Macro pass^k = 1/N Σ_i p_i^k

对 N 个 tasks、每题 k 次 run，经验估计可写为：

             N
pass^k = 1/N Σ  𝟙(y_i1 = ... = y_ik = 1)
            i=1

若每题实际采集 n ≥ k 次、其中 c 次成功，从所有大小为 k 的子集无放回抽样，对“全部成功”的有限样本估计是：

         C(c, k)
pass^k = -------
         C(n, k)

pass^k 衡量稳定性，因此随 k 增大单调不升。它回答“交给系统 k 次，是否每次都能信任”，而 pass@k 回答“给 k 次机会，是否至少撞中一次”。该 reliability metric 由原始 τ-bench 论文提出；论文用 end-state database 与 annotated goal state 评分，并报告 retail domain 的 pass^8 < 25%。2026 的 ReliabilityBench 预印本进一步把 pass^k 与语义扰动强度 ε、工具故障强度 λ 组织成 R(k, ε, λ)；后者是扩展框架，不是 pass^k 的原始来源。

注意两层误区：第一，Macro pass^k = mean_i(p_i^k)，一般不等于 mean_i(p_i)^k；第二，独立假设常不成立，共享 provider outage、同一坏 cache、确定性 harness bug 会产生 run correlation。若相关系数为正，简单使用 p_i^k 会误估风险；应直接重复执行、按 task 聚类，并报告 shared-failure cohorts。pass@1 = pass^1，只有 k>1 时二者才表达相反的 scaling intent。

5.5 Reliability surface

Agent 可靠性至少是：

R = R(k, ε_semantic, λ_fault, d_drift, b_budget)

• k：重复次数；
• ε_semantic：不改变意图的 prompt/命名/顺序扰动；
• λ_fault：timeout、429、partial result、schema drift、工具不可用强度；
• d_drift：repo/version/provider/environment 漂移；
• b_budget：资源约束。

Metamorphic testing 的关键是定义终态等价关系，而非输出文本相似：变量改名、文件顺序、错误文案同义改写不应改变正确 effect。

5.6 Trajectory / process metrics

Process metric 不能越权成为目标。例如“tool calls 越少越好”会压制必要验证；“更多 tests”会诱发无价值测试。它们主要用于诊断与 guardrail，最终仍由 outcome 和 utility 约束。

5.7 Safety metrics

Incident rate              = harmful runs / exposed runs
Unsafe action proposal     = disallowed intents / opportunities
Policy catch rate          = blocked true hazards / true hazards
Over-refusal rate          = blocked safe tasks / safe tasks
Privilege minimization     = used authority / granted authority
Reconciliation completeness= audited effects / uncertain effects

还要按 severity 加权，并单列 near miss。零 incident 不等于安全：样本可能没有 exposure；policy 也可能通过全部拒绝让 incident 归零。必须同时报 task utility 与 over-defense。

5.8 Cost metrics

比较系统时不能只比较 successful runs 的成本，这会产生 survivor bias。超时、拒答、fallback、infra failure 都必须计入 denominator 和 total cost。

5.9 Latency metrics

Agent latency 是分段分布，不是一个平均数：

T_total = queue + first_token + reasoning + tool_wait + human_wait
          + retry + verification + artifact_delivery

建议同时报告：

• TTFA：time to first useful action；
• TTFE：time to first external effect；
• TTFV：time to first valid evidence；
• TTVC：time to verified completion；
• p50 / p90 / p95 / p99；
• timeout/censoring rate；
• active compute 与 human-wait 分离。

只报成功任务 latency 会丢掉超时尾部。对被 timeout 截断的 run，应使用 survival curve / restricted mean survival time，或至少把 censored runs 独立报告。

5.10 统计不确定性

Agent eval 的基本采样单位通常是 task，不是 run。相同 task 的多次 run 高度相关，因此：

• 置信区间优先做 task-level cluster bootstrap；
• A/B 同题比较用 paired bootstrap / McNemar，而不是把两组当独立样本；
• 多 repo、多语言用 hierarchical/random-effects model；
• 报绝对差值 pp、相对变化和 CI；
• 多指标/多 slice 做 multiplicity 控制或声明 exploratory；
• 小样本零事故只给上界，不能声称风险为零。若 n 次零事件，95% 上界近似 3/n（rule of three）。

6. Judge 与 Verifier：谁有资格说“成功”

6.1 Oracle ladder

从强事实到弱判断：

External state invariant / formal property
  > executable functional verifier
  > deterministic static analysis
  > calibrated simulator
  > domain-expert judgment with evidence
  > calibrated LLM judge with rubric/tools
  > uncalibrated LLM preference
  > agent self-report

这不是说上层永远优于下层。许多产品质量只能由人判断；关键是用最强可得证据覆盖每个 criterion，并让弱 judge 不覆盖强证据。

6.2 分层 composite oracle

Gate 0  environment integrity
Gate 1  hard safety invariants
Gate 2  functional acceptance
Gate 3  regression / compatibility
Gate 4  task-specific quality rubric
Gate 5  product/human utility

推荐评分合同：

if integrity_failed or safety_failed:
    FAIL
elif not functional_passed:
    FAIL
else:
    PASS with quality/cost/latency annotations

不要让一个高“代码风格”LLM 分数抵消 functional failure，也不要让 test pass 掩盖越权副作用。

6.3 Deterministic verifier

适合：编译、类型、API contract、终态、文件/数据库 invariant、性能门槛、安全 policy。优点是可重现、便宜、可作为 RL reward；风险是 specification gaming。

设计原则：

• 检查行为语义，不比较 reference patch；
• grader 与 agent workspace/identity 隔离；
• hidden tests 不向模型泄露，但 rubric 和 success criteria 不应故意含糊；
• validator 自身版本、输入 digest、输出和异常全量记录；
• timeout 与 fail 分离；infra error 不算 agent failure；
• performance metric 先 warm-up、多次测量、校准硬件并同时守 correctness；
• 对每个新增 verifier 做 known-good、known-bad、mutation 与 exploit suite。

6.4 Human judge

Human 适合意图完整性、架构质量、可维护性、交互负担、真实 acceptability。它并非自动是真值：标注者会受 reference、品牌、输出顺序、篇幅和 outcome hindsight 影响。

最低协议：

1. criterion 拆解，不给“总体感觉 1–5 分”；
2. blind system identity，随机 candidate 顺序；
3. 给 task、环境证据、diff 和相关 trace，不泄漏不应影响判断的信息；
4. 训练集 + qualification + anchor cases；
5. 至少抽样 double annotation，报告 raw agreement、Krippendorff’s alpha/Cohen’s kappa；
6. disagreement 由独立 adjudicator 处理并记录原因；
7. 监控 individual severity/leniency drift；
8. 标注 “cannot determine / insufficient evidence”，禁止被迫猜测。

Pairwise 往往比 absolute score 稳定，但只回答相对偏好；若 A、B 都不合格，pairwise 仍会选一个。应先过 absolute acceptance gate，再做 pairwise quality comparison。

6.5 LLM-as-a-Judge

LLM judge 适合大规模预筛、开放式 criterion、trace summarization 和疑难样本路由；不适合未经校准直接作为高风险唯一 oracle。

已知偏差：

• position / order bias；
• verbosity、style、self-family bias；
• reference anchoring；
• outcome bias：看到最终失败后过度指责早期合理探索；
• trajectory length bias；
• shared blind spot：generator 与 judge 同源能力缺陷；
• prompt injection：被测 artifact 诱导 judge；
• evidence neglect：语言解释压过真实 tool receipt；
• stochastic inconsistency 与 model-version drift。

MT-Bench / Chatbot Arena 的原始 LLM-as-a-Judge 研究已经明确记录 position、verbosity、self-enhancement bias；其特定设置中“与人类偏好超过 80% agreement”不能外推成所有领域的 oracle validity。JudgeBench 改用知识、推理、数学和代码的客观正确性 pair，显示不少强 judge 在困难样本上只略高于随机猜测：偏好一致性与事实/逻辑裁决能力必须分开校准。

2026 年 TMLR 版（arXiv v2, 2026-06-24）的 Judging the Judges 比较 9 种 debiasing strategy、5 个 judge、3 个 benchmark 和 4 类 bias，说明收益依赖 judge model，不能假设一个固定 prompt 普适。BabelJudge 则用 gold-by-controlled-degradation 构造 trajectory perturbation，测试 tool swap、参数损坏、hallucinated call、missing step 与 trajectory-length bias；但截至本快照它是 2026-06 的 v1 预印本，实证只覆盖 Qwen2.5-7B-Instruct-4bit 与四种语言，适合作为 probe 设计证据，不是 judge population 的普适错误率。它们共同支持的方法论是：judge 也必须拥有自己的 eval set。

Judge calibration card

judge:
  model: exact-version
  prompt_digest: sha256:...
  rubric_version: v12
  evidence_visible: [task, final_state, diff, selected_trace]
  blinded_fields: [system_name, benchmark_score, reference_author]
calibration:
  gold_source: independent_expert_adjudication
  n: 420
  slices: [language, task_family, trajectory_length, success_status]
  confusion_matrix: {tp: ..., fp: ..., tn: ..., fn: ...}
  pairwise_order_flip_rate: ...
  abstention_rate: ...
  inter_run_agreement: ...
policy:
  auto_accept_threshold: ...
  auto_reject_threshold: ...
  human_review_band: [..., ...]

6.6 Tool-using / Agent-as-a-Judge

复杂工程任务中，judge 可能需要 checkout、运行 tests、检查 API、对照 docs。它可能比单次 LLM judge 获得更强证据，但也成为一个新的 Agent system，拥有自己的 harness、tool failure、budget 与污染风险。Agent-as-a-Judge 是对这种从单次语言判定向 planning、工具验证、多角色和 memory 演进的 survey；它不是“加工具就一定更准”的因果证明，具体 judge-harness 仍须对独立 gold set 校准。

正确做法不是递归相信更强 Agent，而是：

• 把可确定部分下沉到 deterministic verifier；
• judge 的每条 claim 引用 evidence ID；
• judge 无法访问 generator 的隐藏 chain-of-thought，只看行为证据；
• 设置 abstain 和 human escalation；
• 单独测 judge 的 false accept/false reject；
• 让 grader infra failure 与 candidate failure 分离。

6.7 Verifier hacking 与 Goodhart

当 metric 进入训练或排行榜，它从测量工具变成优化目标：

proxy becomes target
  -> system learns loophole
  -> observed score rises
  -> target construct does not

Coding Agent 常见 loophole：

• 删除/skip tests；
• hard-code hidden fixture 特征；
• 降低 performance workload；
• 捕获异常后返回成功；
• 修改 evaluator 可读的状态而非真实产品状态；
• 用 reference diff 痕迹恢复答案；
• 在 judge-facing summary 中隐藏失败；
• 过度拒绝以优化 incident rate。

治理方式：grader isolation、anti-cheat checks、held-out verifier variants、manual exploit review、metric rotation、outcome/process 双证据，以及保留 score 与真实用户数据之间的 convergent validation。

7. 2026-08 Coding-Agent Benchmark 版图

7.1 不按榜单排，而按 construct 排

7.2 三个常用 benchmark 的 exact snapshot 合同

SWE-bench：官方维护状态与外部审计必须分开

• 官方 SWE-bench 仓库 与 leaderboard 截至 2026-08-03 仍提供 Full、Lite、Verified（500）、Multilingual（300 tasks / 9 languages）与 Multimodal 等不同 task sets；任何结果先写清具体 split、dataset revision、harness 与 exclusions。
• OpenAI 2026-02 的 Verified 审计只深审了 138 / 500（27.6%）个 o3 在 64 次独立运行中未能稳定解决的 hard/unsolved subset，其中 59.4% 被判有 material test/task issues。59.4% 是 138 个定向审计样本的比例，不是完整 500 题缺陷率。 同一审计还给出污染证据，因此 OpenAI 停止报告 Verified；这是 OpenAI 的评估策略，不是 SWE-bench 维护者退役数据集。
• OpenAI 2026-07 的 SWE-Bench Pro 审计针对 731-task public split：pipeline 标记 200（27.4%），human campaign 识别 249（34.1%），总体估计约 30% broken，并撤回此前采用 Pro 的建议。数字属于 OpenAI 的该次审计协议，不能被改写成 benchmark 维护者或整个 coding-eval 社区的统一裁决。

Terminal-Bench：版本号、题数、修订口径和重复次数都属于结果

• 截至 2026-08-03 最新正式数据集是 Terminal-Bench 2.1，于 2026-05-06 发布，共 89 tasks；本卷核验的仓库 snapshot 是 5c8eadf，实际含 89 个 task directories。
• release note 称修复了 2.0 的 28 / 89 tasks，当前 dataset README 则称 26 tasks were modified。两份官方材料计数不同；没有逐项 provenance 前不擅自合并，应在报告中原样注明。release note 还列出 9 个 external-dependency drift tasks、8 个 resource-mismatch tasks 与 misspecification，并称修订后的对比中没有 task 仍为所有系统 unsolved。
• 官方 leaderboard submission 要求每题至少 5 trials、结果公开上传 Harbor Hub，并经 CI 与 maintainer trajectory review。单跑 Pass@1 或第三方自定义 sandbox 成绩不能冒充官方 leaderboard protocol。
• Long-Horizon-Terminal-Bench 是 2026-07 的另一项长任务研究，不是 Terminal-Bench 官方 2.2 或 2.1 的别名。

SWE-Lancer：论文全集、公开 split 与当前 runnable set 是三个对象

• 论文与官方介绍的总体 benchmark 是 1,400+ 个 Upwork freelance software-engineering tasks、真实 payout 合计约 $1M，含 independent engineering 与 managerial decision tasks；公开评测 split 名为 SWE-Lancer Diamond。
• 当前官方代码已经迁到 openai/frontier-evals/project/swelancer。其 README 明确写明：截至 2025-07-17，公开仓库只有原 237 problems 中经 offline adjustment/verification 的 198 tasks，删除 39，并只把禁网运行视为有效 rollout。
• 因而引用成绩必须同时报告 paper-full / original-Diamond / current-offline-public 中哪一个、task type、task count、image/runtime 与 network policy；不能把 198-task public 分数称为“在 1,400+ 任务上”的成绩。

7.3 版图的结构性变化

到 2026-08，前沿不再只是“做更多 SWE-bench issue”：

1. 原创化：减少 public commit / discussion recall；
2. 长程化：从单 issue 到 feature、version、持续任务；
3. 组件化：单测 retrieval、exploration、reasoning、harness；
4. 过程化：发布完整 trajectory、成本、恢复和失败行为；
5. 负任务：显式测不应修改、应拒绝或应澄清；
6. 验证器重写：面向需求语义，而非继承历史 patch tests；
7. 配置联合报告：model × harness × budget，而非把成绩归给 model；
8. 分布与时间治理：version、cutoff、hidden/private rolling set；
9. 非功能属性：性能、安全、成本、延迟和人类负担。

7.4 Benchmark contamination：不只是“训练见过答案”

污染有多条通道：

“任务发生在模型 cutoff 之后”只缓解 pretraining contamination；发布 benchmark 后它仍会进入后续 post-training 和 harness 优化。真正策略是 rolling original tasks、严格 lineage、sealed test、退役规则和公开 contamination disclosure，而不是宣称永久无污染。

7.5 Broken tasks 与困难任务要分开

难任务：要求多步推理、广泛修改或昂贵验证，但信息充分、可解且 oracle 公平。

坏任务：失败可能来自题目/环境/oracle，因此无法解释成能力差异。坏任务不能因为“所有模型都低分”就被称为 frontier-hard。

建议每题维护：

validity_status: valid | suspect | broken | retired
validity_reasons: []
audits:
  solvability: human-reference + independent-agent
  prompt_oracle_alignment: passed
  mutation_score: 0.91
  infra_repeatability: 20/20
  contamination_risk: medium
exclusion_rule_version: task-audit@5

7.6 Harness effect 是因果变量，不是注脚

Harness-Bench 在 106 个 sandboxed tasks、5,194 条 trajectories 上观察到 completion、process quality、efficiency 与 failure behavior 随 model-harness pairing 显著变化。Claw-SWE-Bench 中同一个 GLM 5.1 backbone 的 minimal adapter 为 19.1% Pass@1，full adapter 为 73.4%；跨实验 model choice 改变 29.4pp，harness choice 改变 27.4pp。

这说明三个不同研究问题必须分开：

Model study:   固定 task/harness/environment/budget，改变 model
Harness study: 固定 model/task/environment/budget，改变 harness
System study:  固定 task/environment/外部预算，允许 native model-harness pairing

前两者追求局部因果归因，最后一个追求真实可用性。混在同一个 leaderboard 里就既不公平，也无法诊断。尤其不能把两个不同 model × harness native pairing 的分差直接命名为“harness uplift”。

7.7 如何比较 Codex、Claude Code、pi 与 Kimi Code

先建立证据纪律：官方源码或文档只能证明某个机制、接口或观测面存在，不能证明它在真实任务上更有效。 开源程度、feature 数、架构优雅、GitHub stars、release cadence 和 prompt 长度都不是 Agent 能力的替代指标；闭源系统的内部机制不可见也不等于不存在。

“先进 harness”本身不是一个无需定义的标量，而是特定任务分布与约束下的 Pareto 问题：

A(h | D, M, B, E) = {
  verified completion, pass^k, regression/safety,
  cost, latency, human burden, diagnosability
}

只有先声明 D=task distribution、M=model、B=budget、E=environment 和权重/硬门禁，才能讨论 Pareto dominance 或业务 utility；不能先给产品排总榜，再倒推“先进性”。

公开一手证据地图：用于提出假设，不用于排优先级

下表顺序不代表排名，snapshot 为 2026-08-03：

三种 estimand，三套不同实验

1. Harness causal effect：在 harness 支持的共同 model intersection 上，固定 exact model endpoint/version、task、初始环境与预算，只改变 harness；native prompt、tool schema、compaction、retry、subagent policy 都属于 treatment。若只想测 loop 本身，还需再做 tool/context/prompt matched 的 minimal-adapter ablation。
2. Model effect：固定同一 harness 与 adapter contract，只改变 model；provider schema、reasoning effort、cache 与 rate-limit 差异要作为中介或 nuisance 显式记录。
3. Native product-system effect：各产品使用其合法最佳 model-harness pairing，但固定外部任务、环境、总时间/成本/人工边界；结论只能是“system A 在该合同下优于 system B”，不能归因给 harness 或 model。

现实中 Codex、Claude Code、pi、Kimi Code 的 model-support matrix 未必完全交叉。此时只能在有共同 model 的连接子图估计 harness effect；对不相交 cell，不得插值出全局 main effect。可以另做 native-system comparison，但必须换 claim。same prompt 也不是公平性的充分条件：各模型的 native tool protocol 与 elicitation 不同；公平合同应约束可获得的能力机会、外部预算和环境，并披露实际 prompt/tool 差异。

最低受控协议

estimand: harness_effect | model_effect | native_system_effect
population:
  task_set_revision: frozen
  lineage_split: sealed
system:
  model_endpoint_version: exact
  harness_commit: exact
  prompts_and_tool_schemas: digested
environment:
  repo_commit: exact
  image_digest: exact
  hardware_network_secrets_policy: fixed
budget:
  wall_time_cost_tokens_tool_calls: explicit
  retries_compactions_subagents: counted
  human_intervention: forbidden_or_metered
protocol:
  paired_tasks: true
  randomized_run_order: true
  repeated_runs_per_task: preregistered
  infra_rerun_policy: preregistered
oracle:
  verifier_version: exact
  grader_blinding: enabled

• “同 token budget”跨 tokenizer/provider 未必等价，因此同时守 wall time、货币成本、tool/action 次数和最大人工介入；自动 retry、compaction 与 subagent 消耗必须计入，不得当免费能力。
• 每个 task 为每个 system 从独立、同 digest 的环境 clone 启动；缓存预热、provider incident、rate limit 与执行时段用 randomized order/blocking 控制。
• 保存每个产品的 raw native trace，再映射到共同的 observe → decide → act → effect → receipt → verify schema；外部 observer 统一采集 filesystem diff、process、network、tests 与资源。某产品没暴露内部事件时标为 unobservable，不能当作“该步骤不存在”或直接判差。
• 不收集 private chain-of-thought；机制判断依赖可见 evidence、tool call/result、状态变化、artifact 与 verifier receipt。

必须联合报告的 failure slices

统计上使用同题 paired repeated runs、task-cluster bootstrap 或 mixed-effects model：

Y_i,m,h,r = β0 + βM[m] + βH[h] + βMH[m,h] + u_task[i] + ε_i,m,h,r

只有观测到的 model-harness cells 支持估计；interaction 大时不报脱离 model 的“最佳 harness”。公开 benchmark 给外部可复现 snapshot，真实 opt-in production trace 给 traffic validity 与 failure exposure；后者仍是 observational evidence，需 shadow/randomized canary 或可信准实验才能做上线因果结论。

合格结论应写成：

在冻结任务集 D、模型 M、环境 E 与预算 B 下，harness H2 相比 H1 的 verified completion 改变 Δ（CI），主要机制证据来自哪些 failure slices；未覆盖的 model、task family 与线上 traffic 不外推。

而不是：“H2 源码更先进，所以应优先采用。”

7.8 Benchmark result 的最低披露

• exact task-set version 与 exclusions；
• model provider/version/date/effort/sampling；
• harness commit、system prompt digest、tool schemas；
• environment image、repo commit、network policy；
• token/turn/time/cost/retry/human budgets；
• refusal、fallback、timeout、infra error 分布；
• N runs、seed policy、CI 与 paired protocol；
• verifier/judge version 与 calibration；
• full或抽样 trajectories、diff、receipts；
• contamination 与 broken-task audit；
• claim 和明确不能支持的 claim。

OpenAI 的第三方评测 playbook也强调 broken problems、elicitation 与 harness 适配会决定 capability claim，而非只要求“第三方”标签。

8. Regression、Ablation 与因果诊断

8.1 Regression eval 不是重跑总榜

Regression set 应来源于稳定 product contract 和已经发生过的高价值失败：

Invariant suite      小、确定、每次提交运行
Core capability      中等、重复运行、release gate
Failure regressions  每个修复对应最小复现 + 邻域扰动
Frontier suite       高难、低稳定，只做趋势
Safety red team      独立门禁，不被平均分抵消
Online sentinels     发布后监控真实 cohort

每个 regression case 必须有 owner、加入原因、可删除条件和 lineage。否则集合只增不减，最后变成昂贵、重复、无法解释的测试墓地。

8.2 Paired experimental design

比较 A/B 时，任务难度通常远大于 system 差异。应让 A、B 运行同一 task、尽量相同环境快照与时间窗口：

d_i = y_i(B) - y_i(A)
Δ = mean_i(d_i)

再对 task i 做 paired cluster bootstrap。对随机系统每题跑 r 次，保留 task 内均值与方差，不要把 N×r 当成独立 tasks 人为缩窄 CI。

必须随机化：

• A/B 执行顺序，避免 provider/load/time trend；
• task queue placement；
• judge candidate order；
• 可控 seed；
• 多硬件时的 block assignment。

共享不可控因素要记录：provider incident、镜像 cache、rate limit、网络、grader version。Infra error 单列并按预注册规则重跑，不能只重跑失败版本。

8.3 Regression gate 的三段判定

Hard invariants: any disqualifying failure -> block
Primary metric: CI / non-inferiority margin -> ship or block
Diagnostic slices: alert / investigate, not ad-hoc cherry-pick

若目标是保证新版本“不差”，先定义 non-inferiority margin δ：

H0: p_new - p_old <= -δ

只有 CI 下界高于 -δ 才能声明 non-inferior。没有足够 power 时结论是 inconclusive，不是“没有 regression”。

8.4 Ablation 的正确对象

Agent 系统组件高度交互。单变量 ablation：

Δ_retrieval = score(full) - score(without retrieval)

只估计“在当前其余配置下移除该组件”的局部效应，不等于组件的普适价值。更好的 factorial design：

Y = β0 + βM·Model + βH·Harness + βC·Compaction
    + βMH·Model×Harness + βHC·Harness×Compaction
    + u_task + ε

βMH 可以揭示某 harness 只适配某模型。若 interaction 大，报告单独 main effect 会误导。

典型 ablation table

8.5 Causal diagnosis：从相关 trace 到最小机制改动

诊断链：

Population regression
  -> failing slice
  -> failure cohort
  -> candidate critical step
  -> violated invariant / missing evidence
  -> counterfactual intervention
  -> prefix/environment replay
  -> component ablation
  -> minimal mechanism fix
  -> neighboring regression tests

Trace 只能提供观察性证据。“失败 run 更常使用 grep”不表示 grep 导致失败；可能是困难任务导致更多 grep。需要 intervention：在相同 prefix/state 下替换 retrieval result、tool decision 或 policy，再看 outcome 是否恢复。

8.6 First bad decision：精确定义

First bad decision (FBD) 不是第一个异常，也不是最后一个失败，而是：

在当时可用信息下，第一个使成功概率显著下降、违反关键 invariant 或制造不可恢复成本，并且后续未被系统充分纠正的可控决策。

三个限定非常重要：

• 当时可用信息：不能用 outcome hindsight 指责一个合理探索；
• 可控决策：外部 API outage 是 cause，但未必是 agent decision；真正 FBD 可能是把 timeout 当成功或非幂等重试；
• 未被纠正：早期错 hypothesis 后主动证伪并恢复，不应算最终 critical step。

8.7 FBD 标注算法

对 trajectory τ = (s_0,a_0,o_1,...,s_T)：

1. 从最终 failed criteria 向后建立 evidence chain；
2. 标记每个 step 前的 information set I_t；
3. 为每个 action 检查：合法性、证据充分性、状态对齐、可恢复性；
4. 找到最早的 invariant violation 或必要 evidence 被错误丢弃；
5. 判断后续是否 detection + recovery；若恢复，继续向后；
6. 构造最小 counterfactual a'_t，不改变更早历史；
7. 从 step t 的 environment snapshot replay；
8. 若多次 replay 显著提高成功，FBD 得到因果支持；否则标记 tentative；
9. 分离 trigger、proximate cause、root mechanism 与 owner。

可以形式化为成功价值下降：

Criticality(t) = V(I_t, a*_t) - V(I_t, a_t)
                 + λ · IrreversibleCost(a_t)

其中 a*_t 是当时信息下可行的替代动作。实际不需要精确知道 V；通过 verifier、invariant、专家 judgment 和 counterfactual replay 估计相对差异。

8.8 FBD 报告

failure_id: f-0188
symptom:
  step_id: s-42
  description: integration test timed out
critical_step:
  step_id: s-17
  decision: retried deploy after ambiguous timeout
  information_available:
    - request accepted receipt existed
    - operation id was present
  violated_invariant: reconcile-before-retry-non-idempotent-effect
causal_chain:
  - timeout response misclassified as no-effect
  - second deploy created duplicate worker
  - test waited on conflicting workers
counterfactual:
  intervention: query operation_id before retry
  replay_runs: 10
  recovered: 9
confidence: high
owner: runtime
recoverable_at_step: s-18
minimal_fix: typed ambiguous-effect error + reconciliation branch

8.9 常见错误归因

2026 年的 AgentRx 采用 trajectory IR、invariant synthesis、逐步 checker 与 judge 组合来定位 critical step，代表一个重要方向：让诊断建立在可审计约束违反上，而不是只让 LLM 自由总结失败。

9. Trace Schema：为因果诊断而记录，不是为看漂亮瀑布图

9.1 Journal、Trace、Transcript、Telemetry、Eval record

把它们全部塞进 messages[] 会同时破坏恢复、隐私、查询和 evaluator reproducibility。

9.2 Trace hierarchy

EvaluationRun
└── TaskRun span
    ├── Turn span
    │   ├── ContextBuild span
    │   │   ├── Retrieval span
    │   │   └── Compaction span
    │   ├── ModelInference span
    │   ├── Decision event
    │   ├── ToolIntent span
    │   │   ├── Permission span
    │   │   ├── ToolExecution span
    │   │   ├── Effect event
    │   │   └── Receipt event
    │   └── Verification span
    ├── Recovery / Resume span
    └── TerminalOutcome event

9.3 必须支持的因果链接

• trace_id：一次 task run 的端到端关联；
• span_id / parent_span_id：同步层级；
• links[]：异步任务、subagent、重试、resume 和跨服务因果；
• turn_id、step_id、tool_call_id、effect_id、receipt_id；
• retry_of、resume_from、spawned_by、verifies_effects[]；
• task_family_id、run_group_id、experiment_id；
• journal_offset：关联持久化事实但不把 trace 当 journal。

9.4 推荐 schema

schema_version: agent-trace@3
identity:
  trace_id: 8f2c...
  run_id: run-20260803-0042-b-03
  task_id: deep-ts-0042
  task_family_id: async-cancellation-v3
  experiment_id: retry-policy-ablation-17
  parent_run_id: null
configuration:
  model:
    provider: moonshot
    id: k3
    version: exact-provider-version
    reasoning_effort: max
    sampling: {temperature: 1.0, top_p: 1.0, seed: null}
  harness:
    name: kimi-code
    commit: e22479a
    config_digest: sha256:...
    system_prompt_digest: sha256:...
  context_policy:
    retrieval_version: hybrid@8
    compaction_version: full@4
    max_context_tokens: 1048576
  tools:
    catalog_digest: sha256:...
    permission_policy: policy@12
  environment:
    repo_commit: 4b3d...
    image_digest: sha256:...
    os_arch: linux-amd64
    network_policy: denied
  budget:
    wall_time_s: 3600
    token_limit: 1120000
    cost_limit_usd: 20
spans:
  - span_id: step-017
    parent_span_id: turn-002
    kind: tool
    start_ns: 178...
    end_ns: 179...
    state_before_digest: sha256:...
    intent:
      tool_name: shell
      args_digest: sha256:...
      effect_class: process_start
      target_scope: workspace
      idempotency_key: null
    permission:
      decision: allow
      policy_rule_id: local-process-04
    execution:
      attempt: 1
      status: ambiguous
      error_type: timeout_after_accept
    effect:
      effect_id: eff-991
      known_state: uncertain
    receipt:
      receipt_id: rec-772
      operation_id: op-223
      content_artifact_ref: local://artifact/...
    usage:
      wall_ms: 30122
    links:
      retry_of: null
events:
  - type: decision
    step_id: step-018
    observed_evidence_ids: [rec-772]
    chosen_action: retry_without_reconciliation
  - type: verifier_result
    verifier_id: cancellation@7
    criterion_id: no_process_leak
    verdict: fail
    evidence_ids: [proc-snapshot-19]
outcome:
  terminal_reason: verifier_failed
  success: false
  safety_incident: duplicate_effect
  user_intervention_count: 0
  final_state_digest: sha256:...
privacy:
  content_capture: local_encrypted
  cloud_export: metadata_only
  redaction_policy: telemetry-redaction@6

9.5 Decision event：可观测的是依据，不是私有 chain-of-thought

为诊断记录：

• 可见 evidence IDs；
• selected action 与 alternatives class；
• policy/permission 分支；
• confidence/uncertainty 若系统实际使用；
• goal/subgoal/constraint IDs；
• tool result 是否 acknowledged；
• termination rationale 的结构化 code。

不要要求或持久化模型私有 chain-of-thought。自然语言 rationale 既可能不忠实，也引入隐私和安全成本；诊断重点是“当时看到了什么证据，选择了什么动作，外部发生了什么”。

9.6 Content 与 metadata 双层

Cloud telemetry:
  stable IDs, versions, status, duration, token/cost,
  tool class, error type, effect risk, counts, hashes

Local opt-in debug bundle:
  sanitized prompt, tool arguments/results, diff,
  logs, screenshots, verifier evidence

禁止把 secret、token、私钥、完整源码、绝对用户路径、email 和原始 personal data 作为高基数 span attributes。内容应 artifact 化、加密、有 TTL、访问审计和用户显式分享。

9.7 OpenTelemetry 映射

OpenTelemetry GenAI Semantic Conventions 已从 core semantic-conventions 仓库迁到独立仓库。本卷在 2026-08-03 核验的 9af0834 snapshot 中，top-level manifest 使用 https://opentelemetry.io/schemas/gen-ai-dev/1.42.0-dev，并依赖 core semantic conventions 1.43.0；该 snapshot 的通用 GenAI span 文档和 agent/framework span 文档均明确标记 Status: Development，不是 Stable。

当前文档已定义/覆盖 invoke_agent 的 client/internal spans、execute_tool、retrieval、model inference、usage、streaming、cache token、reasoning token、time-to-first-chunk 与 evaluation event 等通用语义。这里的正确工程结论是“可作为跨系统对齐基线”，不是“字段已经冻结”：instrumentation 必须 pin schema/semconv 版本、记录 opt-in 配置并为 rename/migration 留兼容窗口。

采用原则：

• OTel 负责跨服务 trace 基础与通用 GenAI spans；
• domain schema 扩展 task/turn/step/effect/receipt/verifier/lineage；
• 扩展字段 namespaced、版本化，不篡改标准字段语义；
• high-cardinality content 放 artifact，不放 metric labels；
• schema migration 与 exporter sampling 不能丢失 safety/effect evidence；Development 字段升级前必须做兼容性测试。

Cursor Agent Trace RFC 聚焦 AI 生成代码的文件/行贡献归属，不等于运行时 trajectory schema；它可以作为 artifact provenance 的互补层，不能替代 tool/effect/verification trace。

9.8 Trace quality 自身也要评测

Coverage      关键 step/effect 是否都有记录
Linkability   model intent -> tool -> effect -> receipt -> verifier 能否关联
Faithfulness  trace status 是否与 journal/environment 一致
Ordering      async/retry/resume 的 happens-before 是否可恢复
Privacy       是否捕获禁止内容
Overhead      tracing 对延迟/成本/行为的扰动
Queryability  能否稳定回答诊断问题

建议注入 synthetic canary events 和 known failure，验证 exporter、sampling、redaction、storage、query 全链路。没有完整 trace 的 run 不应静默进入 trajectory metrics，应标记 trace_incomplete。

10. Failure Clustering：把一万条失败压缩成可修的机制

10.1 三层标签，不要只有一个 error code

Symptom:       用户/系统最后看到了什么
Critical cause: 哪个 step 首次让成功路径崩坏
Root mechanism: 哪个组件/contract 允许它发生

例如：

symptom         = tests_timeout
critical_cause  = duplicate_non_idempotent_tool_retry
root_mechanism  = ambiguous_effect_error_lacks_reconciliation_state
owner           = runtime

只按 symptom 聚类会把不同根因混在一起；只按 root cause 聚类又可能失去用户影响与优先级。

10.2 正交 taxonomy

不要强迫一个 flat enum 同时表达这些维度。

10.3 聚类 pipeline

raw runs
  -> validity/infra filter
  -> structured feature extraction
  -> trajectory segmentation around critical step
  -> candidate embedding/rule clustering
  -> expert naming and merge/split
  -> counterexample search
  -> cohort metric + owner + hypothesis
  -> reproducible eval family

Features

• task metadata：language、repo size、horizon、risk；
• system/config：model、harness、context、tool versions；
• structured trace：stage、error type、tool class、retry、compaction；
• process sequence：abstract action n-grams / state transitions；
• critical-step evidence；
• final artifact and verifier failures；
• user correction/rollback；
• cost after FBD。

Embedding 适合发现未知相似性；规则适合稳定监控。实践中应先用结构字段收敛大类，再在类内对局部 trace 摘要 embedding，最后由专家建立可解释 cluster definition。

10.4 Cluster 的质量标准

一个 cluster 名称如果是“模型表现不好”或“复杂任务失败”，不具可操作性。

10.5 优先级不是 frequency 排序

Priority(c) = Exposure(c)
              × P(failure | exposure, c)
              × UserHarm(c)
              × Fixability(c)
              × Confidence(c)
              / EngineeringCost(c)

还要设置 hard override：低频但不可逆的安全/data-loss cluster 优先级不能被频率压低。

10.6 Cluster dossier

cluster_id: ambiguous-effect-retry
definition: non-idempotent tool timed out after possible acceptance, then retried without reconciliation
exclusions: read-only/idempotent retries
population:
  exposed_runs: 812
  failures: 37
  trend_28d: +1.2pp
impact:
  task_failures: 31
  duplicate_effects: 9
  estimated_wasted_cost_usd: 421
evidence:
  confirmed_fbd: 22
  counterfactual_recovered: 18/20
owners: [runtime, tool-contract]
hypothesis: error taxonomy collapses accepted-timeout and pre-send-timeout
eval_family: reconciliation-chaos@3
ship_gate: pass^3 = 100% on high-risk subset

10.7 防止闭环自欺

• 失败容易被看见，silent wrong success 不易进入 cluster；必须抽样成功 run 做审计；
• 用户纠正多的 cohort 可能只是用户更专业，不代表系统更差；
• 新 instrumentation 会“制造”表观趋势；按 schema/coverage 校正；
• LLM cluster label 可能继承 outcome bias；让它引用 evidence 并做 blind review；
• 只修 top-frequency 会忽略 rare catastrophic；安全单独建 risk register；
• cluster 变小可能是流量迁移，不是修复生效；看 exposure-normalized rate。

11. Agent Eval Card：每个分数都要带可审计合同

11.1 完整模板

eval_card_version: 2
identity:
  name: kimi-retrieval-regression-2026q3
  result_id: er-20260803-18
  owner: agent-eval
  executed_at: 2026-08-03T10:00:00+08:00

claim:
  primary: "hybrid retrieval v8 improves verified completion on large TS repos"
  decision: canary_gate
  supported_scope:
    languages: [typescript]
    repo_loc: [100000, 2000000]
    task_families: [bugfix, feature]
  unsupported_claims:
    - model intrinsic capability
    - high-risk external effects

population:
  target_definition: production-eligible-large-ts-tasks
  sampling_frame: sanitized-production + authored-neighboring-cases
  traffic_weights_version: weights@2026q3
  known_coverage_gaps: [monorepo-over-2m-loc, windows]

task_set:
  version: large-ts@14
  n_tasks: 420
  sources: {production_derived: 210, authored: 160, public: 50}
  lineage_split: family+repo+time
  validity_audit:
    solvable: 420/420
    oracle_reviewed: 420/420
    suspect: 3
    excluded_pre_registered: 3
  contamination:
    model_cutoff_check: done
    future_commit_scan: done
    train_eval_lineage_overlap: none_known

systems:
  baseline:
    model: k3/exact-version
    harness_commit: ...
    retrieval: hybrid@7
  candidate:
    model: k3/exact-version
    harness_commit: ...
    retrieval: hybrid@8
  shared:
    context_policy: ...
    tools_digest: ...
    permission_policy: ...

protocol:
  paired: true
  repetitions_per_task: 3
  order_randomized: true
  budgets: {time_s: 3600, tokens: 1000000, cost_usd: 20}
  environment_image: sha256:...
  network: denied
  retry_policy: infra-only-symmetric@2
  preregistration_ref: local://...

scoring:
  primary: verified_completion
  hard_gates: [safety_invariant, regression_free]
  verifier_version: task-verifiers@14
  judge:
    model: exact-version
    rubric: trajectory-quality@6
    calibration_set: judge-gold@4
    human_review_band: [0.35, 0.65]

results:
  primary:
    baseline: 0.612
    candidate: 0.674
    absolute_delta_pp: 6.2
    ci95_pp: [2.1, 10.0]
  reliability:
    pass_3_baseline: 0.381
    pass_3_candidate: 0.442
  efficiency:
    cost_per_verified_success: {...}
    ttvc_p50_p95: {...}
  safety: {...}
  slices: [...]

failures:
  infra_errors: {baseline: 7, candidate: 6}
  timeouts: {...}
  refusals: {...}
  fallbacks: {...}
  top_clusters: [...]
  first_bad_decision_review_n: 80

statistics:
  method: paired-task-cluster-bootstrap
  bootstrap_replicates: 10000
  multiplicity_policy: primary-confirmatory_rest-exploratory
  power_notes: "insufficient for <0.5% severe incident delta"

artifacts:
  trajectories: access-controlled://...
  verifier_outputs: ...
  diffs: ...
  task_audit: ...
  analysis_code_commit: ...

decision:
  verdict: proceed_to_shadow
  rationale: ...
  residual_risks: ...
  owners: ...
  expires_at: 2026-09-03

11.2 Eval Card 的作用

• 防止结果与配置脱离；
• 让 broken-task / judge 变更可追溯；
• 把“不支持的结论”写入一手事实源；
• 让同一结果能被 release、research、product、安全分别消费；
• 结果过期后不再被产品页面无限复用。

Card 不应手工复制粘贴。字段应从 task registry、run manifest、trace store、verifier 和 analysis pipeline 自动生成，只有 claim、scope limit、decision 和 residual risk 由负责人签署。

12. Data Flywheel：Production Trace 到 Training/Eval 的闭环

12.1 真正闭环

Production exposure
  -> consent / policy / retention gate
  -> privacy-preserving trace + artifact capture
  -> validity and observability audit
  -> outcome + delayed user feedback join
  -> failure/success cohorting
  -> causal diagnosis / FBD
  -> task reconstruction + oracle authoring
  -> lineage-aware split
       ├── regression eval
       ├── judge calibration
       ├── SFT / preference / process supervision
       ├── agentic RL environment
       └── runtime policy/harness fix
  -> offline repeated eval
  -> shadow / canary / online
  -> post-launch drift and harm audit

“trace 多”不是飞轮。只有 trace 被转成可复现任务、可信标签、可定位机制和发布证据，才产生学习。

12.2 数据进入闭环前的四道 gate

1. Legal/privacy gate：用户授权、purpose limitation、retention、删除、跨境和敏感代码；
2. Observability gate：trace 是否完整、effect 与 receipt 是否可关联；
3. Validity gate：outcome 是真实失败还是环境/oracle 错；
4. Lineage gate：与 train/eval/benchmark family 的关系是否明确。

任何 gate 不通过，数据可以用于 aggregate operations，但不应自动进入训练或 hard eval。

12.3 一条 trajectory 可以生成不同数据产品

不要把原始失败 trace 直接做 negative SFT；其中可能包含前半段正确探索、环境故障和 judge 误判。必须先做 credit assignment。

12.4 Curation 的核心是保留 counterfactual

高价值数据不是“成功回答”，而是：

same task prefix
  + chosen bad action
  + available evidence
  + better feasible action
  + observed/counterfactual outcome
  + why verifier distinguishes them

这使数据能教会模型在具体 decision boundary 上改变 policy，而不是只模仿最终 patch。

12.5 Train / validation / eval 的 lineage split

随机按 run 切分几乎一定泄漏。至少按以下最强相关单元分组：

• source task / issue / commit；
• task family / template / synthetic generator seed family；
• repository 与 fork；
• user/org（受隐私和公平约束）；
• 时间；
• reference solution / verifier lineage；
• trajectory prefix / memory item 来源。

推荐：

Training: older families + full trajectories
Development: disjoint families/repos, frequent iteration
Regression: previously observed failures, visible but protected from training
Sealed evaluation: new time window + original tasks, restricted access
Rolling production holdout: delayed labels, never enters current release training

同一个 production failure 不能既进入训练，又作为“未见过能力提升”的 eval 证据。它可以成为 regression test，但 claim 必须是“记住并不再复发”，而不是泛化。

12.6 Production data 的十二类偏差

12.7 Feedback loops 与 performative data

系统发布后会改变数据分布：

• Agent 擅长的任务被更多委派；
• 不擅长的任务用户不再尝试，因此失败“消失”；
• permission 设计改变哪些 effects 可见；
• 自动补全风格改变未来 repository；
• judge 指标驱动模型输出迎合 judge；
• memory 把过去 evaluator 偏差传播到未来决策。

因此线上指标必须同时看：exposure、eligible population、attempt rate、abandonment、human fallback 和 counterfactual control。不能只看 observed success among attempted tasks。

12.8 Curation 策略

优先级不是只采 hardest failures。一个平衡 batch 应包含：

high-frequency ordinary tasks
+ high-severity rare boundaries
+ recently regressed families
+ uncertain/disagreement items
+ underrepresented languages/repos/users
+ correct no-op/refusal/clarification
+ successful but inefficient trajectories
+ adversarial neighboring counterexamples

可用 acquisition score：

A(x) = w1·ExpectedProductImpact
     + w2·ModelUncertainty
     + w3·JudgeDisagreement
     + w4·CoverageGap
     + w5·FailureSeverity
     - w6·PrivacyRisk
     - w7·LabelCost

12.9 Agentic training 的 credit assignment

长轨迹只有 terminal reward 时，模型不知道哪一步造成结果。可增加：

• executable subgoal verifier；
• invariant-preserving reward；
• FBD pairwise preference；
• hindsight relabeling，但必须避免用当时不可知信息；
• turn-aware advantage；
• recovery reward 与 duplicated-effect penalty；
• cost/latency regularization；
• judge uncertainty / abstention。

ToolVerse 用近 400 个 MCP、约 4,500 个工具构建 executable environments，并提出 tool dependency graph 与 turn-aware relative advantage 来处理长程 agentic RL 的任务生成和 credit assignment。其意义不是说明 production trace 可直接训练，而是证明环境多样性、依赖结构和逐 turn credit 已成为训练基础设施的一部分。

ReasoningBank 展示从成功与失败 trajectory 提取可迁移 reasoning strategy 的 test-time learning；但从 eval 角度仍要治理 self-judge noise、memory scope、过期和 train/test contamination，不能把“经验被保存”直接等同于“系统学对了”。

12.10 闭环的健康指标

最重要的速度不是每天增加多少 traces，而是从真实 failure cohort 到有因果证据的机制修复，再到安全发布需要多久。

13. Kimi Code 机制映射：公开代码能支持哪些具体判断

以下只映射公开仓库与 K3 公开披露，不推断 Moonshot 内部未公开 eval pipeline。源码能支持的是“这里存在什么 ownership seam、能在哪里插桩和构造反事实”；它不能支持“Kimi Code 已经比 Codex、Claude Code 或 pi 更有效”。后者必须回到 7.7 的固定 model-task-budget-environment 受控实验、可核验 outcome、真实 trace 与 failure slices。架构可读性本身可作为 diagnosability/maintainability 维度测量，但不是 completion/reliability 的代理。

13.1 Public architecture 到 eval object

公开源码入口：loopService、toolExecutorService、wireService、contextMemoryService、fullCompactionService、permissionGateService。

13.2 最有区分度的 Kimi eval 设计

1. Compaction counterfactual：同一 long-horizon prefix，从 compaction 前 snapshot 分别跑不同 policy，比较必要 evidence preservation、后续 FBD 与 TTVC；
2. Wire recovery matrix：在 model stream、tool execution、effect receipt、compaction、subagent complete 等边界 kill process，验证 replay 后状态与外部世界 reconcile；
3. Tool execution alignment：固定模型，改变 tool schema/truncation/dedupe/retry，分析模型合理推理是否与 workspace/effect 脱节；
4. Permission utility frontier：同时测 hazard catch 与 safe-task prompt burden，不用 incident-only metric；
5. Harness × model factorial：只在共同支持的 model-harness cells 上，让 K3 与至少一个其他模型跨 Kimi Code/对照 harness，固定 task/environment/budget，区分 model main effect、harness main effect 与 interaction；不支持的 cell 不补值、不跨 disconnected graph 排名；
6. No-op / abstention set：已经修复、需求矛盾、证据不足、不应越界的 tasks；
7. Trace-to-regression latency：公开 issue/用户失败到最小可复现、FBD 和 regression gate 的时间。

13.3 K3 公布成绩本身教会我们的 eval literacy

Kimi K3 公开仓库 对 coding benchmark 披露了：

• 不同模型使用 Kimi Code、Claude Code、Codex 等不同 harness；
• reasoning effort、temperature/top-p；
• Kimi Code Bench 2.0 的 refusal/fallback 数；
• BrowseComp 在 300K token 触发 compaction，并另报 1M 无 context management 的结果；
• 某些 benchmark 使用 H20 校准 branch、三次平均或特定日期 leaderboard。

这组披露的正确读法不是直接做 model 或 harness ranking，而是看到 score 是 model-harness-context-budget-environment 的联合测量。Kimi Code Bench 2.0 中 K3 在 Kimi Code harness 与 Claude Code harness 的结果不同，只能先作为“harness 可能是重要 treatment”的敏感性证据；只有 task revision、model endpoint、environment、预算、grader、运行次数与 infra handling 全部可比时，差值才可解释为该协议下的 harness effect。公开实现多、机制新或 trace 更可读，都不能替代这一步。

13.4 面试中可以提出的内部指标树

North star: verified, regression-free, user-accepted completion

├── Capability
│   ├── understand/retrieve/act/recover/verify
│   └── task family × horizon × language
├── Reliability
│   ├── pass^k / perturbation / fault injection
│   └── interruption-resume / compaction fidelity
├── Trust
│   ├── harmful effect / over-refusal
│   └── permission burden / reconciliation
├── Efficiency
│   ├── cost per verified success
│   └── TTFA / TTVC / wasted-after-FBD
└── Learning
    ├── top failure cohorts / unknown attribution
    └── failure-to-regression-to-canary lead time

13.5 不应假装知道的内容

• Kimi 内部生产 traffic 权重；
• private benchmark task source、grader 和防污染合同；
• K3 post-training 是否直接使用 Kimi Code traces；
• 公开 telemetry 字段是否等于内部完整 schema；
• 团队当前 top failure cohort；
• Kimi Code、Codex、Claude Code、pi 在共同模型与共同任务合同下的相对 frontier 顺序。

面试表达应是“根据公开 architecture，我会这样设计/验证”，而不是把合理设计冒充内部事实。

14. 设计决策速查表

15. 反模式与失效清单

1. 用 benchmark 名替代 construct 定义；
2. 把 model score 和 system score 混为一谈；
3. 任务只是一段 prompt，没有 initial state 与 budget；
4. tests 能跑就认为 oracle 有效；
5. 只跑一次随机 Agent；
6. 报 pass@k 却产品没有 chooser；
7. 用平均 latency 隐藏 timeout 尾部；
8. 只算成功 run 的成本；
9. 删除 broken task 但不版本化重算历史；
10. 同一个 LLM 造题、判题、处理争议；
11. 把 agent 自称完成当 outcome；
12. 只看 final tests，不看副作用与无关 diff；
13. 只按最后 error code 聚类；
14. 用 hidden hindsight 判断早期合理探索；
15. 将静态 replay 当新 policy 的端到端结果；
16. 改多个组件后用总分做单一归因；
17. 线上指标改善却不看 exposure/attempt shift；
18. 只从 explicit failure 学习，忽略 silent wrong success；
19. 随机 run-level train/eval split 导致 family 泄漏；
20. 原始 production trace 未经 privacy/validity gate 直接训练；
21. 将 regression case 重新用于训练，却继续声称 unseen generalization；
22. 收集更多 telemetry，但没有任何 release decision 消费；
23. trace 记录私密内容，却缺 TTL、权限和删除；
24. 零 incident 小样本被解释为安全；
25. 综合分数让安全失败被普通成功抵消。
26. 用开源程度、feature checklist、stars 或 release cadence 排“先进 harness”；
27. 把不同 native model × harness pairing 的榜单分差归因给 harness；
28. 因某系统没公开内部 trace，就把 unobservable 机制当作不存在；
29. 为追求“同 prompt”破坏模型的 native tool protocol，却声称比较公平。

16. 二十五组面试深追问与专家答题骨架

1. “你会怎么定义 Coding Agent 的成功？”

答题骨架：先拒绝“最终回复正确”这一定义。成功是外部世界的 verified state transition：需求满足、旧行为不回归、约束不违反、有独立 evidence、无 disqualifying incident。再区分 benchmark success、用户 accept 与长期无 rollback；说明它们是递进证据，不是同一标签。

继续追问：“用户接受了为什么还不算成功？”

关键点：用户可能未发现 latent bug；accept 是产品信号，需 join CI、revert、incident 和后续修改。反过来用户拒绝也可能是偏好问题，不必等同 functional failure。

2. “Construct validity、task validity、oracle validity 有什么区别？”

答题骨架：construct 问“这个测量代表我声称的能力吗”；task 问“这个实例在指定世界中公平、可解、代表目标分布吗”；oracle 问“判分器能否正确接受所有合法解并拒绝非法解”。举例：一个题可解且 tests 准确，但只测单函数生成，所以不能代表 repo-level engineering；也可能题很真实，但 inherited tests 拒绝合法替代实现。

继续追问：“谁先 gate？”

关键点：先明确 claim/construct，再审 task，再审 oracle/protocol。否则会为一个不值得的 construct 把题和 grader 做得很精确。

3. “怎么证明一个 benchmark task 没坏？”

答题骨架：四方对齐 prompt、repo semantics、allowed environment、oracle；独立工程师从初始 snapshot 完成；reference + alternative correct solutions；incomplete/mutant/exploit patches；环境重复；future leakage 扫描；标记 audit version。不能证明绝对没坏，只能建立可反驳、可复审的证据。

继续追问：“发现 30% broken 后怎么重算？”

关键点：预注册对称 exclusion rule、task-set 新版本、所有 system 重跑或在相同 evidence 下重算、旧版保留、披露 ranking sensitivity；不能只删某模型失败题。

4. “pass@k 与 pass^k 的业务含义？”

答题骨架：pass@k = 至少一次成功，衡量采样搜索可达性，适合有 chooser/verifier 的多候选系统；pass^k = 连续 k 次都成功，衡量一致可靠性。独立时分别是 1-(1-p)^k 与 p^k，方向相反。一次自主交付重点看 Pass@1 与 pass^k，不能拿 Pass@10 粉饰不稳定。

继续追问：“为什么不能只用公式？”

关键点：run 共享 cache、provider outage、harness bug，非独立同分布；应按 task 重复、直接估计、报告 shared-failure correlation。

5. “离线 eval 很好，线上却变差，你先怀疑什么？”

答题骨架：按分布、交互、环境、指标四类排查：offline task weights 与 traffic 不同；真实 clarification/permission/外部 effect 缺失；provider/load/dependency 漂移；oracle 与用户效用不收敛；attempt/exposure 变了；trace/join coverage 变化。先做 slice reweighting 与 offline-online matched cohort，不急着判模型退化。

继续追问：“该信哪个？”

关键点：取决于 decision。真实产品价值优先线上，但需因果设计与 guardrail；离线用于机制归因。冲突本身说明 construct 或 population mapping 有缺口。

6. “Shadow 为什么不能替代 canary？”

答题骨架：shadow 能看到真实输入，但通常不提交 effect、拿不到真实反馈/permission/user response，trajectory 会偏离；它验证兼容、延迟、明显行为和估算成本，不能证明真实 completion 和 harm。Canary 在受限 cohort 中执行真实状态改变，因此需要 kill switch、reconciliation、abort metrics。

继续追问：“fork sandbox shadow 呢？”

关键点：比 no-op shadow 强，仍缺真实外部系统和用户后续；适合作为 canary 前最后一道证据。

7. “怎么设计 Agent regression gate？”

答题骨架：hard invariant 任一失败阻断；primary metric 用 paired repeated eval 和预先定义 non-inferiority margin；diagnostic slices 用于调查而非事后挑结论；infra failure 对称重跑；同时报 reliability、safety、cost、latency。任务分 invariant/core/failure regression/frontier，frontier 不宜成为硬门禁。

继续追问：“没显著下降就是没 regression 吗？”

关键点：不是；可能 power 不足。只有 CI 下界高于 -δ 才能声明 non-inferior，否则 inconclusive。

8. “一个 prompt 改动让成功率 +4pp，如何证明是它造成的？”

答题骨架：固定 model、harness commit、tools、context、budget、environment；同题 paired、随机执行顺序、多次 run；记录 prompt digest；看 trajectory mechanism 是否按假设改变；prefix replay/ablation；检查 token length/cache/tool schema 这些中介。若同时改了 retrieval，就用 factorial design 拆 main effect 与 interaction。

继续追问：“只看总分够吗？”

关键点：不够；要看到目标 failure cohort 降低且 neighboring cohorts 不恶化，否则可能是偶然或换了一种失败。

9. “怎么找到 first bad decision？”

答题骨架：从 failed criterion 反向构建 evidence chain；恢复每步当时 information set；找最早 invariant violation 或关键 evidence 错失；排除后续已恢复的弯路；设计最小替代 action；从 prefix/environment snapshot 重放；记录 counterfactual recovery、confidence 与 owner。

继续追问：“最后一次错误是不是 FBD？”

关键点：通常不是。最后 test fail 只是 symptom；FBD 可能是更早检索漏文件、误分类 ambiguous effect 或 compaction 丢约束。

10. “模型早期猜错根因，后来修正了，算失败吗？”

答题骨架：合理探索不是错误。评估它是否基于当时证据、是否主动寻求区分性实验、修正成本是否可接受、是否残留副作用。已恢复的错误不作为 final FBD，但可进入效率和 hypothesis-quality process metric。

继续追问：“那怎么奖励探索？”

关键点：奖励 information gain 与 bounded reversible probes，不奖励无证据的大改；最终仍以 verified outcome 约束。

11. “Human、LLM judge、tests 怎么组合？”

答题骨架：硬事实由 deterministic verifier；开放式架构/交互质量由 blind calibrated human/LLM；安全 hard gate 不被质量分抵消；LLM 做规模化预筛和 explanation，uncertain band 给人；judge 的 confusion matrix、order flip、slice drift 单独监控。

继续追问：“强模型 judge 能替代人吗？”

关键点：不能按 model capability 推导 judge validity。被测 artifact 可能 prompt-inject，generator/judge 可共享盲点；高风险与 calibration drift 仍需人和外部 evidence。

12. “怎么评测 LLM judge？”

答题骨架：独立专家 adjudicated gold；known degradation/trajectory perturbations；candidate 顺序交换；长度/style/品牌 blind；同一 item 多次；按 language、trajectory length、success status 切片；测 false accept/reject、order flip、abstain、inter-run agreement；版本更新重新 calibration。

继续追问：“agreement 高就够吗？”

关键点：两个 judge 可一致地错；要对独立真值和 hard evidence 测 validity，不能只看互相一致。

13. “为什么 outcome pass 还要看 trajectory？”

答题骨架：成功可能是偶然、spec gaming、危险路径或不可扩展高成本；trajectory 负责归因、检测近失事件、效率和可恢复性。反过来漂亮 trajectory 不能抵消失败 outcome。二者关系是 outcome gate + trajectory diagnosis/guardrail。

继续追问：“过程指标会不会限制创新路径？”

关键点：会，所以只把真正的不变量 hard-code；其他 process metric 用于诊断，不要求匹配 reference reasoning/path。

14. “怎么测 context compaction？”

答题骨架：冻结长轨迹 prefix，在 compaction 边界 fork；建立 required evidence/constraint set；比较 preservation、false insertion、token reduction、cache、后续 FBD、verified completion 与 TTVC；测不同 horizon 和重复 compaction；加入 outdated/conflicting evidence。不要只用 summary similarity。

继续追问：“1M context 还需要测吗？”

关键点：需要。长窗口不消除 relevance、cost、attention dilution、cache 和跨多次请求状态问题；K3 公开 BrowseComp 也披露 compaction 与 full-context 两种条件。

15. “如何单独测 repository retrieval？”

答题骨架：区分 gold-file recall、line/evidence precision、time/steps to first relevant evidence、next-context value，以及给定检索结果后的 downstream completion。设置固定 line/token budget、no-gold controls、counterfactual inject/remove evidence。gold file 是 proxy，不是唯一正确路径。

继续追问：“检索 recall 高但完成率不变？”

关键点：可能模型不会利用 evidence、加入太多噪声、时机太晚或 oracle 不敏感；做 mediation 和 prefix intervention，而不是继续优化 recall。

16. “如何评测 retry/recovery？”

答题骨架：按错误语义注入 pre-send failure、accepted-timeout、partial result、429、schema drift、process kill；明确 effect idempotency；测 detect、classify、reconcile、retry、终态和 duplicate effect；recovered 必须满足正确终态，不是请求最终返回 200。

继续追问：“retry 提高 success 就值得吗？”

关键点：还要看重复副作用、成本尾部和错误被掩盖；non-idempotent ambiguous effect 必须先 reconciliation。

17. “如何评价两个 harness？”

答题骨架：先声明 estimand。测 harness causal effect 时固定 exact model/task/environment/budget 与 oracle，只把 native prompt/tools/context/retry/compaction 等当 harness treatment；同题 paired、多次 run、随机顺序，再做 cross-model factorial 看 interaction。若 model-support matrix 不完全交叉，只在连接子图估计，不给缺失 cell 排名。报告 verified completion、pass^k、cost、latency、human burden、外部状态证据与 retrieval/context/tool/verification/recovery failure slices。若允许各自 native model-harness，则 claim 是 product-system comparison。

继续追问：“同一 prompt 就公平吗？”

关键点：不一定；模型工具协议、prompt elicitation 和 native affordance 不同。公平不是文本完全相同，而是 capability opportunity 与预算/环境合同可比较，并完整披露。官方源码只证明机制存在，不证明先进；raw native trace 要保留并映射到共同 schema，缺失内部事件标 unobservable。

18. “线上 failure clustering 怎么做？”

答题骨架：先排除 invalid task/infra；用 stage、mechanism、owner、recoverability、severity 等结构字段；围绕 critical step 截取局部 trace；规则 + embedding 候选聚类；专家 merge/split、查成功 counterexamples；cluster 必须对应一个可复现 eval 和 owner。

继续追问：“如何排优先级？”

关键点：exposure-normalized failure × harm × fixability × confidence / cost，安全灾难有 hard override；不能只按 raw frequency。

19. “你会怎么设计 trace schema？”

答题骨架：task/run/turn/step 层级；model/context/tool/permission/effect/receipt/verifier spans；稳定 ID 与 async links；exact config/environment/budget；state/evidence digests；terminal outcome；privacy metadata。分 journal、trace、transcript、telemetry、eval record；对齐 OTel GenAI，再加 versioned domain fields。

继续追问：“要存 chain-of-thought 吗？”

关键点：不依赖私有 CoT。记录可见 evidence、选择的 action、policy branch、effect 与 receipt；自然语言 rationale 可能不忠实且扩大隐私风险。

20. “Trace 全量采集太贵怎么办？”

答题骨架：metadata 全量低成本；内容本地加密、opt-in artifact；errors/high-risk/experiment cohort 保留更高采样；head sampling 不能漏掉后来才显现的失败，使用 tail sampling；safety/effect spans 不采样丢失；监控 trace completeness 与 overhead。

继续追问：“只保存失败 run？”

关键点：会丢 success baseline、silent wrong success 和 counterexamples；至少分层保留成功样本用于比较与审计。

21. “Production traces 怎么进入训练？”

答题骨架：先 consent/privacy、trace completeness、task/oracle validity、lineage gates；再做 FBD/credit assignment；按用途生成 regression、preference、SFT、process、RL environment 或 memory；train/eval 按 family/repo/time 切分；离线验证后 shadow/canary。原始 trace 不直接进训练。

继续追问：“用户接受的 trajectory 能直接当正例吗？”

关键点：不能。可能包含无关步骤、潜在 bug、过度权限和昂贵路径；需 delayed outcome 和 process/safety audit。

22. “怎么防止 data flywheel 把偏差越放越大？”

答题骨架：记录 eligible exposure/attempt，纠正 selection；主动采 silent success 和 underrepresented cohorts；judge gold calibration；rolling holdout；分离 train/regression/sealed eval；监测数据/策略/用户行为漂移；保留 correct no-op、refusal、clarification；检查 model-on-policy state coverage。

继续追问：“指标越来越好为什么还可能退化？”

关键点：系统改变谁会使用它、哪些任务会被尝试，且模型学会迎合 judge；这是 performative data 和 Goodhart，需要独立用户/外部 evidence。

23. “一个 production failure 应该进 eval 还是 training？”

答题骨架：先进入 regression，证明 fix 不复发；若有可迁移 decision boundary 和可信 counterfactual，再进入训练。若同一 family 训练过，之后只能声称 memorized regression，不可作为 unseen generalization。留 sealed neighboring family 测迁移。

继续追问：“什么时候退休 regression case？”

关键点：contract 消失、被更深 invariant 覆盖、重复冗余或环境不可维护；安全/data-loss incident 可长期保留，但也要 version migration。

24. “Kimi Code 最值得先建哪类 eval？”

答题骨架：不凭公开信息假装知道内部 top priority。基于公开架构，我会先从内部 trace 选高频高损 cohort；若无数据，候选是 compaction fidelity、interruption/wire recovery、tool ambiguous-effect reconciliation。每个方向都能在 Kimi 的 context/wire/tool 深模块边界上建立 deterministic fault injection、FBD 和 online metric。

继续追问：“为什么不是再做一个大 benchmark？”

关键点：产品迭代价值来自高质量 failure-to-regression loop；大榜单覆盖面广但不一定能归因或映射真实 traffic。

25. “如果只能保留一个 eval 指标，你选什么？”

答题骨架：挑战问题前提。单指标会 Goodhart，无法同时表达成功、风险、成本和不确定性。若被迫选 north star，选“traffic-weighted verified、regression-free、user-accepted completion within budget”，但保留 safety hard gates 和最低 observability；没有这些，north star 本身无效。

继续追问：“这是不是太复杂？”

关键点：对外可以是一条 north star；复杂性应封装在深 eval module 中，而不是从真实系统删掉。接口简单：can_ship(candidate, baseline, claim) -> decision + evidence + residual_risk。

17. 2026-08 前沿判断：已经确定、正在形成、仍需谨慎

已经确定的结构性变化

1. 被测对象是 model-harness system，而不是 base model；
2. 原创任务、verifier audit、完整 trajectory 和预算披露成为可信 coding eval 的基础；
3. pass rate 必须与 reliability、cost、latency、safety、human burden 联合解释；
4. trace 已从 debug 日志变成 eval、data curation 和发布控制面的共同事实入口；
5. offline benchmark 与 production eval 必须通过 task lineage 和 traffic weights 连接；
6. no-op、abstention、recovery 和 long-horizon task 正在补齐传统 patch benchmark 的盲区。

正在形成的方向

1. 用 executable invariant + tool-using judge 做 trajectory attribution；
2. OpenTelemetry GenAI 逐步成为跨框架通用 spans/events 基线；
3. harness science 从“prompt 经验”走向 factorial experiment 和自动优化；
4. 从 trace 提取 preference、process credit、memory 与 RL environment 的统一 data layer；
5. rolling/private/original benchmark 与 public reproducibility 的双轨制；
6. reliability surface、metamorphic task 和 chaos fault 成为 production readiness 标准。

仍需谨慎

1. LLM/Agent-as-a-Judge 的语言能力增长不等于 oracle validity 已解决；
2. process score 可能把合法替代路径锁死；
3. 自动 harness optimization 极易 benchmark overfit；
4. production data flywheel 会因 selection、judge 与 performative feedback 自我强化；
5. 长任务 dense reward 可能优化 intermediate proxy 而非最终工程价值；
6. private benchmark 更贴近产品，但缺乏外部审计，不能替代公开证据。

18. 一手资料索引

测量、可靠性与 judges

• Evaluating Large Language Models Trained on Code / HumanEval 与 pass@k
• τ-bench：pass^k 的原始定义与 tool-agent reliability
• ReliabilityBench 预印本：语义扰动与故障曲面扩展
• MT-Bench / Chatbot Arena：LLM-as-a-Judge 与已知偏差
• JudgeBench：客观正确性 pair 的 judge benchmark
• Judging the Judges（arXiv v2；TMLR 2026）
• BabelJudge v1 预印本：多语言与 trajectory perturbation
• Agent-as-a-Judge survey
• AgentRx：trajectory invariant 与 critical-step diagnosis

Coding benchmark 与 validity

• SWE-bench 原始论文
• SWE-bench 官方数据与 harness 仓库
• OpenAI：Why SWE-bench Verified no longer measures frontier coding capabilities
• OpenAI：Separating signal from noise in coding evaluations
• OpenAI：A shared playbook for trustworthy third-party evaluations
• Terminal-Bench 2.1 官方 release note
• Terminal-Bench 2.1 官方 dataset / leaderboard 仓库
• SWE-Lancer 原始论文
• SWE-Lancer 官方介绍与 2025-07 update
• SWE-Lancer 当前官方 runnable dataset
• SWE-Explore
• Agent Retrieval Bench
• RACE-bench
• DeepSWE
• RoadmapBench
• Long-Horizon-Terminal-Bench
• PERFOPT-Bench
• FixedBench / Coding Agents Don't Know When to Act
• Tencent WorkBuddy Bench
• AgentLens

Harness、trace 与 learning loop

• Harness-Bench
• Claw-SWE-Bench
• Codex 官方仓库
• Codex exec --json JSONL event 实现
• Claude Code 官方 extension surface
• Claude Code 官方 CLI stream-json / budget contract
• Claude Code 官方 hooks lifecycle
• Claude Code 官方 sandbox / managed controls
• pi coding-agent SDK / session events
• pi extension / tool surface
• pi compaction contract
• OpenTelemetry GenAI Semantic Conventions
• OpenTelemetry GenAI client span definitions（Development）
• OpenTelemetry GenAI agent/framework span definitions（Development）
• Cursor Agent Trace RFC
• ToolVerse
• Google Research：ReasoningBank

Kimi 一手资料

• Kimi Code 公开仓库
• Kimi K3 公开仓库与 evaluation disclosure
• Kimi Code loop service
• Kimi Code tool executor
• Kimi Code wire journal
• Kimi Code context memory
• Kimi Code full compaction

19. 最终自检：能回答这些，才算真正掌握

• 能否先写 claim，再选择 benchmark，而不是反过来？
• 能否分别审 construct、task、oracle、protocol 与 statistics？
• 能否解释为什么 pass@k 上升和 pass^k 下降可以同时发生？
• 能否让每个 score 回到 exact model-harness-environment-budget？
• 能否从最终 symptom 找到有反事实证据的 first bad decision？
• 能否让 trace 关联 intent、effect、receipt 和 verifier，同时不泄露源码/secret？
• 能否把一个 failure cluster 变成可复现 task、机制改动、regression gate 和 canary？
• 能否解释 static replay 的 off-policy 限制？
• 能否识别 production trace 的 selection、survivorship、judge 和 feedback-loop bias？
• 能否区分“修复已知 regression”与“对未见任务泛化”？
• 能否在 benchmark 分数与用户指标冲突时，指出缺失的 population/construct mapping？
• 能否明确说出某份 eval 不能支持什么结论？

一句话收束：

顶级 Agent eval 的能力，不是把运行压成一个分数，而是把现实任务、系统配置、外部证据、因果轨迹和发布决策连成一条可反驳、可复现、可持续学习的链。