把 OpenClaw 搬进公司：一个运维的企业级部署实战

这是「AI运维实验室」的第二篇文章。上一篇聊了养虾社 Meetup 的见闻，这一篇讲讲我自己的实践——怎么把 OpenClaw 部署到公司的 AWS 环境里，让业务团队用自然语言查数据。

起因：业务天天找研发查数据

我们公司做海外互联网产品，业务团队经常需要查各种运营数据——用户信息、行为记录、注册时间之类的。每次都要找研发写 SQL，研发烦，业务也等得急。

有一天开会，研发提了一个想法：能不能搭一个 AI 平台，让业务自己用自然语言描述需求，系统自动返回结果？

OpenClaw + MCP 刚好能做这件事。

架构：两个 VPC，一道墙

方案不复杂，但安全必须到位。

┌──────────────────────────────┐
│     OpenClaw VPC             │
│                              │
│  OpenClaw ──► Kiro CLI       │
│  (Web Chat)   (代码生成)      │
│                              │
└──────────┬───────────────────┘
           │ 公网隔离，IP 白名单
           ▼
┌──────────────────────────────┐
│     业务 VPC                  │
│                              │
│  API Gateway ──► MCP Server  │
│                  → 数据库     │
└──────────────────────────────┘

两个 VPC 完全隔离，不做 VPC Peering。OpenClaw 通过公网调用业务侧的 MCP 接口，但只允许 OpenClaw 的固定 IP 访问。业务人员通过 VPN 访问 OpenClaw 的 Web 界面。

工作流分两个阶段：

搭建阶段：业务提需求 → OpenClaw 对话 → Kiro 写代码 → 生成查询页面 → 研发 Review → 上线
日常使用：业务人员打开页面 → 输入参数 → MCP 接口查数据库 → 返回脱敏结果

运维做了什么

说实话，OpenClaw 本身的安装不难，难的是把它安全地跑在企业环境里。我做的事情：

基础设施

一台 EC2（t3.medium，2C4G），Amazon Linux 2023
EBS 加密，IMDSv2 强制（防 SSRF）
ALB + ACM 证书，TLS 1.3
域名通过内部 DNS 解析

网络安全

SSH 只允许堡垒机访问，不开公网 22 端口
HTTPS 只允许 VPN IP 白名单
安全组最小权限，入站只开必要端口
VPC Flow Logs 开启，记录所有网络流量

访问控制

通过堡垒机堡垒机管理，MFA 认证
研发按需授权，不给 root 权限
IAM 使用 Instance Profile，不在机器上放 AK/SK

备份和恢复

每周自动快照，保留 35 天
EC2 Auto Recovery 开启，实例故障自动恢复
CloudWatch 监控 CPU/内存/磁盘，异常告警推钉钉

这些东西加起来，比装 OpenClaw 本身花的时间多 5 倍。但这就是企业级部署和个人玩具的区别。

安全：不是可选项

AI 工具进企业，安全是第一道门槛。我们在 MCP 接口层做了三件事：

字段白名单

每个查询接口明确定义可返回的字段。白名单之外的字段一律不返回。查用户信息只返回昵称、注册时间、设备类型，不返回密码、token、密钥。

数据脱敏

MCP 接口返回数据前自动脱敏：

手机号中间 4 位打码
邮箱用户名部分打码
身份证中间 11 位打码

脱敏在接口层统一处理，不依赖前端，确保任何调用方式都无法拿到明文。

查询日志全量记录

每次查询记录谁查的、什么时候查的、查了什么参数、返回了什么。日志保留 90 天，支持事后审计。

这三条是硬性要求，MCP 接口上线前必须全部实现。

Token 消耗和用量监控

AI 工具进企业，成本控制是绕不开的话题。

我们的 AI 模型调用采用 AWS Bedrock 和 Kiro 共存的方式——OpenClaw 通过 Bedrock 调用 Claude 模型，日常运维分析和文档生成走 Kiro 订阅。两条链路各司其职，互为备份。但不管走哪条，token 用量都必须监控。

用量监控

Bedrock 的调用量通过 CloudWatch 监控：Invocations（调用次数）、InputTokenCount、OutputTokenCount
设置了日级别的费用告警，超过阈值推钉钉
每周看一次用量趋势，防止某个查询场景意外消耗大量 token

成本优化

简单查询用小模型（Haiku），复杂分析才用大模型（Sonnet）
优化 Prompt，减少不必要的上下文传递
查询结果做缓存，相同参数短时间内不重复调用模型

OpenClaw 安全更新策略

OpenClaw 是开源项目，版本迭代很快。但在企业环境里，不能无脑跟进最新版。

更新原则

不自动更新，每次手动评估 changelog 后再决定是否升级
先在测试环境验证，确认无问题再更新生产
更新前做 AMI 快照，出问题 30 分钟内回滚

Skill 策略：不装第三方，全部自己实现

这是我们的一个重要决策：不从 ClawHub 安装任何第三方 Skill。

原因很简单——第三方 Skill 的代码质量和安全性无法保证，OpenClaw 官方自己都在 GitHub 上标注"may contain suspicious or malicious skills"。在企业环境里，一个恶意 Skill 就可能导致数据泄露。

我们的做法是：所有需要的能力，直接通过 AI 模型本身的能力实现，或者用 Kiro 写自定义脚本。比如需要读写文档，不装 feishu-doc Skill，而是让 Kiro 直接调用飞书 API。这样每一行代码都在我们自己的控制范围内。

多花点时间，换来的是完全可控。

成本：月费 $36

项目	月费
EC2 t3.medium	~$30
EBS 30GB gp3	~$2.5
API Gateway	~$3.5
AI 模型调用	公司已有订阅
合计	~$36

转 Reserved Instance 后可降到 ~$20/月。

$36 一个月，替代了业务找研发查数据的人力成本。以前一个查询需求从提出到拿到结果可能要半天，现在业务自己几分钟搞定。

踩坑和思考

踩坑 1：VPC 隔离方案的选择

一开始考虑过 VPC Peering，让 OpenClaw 直接访问业务数据库。后来否决了——一旦 OpenClaw 被攻破，攻击者就能直接摸到数据库。最终选择公网 + IP 白名单 + API Gateway 的方案，多一层隔离，安全性更高。

踩坑 2：堡垒机权限管理

研发需要 SSH 到 OpenClaw 服务器部署和调试，但不能给太大权限。通过堡垒机做细粒度授权，每个人只能访问自己被授权的资产，所有操作有录像回放。

踩坑 3：监控不能少

AI 工具跑在生产环境，跟其他服务一样需要监控。CPU、内存、磁盘、网络，一个都不能少。我们复用了现有的 CloudWatch → SNS → Lambda → 钉钉的告警链路，没有额外搭建。

一个运维的视角

上一篇文章我说过："AI 工具的落地，20% 是选型和开发，80% 是工程化和运维。"

这次部署 OpenClaw 再次验证了这个判断。OpenClaw 本身很好装，但要让它在企业环境里安全、稳定、可控地运行，需要做的事情远比安装多得多：

网络隔离和访问控制
数据安全和脱敏
备份和灾备
监控和告警
权限管理和审计

这些不是 AI 的事，是运维的事。

会用 OpenClaw 的人越来越多，但能把它安全地部署到企业环境里的人很少。如果你也在做类似的事情，欢迎交流。

关于这个公众号

「AI运维实验室」持续分享 AI 工具在企业中的真实落地经验。不是概念，是踩过的坑和跑通的路。

上一篇：[一个运维去了养虾社北京 Meetup，聊聊我看到的 OpenClaw 生态]

写于 2026 年 3 月，OpenClaw 企业部署完成之后。