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

01 七、配置消息渠道

02 八、发送消息验证

03 九、查看监控和日志

04 相关链接

七、配置消息渠道

基础设施和运行时都部署完了，现在需要把 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

脚本会自动：

从 Secrets Manager 读取你刚存的 Token
从 AWS CloudFormation 读取 API Gateway URL
调用 Telegram setWebhook API，把 webhook 指向 {ApiUrl}/webhook/telegram，同时传入 secret_token 用于后续的签名验证
提示你输入 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：创建飞书自建应用

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

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

B2：配置权限

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

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

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

B3：配置事件订阅

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

先开启加密策略：生成 Encrypt Key 和 Verification Token，保存备用（后面要填入 Secrets Manager）
请求地址填入：{API_URL}webhook/feishu（API_URL 从 CloudFormation OpenClawRouter stack 的 ApiUrl 输出获取）
订阅模式选择”将事件发送至开发者服务器”
添加事件：
- 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 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用