可运行的验证工件

仓库级编码代理应该返回补丁，以及证明它有效的精确执行记录。AgentForge 最能支持把这件事当作产品要求，而不是研究层面的附带优化：每次代码变更都会先在网络隔离的 Docker 沙箱中运行，系统在 SWE-bench Lite 上达到 40.0% 的解决率，比单代理基线高 26 到 28 个百分点。这里更实用的交付物是一个面向 CI 的执行凭证层，保存补丁、生成的测试、沙箱配置、stdout 和 stderr，以及每次尝试的 fail-to-pass 和 pass-to-pass 结果。

这适合已经在试仓库代理、又被评审时间拖慢的团队。评审者不需要再看一段“为什么这个修复应该有效”的总结；他们需要的是可回放的记录，能看出实际运行了什么、有没有引入回归。第一个便宜的测试范围要收窄：先要求代理在一种任务上附带执行凭证，比如 flaky test 修复或小型 bug 修复，再把评审通过率和合并时间，和只提供文本与 diff 的代理输出做对比。AnalysisBench 从另一个角度支持同样的边界。它的最佳代理只有在出现工具特定证据后才停止，而自验证仍把成功率高报了 15%，这说明不能让代理在没有外部工件检查的情况下自己宣布完成。

安全团队可以在 LLM 找 bug 和人工分流之间加一道可执行 PoC 门禁。AnyPoC 说明了这层为什么有用。它接收候选 bug 报告，要么生成一个带日志、可重复运行的 proof-of-concept，要么直接拒绝该报告，而且能覆盖 Chromium、Firefox、LLVM、OpenSSL、SQLite、FFmpeg 和 Redis 在内的 12 个大型系统。报告中的收益很实际：对真实 bug 报告，能产出 1.3 倍更多有效 PoC；对假阳性，能拒绝 9.8 倍更多；还把 45 个生成的 PoC 采纳为正式回归测试。

最直接的交付物是一个验证服务：接收代理生成的 bug 报告，在隔离环境中启动目标项目，尝试生成并重放 PoC，然后写回两种结果之一，确认并附上可运行工件，或拒绝并附上失败证据。这对内部 AppSec 团队和维护者很有用，他们已经收到太多只靠文字描述、不能直接相信的报告。一个简单的首发版本可以先选一个代码库里的一个 bug 类，接入稳定 CI，再比较每个确认发现的分析工时，以及那些本来会进入人工评审的被拒绝报告比例。

采用分析器、fuzzer、符号执行工具或 profiler 的团队，需要的是能完成完整设置并展示工具特定输出的代理，而不是在构建完成或帮助页之后就停下来的代理。AnalysisBench 对失败模式说得很直接：基线代理混淆了阶段，在长日志里丢掉了根因，还会在只看到表面信号后就宣布成功。定制的 AnalysisAgent 在 35 个工具-项目任务上达到 94% 的验证成功率，而最佳基线是 77%，方法是使用明确的工作流阶段、每轮只做一个动作、确定性的日志压缩，以及基于证据的完成检查。

这指向一个面向平台工程和开发效率团队的具体支持产品：一个 analysis-runbook 代理，负责安装工具、准备项目、记录精确命令和环境，并在预期的分析工件出现之前拒绝结束。第一个便宜的检查方式是选两个内部难工具，它们 adoption 低是因为设置脆弱，然后测量这个 runbook 代理是否能提高从未配置过这些工具的工程师的首次成功率。价值不在模型有多聪明，而在每个阶段都足够清楚，环境配置失败时可以直接排查。