场景：你的 AI Agent 上线后缺乏观测和管控？CLRK 用 gVisor 沙箱 + 透明代理提供 K8s 原生治理
当你把 AI 编码 Agent 从开发环境推向生产时，一个棘手的问题马上浮现：Agent 内部在调用哪些 API？触发了什么工具？有没有泄露凭据的风险？传统容器编排（Kubernetes）并不感知 Agent 的工作负载特征——它管不了哪个 Agent 访问了哪个 LLM 端点、调用了什么 MCP 服务。
CLRK 正是为了解决这个痛点而生的开源项目。它是一个 Kubernetes 原生的 LLM Agent 运行时，将每个 Agent 运行在 gVisor 沙箱中，并通过透明代理拦截所有出口流量——包括 LLM API 调用、MCP 服务请求、工具调用——全部无需修改 Agent 代码。本文将带你了解 CLRK 的架构设计、核心能力，以及如何在本地快速体验。
问题：生产环境中的 Agent 管控空白
Kubernetes 提供了 Pod 级别的资源隔离和网络策略，但对于 AI Agent 的工作负载存在几个空白：
- 观测盲区：Agent 调用了哪些 LLM 服务？每次调用的延迟和 Token 消耗是多少？传统容器看不到 Agent 内部的数据流
- 治理缺失：无法阻止 Agent 连接到未经授权的外部服务，也无法在执行违反组织策略的操作前拦截
- 凭据风险：API Key 存储在 Pod 的环境变量或挂载文件中——一旦沙箱被攻破，凭据立即泄露
CLRK 的核心理念是：在 Agent 的网络和进程边界进行拦截，而非要求 Agent 使用特定的框架或 SDK。
CLRK 架构概览
CLRK 由三个主要组件构成：
- controller-manager：控制平面，运行 Kubernetes controller-runtime 协调器，管理自定义资源（CRD）并内置 Web UI 仪表盘
- worker：沙箱节点，通过 gVisor/
runsc管理 Agent 沙箱生命周期，配置每个沙箱的网络拦截 - CLI（
clrk）：运维和开发者命令行工具
出口拦截的核心机制
Agent 在 gVisor 沙箱中运行，所有出口流量（包括 TLS 加密的连接）都经过一个 Envoy 代理——EgressGateway。这个代理执行三项关键操作：
- TLS 终止（MITM）：解密 Agent 的出口流量，使得平台能看到 LLM 请求的内容
- 凭据注入：API Key 在请求时由代理注入，Agent 本身从不持有凭据
- 策略执行：通过
EgressL4Route、MCPRoute、AIProviderRoute等 CRD 控制 Agent 能连接哪里
所有拦截的流量都被记录为 Invocation 记录，存储在 ClickHouse 中，可通过 /logs 和 /traces 端点查询，也可通过 OpenTelemetry 导出。
安装与快速启动
CLRK 最友好的地方在于：你不需要一个正式的 Kubernetes 集群就能开始使用。
git clone https://github.com/apoxy-dev/clrk.git cd clrk && go build ./cmd/clrk clrk dev
clrk dev 会启动一个本地集群和开发循环，包含所有组件。生产部署使用 clrk install / clrk upgrade 安装到正式 K8s 集群。
声明式 Agent 定义
Agent 通过 Kubernetes CRD 声明式定义。CLRK 支持两种 Agent 类型：
TaskAgent：短任务型
适合由 HTTP 请求或定时任务触发的”运行即结束”场景：
apiVersion: clrk.apoxy.dev/v1alpha1
kind: TaskAgent
metadata:
name: cron-bot
spec:
# 每分钟触发一次
schedule: "*/1 * * * *"
scheduleInput: '{"task": "check-status"}'
image: my-registry/cron-bot:latest
egressPolicy:
allowedDomains:
- "api.example.com"
DaemonAgent：长期守护型
适合需要持续运行的 Agent 进程：
apiVersion: clrk.apoxy.dev/v1alpha1
kind: DaemonAgent
metadata:
name: gemini-bot
spec:
image: my-registry/gemini-bot:latest
restartPolicy: Always
egressPolicy:
credentialInjection:
- target: "generativelanguage.googleapis.com"
secretRef:
name: gemini-api-key
注意 credentialInjection 字段——Agent 的 Gemini API Key 存储在 Kubernetes Secret 中，在出口代理处自动注入，Agent 容器内部没有任何凭据文件或环境变量。
观测与治理实战
CLRK 的真正威力体现在运行时的观测和治理能力。
自动插桩的调用追踪
所有 LLM 调用、MCP 服务请求、外部工具调用都会被自动记录为 Invocation 资源：
clrk get invocations --agent cron-bot clrk logs cron-bot clrk traces cron-bot --since 10m
拦截的流量支持 OpenTelemetry 语义——Gemini 调用自动填充 gen_ai.system=google_genai 属性，OpenAI 调用填充 gen_ai.system=openai，让你在标准观测工具中看到 AI 特定的性能指标。
细粒度出口路由控制
通过 CRD 可以精确控制 Agent 的出口路由行为：
apiVersion: clrk.apoxy.dev/v1alpha1
kind: AIProviderRoute
metadata:
name: openai-route
spec:
agentSelector:
matchLabels:
team: data-science
destination:
provider: openai
models:
- "gpt-4o-mini"
egressGatewayRef:
name: default-egress
这意味着你可以对不同的 Agent 团队设置不同的模型和目标路由策略——数据科学团队的所有 OpenAI 请求走专用出口网关，而核心产品团队则可以使用其他模型。结合 EgressL4Route 和 MCPRoute，你能给每个 Agent 定义精确的”能连接哪、不能连接哪”。CLRK 的 Invocation 记录还会记录每次调用，为成本分摊和用量审计提供数据基础。
凭据安全：零信任架构
CLRK 在安全方面做了一个关键设计决策：凭据永远不在 Agent 中。
传统做法是把 API Key 放在 Pod 的环境变量或挂载文件中，但一旦 Agent 进程被攻破（例如通过提示注入诱导 Agent 执行恶意代码），所有凭据即刻泄露。
CLRK 的做法是：
- Agent 在 gVisor 沙箱中运行，没有 Docker Socket，没有 Root 权限
- 所有出口流量经过 MITM 代理
- 代理在请求时注入凭据——Agent 从不持有凭据原文
- 凭据材料本身安全存储在 Kubernetes Secret 中
即使沙箱被完全攻破，攻击者也拿不到任何 API Key。
适用场景
CLRK 特别适合以下场景：
- 平台工程团队：需要为多个 AI Agent 团队提供统一的基础设施，同时实现成本分摊和用量控制
- 安全敏感环境：金融、医疗等行业的 Agent 需要严格的出口管控和审计日志
- 多租户 Agent 服务：一个 K8s 集群运行来自不同客户或部门的 Agent，需要隔离和策略分级
- Agent 成本治理：通过
AIProviderRoute限制每个 Team 的 LLM 调用预算
许可证说明
CLRK 采用 AGPL-3.0 许可证，但 api/ 和 client/ 目录使用 Apache-2.0 许可证——这意味着你可以基于它的 API 类型定义和生成的 Kubernetes 客户端进行二次开发，而不受 AGPL 的传染性约束。
总结
CLRK 填补了 Kubernetes 生态中 AI Agent 运行时治理的空白。它不像传统的 sidecar 代理那样需要每个 Agent 集成 SDK，而是在基础设施层提供透明的拦截和管控——gVisor 沙箱保证隔离，MITM 代理提供观测和策略执行，Invocation 记录实现可审计的调用追踪。
如果你已经在使用 Kubernetes 运行 AI Agent，或者正计划将 Agent 推向生产环境，CLRK 值得一试。从 clrk dev 开始，几分钟就能体验到 Agent 运行时治理的效果。
相关链接