可执行的仓库就绪性

仓库级编码代理需要一个独立的环境搭建阶段，并为它单独设定预算、遥测和通过标准。本周的证据表明，搭建失败是一个独立的运维问题，不是代码生成前的一小段准备工作。RAT 在一个覆盖 2,000+ 个仓库的基准上报告了可执行环境搭建成功率：Python 为 63.2%，Java 为 41.3%，Rust 为 98.7%，JS/TS 为 68.7%，并且相对使用相同底座模型的 SWE-agent 有明显提升。成本也很明确：在一个 Python 设定下，完整 RAT 平均使用约 421.9K tokens，耗时 24.3 分钟。在内部仓库中部署编码代理的团队可以把这转成一个具体的流程变化：把环境配置当作一级步骤来运行，记录仓库是否变为可运行状态，并且当搭建从未成功时，不再继续评估下游补丁质量。

这里可落地的构建是一个仓库引导 worker：检测语言、选择基础镜像、在沙箱中安装依赖，并输出机器可读的搭建记录，其中包含尝试过的命令、修改过的文件、测试或 smoke check 状态，以及失败类别。这类输出既能用于评测，也能驱动面向用户的产品行为。一个低成本测试方法是，从内部仓库中抽取一个混合样本，测量这个 worker 在任何代码编辑代理启动前，把仓库带到可运行状态的比例。如果这个比例很低，那么补丁生成指标就在掩盖主要失败模式。

仓库级代码生成的评测现在可以围绕结构化设计输入和可运行的仓库测试来构建，并按仓库规模分开评估。RealBench 给出了修改评测 harness 的直接理由：当前模型在完整仓库生成上的平均 Pass@1 只有 19.39%；在低于 500 LOC 的仓库上，表现还能保持在 40% 以上；超过 2000 LOC 后，则降到 15% 以下。它还报告称，整体式生成在较小仓库上效果更好，而仓库变大后，增量式生成效果更好。

对模型团队和应用平台团队来说，一个具体可做的构建是内部基准：从需求说明加包图和类图开始，再按测试通过率、覆盖率和规模分桶来给生成仓库打分。关键的流程变化是停止只报告一个覆盖整个仓库的总分。小仓库和大仓库的行为差异已经大到足以让单一混合指标掩盖系统真正可用的范围。这也能形成一个直接的产品门槛：对小型、低依赖代码库允许端到端仓库生成；对更大的代码库，则要求按文件或按模块逐步规划。一个低成本检查方法是，在同一组任务上重新运行现有编码代理，分别对低于 1000 LOC 和高于 1000 LOC 的仓库单独计分，并比较整体式生成与增量式生成。

在继续加入更多记忆、反思或自评特性之前，代理团队有理由先建立一个独立的 harness 调参循环。HARBOR 在 Terminal-Bench 2 上的手动调参研究显示，这些组合很不稳定：全部 flag 关闭的基线通过了 89 个任务中的 15 个；一个包含 5 个原生 flag 的配置达到 17/89；加入自评 gate 后降到 13/89；再加入 ACON、Reflexion 和 PASTE 后降到 12/89。论文还指出，在生产风格代理中，harness 代码占实现的大头，其中一个被引用的审计给出的 Claude Code 比例约为 98.4%。

最直接的构建是为 harness 特性建立一个 flag 注册表和实验运行器，覆盖缓存模式、上下文压缩、轨迹回放、工具预测和自评 gate 等功能。每次运行都应记录启用的 flags、任务集版本、运行成本，以及在固定可执行基准上的通过数。这对那些不断给编码代理加特性、却只看最新版本在演示里是否感觉更好的团队很有用。一个低成本检查方法是，在一个稳定的终端或仓库基准上回放最近几次 harness 发布，看看最近新增特性到底提高了通过率，还是只增加了时延和上下文占用。