Can a Cloud-Native Harness Make Agents Reliable Beyond the Desktop?

云原生的代理框架能否让代理超越桌面限制？

Kubernetes 联合创始人 Craig McLuckie 和 Joe Beda 致力于将代理框架完全引入云端。

Richard MacManus

2026年10月7日

从宏观层面来看，编码代理具有基本的架构：大型语言模型（LLM）通过循环调用工具，同时持续传递所需的上下文信息。由于这种架构在本地实现最为简单，许多编码代理最初都以终端工具的形式出现，随后发展为桌面应用程序（Claude Code 最初就是以命令行工具的形式推出）。但正如“开放笔记本”这一网络迷因所揭示的，如果现代代理框架无法在云端进行管理，就会面临令人沮丧的限制。

Cormac

@cormachayden_

软件工程师在代理出现前后

2026年5月3日 凌晨3:04

·

509万次观看

1290条评论

19700次转发

50900次点赞

自2025年以来，OpenAI 和 Anthropic 都在尝试将各自的框架向云端迁移——但成效不一。面临的挑战包括保持会话的可靠性、隔离工具执行环境以及保留上下文信息。

这听起来与2010年代初的容器编排非常相似，当时催生了2014年诞生的开源 Kubernetes。由 Google 开发的 Kubernetes 成为了部署和管理大规模云应用的主流开源系统，开启了计算领域的“云原生”时代。

Kubernetes 通过控制循环保持应用程序运行、从故障中恢复并在需要时进行扩展。如果编码代理也能以相同方式管理会怎样？

这正是 Kubernetes 创始人 Craig McLuckie 和 Joe Beda 与 Stacklok 所押注的方向。

Stacklok 架构；图示来自 Stacklok

Stacklok 于2023年从 Accel、Madrona 和 Bain Capital 获得了1750万美元的A轮融资。最初专注于软件供应链安全，该公司最近转向基于 Kubernetes 的代理解决方案。

Mecatl：专为云端构建的框架

Stacklok 最具吸引力的产品是 Mecatl，这是一个“云原生框架”，于今年6月作为 GitHub 上的开源项目启动。起初我以为这个名字发音为“me-cattle”——这是对 Kubernetes 中“牛群与宠物”概念的文字游戏，即把服务器、Pod 和集群视作牛群而非宠物。但事实并非如此，这个名字实际上发音为“MEH-kah-tl”，源自阿兹特克语，意为“绳索”！

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

McLuckie 表示：“这主要是关于‘将价值中心从桌面转移到云端’。”他从企业的角度谈论“价值”——代码和上下文通常源自本地环境。“IP 就在那里，”Beda 补充道，“如果想要真正实现管理，当这些数据存储在桌面上时，难度会更大。”

McLuckie 补充说，云原生方法还使 Stacklok 能够就代理编码提出更深层次的问题。

“为什么代理循环与工具调用子系统如此紧密耦合？为什么代理身份需要通过人类身份系统来推理？”

图示来自 Mecatl GitHub

在开源代理框架领域，已有备受推崇的解决方案——例如 Pi，这是一个“最小化代理框架”，Flue 等项目在其基础上构建。我们向 Stacklok 团队询问他们的框架有何独特之处？

Beda 并未具体提及 Pi，但他表示在以桌面优先的测试框架中，循环、本地执行和会话状态通常会从同一个进程开始。

“这个领域有很多解决方案，但它们都集中在本质上运行于桌面的架构上，”他表示。“即使它们具备可插拔性，架构仍然是一个进程，或一组紧密耦合的进程，专为桌面环境设计。”

Mecatl 的 Kubernetes 部署；来自 GitHub

但企业是否可以使用虚拟机、容器，或多种不同的沙箱产品将测试框架迁移到云端？

Beda 表示，这种“迁移并转移”的方法通常会在代理生命周期管理或安全暂停代理（等待人工输入时）方面产生问题。

“我们的思考是，如果我们从零开始重新设计测试框架，使其真正能够在云端运行，会怎样？”

将代理循环与执行分离

Mecatl 的一个引人注目的方法是将代理循环与客户端、模型提供方、状态存储和执行环境保持独立。

Beda 表示：“我们知道如何在云端良好运行循环应用。假设我们将其与更敏感的操作（如工具调用和 Bash）分离，同时还将会话管理和内存等组件分离，这样这些数据就不再以 JSONL 文件的形式存储在磁盘上，而是可以原生地存入可管理的系统中。”

Mecatl 架构；图表来自项目 GitHub

阅读本文的许多人可能已经拥有高度定制化的测试框架，专为特定需求设计。但 Mecatl 的设计目标是超越单用户本地测试框架，扩展到企业可以集中管理的基础设施。Beda 将此比作企业如何管理电子邮件。

“我们认为，未来在企业工作时与代理的互动应属于该企业，他们将希望像管理电子邮件一样对其进行管理和治理。”

解耦 AI 代理与前沿实验室

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

对 McLuckie 来说，“云原生”这一术语代表了一种“在与云提供商具体细节解耦的云中运行”的方式。因此，Stacklok 正在尝试做的很多工作，基本上与我们在 Kubernetes 时代所做的类似。

在转向代理基础设施后，Stacklok 构建了 ToolHive——一个用于运行和管理 MCP 服务器的开源平台。它最初是作为管理在桌面 Docker 容器中运行的 MCP 服务器的一种方式而诞生的。Beda 表示，他们随后将其扩展为“基于 Kubernetes 的网关和其他相关服务——一个注册中心和一个用于运行和管理 MCP 服务器的操作助手，同时正确处理这些服务器的输入输出认证问题。”

图表来自项目 GitHub

正如 McLuckie 所说，这个想法是让已经使用 Kubernetes 的企业“开始将代理工作负载引入这些环境”。

Beda 表示，许多其他代理工具是为个人或小型创业团队设计的，这显然无法满足大型企业的需求。

“我们与大型组织交流时，他们正面临这样的难题：如何将原本为六人团队开发的系统，部署到数千甚至数万名工程师的工程任务部队中。”

Stacklok 的 LLM 网关

MCP 是第一步。接下来是构建一个 LLM 网关（在 Stacklok 官网上称为“AI 网关”），帮助公司控制访问权限和成本。

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

Stacklok 的“AI 网关”（即 LLM 网关）

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

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

McLuckie 解释道：“我们更倾向于在经过优化的系统中进行语义路由模型选择，因为那里的上下文信息更丰富。”

企业主干

由于 ToolHive（MCP 平台）和 Mecatl（网关）都是开源的，Stacklok 的商业模式是什么？

McLuckie 回答说，ToolHive 和 Mecatl 都是独立可用的，但公司提供跨开源组件的一致身份、授权、策略和审计功能。

“我们的商业产品是企业主干，即连接所有组件的控制平面，”他说道。

根据 Stacklok 对“520 位负责其组织使用大型语言模型和/或 AI 代理的领导者”的调查：

Beda 补充道：“对于小团队来说，开源项目相对容易部署。但一旦开始将这些系统扩展到多个集群、多个云环境……各种新的问题就会浮现。而我们正专注于解决这些问题。”

AI 的云原生时代？

亚马逊在 2006 年推出了 S3 和 EC2——云时代的开端，但最初这些产品主要被初创公司和个人使用。企业级解决方案如 Windows Azure 出现了数年之后，直到 2014 年 Kubernetes 的出现才实现了对容器化应用的大规模管理。

我们开始看到类似的模式在智能体技术中重现。企业并不一定希望员工自定义开源网关，甚至可能不愿意使用运行在个人电脑上的前沿实验室网关。Stacklok 由两位云原生领域的专家创立，旨在通过将智能体网关完全迁移到云端来解决这些问题。