Amazon Bedrock AgentCore 架构详解：组件分工、适用场景与试点指南

当智能体已经能完成任务，围绕它搭建和维护的基础设施却快要变成另一个产品时，就值得试点 Amazon Bedrock AgentCore。AWS 当前列出了 13 项模块化服务与能力。选择时，应让每个组件解决一项明确的运行维护负担；至于智能体在业务上如何行动，责任仍在你。

本文于 2026 年 10 月 30 日对照 AWS 在线产品页面和文档完成核验。下方组件清单来自 AgentCore 产品页面链接的开发者概览；各组件能替代哪些自建工作，则是本文从工程角度作出的分析。

Amazon Bedrock AgentCore 是什么？

AgentCore 让你把智能体生产运行中的部分工作交给 AWS。 智能体是一类借助模型选择动作、调用工具并推进任务的软件。即使这套执行循环已经能在本地给出回答，身份管理、执行环境、状态管理、访问控制和调试仍有大量工作要做。

可以把它想象成一座音乐厅：智能体的行为是台上的演出；Runtime 提供舞台和配套设施，访问控制把守入口，记忆保存有用的上下文，可观测性则记录发生了什么。演出要达到什么目的、最终是否成功，仍由你来判断。

AWS 明确表示，AgentCore 支持**“任何框架、任何模型”**。产品页面列出了 LangChain、OpenAI Agents SDK、Claude Agent SDK、Strands SDK，也包括你自己的框架。这是 AWS 对平台支持范围的说明，并不意味着每项可选能力都有完全相同的集成支持，也不意味着迁移无需投入工作。参见 AWS 产品概览。

执行循环由谁负责，也有不同的选择。使用 Runtime，你部署的是自己的智能体代码；使用 Harness，则通过配置描述智能体，使用 AWS 托管的执行循环，其底层由 AWS 开源智能体框架 Strands Agents 驱动。Harness 文档明确区分了这两条路径。如果团队已经有可用的编排代码，工程负责人应优先评估 Runtime。

Bedrock Agents 和 AgentCore 该怎么选？

已经部署了 Amazon Bedrock Agents，不必因为 AgentCore 出现就迁移。 AWS 表示，现有 Bedrock Agents 用户可以继续使用。只有在执行、集成或运行维护能力上有具体需求时，才有必要考察 AgentCore。参见 AWS 常见问题。

如今，二者的区别已不能简单概括为“托管执行循环与基础设施之别”，因为 AgentCore 也通过 Harness 提供托管循环。先确定是否要自行掌控编排代码，再选择对应路径。做这个决定时，可以结合更完整的 AI 智能体架构图解，避免一次托管方案选择无意间演变为整个应用的重新设计。

Bedrock AgentCore 组件分别能替代哪些自建工作？

选组件，要看它能替代哪些原本需要你自建和维护的工作。 AWS 文档将这些能力定义为模块化能力，既可配合使用，也可独立使用。表格最后一列列出了即使 AWS 提供配套服务，应用方也仍需承担的责任。

客服助手可能一开始就需要 Runtime、Gateway 和 Identity，等到需要利用老用户的上下文时再引入 Memory。如果助手从不付费访问外部资源，Payments 就派不上用场。当团队难以在组织内找到已获批准的资源时，Registry 才有价值。接入更多组件本身不应成为目标。

Code Interpreter 和 Runtime 解决的是不同问题。 Runtime 托管智能体，Code Interpreter 则为智能体执行的代码提供沙箱。如果你唯一欠缺的是隔离的代码执行环境，可以先对照 AI 智能体代码沙箱指南评估这一需求，再决定是否迁移编排逻辑。

哪些架构决策仍需自己负责？

必须划清托管基础设施与应用业务权限之间的边界。 以客服流程为例，智能体可以读取订单、解释订单状态并提出下一步操作。AWS 能提供执行和访问基础设施，但订单属于谁、是否允许执行该操作，必须由你的应用确认。

Bedrock AgentCore Runtime：执行隔离不等于会话归属校验

Runtime 可以隔离执行环境，但并不知道某个会话属于哪位客户。 AWS 文档说明，会话使用专用的 microVM 环境，对计算、内存和文件系统资源进行隔离。同一份文档也明确指出，AgentCore 不会强制校验会话与用户的对应关系；这一关系必须由客户端应用的后端维护。参见 Runtime 会话文档。

对客服助手而言，不能因为浏览器传来了某个会话标识，就认定该会话属于当前客户。应先对请求进行身份验证，再由后端确定该用户有权使用的会话，并将下游访问范围限定在该客户之内。基础设施隔离与应用授权判断，是两项不同的责任。

Bedrock AgentCore Memory：哪些上下文值得保留？

Memory 替代上下文管理基础设施，存什么仍由你决定。 AWS 支持短期对话上下文，也支持跨会话保留的长期信息。参见 Memory 文档。

记住客户偏好简短回答，与保存作为权威依据的订单余额，是两回事。业务记录应以应用中的数据为准。你需要决定智能体如何获取最新记录、可以保留哪些对话信息，以及记住的偏好不再准确时如何处理。记忆服务不会替你作出这些数据设计决策。

Bedrock AgentCore MCP：Gateway 如何连接工具？

当工具连接变成重复的工程工作时，Gateway 就有了用武之地。 模型上下文协议（Model Context Protocol，简称 MCP）为向智能体提供工具定义了通用接口。Gateway 可以将 API 和 AWS Lambda 函数转换为兼容 MCP 的工具，也能连接已有的 MCP 服务器。当前文档还介绍了向其他智能体和模型路由请求的能力。参见 Gateway 文档。

为订单助手提供工具时，应先开放查询配送状态这类范围明确的操作，再考虑通用数据库查询工具。Gateway 可以传递调用，但操作的具体含义、可访问哪些记录，以及重试是否会重复触发副作用，仍由你的 API 决定。

Bedrock AgentCore Identity：有了凭据，还要有业务权限规则

Identity 管理执行者身份及其使用的凭据；Policy 则在网关处约束允许执行的操作。 Identity 提供工作负载身份和凭据管理，用于访问 AWS 资源及第三方服务，也支持代表用户执行操作。参见 Identity 文档。

Policy 会先评估经过与其关联的 AgentCore Gateway 的流量，再决定是否允许访问工具。这个边界很关键：不要认为网关策略也会管控智能体绕开网关发起的直接网络调用。应让敏感操作经过预定的权限控制点，并限制绕过该控制点的路径。参见 Policy 文档。

客服身份可能获准读取订单，却无权退款。模型指令应描述这一工作流程，而工具层与授权层负责落实权限限制。

Bedrock AgentCore Observability：追踪能还原过程，不能证明业务成功

Observability 帮助还原行为，Evaluations 帮助评估行为。 AgentCore 提供执行过程视图和兼容 OpenTelemetry 的遥测数据，后者为追踪与指标提供标准格式；仪表盘则由 Amazon CloudWatch 支撑。AWS 区分了内置指标与需要你在应用中埋点补充的追踪信息和业务元数据。参见 Observability 文档。

以客服助手为例，应记录所请求的订单查询是否完成、某项操作是否获批。一次技术上成功的工具调用，仍可能答非所问。

Evaluations 提供内置和自定义评估，也包括由模型担任评审的方式。你仍需定义有代表性的用例，并复盘影响较大的失败。评估文档列出了支持的框架和埋点方式；应核实自己选用的路径，而不能把平台层面的广泛兼容性承诺套用到每项功能上。

哪些运行限制会影响架构设计？

计算资源的生命周期，与有效状态需要保留多久，是两回事。 AWS 当前的生命周期文档规定，默认空闲超时为 15 分钟，microVM 计算资源的最长生命周期为 8 小时。另一种模式 Instances 会在你的账户中运行托管的 Amazon Elastic Compute Cloud 计算资源，允许将生命周期配置为最长 14 天，具体还受其容量提供程序设置的约束。参见生命周期设置和 Instances 文档。

逻辑会话可以在新分配的计算资源上恢复。默认情况下，内存和本地文件系统中的状态随计算资源的生命周期存续；配置会话存储后，文件系统数据可在停止、恢复之间保留。必须明确规划哪些数据需要在中断后继续存在。参见会话生命周期与存储。

确定采用哪些能力之前，应先核对 AWS 的各区域功能支持矩阵。对于必须部署在特定区域的应用，“AWS 已提供该功能”还不够。

什么时候值得采用 AgentCore？

当某项明确的运行维护能力缺口正在阻碍交付，而相应的托管组件又符合需求时，就值得行动。 评估时应关注执行隔离、工具访问授权、状态保留、问题诊断能力，以及自行维护这些能力的负担。

对开发者而言，如果智能体逻辑已经可用，却迟迟卡在托管或工具集成上，就可以启动试点。把现有执行循环放到 Runtime 上，试验范围会比同时更换框架和部署平台更可控。

对运维人员而言，如果每个智能体都需要同样的凭据管理、访问控制和故障排查，采用 AgentCore 的理由就更充分。应选择一个能验证这些职责的工作流，也要覆盖一个需要诊断的失败场景。

对技术采购决策者而言，要问的是哪些重复性工作能省掉，又会留下哪些新的集成工作。AWS 配置、权限设计、应用行为和值班响应，仍然需要明确到人的负责人。

如果现有技术栈已经提供所需的控制能力，也没有明确的问题需要解决，就暂缓采用。迁移应有其他具体理由，例如需要现有技术栈无法提供的能力。如果工作流只是按固定顺序执行已知操作，并不需要智能体选择下一步动作，则无需因 AgentCore 改变方案。

如果成本是决策关键，可以结合 AWS 的 AgentCore 定价与本站的 Amazon Bedrock 定价指南一起评估。

如何用 AWS CLI 完成首次试点？

从 AWS 的代码模板入手，再加入一项有代表性的业务操作。 以下流程依据当前的 Runtime 快速入门和完整 CLI 指南整理而成，本文没有对这套部署流程进行实测。

完整指南要求准备 Node.js 20.12 或更高版本、npm、Python 3.10 或更高版本、Python 依赖管理工具 uv，并配置好 AWS 凭据、部署权限和模型访问权限。此模板使用 CodeZip，因此不需要 Docker。

1. 1

   安装并创建项目

   使用用于开发的 AWS 账户或环境。

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   模板包含一个名为 agent 的 Runtime，以及一个 AgentCore Memory 资源。请在生成的配置中检查这两项资源。

2. 2

   本地测试

   cd MyProject
   agentcore dev --mode browser

   在本地检查界面中测试智能体，随后停止服务，再在同一终端继续后续步骤。

3. 3

   构建、部署与调用

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   部署过程通过 AWS Cloud Development Kit（简称 CDK）创建 AWS 资源。

4. 4

   检查运行情况并清理资源

   agentcore logs runtime
   agentcore traces runtime list

   在本次试点项目目录中，执行以下命令会移除项目资源，并拆除已部署的资源栈：

   agentcore remove all --yes
   agentcore deploy --yes

接入生产流量前，应把问候语替换为边界明确的任务，例如查询一笔测试订单。验收项应围绕应用本身来定：是否返回正确数据、是否拒绝未授权访问、追踪记录中是否能看到失败的工具调用，以及是否已弄清中断后的恢复行为。这些是试点的决策标准，并非 AWS 的性能承诺。

哪些说法需要冷静看待？

托管执行并不能证明智能体会作出正确的业务决策。 托管、追踪、评估和策略执行解决的是不同问题。选择有价值的任务、界定允许执行的操作、分析失败原因，这些责任都不会因此消失。

“支持任何框架”也不等于“集成无需投入”。即便平台具备灵活性，你仍需验证依赖、身份认证、埋点，以及所采用各项服务的接口约定。

此外，用齐所有组件，并不能证明系统已经具备生产可用性。一个只读客服助手，不会因为获得支付权限或用不上的浏览器而变得更好。只有具体任务需要时才添加能力，并把随之扩大的权限范围纳入评审。

下周一就可以做什么？

选一个现有的智能体任务，写清楚究竟是哪项运行维护工作拖慢了交付。只试点解决这一阻碍所需的 AgentCore 能力。将试点后的部署、故障处理和维护责任负担与现有技术栈进行比较，有证据支持时再扩大采用范围。

订阅邮件通讯，获取构建和运营 AI 系统的实用指南。