夜雨聆风一个专注于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
| 合计 | ~$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 企业部署完成之后。）
养虾社是一个中立、非商业化的 OpenClaw 爱好者社区。
我们记录养虾人的一手经验，不论成功还是踩坑。
如果你也在探索 AI Agent、在了解一人公司、或者想找到养虾同路人一起交流。
欢迎加入养虾社社群，一起进阶为养虾大户~
往期精彩回顾
在人人都能创建AI智能体的时代，我们如何才能避免走向反乌托邦的未来？
养虾社Meetup丨不招人，先招agent：OpenClaw在独立开发中的进阶之路
养虾社 Meetup｜零代码创业实录：用 6 个 Agent 替代 15 人团队开发了AI塔罗牌应用
养虾社｜曲凯、东旭、之浩、文锋关于 OpenClaw、Agent 与未来组织的深度对话
