企业搭建内部通用 AI Agent 平台隔离只是第一步。原文用 Amazon EKS Kata Container 给每个 Agent Pod 独立 microVM安全有了边界可 Hermes、OpenClaw 这些运行时真正干活时还得向大模型发请求这一层我用 TaoToken 统一收口先在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key再把 Base URL 填成 https://taotoken.net/api模型调用就都被收进同一条链路。这里要说明边界TaoToken 不改变 EKS 的调度逻辑也不负责 Kata 的 microVM 隔离它只解决沙箱内 Agent 的模型调用接入问题。把「Agent 跑在哪里」和「Agent 调谁拿结果」拆成两个独立问题后平台的安全架构可以继续沿用 AWS 峰会里的单集群双节点组方案模型出口则由同一把 Key 管住。1. Kata Nodes 把 Pod 隔离好了模型请求却缺一个统一出口1.1 普通容器共享内核Kata 用 microVM 兜底企业内部 AI Agent 与常规 Web 服务最大的不同是它真的会动手。能执行用户粘贴的代码片段、能装 Python 包、能读写文件系统甚至能在沙箱里自我迭代。这样灵活的行为放进普通容器所有 Pod 共用宿主机内核任何一个 Agent 执行了越界指令影响范围就可能从自身 Pod 扩散到同节点其他租户。Kata Containers 的思路是给每个 Pod 套一层 microVM内核隔离由虚拟化层承担既保留容器镜像交付的轻量又把共享内核的风险挡在门外。EKS 上只需把 Kata Nodes 节点组的 RuntimeClass 指到 Kata 运行时Pod 调度过去后看到的是一台独立虚拟机感知不到兄弟 Pod 的存在。1.2 但 Agent 要干活模型调用通道不能各配各的microVM 解决的是「能安全地跑」没解决「跑起来后往哪发请求」。Hermes、OpenClaw 在 Kata Pod 里执行任务时每一步推理都要把上下文发给模型服务。现实是团队往往同时维护多家供应商账号有的 Agent 走 A 家的 OpenAI 兼容接口有的走 B 家的 Anthropic 接口Key 散落在不同 Secret、不同环境变量里。平台规模一上去运维最先崩溃的不是隔离而是「这次任务到底用了谁的 Key、花了多少钱」根本说不清。1.3 TaoToken 在这里只做兼容入口把模型调用收敛到 TaoToken 后情况变成无论沙箱里跑的是 Hermes 还是 OpenClawBase URL 都填 https://taotoken.net/apiKey 统一用从前面官网创建好的那一把。它不碰核心调度不碰 Kata 运行时只做统一 API 兼容通道上游参数差异被它接住Agent 侧永远只面对一套 OpenAI 风格接口。这样运维团队不用为了新增一个 Agent 运行时再去申请一遍各家供应商的密钥。2. 单集群双节点组Core Nodes 和 Kata Nodes 的模型出口怎么接2.1 Core Nodes 上LiteLLM 的 upstream 换成 TaoToken原文架构里Core Nodes 控制面放着 LiteLLM、Prometheus、Grafana 和 CoreDNS。LiteLLM 原本是模型访问入口负责资源配额分发。接入 TaoToken 时不需要推翻这套设计只要把 LiteLLM 的上游地址从各家供应商改成 TaoToken。Agent 侧仍然把请求发给 LiteLLMLiteLLM 统一鉴权、统一限流再由它路由到 https://taotoken.net/api。这一步对业务 Pod 完全透明沙箱内 Agent 不会感知上游变化。2.2 Kata Nodes 上Hermes 与 OpenClaw 共用同一套环境变量不是所有 Agent 都愿意绕一道 LiteLLM。很多运行时直接支持 OpenAI 兼容环境变量那么就可以在 Kata Nodes 的 Pod 模板里注入 OPENAI_BASE_URL 和 OPENAI_API_KEY。这个方案更轻改动更少适合 Agent 数量不多、各跑各的团队。缺点是配额管理要依赖 TaoToken 控制台来做少了 LiteLLM 这层本地限流。两者选哪个取决于团队是否需要在前置层做更细的租户配额。2.3 可复制配置LiteLLM config.yaml 与 K8s Secret先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 API Key然后按下面的方式把 Key 落到配置里。model_list: - model_name: YOUR_MODEL_ID litellm_params: model: openai/YOUR_MODEL_ID api_base: https://taotoken.net/api api_key: YOUR_API_KEY上面 api_base 是给 LiteLLM 用的不能加 /v1也不能带 UTM。模型 ID 以 TaoToken 模型广场显示为准不要凭记忆填一个看似合理的名称模型广场里是什么 IDconfig.yaml 就填什么。如果 LiteLLM 侧还想保留多个模型入口可以在 model_list 里继续追加条目每一条的 api_base 都用同一个 https://taotoken.net/apiKey 也复用同一把。如果 Agent 直接走环境变量用 Secret 注入apiVersion: v1 kind: Secret metadata: name: taotoken-credential type: Opaque stringData: OPENAI_BASE_URL: https://taotoken.net/api OPENAI_API_KEY: YOUR_API_KEY不少 OpenAI 兼容的 Agent 运行时会读取这两个变量如果你的 Agent 框架用自定义配置文件通常也有等效的 base_url 与 api_key 字段填入同样内容即可。注意有些镜像内部会偷偷在 base_url 后面拼 /v1如果控制台看到请求全部 404优先检查这层拼接而不是怀疑 Key 失效。2.4 Base URL 的两种写法别混用注册、创建 Key、看用量走前面提到的落地页嘴LiteLLM、Agent、curl 里填的是 https://taotoken.net/api。把落地页链接填进 api_base程序会拿到 HTML 而不是 JSON把 /v1 拼在 api 后头路由匹配不上返回 404。所以配置字段和人工访问的地址要分清这是接入阶段最容易忽略的细节。3. 网络链路NLB 入站、Webhook 回调、沙箱出站到 TaoToken3.1 WebSocket 与 Webhook 的入口逻辑保持分开原文专门强调 WebSocket 和 Webhook 不能混用。前者由 Agent 主动外连到飞书、Slack、Telegram无需为单个 Agent 开公网入站后者需要外部平台回调触发必须配 ALB Ingress、TLS 证书和标准化入口。这个设计原则与模型出口无关接入 TaoToken 后不需要改。Agent 的模型请求是出站方向走 WebSocket 那套「默认拒绝入站、按需放行出站」的策略最合适。改造后的流量路径是 NLB → Kata Pods → LiteLLM → TaoToken 统一 API上游模型供应商在 TaoToken 这一侧被屏蔽Kata 沙箱内 Agent 感知不到差异。3.2 沙箱出站白名单要放行 TaoToken 域名Kata Pod 发起模型请求时请求目的地是 https://taotoken.net/api对应主机名 taotoken.net。如果集群出站安全组或 NetworkPolicy 做了域名白名单要确保 443 端口能到达 taotoken.net否则 Agent 会一直卡在等待响应。最容易踩的坑是安全组只放行了 Bedrock 或原有供应商域名换了统一入口后忘记加新域名现象就是任务超时、Pod 日志里全是连接失败。原文部署建议还提到Kata 节点的网络链路需要提前完成 Amazon VPC CNI 测试适配生产环境优先用内部 NLB不要直接走默认 ClusterIP 链路。模型请求出站与入站流量是两条路径建议在测试环境先把出站到 taotoken.net 的通路验证清楚再合并业务流量。3.3 两个真实出现的报错排查接入过程中最常见的两个报错按出现频率排connect timeout / connection refused先检查出站白名单再检查 Pod 内 DNS 能否解析 taotoken.net。Kata Pod 的 DNS 配置走 CoreDNS如果 CoreDNS 上游有问题也会表现为超时。可以先在 Pod 里 nslookup taotoken.net 确认解析是否正常。401 Unauthorized确认 API Key 是否正确特别留意 Secret 里是否带了换行或空格。其次是确认 Key 确实是在前面落地页创建的那把而不是从其他环境拷贝过来的。401 的排查路径比 404 简单基本都落在 Key 本身。4. 在控制台核对 Agent 的真实 Token 消耗4.1 先用 curl 验证最小调用配置完不要急着跑完整 Agent 任务先在 Kata Pod 里用 curl 打一次curl https://taotoken.net/api/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d {model:YOUR_MODEL_ID,messages:[{role:user,content:ping}]}记得把 YOUR_MODEL_ID 换成模型广场展示的 IDYOUR_API_KEY 换成刚才创建的 Key。如果返回带 choices 的 JSON说明配置链路通。这里不要加 /v1不要加任何 UTM 参数curl 只用 API 地址。4.2 打开控制台看这次请求是否记账curl 通了之后回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 控制台找到用量页面应该能看到刚才这次请求对应的模型、Token 数和时间。若显示空记录说明请求实际没有走到 TaoToken重点回头查 Base URL 有没有被 Agent 运行时覆盖或者请求走的还是旧环境变量。这一步是把「沙箱里跑 Agent 任务」和「用量统计」闭环起来的关键动作。4.3 什么样的团队适合这套组合原文的判断依然成立已经落地 EKS、有专职 Kubernetes 运维、需要给多个业务部门统一提供 Agent、对代码执行和文件读写隔离要求高的团队适合这套 EKS Kata 组合。反之如果只是少量固定 Agent、没有专职运维先别急着复刻整套双节点组架构用 TaoToken 统一模型调用通道就能解决大部分问题等 Agent 数量多到必须做隔离时再补 Kata 也不迟。TaoToken 这层不挑运行环境裸机、虚拟机、K8s 都能用迁移成本很低。5. 回到官网创建 Key把刚才的 Agent 任务完整跑一遍5.1 创建 API Key打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 完成注册在 API Key 页面创建名为 agent-kata 的密钥。创建后立刻复制保存Key 明文只在创建页面展示一次。把 Key 填到 LiteLLM config.yaml 或 K8s Secret 后不要在镜像里硬编码也不要提交到 Git。泄漏后可以回到同一页面吊销重建不影响其他配置。5.2 重新部署并观察一次完整任务改完配置后滚动重启 Kata Nodes 上的 Agent Deployment等 Pod 就绪再跑一次 Hermes 或 OpenClaw 的真实任务。任务跑完后回控制台用量页对比 Token 记录与任务日志里的请求次数。这一步验证的是端到端链路Kata Node 发起请求、TaoToken 鉴权、上游模型返回、Token 记账四个环节全部正常才算真正接完。5.3 后续维护建议新增模型时先到模型广场确认 ID再改 LiteLLM 的 model_list新增 Agent 运行时直接复用同一套 Key 和 Base URL不用再找供应商申请。如果团队后来把节点组拆分到多个账号或区域只要出站能到达 taotoken.net这套配置可以整套平移。原文的 EKS 架构继续按它自己的节奏演进模型调用这层交给 TaoToken 统一维护两边互不干扰。