在 Kubernetes 上跑“成百上千个智能体”，他用 ACP-X 给出了另一条路

很多人还在纠结“一个 Agent 怎么写好”，Onur Solmaz 已经在现场展示：如何在 Kubernetes 上规模化运行一整群 Agent，甚至把完整 IDE 跑进 Discord。这场演讲最猛的地方不是模型，而是他对 Agent 基础设施的重新定义。

真正的反差：别人还在写 Agent，他已经在“运维 Agent 群”

演讲一开场，Onur 就抛出一个略显随意、但信息量极大的事实：这套系统还在进行中（work in progress），但已经能跑起来了。很多团队还停留在「如何设计一个好 Agent」的阶段，而他讨论的却是另一个维度的问题——当你同时运行大量 Agent，并且它们各自有任务、状态和生命周期时，系统到底该怎么设计？

他给出的现实例子非常直接：现在他能在 Discord 里跑一个完整的 IDE，同时背后是并行工作负载在执行。换句话说，聊天窗口只是表象，真正的复杂度发生在集群内部。这种“把 IDE 当成 Agent 前端”的思路，本身就和大多数人理解的 Agent 完全不在一个层级。

ACP 不是 MCP 的“变体”，而是为规模化而生的接口层

当 Onur 解释什么是 ACP 时，他特意点了一句：“大家总会问，这是不是像 MCP？”——甚至名字也是故意选的相似。但他的答案是否定的。

在 OpenClaw 的体系里，新增 Agent 能力不是改代码，而是通过 CLI 注入功能。ACP 充当的角色，更像是一个连接层：它把外部操作、代码编辑、任务触发，统一转译为 Agent 可以理解和执行的动作。

他提到一个非常关键的概念：fire hoses。这不是 UI 花活，而是高吞吐的事件/指令通道，用来持续“喂”Agent 工作。你不是在和 Agent 对话，而是在不断向它输送可以执行的操作流。这也是为什么 ACP-X 能够复用别人写的代码扩展，并把它直接驱动到 Codex 会话中——现场展示的，其实只是一次完整执行过程的重放。

真正的核心：把“一个任务一个 Agent”变成基础假设

演讲中最容易被忽略、但最重要的一句话，来自他的日常工作描述：“我们都会开始为每一个任务启动一个 Agent。”

这句话意味着什么？意味着 Agent 不再是稀缺资源，而是像 Pod 一样的调度单元。这也是为什么 Kubernetes 成了不可绕开的基础设施。Onur 提到的 goal operator，正是用来处理那些人类不想碰的复杂部分：调度、依赖、失败重试、生命周期管理。

在这种架构下，Agent 的价值不在于“多聪明”，而在于是否能被安全、低成本、可预测地复制和销毁。这和我们熟悉的单 Agent Demo 完全是两种思维模式。

这场演讲真正透露的行业信号

Onur 并没有试图推销一个“完整产品”，甚至多次强调系统仍在演进中。但恰恰是这种不包装的分享，暴露了一个清晰趋势：

Agent 的竞争焦点，正在从「Prompt 和模型能力」转向「基础设施和操作系统层」。当 Agent 数量上来之后，谁能更好地解决并行、隔离、失败和可观测性，谁就更接近真正可用的 AI 系统。

ACP-X 和 OpenClaw 的尝试，像是在提前回答一个问题：当 Agent 多到像微服务一样普遍时，我们是否已经准备好相应的工具链？

总结

如果你是一名 AI 工程师，这场演讲最大的启发并不是“又多了一个 Agent 框架”，而是一个思维转变：别再假设 Agent 是少量、长期存在的对象。相反，开始用 Kubernetes 的视角去看 Agent——短生命周期、任务导向、随用随毁。

一个值得你立刻思考的问题是：如果明天你的系统需要同时跑 100 个 Agent，你现在的架构还能成立吗？如果答案是否定的，那 Onur 正在做的事情，可能比你想象得更接近未来。

关键词： AI Agent， Kubernetes， ACP-X， OpenClaw， Agent 架构

事实核查备注： 需要核查：演讲者姓名 Onur Solmaz 拼写；ACP 与 MCP 的具体区别是否在视频中明确界定；goal operator 是否确实运行在 Kubernetes 上；Discord 中运行 IDE 的演示描述是否完整对应视频内容。