在上一篇 Governance Decision Intelligence 中，讨论的重点是：AI Agent 在不同风险条件下应该获得什么权限、受到什么约束，以及何时需要人工介入。但当治理系统真正进入生产环境，一个更复杂的问题会出现：如果风险评估结果持续波动，权限系统是否会跟着反复切换？如果多个 Agent 对同一任务给出不同判断，最终采用哪个权限状态？如果 HOLD 已经生效，之前签发的 ALLOW 指令是否仍然可能在队列中继续执行？
这些问题不是单纯的风险评分问题，而是控制系统的稳定性问题。真正需要解决的不是让权限永远不变，而是建立一套能够在风险变化时安全调整、在多节点之间形成一致状态、并且能够拒绝过期授权的治理控制机制。
一、治理决策正确，不代表执行系统稳定
假设一个企业使用多个 AI Agent 协作处理工业设备产品资料：Research Agent 收集产品规格与技术文件；Fact Check Agent 核对参数和来源；Content Agent 生成技术内容；SEO Agent 调整页面结构与内部链接；Publisher Agent 将已批准内容写入 WordPress；Monitoring Agent 监测发布结果和异常。
某个产品参数最初被多个来源确认，系统允许内容进入发布阶段。随后，监测系统发现制造商技术文件与内部产品数据库存在差异，风险评分从 42 上升到 56。如果权限控制直接采用一个固定阈值，例如风险评分超过 50 就从 ALLOW 切换为 HOLD，那么风险评分在 48、52、49、53 之间反复波动时，系统可能不断执行：
ALLOW → HOLD → ALLOW → HOLD → ALLOW这会带来任务频繁暂停和恢复、Agent 不断重新申请权限、排队操作与新权限状态冲突、控制器重复执行状态转换，以及外部系统接收到延迟指令等问题。
如果系统为了减少这种抖动而延迟权限收紧，又可能让已经失效的授权继续产生外部副作用。自适应治理控制要解决的，正是这种安全性与稳定性之间的工程问题。
二、从决策选择进入控制回路
自适应治理控制不是在原有风险评分模型上再增加一个阈值，而是把治理过程设计成持续运行的闭环：
Runtime Evidence
↓
Risk State
↓
Governance Decision
↓
Capability Target
↓
Admission / Effect Gate
↓
Protected Effect
↓
Observed Outcome
↓
Feedback Controller
↓
Stability / Convergence Verification
↺Runtime Evidence 提供身份状态、数据来源、工具调用结果、策略版本、异常行为和任务执行记录。Risk State 将证据转换为风险状态，同时保留置信度、证据新鲜度和不确定性。Governance Decision 根据策略确定 ALLOW、LIMIT、HOLD、ESCALATE 或 CONTAINMENT 等治理状态。
Capability Target 将治理决策转换为明确的权限集合。Admission / Effect Gate 在任务真正产生外部副作用之前，重新检查当前权限、策略版本和授权有效期。Observed Outcome 记录实际执行结果，包括成功、拒绝、超时、部分完成、补偿和异常。Feedback Controller 根据新的证据和执行结果调整治理状态，并验证状态是否达到预期。
Kubernetes 对 Controller Pattern 的解释提供了一个工程参照：控制器持续比较期望状态与实际状态，并通过协调动作让实际状态逐渐接近期望状态。它不要求整个集群永远进入静态状态，而是持续进行状态协调。治理系统的目标也不应该是“永远没有状态变化”，而应该是在给定风险条件、策略版本和系统可用性假设下，治理对象能够收敛到唯一、明确、可验证的有效状态。
三、必须分离四种状态，不能把风险评分直接当作权限
| 状态维度 | 主要含义 | 示例 |
|---|---|---|
| Risk State | 当前风险评估 | LOW、MEDIUM、HIGH、UNKNOWN |
| Governance Decision | 策略给出的治理决定 | ALLOW、LIMIT、HOLD、ESCALATE、CONTAINMENT |
| Capability State | 当前实际授权能力 | READ、DRAFT、APPROVE、PUBLISH、DELETE |
| Effect State | 外部副作用的执行状态 | QUEUED、DISPATCHED、COMMITTED、CONFIRMED、COMPENSATED |
这四种状态不能相互替代。Risk State = HIGH，不一定意味着所有任务都必须完全停止；读取日志、保存证据、通知负责人等低风险操作可能仍然需要保留。Governance Decision = HOLD，也不代表之前已经提交的外部操作能够自动撤销。Capability State = READ_ONLY，不意味着正在执行的写操作已经完成回滚。Effect State = COMMITTED，更不代表系统可以因为权限后来变化而假装这次操作从未发生。
治理系统应明确记录 risk_state、risk_confidence、risk_evidence_version、risk_observed_at、governance_decision、decision_reason、decision_id、governance_epoch、capability_state、capability_set_hash、policy_version、effect_id、effect_state 和 idempotency_key。
风险评估回答“现在有多危险”，治理决策回答“系统应该采取什么措施”，能力状态回答“实际允许做什么”，效果状态回答“外部操作究竟发生到了哪一步”。
四、风险评分是控制信号，不是权限本身
风险评分通常是多个变量的综合结果，例如身份风险、数据完整性风险、工具风险、策略违规风险、执行异常风险和外部影响风险。实际模型可能采用加权计算、规则组合、概率模型或其他方法，但无论采用什么方法，风险评分都只是一个控制输入。
同一个评分可能来自完全不同的风险构成。一个任务风险评分为 65，原因可能是来源证据不完整；另一个任务评分同样为 65，原因可能是身份冒用；第三个任务评分为 65，原因可能是外部写入操作无法确认是否重复执行。三个任务的分数相同，但治理动作不应该完全一致。
来源不完整可能需要限制发布权限并等待补充证据；身份冒用可能需要立即撤销相关授权；外部写入状态不确定则可能需要暂停重试、检查幂等记录和外部系统状态。
因此，治理控制器必须同时读取风险等级、风险构成、证据置信度、证据更新时间、任务影响范围、当前执行阶段、是否存在不可逆副作用，以及是否触发硬性安全规则。风险分数可以参与决策，但不能取代策略判断。
五、Hysteresis：通过滞回机制避免权限反复切换
在工业控制和电子测量系统中，滞回机制常用于减少信号在阈值附近波动时产生的频繁切换。其基本思想是：进入某种状态和退出某种状态，不一定使用同一个阈值。
例如，系统在风险评分达到 50 时进入限制状态，也在风险评分低于 50 时立即恢复权限，那么当评分持续在 49 和 51 之间变化时，系统就可能不断切换。滞回机制通过设置不同的进入阈值与退出阈值，减少这种现象。
| 当前状态 | 转换目标 | 示例条件 |
|---|---|---|
| ALLOW | LIMIT | 风险评分持续达到或超过 55 |
| LIMIT | HOLD | 风险评分持续达到或超过 75 |
| HOLD | LIMIT | 风险评分降至 45 以下，且证据持续稳定 |
| LIMIT | ALLOW | 风险评分降至 30 以下，并通过恢复审核 |
| 任意状态 | CONTAINMENT | 触发硬性安全规则或严重安全事件 |
这里的 55、75、45 和 30 只是解释机制的示例，不是通用风险标准，也不代表任何搜索引擎或 AI 平台使用这些阈值。实际阈值必须通过任务风险、历史数据、错误成本和运行测试确定。
滞回机制的价值在于让系统对风险上升和风险下降采用不同的响应条件。但滞回不能成为延迟安全处置的理由。对于身份泄露、凭据被盗、明确越权、恶意工具调用和其他硬性停止信号，应立即收紧权限，而不是等待滞回窗口结束。
工业保护继电器的技术资料也体现了类似思想：在阈值附近存在测量噪声时，使用不同的动作与复归阈值可以减少重复状态切换。这里引用的是控制工程中的机制类比，而不是将继电器参数直接移植到 AI 治理系统。
参考：Schneider Electric Easergy P3F30 Protection Relay Manual
六、滞回之外，还需要持续时间、冷却窗口和证据新鲜度
只设置两个阈值仍然不够。如果一次短暂异常就能触发状态转换，系统仍然可能频繁进入限制状态。控制器还需要考虑持续时间、冷却窗口和证据新鲜度。
持续时间：对于非紧急风险，可以要求风险信号在一定时间窗口内持续满足条件，而不是根据单次瞬时评分做决定。例如风险评分达到阈值并持续 30 秒，且至少出现 3 次独立有效观测，才进入 LIMIT。时间和观测次数必须根据系统特征设定。
冷却窗口：权限升级之后，可以要求系统经过一段稳定运行时间，才允许再次升级，避免在证据尚未稳定时连续扩大能力范围。
证据新鲜度：风险评分下降不代表风险真正消失。如果评分下降是因为关键监测数据停止更新，系统不应该将 UNKNOWN 解释为 LOW。例如 Evidence Freshness = STALE、Risk Score = 20，不应该自动获得 ALLOW。
恢复权限必须同时满足风险指标达到恢复条件、关键证据仍然有效、不存在未处理的严重异常、策略版本保持一致，以及必要的人工审批已经完成。风险降低与证据缺失是两种不同情况，治理系统必须能够识别它们。
七、能力集合应采用交集约束，而不是简单的权限等级
如果治理决策只输出 ALLOW 或 DENY，系统很难表达复杂任务中的差异化权限。更合理的做法是定义 Capability Set，例如 READ、SEARCH、ANALYZE、DRAFT、EDIT、APPROVE、PUBLISH、DELETE 和 CONFIGURE。
C_effective =
C_role
∩ C_policy
∩ C_risk
∩ C_scope
∩ C_freshness
∩ C_emergency有效权限必须同时满足角色、策略、风险、资源范围、证据新鲜度和紧急控制要求。例如 Content Agent 可以读取资料、创建草稿和编辑内容，但当前策略禁止它直接发布；当风险进入限制状态时，APPROVE、PUBLISH 和 DELETE 仍然被拒绝。
硬性拒绝规则必须具有更高优先级：HARD_DENY overrides ALLOW。ESCALATE 表示将任务交给更高层级的治理流程，而不是一种权限。CONTAINMENT 表示系统进入受控安全模式，也不只是风险评分更高的一个区间。
八、多 Agent 决策冲突不能依赖简单多数投票
多 Agent 协作系统中，不同 Agent 可能对同一任务形成不同判断。例如 Research Agent 提议 ALLOW，Fact Check Agent 提议 HOLD，Security Agent 提议 LIMIT，Publisher Agent 提议 ALLOW。如果简单采用多数投票，系统可能忽略关键风险。
不同 Agent 的职责、证据来源和风险识别能力并不相同。Research Agent 可能只确认来源存在；Fact Check Agent 可能发现关键参数冲突；Security Agent 可能识别到工具权限范围过大。它们并不是在同一个维度上对同一个问题进行独立投票。
更合理的模式是“分布式证据提议 + 权威控制器提交”。每个 Agent 可以提交新证据、风险信号、权限约束、任务状态和异常报告，但不能因为自己提交了一个 ALLOW，就直接改变生产环境的有效权限。
Research / Fact Check / Security / Publisher / Monitoring
↓
Evidence & Constraint Proposals
↓
Governance Controller
↓
Conflict Resolution
↓
Canonical Decision
↓
Capability Controller冲突处理应遵循：硬性拒绝优先于普通允许；高影响风险证据优先触发限制；证据冲突时不自动扩大权限；过期证据不能覆盖新版本；权限范围取交集而不是并集；只有权威控制器能够提交新的治理 epoch。
九、Governance State Convergence：多个 Agent 必须收敛到同一个有效状态
多 Agent 系统可能同时运行在不同进程、不同区域或不同执行环境中。如果每个 Agent 都维护自己的权限副本，就会出现状态分歧。例如 Agent A 和 Agent C 仍然认为治理 epoch 为 21、权限为 ALLOW，而 Agent B 已经更新到 epoch 22、权限为 HOLD。
因此，需要为每个治理对象定义唯一的有效状态标识：resource_scope、governance_epoch、policy_version、decision_id、capability_set_hash、revocation_floor 和 updated_at。
控制器提交状态后，各 Agent 必须同步并确认。尚未确认最新状态的 Agent，不能继续执行依赖新权限的高风险操作。控制平面最终一致，不等于每个执行节点都可以在同步完成之前继续使用旧权限。
对于普通读取和低风险分析，可以允许有限度的延迟；对于发布、删除、配置修改、外部写入等高影响操作，则必须在执行边界重新检查最新有效状态。
Kubernetes Controller 的持续协调、Kubernetes resourceVersion 的乐观并发控制，以及 etcd 的原子事务，都是实现状态收敛与并发更新控制的工程参照。
参考：Kubernetes API Concepts；etcd API Transactions
十、Policy Version Synchronization：策略更新必须具有版本边界
权限状态一致还不够。如果多个 Agent 使用不同版本的治理策略，即使它们看到相同风险证据，也可能得到不同结果。例如 Agent A 使用 v12，风险低于 60 时允许；Agent B 使用 v13，风险低于 45 时才允许。风险评分为 52 时，两者就会产生冲突。
治理策略应具备不可变版本和明确的生效边界，至少记录 policy_id、policy_version、policy_hash、effective_at、minimum_accepted_version 和 governance_epoch。
Policy Draft
↓
Validation
↓
Approval
↓
New Policy Version
↓
Active Policy Pointer Update
↓
Agent Acknowledgement
↓
Old Version Rejection策略更新时不应直接覆盖旧策略文件，而应生成新版本。对于高风险任务，系统应要求执行节点确认当前策略版本。无法确认当前策略的任务，应进入限制或暂停状态，而不是自行选择一个版本。
策略版本不是普通配置文件的版本号，而是治理决策有效性的组成部分。
十一、Fencing Token：让旧 ALLOW 指令无法越过新的撤销边界
假设一个 Agent 在治理 epoch 21 时获得 ALLOW 权限，并向发布队列提交了一个命令。随后，Fact Check Agent 发现严重参数冲突，治理控制器将状态更新为 epoch 22、decision = HOLD。如果旧发布命令仍然可以在队列中执行，那么 HOLD 就只是一个状态标记，并没有真正保护外部系统。
因此，必须在实际副作用发生之前重新验证授权版本。可以使用单调递增的 fencing token：
Epoch 21 → ALLOW
Epoch 22 → HOLD
Epoch 23 → LIMIT
Epoch 24 → ALLOW执行边界维护当前最低允许版本。例如 current_revocation_floor = 22。当旧命令抵达时，command_epoch = 21，小于 22，因此必须拒绝。
一个有效命令至少应携带 subject_id、resource_scope、action、resource_id、decision_id、policy_version、governance_epoch、fencing_token、issued_at、expires_at、payload_hash 和 idempotency_key。
TTL 可以帮助限制授权有效期，但不能替代 fencing token。一个请求可能在有效期内进入队列，随后执行进程暂停；等进程恢复时，旧授权已经被撤销，但它仍可能继续使用之前保存的请求。只有外部执行资源也能够检查 fencing token，旧命令才会真正被拒绝。
Google Chubby 锁服务的经典研究指出，锁的代次信息可以作为 sequencer 传递给资源端，由资源端拒绝过期操作。分布式锁或租约本身并不足够，真正执行写入的资源还必须识别操作是否来自过期持有者。
参考：The Chubby Lock Service for Loosely-Coupled Distributed Systems
十二、撤销必须发生在副作用提交边界，而不只是消息通知阶段
常见的撤销流程是更新治理状态、发布撤销事件、通知所有 Agent。但消息传播需要时间，在传播完成之前，某个执行节点可能仍然保留旧权限。因此，不能把“已经发送撤销消息”当成“旧授权已经失效”。
HOLD Transition
↓
Atomic Epoch Increment
↓
Revocation Floor Update
↓
New Admission Blocked
↓
Async Agent Notification
↓
In-flight Reconciliation新的治理状态必须先在权威控制面完成原子提交，再通过异步机制通知其他节点。执行节点在提交外部副作用之前，需要验证当前治理状态、epoch、fencing token、资源范围、策略版本和幂等记录。
如果 HOLD 在命令提交之前完成，旧命令必须被拒绝。如果外部操作已经在 HOLD 的线性化提交点之前完成，则不能假装它没有发生。系统应将其标记为已提交，并根据风险决定取消后续步骤、执行补偿或通知人工处理。
网络分区下，系统无法保证所有执行节点在同一瞬间获知撤销状态。因此，高风险操作应在无法确认当前权限时失败关闭，并为撤销传播设置可测量的服务目标。
十三、Idempotency：重复请求不能产生重复副作用
治理状态变化经常伴随消息重试。例如 Publisher Agent 提交 WordPress 发布请求后，外部系统已经成功创建文章，但响应在网络中丢失。Agent 看到超时，可能认为操作失败并再次提交。如果发布系统没有幂等机制，就可能产生重复文章。
每个逻辑操作都应该拥有稳定的 idempotency key，用来识别同一个逻辑任务、资源、动作和内容版本。幂等键应识别同一个逻辑操作，而不是简单把每次治理 epoch 都拼进去，否则同一任务在权限版本变化后可能被误认为新动作。
- 相同幂等键、相同请求内容：返回之前记录的结果；
- 相同幂等键、不同请求内容：拒绝并要求重新核验；
- 未找到执行记录：进入正常执行流程；
- 请求结果不确定：先查询外部系统，不盲目重试。
幂等记录应与本地状态变更尽可能原子地保存。对于跨系统操作，可以使用 outbox / inbox 机制和事后 reconciliation，减少消息丢失与重复执行造成的不一致。
幂等不等于整个分布式系统天然具备 exactly-once 执行能力。网络超时、外部系统不可用和执行状态不确定时，系统需要通过稳定的逻辑操作标识、幂等记录和状态对账来控制重复副作用，而不是轻易宣称绝对只执行一次。
参考：AWS Builders’ Library — Making retries safe with idempotent APIs
十四、Rate-limited Authority Changes：权限升级需要限速，权限收紧不能被限速
如果风险评分短时间内下降，系统连续多次扩大权限，就可能在证据尚未稳定时获得过高自治能力。权限升级可以采用单次只增加有限能力、最短稳定观察窗口、token bucket、canary promotion 和高影响权限人工批准等机制。
但权限收紧必须区别对待：
Authority Promotion: Rate Limited
Authority Downgrade: Immediate when required权限升级可以限速，紧急撤销不能因为令牌桶耗尽或冷却时间未结束而被延迟。对于高影响操作，建议采用渐进式恢复：CONTAINMENT → HOLD → LIMIT → READ → DRAFT → APPROVE → PUBLISH。每一步都需要满足对应的证据和审批条件。
十五、Safe Mode Transitions：安全模式必须定义进入和退出条件
治理状态机不能只设计正常状态，还必须设计异常状态和恢复路径。
ALLOW
↓
LIMIT
↓
HOLD
↓
CONTAINMENTALLOW 允许当前任务范围内的批准操作；LIMIT 保留低风险能力并禁止高影响操作；HOLD 暂停新的受保护操作，等待证据补充或人工决策；CONTAINMENT 进入隔离状态，撤销相关执行能力，阻止新的外部副作用，并保留必要的监控与证据采集。
进入 CONTAINMENT 后，系统通常仍需要保留只读监控、审计日志、事件记录、证据快照、人工恢复入口和安全告警。
恢复路径也不能直接从 CONTAINMENT 跳回 ALLOW。更稳妥的路径是 CONTAINMENT → HOLD → LIMIT → ALLOW。每次转换都要检查原始风险是否已经解决、是否仍有未完成的外部操作、旧授权是否已经失效、策略版本是否一致、关键证据是否重新核验，以及是否需要人工批准。
安全模式的退出条件必须与进入条件一样明确。
十六、反馈控制本身也可能制造新的风险
治理系统不仅要防止 Agent 的错误行为，还要防止控制器自己的反馈回路出现不稳定。例如，系统发现任务执行失败，立即提高风险评分并收紧权限；权限收紧后，大量任务进入重试队列；队列积压又触发超时；超时被监控系统识别为新的异常，进一步提高风险评分。
Execution Failure
↓
Risk Increase
↓
Permission Restriction
↓
Queue Backlog
↓
Timeout Increase
↓
More Risk Signals
↺Google SRE 对级联故障的分析指出，正反馈、重试风暴和过载可能相互强化，导致局部故障扩大为系统性故障。治理控制器需要区分真实风险信号与系统自身造成的异常，对重试采用退避和 jitter，限制队列长度和并发度，避免在故障期间连续扩大重试规模，并监控降级策略本身的副作用。
如果风险模型将系统自身的过载错误地解释为外部威胁，控制系统就可能在试图保护系统时进一步破坏系统。
参考：Google SRE Book — Addressing Cascading Failures
十七、如何避免控制器之间的锁竞争与治理死锁
多个 Agent 和控制器同时修改同一资源时，可能出现锁竞争。例如 Governance Controller 正在修改权限，Publisher Controller 正在等待发布结果，Monitoring Controller 正在尝试暂停任务，Recovery Controller 等待发布锁释放。如果这些控制器都持有长时间分布式锁，并在锁内调用外部 API，就可能形成死锁或长时间阻塞。
- 锁只保护短时间状态提交：不要在持有分布式锁时调用 WordPress、CRM、ERP 或其他外部 API。
- 状态转换采用原子操作：优先使用 compare-and-swap、resourceVersion 或事务条件更新，避免多个控制器无条件覆盖同一状态。
- 外部操作采用异步任务：控制器先提交治理状态，再通过 outbox 或任务队列触发外部操作。
- 所有租约和等待都必须有边界：租约超时、任务超时和重试次数都应有明确上限。
- 紧急隔离不能等待所有 Agent 一致同意：高风险事件需要有权威的紧急收紧路径。
- 保留 break-glass 恢复机制：具备授权的人工负责人应能够安全地暂停、隔离或恢复控制流程。
十八、用形式化不变量定义治理系统的安全边界
| 不变量 | 约束含义 |
|---|---|
| Effect Safety | 外部副作用提交时，当前权限必须明确允许该动作 |
| Revocation Safety | 命令 epoch 低于 revocation floor 时不得提交 |
| Hard-stop Safety | 硬性停止状态提交后，不得再接收新的受保护操作 |
| Monotonic Restriction | 风险恶化不能导致有效权限增加 |
| Canonical Epoch | 同一资源范围只有一个权威治理 epoch |
| Policy Consistency | 高风险操作必须使用当前允许的策略版本 |
| Idempotency | 同一逻辑操作不能因为重试产生额外副作用 |
| Liveness | 在风险持续降低、证据有效且控制平面可用时，系统最终能够恢复 |
| Deadlock Avoidance | 外部副作用执行期间不持有治理控制面的长时间锁 |
最重要的安全约束可以表达为：只有当前治理状态允许动作、命令 epoch 不低于撤销下限、策略版本仍被接受、能力范围匹配且幂等检查通过，外部副作用才允许提交。
恢复活性则需要明确前提：风险持续低于恢复阈值、证据保持新鲜、策略允许升级、控制平面可用且必要审批完成，系统才应最终收敛到允许的能力状态。
写出不变量并不自动意味着系统已经被形式化证明。只有当状态模型、并发假设、外部资源行为和执行边界都被纳入验证时，才能讨论相应范围内的形式化保证。
十九、实际实施：从单一资源范围开始建立治理控制器
不建议一开始就对整个企业的所有 Agent 实施统一的复杂治理控制。更可控的做法是从一个资源范围明确、外部副作用有限的任务开始。
- 建立状态模型：明确 Risk State、Governance Decision、Capability State 和 Effect State 的字段定义，确定哪些状态由谁负责维护。
- 建立唯一决策权威：确定每个资源范围的权威治理控制器，明确提议者、批准者和状态提交者的边界。
- 引入滞回与非对称转换：为风险进入和退出设置不同阈值；对权限升级设置稳定窗口，对紧急降级设置立即生效机制。
- 引入 epoch 和 fencing token：让每个高风险操作携带治理版本，在外部副作用提交前重新验证。
- 加入幂等与状态对账：建立稳定的逻辑操作 ID，记录外部系统执行结果，并处理超时、重复请求和结果不确定情况。
- 建立独立监测和恢复机制：监测状态抖动、版本延迟、旧授权拒绝、队列积压和恢复时间，并通过故障注入验证系统行为。
每个阶段都应保留回滚路径，避免治理控制器本身成为新的单点故障。
二十、参考实现：权限状态转换的核心伪代码
以下伪代码展示治理控制器和执行闸门的关键逻辑。它是概念性实现，不是可直接部署的完整代码。
def evaluate_transition(current, evidence, policy):
risk = assess_risk(evidence)
if evidence.has_hard_stop:
return transition_to("CONTAINMENT", immediate=True)
if evidence.is_stale or evidence.is_incomplete:
return transition_to("HOLD", immediate=False)
if current.state == "ALLOW":
if risk.score >= policy.allow_to_limit_threshold:
if risk.sustained_for(policy.entry_window):
return transition_to("LIMIT")
elif current.state == "LIMIT":
if risk.score >= policy.limit_to_hold_threshold:
if risk.sustained_for(policy.entry_window):
return transition_to("HOLD")
if risk.score <= policy.limit_to_allow_threshold:
if evidence.clean_for(policy.recovery_window):
return request_promotion("ALLOW")
elif current.state == "HOLD":
if risk.score <= policy.hold_to_limit_threshold:
if evidence.clean_for(policy.recovery_window):
return request_promotion("LIMIT")
return current状态转换必须通过原子提交：
def commit_transition(resource, expected_epoch, new_state):
return atomic_compare_and_swap(
resource_id=resource.id,
expected_epoch=expected_epoch,
new_epoch=expected_epoch + 1,
governance_state=new_state,
revocation_floor=expected_epoch + 1
)外部执行闸门：
def authorize_effect(command, current):
if command.governance_epoch < current.revocation_floor:
return DENY("stale_authorization")
if command.policy_version not in current.accepted_policy_versions:
return DENY("stale_policy")
if not current.capabilities.allows(command.action, command.resource_scope):
return DENY("capability_not_allowed")
if not idempotency_check(command.idempotency_key):
return DENY("duplicate_or_conflicting_request")
return ALLOW实际系统还需要处理事务边界、外部系统 fencing、消息投递、超时、补偿操作和权限缓存失效等问题。
二十一、必须覆盖的故障测试矩阵
| 测试场景 | 注入条件 | 预期结果 |
|---|---|---|
| Threshold Jitter | 风险评分在阈值附近反复波动 | 不发生无意义的频繁切换 |
| Stale Evidence | 风险数据停止更新 | 不因数据缺失自动恢复权限 |
| Delayed ALLOW | 旧 ALLOW 命令延迟到达 | fencing token 拒绝执行 |
| Network Partition | 部分 Agent 无法同步状态 | 高风险操作失败关闭 |
| Dual Controller | 两个控制器同时修改同一资源 | 只有符合版本条件的提交成功 |
| Policy Update Mid-task | 执行期间更新策略 | 旧版本操作按策略边界处理 |
| Duplicate Retry | 外部操作成功但响应丢失 | 不产生重复副作用 |
| Controller Restart | 状态转换过程中控制器重启 | 从持久化状态恢复，不重复提交 |
| Agent Disagreement | 多个 Agent 提交冲突决策 | 权威控制器按确定规则解决 |
| Emergency Override | 人工触发紧急隔离 | 不等待普通升级或冷却窗口 |
| Safe Mode Recovery | 风险解除后申请恢复 | 按分阶段条件恢复权限 |
| External Timeout | 外部 API 长时间无响应 | 不持有控制面锁等待，不盲目重试 |
还需要测试一个容易被忽视的场景：外部操作已经成功，但控制器没有收到成功响应。此时系统不能仅根据本地超时就断定操作失败，必须通过外部查询、幂等记录和 reconciliation 确认实际状态。
二十二、治理稳定性必须成为可观测指标
| 指标 | 含义 |
|---|---|
| Governance Transition Churn | 单位时间内治理状态切换次数 |
| Promotion Rate / Demotion Rate | 权限升级与降级频率 |
| Transition Latency | 风险变化到治理状态提交的时间 |
| Revocation Propagation Latency | 撤销状态传播到执行节点的时间 |
| Stale Command Rejection Count | 被拒绝的过期授权命令数量 |
| Stale Command Accepted Count | 被错误接受的过期授权数量，目标必须为零 |
| Policy Version Lag | Agent 与权威控制器之间的策略版本差距 |
| Capability Hash Divergence | 不同节点有效权限集合不一致的情况 |
| Duplicate Effect Rate | 重复外部副作用发生率 |
| Reconciliation Backlog | 尚未完成对账的外部操作数量 |
| Unresolved In-flight Effects | 状态不确定的进行中操作 |
| Deadlock Timeout Count | 控制器等待或锁竞争超时次数 |
| Safe Mode Recovery Time | 从安全模式恢复到批准状态所需时间 |
治理状态切换次数不能孤立地追求越低越好。如果系统遇到真正的严重风险，却因为冷却窗口而不愿意收紧权限，那么低 churn 反而代表控制器失效。更合理的判断是：无意义的状态抖动减少，必要的风险收紧仍然及时，过期授权成功越过撤销边界的次数为零，策略版本差异得到控制，并且系统在满足恢复条件后能够逐步恢复。
二十三、在 SEO / GEO 自动化中的具体应用
以一个企业网站内容治理流程为例。系统准备发布一篇工业设备技术文章，文章包含产品型号、额定参数、运行条件、维护周期和应用场景。Content Agent 已完成草稿，Fact Check Agent 核对了主要资料，Publisher Agent 获得了单篇发布权限。
此时 Monitoring Agent 发现制造商最新技术文件中的额定参数与草稿不一致，企业内部产品资料仍然使用旧版本，现有内容审批记录引用的是旧文件，而 Publisher 队列中已经存在一个 ALLOW 命令。
New Evidence Detected
↓
Risk State Updated
↓
Governance Decision = HOLD
↓
Governance Epoch Incremented
↓
Revocation Floor Updated
↓
Old ALLOW Command Rejected
↓
Publisher Admission Blocked
↓
Fact Check Re-evaluation
↓
Content Revision
↓
New Approval
↓
New Governance Epoch
↓
Controlled Publishing
↓
Frontend Verification系统不应该简单地把旧文章删除，也不应该因为 Publisher 已经收到过 ALLOW 就继续发布。如果文章尚未产生外部副作用，直接拒绝旧命令即可。如果 WordPress 已经创建了文章，但前台验证尚未完成，则需要读取文章状态、确认实际内容版本，并决定更新、恢复或进入人工处理。
对于 SEO 和 GEO，这套机制的价值不在于直接提高 Google 排名或保证 AI 引用，而在于降低错误产品参数进入公开页面的风险，防止过期授权继续修改生产内容，让内容审批和发布状态保持一致，并保留每次治理决策的证据与版本。
二十四、稳定性不等于不变化，收敛也不等于永远静止
真实运行环境始终在变化：新风险会出现，旧风险会消失，策略会更新，Agent 会重启，外部系统会超时，证据会过期，任务会进入新的执行阶段。如果系统拒绝变化，就无法适应真实环境。
稳定性应该定义为：在风险变化和运行异常发生时，系统仍然能够按照明确规则完成必要的状态转换，并在满足条件后收敛到一致、可验证的有效权限状态。
它包含三个不同层面的能力：Safety，不允许危险操作越过权限和撤销边界；Liveness，在条件恢复后系统不会永久停留在无意义的阻塞状态；Convergence，多个 Agent 和执行节点最终采用同一个权威治理状态。
过度追求 Safety 可能造成长期 HOLD 和任务停滞；过度追求 Liveness 可能在证据不足时提前放权；过度追求 Convergence，如果要求所有节点同步完成后才能进行任何动作，也可能形成控制平面的阻塞。工程设计必须明确哪些操作需要强一致性，哪些操作可以容忍短暂延迟，以及哪些场景必须失败关闭。
二十五、实施边界：滞回、fencing 和幂等都不是万能保证
Adaptive Governance Control 可以显著改善自治系统的稳定性，但不能消除所有不确定性。
- 滞回不能修复错误的风险信号。如果风险模型本身存在系统性偏差，两个阈值只会让错误状态更加稳定。
- Fencing token 必须由受保护资源验证。如果外部系统不检查 token，旧进程仍然可能产生副作用。
- 分布式状态收敛需要明确的可用性假设。网络分区、节点失效和存储故障会影响撤销传播和状态一致性。
- 已经发生的外部副作用不一定可逆。HOLD 可以阻止新的发布请求，但不能自动撤回已经发送给客户的邮件或已经生效的外部配置。
- 幂等不代表 exactly-once。跨系统操作仍然需要持久化记录、状态对账和必要的补偿流程。
- 形式化不变量不等于完成形式化证明。如果没有验证并发模型、外部系统行为和异常边界，就不能把设计原则宣传成数学保证。
NIST 对已部署 AI 系统监测挑战的研究也强调，部署前测试无法覆盖真实运行环境中的全部变化。实际系统会遇到非确定性输出、环境变化和意外后果，因此部署后的持续监测、风险管理和响应机制不可缺少。
参考：NIST CAISI — Challenges to the Monitoring of Deployed AI Systems
二十六、结语：从“能够做出正确决策”走向“能够稳定地执行正确决策”
AI Agent 自治能力不断增强之后，企业需要解决的问题已经不只是模型是否足够聪明、Agent 能否完成复杂任务、风险评分是否足够准确、策略是否定义了权限边界。还必须进一步回答：风险发生变化时权限能否稳定调整？多个 Agent 是否采用同一个权威治理状态？策略更新后旧版本是否仍可能继续执行？HOLD 生效后旧 ALLOW 命令是否能够被拒绝？外部操作超时或重复请求时系统是否会产生重复副作用？控制器发生故障后系统是否能够恢复？风险解除后权限是否能够按照可验证的步骤重新开放？
这标志着 AI Agent 治理从静态权限管理进入动态控制系统阶段。一个成熟的自治系统，不应该只具备决策能力，还应该具备状态稳定性、权限可撤销性、版本一致性、执行幂等性和故障恢复能力。
最终目标不是让 AI Agent 永远拥有更多权限，也不是让系统永远处于限制状态，而是建立一种能够根据证据变化、风险变化和业务边界持续调整的治理机制：风险上升时及时收紧，风险下降时审慎恢复；多个 Agent 最终采用同一有效状态；旧授权不能越过新的撤销边界；每一次外部副作用都能够验证、追溯和对账。
这才是 Stable and Adaptively Governed Autonomous System 的工程含义。
技术参考资料
- Kubernetes Controllers：控制器持续协调期望状态与实际状态。
- Kubernetes Coordinated Leader Election：Lease、领导者协调与并发更新控制。
- Kubernetes API Concepts：resourceVersion 与乐观并发控制。
- etcd API Transactions：基于比较条件执行原子事务。
- etcd API Guarantees：事务、Revision 和一致性保证。
- The Chubby Lock Service for Loosely-Coupled Distributed Systems：分布式锁、sequencer 与过期操作拒绝机制。
- AWS Builders’ Library — Making retries safe with idempotent APIs：幂等请求、重复执行与安全重试。
- NIST AI Risk Management Framework — Core：GOVERN、MAP、MEASURE、MANAGE 四项核心职能。
- NIST AI RMF Playbook — Manage：部署后监测、事件响应、恢复和变更管理。
- NIST CAISI — Challenges to the Monitoring of Deployed AI Systems：部署后 AI 系统监测挑战。
- Google SRE Book — Addressing Cascading Failures：正反馈、重试和级联故障。
- Schneider Electric Easergy P3F30 Protection Relay Manual：保护继电器中的滞回与阈值复归机制。
下一篇预告
《SEO / GEO 自动化治理（五十一）：Governance Chaos Engineering——如何通过故障注入验证 AI Agent 权限、策略同步与控制回路的真实安全边界？》
下一篇将从治理系统的设计约束进入对抗性验证：通过延迟消息、网络分区、双控制器、过期授权、重复副作用和控制器重启等故障场景，验证前述治理不变量是否真正成立。