Stacklok 打造雲端原生 AI 代理平台，解決企業部署挑戰

高階來看，程式碼代理（coding agents）的基本架構是：大型語言模型（LLM）在迴圈中呼叫工具，同時傳遞所需的情境資訊。由於這種方式最容易在本地實作，許多程式碼代理最初都是終端機工具，然後發展成桌面應用程式（例如 Claude Code 最初就是一個命令列工具）。然而，正如「筆電打開」的迷因所諷刺，如果現代代理框架無法在雲端進行管理，它們就會面臨令人沮喪的限制。

自 2025 年以來，OpenAI 和 Anthropic 都試圖將其代理框架更多地轉移到雲端，但成功程度不一。挑戰包括保持會話（session）的可靠性、隔離工具執行以及保留情境資訊。這聽起來很像 2010 年代初期的容器編排（container orchestration），當時開源的 Kubernetes 於 2014 年應運而生。

由 Google 開發的 Kubernetes，成為大規模部署和管理雲端應用程式的主導開源系統，它開啟了運算的「雲端原生」（cloud native）時代。Kubernetes 使用控制迴圈（control loops）來保持應用程式運行、從故障中恢復並在需要時進行擴展。那麼，如果程式碼代理也能以相同的方式進行管理呢？

這正是兩位 Kubernetes 創辦人 Craig McLuckie 和 Joe Beda 透過 Stacklok 所下的賭注。Stacklok 在 2023 年從 Accel、Madrona 和 Bain Capital 獲得了 1750 萬美元的 A 輪融資。該公司最初專注於軟體供應鏈安全，最近則轉向基於 Kubernetes 的代理解決方案。

Stacklok 最有趣的產品是 Mecatl，這是一個於六月在 GitHub 上啟動的開源專案，被稱為「雲端原生代理框架」。起初，我以為這個名字發音為「me-cattle」，是參考 Kubernetes 中「牛群與寵物」（cattle vs. pets）概念的雙關語，意指將伺服器、Pod 和叢集視為牛群而非寵物。但實際上，這個名字發音是「MEH-kah-tl」，是一個阿茲特克語，意思是繩索！

無論如何，在代理框架的背景下，「雲端原生」意味著什麼？McLuckie 表示，這主要是關於「將價值重心從桌面轉移到雲端」。他從企業角度談論「價值」，因為程式碼和情境資訊通常來自本地環境。Beda 補充說：「智慧財產（IP）就存在於那裡。如果你想真正將其納入管理，當它位於桌面上時會困難得多。」

McLuckie 補充說，雲端原生方法也讓 Stacklok 能夠對代理程式碼提出更深入的問題。「為什麼代理迴圈與工具呼叫子系統如此緊密耦合？為什麼代理身份是透過人類身份系統的視角來推斷的？」當談到開源代理框架時，已經有一些備受推崇的解決方案，例如 Pi，一個被 Flue 等專案作為基礎的「極簡代理框架」。我們詢問 Stacklok 的兩位創辦人，他們的框架有何不同？

Beda 沒有特別提到 Pi，但他表示在桌面優先的代理框架中，迴圈、本地執行和會話狀態通常在同一個程序中啟動。「這個領域有很多解決方案，但它們都主要專注於在桌面上運行。」他說：「所以即使它們具有可插拔性，其架構仍然是一個程序，或一組緊密耦合的程序，專為在桌面上運行而建構。」

但企業難道不能使用虛擬機（VMs）、容器或許多不同的沙盒產品，將其代理框架遷移到雲端嗎？Beda 表示，這種「隨意搬遷」（lift and shift）的方法往往會在代理的生命週期或使其靜止（安全暫停，等待人工輸入）方面產生問題。「我們的想法是，如果我們從頭開始重新思考代理框架，使其真正在雲端運行呢？」

Mecatl 的一個引人入勝的方法是，它使代理迴圈獨立於客戶端、模型供應商、狀態儲存庫和執行環境。「這是一個我們知道如何在雲端良好運行的應用程式。」Beda 談到迴圈應用程式時說：「如果我們將其與更敏感的操作（如工具呼叫和 Bash）分開，然後再將會話管理和記憶體等內容分開，這樣這些東西就不再以 JSONL 檔案形式儲存在磁碟上，而是可以原生放入可管理的系統中。」

許多讀者可能已經擁有高度客製化的代理框架，以滿足自己的需求。但 Mecatl 的設計旨在超越單用戶、本地框架，成為企業可以集中運營的基礎設施。Beda 將其比喻為企業管理電子郵件的方式。「我們認為，未來你在企業工作時與代理的互動屬於該企業；他們會希望像管理電子郵件一樣管理和治理這些互動。」

Stacklok 的主要動機之一是幫助大型企業減少對前沿實驗室和超大規模供應商（如 Codex、Claude Code 和 GitHub Copilot）的依賴。McLuckie 認為，這類似於 Kubernetes 如何幫助公司減少對大型雲端供應商的依賴。

對 McLuckie 而言，「雲端原生」一詞代表了一種「在雲端運行，且與雲端供應商的具體細節解耦」的方式。因此，Stacklok 正在努力做的很多事情，與他們在 Kubernetes 時代所做的大致相同。

在轉向代理基礎設施後，Stacklok 建立了 ToolHive，這是一個用於運行和治理 MCP 伺服器的開源平台。它最初是作為管理在桌面上 Docker 容器中運行的 MCP 伺服器的一種方式。然後，Beda 表示，他們將其擴展為「基於 Kubernetes 的閘道和其他相關服務，包括一個註冊中心和一個操作員輔助工具，用於運行和管理 MCP 伺服器，並正確處理輸入輸出身份驗證等問題。」

正如 McLuckie 所說，這個想法是讓已經在 Kubernetes 上運行的企業「開始將代理工作負載引入這些環境」。Beda 聲稱，許多其他代理工具是為個人或小型新創團隊設計的，這對於企業規模的公司來說是行不通的。「我們與大型組織交談時，他們正在努力解決如何將為六人團隊構建的東西，部署給數千甚至數萬人的工程任務團隊。」

MCP 是第一步。接下來是建立一個大型語言模型閘道（LLM gateway），或 Stacklok 網站上所稱的「AI 閘道」，以幫助公司控制存取和成本。「我們的大多數客戶是銀行、半導體公司、電信公司，你知道，那些在相對受監管行業中運營的公司。」McLuckie 說。

AI 閘道是 Stacklok 尚未開源的主要產品，但 Beda 表示它「已列入我們的藍圖，我們很快就會實現」。與 Glean 的解決方案不同，Stacklok 的 AI 閘道目前不根據任務選擇模型。相反，它專注於存取控制、預算、報告和供應商路由。「我們更傾向於看到語義路由模型選擇發生在代理框架中經過磨練的智能系統中，因為那裡有更多的情境資訊。」McLuckie 解釋道。

由於 ToolHive（MCP 平台）和 Mecatl（代理框架）都是開源的，那麼 Stacklok 的商業模式是什麼？McLuckie 回答說，ToolHive 和 Mecatl 都旨在獨立有用，但該公司提供跨開源部分的統一身份、授權、政策和審計等服務。「我們的商業產品是企業骨幹，即將它們全部連結在一起的控制平面。」他說。

根據 Stacklok 對「520 位負責其組織使用大型語言模型和/或 AI 代理的領導者」的調查。「這些開源專案對於小型團隊來說相對容易啟動和運行。」Beda 補充說：「但一旦你開始將這些東西擴展到多個叢集、多個雲端，各種新問題就會隨之而來。這就是我們專注於解決的問題。」

Amazon 在 2006 年推出了 S3 和 EC2，這是雲端時代的開端，但起初這些產品主要由新創公司和個人使用。直到幾年後，像 Windows Azure 這樣的企業解決方案才出現，然後在 2014 年 Kubernetes 到來，以大規模管理容器化應用程式。

我們開始看到同樣的模式在代理技術中上演。企業不一定希望允許其員工客製化開源代理框架，甚至使用運行在個人電腦上的前沿實驗室代理框架。由兩位雲端原生領域的領軍人物創立的 Stacklok，旨在透過將代理框架完全帶入雲端來解決這些問題。