Kubernetes 创始人押注云端 Agent Harness
云端化：编码代理的新难题
从架构上看，编码代理通常是一个相对清晰的循环：大语言模型不断调用工具，并在过程中携带必要上下文。由于本地实现最简单，许多编码代理最初都以终端工具或桌面应用的形式出现，Claude Code 也曾以 CLI 工具起步。
但随着编码代理被更频繁地用于真实开发流程，仅停留在本地桌面环境会暴露出明显限制：会话可靠性、工具执行隔离、上下文保存，以及跨设备、跨环境的管理能力，都变得越来越重要。
自 2025 年以来，OpenAI 和 Anthropic 都在尝试把各自的 Agent Harness 更多迁移到云端，但效果并不一致。核心挑战包括：
- 如何让长时间运行的代理会话保持可靠；
- 如何安全隔离工具调用与代码执行；
- 如何在失败、重启或迁移后保留上下文；
- 如何对多个代理任务进行统一调度和管理。
从容器编排到 Agent 编排
这些问题听起来很像 2010 年代早期的容器编排难题。当时，云应用需要一种方式来自动部署、恢复、扩缩容和管理生命周期。2014 年，由 Google 开发的开源项目 Kubernetes 出现，并逐渐成为大规模部署和管理云应用的主流系统，也推动了“云原生”计算时代。
Kubernetes 的核心机制之一是控制循环：系统持续观察当前状态与期望状态之间的差异，并自动采取行动，让应用保持运行、从故障中恢复，并在需要时进行扩展。
现在，一个类似的问题被提出：如果编码代理也能以同样方式被管理，会怎样？
这正是 Kubernetes 共同创建者 Craig McLuckie 和 Joe Beda 在 Stacklok 上的押注方向。
Stacklok 的转向
Stacklok 在 2023 年完成了 1750 万美元 A 轮融资，投资方包括 Accel、Madrona 和 Bain Capital。公司最初聚焦软件供应链安全，近期则转向基于 Kubernetes 的 Agentic 解决方案。
其重点产品是 Mecatl，一个面向云端构建的 Agent Harness。根据现有介绍，它试图把代理运行环境从个人电脑迁移到更可控、可编排的云基础设施中。
这种思路并不是简单地“把代理放到服务器上运行”，而是借鉴 Kubernetes 式的管理方式：将代理会话、工具调用、执行环境和上下文管理纳入统一控制系统，使其具备更强的恢复、隔离和可观察能力。
为什么本地 Agent Harness 不够用
本地 Agent Harness 的优势是启动快、集成简单、便于开发者直接使用。但当代理承担更复杂任务时，本地环境也会成为瓶颈：
-
可靠性不足
代理任务可能运行很久，本地电脑休眠、网络中断、进程崩溃都会打断执行。 -
环境不稳定
每个开发者的机器配置、依赖和权限不同，代理执行结果容易受本地环境影响。 -
隔离能力有限
编码代理需要运行命令、修改文件、调用外部工具。如果缺少隔离机制，安全风险会更高。 -
上下文难以持久化
代理需要记住任务目标、代码状态、工具调用历史和中间推理结果。本地会话一旦中断，恢复成本较高。 -
团队协作困难
当代理从个人工具变成团队基础设施，就需要审计、权限管理、任务分配和集中监控。
这些问题正是云端 Agent Harness 想要解决的方向。
Kubernetes 思路能否复用到代理系统？
Kubernetes 管理的是容器化应用，而编码代理管理的是更动态、更不确定的任务循环。二者并不完全相同，但确实存在一些相似点：
- 都需要维持长期运行任务；
- 都需要故障恢复；
- 都需要资源调度；
- 都需要执行隔离；
- 都需要可观察性；
- 都需要在复杂系统中接近期望状态。
因此，把 Agent Harness 云原生化，本质上是在尝试为代理建立一套类似“控制平面”的基础设施。
如果这一方向成立，未来编码代理可能不再主要依赖开发者打开笔记本电脑持续运行，而是可以在云端托管、调度和恢复。开发者与代理之间的交互方式，也可能从“本地命令行工具”逐步演变为“云端任务系统”。
仍需验证的问题
不过，云端 Agent Harness 仍处在早期阶段，尚有许多问题需要验证：
- 云端执行是否会带来新的安全和权限管理复杂度；
- 代理上下文如何在可恢复和隐私保护之间取得平衡；
- 云端运行成本是否可控；
- Kubernetes 是否真的是管理代理任务的最佳抽象；
- 开发者是否愿意把本地编码流程迁移到云端；
- 这类系统能否在真实工程项目中显著提升可靠性。
Stacklok 的转向说明，Agent Harness 正从工具形态走向基础设施形态。无论 Mecatl 最终能否成为主流方案，编码代理的云端编排、隔离和恢复能力，已经成为下一阶段基础设施竞争的重要问题。