企业官网建设流程全解析

本文是《执行缝隙》（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 Research

• English Edition The Execution Gap | Havenlon Research

• Amazon 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 Store

• 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.

本文为作者手记，与《执行缝隙》正式书籍正文相互独立。 未经授权，请勿全文转载或用于商业再出版。 引用请注明作者及出处。