如何设计抗污染、可信的代码 Agent 评估系统？

设计抗污染的代码 Agent 评估系统需要从污染来源识别、防污染设计、评估分数治理三个维度入手。污染来源包括训练数据泄露、缺陷测试污染、评分逻辑漏洞三类。防污染设计采用四原则：动态任务生成避免固定测试集被记忆、隐藏测试集在评估时动态注入未公开任务、审计追踪记录模型训练数据来源并与评估集交叉检查、评分鲁棒性设计难以被 hacking 的指标。评估分数治理需要建立基准版本管理、独立审计团队、退役标准和透明报告机制。SWE-bench Verified 退役与 Pro 审计 731/286/30% 的数字说明，即使是顶级基准也需要持续审计和版本迭代，评估系统是需要持续监控和治理的活系统。

一、污染来源识别：三分类框架

代码 Agent 评估的污染来源可分为三类：

1. 训练数据泄露（Training Data Contamination）：模型在训练阶段见过评估任务的答案。这是最常见也最危险的污染形式，因为它使评估分数完全失去意义——模型不是在展示能力，而是在回忆答案。SWE-bench Verified 退役的核心原因即是训练数据泄露。检测方法包括：n-gram 重叠检查（评估任务文本是否出现在训练数据中）、困惑度测试（模型对污染任务的困惑度显著低于未污染任务）、以及训练数据来源审计（要求模型提供方公开训练数据来源并与评估集交叉检查）。

2. 缺陷测试污染（Defective Test Contamination）：测试用例本身有 bug 或过于简单，无法有效区分模型能力。例如测试用例只检查函数签名而不检查实现逻辑，或测试用例覆盖的边界条件过少。SWE-bench Pro 审计发现 731 个任务中 286 个存在污染（39%），其中相当比例属于此类。检测方法包括：人工审查（随机抽样检查测试用例质量）、对抗性测试（用随机生成的错误代码提交，检查是否能通过测试）、以及测试覆盖率分析（检查测试用例是否覆盖了任务要求的所有边界条件）。

3. 评分逻辑漏洞（Scoring Logic Vulnerability）：评分指标可被 hacking 而非反映真实能力。例如评估指标是'通过测试用例数量'，模型可能学会写针对测试用例的特化代码而非通用解决方案。检测方法包括：对抗性评估（用已知能力的模型测试评分逻辑是否可被 hacking）、指标相关性分析（检查评分是否与人类判断一致）、以及多维度评估（不依赖单一指标，而是组合多个指标如代码质量、可维护性、性能等）。

二、防污染设计：四原则

1. 动态任务生成（Dynamic Task Generation）：避免固定测试集被记忆。方法是设计任务生成器，每次评估时动态生成新任务。例如代码生成评估可以动态生成新的函数签名和测试用例，而非使用固定任务。挑战在于动态生成的任务需要保证质量和难度一致性，需要人工审查或自动化质量检查机制。

2. 隐藏测试集（Hidden Test Set）：评估时动态注入未公开任务。方法是维护一个持续更新的隐藏任务池，评估时随机抽取。隐藏任务池需要定期更新（如每月更新 10%），并在发现污染后立即剔除。SWE-bench Pro 的审计机制即是此类设计的实践。

3. 审计追踪（Audit Trail）：记录模型训练数据来源并与评估集交叉检查。方法是要求模型提供方公开训练数据来源（或至少提供训练数据的统计特征），并与评估集进行交叉检查。挑战在于训练数据通常规模巨大（数 TB），交叉检查需要高效的相似度检测算法（如 MinHash LSH）。

4. 评分鲁棒性（Scoring Robustness）：设计难以被 hacking 的指标。方法是采用端到端任务完成指标（如 SWE-bench 的'解决真实 GitHub issue'），而非单步准确率（如'通过测试用例数量'）。端到端指标更难被 hacking，因为它要求模型完成整个任务流程而非仅通过局部测试。同时可以引入多维度评估（代码质量、可维护性、性能、安全性等），降低单一指标被 hacking 的风险。

三、评估分数治理：四机制

1. 基准版本管理（Benchmark Versioning）：建立基准的版本演进机制。例如 SWE-bench 从 Verified 演进到 Pro，每次版本更新都伴随污染检测和任务剔除。版本管理需要公开版本变更日志（哪些任务被剔除、原因是什么），使评估分数的可比性透明。

2. 独立审计团队（Independent Audit）：由第三方独立团队定期审计基准质量。审计团队应独立于基准维护方和模型提供方，避免利益冲突。审计结果应公开，包括污染率、剔除任务数量、检测方法等。SWE-bench Pro 的审计即是此类机制的实践。

3. 退役标准（Retirement Criteria）：当污染率超过阈值时自动触发退役。例如当污染率超过 20% 时，基准应被标记为'不可信'并停止用于模型比较。退役标准应预先定义并公开，避免事后争议。

4. 透明报告（Transparent Reporting）：公开污染检测方法与退役决策。透明报告应包括：检测方法（如何发现污染）、污染率（多少任务受影响）、剔除决策（哪些任务被剔除、原因是什么）、以及重新评估建议（是否需要在更新后的基准上重新评估模型）。

四、SWE-bench 事件的教训

SWE-bench Verified 退役与 Pro 审计 731/286/30% 的数字（731 个任务中 286 个存在污染，最终 30% 任务被撤销）说明三个教训：

教训一：污染是系统性问题。39% 的污染率说明污染不是个案，而是基准设计和维护中的系统性缺陷。任何基准都可能存在污染，关键在于是否有持续审计机制。

教训二：审计是必要的。如果没有 Pro 版本的审计，Verified 版本的污染将继续影响模型评估。独立审计团队是发现污染的关键机制。

教训三：评估系统是活系统。评估系统不是一次性设计，而是需要持续监控和治理的活系统。基准需要定期更新、审计、退役，评估分数需要随基准版本演进重新计算。

五、工程落地建议

对于企业级代码 Agent 评估系统，建议采用以下落地路径：

第一阶段：基础防污染。采用隐藏测试集 + 审计追踪，确保评估任务未被训练数据覆盖。建立基准版本管理机制，公开版本变更日志。

第二阶段：动态评估。引入动态任务生成器，每次评估生成新任务。建立独立审计团队，定期审计基准质量。

第三阶段：治理机制。定义退役标准（如污染率超过 20% 自动退役）。建立透明报告机制，公开污染检测方法和退役决策。

第四阶段：多维度评估。引入代码质量、可维护性、性能、安全性等多维度指标，降低单一指标被 hacking 的风险。

误区一：认为固定测试集足够。固定测试集容易被记忆，模型可能在训练数据中见过任务答案。SWE-bench Verified 退役即是教训。必须采用动态任务生成或隐藏测试集机制。

误区二：认为测试用例数量越多越好。测试用例数量多不等于质量高。SWE-bench Pro 审计发现 39% 污染率，说明大量测试用例可能存在缺陷。关键在于测试用例的质量而非数量。

误区三：认为评分指标越简单越好。简单指标（如'通过测试用例数量'）容易被 hacking。应采用端到端任务完成指标，并引入多维度评估降低单一指标被 hacking 的风险。

误区四：认为基准设计是一次性工作。基准需要持续审计和版本迭代。SWE-bench 从 Verified 到 Pro 的演进说明，即使是顶级基准也需要持续监控和治理。评估系统是活系统，不是一次性设计。