--- title: "控制爆炸半径" author: "Shawn Jiang" lang: zh date: 2026-08-30 canonical: https://tplog.dev/zh/essay/shrink-the-blast-radius-first/ translations: en: https://tplog.dev/en/essay/shrink-the-blast-radius-first/ ja: https://tplog.dev/ja/essay/shrink-the-blast-radius-first/ --- # 控制爆炸半径 很多团队讨论 AI Coding 时，第一反应仍然是：Agent 写完代码以后，谁来 Review？能不能 Merge？出了问题谁负责？ 这些问题没有错，但它们继承了一个旧前提：一次代码变更昂贵而危险，所以必须在进入主分支前集中检查、谨慎放行。 PR 工作流正是在这个前提下发展起来的。人写代码慢，一次改动往往攒得比较大；Review 的人也稀缺，于是团队需要设置一道明确的关口，把代码拦下来检查。Merge 因此像一道闸门：闸门之前是草稿，之后才算进入真实世界。 Agent 改变了这笔账。它可以不断提交小改动，自动运行测试，发现失败后继续修复。Git 又保存了完整历史。只要改动足够小，问题能够及时发现，失败后也确实能够恢复，每次变更都排队等待一次庄严的人工 Review，反而可能成为系统里最慢的一环。 真正该问的已经不是“有没有 PR”，而是：这次变化的爆炸半径有多大？ ## 信任来自有限的损失 普通的个人 Todo List 通常是失败成本较低的软件；银行核心系统则是失败成本高、责任密度高的软件。软件风险的高低不只取决于功能复杂度，更取决于它承担了多大的现实后果。 让 Agent 自主处理低失败成本的工作，不要求我们先证明 AI 永远不会犯错。我们给 Agent 自由，不是因为相信它足够聪明，而是因为错误便宜、可见、可逆。 因此，好的 Agent 基础设施不该只追求“让它做更多”，还要不断缩小每次行动的爆炸半径： - 使用隔离工作区，避免多个任务互相污染； - 保持提交足够小，随时可以定位和撤销； - 用 Feature Flag（功能开关）、灰度发布和自动回滚控制影响范围； - 先在测试环境运行，再逐步接近真实用户； - 让 Agent 提交证据，而不只是提交代码； - 把一次大变更拆成许多可以分别验证的小变化。 Sandbox（沙箱）可以把这些约束落实到任务环境：每个 Agent 都有独立环境、明确的生命周期和有限的任务边界。任务可以扔出去运行，人不必守着每个 Terminal；出了问题，也不至于拖垮整个工作现场。 ## Git 只能撤销代码，不能撤销世界 Git 的可逆性很容易给人一种错觉：反正有版本控制，怕什么，有问题 Revert 就好。 数据库里被删除的数据，不会因为代码回滚而自动回来。已经发出的邮件收不回，已经扣掉的钱不会自行退还，泄漏的密钥也不能重新变得秘密。一个错误的 API 返回被客户系统消费以后，对方据此采取的行动同样不会消失。 这些操作就是 Agent 面前的核弹按钮。 核弹按钮不一定长得吓人。它可能只是一个普通的 `DELETE`，一次数据库迁移，一个发送通知的 API，或者一次看似平常的生产部署。危险不在命令本身，而在它被执行以后，世界已经发生变化，Git 无法替你把它改回来。 Agent 治理真正需要的，既不是“所有操作都由人审批”，也不是“全部自动化，失败就回滚”。更合理的边界是：低爆炸半径的操作，尽量让 Agent 自主完成；不可逆、高爆炸半径的操作，把最终签字权留给人。 ## 把边界写进权限，而不只是 Prompt 这条线不能只写进 Prompt。如果一个 Coding Agent 同时拥有生产数据库写权限、云账户管理员权限和对外发送消息的能力，再漂亮的系统提示词也只是礼貌提醒。 真正可靠的 Harness，也就是承载 Agent 的运行环境、工具和权限体系，应该从能力上拆开权限：Agent 可以准备迁移脚本，但不能直接执行；可以生成邮件，但不能代表公司发送；可以部署到隔离环境，但进入生产需要另一道独立验证。 人的角色也会随之变化。过去，人通过逐行 Review 控制质量。以后，人更重要的工作可能是设计变化的边界：哪些东西允许自动试错，如何发现失败，怎样恢复，什么动作一旦执行就无法撤回，以及谁有资格按下最后那个按钮。 逐行检查所有代码，容易给人一种自己仍掌控全局的安全感。真正危险的地方却往往不在某一行代码写得漂不漂亮，而在系统是否会把一次普通错误放大成无法收拾的事故。 新世界不是没有闸门。只是闸门不该继续机械地放在每一次 Merge 前面。 它应该放在爆炸半径突然扩大的地方。