编码代理控制门

为新的内部工具和小型产品模块构建一个先写合同的仓库生成器。这个做法的关键变化是，让代理在写文件前先写一份可机器检查的规格：需要的模块、文件映射、API、类型签名和状态定义。Contract-Coding 给出了这样做的直接理由。在 Greenfield-5 上，它报告 Gomoku 和 Plane Battle 的成功率都是 100%，City Sim 为 87%，Snake++ 为 80%，Roguelike 为 47%，并且在这个集合里最难的任务上明显优于 OpenHands、MetaGPT、ChatDev 和 FLOW。速度结果也对想缩短迭代周期的产品团队有用：Hierarchical Execution Graph 让 Roguelike 的成功率保持在 47%，同时把运行时间从 510 秒降到 232 秒。

最先会用到它的是那些生成新的多文件服务、管理工具、游戏原型或迁移脚手架的团队，因为这类任务里跨文件一致性比本地语法更容易出错。一个简单的测试方法是：拿十个现在通常要经过多轮代理修复的绿色项目任务，加上一份必须在代码生成前审批或自动检查的合同工件，然后测文件级一致性、重跑次数和到可通过仓库的耗时。同一组证据也说明了它的边界：当任务可以拆成明确接口和模块边界时，这种方法最有用。带有密集策略逻辑或业务规则冲突的任务，仍然需要合同之上的另一层控制。

给代码生成加上一层安全评分，再配上受限编辑工具。DeepGuard 给出了一条具体的模型侧路径：聚合多个 Transformer 层的安全信号，然后在推理时加一个很便宜的偏置，让模型更偏向安全 token，同时几乎不损失功能正确性。在五个代码 LLM 上，它把安全且正确的生成率平均比 SVEN 提高了 11.9%；在 Qwen2.5-Coder-3B 上，它把 sec-pass@1 从 70.47% 提到 80.76%，同时把 pass@1 保持在接近基础模型的水平。

这足够支持一个窄一些的产品方案，面向把内部编码代理放进常见安全敏感代码库的团队：Web 处理程序、认证流程、文件操作、数据库访问和依赖拼接。Zup 的部署论文给出了工具侧的补充。它的内部代理依赖定向字符串替换编辑、分层 shell 限制、审计日志，以及在更高自治之前的审批模式。实际落地可以这样做：把高风险文件路由到安全强化过的模型路径，保持编辑为补丁式，并在早期阶段要求 shell 和写入操作先审批。一个便宜的检查方法是，回放几百个已接受的代理任务，带上安全审查标签，然后在扩展权限前比较漏洞发现、通过率和人工返工。

在含糊的编码任务前加一个明确的澄清关卡，并把它当作产品功能来评估。HiL-Bench 显示，这个缺口已经大到值得单独做一套流程。在 SQL 任务上，完整信息下能拿到 86% 到 91% pass@3 的模型，在必须决定何时调用 ask_human() 时会掉到 5% 到 38%。在 SWE 任务上，完整信息下能到 64% 到 88% 的模型，在选择性升级求助时会掉到 2% 到 12%。没有任何模型在 SWE 上的 blocker recall 超过 50%。问题也不是少见边缘情况。这个基准包含 1,131 个经过人工验证的 blocker，平均每个任务 3.8 个，类型包括缺失信息、含糊请求和矛盾信息。

实现方式很直接：在涉及需求不清、隐藏策略选择或仓库上下文不完整的工单上，执行前先做 blocker 检查。代理应该暴露候选 blocker，提出有针对性的问题，并在问题没有得到回答时暂停。评估也不能只看成败。Ask-F1、blocker recall 和 question precision 应该和任务完成率一起出现在内部评分卡上。旁边的日志研究从另一个角度指向同一个操作问题。代理会漏掉非功能性要求，后续由人工补救：在 58.4% 的仓库里，人工修改日志的次数比代理更多，代理对建设性日志请求的遵守失败率是 67%，而 72.5% 的生成后日志修复由人工完成。把代理接进 issue-to-PR 流程的团队，在开始编码前需要正式的澄清步骤，而不只是一个模型很少用好的聊天框。