AWS发布迁移指南：把多模型医疗AI Agent从ECS迁到Bedrock AgentCore
迁移保留三模型编排与向量检索，仅需加装AgentCore装饰器，部署从ECS服务更新变为一条agentcore deploy命令，耗时约 10 到 15 分钟。
AI解读：AWS官方博客给出一个具体迁移样本：把此前跑在自管ECS+Fargate上的多模型医疗Agent，搬到Bedrock AgentCore runtime。对正在自己维护容器编排、扩缩容和身份配置的团队来说，这相当于把运维活交出去，只留Agent逻辑。
变化的核心不是换了模型，而是换了部署方式。同一份healthcare_agentcore.py代码不用重写，只需加上BedrockAgentCoreApp、@app.entrypoint和app.run() 三段装饰器即可运行；原先由用户配置的容器生命周期、扩缩容、身份和可观测性，转由AgentCore接管。
需要留意限制：这是演示用的样本实现，处理医疗等敏感查询时官方明确建议生产部署用Amazon Bedrock Guardrails做内容过滤与接地验证。另外迁移不改变模型接入和向量检索部分，OpenSearch、SageMaker和Bedrock的调用关系照旧。
AWS Machine Learning博客发布迁移指南，把此前基于Hugging Face smolagents构建的多模型医疗AI Agent，从自管的Amazon ECS with AWS Fargate迁移到Amazon Bedrock AgentCore runtime。作者为Sanhita Sarkar。
该Agent在三个模型后端之间编排：Amazon SageMaker AI上的BioM-ELECTRA-Large-SQuAD2处理专业生物医学查询，Amazon Bedrock上Meta的Llama 3.1 70B Instruct处理更广的医学推理，另有一个容器化模型服务器部署BioM-ELECTRA-Large-SQuAD2。向量增强的知识检索由Amazon OpenSearch Service承担。
迁移不需要改动核心Agent逻辑。同一份healthcare_agentcore.py文件通过AgentCore装饰器模式包装后即可运行，新增的是BedrockAgentCoreApp初始化、@app.entrypoint装饰入口函数、app.run() 启动服务三部分。
官方称AgentCore runtime负责容器生命周期、扩缩容、身份和可观测性，团队可以专注Agent代码。部署从ECS的task definition、自动扩缩容策略、按服务的IAM角色、CloudWatch可观测性配置，简化为一条agentcore deploy命令，博客称部署耗时约 10 到 15 分钟。
注意：该方案定位为演示用样本实现。博客指出，处理医疗或其他敏感查询的生产部署，应使用Amazon Bedrock Guardrails做内容过滤和接地验证作为标准控制措施。
迁移后保持不变的部分包括：核心Agent逻辑、跨Amazon Bedrock/Amazon SageMaker AI/容器化后端的多模型编排、基于OpenSearch的向量增强检索，以及各模型后端对Hugging Face Messages API的兼容。
从自管ECS到AgentCore：运维职责的转移
博客对比了两条部署路径。自管版运行在Amazon ECS with AWS Fargate上，用户需自行定义ECS task definition与服务配置、设置自动扩缩容策略、按服务配置IAM角色，并通过Amazon CloudWatch建立可观测性；部署流程是Docker构建、推送Amazon ECR、更新ECS服务。这条路径让团队对容器配置、网络和扩缩容行为有完全控制权。
AgentCore runtime版运行同一份healthcare_agentcore.py代码，只是套上装饰器。容器编排、基于会话的扩缩容、通过IAM集成完成身份管理、以及内置tracing和logging提供的可观测性，都由AgentCore提供。
博客称两种方式各有优势：ECS+Fargate适合已有容器运维经验或有特定基础设施要求的团队；AgentCore runtime适合偏好托管基础设施、希望把精力放在Agent逻辑上的团队。
- 装饰器三段式：BedrockAgentCoreApp初始化应用，@app.entrypoint标注请求到达时调用的函数，app.run() 启动AgentCore runtime服务器
- 装饰器与return之间的Agent代码与独立版保持一致
- AgentCore runtime支持bring-your-own（BYO）Agent，现有Agent代码无需改写或适配特定框架
- 博客强调AgentCore runtime与模型无关：上一篇文章用Anthropic的Claude 3.5 Sonnet V2，本篇改用Meta的Llama 3.1 70B Instruct，模型选择属于实现决策而非硬性要求
三后端如何分工，以及迁移的前置条件
该样本通过model_type参数把查询路由到合适的后端。专业生物医学查询走SageMaker AI上带托管自动扩缩容的BioM-ELECTRA-Large-SQuAD2；复杂的医学推理走Amazon Bedrock上的Llama 3.1 70B Instruct；容器化模型服务器用于自托管部署和从Hugging Face Hub集成工具，可部署在Amazon ECS、Amazon Elastic Kubernetes Service或其他容器环境。三个后端都实现Hugging Face Messages API兼容，请求和响应格式一致。
前置条件包括：具备AgentCore runtime访问权限并能创建IAM角色和OpenSearch域的AWS账户；AWS CLI 2.0或更高版本；Node.js 20或更高版本（部署CLI所需）；AWS CDK；AgentCore CLI；Python 3.10或更高版本；Docker运行中（代码执行隔离所需）；AWS区域内对Amazon Bedrock模型、Amazon SageMaker AI和Amazon OpenSearch Service域的访问权限及相应IAM权限；bedrock-agentcore Python SDK。实现使用Python 3.10+、smolagents、transformers 4.55.0+和boto3。
- 创建项目：npm install -g @aws/agentcore后执行agentcore create --project-name healthcareagent --no-agent --build Container --language Python --protocol HTTP --model-provider Bedrock --memory none
- 添加自有Agent：agentcore add agent --name healthcare_agentcore --type byo --build Container --language Python --protocol HTTP --network-mode PUBLIC --code-location ./agent-code --entrypoint healthcare_agentcore.py --framework Strands --model-provider Bedrock
- 博客说明 --framework只指定CLI模板，实际代码用的是Hugging Face smolagents，与模板选择无关
- 容器镜像需控制在 2 GB以内，博客建议用 .dockerignore排除venv、.git、__pycache__、*.pyc等目录和文件
- 测试方式有两种：agentcore invoke --prompt用CLI调用；或用boto3的invoke_agent_runtime以agentRuntimeArn、contentType、payload编程调用
- 清理资源：先用agentcore remove all移除本地配置，再agentcore deploy拆除AWS资源；另有删除SageMaker端点和OpenSearch域的命令