【攻略】Loom for AWS使用指南
Loom for AWS是AWS Labs开源的企业级Agent运营平台，把Agent部署、记忆、MCP、A2A、权限、审计、成本与可观测性放进统一控制台。
很多团队已经能做出Agent演示，但真正上线时会连续遇到同一批问题：谁能调用哪些工具，凭证放在哪里，Agent之间怎样协作，执行记录如何审计，成本怎样按Agent统计。
AWS Labs新近开源的Loom for AWS，就是为这批生产问题准备的企业级Agent运营平台。
项目基本信息
- 项目名称：Loom for AWS
- GitHub仓库：awslabs/loom
- 维护方：AWS Labs
- License：Apache License 2.0
- 主要技术栈：FastAPI、SQLAlchemy、boto3、React 18、TypeScript、Vite、Tailwind CSS、AWS SAM、ECS Fargate
- 最近活动：main分支最新可核验提交为2026-07-10，加入通过LiteLLM支持多模型提供商的能力
- Release状态：截至2026-07-14，仓库尚未发布正式Release，部署时应以main分支文档和提交记录为准
Loom建立在Amazon Bedrock AgentCore Runtime和AWS Strands Agents之上，提供统一管理界面。它可以管理Agent、记忆、MCP服务器、A2A Agent、身份与凭证、标签、成本和审批流程。
它解决什么问题
Loom最有价值的不是“帮你再造一个聊天页面”，而是把Agent从代码项目提升为可运营资源。
它支持：
- 部署新Agent，或导入已有AgentCore Runtime Agent
- 通过AgentCore Harness无代码配置托管Agent
- 管理语义记忆、摘要记忆、用户偏好和情景记忆
- 注册MCP服务器并发现工具，支持OAuth2和按角色限制工具
- 注册A2A Agent，读取Agent Card并处理SSE或JSON响应
- 使用Cognito和分组Scope做双维度权限控制
- 为高风险工具动作加入人工审批和审计轨迹
- 统计每次调用的Token与估算成本
- 通过OpenTelemetry与ADOT查看调用链
最新代码还允许单个Agent把模型请求路由到自建LiteLLM代理。平台为每个Agent下发隔离的虚拟密钥，避免把共享主密钥塞进Agent本身。
部署前准备
本地体验至少需要：
- Python 3.11或更高版本
uv依赖管理工具- Node.js 18或更高版本及npm
- 已配置凭证的AWS CLI
- AWS SAM CLI
- Docker或Podman
如果继续部署到AWS，还要准备VPC、公私有子网、SAM制品S3桶、日志S3桶、Route 53域名，以及可用的Amazon Bedrock与AgentCore权限。
第一步：克隆并复制配置模板
git clone https://github.com/awslabs/loom.git\ncd loom\n\ncp backend/etc/environment.sh.example backend/etc/environment.sh\ncp frontend/etc/environment.sh.example frontend/etc/environment.sh\ncp shared/etc/common.sh.example shared/etc/common.sh\ncp shared/etc/environment.sh.example shared/etc/environment.sh\ntouch shared/etc/outputs.sh核心配置集中在shared/etc/common.sh。至少要填写AWS Profile、Region、Account ID、S3桶、VPC与子网、公开域名、Cognito名称和数据库密码。
需要重点保护的配置包括：
RDS_PASSWORDSUPER_ADMIN_PASSWORD- 演示用户密码
- LiteLLM Master Key
- 第三方OIDC客户端密钥
这些值不应提交到Git仓库，也不要直接复制进Agent提示词或前端代码。
第二步：先跑本地阶段
官方建议从“本地前后端+SQLite+Cognito”开始。这样既能测试真实身份流程，又不必先部署完整计算基础设施。
先部署Cognito：
cd shared\nmake cognito\nmake outputs\nmake cognito.set-passwords启动后端：
cd backend\nuv venv .venv\nsource .venv/bin/activate\nmake install\nmake run后端默认使用sqlite:///./loom.db，并监听本机8000端口。
启动前端：
cd frontend\nmake install\nmake dev浏览器打开http://localhost:5173，使用前面配置的Cognito用户登录。
Windows用户需要注意，官方命令以类Unix Shell为例。PowerShell下激活虚拟环境的方式不同，或者可直接通过WSL运行部署脚本。
第三步：按三阶段逐步上云
Loom把部署拆成三个阶段：
- 本地阶段：SQLite、本地前后端、云端Cognito。
- 混合阶段：数据库切到Amazon RDS PostgreSQL，本地后端通过SSM隧道访问。
- 完整阶段：前端、后端和数据库全部部署到AWS，运行在ECS Fargate与Application Load Balancer之后。
混合阶段适合先验证多人共享数据和迁移；完整阶段则需要继续部署Route 53、ACM、ECR、ECS、RDS、IAM与负载均衡。官方估计端到端部署约35分钟，其中RDS约占25分钟。
一个适合企业的试用顺序
不要一上来把所有Agent和系统接入Loom。可以先选一个只读场景，例如：
- 注册一个内部知识库MCP服务器。
- 创建一个只允许读取指定工具的测试Agent。
- 用Cognito分组区分管理员与普通用户。
- 打开调用追踪和成本统计。
- 给一个高风险工具设置人工审批。
- 通过审计记录复盘权限是否过宽。
这条路径能同时验证Loom最核心的价值：Agent是否真正可管、可查、可控。
常见坑
第一，AWS资源前置条件较多。完整部署不是一个docker compose up就能完成的轻量工具，需要熟悉VPC、IAM、Cognito、SAM、ECS和RDS。
第二，仓库仍处于早期阶段。没有正式Release，也没有服务等级承诺，生产使用前必须自己完成依赖审计、安全评估和版本锁定。
第三，权限模型需要先设计。Loom同时使用类型组和资源组，若团队不先定义角色与Scope，后续会很容易把权限配宽。
第四，SSM隧道依赖VPC Endpoint与安全组。官方特别提醒，ssm、ssmmessages和ec2messages端点缺失，或443入站规则错误，都会导致TargetNotConnected。
第五，云成本不会因为使用开源平台自动消失。RDS、NAT Gateway、ALB、ECS、日志和模型调用都要单独核算。
适合谁，不适合谁
适合：
- 已在AWS上运行企业AI应用的团队
- 需要统一管理多个Agent、MCP和A2A集成的团队
- 对身份、权限、成本、追踪和人工审批有明确要求的企业
- 希望基于开源项目二次开发Agent控制台的技术团队
不太适合：
- 只想快速做一个本地聊天机器人的个人用户
- 没有AWS运维经验、也不准备投入云基础设施的团队
- 仍处于单Agent概念验证阶段的小项目
- 要求厂商提供明确SLA和长期商业支持的关键生产系统
地呱碰实践建议
对做企业数字化、AI应用开发和门店运营系统的团队，Loom最值得借鉴的是“控制面”思路：模型和Agent可以更换，但身份、工具权限、人工确认、成本和审计必须稳定存在。
即使不直接采用Loom，也可以把这五类能力加入自己的企业Agent方案：资源目录、最小权限、审批链、成本账和执行轨迹。