---
kind: ideas
granularity: day
period_start: '2026-07-08T00:00:00'
period_end: '2026-07-09T00:00:00'
run_id: materialize-outputs
status: succeeded
topics:
- coding agents
- agent security
- MCP
- bug reports
- software benchmarks
- production automation
- AI personalization
tags:
- recoleta/ideas
- topic/coding-agents
- topic/agent-security
- topic/mcp
- topic/bug-reports
- topic/software-benchmarks
- topic/production-automation
- topic/ai-personalization
language_code: zh-CN
---

# 编码代理的控制闭环

## 摘要
编码代理的采用面临三个具体的运维问题：不可信仓库可能诱导代理运行攻击者代码，重复事件持续产生完整的推理成本，面向人工编写的问题文本可能让修复代理缺少判断依据。最实际的改进包括限制仓库和 MCP 工具使用的执行检查、将经过验证的事件轨迹转化为操作手册的升级规则，以及在问题提交时收集可执行的修复证据。

## 针对不可信仓库命令和 MCP 工具调用的执行检查
测试 Claude Code、Codex 或基于 MCP 的代理时，安全团队应在执行前增加一道检查，拦截任何来自仓库文本或用户控制输入的命令、二进制文件、脚本、文件路径、URL、数据库查询或终端工具调用。检查可以保持简单：标记每个待执行参数的来源，阻止自动批准执行未签名的本地二进制文件和仓库建议运行的脚本，首次运行命令时要求人工说明批准理由，并记录引入该指令的具体仓库文件或 MCP 参数。

需求很明确。一项概念验证在本地 `geopy` 仓库中加入了看似正常的项目指引、`security.sh` 脚本、恶意的 `code_policies` 二进制文件和诱饵源文件。Claude Code 和 Codex 检查这些文件后，将脚本判断为安全，并在自动模式或自动审查模式下运行了恶意二进制文件。报告称，受影响的环境包括多个 Claude Code CLI 版本和 Codex CLI 0.142.4。

MCP 服务器在工具边界上也会出现同类问题。SpellSmith 的 MCP 研究在 53 份漏洞报告中发现了 43 起污染类型案例，其中大多数在调用工具时触发。该研究提出的缓解方法会在工具描述中加入安全指引，并在最终执行前增加一次反思步骤。第一项实际测试可以使用一个小型仓库样本，让现有代理读取看似无害的 README 指引，而该指引要求执行脚本；然后启用检查再次运行，确认代理仍能检查代码，同时失去自动执行的路径。

### 资料来源
- Document 1794: 记录了针对 Claude Code 和 Codex 自动批准模式的基于仓库的远程代码执行概念验证。
- Document 1799: 报告称，收集到的 MCP 服务器漏洞大多属于污染类型问题，并介绍了安全感知工具描述和调用前反思机制。

## 将经过验证的事件代理轨迹提升为操作手册的规则
使用代理进行事件分诊的运维团队，应把成功的代理轨迹保留下来，作为自动化素材。一个可构建的版本会在每次经过验证的事件处理后记录工具调用顺序、分支条件、模式、依赖、参数和人工批准点。经过多次安全运行后，可以把重复出现的模式提升为混合式操作手册；在一致性更高、通过回归测试并完成人工审查后，再提升为确定性执行。

这种做法能降低重复事件的成本，并提高处理一致性。在报告中的云网络运维部署中，运行八个月后，确定性执行占比达到约 45%。最终组合约为 45% 确定性执行、30% 混合式执行和 25% 完全由代理编排的执行。事件数量大致翻倍时，单次事件的代理成本下降了 70% 以上，平均解决时间也从数小时缩短到数分钟。

低成本的采用验证可以先选择一个事件类别，例如已知的网络告警或常规服务降级。收集 20 到 30 次成功的代理运行记录，对操作序列进行聚类，并生成一份候选操作手册，其中明确规定检查失败、安全违规或验收测试回归时的降级规则。团队可以先确认轨迹数据是否足够完整，再决定是否扩大事件自动化计划。

### 资料来源
- Document 1800: 介绍了云网络事件处理中的轨迹提取、升级和降级标准、执行类型及生产结果。

## 为修复代理收集可执行证据的问题模板
负责将缺陷交给修复代理的工程团队，应更新问题模板，要求填写对代理有用的字段：最小复现脚本、预期行为、观察到的错误、相关源代码片段或 API 契约、疑似文件或模块，以及可能的修复方向。模板还应避免在初始任务中加入过长的叙述性报告，防止推测、历史背景和无关讨论混在一起。

证据指向了具体字段。在 87 个代理尝试修复的 433 个 SWE-bench Verified 问题中，修复建议与成功之间的正相关最强，优势比为 3.61。提供仓库源代码、复现脚本以及指出最终补丁文件名，也与更高的修复成功概率相关。报告越长，修复成功概率越低；日志报告长度每增加一个标准差，优势比为 0.49。

可以先进行小规模试点，无需修改整个问题跟踪系统。让一部分新缺陷使用修订后的模板，针对匹配的旧格式和新格式报告运行同一个修复代理，然后比较有效补丁率、生成第一个合理补丁所需的时间，以及搜索仓库的步骤数。如果报告人无法提供修复建议，模板可以要求填写失败的不变量，或最可能负责该行为的文件。

### 资料来源
- Document 1797: 报告了 SWE-bench Verified 研究结果：修复建议、复现脚本、源代码提示、问题定位信息和较短的报告都与修复代理成功相关。