一句话结论
AWS 发布实战方案，将医疗多模型智能体从 ECS/Fargate 迁移至 AgentCore 运行时，通过装饰器模式简化部署运维，保留多模型编排与向量检索能力。
关键要点
- 迁移方案采用 Hugging Face smolagents 开源 Python 库作为参考实现，通过自带（BYO）智能体方法部署现有代码，核心逻辑无需重写。
- 智能体在单个 AgentCore 管理容器内运行，保留三重模型编排：BioM-ELECTRA-Large-SQuAD2 处理专业生物医学查询，Meta Llama 3.1 70B Instruct 处理广泛医疗推理，架构支持模型无关性。
- 部署通过单一命令 `agentcore deploy` 完成，CLI 自动构建容器、推送至 Amazon ECR 并创建运行时代理，耗时约 10–15 分钟。
- 容器镜像大小需控制在 2GB 限制内，通过在 `pyproject.toml` 定义依赖及配置 `Dockerfile` 与 `.dockerignore` 实现。
- 生产环境处理敏感查询时，需使用 Amazon Bedrock Guardrails 进行内容过滤和基础验证，完整实现代码位于 GitHub 仓库 sample-healthcare-agent-with-agentcore-on-aws。
背景与事实
Amazon Bedrock AgentCore 运行时是一种托管部署功能，负责处理容器生命周期、扩展、身份验证和可观察性。AWS Machine Learning Blog 发布的方案展示了一个具体案例：将原本运行于 Amazon ECS 配合 AWS Fargate 的多模型医疗 AI 智能体，迁移至 AgentCore 运行时。该智能体在迁移前后保留三重模型编排及向量增强知识检索能力。具体而言，专业生物医学查询被路由至部署于 Amazon SageMaker AI 的 BioM-ELECTRA-Large-SQuAD2 模型，而广泛医疗推理任务则交由部署于 Amazon Bedrock 的 Meta Llama 3.1 70B Instruct 模型处理。
在技术实现层面，该方案使用 Hugging Face 提供的 smolagents 开源 Python 库作为参考实现。与前一版本使用 Anthropic Claude 3.5 Sonnet V2 不同，本方案采用 Llama 3.1 70B Instruct，旨在展示 AgentCore 运行时的模型无关性。三个后端均实现了 Hugging Face Messages API 兼容性，确保了请求和响应格式的一致性。架构中集成了 Amazon OpenSearch Service 用于向量增强知识检索，而 AgentCore 运行时则提供了内置身份验证和可观察性功能。整个方案的完整实现代码公开在 GitHub 仓库 sample-healthcare-agent-with-agentcore-on-aws 中。
迁移过程的核心在于集成方式的变化。AgentCore 运行时通过 `BedrockAgentCoreApp` 装饰器、`@app.entrypoint` 及 `app.run()` 集成现有代理代码，自动管理容器生命周期、扩缩容、身份验证及可观测性。开发者使用 AgentCore CLI 安装工具，创建项目并通过 `--framework` 标志添加自带（BYO）代理。需注意，该标志指定 CLI 模板，而实际代码使用 Hugging Face smolagents，这与 AgentCore 运行时兼容。开发团队需在 `pyproject.toml` 定义依赖，并配置 `Dockerfile` 及 `.dockerignore` 以保持镜像大小在 2GB 限制内。部署通过单一命令 `agentcore deploy` 执行，CLI 自动构建容器、推送至 Amazon ECR 并创建运行时代理，整个过程耗时约 10–15 分钟。测试可通过 CLI 或 boto3 进行，利用 `agentRuntimeArn`、`contentType` 及 `payload` 调用代理。
影响分析
对中文开发者与从业者而言，该方案提供了从传统容器编排向托管智能体运行时迁移的具体路径。采用 ECS 配合 Fargate 的团队需要手动配置任务定义、服务、自动扩缩容策略、IAM 角色及 Amazon CloudWatch 可观测性，这种模式提供了对容器配置、网络及扩缩容的全控，适合具备容器运维经验的团队。相比之下，AgentCore 版本运行相同的 `healthcare_agentcore.py` 代码，提供了容器编排、基于会话的扩缩容、IAM 身份管理及内置追踪日志，从而简化了运维工作。这一变化意味着开发者可以将精力从基础设施管理转移至代理逻辑本身。
然而，这种迁移并非适合所有场景。该方案强调框架无关设计，支持跨行业（医疗、金融、制造）的应用，但生产环境处理敏感查询时，必须使用 Amazon Bedrock Guardrails 进行内容过滤和基础验证。这表明在合规要求较高的领域，开发者需额外投入配置安全护栏。对于希望简化运维、专注业务逻辑的团队，AgentCore 提供了更低的门槛；但对于需要深度定制容器网络或扩缩容策略的团队，ECS 方案可能仍是更优选择。
适用边界
该结论主要适用于希望简化智能体部署运维、且能够接受 AgentCore 内置功能的团队。若团队对容器网络配置、自定义扩缩容策略有深度定制需求，或运行环境无法使用 Amazon ECR 及 AgentCore 运行时，则此迁移方案不适用。此外，方案中提到的 2GB 镜像限制意味着资源密集型模型需仔细优化依赖管理。生产环境中处理敏感医疗数据时，必须额外集成 Amazon Bedrock Guardrails，否则基础验证和内容过滤功能缺失，不符合合规要求。
孤本观察
该方案通过保留核心逻辑并仅增加装饰器模式实现迁移，降低了技术债务转换成本。编辑判断认为，这种“代码不动、环境换”的兼容性策略，是托管平台吸引存量用户上云的关键设计。
常见问题
AgentCore 部署命令及耗时？
通过单一命令 `agentcore deploy` 完成，CLI 自动构建容器、推送至 ECR 并创建运行时代理，耗时约 10-15 分钟。
容器镜像大小限制及处理方法？
限制在 2GB 内，需在 `pyproject.toml` 定义依赖，并配置 `Dockerfile` 与 `.dockerignore` 进行优化。
方案使用哪些模型处理不同医疗任务？
BioM-ELECTRA-Large-SQuAD2 处理专业生物医学查询，Meta Llama 3.1 70B Instruct 处理广泛医疗推理。
生产环境处理敏感查询需集成什么？
必须使用 Amazon Bedrock Guardrails 进行内容过滤和基础验证，以满足合规要求。
该迁移方案的核心参考实现库是什么？
采用 Hugging Face smolagents 开源 Python 库作为参考实现，通过自带（BYO）智能体方法部署现有代码。