传统权限控制是按单个请求来检查的。Agent 调用查账户，检查通过；Agent 调用转账，检查通过。但问题出现在中间：Agent 查账户时返回的是账户 A，转账时却传了账户 B——两个操作分别看都合规，连起来就是一个严重错误。
这就是 AI Agent 时序治理要解决的问题。它不是问”这一步能不能做”，而是问”根据前面已经做了的事，这一步加上去还安全吗”。以前这种判断靠人来做，但现在 Agent 可以连续调用几十个工具，靠人看不过来。
这个问题和 质量门禁、审计查询字段、变更后验证清单 在逻辑上是连在一起的：都是从”检查单个点”升级到”检查整条链”。
为什么单个权限不够
传统的权限控制是”无状态”的。你有一个权限列表，Agent 每次调工具时系统检查”你有没有这个权限”。问题是，Agent 不是按一次来用的——它在一个会话里可能连续调用 20、30 个工具，每一步都可能改变前一步的数据或上下文。
举个例子：Agent 先查了一个客户的订单列表，然后给”取消订单”工具传了一个不在列表里的订单号。单独的权限检查看不出来问题——Agent 确实有查订单和取消订单的权限。但连起来看，Agent 在”编造数据”。
这种场景在 Agent 规模化后会越来越多。昨天写的 证据包 里也提到过：要区分”Agent 看到了什么”和”Agent 用到了什么”——时序治理就是把这种区分做成自动化检查。
时序策略要检查什么
时序治理至少应该覆盖四类检查：
第一，数据传递校验。如果前一个工具返回了某个值，后一个工具用到这个值的时候，必须和返回值一致。这不是信任 Agent，而是强制执行。
第二，工具调用顺序。有些操作有内在顺序要求——比如必须先验身份再查敏感数据，先确认信息再发客户通知。时序策略可以要求 A 必须发生在 B 之前，否则 B 拒绝执行。
第三，累积上限。单个转账可能只转 1000 元，但如果一个会话里转了 50 次，总额远远超过预算。时序策略可以追踪会话级的累积值，超限就阻断。
第四，人工审批触发。某些操作（比如删除客户数据、修改核心配置）不应该被 Agent 独立完成——不管前面的步骤有多合规。时序策略可以要求”这个操作必须在过去 5 分钟内有人工审批记录”。
这四点对应了 失败升级规则 里的分级处理思路：不是每个操作都需要时序检查，但关键链路一定要。
怎么落地：策略要在基础设施层，不是提示词层
时序治理最容易犯的错误，是把策略写在提示词里。比如”在调用转账前，请确保账户号与查账户时返回的一致”。这种方式有两个致命问题：第一，Agent 可能忽略（或被恶意指令覆盖）；第二，你没法证明 Agent 确实检查了。
正确的做法是把策略放在 Gateway 层。所有工具调用都经过 Gateway，策略在 Gateway 上执行，Agent 看不到策略逻辑，也无法绕过。AWS Bedrock AgentCore 的时序策略和 Dogwood 语言就是这种思路的实践，OpenClaw 的 Gateway 安全边界也是同样的设计哲学。
这和 人工复核抽检 的安全原理一致：不靠 Agent 自报家门，而是靠外部的、Agent 无法干预的检查机制。
总结
AI Agent 的时序治理，本质是把安全模型从”单步检查”升级到”会话级检查”。四个维度——数据传递校验、工具调用顺序、累积上限、人工审批触发——构成了一个基础框架。关键是策略要放在 Gateway 层，不在提示词层，否则只是心理安慰。
