Google 开源分布式 Agent 运行时 AX：让 AI Agent 像微服务一样可靠

AI Agent 的 Demo 越来越酷，但生产环境里最让人头疼的问题一直没变：Agent 跑到一半崩了怎么办？ 任务执行到第 7 步突然网络断了，或者 LLM 超时了，或者工具调用挂了——整个状态全丢了，只能从头再来。

Google 刚开源了一个叫 AX（Agent eXecutor） 的项目，专门解决这个痛点。它是一个分布式 Agent 运行时，核心理念是把微服务架构里已经验证过的可靠性模式——事件溯源、单写者、可恢复执行——搬到 Agent 世界里来。

项目还非常早期（v0.1.0），但设计思路值得关注。主贡献者是 rakyll（Jaana Burcu Daşdamiroğlu），Google 内部 Go 语言团队的核心成员，之前主导了 OpenTelemetry Go SDK 和许多知名开源项目。

本文提纲

1. AX 是什么——定位与核心设计
2. 架构拆解：Controller、Event Log、Registry
3. 关键特性：可恢复执行与分叉
4. Agent 接入方式：从远程 Agent 到 A2A 协议
5. 与现有方案的差异
6. 现状与风险

AX 是什么——定位与核心设计

AX 的定位非常明确：它不是 Agent 框架，而是 Agent 的运行时基础设施。

什么意思？LangChain、CrewAI、Google ADK 这些框架帮你定义 Agent 的行为（用什么 prompt、调什么工具、怎么编排流程）。AX 不管这些——它管的是 Agent 跑起来之后的事：状态管理、故障恢复、分布式协调、审计追踪。

用微服务的类比：框架是你的业务代码，AX 是你的 Kubernetes。

AX 的几个设计决策很有意思：

MERMAID_BLOCK_0

从单体 Agent 走向分布式 Agent 是必然趋势——工具、技能、子 Agent 各自部署为隔离的 Actor，通过协议通信。AX 就是这个分布式架构的协调层。

架构拆解：Controller、Event Log、Registry

Controller（控制器）

Controller 是整个系统的"大脑"。它是唯一的 State Writer——所有 Agent 的执行状态、工具调用、事件记录都通过 Controller 协调。

这种单写者设计牺牲了水平扩展性，换来了一致性保证。在 Agent 场景下这是合理的：一个对话的状态本身就不需要分片到多个节点。

Event Log（事件日志）

这是 AX 最核心的数据结构。每个 Agent 动作（接收消息、调用工具、返回结果）都被追加到 Event Log 里，形成一条不可变的时间线。

Event Log 的存储后端目前是 SQLite（单机模式），但设计上可以替换。每条事件有一个单调递增的序列号（sequence number），客户端和 Agent 都用这个序列号来追踪进度。

好处是显而易见的：
- 可回放：任何时刻的状态都能通过事件回放重建
- 可审计：谁调了什么工具、用了什么参数，全有据可查
- 可恢复：崩溃后从最后一个 checkpoint 继续执行

Registry（注册表）

Registry 管理所有可用的 Agent、Tool 和 Skill。配置在 ax.yaml 里声明：

server:
  address: ":8494"

eventlog:
  sqlite:
    filename: "eventlog/log.sqlite"

planner:
  gemini:
    model: "gemini-3.5-flash"
    timeout: "60s"
    skills_dir: "./examples/skills"

registry:
  remote_agents:
    - id: "medical-deep-researcher"
      name: "Medical Deep Researcher"
      description: "Performs deep medical research using various resources"
      address: "localhost:50051"

这个声明式配置让整个 Agent 集群的状态一目了然。

关键特性：可恢复执行与分叉

断线恢复

这是 AX 解决的第一个痛点。假设 Agent 正在执行一个 10 步任务，第 5 步时客户端断开连接：

# 客户端重连后，从序列号 12 开始恢复
ax exec \
  --conversation d85a4b4e-c53b-4c84-b879-f10d905bce40 \
  --last-seq 12 \
  --resume

Controller 会把序列号 12 之后的所有事件重放给客户端。注意这不是回滚——Agent 的执行在服务端一直在继续，客户端只是"追赶"自己错过的部分。

分叉（Fork）

更有意思的是 ax fork 命令。你可以从一个对话的某个 checkpoint 分叉出一个新的对话：

# 从序列号 12 的位置分叉出新对话
ax fork \
  --src-conversation 38460323-9a78-41cb-8991-022b0ff2c19c \
  --dest-conversation e5e26e38-53a2-4f22-b1cb-ae867357df83 \
  --src-seq 12

这个特性在 Agent 开发中非常实用。比如 Agent 在第 7 步走了弯路，你可以从第 5 步分叉出来，换一个 Agent 或调整参数重新执行——原始对话不受影响。

可视化追踪

ax trace --conversation 1a6e0b29-87c2-4af0-81ac-0c73bf8fa293

自动启动一个本地 Web UI，展示整个执行过程的时间线。调试 Agent 行为时，这种可视化比翻日志高效得多。

Agent 接入方式：从远程 Agent 到 A2A 协议

AX 目前支持四种 Agent 接入方式：

1. 远程 Agent（gRPC）

最直接的方式——你的 Agent 作为一个 gRPC 服务运行，实现 AX 的 AgentService 接口：

# 启动远程 Agent
go run examples/remote_agent/main.go

# AX Controller 通过 gRPC 调用
ax serve

2. ADK Agent（Python）

Google ADK（Agent Development Kit）是 Google 的 Python Agent 框架。AX 提供了桥接层，让 ADK Agent 可以作为远程 Agent 接入。

3. A2A Agent

A2A（Agent-to-Agent）是 Google 主推的 Agent 间通信协议。AX 内置了 A2A 桥接，支持任何实现了 A2A 协议的 Agent 直接接入。

4. Colab Agent（实验性）

可以直接在 Google Colab 里运行 Python 脚本或 Notebook 作为 Agent。这个对快速原型验证很方便。

关键点：AX 不强迫你用特定的框架。 不管你的 Agent 是用 LangChain 写的、ADK 写的、还是裸 Python 写的，只要能通过某种协议（gRPC、A2A）和 Controller 通信就行。

与现有方案的差异

AX 和这些框架不是竞争关系，而是互补——你完全可以用 LangChain 写 Agent 逻辑，然后用 AX 做运行时托管。

真正和 AX 有竞争关系的是 Temporal（分布式工作流引擎）。两者的设计理念非常相似：事件溯源、可恢复执行、单写者。区别在于 AX 专门为 Agent 场景优化——理解 tool call、skill selection、agent delegation 这些 Agent 特有的概念。

现状与风险

需要诚实地说，AX 目前还很粗糙：

• v0.1.0，官方明确说会在稳定版之前引入"major breaking changes"
• 核心贡献者只有 5 人（rakyll 个人贡献了 371 commits，占 80%+）
• 文档不完整，很多设计还在讨论中
• 不接受外部贡献（代码还在重构中）
• 只内置了 Gemini Agent，其他模型需要自己接入

但设计思路是扎实的。rakyll 在分布式系统和可观测性领域的经验（OpenTelemetry、gRPC）让 AX 在可靠性设计上比大多数 Agent 框架成熟得多。

如果你在做需要长时间运行的 Agent（自动化运维、数据处理管线、多步骤研究 Agent），AX 的可恢复执行和审计能力值得提前关注。如果只是做简单的对话式 Agent，现阶段用 LangGraph 的 Checkpoint 就够了。

作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。