本文是《执行缝隙》（The Execution Gap）的作者手记。 它不是书籍正文的摘要或重写，而是围绕本章问题、工程背景与写作之后的进一步思考。
写到第九章的时候，我第一次明显感觉到，《执行缝隙》需要停止继续“吸收”问题，转而做一件相反的事情：把一些看起来非常相关、甚至后果十分严重的问题明确地留在外面。
前面的章节一直在向内建立结构。我们先拆掉了“每一环都正确，所以最终执行就应该正确”的推论，又把“执行了”拆成提交、调用、状态、回执、结果与证据这些不能默认等同的对象；随后，偏差的位置从单个组件转向对象之间的关系，并进一步收敛为判断与绑定、执行路径、执行边界、状态与结果、因果链内证据与证明这几类直接机制。到了第七章和第八章，我们又把 Change 与 Amplification 从一级成因的位置上移开。
理论走到这里，最容易产生一种诱惑：既然已经建立了一套能够解释许多事故的语言，那么是不是可以继续用它解释更多事情？
我后来反而觉得，真正应该做的是相反方向。
一个概念如果只能不断告诉我们“这个也算、那个也算”，最终通常会变成一个覆盖范围很大、定位能力却越来越弱的词。Execution Gap 如果最后能够包住所有软件 bug、所有错误决定、所有 AI 失误、所有证据问题和所有坏结果，那么它与“系统出了问题”之间也就没有多少实质区别了。
所以第九章真正要回答的，不是还能把什么装进来，而是：什么东西即使重要，也不能仅凭结果不好就自动叫作执行缝隙。
边界不是为了保护理论，而是为了保护问题本身
我一直认为，一个新概念最危险的时候，不是它解释不了一些事情，而是它开始什么都能解释。
现实事故往往很复杂，一件事情里面可以同时存在软件缺陷、错误判断、治理问题、证据缺失、恢复动作和自动化放大。如果我们看到这些东西以后，都把它们统一叫成 Execution Gap，表面上像是找到了一套更加完整的语言，实际上却会把不同的问题重新压成一个词。
这会同时伤害两个方向。
一方面，《执行缝隙》前面建立的那些关系、机制和因果位置会失去意义，因为无论最后发生什么，我们都可以用同一个概念概括；另一方面，那些真正属于软件质量、治理合法性、可观察性或者韧性工程的问题，也会因为被放进错误的问题空间，而错过自己真正应该接受的分析方法。
所以第九章里的六条边界，我不把它们理解成六个新的类别，更不认为它们是一张“非执行缝隙分类表”。它们真正做的是提醒我们：面对一个已经发生的坏结果，不要急着把它装进 Execution Gap，而应该先看它是否真的满足这个问题空间所要求的关系条件。
“不算执行缝隙”，从来不等于“不重要”。
它只意味着，第一步应该去别的地方寻找答案。
一个 bug 可以进入执行缝隙，但“有 bug”还不是答案
软件 bug 是最典型的例子。
如果一段程序把数字处理错了，某个函数返回了错误结果，或者一个边界条件没有被正确处理，这当然是需要修复的工程缺陷。但仅仅知道“这里有一个 bug”，还没有告诉我们 Execution Gap 是否存在。
真正的区别，要看这个错误后来进入了什么关系。
假设一段代码错误地截断了付款金额的小数位，那么在这一刻，它首先只是一个实现错误。如果这个错误被发现、修正，事情到这里就结束了，并没有必要为它再建立另一套理论解释。
可如果这个错误金额继续进入执行链，而上游真正批准的是另一个金额，那么事情就发生了变化。此时我们已经能够明确指出：批准所针对的对象，与最终被执行的对象不再保持原来的绑定关系。
到这个位置，它才进入《执行缝隙》所关心的问题。
所以“普通 bug 不自动算 Execution Gap”并不是在降低 bug 的重要性，而是在要求分析继续向前走一步。我们需要知道这个 bug 是否只是实现内部的错误，还是已经进一步改变了某个原本必须成立的执行关系。
如果没有这一步定位，“Execution Gap”就会变成 bug 的一个新名字，而这正是我最想避免的事情。
一个错误决定被忠实执行，问题首先可能不在执行侧
第九章里另一个非常重要的边界，是规范上错误、甚至违法的上游决定。
这一类事件最容易让人产生强烈直觉：既然后果如此严重，而且还是由自动化系统执行出来的，那当然属于执行失败。
但如果我们把情绪先拿掉，只看关系本身，就会发现事情并没有这么简单。
假设上游决定是 A，执行系统最后准确执行的也是 A，那么决定与执行之间的对应并没有发生偏离。真正的问题，是 A 为什么能够成为一个有效的上游决定，它有没有法律依据、事实依据或者足够的正当性。
Robodebt 对我来说一直是一个非常重要的边界案例，因为它逼着这套理论面对一个不舒服的事实：严重的坏结果，并不能单独证明偏差发生在执行侧。
这不是替系统开脱，更不是降低现实伤害的重要性。恰恰相反，它是在要求问题被放回真正应该承担责任的位置。
如果一个违法或者证据基础不足的决定被系统忠实执行，那么首先应该追问的是那个决定为什么能够成立，而不是因为它后来被自动化了，就把整个问题重新描述成执行偏离。
当然，这也不是永久排除。进一步分析以后，如果其中还能找到批准对象与实际载荷失配、边界失效或者状态与结果关系断裂，它仍然可以从具体机制位置重新进入 Execution Gap。
但那时让它重新进来的，已经不是“结果很坏”，而是一个真正可以被指认的执行关系失效。
证据有没有问题，要看它还会不会继续改变现实
证据问题也是我在写这一章时特别想划清的一条线。
安全系统天然重视日志、审计、记录和证明，因此事故发生以后，只要发现日志不完整、记录缺失或者无法还原事实，人们很容易把这些问题一起放进“执行安全”。
可这里真正重要的不是证据长什么样，而是它处在因果链的什么位置。
如果一份错误或者不完整的证据参与了当前判断，导致系统继续执行，那么它显然属于 Execution Gap 的因果链；如果错误记录导致系统错误重试、恢复，或者影响下一次动作，它同样已经重新参与现实。
但如果现实动作早已完成，结果也已经确定，之后我们才发现缺少日志、无法审计或者难以追责，那么这仍然是一个严重的问题，却不是让那次动作最初抵达现实的结构原因。
我觉得这里最关键的一点，是证据问题还可以“有界回入”。
一份事后证明缺失原本位于 Execution Gap 核心之外，但如果后来系统因为这份缺失错误地判断了当前状态，并因此再次执行、恢复或者重试，那么从它重新开始改变现实的那个节点起，它又进入了执行链。
所以真正的判据从来不是“有没有完整证据”，而是：这份证据此刻还会不会影响现实中的下一次动作。
这条边界比单纯讨论日志质量更接近执行问题本身。
恢复得很好，也不能替过去重新定义性质
韧性与恢复同样不能从结果反推性质。
一个系统出现异常以后成功回滚，或者通过降级、重试、人工介入最终恢复正常，并不能自动证明此前已经发生过 Execution Gap。恢复机制被触发，只能说明系统遇到了需要处理的状态，它可能只是一个普通故障。
反过来，如果一次偏离已经真正到达现实，后面的补救再成功，也不会把那个已经发生过的执行关系失效从历史中抹掉。
这两种误读其实来自同一种思维习惯：我们习惯用最后的结果重新解释前面的过程。
结果没有造成损失，于是认为前面没有真正发生问题；结果非常严重，于是认为前面一定发生了最严重的执行偏离。
但《执行缝隙》一直试图坚持另一种方式：先判断结构关系有没有失效，再讨论它最后造成了多大的现实后果。
恢复解决的是后果和连续性，不能替执行关系本身作证明。
AI 说错了话，与 AI 执行错了现实，仍然不是同一个问题
到了 Agent 时代，这条边界会越来越重要。
一个聊天系统可以给出错误信息，一个模型可以产生错误建议，这些内容经过人的判断之后，完全可能造成现实后果。但如果这个系统本身并没有获得现实动作权，那么仅凭信息错误最终影响了人的行为，还不能直接把它称为执行偏离。
Moffatt v. Air Canada 在这一章里承担的就是这种边界作用。
这里并不是否认错误表示，也不是说聊天系统造成的后果不重要，而是要区分：提供信息，与直接拥有改变现实的动作能力，是两个不同的位置。
如果系统只是告诉人“应该怎么做”，真正形成决定并采取现实动作的是另一个主体，那么问题首先落在信息与判断层。
一旦 Agent 开始拥有工具，可以自己付款、修改账户、改变配置或者控制设备，情况当然会发生变化，因为它已经真正进入执行链。
因此，真正决定 AI 是否进入 Execution Gap 的，从来不是“它是不是 AI”，而是它有没有进入那个最终能够改变现实的位置，以及进入以后哪些必要关系是否仍然成立。
同样的道理也适用于 Tool。模型调用了工具，并不能自动建立一个新的“Tool Failure”机制。工具参数错误可能属于绑定问题，合法工具被组合成未经整体授权的链路可能属于路径问题，工具能力超出其现实作用范围可能落到边界与资格关系，而递归调用带来的速度和规模更多属于 Amplification。
“用了工具”只是一个应用语境，不是一个已经完成的定位结论。
要说“偏离”，必须先知道它偏离了什么
第九章让我重新意识到一个非常基础的问题：我们一直说“执行发生了偏离”，但偏离必须有参照物。
这个参照物不能是事故发生以后我们重新想象出来的“正确结果”，也不能只是“大家都觉得本来不应该这样”。如果这样处理，Execution Gap 很快就会从一个工程问题变成一个规范判断。
真正能够承担比较的，必须是一个在执行之前已经成立、并且可以被指认的 Intent、Decision、Approval 或其他上游对象。
The DAO 之所以适合作为边界案例，就是因为这里很难先确定“哪一个已经成立的意图”应该成为执行比对的对象。协议按照既有规则运行，但社会期待、治理规范与不同参与主体的意图并没有天然形成唯一层级。
当比较的一端都还没有确定时，“执行是否偏离”其实还没有建立它所需要的比较基础。
这并不意味着协议执行永远不能形成 Execution Gap，也不意味着治理争议不重要，而是提醒我们：偏离不是结果与期待不同，而是现实执行与一个已经成立的上游对象之间的关系发生了断裂。
只要这条线守不住，Execution Gap 最后就会重新退回“事情没有按照我们希望的方式发展”。
一个理论真正有边界以后，才开始知道下一个问题在哪里
写完第九章以后，我反而觉得《执行缝隙》第一次真正有了形状。
它不是所有软件 bug，不是所有自动化错误，不是所有坏结果，也不是所有 AI 造成的现实影响。它有内部结构，也有明确排除边界；有些问题可以从具体机制重新进入，有些问题应该留在相邻的工程领域继续处理。
这并没有让这个概念变得更弱，反而让前面的讨论终于有了一个可以停下来的地方。
而一旦这个边界真正出现，另一个此前一直被绕着讨论的问题也开始浮出来。
Intent 可以成立，Approval 可以成立，Authorization 可以成立，Policy 可以成立，Path 甚至也可以完全正常，Boundary 也可能仍然存在，可最终那一次现实动作仍然可能与它们对不上。
前面九章已经把很多东西拆开，但还有一件事一直没有真正被命名：所有这些上游对象最终只是决定、资格、约束和证明，真正让现实发生变化的，是最后那个动作获得了现实效力。
那么，一个动作究竟凭什么获得最终改变现实的资格？
当 Execution Gap 的外边界被划清以后，这个问题已经很难再绕过去了。
关于《执行缝隙》
《执行缝隙》（The Execution Gap）是Execution Engineering Trilogy第一卷。
本书讨论一个基础而关键的问题：
从人的意图，到机器最终改变现实世界，中间究竟发生了什么？
在线阅读
繁體中文版 執行縫隙 | Havenlon Research
English Edition https://havenlon.com/research/books/the-execution-gap/
Amazon Kindle https://www.amazon.com/dp/B0HKYLBK3B
Amazon 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.
本文为作者手记，与《执行缝隙》正式书籍正文相互独立。 未经授权，请勿全文转载或用于商业再出版。 引用请注明作者及出处。
