这是"历史中的执行控制"系列的第九篇。
第一篇：历史中的执行控制（一）：诺曼底登陆 D-Day 的天气窗口——没有正确的执行窗口，就不执行。
第二篇：历史中的执行控制（二）：切尔诺贝利——不要让错误穿过所有边界。
第三篇：历史中的执行控制（三）：阿波罗 13——失败不是终点，边界才是系统韧性。
第四篇：历史中的执行控制（四）：图灵与 Bletchley Park——不是破解密码，而是重构决策优势。
第五篇：历史中的执行控制（五）：珍珠港——信号必须及时改变执行状态。
第六篇：历史中的执行控制（六）：挑战者号 Challenger——工程边界不能被执行压力压过。
第七篇：历史中的执行控制（七）：Therac-25——软件不能替代所有硬件安全边界。
第八篇：历史中的执行控制（八）：火星气候轨道器——接口通过，不代表语义一致。
上一篇讲的是"接口两端的语义要一致"。这一篇讲一个更微妙的问题：一段在旧系统里被反复验证、从未出错的代码，原封不动搬到新系统里，可能正好成为致命入口。
摘要
阿丽亚娜 5 号首飞失败，常被讲成"软件 bug 导致火箭爆炸"的经典案例。但从 Havenlon 的视角看，它真正值得讨论的不只是软件错误，而是一个更深的问题：在旧系统里长期有效的代码，换到新场景里，不一定仍然安全。
这件事对今天的 AI Agent、自动化系统、企业运维和高风险执行非常重要，因为它告诉我们：历史成功不等于当前安全；旧场景成立不代表新场景成立；代码可复用不代表边界可复用。一个过去从没出事的逻辑，换到新环境里，可能正好成为风险入口。
这就是阿丽亚娜 5 号给 Havenlon 的第九课：执行不能只相信"以前这样做没问题"，每一次高风险执行，都必须重新绑定当前场景。
一、先把历史讲准确
1996 年 6 月 4 日，阿丽亚娜 5 号运载火箭的首次发射（编号 Flight 501 / V88）在法属圭亚那库鲁进行，箭上载有欧洲空间局（ESA）的Cluster——一组四颗研究卫星。升空约 37 秒后，火箭突然偏离航迹，在剧烈的气动应力下开始解体，随后被自动自毁系统炸毁，连箭带星损失约 3.7 亿美元。ESA 与 CNES 随即组建了由数学家雅克-路易·利翁（Jacques-Louis Lions）领衔的调查委员会，7 月即发布了报告。
事故的技术链条，是软件工程史上被引用最多的案例之一。火箭上有两套并行的惯性参考系统（SRI），硬件和软件完全相同，一套工作、一套热备。SRI 里有一段"对齐"功能的代码——它只在起飞前有意义，用于对准惯性平台。这段代码是从上一代阿丽亚娜 4 号直接复用来的；按照阿丽亚娜 4 的需求，对齐功能在进入飞行模式后还会继续运行约 40 秒（以便倒计时中断时无需重新长时间对齐）。可在阿丽亚娜 5 号上，这段代码起飞后根本没有任何用途，却依然在运行。
而阿丽亚娜 5 号的飞行轨迹比阿丽亚娜 4 号更"猛"，水平速度高得多。这让对齐功能里一个叫BH（水平偏置，Horizontal Bias）的内部变量变得异常大。软件在把 BH 从一个 64 位浮点数转换成 16 位有符号整数时，数值超出了 16 位整数能表示的最大范围（32767），触发了操作数错误（溢出）。
这里有一个最能说明本篇主题的细节。当时工程师其实分析过：代码里有 7 个变量可能发生这类溢出。但为了把 SRI 处理器的负载压在80% 以下，他们只给其中 4 个变量加了保护，BH 等 3 个被特意留空——因为按阿丽亚娜 4 号的物理极限做手工分析，这些值"永远不可能大到溢出"。这个判断，在阿丽亚娜 4 号的场景里是完全正确的；换到阿丽亚娜 5 号，就不再成立了。
溢出发生后，工作中的 SRI 按设计"自我关闭"；而热备的那套 SRI 跑着同一份代码、遇到同样的条件，几乎在同一瞬间也失效了。随后关闭的 SRI 向主机（OBC）发出的是一段诊断位模式，主机却把它当成了有效的飞行姿态数据，据此下达了极端的喷管偏转指令——火箭猛地偏航、解体、自毁。
利翁委员会的结论一句话概括：失败源于惯性参考系统软件中的规格与设计错误，而非某个孤立的手误。
二、这不是"代码写错了"这么简单
阿丽亚娜 5 号的失败，很容易被讲成一个纯软件故事：某个变量溢出、某段程序异常、系统失去制导、火箭失败。这些都对，但只看到这里，就会错过更深的系统教训。
真正的问题是：这段逻辑不是凭空出现的。它来自已有系统，在过去的场景里曾经有意义，带着旧系统里的假设被带进了新系统。而且它甚至不是在做一件有用的事——那段对齐代码在起飞后毫无用途，却依然在运行，最终亲手掀翻了这枚火箭。
一个逻辑在旧系统里可能合理，一个参数范围在旧轨迹里可能从未越界，一个异常路径在旧场景里可能从未被触发——但新场景不是旧场景：火箭变了，轨迹变了，速度曲线变了，系统边界变了，原来的假设也应该重新验证。没有重新验证，就不是复用，而是把旧风险悄悄带进了新的执行链。
三、复用成功代码，最容易复用隐藏假设
工程里代码复用很常见，复用成熟模块、验证过的逻辑、团队熟悉的组件——这本身没问题。真正的问题是：复用代码的同时，也复用了代码背后的假设。
这段代码假设了什么输入范围？什么运行阶段？什么速度曲线？什么系统边界？它假设自己在哪个上下文里被调用？如果这些假设没有被显式检查，代码看起来是复用，实际上是在把旧上下文偷偷带入新系统。BH 那个"永远不会溢出"的判断，就是一条被原封不动继承下来的隐藏假设。
这和 Havenlon 一直强调的"执行前重新绑定语义"非常接近。你不能只问"这段代码以前有没有跑过"，你必须问：这段代码现在运行的场景，还是以前那个场景吗？
四、旧逻辑的新风险：上下文漂移
阿丽亚娜 5 号的关键教训，可以用一个词概括：上下文漂移——逻辑本身看起来没变，但它所在的环境变了：输入范围变了、速度曲线变了、接口语义变了、运行阶段变了、失效后果变了、安全边界变了。于是原本安全的逻辑，变成了危险逻辑。
这在今天的系统里非常常见：一个运维脚本以前只用于测试环境，后来被搬到生产；一个交易规则以前只处理小额资产，后来处理高价值资产；一个审批流程以前只用于低风险操作，后来接入高风险权限；一个 AI Agent 工具以前只读数据，后来能写入、删除、转账、重启；一个策略以前只在单人账户里使用，后来进入多人共同治理。表面看逻辑没变，但执行上下文已经完全不同。
这时候，如果系统仍然说"以前这样没出过事"，就是危险信号。Havenlon 要防止的正是这种情况：旧路径不能自动继承新场景的执行权，旧逻辑不能自动越过新边界，旧成功不能自动成为新安全。
五、测试通过，不代表测试代表真实场景
阿丽亚娜 5 号还提醒我们一个很现实的问题：测试通过，不代表系统真的安全。事实上，SRI 的硬件测试过了、软件也被证明符合规格，唯独完整的惯性参考系统从未在能代表阿丽亚娜 5 号真实飞行包线的配置下被测试过——否则这个溢出本可以被提前发现。
很多系统都会说：我们测试过、评审过、跑过模拟、有灰度、有回滚、有审批。但问题是：测试是否覆盖了真实执行场景？仿真是否代表真实输入边界？评审是否重新验证了上下文变化？不具代表性的测试，反而会制造安全幻觉，因为系统会以为自己已经被验证过。这和 Havenlon 的执行控制逻辑一致：执行前不是只看有没有测试记录，而是看当前动作是否满足当前边界。
六、异常处理不是附属功能，而是执行边界的一部分
阿丽亚娜 5 号里还有一个关键问题：异常处理本身就是执行边界。
溢出发生后，SRI 直接关闭，把一段诊断数据当成飞行数据送了出去——一个本可局部化的问题，被"处理"成了整箭失效。利翁委员会尖锐地指出：这个异常被检测到了，却被错误地处理，因为当时抱持着一种观念——"软件在被证明有错之前，应当被视为正确"。报告还特别提到，SRI 的计算机其实完全可以继续输出它对姿态的最佳估计值，而不是一关了之。
这说明异常处理绝非细枝末节。一个系统出错不可怕，可怕的是出错之后的处理方式把局部问题放大成系统失效。在高风险执行系统里，异常处理必须回答：异常发生后是继续还是停止？是降级还是关闭？是冻结最后的有效值，还是输出错误状态把下游一起带偏？
这对 Havenlon 非常重要，因为执行控制不能只设计正常路径，还必须设计异常路径：证据链断了怎么办？策略冲突了怎么办？设备状态异常怎么办？上游请求不可验证怎么办？Agent 输出与 Intent 不一致怎么办？真正可靠的系统不是没有异常，而是异常发生后不会把错误继续推进到现实执行。
七、冗余不是复制同一个错误
复杂系统常用冗余：两套惯性参考系统、多个服务实例、多节点审批、多重签名、主备切换。但阿丽亚娜 5 号给了一记警钟——冗余不是简单复制。
它的两套 SRI 跑着完全相同的软件、共享完全相同的假设、面对完全相同的未覆盖输入，于是当溢出到来时，主用的那套关闭，热备的那套几乎在同一瞬间以同样方式失效。看起来有两套，实际上只是同一个错误假设的两份副本。
在 Havenlon 的世界里，这个教训非常关键：多审批不等于共同治理，多签名不等于多边界，多策略来源不等于更安全，多个软件模块不等于独立裁决，多个 Agent 复核不等于真正的分层不信任。如果它们共享同一份错误上下文，风险仍然会一起穿透。真正的冗余应该带来差异化的边界，真正的多层控制应该避免同源失败，真正的共同治理应该让任何单点都无法把灾难性执行直接推到底。
八、AI Agent 时代，旧流程复用会更危险
阿丽亚娜 5 号的故事，在 AI Agent 时代会重新变得重要，因为Agent 极其擅长复用：复用历史流程、已有脚本、过去的操作经验、模板化审批、工具调用链、上一次成功的路径。这看起来很高效，但高风险执行最怕的就是——把上一次的成功，误认为这一次的安全。
一个 Agent 很可能会"想"：上次这样部署成功了、上次这样导出没问题、上次这样转账通过了、上次这个权限临时放开没出事、上次这个审批模板被接受了。但这一次的上下文可能已经变了：环境变了、权限变了、数据范围变了、资产规模变了、风险窗口变了、审批成员变了、工具版本变了、攻击面变了。
所以 AI Agent 的执行不能只依赖"历史可行"，它必须在每一次高风险动作前重新绑定当前上下文。这就是 Havenlon 的位置：Agent 可以提出计划，SaaS 可以组织流程，审批可以表达同意，策略可以给出规则——但最终执行必须经过独立边界重新裁决那个唯一重要的问题：这一次，真的安全吗？
九、Havenlon 的答案：每次执行都必须重新绑定当前场景
Havenlon 反对的不是复用——工程系统不可能不复用，企业系统不可能每次从零开始，AI Agent 也不可能每一步都完全手工构造。Havenlon 反对的是未经重新绑定的复用：旧逻辑可以被复用，但不能自动继承执行权。
每一次高风险执行，都应该重新绑定当前的 Intent、身份、策略、设备状态、时间窗口、资产范围、操作对象、上下文版本、证据链状态和本地执行边界。如果这些绑定不成立，系统就不应该因为"以前成功过"而继续放行。
这就是 Havenlon 与普通自动化系统的差别：普通自动化更关心"如何把过去成功的流程更快地复制"，而 Havenlon 更关心"这次复制是否仍然满足当前边界"。
十、从九篇看主线：执行控制的第九个侧面
D-Day 告诉我们：没有正确窗口，不执行。命令存在，不等于现实允许。
切尔诺贝利告诉我们：不要让错误穿过所有边界。灾难往往来自多个弱边界连续放行。
Apollo 13 告诉我们：失败不是终点，边界才是系统韧性。失败后的边界决定系统能否收敛。
Bletchley Park 告诉我们：不是破解密码，而是重构决策优势。信息不进入边界，就只是信息。
珍珠港告诉我们：信号必须及时改变执行状态。看见风险不够，必须在窗口关闭前完成状态切换。
挑战者号告诉我们：工程边界不能被执行压力压过。系统最想继续的时候，边界最应该能说"不"。
Therac-25 告诉我们：软件不能替代所有硬件安全边界。高风险执行必须保留独立边界。
Mars Climate Orbiter 告诉我们：接口通过，不代表语义一致。一个语义错配就能穿过整条执行链。
Ariane 5 告诉我们：复用成功代码，不代表新场景依然安全。旧逻辑进入新环境，必须重新验证边界。
这九篇共同指向 Havenlon 的核心判断：执行不能只服从意图，不能只服从接口，不能只服从软件，也不能只服从历史经验——执行必须经过当前场景下的边界裁决。
结语
阿丽亚娜 5 号的故事，不该只被当成一个软件 bug 案例。它真正提醒我们的是：成功经验本身，也可能成为风险来源。
因为成功经验最容易被信任，被信任的东西最不容易被重新检查，不被重新检查的假设最容易穿过执行链，一旦进入真实执行窗口，它就可能变成不可逆的结果。那段在阿丽亚娜 4 号上安全飞行了无数次的代码，正是因为"一贯正确"，才没有人再去质疑它在阿丽亚娜 5 号上是否依然成立。
Havenlon 要防止的，正是这种从"过去成功"到"当前失控"的滑坡。AI 和自动化时代，系统会越来越快地复用过去的动作——但越是能快速复用，就越需要重新绑定当前边界。不是每段成功代码都适合新场景，不是每个旧流程都适合新任务，不是每次历史经验都能成为当前执行依据。
Ariane 5 给 Havenlon 的第九课是：
复用不是问题，未经边界重验的复用，才是问题。 真正可靠的执行系统，必须在每一次高风险动作发生前，重新问一次：这一次，场景还是原来的场景吗？
参考资料
J. L. Lions 等，ARIANE 5 — Flight 501 Failure: Report by the Inquiry Board（ESA / CNES，1996 年 7 月 19 日）
Bashar Nuseibeh,Ariane 5: Who Dunnit?, IEEE Software, 14(3), 1997
Jézéquel & Meyer,Design by Contract: The Lessons of Ariane, IEEE Computer, 1997
Wikipedia,Ariane flight V88；ESA 关于 Cluster 任务与 Ariane 501 的资料
