本文是《执行缝隙》The Execution Gap的作者手记。 它不是书籍正文的摘要或重写而是围绕本章问题、工程背景与写作之后的进一步思考。很多事故在复盘时都会出现一句非常自然的话流程为什么没有把它拦下来这句话听起来没有问题但继续往下追很容易把两件不同的事情混在一起。一种情况是请求实际上走了一条不该走的路本应发生的步骤被跳过了顺序被改变了执行主体被替换了或者某个未经预期的入口参与了进来。另一种情况则完全不同请求从头到尾走的就是系统原本设计好的路径每一步都有对应的流程每一个参与者也都拥有合法资格可最终仍然没有任何东西阻止那个动作产生现实后果。第五章真正想拆开的就是这两个问题。过去我们很容易把安全控制想成一条带有很多关卡的道路。请求从入口进入经过认证、授权、审批、策略和各种检查只要某一步不符合条件就应该在那里被挡下来。在这种图景里“走错了路”和“没有被拦住”确实非常接近因为只要最后发生了不应该发生的事情我们很容易认为它一定在某个地方绕过了控制。但现实系统里存在另一种更加值得警惕的情况它根本没有绕。正常流程并不是安全结果的证明工程师对于“绕过”非常敏感因为绕过通常能够留下明确痕迹。一个本来应该经过审批的操作没有经过审批一条请求进入了非标准接口一个权限不足的主体使用了高权限路径这些问题很容易理解也很容易形成整改方案。增加检查、关闭入口、限制调用路径、补上缺失步骤这些措施都很自然。真正麻烦的是当我们把整条执行链重新展开以后发现没有任何明显的绕过。AWS S3 2017 年的事故让我特别注意到这一点。执行动作来自获得授权的人员使用的是既有工具按照既有 playbook 操作真正造成问题的是输入参数使动作作用范围远远超过原来的意图。流程没有突然变成另一条流程操作者也没有闯入一个不属于他的入口。Citibank 的 Revlon 误付款同样如此。交易经过正常的系统两级复核真实发生资金最后也通过银行正常的支付通路被汇出。事后当然可以找到具体的操作问题但如果只问“有没有绕过正常流程”答案并不会自动变成肯定。Waymo 的案例则更加直观。一辆车最终撞上了电线杆很容易被口语化地描述成“走错路了”可如果把 Path 严格限定为“实际执行是否偏离已经规划出的路径”事情就完全不同。车辆执行的恰恰是规划器生成的路径真正的问题是那条被规划出来的路径本身包含了现实中的障碍物。这几个案例放在一起以后对我最大的提醒不是“流程没用”而是相反流程有没有被遵守与这个流程最终有没有限制住错误动作是两个独立问题。如果不把它们分开一个非常危险的推论就会出现路径检查没有发现异常所以控制应该没有问题。而现实已经告诉我们这个推论并不成立。“怎么走”与“能走多远”是两种问题第五章里我最后把 Path 和 Boundary 分开其实来自一个很简单的工程直觉。Path 关心的是一次具体请求的行进过程。它问的是真正发生的步骤、顺序、主体、入口和链路和原本应该发生的那条路径是不是一致。Boundary 关心的是另一件事。它并不首先问请求经过哪里而是问这个动作的能力究竟被限制在什么范围内。一个拥有合法权限的管理员可以使用正常工具执行操作这并不意味着系统应该允许一次操作影响任意数量的资源一笔已经经过审批的付款也不意味着后来进入执行端的金额、账户和业务对象可以无限偏离最初批准的范围一个 Agent 可以合法调用某个工具也不意味着它获得了利用这个工具改变任意现实状态的资格。这就是为什么我越来越不愿意把执行边界简单理解成另一种访问控制。访问控制主要回答“谁有权做什么”。执行边界还需要回答即使这个主体有权做这一次动作究竟允许做到什么程度它能影响多少对象改变多少资源持续多长时间在什么状态下必须停止又有什么东西拥有最终拒绝它的能力这几个问题不属于“这个人有没有权限”的简单延伸。一个系统完全可以在访问控制意义上没有任何问题却在执行边界上极其脆弱。高权限主体被正确认证调用也完全合法只是系统没有把一次动作的现实影响限制在一个能够承受的范围内。如果到了事故以后我们才说“早知道应该限制一下”那真正缺失的并不是身份认证而是那个在动作真正进入现实之前仍然有效的边界。我后来越来越在意“谁还能说不”写这一章的时候有一句话逐渐变得很重要谁能最终拒绝它和审批不是一回事。审批发生在执行之前的某个时间点它可以决定一个动作是否获得进入后续流程的资格。但现实在变化参数在变化系统状态在变化真正执行的对象也可能在后面的转换中发生变化。于是一个动作曾经获得批准并不意味着从那一刻开始它就应该拥有不受条件变化影响的最终执行权。这也是执行控制真正开始出现的地方。越靠近现实动作系统越需要重新回答此刻这些条件还成立吗对象还是原来那个对象吗参数还处在被允许的范围内吗当前状态是否仍然允许这个动作继续如果答案是否定的那么即使前面的审批、授权和流程全部真实存在系统仍然应该存在一个可以拒绝执行的位置。我后来越来越觉得这种“最终拒绝能力”是很多传统软件架构里没有被单独拿出来讨论的东西。我们设计了很多允许动作发生的机制授权允许它进入审批允许它继续API 允许它被调用流程引擎允许它向下推进。可一个动作越接近真正改变现实的那一刻究竟还有谁能够说“不”往往并没有同样清晰的设计。如果所有上游结论最终都汇聚成一句“已经批准可以执行”那么系统真正失去的可能不是某个检查步骤而是在现实发生之前最后一次重新判断的能力。边界失效不一定意味着有人修改了边界Boundary 还有一个特别容易被误解的地方。一说到边界失效人很容易联想到“边界被突破”或者“规则被改掉了”。这是一种很强的事故叙事因为它通常存在清晰的变化原来的规则是这样的后来有人把它改成了另一种样子所以控制失效了。这种情况当然存在第五章把它称为 Boundary Mutation。但如果把所有 Boundary Failure 都理解成 Mutation很多真正的边界问题反而会被漏掉。有些时候没有任何人修改规则。约束从一开始就不存在。或者规则确实存在只覆盖了其中一部分能力。也可能规则在设计上看起来完整但真正危险的动作根本没有进入它能够拒绝的范围。在这些情况下调查人员可能查遍配置变更、权限变化和管理员操作却什么都找不到因为根本没有发生过一次明确的“边界被改写”。真正的问题是那道边界从来没有覆盖到这里。这也是为什么我认为 Boundary 不能被理解成一种攻击模型。执行边界首先是一种系统属性它可以因为攻击而失效也可以在所有参与者都善意、所有身份都合法、所有流程都正常的情况下暴露出缺口。这件事对于 AI Agent 尤其重要。未来很多 Agent 的危险动作未必来自恶意绕过。相反它们很可能使用被允许的工具、经过被允许的接口在被允许的权限范围内完成一个系统本来就允许它完成的动作。真正的问题是系统允许它做的那件事现实作用范围是不是过大了。如果修错了对象事故复盘就只是让流程变得更复杂把 Path 和 Boundary 分开以后还有一个很现实的意义它会直接决定事故之后究竟修什么。如果问题真的来自路径偏离那么修路径完全合理。把缺失步骤补回来关闭旁路避免主体替换恢复正确顺序。但如果实际路径没有问题而真正缺少的是边界那么继续给流程增加节点未必能解决问题。多一次审批多一个确认框多一个微服务多一条日志都可能让流程看起来更加严密却没有回答那个动作究竟能影响多少现实资源。这是我越来越警惕的一种“安全改进”。事故发生以后系统变得更复杂了于是所有人都有一种已经加强控制的感觉。但复杂度本身不是控制增加步骤也不等于增加边界。如果新增的节点仍然只是检查同样的信息或者仍然允许同一个动作在通过之后拥有完全相同的现实作用范围那么它可能只是把原来的问题拉长而没有真正缩小它。所以第五章最后保留的不是一个关于哪一种机制更重要的结论而是两个必须被独立执行的判断。先问这一次请求有没有真正偏离规范路径然后另外再问在它最终改变现实之前限制它作用范围的那些约束是否存在、是否完整、是否有效一个答案不能替另一个答案作证。路径完全正常并不意味着边界正常发现边界失效也不能反推出一定有人绕开了路径。两者可以同时成立也完全可以只成立其中一个。写完这一章以后我对“正常流程”这四个字的理解也发生了一些变化。正常流程仍然重要但它只能说明事情按照设计好的路线发生。它没有回答一个更加靠近现实的问题当这条路线本身正在把一个错误动作送向现实的时候究竟还有什么东西能够让它停下来这可能才是执行边界真正开始出现的位置。关于《执行缝隙》《执行缝隙》The Execution Gap是Execution Engineering Trilogy第一卷。本书讨论一个基础而关键的问题从人的意图到机器最终改变现实世界中间究竟发生了什么在线阅读繁體中文版 執行縫隙 | Havenlon ResearchEnglish Edition The Execution Gap | Havenlon ResearchAmazon Kindle Amazon.com: The Execution Gap: The Structural Discontinuity Between Intent and Action (Execution Engineering Trilogy Book 1) eBook : Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: Kindle StoreAmazon Paperback The Execution Gap: The Structural Discontinuity Between Intent and Action (Execution Engineering Trilogy): Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: 9798177903347: Amazon.com: Books© 2026 Lin Wang / Havenlon.本文为作者手记与《执行缝隙》正式书籍正文相互独立。 未经授权请勿全文转载或用于商业再出版。 引用请注明作者及出处。