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