编程智能体自主曲线：阅读是免费的，合并是事故级的

关于编程智能体（coding agents）的讨论总是陷入二元对立：自主还是受监督，YOLO 模式还是手握方向盘，--dangerously-skip-permissions 还是“批准每一次按键”。这种构想框架本身就是一个范畴错误。编程智能体执行的并非“一个动作”，而是一系列动作，其成本跨越了至少七个数量级 —— 从读取文件（免费、可撤销、无副作用）到合并至主分支（不通过 revert PR 则不可逆），再到向集群发布二进制文件（六位数成本级别的事故）。用一个自主性开关来处理如此广泛的范围，就像是为停车场和高速公路设置统一的限速一样。

如果团队在发布“无所不能的智能体”时，没有将每个动作映射到其爆炸半径（blast radius），那么只需一个带有提示词注入风险的 GitHub 评论，就足以引发一场事后复盘 —— 事实上，我们已经有了这种失败模式的公开案例。Anthropic 的 Claude Code 安全审查、Google 的 Gemini CLI Action 以及 GitHub Copilot Agent 在 2026 年都被证实可以通过精心设计的 PR 标题和 issue 正文被劫持，研究人员将这种攻击模式命名为“评论并控制”（Comment and Control）。这些智能体并非在抽象意义上损坏了，而是因为自主性层级悄无声息地将低信任输入抹平为“一视同仁”，从而基于这些输入执行了高阶动作（如推送代码、开启 PR）。

接下来需要建立的规范是：针对每个动作的曲线、随层级扩展的闸门、与爆炸等级匹配的回滚速度，以及一个测试工具组合升级而非单一动作失败的评估程序。

没人画出来的动作阶梯

首先，列出编程智能体可以调用的每个工具，并为其标注爆炸半径等级。这个阶梯大致分为七个层级：

• 第 0 层 —— 读取。 文件读取、grep、AST 查询、gh pr view、日志获取。无副作用，除了推理之外没有令牌（token）成本，无限可撤销。80% 的智能体流量应该留在这里。
• 第 1 层 —— 沙盒计算。 在容器内运行测试，在临时虚拟机中执行一次性脚本，运行 linter。副作用存在但被隔离。成本：几分钟的 CI 时间。
• 第 2 层 —— 本地分支写入。 在功能分支中编辑文件、创建提交（commit）、推送分支。受分支限制 —— 在人类采取行动推动其进展之前，影响是受限的。
• 第 3 层 —— 可审查的提案。 开启 PR、留下评审评论、建议更改。触达人类，但由人类把控下一步。
• 第 4 层 —— 主分支写入。 合并至主分支（main）、关闭 issue、修改 GitHub Actions、编辑 CODEOWNERS。涉及共享状态。只能通过 revert PR 撤销，且受 CI 的实际耗时（wall-clock latency）限制。
• 第 5 层 —— 生产部署。 发布产物、运行数据库迁移、在生产环境中切换功能开关。客户可见。只能通过经过测试的回滚来撤销。
• 第 6 层 —— 集群级。 向 N 个生产主机分发二进制文件、广播缓存失效、大规模 DNS 或路由更改，以及任何“一次性触达全球”的操作。恢复工作是以事故响应来衡量的，而非提交代码。

写下这些层级的目的不是为了记住这七个分类，而是为了强制提出一个问题：每个工具属于哪个层级，以及该层级对应的合适闸门是什么？ 一个只提供全局“询问用户”开关的编程智能体平台，实际上已经用单一数值隐含地回答了这个问题，这意味着除了偶然情况外，它在矩阵的每个单元格上都答错了。

随层级扩展的审批闸门

单一的全局确认提示只是一种“审批演戏”。在对第 0 层文件读取进行了 50 次快速的“批准 / 批准 / 批准”点击后，当智能体到达第 4 层动作时，人类已经产生了反射性点击 —— 在关于“人在回路”（human-in-the-loop）系统的用户研究中，这种审批疲劳是主要的失败模式，而不是恶意绕过。解决方案是建立一个具备层级意识的闸门矩阵：

• 第 0-1 层： 默认允许，无需提示。智能体以全速读取文件并运行测试，因为询问的成本高于出错的成本。
• 第 2 层： 轻量级闸门 —— 在聊天界面显示简要 diff，除非人类在短时间内反对，否则智能体继续操作。智能体保持在工作流中。
• 第 3 层： 显式批准，但审查的对象是 PR 本身，这已经是开发者熟悉的评审界面。复用现有工具，而不是发明新的弹窗。
• 第 4 层： 硬闸门。人类必须主动点击，且智能体必须展示结构化的计划，包括受影响的文件、回滚命令以及推断的风险等级。这也是平台应该要求提供理由字符串（justification string）的地方，用以说明该动作正在履行哪个用户请求 —— 这对审计和捕捉由提示词注入引起的偏离都很有用。
• 第 5-6 层： 带外（Out-of-band）审批。智能体不负责按下按钮。它暂存动作，在现有的变更管理系统中开启变更请求，并等待由人类发起的触发。智能体在执行瞬间绝不持有生产环境的凭据。

请注意，这并不是“到处都要更多审批”。第 0 层的流量应该加速，而不是减慢。闸门预算是一种有限的人类注意力资源，唯有将其花在出错成本巨大的地方，才是对这种资源的明智利用。Claude Code 在内置的安全工具白名单（文件读取、搜索、代码导航）与针对 Shell 命令和外部工具调用的转录分类器闸门之间所做的区分，就是这一理念的一个生产实践案例 —— 尽管对于一个正在进行实际合并操作的智能体来说，即使是这种双层划分也显得过于粗糙了。

回滚速度是层级的属性

每个层级都有其回滚预算。如果 Agent 可以在 30 秒内产生第 4 级的结果，但恢复路径却需要 45 分钟的撤销并重新部署，那么这种不对称性就是问题的核心。由此产生了两条规则：

Agent 在某个层级的速度绝不能超过系统在该层级的恢复速度。 如果你的团队无法在不到一分钟内撤销对主分支 (main) 的合并，那么 Agent 绝不能获准直接合并到主分支，除非加入延迟以给人类留出中止的时间。这不是模型的问题，而是 Agent 让原本存在的发布工程问题显现了出来。发现这一点的团队通常会意识到，在引入 Agent 之前，主分支之所以安全，是因为人类 PR 作者会感到疲倦并去睡觉——这种社会学摩擦保护了分支，而 Agent 并没有这种摩擦。

每一个第 4 级及以上的操作都必须配对一个同级或更低级的回滚操作，且该回滚操作必须在 CI 中可测试。 如果六个月没人运行过“点击撤销按钮”，那它就不是一个回滚。在注册高层级工具时，编程 Agent 平台应该要求团队同时注册其逆操作以及一个能够运行该操作的合成测试。需要防范的失败案例是：Agent 满怀信心地将数据写入四个下游系统——代码、缓存、向量嵌入、审计事件——而回滚操作只撤销了其中一个。

将空运行作为高层级操作的默认模式

对于第 4 级及以上的操作，Agent 的默认模式应该是结构化的空运行 (Dry-run)，生成 diff、受影响的资源以及预测的副作用——但不执行。空运行的结果是供人类评审的产出物。执行则是第二个、独立的、显式提升权限的步骤。

这与典型的自主性滑块正好相反，后者将执行视为默认，而将确认视为可选的干扰。反转默认模式有两个作用。首先，它迫使 Agent 在意图最为关键的层级上清晰地表达意图——一个格式错误的空运行比一个执行错误的后果要早得多。其次，它大大缩小了提示词注入的爆炸面 (blast surface)：攻击必须同时说服模型和评审的人类，而不仅仅是模型。

在 2026 年的生产系统中出现的实现模式是一个两阶段工具：propose_merge（第 3 级，空运行，返回结构化计划）和 execute_merge（第 4 级，需要计划 ID 和单独的人工触发）。模型可以在同一个会话中串联它们，但关口存在于两步之间，且其形式是产出物评审，而非中断提示。

评估组合，而非单个操作

单个工具评估无法揭示的风险是“工具组合”。Agent 拥有第 0 级的读取工具、第 2 级的分支写入工具和第 4 级的合并工具。单独看每个工具都没问题。但攻击路径是这样的：Agent 读取了一个包含提示词注入指令的文件，将这些指令写入提交，开启一个正文中包含更多注入内容的 PR，然后自动评审步骤授权了合并。已有记录显示受攻击的 Agent 会修改其他 Agent 的配置文件——被劫持的 Copilot 写入 ~/.mcp.json 和 CLAUDE.md，下一个 Claude Code 会话加载了被投毒的配置，链条由此延续。

捕捉这种风险的评估准则不是“测试每个工具”，而是“对操作空间的整个可达性图进行红队测试”。像 promptfoo 风格的方法是正确的方向：提供对抗性输入，尝试通过工具组合实现从低层级读取到高层级写入的权限提升，并记录 Agent 的实际追踪轨迹（LLM 调用、工具选择、关口决策），以便在轨迹出现问题时（而不仅仅是最终答案错误时）判定测试失败。单次提示词注入基准测试会遗漏这一点，因为它们没有对多步工具预算进行压力测试。OWASP 指出 73% 的生产环境 AI 部署存在可被利用的提示词注入漏洞，一旦你意识到大多数部署只测试了模型而非操作图，这个数字也就不那么令人惊讶了。

在评估套件中加入一个有用的不变量：如果没有人类参与，任何第 0 级的输入都不应触达第 N+2 级的操作。 如果一个对抗性的文件读取可以扇出并导致合并，那么无论模型是否“理应识破”，这都是一次彻底的测试失败。

成本框架：摩擦税 vs 爆炸税

每个审批关口都是一种延迟税——以人类注意力的秒数和 Agent 流程的损失来衡量。层级纪律的怀疑者喜欢总计这些税收，并将其称为安全的生产力代价。这种框架是不完整的，因为另一种选择并不是“不交税”，而是“爆炸税 (blast tax)”，它以事故响应、客户信任、监管关注和事后的工程师工时来支付。这两种税的分布截然不同。摩擦税是小额、平滑且可预测的。爆炸税是罕见且具有厚尾特征的，中等水平的工程师往往会低估它，因为他们还没写过那种级别的故障复盘。

从经济角度看，有意义的问题是：在哪个层级上，摩擦税会超过预期的爆炸税？对于第 0 级和第 1 级，摩擦税完胜——在这里设置关口纯属浪费。对于第 4 级及以上，爆炸税完胜——任何曾在凌晨 3 点因为一次未经评审的变更而呼叫整个团队的人都知道，一次未预算的爆炸事件成本几何。第 2 级和第 3 级是真正需要进行设计工作的地方，也是团队应该投入注意力预算的地方，而不是没完没了地争论是否应该允许 Agent 读取文件。

“摩擦 vs 流程”阵营往往忽略了第二种成本：每个审批关口也是一个提示词注入熔断器。“评论与控制 (Comment and Control)”攻击之所以得逞，部分原因是关口矩阵是扁平的。分层的关口矩阵可以在第 2 级阻止同样的攻击——Agent 或许可以处理恶意评论，但在跨越攻击者无法控制的边界之前，它无法升级为写入操作。关口不仅是用户体验上的摩擦，它们也是安全防御周界的一部分。

持续设计，而非配置开关

Coding-agent 的自主性并不是你在安装时选择的一个设置。它是一个持续性的设计问题，针对每个工具都有特定的方案，且每当工具目录发生变化时——对于任何在生产环境中运行智能体的团队来说，这大约是每周一次——都必须重新进行评估。做得出色的团队会做三件事：他们维护一个工具注册表，其中每个工具都有层级标签和配对的回滚方案；他们将审查准入矩阵作为一种常规节奏，而非故障复盘时的临时举措；他们将新工具的引入视为一次安全审查，而非单纯的功能交付。

那些做得不好的团队往往有一个共同的特征：他们在营销文案中将自己的智能体描述为“完全自主”。在 2026 年，这个短语大多意味着说话者还没有画出行动阶梯，还没有决定他们的准入矩阵长什么样，也还没有询问他们的 CISO 回滚速度是否匹配爆炸速度。他们最终会去做的。有趣的问题在于，他们是在第一次故障之前还是之后才画出那个阶梯。