AI Agent正在改变企业应用的形态。
过去的软件大多按照预设逻辑运行：调用接口、处理数据、返回结果。Agent则不同，它可以根据任务自主规划，调用不同工具，访问数据并持续执行复杂任务。
这意味着，企业正在迎来一种新的生产负载。而新的生产负载，通常也会带来新的基础设施问题。
当Agent数量从几个PoC增加到几十、几百甚至更多时，企业需要解决的已经不是简单的模型调用，而是运行时、身份、权限、工具接入、隔离、弹性以及可观测性等一整套问题。
9月29日，亚马逊云科技宣布Amazon Bedrock AgentCore在亚马逊云科技中国（北京）区域和亚马逊云科技中国（宁夏）区域正式可用。Runtime、Gateway、Identity、Browser Tools、Code Interpreter和Observability等组件，构成了一套围绕Agent生产运行设计的服务体系。
如果从企业IT架构的角度观察，这次上线的意义并不只是“多了一个Agent服务”，而是云厂商开始针对Agent这种新型工作负载，把原本分散在不同基础设施层的能力重新组织起来。
Agent为什么会给传统架构带来新问题？
原因在于Agent的运行方式与传统应用并不完全相同。一个Agent可能只运行几秒，也可能持续执行数小时；一次任务可能只调用一个API，也可能连续调用多个工具；业务流量可能平稳，也可能在短时间内出现数量级增长。
如果按照传统方式建设基础设施，企业很快会遇到一个问题：到底应该按照多少规模建设？
建少了，应对不了峰值；建多了，大量资源又会处于闲置状态。
Amazon Bedrock AgentCore Runtime采用Serverless架构，根据业务流量自动扩缩容，支持从零到数十万并发会话，并支持长时间运行任务。其计算资源按照实际消耗进行秒级计费。
对于企业来说，这种模式的价值并不复杂：Agent的基础设施可以随着Agent本身的使用情况变化，而不是要求企业提前为一个尚未确定规模的未来进行大量基础设施建设。
Agent进入生产，首先要解决身份问题
传统应用的访问权限通常可以通过账号、角色和服务权限进行管理。Agent的出现，让“谁在访问”这个问题变得更加复杂。一个Agent可能代表用户访问企业资源，也可能以自身身份访问资源；它还可能需要调用第三方API、Lambda函数或MCP Server。
因此，Agent的身份和凭据不能简单地沿用开发阶段的处理方式。
Amazon Bedrock AgentCore Identity提供面向Agent的身份与访问管理，可以对接符合OIDC标准的身份提供商，并负责安全托管访问下游服务所需的凭据。Gateway则提供统一的工具接入入口，并支持对请求数、Token和连接速率进行控制。
从架构设计来看，这实际上是在回答一个基础问题：当Agent开始代表企业执行任务时，企业如何让它“有身份地行动”。这也是Agent走向企业级应用之后必然需要补上的一层。
从逻辑隔离走向运行环境隔离
安全之外，另一个核心问题是不同Agent任务之间如何隔离。尤其在多租户环境中，如果多个Agent会话共享同一运行环境，数据交叉和状态污染的风险就会成为企业无法忽视的问题。
Amazon Bedrock AgentCore Runtime采用microVM提供硬件级虚拟化隔离，为每个Agent会话提供独立的隔离计算环境。
这并不意味着企业可以因此忽略自身的安全体系，而是让Agent运行时本身具备更清晰的隔离边界。对于需要运行大量Agent任务的企业而言，这种基础能力的重要性会随着Agent数量增加而进一步放大。
这也是Agent基础设施与传统应用基础设施一个值得关注的变化：过去企业更多是在应用层定义安全边界，而Agent时代，运行时本身也正在成为安全边界的一部分。
开放架构，决定企业能不能持续迭代
Agent还有一个传统软件不太一样的特点：底层技术变化非常快。
模型在变，框架在变，工具调用协议也在不断发展。
因此，如果Agent基础设施与某个特定模型或者开发框架深度绑定，企业未来升级技术栈时，就可能再次面临大规模迁移。
Amazon Bedrock AgentCore选择了相对开放的方式，支持任意模型、主流开源Agent框架以及MCP标准协议，并将底层基础设施与上层应用逻辑进行解耦。
对于企业架构师而言，这一点的意义可能比单项性能指标更加长期。企业不一定需要今天就判断出未来最重要的模型是什么，但需要确保自己的应用架构不会因为模型变化而被迫推倒重来。
从这个意义上说，开放性实际上是一种架构上的“抗变化能力”。
Agent也需要自己的“运维体系”
另一个问题是，Agent一旦进入生产环境，企业怎么管理它？
传统应用可以依靠日志、监控、调用链和告警体系定位问题，但Agent的执行过程更加复杂。一个任务可能涉及多轮推理、工具调用和外部服务交互。如果企业无法看到这些过程，那么Agent出了问题之后，排查就会变得非常困难。
Amazon Bedrock AgentCore Observability基于Amazon CloudWatch提供全链路追踪、调试和监控能力，可以对Agent工作流以及工具调用进行追踪。这让Agent开始具备一个成熟生产系统应有的基本特征：不仅能够运行，而且能够被观察、定位和持续优化。
对于企业IT部门来说，这一点尤其重要。因为Agent规模越大，人工逐个排查问题的方式就越不可持续。
从一个Agent到一组Agent，才是企业真正需要面对的挑战
Agent进入生产的最终形态，很可能不是一个超级Agent解决所有问题，而是大量Agent分别承担不同任务。这也是企业为什么需要统一的Agent运行和治理能力。
目前已经有一些全球企业开始借助Amazon Bedrock AgentCore进行探索实践。Cox Automotive已经将17个企业级Agent解决方案推向生产；爱立信在涉及数百万行代码和数千个互联子系统的研发环境中使用Amazon Bedrock AgentCore，覆盖数万名员工；索尼集团则基于Amazon Bedrock AgentCore构建覆盖集团的Agentic AI平台。
从这些实践可以看到，Agent的企业级价值并不只来自某一次任务效率提升，而来自企业是否能够持续增加Agent数量，同时保持统一的安全、运行和治理能力。
这也让云基础设施厂商在Agent时代获得了新的机会。模型负责提供能力，应用负责定义业务价值，而运行时、身份、安全、弹性、工具连接和可观测性，则决定这些能力能不能真正进入企业生产体系。
Amazon Bedrock AgentCore此次在中国区域正式可用，正是在这一层提供了一套相对完整的能力组合。对于已经开始从单点PoC转向规模化部署的企业而言，这类能力的重要性可能会越来越明显。
AI Agent正在从一个新的应用形态，变成企业需要长期运营的一类生产负载。
当这个变化真正发生之后，企业IT面对的问题也会随之改变：不再只是“怎么开发一个Agent”，而是如何让越来越多的Agent安全、稳定、可控地运行起来。
这或许才是Agent走向企业级规模化之后，真正需要解决的基础设施问题。
