---
kind: ideas
granularity: day
period_start: '2026-07-06T00:00:00'
period_end: '2026-07-07T00:00:00'
run_id: materialize-outputs
status: succeeded
topics:
- coding agents
- software engineering
- agent evaluation
- open-source software
- agent security
tags:
- recoleta/ideas
- topic/coding-agents
- topic/software-engineering
- topic/agent-evaluation
- topic/open-source-software
- topic/agent-security
language_code: zh-CN
---

# 编码代理仓库控制措施

## 摘要
仓库所有者可以在编码代理已经造成运维负担的环节增加控制措施：重叠的拉取请求、混合信任级别的工具数据，以及遗漏长期仓库工作的评估。现有证据支持在 GitHub 和 CI 工作流中进行小范围、可测试的改动。

## 并发代理拉取请求的合并前冲突检查
使用编码代理的维护者应在审查前增加队列或检查，重放处于开放状态且由代理创建的拉取请求之间的合并操作。该检查可以对同时活跃的 PR 两两运行 `git merge-tree`，发布冲突摘要，并阻止修改相同源文件的低优先级代理 PR，直到第一个 PR 合并或关闭。

GitHub 数据显示了这一运维负担。在 AIDev-pop 中，带有代理创建 PR 的仓库中有 40.2% 出现了精确的时间重叠，这些重叠涉及 79.4% 的代理 PR。合并重放发现，同一代理 PR 对中有 19.8% 存在文本冲突，跨代理 PR 对中有 41.7% 存在文本冲突，发生冲突的文件大多是源代码。首次测试可以从两周开始：在代理会打开多个 PR 的仓库中运行该检查，再将冲突评论、CI 重跑次数和维护者执行 rebase 的工作量与此前两周进行比较。

### 资料来源
- Document 1776: 报告了 AIDev-pop 中代理创建拉取请求的重叠率，以及合并重放的冲突率。
- Document 1776: 说明了抽样合并重放的结果，并指出大多数冲突来自源代码变更。
- Document 1759: 显示维护者认为他人生成的 AI 代码更难维护，即使可观察到的仓库指标整体没有恶化。

## 编码代理使用的 GitHub 评论和工具响应的类型化信任边界
在 issue、拉取请求和 CI 输出上运行编码代理的团队，应将每个外部文本字段视为不可信数据，并为可信元数据设置单独的类型化封装。一个可行的实现是工具响应适配器：将作者、资源 ID、工具名称和执行历史传入由解析器管理的字段，同时将评论、日志、网页文本和模型可见的摘录保留为带引号的数据。该适配器还应拒绝或转义不可信字段中的类 JSON 分隔符、伪造标签、冒充工具输出的代码块，以及复制的界面标识符。

这项隔离应放在代理运行时中，不能只依赖提示词规则。关于代理数据注入的论文显示，攻击者可以在不可信内容中放入分隔符、类 JSON 结构、标签或伪造的元数据，使模型将其读取为可信的代理数据。论文报告的攻击包括伪造 GitHub issue 评论和针对编码代理的虚假工具响应，并在 Claude Code、Codex 和 Gemini CLI 上展示了远程代码执行和供应链攻击路径。一次低成本的验证可以重放论文中的分隔符注入和元数据伪造案例，测试团队自己的 GitHub issue 读取器和 PR 审查工具；如果不可信文本能够修改可信字段，就让构建失败。

### 资料来源
- Document 1770: 定义了代理数据注入，描述了伪造的 GitHub 评论和虚假工具响应，并报告了攻击成功率。
- Document 1770: 报告了针对编码代理的远程代码执行和供应链攻击路径，并指出可信数据与不可信数据之间缺少隔离。
- Document 1770: 解释了代理输入中可信元数据与不可信内容的区别。

## 带重建验证和长期进度日志的仓库代理评估运行
选择编码代理的工程团队，应在可重建的仓库沙箱中运行候选代理，配合真实测试、隐藏评测检查，以及覆盖数小时工作的进度日志。评估应记录代理是否搜索了正确的文件、定位了故障、生成了补丁、完成了验证、在失败后恢复，并在停滞时如实报告状态。可以先从五到十个已有已知修复方案和测试用例的内部缺陷开始。

几项新结果指向相同的评估方式。KAT-Coder-V2.5 报告称，AutoBuilder 将可执行环境构建成功率从 16.5% 提高到 57.2%，并按探索、定位、补丁质量、验证、恢复和诚实性筛选轨迹。EdgeBench 在 12 小时可执行任务上评估代理，发现早期进度可以较好地预测后续表现。EvoAgentBench 通过可复用的搜索、调试和验证过程连接任务，增加了迁移检查；现有自动记忆方法仍会出现负迁移。内部评分表应包括环境重建成功率、通过或失败结果、首次有效测试所需时间、补丁失败后的恢复情况，以及存储的过程对后续任务产生了帮助还是阻碍。

### 资料来源
- Document 1775: 描述了可执行环境构建、轨迹筛选，以及 AutoBuilder 成功率提升的报告结果。
- Document 1768: 描述了 12 小时可执行任务、进度曲线和长时间运行的代理评估设计。
- Document 1766: 描述了通过 Ability 单元进行的过程迁移测试，并报告了自动迁移效果不一且存在负迁移的案例。