Stacklok 用 Kubernetes 思路把 agent harness 搬进云端，两位 Kubernetes 创始人详解 Mecatl 架构

从宏观层面看，编程智能体的基本架构是：一个 LLM 在循环中调用工具，同时携带所需的上下文。由于这在本地最容易实现，许多编程智能体最初都是终端工具，随后发展为桌面应用（Claude Code 就是以 CLI 工具起家的）。但正如打开笔记本的梗所展示的那样，现代智能体框架如果无法在云端管理，就会存在令人沮丧的局限。

自2025年以来，OpenAI 和 Anthropic 都在尝试将其框架更多地迁移到云端——但成效参差不齐。挑战包括保持会话的可靠性、隔离工具执行以及保留上下文。

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

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

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

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

Mecatl：一个为云端构建的框架

Stacklok 最有趣的产品是 Mecatl，这是一款六月份作为 GitHub 上的开源项目启动的 “云原生 harness”。起初，我以为这个名字的发音是“me-cattle”——这是对 Kubernetes 中“牲畜 vs. 宠物”概念的文字游戏，即把你的服务器、Pod 和集群当作牲畜而非宠物来对待。但并不是，这个名字的实际发音是“MEH-kah-tl”，是一个阿兹特克词汇，意为绳索！

不管怎样，在 harness 的语境下，云原生意味着什么？

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

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

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

说到开源智能体 harness，已经有一些备受推崇的方案——例如 Pi，一个“极简智能体 harness”，像 Flue 这样的项目就是在其之上构建的。我们问 Stacklok 的这两位，他们的 harness 有何不同？

Beda 没有点名 Pi，但他确实提到，在以桌面为主的环境中，循环、本地执行和会话状态通常都在同一个进程内开始。

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

但企业难道不能用虚拟机、容器，或众多沙箱产品中的一种，把他们的环境迁移到云端吗？

Beda 说，这种“直接迁移”的方法往往会在智能体生命周期方面产生问题，或者无法安全地静默智能体（在等待人工输入时安全地暂停它）。

“我们的想法是，如果我们从零开始重新思考这套环境，让它真正在云端运行会怎样？”

将智能体循环与执行分离

Mecatl 的一个有趣之处在于，它让智能体循环独立于客户端、模型提供商、状态存储和执行环境。

“这是一个我们深知如何在云端良好运行的应用，”Beda 谈到这个循环应用时说。“如果我们把它从更敏感的操作中分离出来，比如工具调用和 bash，然后再把会话管理和记忆之类的东西也分离出来，让它们不再以 JSONL 文件的形式存放在磁盘上，而是可以原生地放入可管理的系统中，会怎样？”

正在阅读本文的许多读者可能都有非常符合自己见解、根据自身需求定制的环境。但 Mecatl 的设计目标是超越单用户的本地环境，扩展为企业可以集中运营的基础设施。 Beda 将此比作企业管理电子邮件的方式。

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

将 AI 智能体与前沿实验室解耦

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

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

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

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

Beda 声称，许多其他智能体工具是为个人或小型初创团队设计的，这并不适用于企业级规模的公司。

“我们与大型的组织交流，他们正在为这样的问题而苦恼：如何把这个为六人团队构建的东西，部署给成千上万甚至数万名工程师组成的工程团队使用。”

Stacklok 的 LLM 网关

MCP 是第一步。接下来是构建一个 LLM 网关，在 Stacklok 的网站上被称为“AI Gateway”，以帮助企业控制访问和成本。

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

AI Gateway 是 Stacklok 目前唯一尚未开源的主要产品，但 Beda 表示它“已经在我们的路线图上，我们很快就会做到”。

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

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

企业主干

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

McLuckie 回答说，ToolHive 和 Mecatl 都旨在独立可用，但该公司在开源部分之上提供了诸如统一的身份、授权、策略和审计之类的功能。

“我们的商业产品是企业主干，是控制平面，将它们全部联系在一起。”他说。

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

AI 的云原生时代？

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

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