Beyond Pass@k：Agentic Code Generation 的可靠性与安全评测

Beyond Pass@k：Agentic Code Generation 的可靠性与安全评测

一句话结论

Beyond Pass@k 指出 coding-agent benchmark 里一个很容易被忽略的统计错误：pass@k 的 n 应该是独立 rollout 次数，而不是同一次提交里的单元测试数量。它提出 reliability@k 与 security-adjusted reliability@k，直接补强 Agent-Benchmarks 对重复次数、严格任务成功和安全性的要求。

为什么对用户重要

用户正在关注企业内部 coding-agent benchmark。内部评测若把测试数量误当成独立尝试次数，会把“一个 patch 通过很多测试”误读成“多次尝试稳定解决任务”。这会高估 agent 可靠性，尤其危险于自动合并、自动迁移和长期 loop 场景：一次 lucky pass 或单一 hidden-test pass rate 不能证明 agent 在团队私有仓库上稳定、安全地完成任务。

机制 / 一阶原理

pass@k 的核心假设是从 n 个独立样本里抽 k 个，至少一个正确的概率。如果 n 被替换成同一个提交里的测试用例数量，统计对象就变了：测试用例不是独立 agent rollout，也不能代表 agent 多次尝试的分布。reliability@k 把 n 重新定义为独立 rollout，c 定义为完全通过的 rollout 数，从而测量“重复尝试下至少一次严格解决任务”的概率。

security-adjusted reliability@k 再加一层：正确不等于安全。一个 rollout 即使功能通过，也可能引入高严重度不安全模式；因此 benchmark 应把 functional correctness 和 security scanner / review verdict 组合成更严格的成功条件。

与已有概念的关系

• 对 Agent-Benchmarks：补充 pass-rate 之外的重复运行和统计定义边界。
• 对 Harness-Engineering：harness 不只要跑测试，还要定义独立 rollout、停止条件、安全 scanner 和严格 task-resolution verdict。

对 Hermes / llm-wiki 的可执行启发

1. 为本地 coding-agent eval 记录 attempt_id、seed/config、harness_version、strict_task_resolved、hidden_tests_passed、security_verdict。
2. 报告中避免把“测试项通过率”称为“任务解决率”；两者必须分开。
3. 对高风险自动化至少重复运行代表性任务，或明确标注 single-rollout evidence，不把它硬化为可靠性结论。
4. wiki radar 自评也可借鉴：一次成功入库只能证明本轮完成，不能证明 cron/rule 长期可靠；可靠性需要多日/多样本 receipts。

失败模式 / 边界

• 本轮只读取 abstract/metadata，未完整审查数学推导、实验设置和 scanner 规则。
• security-adjusted reliability@k 依赖 scanner 能力；scanner 弱会让安全调整失去区分度。
• 独立 rollout 的定义需要控制缓存、上下文、随机性、任务状态和 harness 版本，否则“独立”只是名义上的。

深度判断

晋升为正式 source 页，因为它直接击中 benchmark integrity：独立重复次数、严格任务成功、安全调整和统计语义，都是用户构建企业内部 coding-agent benchmark 时必须避免的坑。

写入记录

• 2026-08-29 09:01 CST：根据 arXiv abstract/metadata 新增 Beyond Pass@k 分析，提炼 reliability@k、security-adjusted reliability@k 和内部 coding-agent benchmark 的统计边界。