本文是《执行缝隙》The Execution Gap的作者手记。 它不是书籍正文的摘要或重写而是围绕本章问题、工程背景与写作之后的进一步思考。做工程很多年以后人会形成一种近乎本能的习惯只要结果出了问题就沿着链路往回找。这是一种非常有效的工程方法。程序崩溃了就去看调用栈数据错了就去检查输入和转换过程权限出了问题就去检查认证、授权和策略一个自动化任务造成了意料之外的结果就顺着日志把每一步重新拼起来。绝大多数工程故障最后确实能够落到一个相对明确的位置参数传错了状态过期了规则写错了接口被错误调用了或者某个组件没有按照设计工作。我们甚至已经习惯了这样理解“事故”既然最后发生了不应该发生的事情那么前面总有一个地方出了错只是暂时还没有找到。《执行缝隙》第一章真正让我想写下来的恰恰是一种不太符合这种工程直觉的情况。有时候你把整条链重新检查一遍可能会发现每一个局部判断都成立。审批确实完成了审批人也拥有相应资格授权系统没有越权发起动作的主体确实拥有所需权限策略引擎按照当时拿到的输入运行也命中了应该命中的规则资格校验在那个时刻是有效的日志完整系统没有被绕过参与者也没有明显违反已经写下来的流程。可是当你把这些东西全部放到一边再去看最终真正发生在现实里的事情时仍然会产生一种很难消除的不协调它和最初已经成立的意图、决定、审批或者授权并不完全是同一件事。这种情况之所以麻烦不是因为它比普通的软件错误更加神秘而是因为我们熟悉的排查语言在这里开始失效了。我们习惯问“到底是哪一环错了”可这个问题已经偷偷带进了一个假设只要最终结果出现偏离就一定存在一个局部环节是错误的。于是接下来的工作只是把这个环节找出来。写第一章的时候我越来越意识到这个假设本身并不一定成立。审批系统只能证明审批系统意义上的事情授权系统只能证明授权意义上的事情策略引擎也只能证明在它所获得的输入和规则之下某个结论是怎样得到的。每一个判断都有自己的对象也有自己的边界。它们之所以能够被机器稳定处理恰恰是因为问题已经被收窄到了一个可以判定的范围之内。真正容易被忽略的是这些局部判断之间那个看不见的“因此”。我们很自然地认为审批是对的授权是对的策略也是对的所以最后执行出来的结果应该也是对的。但前面的任何一个系统其实都没有证明这个“所以”。这也是为什么我最后把第一章最核心的判断压缩成了一句话Local Correctness ≠ End-to-End Execution Correctness。局部正确并不等于端到端执行正确。现在再看这句话我觉得它真正重要的地方并不是这个不等式本身而是它迫使我们停止一种非常熟悉的思维方式。过去我们总想找到“坏掉的东西”。可是如果所有参与对象都可以在自己的范围内证明自己没有错那么问题就不再只是“哪个组件出了故障”而变成了另一个层次的问题这些局部成立的判断究竟凭什么能够共同建立最后那个现实动作的正确性这个问题一旦被问出来很多原本看起来理所当然的东西就开始变得不那么稳固。例如授权。现代系统非常擅长回答一个主体“有没有权做某件事”。一个账号是不是管理员一个服务是不是拥有某项权限一个 API 调用是不是来自被允许的身份这些问题已经有非常成熟的工程体系来处理。但“有权做这一类事情”和“眼前这一次就应该这样做”其实是两个不同的问题。一个人可以是合法管理员却仍然可能在某一次操作中判断错误一个自动化系统可以拥有完全合法的权限却可能在不完整的状态下做出不合适的动作一个 AI Agent 也可以经过完整认证、获得明确授权并且严格沿着允许的接口运行但这些事实仍然不能单独证明它这一次对现实的判断就是正确的。这里不需要假设任何人有恶意。这是第一章里我很想保留的一条边界。安全讨论很容易滑向“谁不可信”。外部攻击者不可信被入侵的账号不可信恶意管理员不可信受到提示注入影响的 Agent 不可信。这样的讨论当然重要可如果把所有执行问题都放进“可信与不可信”的框架里我们会很容易漏掉另一种更加普通的情况一个主体完全可以是合法的、善意的、能力很强的同时仍然具有可错性。可错并不是一种道德判断也不是对某种技术能力的贬低。它只是承认没有任何身份、资格、授权、历史表现或者主观善意能够替某一次具体判断提供必然正确的证明。这件事过去并不难理解只是当判断与执行之间隔着很多人工步骤时它造成的影响没有那么集中。一个人判断错了后面可能还有另一个人确认一个流程出现偏差现实动作可能还需要经过另外几个系统才能真正发生。AI Agent 的出现改变了这种节奏。我一直不太愿意把这里讨论的问题称为“AI 的问题”因为它早在 AI Agent 出现之前就已经存在。支付系统、自动化运维、交易系统、工业控制、审批平台甚至最普通的后台任务都可能出现上游对象与最终执行结果之间的偏离。AI 并没有创造这条缝隙。它只是第一次让这条缝隙变得如此难以忽略。过去一个判断与一次现实动作之间往往存在天然的摩擦人要登录系统要打开页面要确认参数要按下按钮要等待另一个系统处理。很多这些步骤并不是为了安全而设计的但客观上它们减慢了错误向现实传播的速度。Agent 正在一点一点消除这些摩擦。它可以连续调用工具可以读取状态可以自己决定下一步动作可以在几分钟之内走完过去需要多个岗位共同完成的流程。从效率角度看这是巨大的进步但从执行问题的角度看它也意味着一个局部判断一旦获得执行能力可能以前所未有的速度穿过整个系统。于是一个原本只是“判断是否正确”的问题迅速变成了“这个判断能否直接改变现实”的问题。我认为这两个问题应该被分开。一个判断会不会出错是认知问题一个判断出错以后能不能直接产生现实后果是系统结构问题。如果把两者混在一起解决方案往往会走向两个极端。要么希望主体变得足够聪明、足够可靠以至于不再犯错要么因为担心犯错就不断收回它的自主能力让所有事情重新回到人工确认。我都不认为这是这个问题真正应该结束的地方。尤其是在 AI 系统里如果最终答案只是“高风险操作全部交给人确认”那么我们其实没有解决自主执行的问题只是暂时取消了自主执行。但反过来如果因为模型越来越强就开始相信“足够强的模型最终可以自己保证执行正确”我们又回到了第一章试图拆掉的那个推论主体足够合法、足够聪明、足够稳定因此它做出来的事情就可以被直接视为正确。这也是为什么第一章最终没有急着给出解决方案。写到这里时其实很容易顺势提出一整套新的控制结构再加一次检查再增加一个审批人再引入一种新的策略或者在执行之前加入某种最终确认。但如果最基础的问题还没有被说清楚那么这些措施很可能只是继续往原来的链路里增加新的局部正确。我们增加了更多“对的环节”然后仍然默认它们最终能够推出一个“对的结果”。那样的话问题其实没有改变。所以《执行缝隙》第一章做的事情非常克制。它没有告诉读者究竟缺了什么也没有声称所有执行偏差背后都存在一个统一的隐藏组件。它只是先拒绝接受一条长期被默认成立的推论上游对象成立并不足以证明最终现实执行成立。这个否定很重要因为只有先把这条推论拆开后面的工程问题才真正有机会出现。而当我把这一章写到最后时另一个问题也越来越无法绕开。我们一直在说“最终执行”“执行结果”“执行偏离”可“执行”这个词本身其实远没有听起来那么简单。一个请求被发送出去算执行了吗一个 API 返回成功算执行了吗数据库状态已经改变算执行了吗如果软件世界里的状态已经变化但真正的资金、设备、账户或者现实流程还没有受到影响这算不算执行反过来如果现实已经发生变化而上游系统还认为任务只是“处理中”我们又应该相信哪一个时刻这些问题看起来只是术语问题但后来我越来越觉得它们实际上决定了我们有没有可能准确地讨论 Execution Gap。如果连“执行发生在什么时候”都没有拆清那么“执行究竟在哪里偏离”也就无从谈起。所以第一章最后并没有真正结束一个问题。它只是把我从一个很熟悉的问题——“到底是哪一环出了错”带到了一个更早、也更基础的问题我们说一件事情已经被执行了到底意味着什么《执行缝隙》真正的讨论也从这里才刚刚开始。关于《执行缝隙》《执行缝隙》The Execution Gap是Execution Engineering Trilogy第一卷。本书讨论一个基础而关键的问题从人的意图到机器最终改变现实世界中间究竟发生了什么在线阅读繁體中文版 執行縫隙 | Havenlon ResearchEnglish Edition The Execution Gap | Havenlon ResearchAmazon Kindle Amazon.com: The Execution Gap (Execution Engineering Trilogy Book 1) eBook : Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: Kindle Store纸质版正在出版中。© 2026 Lin Wang / Havenlon.本文为作者手记与《执行缝隙》正式书籍正文相互独立。 未经授权请勿全文转载或用于商业再出版。 引用请注明作者及出处。