亚马逊AWS官方博客

AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第五篇

摘要：基于 AWS 示例项目，展示如何将 OpenClaw 迁移为基于 Amazon Bedrock AgentCore 的多租户 Serverless 架构。全系列 6 篇，涵盖 Replatform 与 Refactor 两种策略。本篇为第五篇：配置消息渠道与端到端验证，配置 Telegram / 飞书 Bot、发送第一条消息、查看监控大盘和日志。

七、配置消息渠道

基础设施和运行时都部署完了，现在需要把 IM 渠道的消息推送接到我们的 Amazon API Gateway 上。这一步对应的是 Refactor 中”消息接入”维度的改造 — 传统 OpenClaw 的 Gateway 直接监听端口，现在改为通过 webhook 回调的方式接入。

本步骤至少选一个渠道配置。

选哪个渠道？Telegram 配置步骤最少；飞书适合国内企业环境但步骤多。本节先讲 Telegram，飞书见后半部分。

选项 A：配置 Telegram

A1：用 BotFather 创建 Telegram Bot

  • 在 Telegram 中搜索 @BotFather（官方账号，带蓝色对勾）并开启对话
  • 发送 /newbot
  • BotFather 提示：请起个显示名字（Name），例如 OpenClaw Demo
  • BotFather 提示：请起个 username，必须以 bot 结尾，全局唯一，例如 my_openclaw_demo_bot
  • 成功后 BotFather 会回复一段包含 Token 的消息，格式类似：

123456789:AAFD39kkdpWt3ywyRZergyOLMaJhac60qc

  • 把这个 Token 复制保存（后面要用）

为什么做这一步：BotFather 是 Telegram 官方的 Bot 管理入口。Token 相当于 Bot 的身份凭证，请像密码一样妥善保管，不要提交到公开代码仓库。

A2：把 Token 存入 AWS Secrets Manager

aws secretsmanager update-secret \
  --secret-id openclaw/channels/telegram \
  --secret-string 'YOUR_BOT_TOKEN' \
  --region $TARGET_REGION

把上面的 YOUR_BOT_TOKEN 替换成 BotFather 给你的真实 Token。

为什么做这一步：在 Phase 1 部署时，openclaw/channels/telegram 这个 Secret 就已经创建了但里面是空占位值，现在把真实 Token 填进去。容器和 Router Lambda 会从 Secrets Manager 读取这个 Token 与 Telegram 通信。这也是迁移中安全维度的改进 — 传统 OpenClaw 把 API 密钥存在本地的 auth-profiles.json 文件里，现在统一由 AWS Secrets Manager 加密管理。

这一步必须在运行 setup-telegram.sh 之前完成，因为脚本会从 Secrets Manager 读取 Token 来注册 webhook。

A3：运行 Telegram 配置脚本

./scripts/setup-telegram.sh

脚本会自动：

  1. 从 Secrets Manager 读取你刚存的 Token
  2. 从 AWS CloudFormation 读取 API Gateway URL
  3. 调用 Telegram setWebhook API，把 webhook 指向 {ApiUrl}/webhook/telegram，同时传入 secret_token 用于后续的签名验证
  4. 提示你输入 Telegram user ID（纯数字，不是 username），自动写入 DynamoDB 白名单

为什么做这一步：如何找到自己的 Telegram user ID？有两种方法：

① 在 Telegram 里搜索 @userinfobot，给它发任意消息，它会回复你的数字 user ID

② 或者先给你的新 Bot 发一条消息（会被系统拒绝，但拒绝消息里会显示你的 user ID）

为什么需要白名单？默认 registration_open=false，只有 DynamoDB 里有 ALLOW#telegram:xxx 记录的用户才能用 Bot。这样你的 Bot 不会被陌生人滥用。后续想加更多用户，用 ./scripts/manage-allowlist.sh add telegram:user_id。

选项 B：配置飞书

B1：创建飞书自建应用

  1. 打开飞书开放平台 https://open.feishu.cn/app（需要企业飞书账号）
  2. 点击”创建企业自建应用”，填写应用名称、描述、图标
  3. 创建后进入应用详情页，在左侧菜单找到”添加应用能力”，添加机器人能力

为什么做这一步：飞书的 Bot 能力挂在”自建应用”下，一个应用可以开启多种能力（机器人、网页应用、小程序等），这里我们只需要机器人。

B2：配置权限

在应用详情页 → 权限管理，添加以下 5 个权限：

  • im:message — 接收用户消息
  • im:message:send_as_bot — 以机器人身份发消息
  • im:message.content:readonly — 读取消息内容
  • im:chat:readonly — 读取群组信息
  • im:resource — 下载图片/文件

为什么做这一步：这些权限是 Bot 能收发消息和处理图片的基础。飞书的权限比较细粒度，需要逐个开启。

B3：配置事件订阅

在应用详情页 → 事件订阅：

  1. 先开启加密策略：生成 Encrypt Key 和 Verification Token，保存备用（后面要填入 Secrets Manager）
  2. 请求地址填入：{API_URL}webhook/feishu（API_URL 从 CloudFormation OpenClawRouter stack 的 ApiUrl 输出获取）
  3. 订阅模式选择”将事件发送至开发者服务器”
  4. 添加事件：
    • im.message.receive_v1（必须）— 接收用户消息
    • im.chat.member.bot.added_v1（推荐）— 机器人被加入群
    • im.chat.member.bot.deleted_v1（推荐）— 机器人被移出群

为什么做这一步：飞书的 webhook 事件是 AES-256-CBC 加密的（需要 Encrypt Key 解密），Verification Token 用来验证请求确实来自飞书。Router Lambda 已经内置了解密和验证逻辑。

B4：发布应用

在应用详情页 → 版本管理与发布，提交发布申请并等待企业管理员审批通过。

重要：没发布的应用只有开发者自己能看到，其他用户在飞书里搜不到你的 Bot。必须发布后才能实际使用。

B5：运行飞书配置脚本

./scripts/setup-feishu.sh

脚本会交互式提示你输入 4 个凭证（都能在飞书开发者后台找到）：

  • App ID：凭证与基础信息 → App ID
  • App Secret：凭证与基础信息 → App Secret
  • Verification Token：事件订阅 → 加密策略
  • Encrypt Key：事件订阅 → 加密策略

然后脚本会：

  • 把 4 个凭证以 JSON 格式存入 Secrets Manager（openclaw/channels/feishu）
  • 提示你输入自己的飞书 open_id（格式 ou_xxxxxxxx），加入白名单

为什么做这一步：如何找到自己的 open_id？先给 Bot 发一条消息，因为你还没在白名单里，系统会拒绝并在日志里记录你的 open_id，可以去 CloudWatch /openclaw/lambda/router Log Group 查看。

八、发送消息验证

到这一步，整个迁移改造已经完成。现在来验证端到端的消息链路是否打通。下面的时序图展示了一条消息从用户发出到 AI 回复的完整旅程 — 这也是迁移后架构的实际运行路径：

[图1]

容器内部：microVM 里的三个进程

上面的时序图把容器简化为一个节点。实际上每个 microVM 内部运行着三个进程，各司其职：

[图2]
进程 角色 职责
Contract Server 管家 microVM 的入口进程。负责健康检查（/ping）、请求路由（/invocations）、工作区同步（S3 ↔ 本地）、STS 限制版凭证管理（每 45 分钟刷新）。OpenClaw 启动前，由内置的 Lightweight Agent 临时应答
OpenClaw 主力 真正的 AI Agent 进程。启动后接管所有用户请求，执行 17 个内置工具和 5 个预装社区技能
Bedrock Proxy 翻译官 OpenClaw 原生使用 OpenAI 格式的 API 调用，Proxy 将其转换为 Amazon Bedrock ConverseStream API 格式，同时注入 Guardrails 配置

第一步：给 Bot 发送第一条消息

在 Telegram 中找到你的 Bot，发送：

你好，介绍一下你自己

为什么做这一步：第一条消息会触发冷启动：AgentCore Runtime 为你的会话创建一个新的 microVM，大约 10-15 秒后由 Lightweight Agent 先响应。后续消息不需要重新创建 microVM，响应速度取决于 AI 回复的复杂度（简单问题几秒，复杂问题可能十几秒）。

第二步：测试常用功能

发送什么 测试什么能力 涉及的迁移改造点
“帮我搜一下今天北京天气” web_search 工具（NAT Gateway 出网） 网络架构（VPC + NAT）
发一张图片并问”这是什么” 图片上传 + Bedrock 多模态 S3 存储 + 模型调用 Replatform
“帮我把这段文字存到 notes.md” write_user_file 工具（S3 用户文件） 数据持久化 Refactor
“列出我的文件” list_user_files 工具 Per-User S3 前缀隔离
“每天早上 8 点提醒我喝水” create_schedule 工具（EventBridge 定时任务） 定时任务 Refactor

为什么做这一步：每种测试对应架构中的一个组件，验证整个迁移链路是否打通。

九、查看监控和日志

监控是 Replatform 带来的直观运维体验提升。迁移后，所有组件的日志、指标、告警都集中在 Amazon CloudWatch 里，通过统一的 Dashboard 即可掌握系统运行状态。

第一步：查看 Router Lambda 日志

去 CloudWatch → Log groups → /openclaw/lambda/router

为什么做这一步：这里能看到每条消息的完整处理过程：webhook 验证、用户查询、调用 AgentCore、响应返回。排错时第一站。

第二步：查看 AgentCore 容器日志

去 CloudWatch → Log groups → 搜 bedrock-agentcore/runtimes/openclaw_agent

为什么做这一步：容器内部的运行日志：Contract Server 启动过程、Proxy 调用 Bedrock、OpenClaw 工具执行等。

第三步：查看用量大盘

去 CloudWatch → Dashboards → OpenClaw-Token-Analytics-

为什么做这一步：看到你刚才对话消耗了多少 Token、估算成本。用量大盘的数据来自 Bedrock 调用日志 → Token Metrics Lambda → DynamoDB + CloudWatch 指标。

第四步：查看 Amazon DynamoDB 数据

去 DynamoDB 控制台 → openclaw-identity 表 → Explore items

为什么做这一步：能看到几种记录：CHANNEL#telegram:xxx（渠道映射）、USER#xxx（用户信息）、SESSION（当前会话）、ALLOW#（白名单）、CRON#（定时任务）。

相关链接

➡️ 下一步行动：

相关产品：

系列文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

丁有冬

亚马逊云科技合作伙伴解决方案架构师，在企业架构设计、咨询服务以及项目管理方面具有丰富的实践经验。目前主要负责 AWS（中国）合作伙伴的方案架构咨询和设计工作，致力于 AWS 云服务在国内的应用推广以及帮助合作伙伴构建更高效的 AWS 云服务解决方案。

徐达

亚马逊云科技资深解决方案架构师，致力于帮助初创企业在亚马逊云平台上实现业务部署。在呼叫中心及网络通信和云计算领域有多年的实践经验，拥有亚马逊云科技多项专业技术认证以及呼叫中心技术相关认证。

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用