多模型 agent 最麻煩的地方，往往不是模型本身，而是模型外面那一圈東西。三個推論後端、各自的擴縮策略、IAM 身分、日誌與追蹤，全部要自己接起來。團隊花在基礎設施的時間，很容易超過寫 agent 邏輯的時間。
AWS Machine Learning Blog 在 2026 年 9 月 18 日發佈了一篇遷移教學，把先前那個跑在 Amazon ECS 加 AWS Fargate 上的多模型醫療 agent，搬進 Amazon Bedrock AgentCore runtime。這篇的重點不是新模型，而是「同一份 agent 邏輯，換一層執行環境」之後，哪些東西不用再自己管。
搬過去的其實只有一層裝飾器
依 AWS 的說明，AgentCore runtime 是 AgentCore 的受管部署能力，負責容器生命週期、擴縮、身分與可觀測性。遷移後的 agent 仍然在同一個受管容器裡跑，三後端編排與向量檢索都保留。
程式碼層面的改動很小。用 BedrockAgentCoreApp 初始化應用，把入口函式掛上 @app.entrypoint，最後呼叫 app.run()。AWS 明確指出，裝飾器與 return 之間那段 agent 邏輯，跟獨立版本相比沒有改動。
from bedrock_agentcore.runtime import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
@app.entrypoint
def healthcare_agent_entrypoint(payload):
user_input = payload.get("prompt", "")
model_type = payload.get("model_type", "sagemaker")
agent = TripleHealthcareAgent(vector_store=vector_store)
return str(agent.run(user_input, model_type=model_type))
if __name__ == "__main__":
app.run()專案用 AgentCore CLI 建立，再用 agentcore add agent --type byo 把既有程式碼以 bring-your-own 方式掛進去。容器則靠 pyproject.toml 與 Dockerfile 定義依賴，包含 smolagents、transformers、boto3、opensearch-py 與 bedrock-agentcore。
三個後端，換掉一個模型不算換架構
原本的獨立版本用 Claude 3.5 Sonnet V2。遷移後改用 Meta 的 Llama 3.1 70B Instruct 負責較廣的醫療推理，BioM-ELECTRA-Large-SQuAD2 走 Amazon SageMaker AI 處理專門的生物醫學查詢，另外還有一個容器化的模型伺服器。三個後端都實作 Hugging Face Messages API 相容格式，所以請求與回應的形狀一致。
AWS 特別註明，模型選擇是實作決定，不是硬性要求，這正好用來示範 AgentCore runtime 與模型無關。對產品團隊來說，這代表模型替換與執行環境的決策可以拆開來談：想換模型，不必連部署方式一起重寫。
這篇沒有回答的問題
有幾件事值得先寫進自己的檢查清單。
第一，這是 sample implementation，AWS 自己標明僅供示範。處理醫療或敏感查詢的正式部署，標準做法是加上 Amazon Bedrock Guardrails 做內容過濾與 grounding 驗證。教學裡沒有涵蓋這一段。
第二，遷移教學只走到容器準備那一步就結束在供給的內容裡，後續的部署與驗證流程，供給的內容沒有交代。
第三，成本。受管 runtime 省下的是維運人力，不等於省錢；多模型 agent 的帳單本來就分散在多個推論後端，這篇沒有給出成本對照。如果你正在為這類工作流算帳，可以參考我們先前談 Kimi K3 放進 Bedrock 之後長脈絡工作流的成本與資料邊界，那裡處理的是同一個生態系裡的計價與資料落地問題。
什麼時候值得搬
如果你的 agent 已經穩定，痛點集中在擴縮、身分與可觀測性，而且你不想被特定框架綁住，這種「只換執行層、不動 agent 邏輯」的遷移路徑就值得評估。反過來說，如果 agent 還在頻繁改架構，先別急著搬，因為搬過去省下的是維運，不是設計時間。
實務上的第一步很單純：確認你的 agent 入口能不能收斂成一個吃 payload、回傳結果的函式。可以，遷移就只是包一層裝飾器；不行，那才是真正要動工的地方。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。