亚马逊的 Agent 治理宣言与一个找不到代码的开源承诺

让 AI 代理自主执行任务是件诱人的事——想象一个客服 Agent 能在一次会话里独立完成查询订单、发起退款、发送确认邮件，全程无需人工介入。但自主性带来授权难题：如果这个 Agent 答应退回一件客户根本没买过的商品怎么办？如果它在第三步擅自调用了本应在第一步才能执行的账户余额查询怎么办？单个 API 调用的权限控制太粗糙，事后审计又太滞后。2026 年 8 月，亚马逊在 Bedrock AgentCore 上给出的答案是“时序策略”——一种能依据会话历史做出状态化授权判断的规则引擎，它的开源策略语言叫 Dogwood [1][2]。方向正确，工程价值明确。但在尝试验证这套机制究竟处于什么状态时，遇到了一个比技术架构更基础的问题。

从无状态到有状态：为什么时序约束是个必做题

要理解 Dogwood 试图解决什么，先看一个它之前的困局。在 Agent 行为治理中，长期以来可用工具只有两种：静态权限（这个 Agent 能不能调用转账接口）和内容护栏（这条输出内容是否违规）。它们的共同缺陷是无状态——不关心“在调用转账接口之前发生了什么”。

现实世界中的风险往往隐藏在行为序列里。一个正常客服 Agent 的合法旅程是：先验证客户身份 → 再查询订单状态 → 最后执行退款操作。但如果 Agent 跳到第二步之后直接执行退款，跳过了身份验证，单看每一步调用的 API 都是合法的，组合起来却构成高危行为 [2]。传统权限系统看不到这个序列异常，它只检查“该 Agent 是否有退款 API 的调用权限”——答案是有，于是放行。

这就是时序策略的切入点。AWS 为 AgentCore 新增了 temporal policies，用 Dogwood 语言编写基于会话历史的状态化授权规则。它的工作原理可以这样理解：策略引擎在每次 Agent 发出动作请求时，不只是检查这次动作本身是否被允许，还回溯当前会话内已经执行过的动作序列，基于预先定义的规则判断接下来的动作是否合规 [1][2]。可定义的规则类型包括三类：强制工作流顺序（必须按特定步骤走）、防止数据捏造（限制 Agent 只能引用真实 API 返回的数据而不能凭空编造）、以及财务敞口控制和人工审批触发（设定金额阈值并强制高风险操作经人工确认）[2]。

把这三类规则串联起来，想象一个支付场景的时序策略可以写成：已授权金额的累计值不超过 X——这需要累加会话内所有金融操作的返回结果，而非检查单次请求参数；当累计金额触发阈值，强制转入人工审批流程；策略本身由 AWS 托管的引擎执行，Agent 无法绕过或修改规则 [2]。

工程上的创新点很清晰：从“这个 Agent 能不能做 X”进化成了“在当前序列下，这个 Agent 能不能做 X”。这是 Agent 治理从无状态走向有状态的标志性一步。

笼子的栏杆和它所漏掉的东西

但这个笼子有一种结构性的盲区。时序策略检查的是动作层面的合规性——第一步是不是身份验证、第二步是不是订单查询、第三步是不是退款执行——它不检查第二步返回的数据是否真实。这里的技术边界在于：单步幻觉可以完全穿透时序约束 [1]。Agent 可以在合规的时序节点上调用订单查询接口，接口正常返回结果，但模型在生成下一步推理时却伪造了一个从未被 API 返回的订单金额。Dogwood 的策略引擎只看动作序列，它根本看不到模型内部生成了什么内容。护栏在序列层面成立，在单步语义层面有一个大洞。

支持时序策略的一个有力反驳是：这本就不是 Dogwood 的职责。时序策略定位在治理层（governance），内容准确性的防护留给 Guardrails，混淆两者的分工是在做错误的指责。这个反驳在技术分层上成立。防火墙不负责杀毒，时序策略不负责防幻觉——这是合理的能力边界。

但真正的问题出在叙事而非技术上。AWS 的官方材料把 Dogwood 描述为能“防止数据捏造”（preventing data fabrication）的机制 [2]。这个表述暗示行为序列合规可以阻断数据层面的伪造。事实是时序策略能阻止的是一种特定类型的数据捏造——Agent 在无 API 调用支撑的情况下虚构数据。它不能阻止 Agent 调用了 API 之后，在推理环节用与返回结果不一致的数据替换真实值。这两种“捏造”有本质区别，但“防止数据捏造”这个表述没有划定这条区分线 [1]。AWS 文档中使用的措辞 focus 在“确保 Agent 仅能引用经 API 调用返回的真实数据”这一行为约束上，并未明确覆盖推理环节对返回数据的篡改行为 [2]。边界的划线缺失意味着一个概念上的缺口：行为合规被不加限定地等同于数据可信。

开源语言与一个还没打开的代码仓库

在试图理解 Dogwood 的策略语法能写多复杂的规则时，遇到了一个更前置的问题：找不到代码仓库。截至 8 月，AWS 官方博客明确说 Dogwood 是开源策略语言，但未提供仓库地址、无公开语法规范、无独立解析器、无可分离运行的策略引擎 [2]。一篇博客说“已开源”，不等于开源事实成立。

这个证实的缺失在分析的各个层级都有连带影响。现在讨论的策略表达式能力、状态机匹配算法、延迟特性、误杀率——所有这些被反复分析的技术特性，在当前证据下严格来说都属于 AWS 的宣称而非可检验的数据。如果任何一个外部工程师想在本地复现一条最简单的 Dogwood 策略——“如果前两步查询了账户余额，第三步禁止调用转账接口”——他跑不通，因为找不到解析器。

这不是在否定 Dogwood 的工程方向。AWS 同期发布了 AgentCore harness 正式可用版、在 n8n 工作流平台上提供了开源社区节点，Anthropic 也在 Bedrock 上发布了以 Agent 能力为主打的 Claude Sonnet 5 [3][4]。这个信号簇显示 AgentCore 的控制平面在从无状态权限检查向有状态治理迁移，工程资源投入的方向是真实的。但控制平面的架构升级和 Dogwood 语言本身的可独立使用是两件事。n8n 集成验证了“控制平面存在”，没有验证 Dogwood 的策略语法可被第三方编写和部署。一个更审慎的判断是：时序策略的架构方向可信，但当前最核心的组件——策略语言本身——处于“可描述但不可复现”的状态。

替代解释值得被摆上台面。这可能是发布节奏管理：AWS 在开源准备完成前先发布博客，抢占“Agent 治理基础设施”的行业话语权。如果这个替代解释成立，Dogwood 就不仅需要接受技术检验，还要接受信号真实性检验——它究竟是一个产品功能，还是一个市场定位声明。产品功能要求可访问、可复现；定位声明只需要方向描述。当前证据更一致地指向后者。

这个发现把整件事放到一个尴尬的位置：讨论都聚焦在笼子内部的弱点上，但笼子本身是否已经建好，在当前证据基础上给不了肯定答案。

程序性合规的场景价值分层

即便所有技术组件都落到了实处，时序策略提供的也是一种特定类型的价值：程序性合规，而非实质性安全。这个在监管认责的逻辑里是有明确场景分层的。

从正面看，时序策略把行为序列的可审计性首次变成了平台能力，改变的是举证责任的起点。过去如果 Agent 执行了违规操作序列，证明“我有流程约束”的责任完全在部署方自己举证，没有第三方可验证机制。时序策略提供了一条可追溯、可归因的路径：策略执行日志可以证明，Agent 在第三步确实被规则引擎拦截了，拦截点在哪个条件触发。对于那些流程合规本身就具有独立法律意义的行业，这个能力的准入门槛价值是实打实的——金融支付系统里，违反操作流程即使未造成实质损失也可能构成违规 [1]。

但这个合规效力的分布极不均衡。在结果强相关的行业，流程合规无法替代临床正确性。医疗处方场景中，Agent 执行了完整的问诊流程，每一步在时序层面都合规，但最终开出的处方是错误的——患者不会因为“流程合规”而获得安全。时序策略在此类场景中的认责减让效果会大打折扣。

还有一层不确定性在更上游：目前没有任何事故发生率的数据。就连“使用时序策略后风险降低了多少”这个最基础的因果链都无法量化 [1]。任何关于监管认责的推论都应标注为合理推断而非既定事实。需要追踪的指标是：12 到 24 个月内是否能出现真实事故判例，才能回答“当事故发生后，采用时序策略的一方能否在操作过失认定上获得减让”这个关键问题。

部署方的认知风险

把时序策略放进治理工具箱是合理的，把工具箱中的一件工具当成完整答案是危险的。时序策略在能力层面约束了行为合规性，但在三个维度上完全不提供保障：单步语义失真（模型在合规动作中产生与事实不符的输出）、策略设计缺陷（规则本身写错了或被绕过了）、延迟退化导致交互风险（策略引擎在高负载下响应变慢是否影响 Agent 实时决策）[1][2]。

这意味着一个隐性的认知陷阱：如果企业把 Dogwood 视为完整答案，造成的暴露面比不部署还大，因为安全感会降低对其他防控措施的投入意愿。时序策略是治理拼图的一块，它解决了一个过去被完全忽略的维度——状态化行为约束——但这个维度的补齐并不减少模型能力边界、护栏机制、人工监督这些其他维度的治理投入。拼图的另一块拼上了，不代表整幅图画就完成了 [1]。

追踪什么

方向是对的，最小可运行闭环还没到。Agent 治理从无状态走向有状态这一步的工程价值是明确的，但当前对这个价值的判断应该压在“值得追踪的方向”而非“已实现的能力”。

需要等待的事件清单很具体：Dogwood 代码仓库是否公开了地址和完整的策略语法规范；是否有第三方在沙箱环境成功部署并复现了一条基本的时序策略规则；是否公布了延迟基准数据，解决安全工程师对生产负载下误杀率和响应时间无法评估的问题；是否出现真实的 Agent 安全事故案例，其中时序策略的存在或缺失影响了责任认定 [1][2]。这些事情有答案之前，“第一套形式化时序策略”这个标签挂不上。

当前能做到的最好判断是：把时序策略纳入治理工具箱是有益的，但要清楚知道它管住了什么、没管住什么、没管住的那部分恰好是当前最棘手的单步语义问题。笼子的栏杆立起来了，但在确认栏杆之间没有一扇没装锁的门之前，别把钥匙扔掉。