一条 可恢复、可审计、可扩展 的执行链把事情串起来。AX 放在技术栈的哪个位置先看它在技术栈里的位置。AX 既不是模型层也不是某个具体框架的替代品。 它插在 Agent 应用和底层基础设施中间负责把上层的任务意图翻译成一套可追踪的执行过程。mermaid-01.png图AX 位于 Agent 应用与底层执行基础设施之间负责托住执行过程。这层位置很关键。它意味着 AX 对上层 Agent 实现基本保持中立对下层模型也不强绑定。你可以继续用 ADK、LangGraph甚至是自己的 Harness也可以换模型而不必动到 AX 的核心职责。换句话说它想管的是 执行不是 思考。真正的核心不是 Agent而是 Controller系统里最重要的组件不是某个 Planner Agent而是 Controller。因为一旦把 Agent 执行当成生产系统问题第一优先级就不再是“会不会推理”而是“谁在协调、记账、路由和兜底”。mermaid-02.png图Controller 通过 Executor、Registry 和 Event Log 统一托管执行链。这里有三个角色值得单拎出来Executor 决定这次任务该往哪里跑什么时候继续什么时候停。Registry 把可用的 Agent、Tool、Skill 暴露成一张可查询的能力表运行时不用写死依赖。Event Log 不是普通日志它记录的是 执行进度本身所以它参与恢复不只是排错。这也是 AX 和不少“框架式 Agent 编排器”的分水岭。后者更关心节点之间怎么流转AX 更关心 流转发生以后系统能不能把整个过程可靠地托住。一次任务真正怎么跑完AX 并不是把所有事塞给单个 Agent而是把请求拆成几段入口路由、Planner 分析、远程 Agent 执行、Tool 调用、状态回写。中间哪一段出问题Controller 都能知道当前停在什么位置。mermaid-03.png图一次任务会经过路由、规划、远程执行、工具调用和状态回写。这条链路里最容易被低估的是 Resumable Stream。如果只是普通 RPC连接断了就断了调用方只能重试。AX 把执行过程做成 可恢复的流等于承认一件很现实的事长任务在真实环境里就是会被打断系统应该把“中断”当成常态而不是异常。分布式不是卖点是隔离故障域的手段很多人一看到“分布式运行时”会先想到扩容。AX 这套设计更实在它首先解决的是 隔离。Controller、Skills、Tools、Agents 都可以独立部署在不同进程甚至不同节点远程 Agent 通过 gRPC 和 Controller 通信失败边界天然被切开了。这带来几个直接好处远程 Agent 跑崩不会把 Controller 一起拖下去。高风险工具可以丢到单独环境里跑权限边界更干净。资源型任务和轻量型任务能分开调度不必共享一个执行池。某个 Agent 的噪声日志、内存暴涨、重试风暴不会污染整条链路。不少介绍会把它放成一个单独能力点但我觉得它其实是整套系统的基础假设Agent 不该默认和调度器同生共死。Event Log 不是辅助信息它就是恢复现场真正让长任务可恢复的不是简单保存一个“任务成功 / 失败”状态而是把执行过程按序号持续落盘让系统随时知道上次稳定位置停在哪。mermaid-04.png图Event Log 记录稳定序号让长任务能从中断点继续。这类设计在几个场景里尤其有用深度研究类任务 动辄跑几十分钟中途掉线很常见。多工具链路 往往包含外部 API失败率不受你控制。人工介入审批后继续执行天然就是分段运行。Event Log 是 single source of truth。这不是修辞。只要你真的想做恢复、回放、审计和分叉系统就必须承认有一份权威执行历史存在而且它不能只放在内存里。AX 为什么坚持做框架无关接入AX 的接入方式做得很杂但这个“杂”是有理由的。它不要求所有 Agent 都按一种写法来实现而是给了四条进场路径接入方式 适合什么场景 运行时特征原生远程 Agent 已经有独立 Agent 服务 通过 AgentService.Connect 建立 gRPC 双向可恢复流Google ADK Agent Python 生态里的 ADK 项目 由 Python ADK Agent 直接接入底层通信封装为 gRPCA2A Bridge Agent 团队已有 A2A 兼容 Agent 通过 A2A Bridge 转换协议与标头Colab Agent 研究和实验任务 支持把 Python 脚本或 Notebook 作为执行入口mermaid-05.png图AX 通过多种接入模式兼容已有 Agent 生态而不要求统一重写。这背后的判断很工程化企业里不会只有一种 Agent 形态。 有人用 Python有人已经做了 A2A 协议有人只是想把现成脚本纳入统一调度。让这些东西都重写一遍系统很难落地。把协议边界做厚一点反而更现实。审计和权限别散在各个 Tool 里AX 最像“基础设施”而不是“框架”的地方就在 审计与策略控制。所有用户请求、Agent 请求、Tool 调用都经过 Controller 这一个控制面于是权限校验、调用记录、执行限流和审批流可以集中处理。mermaid-06.png图把权限、限流、审计和审批放回控制面才能真正治理 Agent 行为。这套做法的好处很直接安全规则不会散落在每个 Tool 的私有实现里。需要人工确认的危险操作比如 Bash 执行可以被统一拦下来。出了问题以后能回溯到是哪次请求、哪个 Agent、哪一步工具调用触发的。尤其是 Bash Tool 的“需用户确认才能执行”看起来像个小功能其实透露出整套系统的安全姿势默认不信任 Agent 的执行冲动必须给控制面留一个人工刹车。Session Fork 解决的不是重试而是低成本试错如果只想断点恢复事件日志已经够用了。AX 还额外做了 会话分叉这说明它想支持的不只是“接着跑”还有“从历史某一点拐出去跑另一条线”。mermaid-07.png图同一份执行历史既能恢复原链路也能从稳定点分叉试错。这在几个地方很有用What-if 分析不想污染原任务链路。回溯重试直接从失败前的稳定点重开。长任务跑到一半想验证另一套参数不必整段重来。这也是为什么 Fork 和 Resumption 必须分开看。恢复解决的是可靠性分叉解决的是探索效率。 两者依赖同一份事件历史但目标并不一样。如果把 AX 当成一句话它在补“Agent 缺的控制面”Google AX 想解决的不是 Agent 是否足够聪明而是 Agent 一旦进入真实执行环境系统还缺哪几块硬骨头。它给出的答案也很明确用 Controller 把执行调度从 Agent 本体里抽出来。用 Event Log 把任务状态外化支持恢复、回放和分叉。用 分布式部署 和 Actor 隔离 切开故障域。用 统一控制面 接住审计、权限、限流和审批。
