本文是《执行缝隙》The Execution Gap的作者手记。 它不是书籍正文的摘要或重写而是围绕本章问题、工程背景与写作之后的进一步思考。工程系统里有很多词我们每天都在用以至于很少再去追问它们到底是什么意思。“成功”“完成”“生效”“执行”都是这样。只要系统运行正常这些词通常不会造成太大麻烦因为提交、调用、状态变化、外部响应和现实结果往往恰好同时成立于是大家说“已经执行了”彼此也都知道大概在说什么。真正的问题往往是在这些东西第一次分开的时候才出现。一个系统显示任务已经完成接口也返回了成功外部平台甚至给出了一份格式完整的回执可现实里的事情并没有按照人们以为的方式发生。事故复盘进行到这里时讨论经常会变得很奇怪因为不同岗位的人都可以拿出证据证明自己没有说错。调用确实发出去了状态确实更新了回执也确实存在而现场看到的结果同样是真的。没有谁一定在撒谎只是大家说的那个“执行了”从一开始就不是同一件事。写第二章的时候我越来越觉得这不是一个单纯的术语洁癖问题。很多执行风险之所以很难被提前看见恰恰是因为工程语言把几个不同对象压缩进了同一个词里。只要它们长期保持一致这种压缩不仅方便而且几乎没有成本可一旦其中某两个对象发生分离我们就会突然发现过去那个非常好用的词已经不足以描述眼前发生的事情。工程系统最容易相信自己能够看见的东西软件天然更容易确认软件世界里的事实。一条记录有没有写入数据库很容易确认一个请求有没有发出可以从日志中看到一个接口返回了什么可以被完整保存一个任务状态是SUCCESS还是FAILED可以直接展示在界面上甚至外部系统返回的一份签名回执也可以被验证、归档并长期保存。这些东西都有一个共同特点它们容易被系统表示。而现实结果往往没有这么方便。一台机器是不是实际上停了一笔钱是不是已经以业务上认可的方式完成支付一个账户是不是已经真正失去访问能力一项配置是不是已经在所有实际生效节点上被改变这些问题有时可以由系统直接确认有时却需要额外观察甚至需要等待一段时间才能知道。于是工程系统很容易形成一种自然倾向用最容易被确认的对象代表那个最难被确认的对象。接口返回成功于是我们说执行成功了状态被写成完成于是我们说事情做完了第三方给出“已处理”回执于是我们认为现实动作已经发生。绝大多数时候这种替代可能确实没有造成后果因为系统设计者原本就希望这些对象保持一致。但“通常保持一致”和“它们本来就是同一个对象”并不是一回事。这也是第二章里我特别想拆开的地方。提交不是调用调用不是执行状态执行状态不是回执回执不是结果结果也不是证据。这里最重要的甚至不是记住这些名词而是意识到一个系统拥有某个对象并不能因此自动拥有另一个对象。一份完整的日志可以证明系统记录过什么却不能让一件没有发生的事情因此发生一个签名正确的回执可以证明某个外部主体确实做出了某种声明却不能因为签名可信就顺便证明那个声明所指向的现实状态已经成立同样一次真正发生的现实动作也不会因为系统没有留下足够完整的记录就因此变成“没有发生”。我们过去很容易把“能证明什么”与“发生了什么”混在一起。当系统规模还小、动作还慢、人工参与还很多时这种混用未必经常暴露出来。但一旦执行越来越自动化尤其是 Agent 可以连续跨越多个系统之后这种语言上的压缩会直接变成工程上的风险因为后一个系统很可能把前一个系统提供的“成功”当成现实已经成立然后继续做下一件事。错误并不一定发生在某个组件内部它可能发生在对象之间未经证明的替代关系里。我后来越来越警惕“状态已经是成功”做系统的人都喜欢状态机因为状态机可以把复杂过程压缩成有限的几个明确状态。PENDING、PROCESSING、SUCCESS、FAILED看起来非常干净也很容易被其他系统消费。问题在于状态首先是一种系统表达它描述的是系统认为事情已经走到了哪里。现实并不承担遵守这套状态机的义务。一个任务可以因为超时逻辑被标记成失败但外部动作其实已经发生也可以因为异步处理提前返回成功而真正的现实变化要到几分钟之后才出现。甚至可能存在更加麻烦的情况系统已经不知道结果究竟是什么却因为业务流程无法长期停留在“不知道”最终被某种默认逻辑推向成功或失败。我认为“未知”是现代工程系统里一个经常被低估的状态。我们喜欢确定性因为确定的状态容易继续推进流程而未知会让系统停下来。于是很多系统在设计时会努力尽快消灭未知重试一次查一下状态等待一个超时如果还不知道就按照某条规则把它归入成功或者失败。这种设计有时是业务必须但它同时也掩盖了一个事实系统不知道并不等于现实没有答案系统暂时无法确认也不等于那个答案可以由流程自己补出来。在执行控制里这个区别尤其重要。因为一旦“未知”被自动翻译成了一个确定状态后面的所有组件都会开始基于这个确定状态继续推理。于是最初只是“我们还不知道现实发生了什么”经过几层系统传播之后很可能变成“现实已经确定发生了某件事”。这时再去看日志每一层仍然可能都是自洽的。而这恰恰又回到了第一章的问题局部成立并不能替端到端结果作证明。我不想把它们画成一条漂亮的流水线第二章写到中间时还有一个很强的诱惑就是把提交、调用、状态、回执、结果、证据画成一条完整流程。从视觉上看这几乎是最自然的表达方式。左边是提交然后箭头指向调用再指向执行状态、回执、结果最后产生证据。这样的图非常符合工程师的阅读习惯也很容易让人产生一种“终于把执行过程说清楚了”的感觉。但我最后没有这样做。因为一旦画成箭头图本身就在偷偷增加关系。它会让人自然认为这些对象存在固定顺序会认为前一个成立以后下一个就应该成立还会进一步认为只要后面的对象已经出现前面的对象大概也已经成立。可现实系统并不一定按照这条整齐的线运行。证据可能从动作发生之前就已经开始产生回执可能早于某些内部状态更新结果可能已经发生而调用方仍然不知道某个外部状态也可能因为另一个主体的动作而变化并不是由眼前这次调用造成。因此这些对象之间当然可以建立关系但关系必须被建立而不是因为它们同时出现在“执行”这件事周围就默认关系已经存在。这个区别对我来说非常重要。理论最危险的一种完整感就是为了让结构看起来漂亮提前把还没有被证明的关系补进去。图一旦画得太顺读者就很容易把视觉顺序当成因果顺序术语一旦排列得太整齐也很容易让人相信它们天然属于同一个层级。所以第二章有一个看起来有些反常的处理先把对象拆开却不急着把它们重新连起来。这其实和第一章一样。第一章拆掉的是“每一环都对所以整体也对”第二章继续拆掉的是另一种类似的习惯——“这些对象都围绕同一次执行出现所以它们应该能够互相推出”。我越来越觉得在真正建立执行控制理论之前这种克制比快速给出一个完整架构更加重要。“结果”可能比我最初以为的还要复杂把执行动作和结果分开以后我原本以为“结果”会成为一个相对稳定的对象但继续往下写很快又碰到了新的问题。所谓结果到底是哪一种结果系统返回一个技术成功是结果现实世界已经发生某种状态变化也是结果到了业务层面这种变化究竟算不算完成了原来的目标又可能是另一回事。例如支付系统返回成功并不一定等于收款方在业务意义上已经可以使用这笔钱设备控制接口返回停机成功也不一定等于现场设备已经停止产生现实作用。技术系统看到的结果、外部现实呈现出来的状态以及业务最终认可的结果有时高度一致有时却可能在不同时间点才分别成立。我在第二章里没有继续把这几个东西形式化。并不是因为它们不重要而是因为当时还没有足够依据证明它们之间应该如何排列。与其为了完整性强行画出一个层次我更愿意先保留这个问题。写这套理论以后我越来越接受一件事情一个理论在早期真正重要的能力不只是回答问题还包括知道哪些问题暂时不能回答。如果一个关系尚未建立就先不要因为它“看起来应该如此”而把它写进去。这种克制会让理论在开始的时候显得没有那么完整但它也避免了后面大量建立在错误前提上的推导。从“执行了吗”到“你说的是哪一个对象”现在回头看第二章我觉得它真正改变我的并不是让我获得了一套新的术语而是让我对日常工程对话里一个非常普通的句子产生了警惕。以后再有人问我“执行了吗”我很难再像以前那样自然地只回答“执行了”或者“没有”。我会先想知道他到底在问什么。是请求已经提交了吗是调用已经发出去了吗是系统状态已经更新了吗是现实中的动作已经发生了吗是已经收到了某个主体的声明还是我们已经能够确认最终被关心的结果只有当这些对象重新被说清楚“执行”这个词才开始恢复它应有的精度。而第二章结束以后问题反而比开始时更加麻烦了。因为现在我们已经知道一个执行链里可以同时存在很多彼此不同、又都能够在自己的范围内成立的对象。提交可以是真的调用可以是真的状态可以是真的回执和证据也都可以是真的而最终被关心的结果仍然可能与它们对不上。如果这些对象本身都没有坏那么偏差究竟发生在哪里到这里《执行缝隙》才真正开始从“存在一种偏差”走向下一步更困难的问题偏差究竟存在于什么之间。关于《执行缝隙》《执行缝隙》The Execution Gap是Execution Engineering Trilogy第一卷。本书讨论一个基础而关键的问题从人的意图到机器最终改变现实世界中间究竟发生了什么在线阅读繁體中文版 執行縫隙 | Havenlon ResearchEnglish Edition https://havenlon.com/research/books/the-execution-gap/Amazon 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.本文为作者手记与《执行缝隙》正式书籍正文相互独立。 未经授权请勿全文转载或用于商业再出版。 引用请注明作者及出处。