每步合规、连起来就出事——AWS 用 Dogwood 把授权塞进了时间轴

8 月 6 日，AWS 在同一天扔出了三样东西：让 AI agent 在 EC2 上连续跑 14 天的专用运行时、一个能回溯 agent 历史行为的开源策略语言 Dogwood，以及一项由 AWS、OpenAI、Microsoft、Cursor、Vercel 等共同制定的 Agent Plugins 开放标准。三件事指向同一个判断：agent 要从 demo 进生产，信任不能靠 agent 自觉，必须由平台兜底。

Marc Brooker：只看单步授权是"不完整的"

AWS 副总裁兼 Distinguished Engineer Marc Brooker 在 Dogwood 发布的同一天接受采访时，把问题讲得很直白："传统的授权方式是你孤立地看每一个动作、每一次工具调用、每一步，然后问'这个好不好？'"他说这套做法很强，但"不完整"，因为"能不能现在做这件事的答案，常常取决于之前发生过什么。"

Brooker 把 agent 形容为"执拗的问题解决者"："你堵住一条路，它会找到另一条路。这正是我们喜欢 agent 的原因，也是它们难以治理的原因。"他解释，让 agent 在微虚拟机里隔离运行可以挡住外部风险，但"要让 agent 有用，它必须走出去，必须在世界上做事情——我花钱雇 agent 就是为了让它替我干活。"隔离与有用之间的那条缝，就是策略层存在的理由。

AWS AI 与数据负责人 Swami Sivasubramanian 称，这些控制"建在基础设施层，团队不需要在每个 agent 里重建"。他写道："平台越可靠地约束 agent 的行为，组织就越有底气赋予它们更多自主权。"这条推文在四天内获得近 40 次点赞和 14 次书签。

的 Frederic Lardinois 用标题一句话点破要害："你的 AI agent 下一次工具调用可能合法，但是错的。AWS 的 Dogwood 承诺解决这个问题。"

80% 的企业已经被 Agent 坑过了

AWS 选在这个时间点出手不是偶然。AWS 机器学习博客引用了 McKinsey 2026 年的数据：，安全和风险顾虑是规模化部署 agentic AI 的最大障碍。

放到时间线上看，2025 年下半年 AWS 发布了 AgentCore Runtime 的微虚拟机模式（最长 8 小时会话），2026 年 6 月又开放了交互式终端，允许开发者直接进入 agent 会话调试。但每一步都在回应同一个痛点：agent 做着做着就断了，或者做完了没人知道它到底干了什么。

Forrester 同期发现，agentic AI 难以规模化的首要原因就是成本：agent 走多少步、烧多少 token，完全取决于它自己怎么判断，没有预定的速率可循。一个重试循环能把一夜的 token 预算跑光，而每一项单独请求看起来都合规。

所以 AWS 在同一天端出两件事：让 agent 在可控环境里跑得更久（Runtime Instances），以及给 agent 的动作序列装上一道会看历史的闸门（Dogwood + 时序策略 + 网关限速）。两者不是简单的功能叠加。它们合在一起，才构成一个 agent 可以被放手去干活的完整理由。

14 天会话 + 共享文件系统：Agent 开始在同一个主机上协作

Runtime Instances 解决的是一个看似朴素但卡住无数团队的问题：agent 需要连续跑好几天，需要 GPU，需要多个 agent 在同一台机器上协作。此前这些事都得自己拼 EC2、配网络、管会话。上，Sébastien Stormacq 演示了最直接的用法：一个代码编写 agent 和一个代码审查 agent 共享同一个文件系统。编写 agent 生成 code.py 写入共享目录，审查 agent 在同一个 session 里直接读这份文件，两方不需要互发消息或调 API。

三个关键数字：会话最长保持 14 天（微虚拟机模式只有 8 小时），支持 GPU 实例类型，可以在空闲时暂停再恢复。部署方式极简：一个 @app.entrypoint 装饰器加一个 zip 文件或容器镜像。框架不限（CrewAI、LangGraph、LlamaIndex、Strands），模型不限。

定价上，AWS 采用标准 EC2 价格加上 AgentCore 编排的管理费。首批支持的区域覆盖美东、美西、亚太（孟买、新加坡、悉尼、东京）和欧洲（法兰克福、爱尔兰）。

与 Runtime Instances 同日发布的 Dogwood，解决的是另一个维度的问题。是一个基于 Cedar 的策略语言，Apache 2.0 开源，核心能力是给授权决策加上时间维度。一个 agent 查了客户账户，然后转账到另一个账户。每一步单独看都合法，连起来就是问题。Dogwood 的 formerly within 算子可以写"过去一小时内必须有同金额的审批通过"；count_within 可以写"一小时内转账不超过五次"。

策略在 AgentCore 的网关层执行，agent 自己的代码看不到策略逻辑，无论怎么 prompt 都绕不过去。所有决策都是确定性的，默认拒绝，并且记录完整的上下文。

与之配套，AgentCore 网关同步上线了速率限制，按每秒和每分钟窗口，对请求数、token 消耗和连接时长设置上限。不需要改 agent 代码，配置即生效。

信任从 Agent 代码搬进基础设施层

此前 agent 治理的主流做法是把规则写在应用代码里。每个团队各自实现一遍审批流程、速率限制、动作校验。同一家公司里五个 agent 可能有五种实现方式，有的根本没做。

AWS 这次的思路不同。Brooker 在采访中说得很清楚：策略和限速应该活在 agent 触及外部世界的那道边界上，而不是 agent 内部。AWS 机器学习博客同一天的文章把这个逻辑推到了底："对一个 agent 行为的信任，其实不是对模型的判断。是对模型运行的那个系统的判断，以及这个系统在 agent 行为异常时能不能兜住。"

这个判断落地在三个产品决策里。第一，Dogwood 嵌入 Cedar 而非替换它。已经有 Cedar 策略的客户不需要迁移，可以直接在现有策略里嵌入 temporal { ... } 表达式。第二，Dogwood 开源，参考实现放在 GitHub 上，Brooker 公开邀请开发者"把它集成到产品、开源项目、agent 里"。第三，Agent Plugins 1.0.0 作为跨厂商的开放标准同一天发布，AWS 与 Cursor、Microsoft、OpenAI、Vercel 共同组成技术指导委员会，Kiro IDE 和 AWS Agent Toolkit 首发即支持。

Agent Plugins 本身是一个"信封"：一个包含 plugin.json 清单、skills/ 目录和可选的 mcp.json 的文件夹，打包一次就能在 ChatGPT、Codex、Cursor、GitHub Copilot、Kiro 和 VS Code 之间通用。将此事类比为 JavaScript 社区收敛到 package.json 的那一刻。标准化的是封装格式，不是分发方式和市场，所以多家竞争对手能在同一份文档上签字。

挡在 Agent 和放手之间的，只剩平台这道闸

AWS 机器学习博客在同期文章里写了这样一段判断：模型越强，agent 做的事越重大、受到的监督越少。"企业从更好的模型中赚到的东西，取决于它能不能用管理生产环境中其他一切的那种纪律来管理这些 agent。"

AWS 在同一天打包交付的东西，是把"能不能跑得久"和"能不能管得住"这两个问题同时回答了一遍。写完策略、设好限额、部署到专用实例，agent 不用改一行代码。剩下的，是每家企业自己决定什么时候把闸门打开。开到多大。