亚马逊AWS官方博客
AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第六篇
摘要：基于 AWS 示例项目，展示如何将 OpenClaw 迁移为基于 Amazon Bedrock AgentCore 的多租户 Serverless 架构。全系列 6 篇，涵盖 Replatform 与 Refactor 两种策略。本篇为第六篇：清理资源与总结展望，删除部署资源、迁移前后对比回顾，以及进一步探索方向。
十、清理资源
部署完成后，建议删除所有资源避免持续产生费用。
第一步：删除 AgentCore Runtime
为什么做这一步：先删 Runtime，否则 CDK 删除 AgentCore Stack 时会因为依赖关系失败。
第二步：删除 CDK Stack
为什么做这一步：一次性删除所有 8 个 CDK Stack。会提示确认，输入 y。
部分资源设置了 RETAIN 保留策略（比如 S3 桶、KMS 密钥、DynamoDB 表），为了防止误删数据。删除 Stack 后这些资源会保留下来，需要手动在控制台删除。
第三步：手动删除保留资源
到对应控制台删除：
- Amazon S3：
openclaw-user-files--（先清空再删桶） - Amazon DynamoDB：
openclaw-identity、TokenUsageTable（或对应的生成名） - AWS KMS：
openclaw/secrets别名（注意 KMS 密钥需要排队 7-30 天才真正删除） - Amazon ECR：
openclaw_agent镜像仓库 - AWS Secrets Manager：
openclaw/*下的所有 Secret - Amazon CloudWatch Log Group：
/openclaw/*和/aws/bedrock/*等
十一、总结与展望
回顾整个过程，我们完成了一次典型的 Replatform + Refactor 混合迁移：把 OpenClaw 从一台 VPS 上的单进程应用，改造为基于 Amazon Bedrock AgentCore Runtime 的多租户 Serverless 架构。
迁移前后对比
| 维度 | 迁移前 | 迁移后 | 策略 |
|---|---|---|---|
| 运行环境 | VPS 上运行 openclaw gateway 单进程 |
AgentCore Runtime，Per-Session microVM（按会话微型虚拟机），按需启停 | Replatform |
| 用户隔离 | 所有用户共享进程和文件系统 | 每用户独立 microVM + STS scoped credentials（限制版临时凭证） | Refactor |
| 数据持久化 | 本地 ~/.openclaw/ 目录 |
Amazon S3 + Workspace Sync（工作区同步），按用户前缀隔离 | Refactor |
| 安全 | 应用层自行实现 | Amazon VPC + AWS KMS + Amazon Bedrock Guardrails + AWS STS + AWS Secrets Manager | Replatform |
| 监控 | 本地日志文件 | Amazon CloudWatch Dashboard + Alarm + AWS X-Ray + Token 统计 | Replatform |
| 扩缩容 | 手动扩容 | AgentCore 按会话自动扩缩 | Replatform |
这个项目展示了一种将开源 AI Agent 框架迁移到 AWS 托管服务的参考路径。核心思路是：能用托管服务直接替换的（运行环境、模型调用、安全、监控）走 Replatform，需要重新设计架构的（多租户隔离、数据持久化、消息路由）走 Refactor。这种混合策略在实际迁移中比较常见 — 在关键维度做针对性的改造，同时尽可能复用已有的应用逻辑。
进一步探索
| 方向 | 说明 |
|---|---|
| 接入更多 IM 渠道 | 项目预留了 Slack、Discord、WhatsApp 的 Secret 槽位。Router Lambda 已内置 Slack 的 HMAC 签名验证逻辑，配置 Bot Token 后即可启用 |
| 自定义 Guardrails 规则 | 修改 stacks/guardrails_stack.py 中的过滤规则，适配你的业务场景。比如添加行业特定的主题拒绝规则，或调整 PII 检测的动作（ANONYMIZE vs BLOCK） |
| 迁移已有工作区数据 | 如果你已经在使用 OpenClaw，可以将 ~/.openclaw/ 下的 Markdown 文件（MEMORY.md、USER.md 等）上传到 S3 用户桶对应的前缀下，实现数据迁移 |
| 多区域部署 | 本项目的 CDK 代码和部署脚本支持多区域部署。为每个区域创建独立的工作目录，设置不同的 TARGET_REGION，Dashboard 名称已加区域后缀避免冲突 |
| 成本优化 | 通过 cdk.json 调整 session_idle_timeout（缩短空闲超时减少 microVM 运行时间）、subagent_model_id（子代理用更便宜的模型）、daily_token_budget（设置更严格的预算告警） |
完成！
你已经完成了一次从单机到 Serverless 的 AI Agent 迁移和现代化改造。通过这次实操，你应该了解了：
- 如何用 AWS Migration & Modernization 的 7R 框架分析一个开源项目的迁移策略
- Amazon Bedrock AgentCore Runtime 如何通过 Per-Session microVM 实现多租户隔离
- 如何用 AWS CDK 编排复杂的多 Stack 基础设施，实现基础设施即代码
- Replatform + Refactor 混合策略在实际项目中的应用 — 在关键维度做针对性改造，同时复用已有应用逻辑
- OpenClaw 工作区数据（MEMORY.md、USER.md 等）如何从本地磁盘迁移到 S3 持久化存储
相关资源
- 项目源码（GitHub）
- Amazon Bedrock AgentCore 开发者指南
- AWS 迁移策略（7R）— Prescriptive Guidance
- OpenClaw 开源项目
- OpenClaw 迁移指南（官方文档）
➡️ 下一步行动：
相关产品：
- Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
- Amazon Bedrock AgentCore — 加快代理投入生产的速度
- Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
- Amazon CDK — 基础设施即代码框架
- Amazon KMS — 托管式密钥管理
系列文章：
- 第一篇：为什么要把 OpenClaw 从单机搬到 AWS
- 第二篇：环境准备与代码获取
- 第三篇：Phase 1 — 部署基础设施
- 第四篇：Phase 2 & 3 — 部署 AgentCore Runtime 与业务层
- 第五篇：配置消息渠道与端到端验证
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。
本篇作者
AWS 架构师中心：云端创新的引领者探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用
|
 |
