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代理提供了一個安全、可觀察且易於管理的平台，特別適合需要零信任和細粒度治理的場景。