CLRK：一个开源的代理运行时，采用gVisor和MitM防护

CLRK（读作“clerk”）是一个面向LLM代理的Kubernetes原生运行时。它基于gVisor沙箱安全运行每个代理，并通过透明代理拦截所有出口流量——包括LLM API调用、MCP（模型上下文协议）和工具调用——而无需修改代理代码。这一拦截点提供了可观察性、策略执行和基于路由的成本控制，使用户能够深入洞察代理行为。

工作原理

CLRK在gVisor沙箱中运行不受信任的、框架无关的代理工作负载。用户以声明方式描述代理：容器镜像、触发器和出口策略。CLRK将其调度到沙箱工作节点池中，并使用自己的调度器，从而避免pod创建延迟。沙箱中的每个字节都通过CLRK控制的透明代理进行出入，因此平台能够观察和管理所有LLM API调用、MCP流量和外部工具调用，包括TLS加密连接。代理内部可以是任何通过HTTP(S)调用的程序——例如使用OpenAI或Anthropic SDK的Python脚本、Node MCP客户端或shell单行命令。无需特定的代理库；CLRK在网络和进程边界进行拦截。

动机

在生产环境中运行代理会带来通用容器编排无法单独解决的问题。CLRK直接针对这些问题设计：

• 可观察性：所有进出沙箱的I/O都被拦截并记录，LLM、MCP和远程工具调用遥测自动检测，无需按框架附加。
• 治理：防止沙箱逃逸，并在出口边界应用组织级策略（例如代理可以连接到哪里、可以使用哪些凭据）。
• 归因：将代理循环追溯到触发它的客户请求或触发器，并捕获为一级Invocation记录。
• 零信任访问：为代理提供经审计和授权的内部服务访问，而非全有或全无的网络访问。
• 可扩展性：统一模型支持无服务器突发和长期运行的“本地”Kubernetes集群。
• 可靠性：简单的重试和负载丢弃机制，独立于Kubernetes控制平面。
• 凭据安全：凭据从不存储在代理中。AI提供商、MCP服务器和内部服务的API密钥由出口MITM在请求时注入，而非通过pod环境变量、挂载或参数，因此即使沙箱被攻破，也无法泄露凭据。

架构

CLRK包含两个长期运行的二进制文件和一个CLI：

• cmd/controller-manager：控制平面，运行controller-runtime协调器，并嵌入聚合API服务器。可部署为Kubernetes Deployment，也可独立运行，还提供UI仪表板。
• cmd/worker：通过gVisor/runsc管理沙箱生命周期，并通过定制的sentrystack插件设置每个沙箱的网络拦截。仅限Linux（CGO）。
• cmd/clrk：运维/开发者CLI，支持安装、升级、开发、apply、get、logs、traces、status、run-task、上下文管理和本地集群开发循环。

出口拦截通过Envoy-based的数据平面实现，该平面具有TLS终止（MITM）和自定义过滤器。Telemetry记录在ClickHouse中，可通过/logs和/traces子资源以及OpenTelemetry导出。

API

CLRK通过CRD扩展Kubernetes API，主要类型包括：

• TaskAgent：短生命周期代理执行（请求→沙箱→响应）。
• DaemonAgent：长期运行代理进程，支持重启策略。
• WorkerPool：工作节点pod集群（Deployment + Service）。
• EgressGateway：透明出口代理，支持多种TLS终止模式。
• EgressL4Route：L4出口路由规则。
• MCPRoute：MCP协议路由。
• AIProviderRoute：AI提供商特定出口路由。
• Invocation：拦截代理调用的归因记录（基于ClickHouse）。

FAQ

• 是否需要特定框架？ 不需要。CLRK在网络和进程边界拦截，任何使用HTTP/S调用的代理都适用。
• API密钥存储在哪里？ 不在代理中。凭据由出口MITM在请求时通过凭据注入策略注入，不会出现在pod环境变量、挂载或参数中。即使沙箱被攻破，也无密钥可泄露。秘密材料安全地存储在Kubernetes Secret中。
• 沙箱如何隔离？ 通过gVisor（runsc）提供更强的系统调用边界，每个沙箱在独立的网络命名空间中运行，所有出口强制经过拦截路径。
• 本地运行是否需要Kubernetes集群？ 无需。clrk dev命令可以启动本地集群和开发循环。
• 许可证：CLRK整体采用AGPL-3.0，但api/和client/目录采用Apache 2.0，以便无AGPL限制地导入和使用公共API类型。

仓库布局

主要目录包括api/（CRD类型）、client/（生成的Kubernetes客户端）、internal/controller/（协调器）、internal/worker/和internal/sandbox/（沙箱生命周期）、internal/egress/（Envoy出口数据平面）、internal/clickhouse/（遥测存储）等。

贡献与测试

目前不接受外部贡献。项目有测试，但尚未公开；内部保持至少70%的单元测试覆盖率，并为公共API提供了集成测试。代码由AI辅助编写，但每一行都经过仔细审查和测试。

总的来说，CLRK为生产环境中的LLM代理提供了一个安全、可观察且易于管理的平台，特别适合需要零信任和细粒度治理的场景。