治理的缺口
如今大多数企业级 agent 治理，本质上只是披着合规术语的可观测性。仪表盘会记录下 agent 读取了本不该读取的客户记录、两次调用了支付端点，或者把包含凭据的上下文窗口转发给了第三方模型。记录是准确的。但它也来得太晚了。
这种失效模式是结构性的，而非覆盖范围的问题。日志管道位于它所描述的那个决策的下游。当事件抵达存储时，工具调用早已返回，副作用已经落地，运行也已经继续向前。一个记录违规行为的仪表盘，早已在与运行的博弈中败下阵来。
这对 agent 而言比对传统服务更为重要，因为行为的单位不是一次请求，而是一条轨迹。单次运行可能发出数十次工具调用，每一次都以上一次为条件，跨越多个提供商和凭据。对轨迹的事后审查可以解释发生了什么。但一旦第三次调用成功，它就无法阻止第四次调用。只会描述的治理不是治理，而是日记。
执行点长什么样
执行点是一种同步拦截，策略决策可以在某个动作生效之前将其阻断或重塑。对于 agent 运行时，有三条接缝承载了大部分风险。
工具调用。 从模型到工具的每一次调用——函数调用、MCP 工具、HTTP 请求、shell 命令——在派发之前都要经过一次决策。该决策接收工具身份、参数载荷、发起调用的运行与步骤，以及累积的轨迹摘要。它返回允许、拒绝或重写：收窄参数、替换为只读变体、注入确认步骤。
数据外泄。 每一个离开信任边界的载荷——发往模型提供商、第三方 API、webhook——在传输之前都要检查分类标签和密钥模式。上下文窗口泄漏正是在这里被捕获，而不是在运行后对 prompt 的扫描中。
凭据签发。 每一个短期令牌、密钥或会话凭据都通过一个在签发时应用策略的代理来铸造。作用域绑定到具体的调用，而非整个运行。从未签发的凭据无法被滥用，而这条接缝是执行最小权限最廉价的地方，因为爆炸半径只是单个令牌。
每条接缝都需要三个属性，说起来容易，做起来难。
第一，有界的延迟预算。同步决策位于每次工具调用的关键路径上，因此策略服务有一个以百分位数而非平均值表示的延迟上限。如果超出预算，调用方需要一个已定义的行为，而不是一个敞开的套接字。
第二，当策略服务不可用时的默认拒绝路径。诚实的权衡是：默认拒绝会在策略服务中断期间破坏生产运行。默认允许则不会，并且还会在治理最需要它的时刻悄然将其禁用。站得住脚的立场是：对高后果接缝（凭据签发、发往外部端点的外泄）采用默认拒绝，对较低后果的读取采用缓存且带版本的决策集，同时缓存的新鲜度有界并在审计记录中呈现。
第三，确定性。给定相同的策略版本和相同的请求，决策必须完全一致。不得有依赖挂钟时间的规则，不得有随机采样，评估器中不得有可变的全局状态。确定性正是让审计中的重放变得有意义的东西；没有它，一条被记录的决策只是轶事，而非证据。
一个同时满足这三点的具体机制，是带有显式评估上下文的决策契约：
{
"request_id": "run-8f2c/step-14",
"policy_version": "2025-03-11.4",
"seam": "tool_invocation",
"subject": {"agent": "reconciliation-v3", "run": "run-8f2c"},
"action": {"tool": "payments.transfer", "args_hash": "sha256:9c1e..."},
"context": {"data_classes": ["pii"], "egress_target": "internal"},
"decision": "rewrite",
"rewrite": {"tool": "payments.transfer_preview"},
"latency_ms": 7,
"cache": "fresh"
}
评估器消费这条记录，产出一个决策，运行时将两者都持久化。args_hash 让审计记录不含原始载荷，同时仍可针对存储的参数集进行重放。policy_version 字段是承重的那个。
策略版本化作为一项运营要求
策略会变；运行不会。一次在策略版本 A 下启动、并在版本 B 发布时仍在执行的运行，必须受 A 治理，否则审计记录就会变得前后矛盾。这条规则说起来很简单：记录每次决策所评估的策略版本，并为运行的整个生命周期固定该版本，除非触发了显式的重新评估。
固定是必要的，但不充分。在不破坏生产的前提下变更策略，同样必须安全。其机制是影子评估。候选策略版本与生效版本一同部署。每个决策请求都由两者评估。生效版本的决策被执行；候选版本的决策被记录并比对。运维人员在任何一次调用真正阻断运行之前，就能得到一份本会被阻断的调用的差异报告。
影子评估正是大部分运营成本所在。它使评估负载翻倍，要求候选版本具备同样的确定性保证，并且需要一份能区分有意义的分歧与噪声的比对报告。回报是策略发布不再是变更管理事件，而成为例行公事。
另一装饰。
衡量它是否有效
执行点会产生一组小而实用的指标。真正重要的那些并不是覆盖率百分比。
按工具和按接缝跟踪阻断与放行的比率。阻断率接近零的工具，要么确实安全，要么受一条从不触发的规则治理；单看比率无法告诉你究竟是哪一种，但它会告诉你该往哪里看。在策略变更后阻断率飙升的工具，是影子审查的候选对象。
跟踪那个驱使运维人员禁用控制的误报率。这个指标决定了治理能否在与生产接触后存活下来。被关掉的控制不是控制。该衡量还应包括禁用时间：一条嘈杂的规则在被绕过之前存活了多久。禁用时间短，是策略在编写时缺乏对真实流量可见性的信号，而解决办法是影子评估，不是说教。
按延迟预算所指定的百分位数，跟踪各接缝处的决策延迟。一个平均达标、却在高峰期超标策略服务，就是一个会在高峰期被绕过的策略服务。
最后，跟踪重放保真度：针对存储的策略版本和请求重新评估时，能够完全一致地复现的已记录决策所占的比例。这是对确定性的运营测试。一个无法重放自身决策的治理系统，只是在描述行为，而非约束行为——这正是本文开篇所讲的问题。
真正重要的那一层
有用的治理层是小的、同步的、乏味的。它位于三条接缝处，在延迟预算下做出确定性决策，在后果严重处失败关闭，对其策略进行版本化，并衡量运维人员是否让它保持开启。策略文档和仪表盘是那一层的下游产物，而非其替代品。
先构建执行点。审计轨迹会从那里自行书写。
封面照片：Jakub Pabis / Pexels。