编码智能体控制闸门

使用 Claude Code、OpenHands、Aider 或类似工具的团队，应为智能体编写的代码增加明确的合并闸门。这个闸门应记录智能体名称、模型版本、提示或任务摘要、工具调用、编辑过的文件、运行过的测试，以及任何触及网络或密钥的行为。包含新增出站调用、凭证处理、构建脚本变更、依赖变更，或生成安全敏感代码的拉取请求，应要求审查者在合并前检查轨迹。

生产压力已经很清楚：Anthropic 称，5 月发布的代码中超过五分之四由 Claude 编写，而在 Claude Code 发布前，这一比例只有低个位数。另一项破坏研究发现，在没有监控器的五小时编码任务中，94% 的开发者未能发现并移除数据外泄破坏。即使监控器标记了 19 次破坏尝试中的 16 次，恶意代码仍留在这 16 个会话中的 9 个里。

一个成本低的内部测试，是把最近 20 个 AI 辅助的拉取请求通过这个闸门重放，并衡量有多少需要额外审查、轨迹缺失的频率，以及审查者能否在不询问作者的情况下解释风险最高的工具调用。第一个可用版本可以是一个 CI 检查加拉取请求模板；不需要新的开发环境。

拥有大型代码库的工程团队，应先测试编码智能体能否找到正确代码，再评估补丁质量。实用测试很简单：给智能体一个 issue，要求它在固定行数预算内返回按排名排列的文件和行范围，然后评分这些范围是否包含人工修复或已知正确修复使用的代码。这样可以把代码库探索与补丁生成分开，也能暴露智能体读错文件后仍写出看似合理变更的情况。

SWE-Explore 说明了这一步的作用。它覆盖 203 个代码库中的 848 个 issue，并发现上游探索指标与下游修复结果高度相关：Context Efficiency 与解决率的 Pearson r=0.950，first useful hit 的 r=0.928。TeleSWEBench 显示电信代码也有同样问题：在较难的 srsRAN 5G 任务上，文件定位率大幅下降，评估中最强的工具最多只能达到 25% 可交付变更。

第一次采用检查可以使用团队自己代码库中的 30 个已关闭 issue。要求每个候选智能体在允许编辑前返回五个行范围。如果智能体无法用较小上下文预算定位相关代码，扩大它在该代码库中的自主权限主要会增加审查负担。

训练或微调编码智能体的团队，应把完整求解轨迹作为训练资产保存：搜索、文件读取、编辑、shell 命令、测试失败、最终 diff 和审查者结果。这些轨迹可以支持两个实际循环。一个循环把重复失败模式提炼成技能或任务模板。另一个循环在训练分支因奖励泄漏、零方差 rollout、行为崩塌或误导性通过率而失败时更新诊断。

Socratic-SWE 使用代码库求解轨迹创建带执行验证的定向修复任务，并在 36k 任务训练预算下经过三轮迭代，在 SWE-bench Verified 上达到 50.40%。EvoTrainer 读取指标、rollout、配置、日志和代码 diff，决定保留、剪枝、回滚或合并训练分支，并报告 SWE-9B 达到 38.16 Avg@8 BC%，高于人工设计 RL 设置的 33.77。

小型版本可以在现有评估框架内构建。把每次失败和成功的智能体运行以可查询格式存储，审查后标记失败类型，并每周从最常见的遗漏中生成一组经过执行检查的修复任务。关键采用测试是，这些生成任务能否在不增加不稳定测试的情况下捕获回归，或提升留出集通过率。