AWS Loom 管理企業 AI Agent
AWS 開源的 Loom 不是新的託管服務，而是一套企業級 AI Agent 平台參考實作。它用 Strands Agents SDK 建立 Agent，部署在 Amazon Bedrock AgentCore Runtime，並透過 RFC 8693 token exchange，把使用者與 Agent 身分沿著 Agent、MCP Server、API 的呼叫鏈一路傳遞。平台實際涵蓋 Agent 部署、權限、記憶、MCP、A2A、資源標籤、人工審核與目錄管理，重點是讓企業不用每個團隊各自拼一套治理機制。
現實應用
Loom 適合已有多個 Agent 專案、又必須處理內部資料權限的企業。例如財務 Agent 查報表、客服 Agent 讀客戶紀錄，或工程 Agent 呼叫內部 API 時，下游系統仍可依原始使用者權限決定能看到什麼。平台團隊也能用同一份預先審查過的 Python Agent 程式，靠設定注入行為規則、Memory、MCP 與 A2A 連線，減少各團隊自行產生 runtime code 的風險。
期望評估
我認為低標期望，是把 Loom 當成架構範本，直接參考它的 delegated identity、強制標籤、角色加群組權限，以及敏感工具執行前的人工作業流程；即使最後不採用整套平台，也能少踩不少治理坑。
高標期望則是企業以它為底稿，加入既有 SSO、稽核、成本中心與部署管線，做成內部 Agent Platform。我猜真正價值不在聊天介面，而是讓 Agent 從實驗進入正式環境時，有一致的上架、探索、授權與審批規則。
商業策略分析
受影響最大的會是企業平台工程團隊、AI 治理產品，以及自行整合 Agent 基礎設施的顧問商。Loom 免費且開源，但底層 Bedrock AgentCore、Secrets Manager、API Gateway 等 AWS 服務仍會產生成本，因此它同時也是 AWS 擴大 Agent 工作負載黏著度的入口。
我認為正在 AWS 上做多 Agent 專案的團隊值得跟進；若只有一兩個內部 PoC，整套導入可能太重。它目前仍是 AWS Labs 的參考實作，不等於具正式支援承諾的產品，採用前要先估維護責任與供應商綁定。
實作細節
程式碼、架構規格、部署與清理說明都放在 AWS Labs GitHub repository，可依 deployment guide 建立測試環境。部署採 config-driven 模式，Secrets 不存於 Loom，而由 AWS Secrets Manager 在需要時取用。已知限制包括 AWS Agent Registry 尚在 public preview，Registry ARN 不含可辨識名稱，部分 IAM policy 因此得使用 wildcard；角色權限介面也仍看得出示範用途的 scaffolding。