企业级虾方案：我们如何在 EKS 上给全公司每人养了一只 AI 龙虾

从 AWS 官方博客的 Kata Containers 沙箱方案，到最终落地的纯 EKS 架构，踩坑全记录。

---

背景：为什么要给每个人养一只龙虾？

OpenClaw（龙虾）是一个可以自托管的 AI Agent，接入飞书/Slack 后就变成了 7×24 在线的私人 AI 助手——能写代码、查数据、读文档、操作内部工具。

我们的需求很简单：让公司每个人都有一只自己的龙虾，运营用来查数据，开发用来写代码，PM 用来做文档。

问题来了：

• 20+ 人同时用，资源怎么分配？
• AI Agent 有代码执行能力，安全怎么保证？
• 每人每月 Bedrock 调用费用不一样，怎么按人计费和限额？
• 有人离职了怎么一键回收？

一句话：需要一个企业级的多租户 AI Agent 平台。

---

AWS 官方方案：Kata Containers 沙箱

AWS 官方博客「在 Amazon EKS 上部署 OpenClaw AI Agent：基于 Kata Containers 的企业级沙箱实践」给出的方案是：

每个 Agent → 一个 Kata Container → 一个轻量 VM (Firecracker microVM)

核心思路是用 Kata Containers + Firecracker 给每个 Agent 套一层 VM 级别隔离：

• 每个 Agent 跑在独立的微型虚拟机里
• 即使 Agent 执行了恶意代码，也逃不出 VM
• 配合 Agent Sandbox Controller（CRD）做生命周期管理

这个方案的优点：隔离性拉满，安全等级最高，适合对外售卖的 SaaS 平台。

但我们实际落地时遇到了问题：

痛点	说明
节点要求高	Kata 需要裸金属或嵌套虚拟化实例（i3.metal / m5.metal），成本飙升
运维复杂	需要维护 Kata runtime、Firecracker 版本、containerd shim 配置
启动慢	每个 microVM 冷启动 10-20 秒，比普通容器慢 5-10 倍
调试难	出了问题要同时排查 K8s + VM 两层，日志分散
我们是内部用	用户都是自己同事，不需要 VM 级别的防逃逸

结论：杀鸡用了牛刀。

---

最终方案：纯 EKS + 6 层软隔离

我们砍掉了 Kata，回归纯 EKS，用 Kubernetes 原生能力堆出 6 层安全防护：

┌─── 第 1 层：Namespace 隔离 ──────────────────────────┐
│  每人一个独立 namespace（openclaw-张三、openclaw-李四） │
│                                                        │
│  ┌─── 第 2 层：RBAC ────────────────────────────────┐ │
│  │  ServiceAccount 仅允许 get 自己的 pod，啥也干不了   │ │
│  │                                                    │ │
│  │  ┌─── 第 3 层：SA Token 禁挂载 ────────────────┐ │ │
│  │  │  automountServiceAccountToken: false          │ │ │
│  │  │  容器里连 K8s API 的凭证都没有                 │ │ │
│  │  │                                              │ │ │
│  │  │  ┌─── 第 4 层：NetworkPolicy ─────────────┐ │ │ │
│  │  │  │  只允许出站到：LiteLLM + DNS + HTTPS    │ │ │ │
│  │  │  │  内网扫描？不存在的                      │ │ │ │
│  │  │  │                                        │ │ │ │
│  │  │  │  ┌─── 第 5 层：SecurityContext ──────┐ │ │ │ │
│  │  │  │  │  non-root / drop ALL caps /       │ │ │ │ │
│  │  │  │  │  no privilege escalation / seccomp │ │ │ │ │
│  │  │  │  │                                   │ │ │ │ │
│  │  │  │  │  ┌─── 第 6 层：LiteLLM Key ───┐  │ │ │ │ │
│  │  │  │  │  │  独立 API Key + 月度预算上限 │  │ │ │ │ │
│  │  │  │  │  └─────────────────────────────┘  │ │ │ │ │
│  │  │  │  └───────────────────────────────────┘ │ │ │ │
│  │  │  └────────────────────────────────────────┘ │ │ │
│  │  └────────────────────────────────────────────┘ │ │
│  └──────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘

对内部场景来说，这已经够硬了——每只龙虾看不到别人、摸不到集群、连不了内网、提不了权、花不了超额的钱。

---

整体架构

员工 (飞书/Slack) ── WebSocket 长连接（出站，不需要公网入站端口）
        │
        ▼
┌──────────────────── EKS Cluster ────────────────────────┐
│                                                          │
│  openclaw-张三    openclaw-李四    openclaw-王五   ...    │
│  (ns 隔离)       (ns 隔离)       (ns 隔离)              │
│       │               │               │                  │
│       └───────────────┼───────────────┘                  │
│                       ▼                                  │
│           ┌───────────────────┐    ┌──────────────────┐  │
│           │ LiteLLM Proxy     │───▶│ AWS Bedrock      │  │
│           │ 按人分 Key+预算    │    │ Claude Opus/Sonnet│  │
│           └───────────────────┘    └──────────────────┘  │
│           ┌───────────────────┐                          │
│           │ SkillsHub (MCP)   │ ← Grafana/GitLab/       │
│           │ 工具网关+审计      │   Mixpanel/K8s 只读     │
│           └───────────────────┘                          │
│           ┌───────────────────┐                          │
│           │ Prometheus+Grafana │ ← 用量/费用/性能监控    │
│           └───────────────────┘                          │
│                                                          │
│  Core: 2-4× m5.xlarge + Karpenter 自动扩缩              │
└──────────────────────────────────────────────────────────┘

几个关键设计：

1. 飞书/Slack WebSocket 出站连接
龙虾主动连飞书，不需要开公网端口。零入站暴露，NAT Gateway 出去就行。

2. LiteLLM 统一网关
所有模型调用走 LiteLLM，好处：每人独立 API Key、月度预算硬限额、按人统计 token 消耗、OpenAI 兼容接口无缝切模型。

3. SkillsHub MCP 工具平台
龙虾想查 Grafana 图表？调 GitLab API？读 Mixpanel 数据？全走 SkillsHub 网关，API Key 存在网关侧，龙虾 Pod 里没有任何第三方凭证。

4. Karpenter 弹性扩缩
12 人以内复用 Core 节点，0 增量计算成本。人多了 Karpenter 自动开机器，人少了 5 分钟空闲自动回收。

---

一键部署：30 秒养一只龙虾

基础设施用 Terraform 一把梭：

cd openclaw-on-eks/
terraform init && terraform apply

给员工开龙虾，一行命令：

# 运营同学（轻量版）
./deploy-openclaw.sh --name 小明 --tier ops --channel feishu \
  --app-id cli_xxx --app-secret xxx --budget 30

# 开发同学
./deploy-openclaw.sh --name 张三 --tier dev --channel feishu \
  --app-id cli_xxx --app-secret xxx --budget 100

# 高级开发（解锁 Opus 模型）
./deploy-openclaw.sh --name 李四 --tier senior-dev --channel feishu \
  --app-id cli_xxx --app-secret xxx --model claude-opus --budget 200

脚本自动完成 4 步：

1. 生成 LiteLLM 独立 Key（带预算上限）
2. 创建独立 Namespace + RBAC + NetworkPolicy
3. 挂载 EFS 持久存储（重启不丢数据）
4. 拉起 Pod，写入配置，连上飞书

员工离职？

./deploy-openclaw.sh --delete 小明   # 一键回收全部资源

---

四档套餐：按角色分配资源

套餐	适用	CPU	内存	存储	默认模型
ops	运营/PM	0.5 核	2G	10G	Sonnet
dev	开发	2 核	4G	20G	Sonnet
senior-dev	高级开发	4 核	12G	50G	Opus
power	重度用户	8 核	24G	100G	Opus

运营同学日常问问数据、写写文档，ops 套餐绑绑有余。开发同学要跑代码、操作 Git，dev 起步。Power 级别是给那种一天 token 消耗比别人一周还多的狠人准备的。

---

费用：到底要花多少钱？

基础设施固定成本

项目	月费
EKS 控制面	$73
2 台 m5.xlarge	~$280
NAT Gateway	~$55
EBS 存储	~$15
合计	~$423/月

每人增量成本

12 人以内计算增量为 $0（复用 Core 节点），只有存储和模型调用费用：

• 轻度用户（Sonnet，50 万 token/天）：~$33/月
• 中度用户（Sonnet，200 万 token/天）：~$126/月
• 重度 Opus 用户：~$600+/月

算笔账：10 个 dev 级别轻度用户，总成本 ≈ $423 + $330 = $753/月，平均每人 $75/月。比任何 SaaS 订阅都便宜，而且数据全在自己手里。

---

Kata vs 纯 EKS：怎么选？

维度	Kata Containers	纯 EKS（我们的选择）
隔离级别	VM 级（硬隔离）	容器级（软隔离 6 层）
适用场景	对外 SaaS、不可信租户	企业内部、可信员工
节点成本	需要裸金属/嵌套虚拟化，贵	普通 EC2 就行，便宜
冷启动	10-20 秒	2-3 秒
运维复杂度	高（K8s + VM 双层排障）	低（纯 K8s 原生）
安全性	极高	企业内网场景足够

一句话总结：对外卖用 Kata，自己用纯 EKS。

---

踩坑备忘

1. Karpenter NodeClass 的 role 名要对上
Terraform 创建的 IAM Role 名字带随机后缀，EC2NodeClass 里写死了个旧名字就 GG。症状：NodeClaim 卡在 Pending，InstanceProfileReady=Unknown。

2. EFS 首次启动写入配置不覆盖
OpenClaw 首次启动会把 openclaw.json 写到 EFS。之后改了部署参数重启 Pod，配置文件不会更新——因为 EFS 上已经有了。要么手动删文件，要么 --delete 重来。

3. 飞书要开「长连接」订阅方式
飞书开发者后台默认是 Webhook 回调（需要公网 URL），龙虾用的是 WebSocket 长连接模式，需要在后台手动切换，否则消息收不到。

4. LiteLLM port-forward 别忘了
部署脚本要调 LiteLLM API 生成 Key，如果忘了开 port-forward 就会报错。先跑一句：

kubectl port-forward -n litellm svc/litellm 4000:4000 &

5. 占位 Pod 扩容后 5 分钟内必须部署
用占位 Pod 触发 Karpenter 扩容高配节点后，删掉占位 Pod 必须在 5 分钟内把真正的龙虾部署上去，不然 Karpenter 判定节点空闲就自动回收了。

---

写在最后

这套方案跑了一个月，20+ 只龙虾稳定运行。运营同学每天用龙虾查 Mixpanel 数据、写周报；开发同学让龙虾审 PR、查日志、写脚本；PM 让龙虾帮忙做竞品分析。

最大的感受是：AI Agent 的价值不在于单个人用得多深，而在于全公司每个人都能随手用起来。 而要做到这一点，一个稳定、安全、低成本的企业级底座是前提。

如果你也在考虑给团队部署 AI Agent，希望这篇踩坑记能帮到你。

---

参考资料：

• AWS 官方博客：在 Amazon EKS 上部署 OpenClaw AI Agent（Kata Containers 方案）
• AWS 官方博客：基于 Amazon EKS 和 Graviton 构建多租户 AI Agent 平台
• 实际落地代码：openclaw-on-eks（Terraform + deploy 脚本）