Havenlon 执行控制工程 II 03｜为什么裁决需要一份可验证的执行记忆？

传统系统对日志和证据的理解几乎都发生在动作结束之后。一次操作完成系统记下谁执行了、执行了什么、什么时候发生、结果如何。链条很自然请求、裁决、执行、日志。日志在最后职责是帮我们事后回答刚才发生了什么。第一季结尾讨论证据时已经把这个问题往前推了一步高风险执行需要的不只是系统自述式的日志而是能够重新验证关键执行关系的事实。而一旦进入工程实现一个更靠前的问题会浮现出来——证据为什么必须停留在执行之后系统已经执行过一次并留下了可验证的证据那么下一份意图到来时它凭什么要假装过去从未发生现实中的很多执行条件本来就是历史相关的这笔钱今天已经付了多少同一份意图是否已经执行过最近是否连续出现异常拒绝前一个动作有没有真正完成某个计数推进到了哪里是否存在尚未闭合的冲突操作。这些问题没有一个能从当前请求本身得到答案它们全都来自过去发生过什么。所以证据的位置需要变化它不该只是执行的输出还应该成为下一次裁决的输入。链条由此闭合——意图、裁决、执行、证据再回到下一次裁决。证据不再只解释过去它开始约束未来。一、只看当前请求策略就没有记忆设想一条朴素的支付规则单笔金额不得超过某个上限。第一笔请求低于上限放行执行成功一分钟后又来一笔同样金额的请求如果策略每次只看当前意图结论仍然是放行——每一笔确实都在限额之内。规则没有错。但如果真正的业务边界是每日累计不得超过某个上限只看当前请求就无法完成判断。策略必须知道今天此前已经执行了多少需要判断的是已执行历史加上这次拟执行的动作是否仍在允许范围内。这里发生了一个不小的变化裁决不再是无状态的。它开始依赖一份经过验证的执行历史而这份历史最合理的来源之一就是证据。同类规则在工程里随处可见——单笔上限叠加周期总额某台设备一小时内最多执行多少次高风险动作某个凭据在一个周期内只能触发有限数量的操作。它们的共同特征是当前执行能否放行取决于此前已经执行过什么。策略的输入因此从当前意图变成当前意图加上已验证的历史状态。二、当前状态告诉你是什么证据还能说明怎么变成这样有人会问为什么一定要证据直接从数据库读一个累计值不就够了吗在多数业务系统里确实够。但高风险执行面对的要求更严一层。数据库里的当前值只能说明系统现在认为累计是这个数而证据希望进一步回答这个数是由哪些已经发生、并且能够被验证的执行一步步形成的。前者是当前状态后者是状态的来路。差别在有人动手时才显现。如果某个计数值被具备权限的人直接改小而执行控制完全信任这个字段系统就无从知道历史发生过倒退。当当前状态与前序证据之间存在连续关系时策略才有机会判断这个状态不只是看起来是这个值它还有一段能够支撑它为什么是这个值的历史。数据库恢复是同一问题最现实的形态。系统故障后业务库从半小时前的备份恢复那半小时内已经执行过的动作可能从当前状态里消失——付款已经发生而恢复后的数据认为尚未付款于是系统可能再次执行。如果证据拥有独立的连续性恢复之后就可以比对业务状态与证据状态一旦发现历史不一致正确的做法不是继续执行而是先重新建立状态。所以证据作为输入的价值不在于多了几个数据而在于它向裁决提供的是带来路的事实。三、有效性和可再次执行性重放保护是最容易理解这一点的场景。一份合法意图已经被完整执行主体、审批、裁决、签名全都成立。现在完全相同的对象再次进入系统——单独看它仍然合法签名依然有效审批可能还在有效期内。策略如果只检查当前对象很可能再次放行。而真正需要判断的是这份意图是否已经消费掉了它的执行资格。这个问题无法从意图自身得到答案只能查看历史——此前是否已经存在对应的执行证据计数是否已经推进是否已有同一份意图的成功结果。于是证据不再是事后的审计材料它直接成为防重放的事实来源。这也引出一个工程上有意思的变化。传统验证多围绕有效与无效展开签名是否有效审批是否有效规则是否通过。但一份意图即使在密码学上完全有效也可能已经被消费。有效且未执行与有效且已执行在密码学状态上毫无差别执行资格却截然不同。有效性和可再次执行性不是同一个问题。证据帮助系统建立的正是后一个维度它让裁决不只是判断这份东西是不是真的还能判断这份真的东西现在是否还拥有一次新的执行资格。四、谁来提供历史事实如果每次裁决都把完整的历史链加载进运行时性能与复杂度都不可接受运行时也会重新变胖。更清晰的分层是让证据层承担历史让运行时只消费结论。证据层负责存储执行证据、验证来源、检查连续性、维护派生状态、产出有限的历史事实运行时接收当前事实与历史事实做纯粹的裁决。前者回答过去发生过什么后者回答基于这些已确认的事实现在是否允许继续。这与这一季前两篇一致运行时应当消费已经明确建立的事实而不是自己跑出去寻找历史。送进运行时的历史事实通常是被投影过的少数结论——是否存在前序执行某个窗口内的累计量是多少上一次结果如何证据连续性是否完好。工程上当然可以用快照、计数、聚合和检查点来支撑性能关键在于这些派生状态最终应当能够回到可验证的证据而不是凭空成为新的事实权威。这里有一个容易被忽略的风险为了性能生成的派生值一旦无人知道它如何产生就重新退化成一个普通数据库字段。成熟的设计至少要能建立派生事实到证据依据的对应关系——不必每次实时展开但需要能够重新验证这个累计状态由哪些历史事实构成。证据驱动的裁决与普通有状态裁决的区别就在这里不是系统记得过去而是系统拥有能够解释自己为什么这样记得的依据。策略语言也要跟上。它的数据模型需要承认历史事实同样是事实能够表达此前没有成功执行累计量加上本次仍在限额内前一步结果为成功证据连续性完好这类条件并且最好能区分当前事实、历史事实与派生事实让评审者知道某条规则为什么依赖这个值这个值又来自什么证据。还有时效。证据是历史但并非所有历史都对当下有意义。昨天累计支付了多少这个事实本身永远为真对今天的额度却不再适用。所以历史事实同样需要窗口、新鲜度和有效范围——证据的真实性和证据与当前决策的相关性是两个不同的问题。五、历史不只是额度前序结果是另一类历史事实。设想一个自动化流程先执行数据迁移再发布应用服务。第二步能否继续显然取决于第一步的真实结果。而第二次裁决不能只知道迁移命令曾被调用过它需要知道那一步最终是成功、失败、部分完成还是状态未知。这些结论会直接改变下一步的执行资格链条也因此从单纯的命令序列变成带有结果事实的步骤链。行为模式同样可以成为事实。假设某个自动化主体连续多次尝试同一项高风险动作每次都被拒绝。如果每次裁决都无视历史第四次仍然只是一个全新的独立请求。但从安全角度看连续拒绝本身已经是值得注意的模式——它可能意味着配置错误、目标被持续误解、恢复逻辑陷入循环也可能是有人在探索规则边界。这不意味着连续几次拒绝就该永久封锁。重要的是让可验证的历史拥有进入裁决的通道系统可以据此提高后续的风险等级、要求重新建立意图、要求新的授权或让某类自动执行进入受限状态。传统监控体系当然也能发现这些异常但如果这些信息只停留在告警侧安全结构就仍是执行系统照常执行监控系统在旁边看着。证据进入裁决之后已经发生的异常才可能改变未来的执行资格。这类规则需要格外谨慎设计否则一次误报就会演变成大范围拒绝服务——关键从来不是发现异常就封锁。冲突也是如此。第一季说过多个可信来源互相矛盾时应当优先停止。进入工程之后会发现冲突未必只发生在两个当前系统之间它也可能出现在当前状态与历史证据之间业务库说这笔付款从未执行而证据里已有成功记录当前计数落后于此前证据所记录的位置系统认为设备已恢复而前一份证据显示关键恢复步骤尚未完成。这类冲突若只用于事后审计只能在事故之后被人看见一旦证据能进入裁决冲突本身就可以直接成为阻止执行的理由。顺带一提值得记录的不该只有成功。一份因目标冲突而被拒绝的意图如果原样再次出现系统至少应该知道这不是第一次见到它一台因健康状态无法建立而反复拒绝的设备也在提示不该继续让自动化盲目重试。拒绝并不是什么都没发生。安全边界作出一次拒绝本身就是一次值得留痕的状态变化。六、方向性历史只能向前既然证据成为裁决的输入就有一条基本边界运行时不应该修改证据历史。否则会出现一个危险的循环——裁决者不满意当前历史于是改写历史重新判断得到放行。这等于让裁决者自行改变裁决依据。方向必须保持单向证据产生事实事实进入裁决新的证据只能由真正发生的新步骤、新执行和新结果产生。那么上一篇刚把裁决与执行拆开现在执行侧产生证据、证据又流回裁决会不会重新耦合不会只要中间保留一层验证与投影运行时不直接相信执行侧我成功了这句话它消费的是经过必要验证之后形成的历史事实。执行侧负责现实动作证据层负责历史事实运行时负责裁决三者职责依然分明。这条单向性其实是在给系统装一根时间箭头。普通状态只说明现在是什么证据链还能说明我们是怎么走到现在的计数向前证据向前执行历史向前已经发生的事情不会因为某个字段被改动就自动变成没有发生。这与现实本身的性质是一致的——钱转出去之后数据库恢复不会让钱回来门被打开过状态回滚也无法让曾经打开从历史中消失。证据是软件层试图保留这种记忆的方式。七、克制不要让裁决层变成风控系统一旦发现历史有用很容易把越来越多的行为特征塞进裁决过去一小时发生了什么过去一天如何最近一个月的趋势连续失败多少次设备历史、账户历史、自主系统历史……最终裁决层膨胀成一个庞大的行为风控系统。这未必是执行控制运行时该承担的职责。更合理的界限是只有真正影响执行不变量的历史事实才进入核心裁决。复杂的风险分析可以在上层完成模型可以产出评分外部系统可以做统计运行时接收的是有限的结论——风险状态、累计限额状态、重放状态、证据连续性状态。这与本季第一篇一致不要因为证据变丰富就让裁决层重新无限膨胀。也要区分另一件事。让证据进入裁决并不是让策略变成一个自我学习、不断改写自身规则的系统。规则应当保持稳定变化的是输入事实。同一条规则——一份意图只能成功执行一次——第一次面对此前没有成功记录于是放行第二次面对此前已有成功记录于是拒绝。规则没有变世界推进了。不是让规则追着历史变化而是让历史成为规则必须面对的现实。八、从流水线到控制回路第一季结尾把证据放在链条末端身份、权限、意图、策略、裁决、执行、证据。那是第一次闭合。而继续往工程里走会发现证据并不是终点它还应该回到下一次执行的起点意图 → 事实 → 运行时 → 裁决 → 执行器 → 结果 → 证据 → 已验证的历史事实 → 下一次裁决到这一步执行控制才真正从一条流水线变成一个控制回路。昨天的证明变成今天的约束上一次的结果变成下一次的前提事后的执行证据同时成为事前的控制输入。自主系统尤其需要这层记忆。Agent 天然在观察、规划、行动、再观察的循环里工作上一轮的结果通常会进入下一轮上下文。但高风险动作不能只依赖模型上下文记住我刚才已经做过这件事——上下文会截断提示会变化进程会重启模型也可能误解历史。已经执行过这件事不应该只是一段自然语言记忆而应当是独立可验证的执行事实并在下一次裁决时明确进入边界。这样即使自主系统自己忘了执行侧仍然知道。需要说明的是这套结构不会让偏差消失。它降低的是同一件事被当作第一次发生的概率增加的是历史被悄悄改写时暴露的机会并在状态无法自洽时保留拒绝的余地。归根结底执行不是一次孤立的函数调用。真正的执行会改变资金、设备、资源、额度、计数、风险状态甚至后续权限。每一次执行之后下一次执行面对的世界已经不同。如果裁决每次仍然只检查当前请求它其实是在一个虚构的无状态世界里工作而现实是有状态的。真正成熟的证据系统不只是解释过去还应该约束未来。因为执行控制要判断的从来不只是这一次请求看上去是否正确还包括在我们已经做过那些事情之后这一次是否还拥有改变现实的资格。