AX – Google 的开放式 Agent 编排器

原文 ↗ Hacker News 讨论 ↗

Google 的新项目 AX 旨在提供一个基于 Kubernetes 的开源“agentic orchestrator”，用于在安全、沙箱化环境中运行大量 AI agents，并具备快速快照/恢复以及严格的网络和权限控制等功能。评论者意见分化：一些人认为它是严肃的基础设施级工具，适合需要在大规模下管理突发、未受信任 agent 工作负载的研究实验室或企业；另一些人则认为它是过度设计的“面向 agents 的 Kubernetes”，对典型开发工作并无必要。由于 Google 在产品和开源项目持续维护方面的记录参差不齐，许多人因此将 AX 视为实验性、甚至可能短命的项目，尽管它在技术上颇具野心。

AX 是什么，不是什么

  • 许多读者从落地页很难理解 AX 的用途；“orchestrator（编排器）”这个词显得很模糊。
  • 有人将其澄清为：基于 k8s 的控制平面，用于在用户机器之外的隔离沙箱中运行 LLM agents，并提供出站流量控制、资源限制以及快速挂起/恢复。
  • 它属于基础设施层，而不是像 LangChain 这样的应用层 agent 框架；更关注“agents 在哪里以及如何运行”，而不是“它们如何思考”。

Kubernetes、YAML 与复杂性

  • 有人强烈批评 AX 是“面向 agents 的 Kubernetes”：需要 k8s 集群、容器镜像仓库、Agent Substrate API、YAML 配置。
  • 一些人认为这属于不必要的过度工程，尽管营销上声称“易用”，但并不“符合人体工学”。
  • 也有人认为，在企业或已有 k8s 环境中，这其实很自然：原语熟悉，如果你已经有集群，接入成本低，而且与行业基础设施模式一致。

安全性、沙箱与规模

  • 对强隔离能力的反馈普遍积极：microVM/gVisor、零信任出站允许列表、MITM 网关、快速任务恢复、工作区持久化。
  • 有几条评论指出，这正符合运行不受信任的 agent 代码的现实需求，尤其是在大规模或安全敏感的工作流中。
  • 讨论也涉及 microVM 技术，以及不同方案（Firecracker、qemu、smolvm 等）到底能提供多少隔离。
  • AX 被认为更适合大型、突发型的 agent 负载（evals、RL、训练），而不是小型开发团队。

与其他 Google 方案及生态的比较

  • AX 构建在 Agent Substrate 之上，而后者正在移交给 CNCF；它与另一个 Google 项目 Scion 形成对比，后者会包装现有 harness，在一些人看来更具整合性。
  • 有人更喜欢 Scion 或其他编排器，因为它们可以运行“正常工作负载”和现有 harness，而不需要引入一整套新栈。
  • 许多人评论说，“人人和他们的祖母”都在做 agent 框架/沙箱；目前还没有明确的“agents 版 React”。

对 Google 的信任与长期性

  • 人们反复对 Google 的产品和开源长期维护能力表示怀疑，引用了“被 Google 扼杀”的历史以及那些很快被放弃的工具。
  • 也有人举出长期存在的 Google 开源项目作为反例（Kubernetes、Go、Chromium 等），但整体情绪是：把 AX 当作实验性项目，不要深度依赖其生产环境。

实用性与过度设计

  • 有些人认为它技术上很有价值，并期待研究其设计。
  • 另一些人则认为，真正需要“数十亿个 agents”或如此重型基础设施的用户其实很少；对很多人来说，简单的 VM、容器或本地工具就足够了。