AWS大幅提升AgentCore运行时配额，智能体并发能力增至五倍

AWS近日宣布大幅提升Amazon Bedrock AgentCore运行时的关键配额，最高增幅达五倍。此举旨在帮助企业在无需经历繁琐配额申请流程的情况下，支持更多并发AI智能体运行及用户交互，从而加快生产环境部署节奏。

新版默认配额方面，在美国东部（北弗吉尼亚）和美国西部（俄勒冈）地区，活跃并发会话上限从原来的1000个提升至5000个；其他所有支持地区则从500个提升至2500个。

在交互处理能力方面，每个AI智能体每秒可处理的Token数量已从25个提升至200个，覆盖全部支持地区。AWS表示，这一提升将使企业能够同时响应更多用户请求。此外，针对容器部署场景，新建AI智能体会话的速率限制也从每分钟100次提升至400次，增长了四倍，有助于企业在业务高峰期更快速地扩展AI应用。

Forrester首席分析师Charlie Dai认为，这次配额调整是AWS对企业将AI智能体实验快速推向生产部署这一趋势的直接回应。他指出："在与客户的沟通中，更显著的变化并不是智能体数量的增加，而是从单任务副驾驶模式转向服务更大用户群体的多个生产级智能体。"他进一步表示，AWS正在观察到更高的并发量、更长时间运行的智能体，以及超出早期默认预设的更复杂编排模式。

Gartner高级首席分析师Ashish Banerjee认为，对于正在完成这一转变的企业而言，更高的默认配额将有助于降低AI智能体从试点项目扩展到生产部署过程中的运营阻力。

IT咨询公司Kanerika首席分析官Amit Chandak也表示，大规模AI部署、尤其是多智能体系统，正迅速超出默认运行时配额，迫使企业不得不频繁申请配额提升。"在企业环境中，一次配额提升申请意味着要提交支持工单、撰写业务理由并经历审核周期，这可能需要数天乃至数周时间，而这些本不应该成为阻碍部署的障碍。"

Chandak还补充道，配额限制不仅带来行政负担，还直接影响架构设计决策。"团队会围绕默认上限来设计架构。更高的默认值会改变团队在不触发例外流程情况下的尝试边界，进而影响架构选择，而不仅仅是日常运营。"

此外，Chandak强调，生产环境中触及运行时配额上限还可能中断面向客户的应用程序和多智能体工作流。"智能体会话是有状态的。当会话在任务执行中途被限流，智能体可能丢失中间上下文，而重建这些状态远比重试无状态API调用复杂得多。在多智能体流水线中，一个被拒绝的会话会导致整个工作流停滞，进而产生孤立会话、未完成的工具调用以及事后难以诊断的监控空白。"

Avasant研究总监Gaurav Dewan指出，此次提升对高并发、事务密集型AI工作负载的企业受益最为明显，主要涉及客户服务与联络中心、软件工程与DevOps自动化、IT运营、金融服务流程自动化、医疗行政管理、供应链协同以及安全运营等领域，这些场景中AI智能体往往需要大规模并发运行。

值得注意的是，在帮助企业规模化部署AI智能体方面，AWS并非唯一行动者。微软和谷歌等竞争对手也在以各自不同的方式应对这一挑战。Chandak指出，微软Azure Foundry Agent Service的做法与AWS存在明显差异："微软的许多智能体运行时限制是由设计固定的，即便提出申请也无法提升。微软将扩展灵活性放在模型部署层面，而非智能体运行时层面。这与AWS通过AgentCore在运行时层面提升并发会话下限的做法，是一种刻意为之的架构差异。"

AWS表示，Bedrock AgentCore的更新后配额限制将自动应用于所有企业账户。

Q&A

Q1：AWS此次提升AgentCore运行时配额具体提升了哪些指标？

A：此次提升主要涉及三个方面：并发会话数量方面，美国东西部主要地区从1000个提升至5000个，其他地区从500个提升至2500个；智能体每秒可处理的Token数量从25个提升至200个；针对容器部署场景，新建会话的速率限制从每分钟100次提升至400次。所有变更自动应用于企业账户，无需额外申请。

Q2：为什么配额限制对企业AI智能体的生产部署影响这么大？

A：配额限制的影响不仅在于行政流程，还涉及架构设计和业务连续性。在企业环境中，申请配额提升需要提交支持工单、撰写业务理由并经过审核，可能耗费数天乃至数周。更关键的是，团队往往围绕默认上限设计架构，上限越低，尝试空间越受限。此外，生产中触及配额上限可能导致有状态的智能体会话被中断，造成上下文丢失，在多智能体流水线中甚至会引发整个工作流停滞。

Q3：AWS与微软在帮助企业扩展AI智能体部署方面有何不同？

A：两家公司的架构思路存在明显差异。AWS选择在运行时层面直接提升并发会话的默认上限，让企业无需申请即可获得更大的扩展空间。而微软Azure Foundry Agent Service的许多运行时限制是固定的，即便申请也无法更改，其扩展灵活性主要体现在模型部署层面，配额调整发生在模型层而非智能体运行时层。