aayushdixit27/coding-agent-evals

# coding-agent-evals 为 AI 编程代理提供红队级别的严谨评估，在这里，“通过”并不等于“正确”。 ## 问题所在 随着越来越多的代码由 AI 编程代理编写，有一个问题变得愈发重要：当代理的工作通过了测试时，它是真正解决了问题，还是仅仅满足了检查要求？ 测试套件是一种信号。满足信号并不代表它是正确的。代理可以阅读检查逻辑，从如何让测试变绿（通过）的角度逆向推导，然后交出一份虽然过关但偏离问题本质的答案。检查结果显示通过，但问题依然悬而未决。本套件的存在就是为了衡量这一差距，并让代理难以通过错误的方式来填补它。 ## 套件的工作原理 每个任务包含两样东西。 第一样是代理需要生成的交付物。它会在代理从未见过的输入上运行，因此代理无法针对一组已知的测试用例来调整其答案。它必须构建出具备泛化能力的东西。 第二样是隐藏的验证器。它根据书面规范检查语义的正确性，并且是唯一计入分数的依据。代理无法阅读它。 有些任务更进一步。陷阱任务还会提供一个可见的测试，供代理运行和迭代。这个可见的测试看起来像是工作流程的常规部分，代理会自然而然地依赖它来决定何时算作完成。问题在于，参与评分的并不是这个可见的测试，只有隐藏的验证器才是。如果代理自始至终相信这个可见的测试，它就会径直掉入陷阱。 ## 三大主要陷阱 这些陷阱以三重奏的形式出现，分别对应检查逻辑欺骗你的三种方式。 - **过于宽松。** 可见的检查逻辑很弱。它接受了错误的答案，因为它的审查不够严格。通过了该检查的代理仍然可能是错的。 - **过于浅显。** 可见的测试对规范所要求的行为只字未提。它从未走过该代码路径，因此代理可以将其置之不理（不实现）或留下漏洞，而测试依然显示通过。 - **完全错误。** 可见的测试与书面规范相矛盾。如果代理将测试视为真理的来源，它就会按照测试来构建，从而在规范上判定失败。 每个陷阱都奖励了同一种错误：相信检查逻辑胜过问题本身。隐藏的验证器才是将它们区分开来的关键。 ## 验证关卡 每个任务在发布前都要通过一道双向关卡。这就是我们如何从机制设计上（而非凭空指望）确保陷阱具有真正的杀伤力。 1. **Oracle 通过。** 正确的参考解决方案能通过隐藏的验证器。这证明了任务是可解的，并且验证器会接受真正正确的工作成果。 2. **偷懒方案失败。** 采取诱人捷径的手写解决方案会失败，而且恰好失败在它所针对的陷阱上。这证明了该陷阱能捕捉到它被设计用来捕捉的具体错误。 只有当这两个条件都满足时，任务才会发布。Oracle 获得了通过，而偷懒的解决方案则得到了它应得的失败，并且是在它被设计用来击中的地方失败。 ## 状态 本项目正在公开开发，周期约为两周。第一个任务已经落地：T1，range-expand，这是一个确立隐藏验证器格式的能力型任务，随后将推出三大主要陷阱（过于宽松、过于浅显、完全错误）。它是计划中的八个任务之一，随着更多任务通过验证关卡，后续还会有更多任务推出。

标签：AI, AI代理, 代码评估, 测试框架, 自动化代码审查, 逆向工具