云原生运行时能否让 Agent 摆脱桌面限制并保持可靠？
从宏观角度看，编码 Agent 的底层架构其实很简单：LLM 循环调用工具，同时维持上下文。由于本地实现最为方便，许多编码 Agent 最早以终端工具的形式出现，随后演变为桌面应用（Claude Code 最早便是个 CLI 工具）。但正如那个“打开笔记本”的梗图所示，现代 Agent 如果无法在云端管理，将面临诸多令人生厌的限制。
Cormac@cormachayden 软件工程师在 Agent 出现前后对比
凌晨 3:04 · 2026 年 5 月 3 日 · 509 万次浏览457 条回复 · 1290 次转发 · 1.97 万点赞
自 2025 年以来，OpenAI 和 Anthropic 都在努力将 Agent 运行环境迁移到云端，但成效参差不齐。主要挑战在于如何确保会话的稳定性、实现工具执行的隔离以及保持上下文连贯。
这让人不禁联想到2010 年代初的容器编排领域，后来由此诞生了 2014 年开源的Kubernetes。Kubernetes 由 Google 主导开发，逐渐成为部署和大规模管理云应用的主流开源系统，也由此开启了“云原生”计算时代。
Kubernetes 利用控制循环来保持应用运行、从故障中恢复并在需要时进行扩展。如果编码代理也能以同样的方式管理，会怎样？
这正是两位 Kubernetes 创始人 Craig McLuckie 和 Joe Beda 在 Stacklok 押注的方向。
Stacklok 在 2023 年完成了由 Accel、Madrona 和 Bain Capital 领投的 1750 万美元 A 轮融资。该公司最初专注于软件供应链安全，但最近转向基于 Kubernetes 的代理解决方案。
Mecatl：为云端打造的 harness
Stacklok 最具创新性的产品是 Mecatl，这是一个“云原生 harness”，于六月作为GitHub 上的开源项目启动。起初，我以为这个名字发音是“me-cattle”，是 Kubernetes “cattle vs. pets”（家畜 vs. 宠物）概念的玩字梗，意指将服务器、pod 和集群视为家畜而非宠物。但事实上，这个名字发音是“MEH-kah-tl”，是一个意为绳索或绳子的阿兹特克语词汇！
不管怎样，在 harness 的语境下，“云原生”究竟意味着什么？
McLuckie 指出，这主要是关于“将价值中心从桌面转移到云端”。他所说的“价值”是从企业角度出发的——代码和上下文通常源自本地环境。“知识产权就在那里，”Beda 插话道。“如果你想真正将其纳入管理，当它位于桌面时，难度会大得多。”
McLuckie 补充说，云原生方案还让 Stacklok 能够思考一些更深层的问题：智能体编程的本质。
“为什么 agent loop 与工具调用子系统耦合得如此紧密？为什么要用人类身份系统的思路来处理 agent 身份？”
说到开源 agent harness，其实已有口碑不错的方案，比如 Pi——一个“极简 agent harness”，Flue 等项目就在它之上构建。我们问 Stacklok 的两位，他们的 harness 有什么不同？
Beda 没有点名 Pi，但他表示，在桌面优先的 harness 中，loop、本地执行和会话状态往往都运行在同一个进程里。
“这个领域解决方案很多，但它们本质上都是为桌面环境设计的，”他说。“所以即便支持插件化，架构仍然是一个进程，或一组紧耦合的进程，天生就是跑在桌面上的。”
那么，企业就不能用虚拟机、容器或各种沙箱产品把 harness 迁到云上吗？
Beda 指出，这种“平移迁移”方式往往会在 Agent 的生命周期管理方面引发问题，例如如何安全地让 Agent 进入静止状态（即在其等待人类输入时进行安全暂停）。
“我们的思路是：如果从根本上重新设计执行框架（Harness），使其直接在云端运行，会怎样？”
将 Agent 循环与执行环境分离
Mecatl 的一个 intriguing（有趣/巧妙）之处在于，它将 Agent 循环设计得独立于客户端、模型提供商、状态存储和执行环境。
Beda 针对循环应用部分表示：“这是一个我们很清楚如何在云端高效运行的应用。如果我们将它与更敏感的操作——如工具调用和 bash 命令——分离开来，同时将会话管理和内存等也解耦，这样这些数据就不再是存放在磁盘上的 JSONL 文件，而是可以原生地存入可管理的系统中。”
阅读本文的许多人可能拥有经过定制、满足自身特定需求的执行框架。但 Mecatl 的设计初衷是突破单用户本地框架的局限，扩展为企业可以集中运营的基础设施。Beda 将此类比为企业管理电子邮件的方式。
“我们认为，未来你在为企业工作时与 Agent 的交互应归属于该企业；企业会希望像管理电子邮件一样对其进行检查和治理。”
将 AI Agent 与前沿实验室解耦
Stacklok 的主要动机之一，是帮助大型企业和前沿实验室及超大云服务商降低依赖，例如 Codex、Claude Code 和 GitHub Copilot。McLuckie 指出，这与 Kubernetes 帮助公司减少对大型云提供商的依赖类似。
在 McLuckie 看来，“cloud native”代表着一种“在解耦了特定云提供商细节的云环境中运行”的方式。他说：“我们在 Stacklok 试图做的事情，大体上延续了我们在 Kubernetes 时代所做的事情。”
转型涉足 Agent 基础设施后，Stacklok 构建了 ToolHive——一个用于运行和管理 MCP 服务器的开源平台。起初，它只是一种在桌面上管理运行于 Docker 容器中的 MCP 服务器的手段。Beda 说，随后他们将其扩展为一个“基于 Kubernetes 的网关及其他相关服务——包括注册中心和 Operator 助手，用于运行和管理 MCP 服务器，并正确处理好相关的输入输出鉴权事项。”
正如 McLuckie 所述，其核心理念是使那些已经运行 Kubernetes 的企业能够“开始将 agentic 工作负载引入这些环境。”
Beda 声称，许多其他 Agent 工具是为个人或小创业团队设计的，这在企业级公司行不通。
“我们与大型组织沟通时发现，他们正为如何部署一个原本为六人团队构建的工具到数千甚至数万名工程师的任务团队中而苦恼。”
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 的问世，则实现了容器化应用的大规模管理。
如今，我们开始看到同样的模式在 Agentic 技术领域重演。企业未必希望允许员工定制开源 harness，也不一定会采用运行在个人电脑上的前沿实验室 harness。由两位云原生领域资深专家创立的 Stacklok，旨在通过将 Agent harness 完全迁移至云端来解决这些问题。