本文是《执行控制工程》Execution Control Engineering的作者手记。 它不是书籍正文的摘要或重写而是围绕本章问题、工程背景与写作之后的进一步思考。在过去的软件工程实践中我们已经建立了许多用于管理权力的机制。身份认证负责确认请求来自谁权限系统限制主体可以访问什么授权机制建立主体与资源之间的资格关系审批流程记录组织作出的决定策略引擎根据规则判断一项请求是否可以继续。这些机制经过多年发展已经形成了相对成熟的工程方法也成为现代企业系统、金融平台以及自动化基础设施不可缺少的组成部分。但在研究执行控制的过程中我逐渐发现我们虽然花费了大量精力回答“谁可以做什么”却很少单独追问另一个问题当一次动作真正即将改变现实的时候究竟是什么让它获得最终的现实效力这两个问题看起来非常接近甚至在很多系统里一直被当作同一个问题处理。我们习惯认为一个主体通过身份认证、拥有正确权限、取得有效授权、完成审批并通过策略检查以后最终执行就已经具有充分依据。但《执行控制工程》前三章逐步建立的结论表明这些对象各自在自己的范围内成立并不自动意味着当前这一次具体 Action 已经获得执行资格。第四章因此需要继续向前一步。它不再只是讨论应该在什么位置判断也不再只是区分执行能力、授权资格与当前执行判断而是开始触及一个更加基础的问题当这些已有机制全部完成自己的工作以后最终能够让现实发生变化的权力究竟应该怎样被理解一、我们一直在管理权限却可能没有真正回答权力的问题工程师非常习惯通过权限模型理解系统中的权力关系。一个账号能够访问哪些资源一个服务能够调用哪些接口一个管理员具备哪些操作能力通常都可以从角色、权限或者授权记录中找到答案。在许多业务系统里这种方法已经能够有效解决大部分访问控制问题因此当我们进一步讨论执行控制时最自然的反应往往是继续细化这些已有机制。但权限管理与现实执行之间并不存在一条能够自动成立的等价关系。假设一家企业准备修改对外收款账户发起请求的账号是真实的操作人员拥有对应权限授权记录完整业务审批已经通过策略引擎也正确返回了 ALLOW而执行服务本身持有能够完成账户修改的有效凭据。从传统工程检查的角度看这次操作似乎已经具备所有必要条件每个相关组件都能够解释自己为什么允许请求继续。然而当我们真正追问这次修改为什么能够最终生效时会发现前面的答案其实分别指向不同对象。身份认证只能确认请求来源权限描述名义上的允许范围授权记录说明资格如何形成审批表明治理流程曾经作出同意策略引擎完成的是规则判断而执行服务持有凭据只说明现实中存在能够实施修改的技术路径。这些事实全部成立并没有自动建立一个关于最终现实效力的共同结论。尤其当多个系统之间存在状态变化、对象转换或者执行路径交接时任何一个局部判断都不能仅凭自身成立就直接代表最终那一次现实动作。这也是为什么我认为 Authority 必须从已有安全概念中单独抽出来讨论。它不是因为传统权限体系毫无价值才出现而是因为传统体系所回答的问题与现实动作最终为什么能够生效并不能被简单视为同一个问题。一个系统可以准确知道请求来自谁、主体拥有什么权限、流程经过哪些审批却仍然没有单独回答究竟是什么让这一次具体动作获得改变现实的效力。二、现实中能够做到与拥有最终权威之间还有一道边界第三章已经把 Execution Capability 与 Authorization 分开。前者关注现实中是否存在能够造成结果的技术路径后者关注某个主体是否被允许拥有或者使用相应能力。到了第四章这个区分还需要继续推进因为即使我们已经确认能力真实存在也确认资格已经成立仍然不能因此直接认定 Authority 已经得到建立。这一点在自动化系统里尤其容易被忽略。一个程序如果持有某项接口凭据就可能实际完成对应操作一个服务如果能够访问生产环境就可能拥有改变配置或者资源状态的技术能力。随着系统不断扩展技术上能够完成的事情会越来越多而工程师也容易把这些实际能力理解为对应的执行权力。但 Capability 首先描述的是现实中能否造成某个结果它并不自动说明这项能力在什么范围内具有权威更不能仅凭技术路径存在就证明当前这一次动作应当获得现实效力。制度上的授权也不能直接填补这个差额。授权可以有效改变主体的资格状态使某项原本不被允许的能力获得使用资格但资格成立本身仍然不能自动转化成针对所有未来动作的最终 Authority。一个主体可以合法拥有某类能力却不能仅凭这种资格就把任何时候、任何对象和任何状态下的具体操作都视为已经获得最终执行依据。从这里继续往下看就会发现我们过去习惯使用的“拥有控制权”实际上可能包含不同的能力。能够发起动作是一回事能够批准某类动作是一回事能够在特定条件下拒绝动作又是另一回事。它们可以存在联系也可能由不同主体承担但不能因为同样涉及权力就被提前合并成一个概念。这也是第四章需要保持克制的地方。它并没有规定 Capability 应该通过哪些条件转换为 Authority也没有建立一套从权限到授权、再到最终权威的自动升级规则。因为只要这种转换关系还没有被正式证明我们就不能为了让系统结构看起来完整而假定它已经自然存在。掌握一条能够改变现实的执行路径只能说明动作事实上可能发生这项能力是否拥有让当前动作生效的权威仍然需要一个独立答案。三、策略能够作出判断但判断并不会自动约束执行器在安全工程中Policy 往往被视为非常重要的控制手段。我们可以通过规则限定操作范围、对象资格、金额、时间和其他条件也可以让策略引擎根据当前输入给出明确的 ALLOW 或 DENY。相比依赖人工经验这种方式具有可重复、可验证和便于自动化的优势因此在复杂业务系统中具有非常现实的价值。但第四章进一步提醒我们Policy Decision 是否正确与它是否能够真正约束 Executor仍然是两个不同的问题。假设一个策略引擎能够准确识别某次操作不满足当前条件并且正确返回 DENY。从策略自身的角度看这次判断已经完成系统甚至可以保存完整日志证明引擎按照既定规则作出了正确决定。然而如果真正能够改变外部状态的执行程序并不受这个结果约束那么这次拒绝虽然真实存在却没有阻止对应的现实动作。这里的困难并不来自判断逻辑不够准确而是判断结果与实际执行能力之间尚未形成有效的约束关系。反过来即使策略返回 ALLOW也不能仅凭这个结果就认为最终 Action 已经取得现实效力。ALLOW 首先说明策略面对的输入满足相应规则而不是说策略引擎已经自动拥有决定一切现实动作的最终 Authority。我认为这种区分很重要因为现代系统正在不断增加规则、策略和自动判断能力。我们可以设计越来越复杂的策略语言也可以构建更加严格的规则验证机制但如果没有继续追问这些判断如何真正影响执行那么系统可能拥有非常完善的决策能力却仍然没有清楚建立最终现实约束关系。这并不是否定 Policy而是在为它确定正确的位置。策略可以成为执行判断的重要依据可以表达限制条件也可以参与形成对动作的约束但策略存在、策略正确以及策略结果最终能够改变现实是需要分别说明的事情。策略能够准确说出 ALLOW 或 DENY并不意味着现实已经受到这个判断约束决定是否正确与决定能否真正作用于执行器是两项必须分别成立的工程事实。四、Authority 不是职位也不能简单等同于否决权讨论 Authority 时还有一种很自然的误解就是把它理解为组织中的最高负责人、拥有最大权限的管理员或者某个能够批准所有操作的中心角色。这种理解在日常语言里并不奇怪。我们经常把权威与组织职位、管理等级或者专家地位联系起来但《执行控制工程》讨论的是工程意义上的 Authority而不是社会身份或者组织声望。在第四章中Authority 至少指向一种在明确范围内对 Action、规则、状态或者边界作出对系统具有约束力之决定的权力。这个最小工程边界让我们能够开始讨论它与现实执行之间的关系却仍然不足以构成一套完整的一般定义。尤其需要注意的是Authority 不能被理解为某种没有边界的最高权限。如果一项权力可以因为某个主体拥有管理身份而无限扩张或者因为它能够批准某类操作就进一步被认为能够决定所有现实动作那么我们实际上又把 Authority 重新变成了传统权限层级中最大的一层。Governance 也需要与之区分。治理可以制定规则、规定审批程序、建立责任关系并决定组织中哪些主体应该参与某项工作但治理结构存在不意味着它本身就等于最终现实执行权。治理可以对执行形成约束却不能因此与 Final Execution Authority 直接画等号。Veto 则提供了另一个非常重要的观察角度。过去我们讨论执行能力时往往更加关注谁能够发起动作、谁能够完成动作而执行控制还必须关心当现实副作用尚未发生时谁或者什么仍然能够有效阻止这一次动作这个问题揭示了权威的重要一面因为一个能够参与审批的主体并不一定拥有让动作真正停止的能力。但由此仍然不能直接推出 Veto 就是 Authority 的完整定义。能够拒绝是一种重要的现实约束能力Authority 却还涉及其作用对象、范围及与其他结构之间的关系本章并没有把这些部分完整建立起来。因此我更倾向于把第四章理解为一次必要的概念清理。它并不是马上告诉读者应该建立怎样的权威体系而是先阻止身份、职位、授权、治理与否决能力继续被当作可以相互替代的东西。真正的工程权威不来自一个主体拥有多高的职位或者多大的名义权限而必须落实到明确范围内能够对现实动作形成什么约束拥有否决能力很重要却也不能单独定义全部 Authority。五、为什么现在还不能把 Authority 画成一张完整的结构图写到这一章时我其实能够明显感觉到一种来自工程习惯的压力既然已经把 Identity、Permission、Authorization、Approval、Policy、Capability 和 Authority 区分出来那么下一步似乎就应该将它们整理成一张完整的架构图明确每个对象属于哪一层以及它们之间怎样逐级形成最终执行权。这种做法在工程设计中非常常见因为架构图能够帮助团队交流也容易把抽象概念转化为实现任务。但在理论仍然存在未决关系的时候过早画出一张看起来完整的图也可能让图形替尚未成立的结论作出决定。例如我们已经知道 Authority 不能等同于 Permission、Capability 或 Authorization也知道 Policy Decision 不能自动取得对 Executor 的现实约束力。但从这些否定判断出发并不能直接反推出 Authority 应当具备怎样的全部正面条件。排除了几个错误答案并不意味着剩下的部分已经自动成为正确答案。类似地我们可以说 Execution Control 需要面对 Authority但这是一种依赖关系并不能因此认为 Execution Control 与 Authority 是同一个对象。如果因为两个概念在工程中相互依赖就让它们互相定义那么整个结构很容易陷入循环解释Authority 因为执行控制而成立执行控制又因为拥有 Authority 而成立。这也是我希望保留“Dependency ≠ Identity”这一判断的原因。两个对象可以紧密协作可以相互提供必要条件也可以共同影响现实但只要它们回答的问题不同就不应该为了简化架构而被合并。因此第四章不会把若干否定边界整理成一张 Authority 判定清单也不会提前规定提议、批准、治理、仲裁、否决与执行之间必须形成怎样的统一层级。这些结构在后续工程中可能需要讨论但它们之间的完整对应关系不能因为当前已经拥有几个熟悉的术语就被视为完成。在我看来一套工程理论真正需要谨慎的地方往往不是已经建立的部分而是那些看起来只差一步、实际上却尚未获得充分依据的推论。知道 Authority 不能被哪些已有概念替代并不等于已经知道 Authority 的全部成立条件一张漂亮的结构图也不能替尚未完成的理论关系作出证明。六、把问题单独提出以后才真正看见下一道工程难题回头看《执行控制工程》前四章可以发现整个讨论一直在逐渐收紧。第一章说明上游审批、授权和策略分别成立不能自动推出当前 Action 应当执行第二章确定判断必须发生在现实副作用尚未形成而且拒绝仍然能够影响动作的位置第三章进一步区分现实执行能力、制度资格与当前执行判断第四章则终于把“谁或什么能够让这一次动作获得现实效力”从已有权限与控制概念中独立出来。这个过程看起来像是在不断增加新的概念但我认为它真正做的事情恰恰相反它是在逐步减少那些长期存在的概念混用让每个工程对象重新回到自己能够回答的问题上。在 AI Agent 越来越深入真实业务系统的背景下这种区分具有直接意义。一个 Agent 可以拥有真实身份可以通过正常授权获得工具调用资格可以满足既定策略甚至可以通过一条完全合法的执行路径改变现实。但这些事实并不会仅凭自身成立就自动回答最终现实效力由什么决定。同样一个组织可以建立完整治理机制安排人员审批部署策略引擎并让多个组件共同参与执行判断但治理过程完整也不能直接证明最终 Authority 已经被清楚建立。这里真正需要继续面对的已经不是怎样把某个主体的权限配置得更加精细而是最终现实效力的权力结构究竟是什么。这个问题可以涉及人也可以涉及软件、设备或者其他工程主体但第四章并没有证明它必须集中在某一个主体手中也没有证明它一定不能由单一主体持有。这两种结论都不能提前作出。本章能够确认的是 Authority 必须被单独分析而且不能从身份、权限、授权、审批、策略判断或者执行能力中的任何一项自动推出。至于这种权力应当怎样形成是否可以分离由谁持有以及最终能否不依赖某个单一主体而仍然形成有效约束才是接下来真正值得展开的问题。当身份、权限、审批、策略与执行能力都已成立最终现实效力的归属仍然不能被默认只有把“谁或什么能让它发生”单独提出执行控制才有机会真正讨论权力应当如何作用于现实。所以第四章并没有给出一个新的最终控制者也没有宣布某个组件必然拥有最高权威。它只是把一个长期隐藏在其他安全概念下面的问题完整地暴露出来让后续工程不能再轻易绕过。而下一章需要面对的也正是这个问题更难的一面最终让一次 Action 获得现实效力的权力真的必须归属于某一个人、某一个组件或者某一个主体吗关于《执行控制工程》《执行控制工程》Execution Control Engineering是Execution Engineering Trilogy第二卷。本书讨论一个具体的工程问题在一次动作真正改变现实之前它必须满足什么条件才有资格被执行在线阅读繁體中文版 https://havenlon.com/zh-tw/research/books/execution-control-engineering/English Edition Execution Control Engineering | Havenlon ResearchAmazon 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 StoreAmazon Paperback Execution Control Engineering: Designing the Boundary Between Authorization and Execution (Execution Engineering Trilogy): Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: 9798177920689: Amazon.com: Books© 2026 Lin Wang / Havenlon.本文为作者手记与《执行控制工程》正式书籍正文相互独立。 未经授权请勿全文转载或用于商业再出版。 引用请注明作者及出处。