研究想法

面向编码代理的可执行保护措施

日 · 2026-04-28 · Software Intelligence

具体的切入点都在模型周边的代码编辑路径上:更窄的读取结果、专门的补丁执行、带测试的修复循环、可版本管理的 harness 变更,以及来自未覆盖代码的排序报告。团队在改变主开发流程之前,都可以先用现有仓库和可执行测试把这些点验证一遍。

3 个想法

将文件查看、补丁写入和测试修复拆开处理代码编辑

代码助手团队应该把仓库编辑拆成三个可衡量的步骤:一个只返回与任务相关代码块的查看器,一个应用高层补丁请求的编辑器,以及一个运行真实测试并把结构化失败反馈回修复流程的验证器。对于已经调用文件读取、grep、编辑和测试工具的 IDE 助手、CI 修复机器人和内部编码代理,这是一项可落地的改造。

SWE-Edit 给出了读写拆分的具体做法。它的 Viewer 接收路径和自然语言查询,只返回相关代码块;它的 Editor 接收路径和编辑指令,并应用修改。在 SWE-bench Verified 上,论文报告 resolved rate 从 69.9% 升到 72.0%,edit success 从 93.4% 升到 96.9%,推理成本下降 17.9%。SAFEdit 为带指令的代码编辑加入测试循环:Planner 写编辑计划,Editor 修改代码,Verifier 运行单元测试,最多进行三轮修复。它报告 EditBench 任务成功率为 68.6%,高于 60.0% 的 GPT-4.1 ReAct 基线。

一种低成本的落地测试,是在不改基础模型的情况下给现有编码代理加一层包装。把读取请求路由到返回代码块的查看器,把编辑请求路由到补丁执行器,在每次补丁后运行项目测试,并在固定问题集上比较 edit success、无关 diff 大小、resolved tasks 和 token 成本。Claude Code 的回归报告给出了一条实现层面的警告:Read 和 Grep 结果里反复出现安全提醒,会让子代理拒绝普通重构并浪费上下文。文件读取路径里的安全文本需要单独做回归测试,包括在良性仓库上的并行子代理运行。

基于 rollout 轨迹的文件级 harness 变更评审

运行编码代理的团队可以把 harness 当作需要评审的代码。把系统提示、工具说明、工具实现、中间件、技能、子代理设置和长期记忆都存成可编辑文件。在基准测试或内部任务 rollout 之后,把轨迹转成任务报告,把每个拟议的 harness 变更和它对应的失败关联起来,记录预期收益和回归风险,然后只在重放验证预测成立后保留这项变更。

Agentic Harness Engineering 给出了这个流程的具体评估方式。它把七类 harness 组件暴露为文件,使用清洗后的 rollout 轨迹生成证据,让 Evolve Agent 编辑 harness 文件,并为每次变更记录一份 manifest。下一轮会检查任务层面的结果,并在文件级回滚被拒绝的编辑。经过 10 轮迭代,论文报告 Terminal-Bench 2 的 pass@1 从 69.7% 升到 77.0%,覆盖 89 个任务。在 SWE-bench-verified 上,冻结后的 harness 在每次试验中使用的 token 少于种子 harness,同时整体成功率相近。

第一批用户是已经有代理轨迹、但通过临时改 prompt 处理 harness 变更的工程团队。最小试点可以从 30 到 100 个代表性任务、一个带版本管理的 harness 文件目录,以及每次 prompt、工具、中间件、记忆或技能修改都必须附带的变更 manifest 开始。通过/失败检查应该包含 token 使用和回归案例,因为 AHE 的消融结果显示收益主要来自记忆、工具和中间件,而只改系统提示的版本表现低于种子配置。

来自未覆盖 Python 代码的排序 bug 报告

Python 维护者可以加一个预分诊任务,扫描当前测试覆盖之外的代码,并生成一个供人工审核的、经过排序的小型 bug 报告队列。这个任务应包含覆盖发现、LLM 生成的 issue 报告、复现步骤和建议修复、重新排序,以及对候选补丁的测试运行,这样会破坏现有测试的报告就会降权。

IssueSpecter 给出了这一流程的具体版本。SlipCover 找出未覆盖的 Python 代码段。GPT-5-mini 审查每个代码段,并生成包含严重性、受影响操作系统、复现步骤和建议修复的 issue 报告。筛选步骤保留每个项目的前几条报告,GPT-5-mini 再按影响范围、覆盖范围和紧急程度重新排序。在 13 个活跃的 Python 项目上,系统生成了 10,467 条报告。对 130 条排名靠前报告的人工审查发现了 49 个有效 bug、61 个需要进一步调查的问题和 20 条无效报告。论文报告,LLM 排序在 precision@3 上比规则排序高 50%,在 mean reciprocal rank 上高 41%。

这对测试套件较完整、但仍有持续未覆盖模块的项目最有用,尤其是维护者已经不信任原始 AI issue 洪流时。一个受控试点可以按周运行,默认不公开创建 issue,只把每个仓库排名前 3 的报告发给维护者,并附上覆盖位置、复现步骤、拟议修复和测试结果。评审指标应该是每个维护者小时的有效或可行动报告数,因为这些误报仍然需要人工分诊。