@scnace: Google 开源了分布式代理运行时框架

X AI KOLs Timeline 工具

摘要

Google 开源了 AX (Agent eXecutor),这是一个面向 Kubernetes 设计的分布式运行时框架,用于编排代理循环,并内置了故障恢复和任务继续执行能力。

Google 开源了分布式代理运行时框架 https://t.co/FUCgO5HPNl
查看原文
查看缓存全文

缓存时间: 2026/05/22 08:05

Google 开源了分布式 Agent 运行时框架 https://t.co/FUCg5OHPNl — # google/ax 来源: https://github.com/google/ax # Agent 执行器 (AX) > [!WARNING]

🚧 该项目处于早期活跃开发阶段,
将会引入重大变更。
请注意,恢复协议将在稳定版本发布前经历重大修订和
破坏性变更。
请注意,我们处于非常早期的阶段,
并很快会广泛宣布该项目。如果您有兴趣合作,
请联系 [email protected]

AX,即 Agent 执行器(Agent eXecutor),是一个分布式 Agent 运行时。它提供了一个运行时,用于协调 Agent 循环、管理带事件日志的执行,并与本地和远程参与者通信。AX 的设计注重可靠性,原生支持恢复和执行续接,即使在复杂的分布式设置中也是如此。

特性

  • 分布式运行时:控制器、技能、工具和 Agent 可以隔离执行
  • 恢复:自动从故障或中断中恢复
  • 技能、工具、Agent:支持技能、工具和 Agent 的选择与执行
  • 审计与策略:所有用户和 Agent 调用由统一控制器协调,方便控制和审计整体执行以及技能/工具/Agent 调用
  • 可移植性:随处运行,适应小型和大型部署
  • 可定制性:与框架和模型无关

内置的一致性和可恢复性特性:

  • 单写入者架构:单一控制器确保一致的状态管理
  • 事件日志:持久的执行状态,支持自动恢复
  • 高级恢复:在兼容平台上支持计算层 Actor 恢复

演示

演示(https://www.youtube.com/watch?v=L5Iw1IrZ6Nc)
观看我们的演示,了解 AX 在 Agent Substrate(https://github.com/agent-substrate/substrate)上部署时的工作方式。

概览

%%{init: {"flowchart": {"diagramPadding": 80}}}%%
graph LR
    Client -->|可恢复流| Router
    Router --> Controller
    Controller <-->|可恢复流| RemoteAgent
    Controller --> Env
    Controller --> Tool
    subgraph 客户端
        Client
    end
    subgraph 路由层
        Router
    end
    subgraph AX 控制器
        Controller["AX 控制器
        (执行器、事件日志、注册表)"]
    end
    subgraph 远程组件
        RemoteAgent["Agent
        (隔离 Actor)"]
        Tool["工具
        (MCP 服务器)"]
        Env["环境
        (包含技能、内置工具)
        (隔离 Actor)"]
    end

随着 Agent 从简单助手演变为自主长期运行的工作者,开发者需要一个健壮的运行时来管理状态、确保可靠性并审计执行。当我们从单体 Agent 转向分布式框架,工具、技能和 Agent 作为隔离 Actor 部署时,一个具有动态生成隔离工作者的分布式运行时成为必需。AX 提供了填补这些空白的底层基础层。

虽然与计算无关,但 AX 旨在 Kubernetes 上提供最佳体验。我们预计每个复杂的 Agent 应用都将需要 AX 提供的能力。我们正在构建这一层作为广泛可用的基础,让开发者能够专注于构建应用而非基础设施。我们决定公开构建这个项目,以便在稳定版本发布前验证每一个设计决策。我们强烈欢迎您提供反馈。

安装

直接从仓库安装 ax 命令行工具:

go install github.com/google/ax/cmd/ax@latest

验证安装

检查 ax 是否正确安装:

ax --help

您应该会看到 ax CLI 的使用信息。

Kubernetes

AX 在 Kubernetes 上原生支持 Agent Substrate(https://github.com/agent-substrate/substrate),这是生产环境推荐的部署选项。有关设置和配置的更多详情,请参阅部署指南

阅读更多关于这一新层(https://cloud.google.com/blog/products/containers-kubernetes/bringing-you-agent-sandbox-on-gke-and-agent-substrate)的内容,它为 Kubernetes 上的 Agent 工作负载提供了更高密度。

快速开始

1. 执行

CLI 提供了一种简单的方法,使用已链接到 AX 二进制文件中的 Agent 和内置工具来执行。

# 使用默认 ax.yaml
ax exec --input "你能列出这个目录吗?"

# 使用 AX 服务器执行
ax exec --input "你能列出这个目录吗?" --server localhost:8494

对话可以随时继续:

ax exec \
  --conversation d85a4b4e-c53b-4c84-b879-f10d905bce40 \
  --input "显示 README.md 的内容"

如果客户端断开连接,传递它看到的最后一个序列号以重放错失的事件。这会同步客户端,但不会回退对话。要从检查点分支,请使用 ax fork 代替。在此示例中,我们从序列号 12 同步客户端:

ax exec \
  --conversation d85a4b4e-c53b-4c84-b879-f10d905bce40 \
  --last-seq 12 \
  --resume

除了运行默认的规划步骤外,您还可以从任何已注册的 Agent 开始执行:

ax exec \
  --agent coding \
  --input "你能用 Python 写一个简单的 HTTP 服务器吗?"

如果在 Agent 执行过程中出现任何问题,您可以恢复对话中未完成的执行:

ax exec \
  --conversation edf98ef5-4bb1-4a9e-a091-3a77e03727e6 \
  --agent "coding" \
  --resume

2. 使用自定义 Agent 执行

大多数开发者希望构建自己的 Agent。AX 允许将自定义 Agent 作为远程或沙箱 Agent 运行。有关支持的 Agent 完整列表,请参见自定义 Agent

此示例演示了 AX 服务器如何通过 AgentService.Connect RPC 执行远程 Agent。

终端 1 - 启动远程 Agent 服务器:

go run examples/remote_agent/main.go

远程 Agent 作为实现 AgentService 的 gRPC 服务器运行,端口为 :50051

终端 2 - 启动 AX 控制器服务器:

# 确保 Agent 在 ax.yaml 中注册为远程 Agent。
cat ax.yaml
# ...
# registry:
#   remote_agents:
#     - id: "lowercase"
#       name: "Lowercase Agent"
#       description: "将文本转换为小写。"
#       address: "localhost:50051"
ax serve

服务器默认在端口 :8494 上暴露服务。

终端 3 - 注册远程 Agent 并执行:

ax exec \
  --server localhost:8494 \
  --input "你好,你能把我刚才说的小写化吗?"

用法

ax 命令提供多个子命令:

执行

ax exec \
  [--input <输入内容>] \
  [--conversation <对话ID>] \
  [--agent <Agent ID>] \
  [--server <服务器地址>] \
  [--config <配置文件>] \
  [--resume] \
  [--last-seq <序列号>]

执行一个新的 Agent 执行,或自动恢复一个已有的执行。如果对话 ID 已存在,则从最新状态恢复执行。

选项:

  • --input:发送给 Agent 的输入消息(如果设置了 --resume 则为可选,否则必填)
  • --conversation:对话 ID(可选,未提供则生成 UUID,如果存在则恢复)
  • --agent:要使用的 Agent ID(可选,默认为规划器)
  • --server:gRPC 控制器服务器地址(可选。如未提供,则使用本地内置 AX 服务器运行)
  • --config:YAML 配置文件路径(仅在使用本地内置 AX 服务器时有效,默认为 “ax.yaml”)
  • --resume:恢复一个无输入的对话(可选,与 --input 互斥)
  • --last-seq:客户端看到的最后一个序列号,用于从此处恢复(可选)。服务器重放之后的事件,以便客户端在断开后同步。

示例:

# 执行一个新的执行
ax exec --input "你好,Agent!"

# 用新输入恢复一个已有的执行
ax exec --conversation a53d4db3-1165-4925-87da-be6c72bbdeb1 --input "好了,现在让我们做点别的..."

# 使用服务器模式执行
ax exec --server localhost:8494 --input "你好,Agent!"

# 使用自定义 Agent 执行
ax exec --agent coding --input "你好编码 Agent,给我写一个很酷的 Go 程序!"

运行服务

ax serve [--config <配置文件>]

使用 YAML 配置文件启动控制器作为 gRPC 服务器。

选项:

  • --config:YAML 配置文件路径(默认为 “ax.yaml”)

示例配置文件(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: "利用 Pubmed 和 ClinicalTrials.gov 等多种资源进行深度医学研究。"
      address: "localhost:50051"

示例:

# 使用默认配置启动服务器 (ax.yaml)
ax serve

# 使用自定义配置启动服务器
ax serve --config my-config.yaml

分支

从指定检查点(或最新状态)将已有的 Agent 事件日志分支到新的事件日志中。

ax fork \
  --src-conversation <源对话ID> \
  --dest-conversation <目标对话ID> \
  [--src-seq <源序列号>] \
  [--server <服务器地址>]

选项:

  • --src-conversation:要分支的源对话 ID(必填)
  • --dest-conversation:新事件日志的目标对话 ID(必填)
  • --src-seq:要分支的序列号(可选,默认为最新)。必须是源对话中存在的序列。
  • --server:gRPC 控制器服务器地址(默认为 “localhost:8494”)

示例:

# 从最新状态分支到新对话
ax fork --src-conversation 38460323-9a78-41cb-8991-022b0ff2c19c \
        --dest-conversation e5e26e38-53a2-4f22-b1cb-ae867357df83

# 从指定检查点分支
ax fork --src-conversation 38460323-9a78-41cb-8991-022b0ff2c19c \
        --dest-conversation e5e26e38-53a2-4f22-b1cb-ae867357df83 \
        --src-seq 12

追踪

在 Web UI 中可视化 Agent 执行的追踪,直接从事件日志获取数据。

ax trace --conversation <对话ID> [--addr <地址>] [--config <配置文件>]

这将解析执行日志并启动一个本地 Web 服务器,自动在浏览器中打开。

选项:

  • --addr:服务器监听地址(可选,默认为 “localhost:8080”)
  • --config:YAML 配置文件路径(可选,默认为 “ax.yaml”)

示例:

# 在默认服务器 localhost:8080 上追踪
ax trace --conversation 1a6e0b29-87c2-4af0-81ac-0c73bf8fa293

# 在自定义服务器地址和端口上追踪
ax trace --conversation 1a6e0b29-87c2-4af0-81ac-0c73bf8fa293 --addr 0.0.0.0:9090

Gemini Agent

AX 包含一个内置的 Gemini Agent,可用于根据给定提示生成文本。该 Agent 注册为 gemini,可以独立触发或在自定义 Agent 实现中使用。

ax exec --agent gemini \
  --input "你好,最近怎么样?"

认证

Gemini Agent 支持使用 Google AI Studio 或 Vertex AI 进行认证:

# AI Studio API 密钥认证。
export GEMINI_API_KEY="your-api-key"

# Vertex AI 认证,确保已设置应用默认凭据,
# gcloud auth application-default login。
export GOOGLE_CLOUD_PROJECT="your-project-id"
export GOOGLE_CLOUD_LOCATION="us-central1"
export GOOGLE_GENAI_USE_VERTEXAI=True

扩展

技能

AX 内置对 Agent 技能的支持。更多信息请参见技能

Bash 工具

内置规划器配备了一个 bash 工具,使其能够执行通用 shell 命令。该工具会自动适应用户的操作系统。为了安全和可控,bash 工具发起的任何执行都需要通过确认流程获得用户明确批准后才能运行。

自定义 Agent

AX 支持多种方式将您自己的 Agent 带入运行时。

远程 Agent

远程 Agent 在 AX 控制器外部运行,并通过协议边界调用。

  • 远程 Agent 直接实现 AX 的原生 AgentService
  • ADK Agent (Python) 将 Google ADK Agent 作为远程 Agent 运行。
  • A2A Agent 通过 AX 的 A2A 桥接器连接使用 A2A 协议(https://github.com/a2aproject/A2A)的 Agent。
  • Colab Agent (实验性) 在远程 Google Colab 会话中运行 Python 脚本或 Notebook。

请注意,AX 正在积极开发其可恢复流和 Agent 通信协议;这些接口在稳定版本发布前将会变化。如果您正在实现 AX 原生的远程 Agent,请参阅 proto/ax.proto 中的 AgentService

AX 不是什么?

  • 托管服务。AX 是自托管而非托管服务。我们的目标是让用户能够轻松地在自己的 Kubernetes 集群上部署和运行它。
  • Agent 框架。AX 与构建 Agent 所使用的框架无关。我们正在与其他框架作者(例如 ADK)合作,以提供便捷的集成。
  • 特定的框架(如特定的编码 Agent,例如 Antigravity)。AX 提供围绕框架的服务层,与框架实现无关。很快我们将允许用户自带框架。
  • 模型特定的控制器。AX 与所使用的模型无关。

路线图

以下是即将推出的功能和计划变更的概览:

  1. 将 Antigravity 作为内置框架
  2. 支持 BYOH(自带框架)
  3. 启用子 Agent 的挂起/恢复
  4. 支持子 Agent 中的工具调用审批
  5. 改进恢复协议

贡献

请参阅 CONTRIBUTING.md 指南了解如何为该项目做出贡献。我们正处于 AX 的重大重构阶段,因此在核心稳定之前暂不接受新贡献。不过,在此期间,我们鼓励您提交 Bug 和功能请求。

致谢

我们感谢 Google DeepMind 在分布式框架方面的早期工作,这些工作极大地影响了 AX。我们感谢 Google Kubernetes Engine 团队在隔离、恢复和作业调度方面的深入贡献。

许可证

Apache 2.0

相似文章

关于欧洲技术主权及欧盟开源战略的通信

Hacker News Top

欧盟委员会宣布了一项全面的技术主权战略,包括《芯片法案2.0》、《云与人工智能发展法案》、欧盟开源战略,以及数字化和人工智能在能源领域的路线图。

有哪些鲜为人知的最强地下AI工具?

Reddit r/artificial

六个强大但知名度较低的AI开发者工具列表:Instructor(用于结构化JSON输出)、Octopoda(用于智能体记忆)、E2B(安全沙箱)、Firecrawl(网站转Markdown)、Composio(应用集成)和LiteLLM(多模型API)。

AI智能体的执行质量在多大程度上实际上是一个数据问题?

Reddit r/AI_Agents

作者反思了为什么在演示中表现良好的AI智能体在实际工作流中经常失败,认为执行质量可能更多地与数据问题(任务示例、工具轨迹、评估集)相关,而不仅仅是推理或规划,并指出他们正在通过OpenDCAI/DataFlow项目探索这个问题。

改变我们开发Ladybird的方式

Lobsters Hottest

Ladybird浏览器正在关闭公开的拉取请求,并将代码变更限制为仅限项目维护者,理由是AI工具使得评估贡献者可信度变得更加困难,且项目在接近Alpha发布时需要更严格的安全性。