对于coding-agent，如何进行eval，哪些指标需要关注，哪些开源项目可以用来eval

举个例子：让 coding agent 修复“登录接口接受空密码”的 bug。 一次有效的 eval，不是看它有没有说“修好了”，也不是看生成的代码像不像标准答案，而是把它放进固定版本的仓库，让它自己读代码、修改、运行测试，最后由独立的评测程序验证： 空密码和缺失密码是否被拒绝，正常登录是否仍然可用，有没有通过删测试、关闭鉴权来蒙混过关，以及整个过程用了多少时间和钱。 coding-agent eval 的核心，就是评估“在指定环境和预算内，把任务真正做对的能力”。 一、如何设计 eval 先区分你在评估什么。 如果比较模型，应尽量固定 agent 框架、提示词、工具和预算，只换模型。 如果比较整个 coding agent，例如不同 CLI 产品或者自己开发的 agent，就评估完整系统：模型、上下文管理、工具调用、重试策略都会影响结果。分数不能全部归因于底层模型。 具体流程可以这样设计： 任务集：每条任务包含需求描述、仓库起始 commit、依赖环境、验收条件和预算。覆盖修 bug、加功能、重构、补测试等实际场景，按语言、任务类型和难度分组。 运行环境：每次尝试从干净的容器或虚拟机启动，固定依赖、网络策略、工具权限、超时和最大花费。不要让不同任务共享上次留下的改动或记忆。 执行阶段：让 agent 自主完成任务，保存最终 patch、工具调用记录、测试执行结果、token、费用和耗时。 判分阶段：把 patch 放到干净的评测环境，用可信的测试和检查程序验收。隐藏验收测试不能被 agent 修改，要求必须能从题目说明中推导出来，不能靠未公开的奇怪约束卡它。 最后做失败归因：是没定位到问题、实现错误、引入回归、工具调用失败，还是环境本身坏了。环境失败要单列，不能静默删掉，也不能一律算模型不会做。 特别注意：agent 自己写的测试可以作为产物，但不能作为唯一正确性依据，否则它可能把实现和测试一起写错。 二、哪些指标最重要 我会优先看以下几类，而不是只看一个总分。 任务解决率：Resolve rate / pass@1 这是主指标。一次完整 agent 运行，在规定预算内完成全部验收条件的任务比例。 这里的“一次”不是一次模型调用。agent 在这次运行内部多轮读文件、改代码、跑测试，都属于同一次尝试。 修 bug 时通常同时要求： FAIL_TO_PASS：原本失败的目标测试通过。 PASS_TO_PASS：指定的原有回归测试继续通过。 不要只报“测试通过率”。一个任务通过了 99 个测试，却没通过唯一验证核心需求的测试，仍然没解决。 重复运行的稳定性 同一任务要独立跑多次，避免某次碰巧成功。 pass@k 表示 k 次独立尝试中至少一次成功的概率。 pass^k 表示 k 次尝试全部成功的概率。 例如同一题跑 5 次，只成功 1 次，“至少成功一次”很好看，但稳定性很差。 如果真实产品只给用户一个最终结果，优先看 pass@1。若系统会生成多个候选再挑选，必须把挑选机制也纳入评测；隐藏测试帮你挑出的 pass@k，不等于产品实际交付成功率。 成本与效率 关注每任务费用、输入/输出及缓存 token、端到端耗时的 P50/P95、超时率。 再看一个很实用的指标： 每成功任务成本 = 全部尝试的总费用 ÷ 成功任务数。 比如花了 100 元，解决 20 个任务，就是每成功任务 5 元，失败任务消耗也要算进去。 比较时最好同时报告固定预算下的成功率，避免一个系统靠无限重试压过另一个。 回归、质量与安全 关注引入回归的任务比例、编译/类型检查结果、安全扫描结果、需求遵循情况。 可维护性、是否过度设计，可以用明确 rubric 的 LLM judge 辅助，再用人工抽检校准。功能正确性仍然优先交给可执行测试，不要让另一个模型看一眼就决定“代码正确”。 修改行数、修改文件数可以帮助诊断，但不能简单当成“越少越好”。 过程指标 记录工具调用失败、重复无效调用、上下文溢出、卡循环、异常退出、人工介入次数，以及声称测试通过但没有实际证据的情况。 这些主要用于解释为什么失败，不要强制 agent 必须照某条标准轨迹操作。不同但有效的解题路径应该被允许。 统计口径 同时报告任务数量、重复次数和置信区间，并按语言、仓库、任务类型拆分成绩。 对比两个版本时尽量用同一批任务做配对比较。样本很少时，多通过一两题不一定代表真实提升。 三、哪些开源项目可以用 这里要区分“题库”和“运行评测的框架”。 SWE-bench：评估仓库级 issue 修复 给 agent 一个真实仓库和 GitHub issue，产出 patch，再通过 Docker 环境中的测试判定。 Verified 是人工验证过的 500 道任务，主要来自 Python 仓库，适合评估代码定位、跨文件修改和回归修复。官方仓库包含评测 harness。 局限是它不能代表所有语言和所有开发工作，更不能把这个分数直接等同于日常工程能力。 https://github.com/swe-bench/SWE-bench SWE-bench Pro：评估更复杂的长程工程任务 公开集包含 731 个任务，覆盖更复杂的代码库和多文件改动，适合观察 agent 能否持续理解需求、跨模块修改并完成验证。 注意使用公开集，不要把完整 benchmark 的任务总量当成可本地运行的公开数据量。 https://github.com/scaleapi/SWE-bench_Pro-os Terminal-Bench：评估终端里的端到端技术任务 不局限于提交修 bug 的 patch，还包括构建、配置、调试等终端工作。适合你这种 agent 不只编辑文件，还会跑 shell、处理依赖和操作环境的情况。 但它测的是更广义的终端任务能力，不是纯粹的代码生成能力。Terminal-Bench 2.0 的官方运行框架是 Harbor。 https://github.com/harbor-framework/terminal-bench Harbor：评测基础设施，不是单独的题库 支持接入 Claude Code、Codex CLI、OpenHands 等 agent，也支持构建自己的任务和环境、并发执行及容器化评测。 如果你在开发自己的 coding agent，想把“启动环境、调用 agent、执行验收、保存结果”统一起来，它很值得看。自定义 agent 需要按其接口适配，并非任意程序都能零配置跑。 https://github.com/harbor-framework/harbor 怎么选可以归结为： 修仓库 issue，用 SWE-bench；更复杂的长程修改，看 SWE-bench Pro；终端综合任务，用 Terminal-Bench；要搭自己的评测流水线，看 Harbor。 公共 benchmark 用来提供外部参照，自己的真实任务集用来判断产品是否好用。公开题目可能存在训练污染，而且任务分布未必符合你的用户，不能只靠排行榜下结论。 评测方法参考 Anthropic 2026 年 1 月的这篇文章，里面专门讨论了 coding agent、判分器和重复运行指标： https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents