AI News
官方更新 AWS ML Blog Thu, 06 Aug 2026 正文 ok 1492 words

借助 Amazon Bedrock AgentCore 新能力，控制跨越单次操作的 Agent 行为与成本

英文标题：Control agent behaviors and cost beyond a single action: new capabilities in Amazon Bedrock AgentCore

Amazon Bedrock AgentCore 推出由开源策略语言 Dogwood 驱动的时序策略，以及 Gateway 速率限制能力，以在基础设施层对 Agent 行为和成本实施确定性控制。时序策略可基于同一会话中的操作序列进行授权决策，例如验证账户信息一致性、累计预算、强制执行步骤顺序及要求人工审批。Gateway 速率限制可按用户身份限制请求数、Token 消耗量和连接持续时间，并支持按秒或按分钟设置窗口。两项能力均无需修改既有 Agent 代码，有助于企业在扩大自主 Agent 部署时强化安全、治理与成本可预测性。
打开原文相关 4.5 · 机会 5
media1.3 MB media101.1 KB media124.1 KB media345.0 KB media141.2 KB media346.5 KB media1.4 MB media1.1 MB media687.3 KB media27.1 KB media208.6 KB

中文

Agent 正变得更加自主，团队也在运行更多 Agent，但信任与安全能力尚未跟上这一发展。麦肯锡数据显示，约 80% 的组织已经遇到过 AI Agent 的风险行为。因此，安全与风险顾虑已成为扩展 Agentic AI 的首要障碍（McKinsey《2026 年 AI 信任状况》及《2026 年 AI Agent 时代的信任》）。

这使得信任成为 Agent 创新和采用速度的决定因素。要赢得信任，需要在广泛的维度实施控制，包括身份、访问权限、可观测性、评估和可追溯性。我们相信，对信任和安全的投入将加速企业对 Agent 的采用。当护栏足够可靠时，批准一个新 Agent 不再是一次性的协商，而会成为平台能够大规模处理的事务。

挑战在于，如今大多数护栏都是为行为可预测的软件设计的。Agent 会在执行过程中自行决定路径，因此每一步都可能单独通过检查，而整体行为模式却未经审视。一个 Agent 查询客户账户后，将资金转入另一个账号，因为每次调用都是单独判断的。一个 Agent 连续下了多笔订单，每笔都低于审批阈值，因为没有机制跟踪总额是否超出预算。一个 Agent 遇到失败工具后整夜重试，耗尽 Token 预算，因为没有任何机制限制它的消耗量。每一个请求本身都合法，问题只会出现在整体模式中，而 Agent 恰恰是你最不应依赖其发现这类问题的对象。

我们构建 Amazon Bedrock AgentCore，旨在让团队无需自行拼装基础设施，即可大规模构建、连接和优化 Agent。从一开始，我们就秉持一项原则：安全控制应属于基础设施层，并在每个 Agent 中得到一致执行，而不应放在应用代码中，由各个团队以不同方式分别实现。

AgentCore 的 Gateway 是这一理念落地的关键。Gateway 是面向 AI 流量的全托管、无服务器入口，可将请求路由至模型上下文协议（MCP）服务器、大语言模型（LLM）、Agent 和知识库。由于每一次调用都会经过它，Gateway 自然适合施加无论 Agent 如何行为都能保持有效的限制。今天，我们通过以下新能力推进这项工作：由新开源策略语言 Dogwood 驱动的时序策略，以及 Gateway 中的速率限制。

通过时序策略为操作序列设置边界，而不只是约束单个操作

当前，AgentCore 中的策略可让团队对 Agent 行为实施确定性控制：在每项操作执行前进行检查，评估谁可以调用哪个工具，以及可在何种条件下调用。这些检查在设计上是无状态的。每个请求都依据自身情况被快速且可验证地判断——这正是授权机制一贯所需的能力。随着 Agent 在更少监督下承担更长的任务，另一个问题随之出现：其所有操作合在一起，是否构成应被允许的行为？只有观察操作序列，而不仅是单个操作，才能发现这一点。

时序策略扩展了 AgentCore 的策略能力，以弥合这一缺口。策略引擎不再孤立地判断某个请求，还会查看 Agent 在该会话中此前执行过的操作，并根据这一操作序列允许或拒绝此次调用。若某笔转账使用了错误账号，策略可要求传入一次调用的值必须与此前调用返回的值一致，从而阻止该转账。策略还可统计 Agent 在一个会话中的支出，并在预算用尽后阻止下一笔采购，即使该笔采购本身低于单笔限额。团队还可要求操作必须按照既定顺序进行，或要求重大操作必须具备已记录的人工批准。当人员不再参与时，权限也可以自动收窄。

时序策略在 Gateway 层执行，位于 Agent 自身代码之外。无论 Agent 接收何种提示，或带有什么缺陷，它都看不到策略逻辑，也无法绕过策略进行推理。对于需要批准自主系统的安全负责人而言，这一区别至关重要。这意味着不再只是相信 Agent 会守规矩，而是能够确认边界会在其整个操作过程中持续生效。决策具有确定性，默认拒绝，并会记录完整的上下文信息。审查人员不仅能看到某次调用被阻止，还能了解被阻止的原因。

为时序策略提供支持的是 Dogwood，这是一种专为 AI Agent 打造的新策略语言。Dogwood 构建于 Cedar 的基础之上，旨在解决 Agent 控制中的一个新维度：随着 Agent 操作序列逐步展开，评估其是否符合策略。Dogwood 内嵌 Cedar，并增加了用于 Agent 治理的时序构造，包括速率限制、时间窗口、前置步骤和升级触发器。Dogwood 以 Apache 2.0 许可发布开源规范和参考实现。这让客户能够全面了解策略的评估方式，也使更广泛的生态系统能够构建配套工具。

通过 Gateway 速率限制控制 Agent 的资源消耗

AI 成本本身就是一个治理问题；对于 Agent 而言，问题始于它们消耗 Token 和调用的速度。Agent 会自行判断完成任务所需的步骤数量，因此一项任务的成本取决于它选择的工作方式，而不是某个预先确定的速率。如果不加限制，重试循环或异常繁重的会话会以 Agent 自行决定的速度消耗资源。这种不可预测性是获得批准的实际障碍。Forrester 发现，Agentic AI 很少实现规模化的原因之一就是成本（《2026 年 Agentic AI 现状》）。团队需要一个无论 Agent 如何行为都能保持有效的上限。

从今天起，你可以直接在 AgentCore 的 Gateway 上设置这些上限。速率限制使团队能够利用其已通过 OAuth 或 IAM 管理的身份，针对每位用户、Gateway 后的全部工具、模型和 Agent 限制资源消耗。限制可以涵盖用户发出的请求数量、模型为其处理的 Token 数量，以及其保持连接打开的时长。这三类限制都很重要，因为 Agent 会以不同方式推高成本。重试循环表现为请求量增加，推理密集型任务表现为 Token 消耗增加，而长时间研究会话则表现为连接长时间保持打开、但实际流量很少。任何单一指标都可能留下在不触发限制的情况下耗尽服务资源的途径。

限制可在按秒和按分钟的窗口中生效，这正是为了控制团队实际遇到的故障模式：Agent 以无人预期的速率消耗资源，且事后才被发现。速率限制在配置完成后立即生效，无需修改 Agent 代码。容量分配将成为平台团队配置的事务，而非需要自行开发的能力。不同用户、团队、工具和模型可以设置不同上限，而无需在其中任何一方编写限流逻辑。

未来方向

模型持续进步，这正是部署 Agent 的价值所在。但这也提高了风险，因为能力更强的 Agent 会在更少监督下采取影响更重大的操作。企业能从更好模型中获得多少收益，取决于它是否能以管理生产环境中其他一切事物同样严谨的方式运行这些 Agent。

对 Agent 的信任，本质上并不是对模型本身的判断，而是对模型所运行系统的判断：当 Agent 出现意外行为时，该系统是否仍能保持约束。构建这类系统仍是一门年轻的学科，客户如今向我们提出的问题，明显比一年前更加成熟。我们预计将在这一领域持续快速推进，同时继续投入身份、可观测性、评估和可追溯性。每一项从应用代码迁移到平台中的控制能力，都意味着少一项需要为每个 Agent 单独重建、审查和信任的能力。平台越能可靠地约束 Agent 的行为与消耗量，你就越能毫不犹豫地赋予它更高的自主权。

这两项能力都不需要重新架构已投入生产的 Agent，并且可以分别单独采用。要了解更多信息，请参阅 AgentCore 文档和定价页面，并探索 Dogwood 参考实现。

关于作者

Madhu Parthasarathy

Madhu Parthasarathy 是 Amazon Bedrock AgentCore 总经理，负责领导团队构建企业用于构建、连接和优化生产级 AI Agent 的平台。他拥有超过 20 年构建大规模分布式基础设施的经验，其中在 Amazon 工作超过 16 年，曾主导 Amazon Retail、Elastic Block Store（EBS）以及如今 AgentCore 的重要项目。在重返 Amazon 前，Madhu 曾在 LinkedIn 担任高级领导职务，负责领导支撑 LinkedIn 全部企业业务线的企业平台；他还曾在一家新云（neo-cloud）创业公司负责 AI 基础设施，并制定安全性和开发者体验的愿景。他工作于加利福尼亚州圣克拉拉。

English / 原文

Agents are becoming more autonomous and teams are running more of them, but trust and security have not kept pace. According to McKinsey, roughly 80% of organizations have already encountered risky behavior from AI agents. As a result, security and risk concerns are the leading barrier to scaling agentic AI (McKinsey’s State of AI Trust in 2026, and Trust in the age of AI agents 2026).

That makes trust the pacing factor for agent innovation and adoption. Earning it takes control across a wide surface, including identity, access, observability, evaluation, and traceability. We believe that investment in trust and security will accelerate agent adoption in enterprises. When guardrails are dependable, approving a new agent stops being a one-off negotiation and becomes something the platform handles at scale.

The challenge is that most guardrails today were designed for software that behaves predictably. Agents decide their own path as they go, so every step can pass on its own while the shape of the whole goes unexamined. An agent looks up a customer’s account, then transfers money to a different account number, because each call was judged on its own. An agent places a series of orders that each sits under the approval threshold, because nothing is tracking the total against the budget. An agent hits a failing tool and retries through the night, running through the token budget, because nothing capped how much it could consume. Every one of those requests was legitimate. The problem appears only in the pattern, and the agent is the last thing you would rely on to catch it.

We built Amazon Bedrock AgentCore to give teams what they need to build, connect, and optimize agents at scale without assembling the infrastructure themselves. One principle has guided it from the start: security controls belong in the infrastructure layer, enforced consistently across every agent, rather than in application code where each team implements them differently.

AgentCore’s gateway is where that idea becomes concrete. The gateway is a fully managed, serverless entry point for AI traffic, routing requests to Model Context Protocol (MCP) servers, large language models (LLMs), agents, and knowledge bases. Because every call passes through it, the gateway is the natural place to apply limits that hold no matter how an agent behaves. Today we are advancing that work with new capabilities: temporal policies, powered by Dogwood, a new open source policy language purpose-built for AI agents, and rate limiting in the gateway.

Boundaries on sequences of actions, not only individual ones with temporal policies

Policies in AgentCore today give teams deterministic control over agent behavior, checking every action before it runs to evaluate who can call which tool and under what conditions. Those checks are stateless by design. Each request is judged on its own merits, quickly and provably, which is what authorization has always required. As agents take on longer tasks with less supervision, another question arises: whether its actions, taken together, add up to something that should be allowed. That is only visible when you look at the sequence of actions, not only individual ones.

Temporal policies extend the policies in AgentCore to close that gap. Rather than judging a request in isolation, the policy engine also looks at what the agent has already done in that session, then permits or denies the call based on that sequence of actions. The transfer that used the wrong account number can be blocked by a policy requiring that a value passed into one call match what an earlier call returned. A policy can tally what an agent has spent in a session and block the next purchase once the budget is reached, even if that purchase is under the individual limit. Teams can also require that the steps happen in a set order, or that a significant action needs a recorded human approval. Permissions can narrow automatically when a person is no longer engaged.

Temporal policies are enforced at the gateway layer, outside the agent’s own code. The agent does not see the policy logic and cannot reason around it, regardless of how it is prompted or whatever defects it carries. For security leaders being asked to approve autonomous systems, this is the distinction that matters. It is the difference between trusting an agent to behave and knowing the boundary holds over the course of its actions. Decisions are deterministic, deny by default, and logged with the full context behind them. A reviewer can see not only that a call was blocked but why.

Powering temporal policies is Dogwood, a new policy language purpose-built for AI agents. Built on the foundation of Cedar, Dogwood was designed to address a new dimension of agent control: evaluating whether a sequence of agent actions conforms to a policy as it unfolds. Dogwood embeds Cedar and adds temporal constructs for agent governance including rate limits, time windows, prerequisite steps, and escalation triggers. Dogwood is available as an open source specification and reference implementation under Apache 2.0. This gives customers full visibility into how their policies are evaluated and allows the broader ecosystem to build supporting tooling.

Control what agents consume with rate limiting on gateway

AI cost is its own governance question, and with agents it starts with how fast they consume tokens and calls. An agent takes as many steps as it judges necessary, so what a task costs depends on how it chooses to work rather than on a predetermined rate. Left unbounded, a retry loop or an unusually heavy session consumes at whatever speed the agent decides. That unpredictability is a real constraint on approval. Forrester found that the reasons agentic AI rarely reaches scale starts with cost (The State Of Agentic AI In 2026). Teams need a ceiling that holds regardless of how an agent behaves.

Available today, you can set those ceilings directly on AgentCore’s gateway. Rate limiting lets teams cap consumption per user across every tool, model, and agent behind the gateway, using the identities they already manage through OAuth or IAM. Limits can cover how many requests someone makes, how many tokens a model processes for them, and how long they hold connections open. Having all three matters because agents run up cost in different ways. A retry loop shows up as request volume, a reasoning-heavy task shows up as tokens, and a long research session shows up as a connection held open while very little traffic moves. Any single measure leaves a way to exhaust a service without tripping a limit.

Limits apply in per-second and per-minute windows, which is what contains the failure mode teams actually hit: an agent consuming at a rate nobody intended, discovered after the fact. Rate limits take effect once they are configured, with no changes to agent code. Capacity allocation becomes something platform teams configure rather than build. Different users, teams, tools, and models can carry different ceilings, without throttling logic written into any of them.

Where this is heading

Models keep improving, and that progress is what makes agents worth deploying. It also raises what is at stake, because a more capable agent takes more consequential actions with less supervision. What an enterprise earns from better models depends on whether it can run those agents with the same discipline it applies to everything else in production.

Trust in an agent is not really a judgment about the model. It is a judgment about the system the model runs inside, and whether that system holds when an agent behaves unexpectedly. Building that system is a young discipline, and the questions customers bring us now are noticeably more sophisticated than the ones they brought a year ago. We expect to keep moving quickly here, alongside continued investment in identity, observability, evaluation, and traceability. Every control that moves out of application code and into the platform is one fewer thing that must be rebuilt, reviewed, and trusted separately for each agent. The more reliably a platform can bound what agents do and how much they consume, the more autonomy you can extend without hesitation.

Neither capability requires rearchitecting agents already in production, and you can adopt either on its own. To learn more, see the AgentCore documentation and pricing pages, and explore the Dogwood reference implementation.

About the author

Madhu Parthasarathy

Madhu Parthasarathy is the GM of Amazon Bedrock AgentCore, where he leads the team building the platform that companies use to build, connect, and optimize production AI agents. He brings more than 20 years of experience building large-scale distributed infrastructure, including over 16 years at Amazon, where he has led major initiatives across Amazon Retail, Elastic Block Store (EBS), and now AgentCore. Before returning to Amazon, Madhu held senior leadership roles at LinkedIn, where he led the enterprise platform powering all of LinkedIn’s enterprise lines of business, and at a neo-cloud startup, where he led AI infrastructure and set the vision for security and developer experience. He is based in Santa Clara, California.