《执行控制工程》作者手记 10｜系统说“我有日志”，究竟证明了什么

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

在开发和维护软件系统的过程中，我发现工程师有一种非常自然的习惯：当有人质疑系统为什么作出了某个决定，或者某项操作究竟有没有正确发生时，我们往往会首先打开日志。如果日志记录完整，时间戳清楚，请求参数能够对应，关键操作也有相应的返回结果，那么我们通常会认为，这件事情已经有了可以追溯的依据。

这种习惯并没有错。现代系统能够被维护、排查和审计，很大程度上依赖于日志与记录机制。没有这些材料，许多软件故障甚至无法被准确还原。但在研究执行控制的过程中，我越来越意识到，我们经常在不知不觉中赋予日志一种它本来不具备的能力：因为系统记录了某件事，就认为这件事已经得到证明；因为一份记录能够被验证，就进一步认为记录所描述的现实必然成立。

这个推论在普通故障排查中可能不容易暴露问题，因为工程师通常只需要还原程序经过了哪些步骤。但当系统开始根据这些材料决定是否允许资金转移、生产配置修改或者物理设备动作时，“记录了什么”与“凭什么相信它”之间的区别，就不再只是审计方法上的问题，而会直接影响一次现实执行能否获得正确的判断依据。

《执行控制工程》前两章已经为判断建立了两个重要参照：Intent 说明原来希望发生什么，State 说明当前现实中与这一次 Action 直接相关的事实和条件。到了第十章，我们需要面对一个此前一直没有得到完整回答的问题：即使系统能够明确指认 Intent 和 State，又凭什么认为它们所表达的内容确实成立？

我认为，这正是 Evidence 必须作为独立工程对象被讨论的原因。

一、日志能够记录系统说了什么，却不能让系统说的话自动成为事实

在日常软件工程中，我们往往会把日志视为事实的直接来源。某个服务记录“检查已通过”，我们便认为相关检查已经完成；某个接口返回“执行成功”，我们便认为操作已经发生；某个设备报告“当前连接数为零”，我们也很容易将这个结果作为判断系统当前状态的依据。

但仔细分析以后，会发现这些表达首先都是系统给出的声明。

一条记录写着“检查已通过”，至少能够说明系统保存了一条具有这项内容的记录；至于检查是否真的按照要求完成、记录是否对应当前动作、形成记录的主体是否具有相应资格，以及记录内容是否足以支撑最终判断，仍然需要另外回答。

假设某个自动化系统准备关闭一项服务，执行条件要求当前连接数必须为零。系统在日志中找到一条“连接数为零”的记录，于是允许关闭操作继续。整个流程可以非常清楚，日志也可以具备完整的时间戳和数字签名，但我们仍然需要知道，这条记录描述的究竟是当前连接状态，还是某个历史时点的状态；记录来自真正能够观察连接情况的位置，还是来自一个只能读取缓存的组件；它所对应的服务对象，是否就是眼前准备关闭的服务。

这些问题不是在怀疑日志一定错误，而是在指出日志与现实之间存在一段不能被自动省略的证明关系。

一份材料的内容可以真实存在，保存过程可以完全正确，甚至在密码学意义上没有受到篡改，但这些性质仍然不能直接证明它描述的现实事实。签名能够为特定数据的完整性以及与签名密钥之间的关系提供支撑，却不能因为签名验证成功，就自动证明数据来源所作出的全部现实声明都是真实的。

第十章真正希望拆开的，就是这种看似顺畅的推理。我们不能因为记录存在，就默认事实成立；也不能因为记录经过签名，就把签名有效直接等同于现实正确。

日志能够忠实记录一项声明，却不能仅凭记录真实、格式完整或者签名有效，就让这项声明自动成为已经得到证明的现实事实。

二、被证明的对象、证据和判断，必须是三件不同的事

写这一章时，我认为最值得固定的不是某一种日志格式，也不是某项密码学技术，而是 Evidence 在整个执行判断中究竟应该承担什么角色。

在本书当前采用的工程定义中，Evidence 为一个与自身可区分的 Claim、Fact、State、Relation 或 Event 提供可验证支撑。

这里真正重要的是“与自身可区分”。

如果系统需要确认当前连接数是否为零，那么“当前连接数为零”首先是一个等待确认的事实。为了支持这个事实，系统可以取得与当前对象、时点和状态有关的可验证材料。这些材料承担 Evidence 的作用，而系统根据它们判断当前连接数是否确实满足要求，则形成另一项 Judgment。

这三种对象不能因为它们最终参与了同一次执行判断，就被压缩成同一个东西。

如果把事实和 Evidence 合并，那么事实就开始通过自身的声明证明自己。系统只要写下一条记录，就能够把记录里的内容视为现实成立，这相当于取消了证明过程中被证明对象与支撑材料之间本应存在的距离。

如果把 Evidence 与 Judgment 合并，问题则发生在另一侧。材料一旦存在，系统就自动认为判断已经完成，不再检查这些材料究竟能不能支持当前结论。进一步发展下去，甚至会形成“材料已经齐备，所以动作可以执行”的逻辑，让 Evidence 在没有独立判断的情况下，直接取得影响现实动作的能力。

这种混淆在自动化系统里尤其需要警惕。因为软件完全可以把记录生成、记录读取和执行放行安排在同一个程序中，使整个过程看起来非常高效。程序完成操作以后写入成功记录，随后读取自己的记录，再据此认为某个条件已经满足。从代码逻辑看，每一步都可能正常运行，但整个过程中，待证事实、支撑材料和判断已经形成了相互依赖的闭环。

因此，Evidence 的独立地位并不是为了增加一个新的数据类型，而是要求系统不要让需要证明的事实、用于证明的材料，以及最终作出的判断彼此替代。

事实不能因为被记录就自动证明自己，Evidence 不能因为存在就自动完成 Judgment，而 Judgment 也不能反过来成为证明自身正确的依据。

三、证据不是一种文件格式，而是材料在判断中承担的角色

很多工程师听到 Evidence，首先想到的可能是一份审计报告、一条具有签名的记录、一份不可篡改日志，或者某种专门保存的证明文件。这些联想都可以理解，因为在具体工程系统里，Evidence 总需要通过某种数据结构或者存储介质被承载。

但 Evidence 的工程角色，不能直接由它采用什么载体来决定。

一条普通日志可以成为 Evidence 的载体，一份 Record 可以参与形成 Evidence，数字签名也可以为某项支撑关系提供密码学依据。但这并不意味着所有日志都是 Evidence，也不意味着只有某种特殊格式的数据才有资格承担 Evidence 的作用。

真正需要关心的，是这份材料究竟在支持哪个与自身可区分的对象，以及这种支持能否被验证。

这也是为什么 Evidence 不能直接等同于 Fact 或 State。Fact 是等待支撑的事实，State 描述当前与某项具体动作有关的现实条件，而 Evidence 所承担的是为这些对象提供可验证支撑。如果因为系统已经保存了 State，就认为 State 已经自动证明自身成立，那么第九章区分当前事实与代理记录的工作，就会在这里被重新抹掉。

Evidence 同样不能被 Authorization、Policy 或 Result 吸收。授权证明某种资格如何形成，策略描述规则及其适用条件，结果则说明某项现实变化或其观察结果。它们都可能涉及需要支撑的声明，但不能因为各自拥有数据和记录，就自动承担 Evidence 的全部语义角色。

尤其需要注意 Result。一个系统返回“执行成功”，并不意味着我们已经知道它究竟完成了哪种程度的执行。请求被接受、执行被尝试、接口返回成功，以及现实中预期结果真正发生，可能分别涉及不同的事实。如果不区分这些对象，系统就容易把某个返回值当作最终现实结果，再把这个返回值自身当作结果已经成立的证明。

因此，Evidence 不是为了取代日志、记录和签名而出现的。相反，只有明确了 Evidence 的角色，这些原本已经存在的工程机制，才可能在需要支持执行判断时被准确使用。

Log、Record 和 Signature 可以承载或参与形成 Evidence，但材料采用什么载体，与它能否为某个具体事实提供可验证支撑，是两个必须分别回答的问题。

四、证据可以支撑决定，却不能因此获得决定现实的权力

当 Evidence 被引入执行控制以后，一个非常自然的工程设想，是让系统在执行之前检查相关证据是否存在。如果证据完整，就允许动作继续；如果证据缺失，就拒绝执行。这样的设计看起来十分合理，因为我们希望每一次现实动作都有充分依据。

但这里仍然隐藏着一个必须保留的区别：Evidence 可以支持 Judgment，却不能直接替代 Judgment。

一份材料即使能够被认定为 Evidence，也不意味着它已经足以支撑当前动作获得执行资格。系统仍然需要根据具体规则、条件和判断关系，确定这些材料对于眼前这一次 Action 究竟意味着什么。

这也是为什么 Evidence 本身不产生 Authority。

一个负责保存证据的系统，可以具有非常重要的记录能力；一个能够签署执行记录的组件，也可以使某些事实具有更强的可验证性。但它们不会因为拥有保存、生成或者签署 Evidence 的能力，就自动获得决定现实动作是否发生的最终裁决权。

这里尤其需要避免把“证明能力”与“执行能力”合并。一个组件可以负责为执行过程形成可信材料，却不因此拥有亲自实施动作的资格；另一个组件可以拥有真实执行能力，也不意味着它能够不受限制地生成关于自身行为的最终证明。

本书在讨论 Proof Authority 时，只使用它来表示生成、签署和保存关于执行过程及结果之可信 Evidence 的能力，并没有据此建立一套新的完整权力分类。至于这种能力应该由谁持有、是否需要进一步分解，以及它与其他 Authority 应当保持什么关系，都不能在第十章中提前得到答案。

我认为这一点与前面几章建立的执行权威边界具有直接联系。我们已经知道，Policy Decision 的存在不等于真实执行受到控制，Authorization 的成立也不等于最终 Authority 已经形成。到了 Evidence 这里，同样不能让“材料已经存在”自动变成“执行已经被允许”。

否则，系统只是把过去依赖审批结果直接放行的方式，替换成了依赖证据存在直接放行，而原本需要独立建立的 Judgment 仍然被跳过。

证据不做决定，它让决定可以被检验；保存、生成或者验证 Evidence 的能力，也不会因此自动获得让 Action 成为现实的 Authority。

五、判断中有没有使用记录，与记录能不能被独立验证，也不是一回事

在实际工程中，我们可能希望进一步判断，某份材料究竟只是普通日志，还是已经承担 Evidence 的作用。这里很容易出现另一种熟悉的做法：为证据设计一张检查表，要求材料具备签名、完整时间戳、独立存储和不可篡改能力，全部满足以后便认定它已经合格。

这些措施可能有重要价值，但第十章并没有建立这样一套充分条件。

本章只是从三个不同方向观察一份材料。

首先，需要检查材料是否具有验证独立性。如果一份记录所表达的事实，只能依靠被验证对象自己的声明才能被接受，那么它在验证结构中就可能缺少必要的距离。系统能够读取记录，并不意味着它已经能够独立验证记录中的事实。

其次，需要观察材料是否真正进入决策路径。某个系统即使保存了大量日志，如果这些日志只在事故以后供人查阅，而执行前的判断从来不读取它们，那么它们至少没有在当前判断中承担输入作用。这并不否定日志的审计价值，而是说明材料用于事后观察，与材料实际参与某次执行判断，具有不同的位置。

再次，需要检查信任域关系。如果某个 Executor 既能够完成现实动作，又能够无痕修改关于这次动作的全部记录，那么这些材料在相关失陷条件下能够提供的支撑，就不能仅凭记录完整而获得保证。

这里还存在一个很值得注意的情况：一份材料可能确实位于决策路径中，却仍然缺乏验证独立性。例如，Executor 可以读取自己生成的记录，并据此判断是否继续执行。删除记录会改变系统行为，因此记录真实参与了判断；但它与被记录行为仍然受同一个主体控制，验证独立性并不会因为材料参与了决策就自然成立。

这说明三个观察方向彼此不能替代。

但更重要的是，我们还不能反过来把它们写成完整的 Evidence 认定规则。当前没有建立三者联合起来必然必要或者已经充分的结论，因此不能因为系统通过了三项检查，就直接宣布 Evidence 的全部语义条件已经得到满足。

在我看来，这种克制非常重要。工程实践中可以设计检查项，却不能让检查项的存在，替代对其理论覆盖范围的说明。

一份记录真正参与了执行判断，并不自动意味着它能够被独立验证；不同的检查方向可以暴露不同问题，却不能未经证明就被合并成完整的 Evidence 判定清单。

六、证明一件事发生过，与证明为什么允许它发生，是两个问题

在传统审计体系中，我们经常把证据理解为事情发生以后用于还原过程的材料。系统保存日志，事故发生后进行调查，最终解释动作由谁发起、经过哪些环节，以及产生了什么结果。这些工作都非常重要，也是许多企业建立审计能力的直接目的。

但执行控制关注的不仅是事后能不能还原现实，还包括现实改变以前，系统究竟依靠什么作出允许或者拒绝的判断。

这实际上形成了两个不同的问题。

一个问题是：这次 Action 是否发生过？

另一个问题则是：这次 Action 为什么被允许发生？

前一个问题可以由执行记录、接口返回值、设备反馈和其他材料提供支撑；后一个问题则要求我们进一步回到动作发生以前，检查当时的 Intent、State、Boundary 以及 Judgment 究竟建立在什么依据之上。

假设某项生产配置已经成功变更，系统能够完整证明修改命令由哪个主体发起、经过什么接口、什么时候得到执行，以及最终返回了什么结果。这样的记录可以为“发生过什么”提供重要材料，但它并不自动证明，当时的对象、参数和状态已经满足必要条件，也不能自动证明最终放行判断具有充分依据。

如果执行发生以前根本没有形成能够支持这些判断的材料，事后即使继续增加日志，也未必能够重新建立当时实际上不存在的证明关系。

这一点让我越来越觉得，Evidence 在执行控制中的地位不能被限制在事后审计。它可以支持执行前的状态判断、边界判断和其他必要结论，也可以用于执行以后验证实际结果。两侧所面对的对象和判断不同，却都可能需要 Evidence。

这里也不能因为 Evidence 能够贯穿执行前后，就认为已经建立了一套固定的证据生命周期模型。第十章并没有规定所有系统必须按照某种统一顺序生成证据，也没有为不同记录形式建立完整类型体系。

真正重要的是，我们不能只让系统回答“做了什么”，却让“为什么当时有资格做”永远停留在无法检验的解释中。

能够证明一项动作发生过，不等于能够证明它为什么被允许发生；真正面向执行控制的 Evidence，必须能够为现实改变以前的必要判断提供可验证支撑。

七、证据已经存在，为什么仍然不能直接说它足够

写到第十章结束时，我觉得 Evidence 的工程位置已经逐渐清楚，但另一个问题也开始显现：我们现在能够说明什么样的对象可以承担 Evidence 的作用，却还不能因此回答，某一份 Evidence 对当前这一次执行判断究竟是否足够。

这其实是两个不同层面的问题。

一份材料可以真实存在，也可以确实为某个与自身不同的事实提供可验证支撑，但它仍然可能来自不适用的来源，可能与错误的执行对象绑定，可能已经超过当前判断允许的时间范围，也可能缺失了某个关键阶段的记录。

这些情况不需要被统一解释为“它根本不是 Evidence”。因为我们仍然需要一种准确的工程表达：Evidence 已经存在，但对于眼前这一次 Judgment，它还不够。

正因为如此，第十章没有将来源资格、对象绑定、时效、内容完整性、顺序完整性、集合完整性和存续性，直接写进 Evidence 的最小定义。这些条件当然重要，却属于另一层需要独立建立的判断。

如果把这些条件全部提前塞进 Evidence 本体，那么任何材料一旦未满足某项充分性要求，就会在定义层被排除为“不是证据”。这样看起来让定义更加严格，实际上却让系统失去了区分证据是否存在、证据是否可信以及证据是否足够支持当前判断的能力。

我认为这种区分，是执行控制逐步走向工程化过程中必须保留的严谨性。因为我们不能把所有尚未完成的判断都放进一个越来越庞大的概念，然后认为只要这个概念存在，其他问题就自动解决了。

Evidence 的价值，不在于它能够替代所有事实判断，而在于它使那些过去经常被默认接受的事实和关系，开始拥有可以被独立检查的支撑对象。

但这样的支撑究竟需要达到什么程度，是否必须具有特定来源、满足特定时效，以及不同材料之间应当保持怎样的完整性与连续性，已经进入另一个尚未建立完整答案的问题空间。

这也是为什么我不愿意把“证据链完整”简单写成“可以执行”。一条记录链看起来完整，并不意味着其中所有材料都已经满足当前判断所要求的条件，更不意味着系统已经作出了正确的 ALLOW。

Evidence 是否存在，回答的是材料在判断中承担什么角色；Evidence 是否充分，回答的是这些材料能否支持当前这一次具体 Judgment。前者成立，不会让后者自动成立。

到这里，《执行控制工程》已经从 Intent 与 State 走到了 Evidence。规范侧参照说明原来希望发生什么，现实侧状态说明当前条件是什么，而 Evidence 则开始回答，我们凭什么认为这些对象与关系确实成立。

这三个对象彼此相关，却不能相互代替。只有把它们各自的职责保持清楚，后续执行判断才不会因为某个系统拥有记录、规则或者历史批准，就自然跳过原本必须建立的依据关系。

因此，第十章没有试图发明一种比日志更加高级的文件格式，也没有宣称所有审计数据都应该被新的证据系统取代。它真正希望建立的，是一个更加基础的认识：记录可以成为证据的载体，证据能够为判断提供支撑，而判断仍然需要独立面对具体 Action 的执行条件。

接下来真正需要回答的，已经不是系统有没有日志，也不只是系统有没有 Evidence，而是一个更加严格的工程问题：

对于这一次具体执行判断，已经拥有的 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 https://www.amazon.com/dp/B0HL6CD6LY

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

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