Kubernetes 创始人谈 Stacklok：云端 harness 能否让智能体在企业可靠运行

从高层来看，编码智能体有一个基本架构：一个 LLM 在循环中调用工具，同时携带所需的上下文。由于这在本地最容易实现，许多编码智能体最初是终端工具，然后才成为桌面应用（Claude Code 就著名地始于一个 CLI 工具）。但正如打开笔记本电脑的梗图所示，现代智能体框架如果无法在云端管理，就会受到令人沮丧的限制。

自 2025 年以来，OpenAI 和 Anthropic 都在试图将其框架更多地转向云端——但成功程度参差不齐。挑战包括保持会话可靠、隔离工具执行以及保留上下文。

这听起来很像2010 年代初的容器编排，由此在 2014 年诞生了开源项目 Kubernetes。Kubernetes 由 Google 开发，成为大规模部署和管理云应用的主导开源系统——它开启了计算的“云原生”时代。

Kubernetes 使用控制循环来保持应用运行、从故障中恢复并在需要时扩展。如果编码智能体也能以同样的方式管理呢？

这正是两位 Kubernetes 创造者 Craig McLuckie 和 Joe Beda 通过 Stacklok 所下的赌注。

Stacklok 早在 2023 年就从 Accel、Madrona 和 Bain Capital 筹集了 1750 万美元的 A 轮融资。该公司最初专注于软件供应链安全，最近转向基于 Kubernetes 的智能体解决方案。

Mecatl：为云构建的框架

Stacklok 最有趣的产品是 Mecatl，一个“云原生框架”，于 6 月作为GitHub 上的开源项目启动。起初，我以为这个名字读作“me-cattle”——一个双关语，指 Kubernetes 的“牛与宠物”概念，即你把服务器、Pod 和集群当作牛而不是宠物来对待。但不对，这个名字实际上读作“MEH-kah-tl”，是一个阿兹特克语单词，意为绳索或绳子！

无论如何，在框架的语境下，云原生意味着什么？

这主要是关于“将价值所在从桌面转移到云端”，McLuckie 说。他谈论的是从企业视角看的“价值”——代码和上下文往往源自本地环境。“知识产权就在那里，”Beda 插话道。“而如果你想真正将其纳入管理，当它位于桌面上时，这就困难得多。”

McLuckie 补充说，云原生方法还让 Stacklok 能够就智能体编码提出一些更深层的问题。

“为什么智能体循环与工具调用子系统如此紧密地耦合？为什么智能体身份要通过人类身份系统的视角来考量？”

在开源智能体框架方面，已经有备受推崇的解决方案——例如 Pi，一个“极简智能体框架”，Flue 等项目已在其之上构建。我们问 Stacklok 的这两位，他们的框架有何不同？

Beda 没有具体提到 Pi，但他确实说过，在桌面优先的 harness 中，循环、本地执行和会话状态通常始于同一个进程。

“这个领域有大量的解决方案，但它们基本上都专注于在桌面上运行，”他说。“所以即使它们具有可插拔性，其架构仍然是一个进程，或一组紧密耦合的进程，是为在桌面上运行而构建的。”

但企业难道不能使用虚拟机、容器或众多不同沙箱产品之一，将其 harness 迁移到云端吗？

Beda 表示，这种“直接迁移”方法往往会在 agent 的生命周期或使其静默（在等待人工输入时安全暂停）方面产生问题。

“我们的想法是，如果我们从头重新思考 harness，让它真正在云端运行，会怎么样？”

将 agent 循环与执行分离

Mecatl 的一个有趣方法是，它使 agent 循环独立于客户端、模型提供商、状态存储和执行环境。

“这是一个我们知道如何在云端良好运行的应用程序，”Beda 在谈到循环应用程序时说。“如果我们把它拿出来，将其与更敏感的操作（如工具调用和 bash）分离，然后再分离出会话管理和内存之类的东西，这样这些东西就不再作为 JSONL 文件存储在磁盘上，而是可以原生地放入可管理的系统中，会怎么样？”

阅读本文的很多人可能都有非常有主见的 harness，根据自己的需求进行了定制。但 Mecatl 的设计目标是超越单用户本地 harness，成为企业可以集中运营的基础设施。Beda 将此比作企业管理电子邮件的方式。

“我们认为，未来你在为企业工作时与 agent 的交互属于该企业；他们会希望像管理电子邮件一样管理和治理这些交互。”

将 AI agent 与前沿实验室解耦

Stacklok 的主要动机之一是帮助大型企业减少对前沿实验室和超大规模云服务商的依赖，例如 Codex、Claude Code 和 GitHub Copilot。McLuckie 表示，这类似于 Kubernetes 帮助企业减少对大型云提供商的依赖。

对 McLuckie 来说，“云原生”一词逐渐代表了一种“在与云提供商的具体细节解耦的云中运行”的方式。因此，我们[在 Stacklok]试图做的很多事情，或多或少就是我们在 Kubernetes 时代所做的。”

在转向 agent 基础设施后，Stacklok 构建了 ToolHive——一个用于运行和治理 MCP 服务器的开源平台。它最初是作为一种管理在桌面 Docker 容器中运行的 MCP 服务器的方式。然后，Beda 说，他们将其扩展为一个“基于 Kubernetes 的网关和其他相关服务——一个注册表和一个 operator 辅助工具，用于运行和管理 MCP 服务器，并正确处理这些事物的输入输出认证相关内容。”

正如 McLuckie 所说，这个想法是为了让已经在 Kubernetes 上运行的企业能够“开始将智能体工作负载引入这些环境”。

Beda 声称，许多其他智能体工具是为个人或小型初创团队设计的，这对企业级公司来说行不通。

“我们与大型组织交流时，他们正苦苦挣扎于，我该如何把这个为六人团队打造的东西，部署给成千上万甚至数万人的工程团队。”

Stacklok 的 LLM 网关

MCP 是第一步。下一步是构建一个 LLM 网关，也就是 Stacklok 网站上所称的“AI 网关”，以帮助企业控制访问和成本。

“我们的大多数客户是银行、半导体公司、电信运营商……你知道，都是在监管相对严格的行业运营的，”McLuckie 说。

AI 网关是 Stacklok 唯一尚未开源的主要产品，但 Beda 表示它“在我们的路线图上，我们很快就会实现。”

与 Glean 的解决方案不同，Stacklok 的 AI 网关目前不会根据任务选择模型。相反，它专注于访问控制、预算、报告和提供商路由。

“我们更希望看到语义路由的模型选择发生在一个在 harness 中打磨过的智能系统中，因为那里有更多的上下文，”McLuckie 解释道。

企业脊柱

既然 ToolHive（MCP 平台）和 Mecatl（harness）都是开源的，那么 Stacklok 的商业模式是什么？

McLuckie 回答说，ToolHive 和 Mecatl 都旨在独立发挥作用，但公司提供诸如跨开源部分的一致身份、授权、策略和审计等功能。

“我们的商业产品是企业脊柱，即把它们全部连接在一起的控制平面，”他说。

“开源项目对于小团队来说相对容易启动和运行，”Beda 补充道。“但一旦你开始将这些扩展到多个集群、多个云，[...] 各种新问题就会在那里涌现。而这正是我们专注于解决的问题。”

AI 的云原生时代？

Amazon 于 2006 年推出 S3 和 EC2——云计算时代的开端——但起初这些产品主要被初创公司和个人使用。几年之后，Windows Azure 等企业级解决方案才出现，随后在 2014 年，Kubernetes 问世，用于大规模管理容器化应用。

我们开始看到同样的模式在智能体技术上重演。企业不一定想让员工自定义开源 harness，甚至不想使用在他们个人电脑上运行的前沿实验室 harness。Stacklok——由两位云原生之王打造——旨在通过将智能体 harness 完全带入云端来解决这些问题。