《执行控制工程》作者手记 09｜昨天的批准，为什么不能替今天的现实作出决定

本文是《执行控制工程》（Execution Control Engineering）的作者手记。 它不是书籍正文的摘要或重写，而是围绕本章问题、工程背景与写作之后的进一步思考。

在企业管理和软件工程中，我们经常听到一种非常自然的解释：“这件事情之前已经批准过了。”对于一个依赖流程和制度运行的组织来说，这句话通常具有相当充分的依据。审批可能确实经过了有资格的负责人，授权记录仍然有效，相关策略也没有发生变化，甚至整个操作流程都严格遵守了既定要求。因此，当有人再次询问这项动作为什么可以继续执行时，拿出此前已经成立的批准，似乎就是一个合理而完整的回答。

但在研究执行控制的过程中，我逐渐意识到，这种解释实际上把两个不同时间里的问题连接在了一起。过去批准过，说明过去确实发生了一次有效判断；现在准备执行，则意味着系统即将面对当前对象、当前参数以及当前已经存在的现实状态。两者之间可能存在直接联系，却不能因为前一个事实真实成立，就默认后一个结论也已经同时成立。

这并不是要否定历史审批的有效性，也不是要求所有操作都重新开始完整的授权流程。恰恰相反，只有承认过去形成的 Authorization、Policy Decision 和其他判断可以真实有效，我们才能进一步指出它们的边界：一项曾经正确的判断，并不天然覆盖未来所有不断变化的现实条件。

《执行控制工程》第八章已经讨论了执行判断的规范参照，也就是能够被识别、绑定、引用和验证的 Intent。它解决的是系统究竟拿什么来说明原来希望发生的行动。但仅仅拥有这把尺子还不够，因为一次真正的判断必须同时面对现实。我们不但需要知道原来希望发生什么，还必须知道此刻与这一次 Action 能否继续有关的现实条件究竟是什么。

这就是第九章为什么需要单独讨论 State。

一、历史判断可以继续有效，却不能自动延伸到今天

现代软件系统离不开对历史判断的继承。一个主体取得某项授权以后，后续业务可以反复验证这项资格；一条策略发布以后，可以在较长时间里持续适用；一次审批完成以后，也可能支持一系列后续操作。如果这些对象每次使用都必须从头建立，那么现代业务系统就很难维持必要的效率。

因此，问题从来不是历史判断能不能继续使用，而是它能够以什么身份进入当前执行。

Authorization 说明某项资格已经形成，而且这项资格在没有被撤销或者失效以前，完全可能继续有效。但资格的有效性与当前具体动作的执行条件并不是同一个问题。一个主体可以仍然拥有某类操作资格，而某一次操作面对的对象、金额、范围或者现实环境，已经不同于此前判断所面对的条件。

Policy 也具有类似的特点。一条规则可以长期保持不变，却不断面对发生变化的现实。假设策略规定某项操作只有在特定状态成立时才能继续，那么策略版本没有变化，只能说明规则仍然是原来的规则，不能因此证明它所要求的状态现在依然成立。

同样，一次此前形成的正确判断，也只能证明在当时输入和条件下得出了相应结论。即使这份判断可以被完整验证，也不能因为它被保存下来，就把它直接提升为关于未来现实的持续保证。

这也是为什么我认为，执行控制需要非常谨慎地处理“继承”这个概念。过去的判断可以成为当前判断的重要依据，但系统必须能够区分哪些内容可以继承，哪些条件必须根据当前现实重新确认。否则，随着时间推移，真实有效的历史记录反而可能逐渐变成掩盖现实变化的依据。

过去的授权可以继续有效，过去的策略也可以保持正确，但规则和资格没有变化，并不意味着它们今天所面对的现实条件仍然相同。

二、State 不是整个系统的数据，而是这一次执行面对的现实

讨论当前现实，很容易让工程师想到数据库、内存状态、缓存、设备遥测或者各种系统指标。现代平台拥有庞大的数据体系，也能够通过监控持续采集大量信息，因此我们似乎可以直接把这些内容统称为 State，并交给执行判断使用。

但这种理解很容易让 State 失去它在执行控制中的明确位置。

第九章对 State 的定义其实相当克制：它是在特定时点，与某次 Action 能否被判断和执行直接相关的事实与条件集合。

这里有三个必须同时保留的限定：特定时点、具体 Action，以及直接相关。

首先，State 必须具有时间属性。某项事实在过去成立，不意味着它可以脱离时间继续代表当前现实。尤其当执行链中存在排队、延迟、调度或者跨系统处理时，判断形成时的状态与动作最终发生时的状态，完全可能已经不同。

其次，State 必须围绕某一次具体 Action 建立。同一个系统可能同时运行支付、查询、配置修改和设备操作等不同业务，对于某一次付款至关重要的现实条件，未必与另一次设备操作有关。如果把整个系统的全部信息都塞进 State，就很难继续判断对于当前动作而言，究竟哪些事实是必要的。

最后，State 必须与当前动作的判断和执行直接相关。这一限定尤其重要，因为它不仅排除无关数据，还要求我们不能把某些仅仅与现实高度相关的记录，未经区分就当作现实事实本身。

因此，State 不能简单等同于数据库快照。数据库可以准确保存某个字段，也可以保证内部数据结构完整，但字段正确并不意味着它此刻必然代表真正需要判断的现实条件。

Policy 与 State 也不能混为一谈。Policy 描述规则，State 则说明规则当前面对什么事实。一条规则可以规定某个条件成立时允许操作，而 State 需要回答的是，这个条件此刻究竟是否成立。

这样的区分使 State 成为一个可以被工程化分析的对象，而不是一个笼统的“系统上下文”。它的目的不是描述整个世界，而是让当前这一次 Action 所依赖的现实条件能够被明确指出，并在执行判断发生时作为输入被使用。

State 的完整性不是由系统收集了多少数据决定的，而是由当前这一次 Action 所必需的现实事实与条件，是否真正进入了判断来决定。

三、仪表可以没有说谎，而它代表的现实已经不同

第九章使用三里岛二号机组事故作为工程说明案例，我认为其中最值得关注的，并不是仪表是否发生了通常意义上的读数错误，而是一个更加微妙的问题：系统记录的信息可能完全真实，却仍然没有表达判断真正需要的现实事实。

1979 年 3 月 28 日，三里岛二号机组事故过程中，一只泄压阀在按照设计打开以后卡在了开启位置。然而，控制室中的有关指示让操作人员认为阀门已经关闭。

这里存在一个非常关键的技术区别。根据监管机构的相关技术材料，控制室里的指示表达的是电磁阀已经失电，也就是关闭信号已经发出，并不是阀门真实的机械位置。当时控制室也没有能够直接显示该阀门实际位置的仪表。

换句话说，系统显示的信号在自身语义上可以完全正确，但它并不等于操作人员真正需要知道的那个事实。

正常情况下，关闭信号发出以后，阀门通常会按照预期完成关闭，因此这一信号可以长期与实际机械状态保持高度相关。然而，当阀门发生卡滞时，原本稳定的关系出现了分离：关闭信号仍然存在，指示也忠实表达了这个信号，可阀门本身仍然处于开启状态。

我认为这个区别对于现代自动化系统具有非常直接的启发。

我们经常把接口返回值、数据库记录或者设备反馈视为现实状态，但这些信息可能只是某种代理。接口返回“命令已接受”，未必意味着对应现实结果已经完成；控制器记录“关闭指令已经发出”，也未必能够直接证明被控制对象已经处于关闭状态。

这里不能因为代理信号与目标事实通常保持一致，就默认二者具有相同的工程语义。尤其当异常发生时，这种长期相关的关系恰恰可能成为最需要重新验证的部分。

当然，三里岛事故具有复杂的技术和组织背景，不能简单归结为一个仪表问题或者某个操作人员的失误。第九章也没有利用这起事故证明 State 的定义，而只是借助其中已经核实的技术事实，说明代理记录与当前现实可能发生分离。

真正值得记住的是，当判断需要某个现实事实时，系统不能仅仅因为拥有一个与事实高度相关的信号，就自动认定那个事实已经成立。

一个记录可以完全真实，却不代表它所代理的现实仍然成立；执行判断需要的是当前事实，而不是未经验证就被当作事实的代理信号。

四、现实条件发生变化，并不意味着原来的 Intent 已经改变

当我们开始要求执行控制面对当前 State，另一个问题也随之出现：如果现实条件不断变化，那么原来已经形成的 Intent 是否也应该随着变化而失效？

我认为这里必须保留一个非常清楚的区别。

Intent 描述的是原本希望发生的行动，包括相关对象、范围、条件和结果方向。State 描述的则是在特定时点，与这一次 Action 能否被判断和执行直接相关的现实事实。两者可以相互关联，却承担不同职责。

假设某个系统已经形成了一个明确的转账 Intent，目标账户、金额和行动范围都已经得到识别与绑定。随后，在真正执行之前，某项与当前执行资格有关的现实条件发生变化。此时，原来的 Intent 完全可能仍然是那个 Intent，它的内容没有被篡改，身份也没有发生变化。

改变的是这次 Action 在当前条件下是否仍然满足执行要求。

如果我们把这种情况直接解释成 Intent 已经改变，就会把规范参照和现实状态混在一起。系统将无法清楚地区分，究竟是最初希望发生的事情发生了变化，还是最初希望发生的事情没有变化，但现实条件已经不再支持它继续执行。

这种区分对 AI Agent 同样重要。Agent 可以根据环境变化重新调整操作计划，但并不是每一次状态变化都意味着用户原来的目标发生了变化。有些变化只影响当前动作是否具备继续执行的资格，而不必然要求重新定义整个行动指向。

不过，这里也不能走向另一个极端。如果变化本身已经触及 Intent 所表达的关键内容，那么是否形成新的 Intent，确实可能成为需要单独判断的问题。第九章并没有建立 Intent Mutation 的完整判据，因此不能简单宣布所有状态变化都不会影响 Intent。

本章真正确定的只是一个有限结论：State 的变化可以影响当前 Execution Qualification，但这种影响不自动等于 Intent Mutation。

现实条件可以变化，执行资格也可以随之改变，但原来的 Intent 并不会因为现实发生变化，就自动变成另一个 Intent。

五、最危险的不是状态未知，而是把未知继续当作成立

State 被引入执行判断以后，还会出现一系列工程中无法回避的问题。状态可能缺失，可能已经过期，也可能来自相互冲突的信息来源。有时候系统只能看到局部事实，有时候某个关键组件刚刚完成恢复，系统尚未重新建立对当前状态的充分认识。

这些情况本身并不罕见。分布式系统、云平台和物理设备都会面对信息延迟、局部不可见以及状态更新不同步的问题，因此我们不能简单要求系统始终拥有完美、完整而且实时的全部现实信息。

但执行控制真正需要防止的是，当某项必要条件没有得到确认时，系统仍然把它当作已经成立。

例如，一条执行策略要求目标设备处于某种安全状态，但系统在当前时点并没有取得足以支持该状态的有效输入。如果它只是沿用此前保存的“安全”标记，就可能在没有重新确认当前现实的情况下继续执行。

类似地，当两个来源提供了相互冲突的状态，或者某个必要字段已经超过适用时间，系统都不能仅仅因为历史上曾经存在过一个允许结果，就把当前条件自动视为满足。

这种要求与“所有状态异常都等于现实事故”并不是同一个意思。状态信息缺失、过期或者冲突，并不能单独证明现实系统已经发生了什么具体故障。真正需要区分的是，现实条件究竟如何，与系统是否已经拥有足够依据对其作出当前判断。

这也解释了为什么第九章没有把 State 的全部工程问题塞进最小定义。来源资格、版本、时间、新鲜度、冲突、局部可见性和恢复状态，都需要继续研究，但这些问题尚未被建立为完整、同层级的 State 分类体系。

能够列出这些问题，并不等于已经拥有处理它们的全部算法和协议。State 的最小定义首先确保我们知道执行判断需要面对什么对象，至于如何获得可信状态、怎样处理冲突以及如何保证状态在判断时有效，还需要后续工程继续完成。

执行控制无法要求现实永远没有未知，但不能在必要状态缺失、过期或者相互冲突时，仅凭历史上曾经允许过，就把当前条件自动判定为满足。

六、执行前重新判断，不等于把所有审批重新做一遍

讨论当前 State 时，还有一种非常自然的误解：既然过去的判断不能自动代表现在，那么是不是意味着任何一次现实状态变化，都必须重新发起审批、重新授权，并将完整流程从头再走一次？

这不是第九章的结论。

历史审批仍然具有自己的效力，Authorization 仍然可以在原有范围内继续成立，Policy 也不必因为现实条件变化就重新定义。执行控制真正要求的是，当一次具体 Action 接近现实执行时，系统不能脱离当前条件直接继承过去的允许结果。

至于这项要求应该怎样实现，并不存在从本章直接推出的唯一方案。

一种直观的工程方法，是将最终执行对象、参数以及当前 State，与此前已经批准的内容重新进行可验证的一致性比较。这种方式能够帮助系统发现原来的操作对象是否被替换，参数是否仍然属于批准范围，以及当前现实条件是否继续支持动作执行。

但显式比对并不是所有执行控制结构唯一可能的形式。某些系统也可以通过明确的 Boundary Rule，在当前动作进入现实以前直接限制它的执行范围，而不要求每次都逐项重新比较所有历史审批材料。

真正重要的是，无论使用哪一种结构，当前动作都必须受到当时适用条件的有效约束，而不是把过去的批准当作一张可以无限延续到未来的通行证。

我认为这种区分具有很强的现实意义，因为执行控制不应该被简单理解成增加组织管理成本。如果每一个当前状态变化都必须重新等待人工审批，那么系统不仅可能失去自动化效率，也未必真正解决了判断与现实之间的关系。

执行控制的价值，恰恰在于让历史资格、规范参照和当前现实各自承担自己的职责，使系统能够在不否定已有治理成果的前提下，对眼前这一次动作作出真正适用的判断。

执行前重新判断，并不等于重新完成所有历史审批；它要求的是过去已经成立的资格与当前现实条件之间，不能失去必要的执行约束关系。

七、Intent 和 State 都有了，为什么判断仍然没有完成

写到第九章结束的时候，我觉得《执行控制工程》终于把执行判断的两个重要参照放在了一起。

一端是 Intent，它说明此前希望发生什么，并且需要在执行链中保持可识别、可绑定和可验证的身份。另一端是 State，它说明当前时点与这一次 Action 能否被判断和执行直接相关的现实事实与条件。

当这两个对象被真正区分以后，我们才能清楚地讨论，一次过去已经成立的判断，为什么不能直接延伸为对今天现实的保证。

但这并不意味着执行判断已经具备了全部条件。

因为我们虽然已经知道应该依据什么，却还没有充分回答这些依据本身为什么可以被相信。

一个 Intent 可以被系统保存，却仍然需要证明它的身份、完整性和绑定关系没有被无痕改变。一个 State 可以来自数据库、设备或者外部服务，却仍然需要说明它为什么足以代表当前现实，而不是一个已经过期、只在局部可见或者与目标事实仅仅高度相关的代理记录。

三里岛事故中的技术事实，恰好让这种困难变得具体。一个在自身语义上正确的信号，并不一定就是判断需要的现实事实。即使判断逻辑完全正确，只要输入所代表的对象与实际需要判断的对象不同，最终结论就可能建立在错误的对应关系之上。

同样，我们现在也不能假定 State 与其他执行对象之间的全部关系，都可以用简单的“存在”或者“断开”来表示。有些关系从未建立，有些曾经有效却后来失去适用性，有些条件在允许的现实变化中发生改变，而这些情况并不自动构成同一种失效。

第九章虽然指出了这些问题，却没有提前建立完整的 Relation-State Model，也没有规定状态同步协议或者具体数据结构。它真正完成的，是让当前现实作为一个独立的工程对象进入执行判断，而不是继续隐藏在历史授权、数据库记录或者策略输入之中。

Intent 让系统知道原来希望发生什么，State 让系统面对现在真实存在什么；但拥有这两个参照，还不等于已经证明它们本身值得相信。

这也是我认为第九章在整个《执行控制工程》中非常重要的原因。过去我们习惯把安全性建立在审批是否完成、授权是否有效、策略是否通过这样的判断结果上，而现在我们已经能够进一步追问，这些判断究竟面对了什么现实条件，以及它们能否继续适用于眼前这一次动作。

真正的困难由此向前推进了一层：系统不能仅仅知道自己保存着什么记录，还必须能够说明这些记录与现实之间具有怎样的关系。

因此，第九章最终留下的，不是如何设计一个更完整的状态数据库，而是一个更加基础的问题：

当执行判断依赖 Intent 和 State 时，系统究竟凭什么相信，这些用于判断的依据确实成立？

这将把《执行控制工程》的讨论继续引向 Evidence，也就是那些能够使执行判断所依赖的事实与关系获得可验证依据的工程对象。

关于《执行控制工程》

《执行控制工程》（Execution Control Engineering）是 Execution Engineering Trilogy 第二卷。

本书讨论一个具体的工程问题：

在一次动作真正改变现实之前，它必须满足什么条件，才有资格被执行？

在线阅读

• 繁體中文版 https://havenlon.com/zh-tw/research/books/execution-control-engineering/

• English Edition https://havenlon.com/research/books/execution-control-engineering/

• Amazon Kindle Amazon.com: Execution Control Engineering: Designing the Boundary Between Authorization and Execution (Execution Engineering Trilogy Book 2) eBook : Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: Kindle Store

• Amazon Paperback https://www.amazon.com/dp/B0HLL6YQ4Q

© 2026 Lin Wang / Havenlon.

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