Google 开源 Agent Executor:你的 AI Agent 终于不用每次断线就从头来了

Google 开源 Agent Executor(AX),专为生产环境长周期 Agent 设计的分布式运行环境。针对状态丢失、并发冲突等运维痛点,AX 提供持久执行、安全沙箱、会话一致性、连接恢复及轨迹分支五大核心能力,且保持模型与框架无关。配套项目 Agent Substrate 优化了 K8s 资源调度。该项目目前处于早期预览阶段,旨在填补 Agent 落地基础设施空白,建议用于技术预研而非直接投产。

发布于2026年5月28日 14:11
编辑零重力瓦力
评论0
阅读141

谷歌开源 Agent Executor:为了让 Agent 在生产环境“活下去”,它拼了

5 月 20 日,Google 开源了一个叫 Agent Executor(简称 AX)的项目。简单来说,这是一个专为“长跑型” Agent 设计的分布式运行环境。它的核心使命只有一个:让你的 Agent 能够“持久地活下去”

为什么 Agent 一进生产环境就“见光死”?

很多团队都有过这种体验:写好的 Agent 在 Demo 里跑得行云流水,简直完美。可一旦扔进真实的生产环境,跑了三个小时突然掉线,再连上时,之前的状态全丢了。或者多个用户同时操作,共享的数据直接被并发写入给搞崩溃了。再或者,遇到需要人工审批的步骤,Agent 等着等着就超时挂掉了。

这些让人头疼的运维痛点,LangChain 和 AutoGen 其实都没帮你解决。因为它们擅长的是“排兵布阵”(编排),而不是“端茶倒水、修路搭桥”(运维)。

博通(Broadcom)的高级可靠性工程师 Advait Patel 表示:“现有的框架做个原型还行,但 Agent 要是跑上几天甚至几个星期,根本撑不住。一旦 Agent 开始在真实系统里执行核心业务,你绝对承担不起它半途失忆的代价。”

这绝不是个别现象。过去一年,无数团队把 Agent 做出来了,却始终无法让它“跑得稳”。Google 自己在内部跑 Agent 时也踩了无数这样的坑,所以有了 AX。

拆解 AX 的五个“硬核”能力

AX 是怎么解决这些问题的?它主要带来了五个核心能力:

  1. 死活不丢状态(持久执行):Agent 执行过程中的所有事件、日志和快照,AX 都会自动记录。服务器崩了?需要人工审批暂停了?没关系,重启或恢复后,它能从断点精准继续,一点状态都不丢。这可不是开发者自己苦哈哈写代码做 checkpoint,而是 AX 在底层自动帮你搞定的。
  2. 自带安全结界(安全沙箱):Agent 经常需要自动生成代码、处理敏感数据,或者面对多用户并发。安全问题绝对不能事后补救。AX 在架构底层就内建了沙箱隔离,哪怕某一个 Agent 抽风或者写了恶意代码,也绝对影响不到整个系统。对企业合规来说,这是刚需。
  3. 彻底告别数据冲突(会话一致性):在分布式系统里,多个 Agent 节点如果同时去改同一个数据,极易把数据写脏。AX 采用了“单写入者(Single-Writer)”架构,保证同一时间只有一个地方能写数据,从根源上掐死了并发冲突的可能。
  4. 网络抖动也不怕(连接恢复):客户端断线重连是家常便饭。AX 能根据上一次收到的响应序列号,继续精准推送消息,不丢包也不重复。对于要跑很久的工作流,网络抖动是常态,AX 帮你想好了退路。
  5. 随时开平行宇宙(轨迹分支):开发者可以从任意一个检查点“分叉”出一条新的执行路径,去测试不同的决策走向,而且完全不影响主线。这在做 A/B 测试或者回溯排查 Bug 时,简直是神器。

架构设计:不玩“全家桶”捆绑

AX 最聪明的一点在于它“不绑架用户”。它是模型无关(model-agnostic)且框架无关(harness-agnostic)的。你可以继续用你喜欢的 LLM 和规划逻辑,AX 只在幕后默默负责执行、持久化和协调。

在部署上,企业可以灵活混搭:既可以用 Google 的托管服务,也可以用自己开发的 Agent。可以用 ADK 构建,也可以用 LangChain 或 LangGraph。甚至可以通过协议对接外部 Agent,或者直接跑在本地机房。数据和策略,依然牢牢掌握在你自己手里。

不过,Avasant 的研究总监 Gaurav Dewan 也提了个醒:AX 搞定的是“运维”层面的活。至于更上层的“治理”挑战(比如出了事谁负责、决策怎么解释、跨系统安全访问等),目前还在演进中。AX 强健了骨架,但 CIO 们关心的信任和合规,依然需要额外的配套方案。

连 Kubernetes 调度都帮 Agent 订制了

还有一个容易被忽略的配套项目:Agent Substrate。这是 Google 联合 GKE(谷歌 Kubernetes 引擎)团队专门为 Agent 负载打造的开源 K8s 抽象层。

传统的计算资源调度对 Agent 非常不友好。因为 Agent 经常要花大量时间等外部输入(比如等用户回复、等接口响应),这时候它不干活,却白白霸占着计算资源。

Agent Substrate 的做法是:动态地把 Agent 在不同的计算节点间迁移。有活干时,立马分配资源。进入等待状态时,就把资源释放掉。这样既能降低延迟,又能省下大笔的算力开销。对于要跑大规模 Agent 集群的团队,这套基础设施非常关键。

避坑与实操建议

如果你正准备把手头的 Agent 推向生产环境,建议分三步走:

  1. 先对齐需求:评估你的 Agent 到底需不需要“持久执行”。如果是跑几分钟就完事的简单任务,用 AX 属于杀鸡用牛刀。但如果是需要跑几个小时甚至跨天、跨周的复杂任务,必须认真研究一下。
  2. 尝鲜体验:目前 GitHub 仓库 google/ax 已经开放。它是用 Go 语言写的,一行命令就能安装 CLI:
    go install github.com/google/ax/cmd/ax@latest
    
    不过要注意,现在还处于 Early Preview(早期预览)阶段,API 随时可能变,适合技术预研,千万别直接往生产环境上怼
  3. 关注生态:如果你打算用 K8s 部署 Agent,可以同步关注一下 Agent Substrate(ate.dev),它俩搭配起来用效果最好。

总结

Agent Executor 解决的,其实是行业里那些**“枯燥、不性感、但能要命”**的底层问题。

现在做 Agent 的人,大多把精力放在如何让 Agent 更聪明、更懂人话上,很少有人愿意下苦功夫去修路。但所有真正做过落地的人都知道,Demo 到生产环境之间隔着一条鸿沟。

Google 把自己踩过的坑总结成这个开源运行环境,其意义不亚于当年 Kubernetes 之于容器编排。虽然项目现在还很早期,文档不全、API 不稳,但它指明了一条无比正确的路:Agent 需要属于自己的专属运行环境,就像容器需要 Docker,编排需要 K8s 一样。

相关文章

把 LLM 当文字编辑而非代写枪手:两条铁律与改稿提示词
智能体工程
2026年9月18日
0 条评论
小创

把 LLM 当文字编辑而非代写枪手:两条铁律与改稿提示词

使用 LLM 辅助写作应将其定位为文字编辑而非代写枪手。核心原则包括绝不采纳模型生成的具体词汇及禁止其提供夸奖,以避免内容同质化。推荐采用“诊断-重写-比对”三阶段改稿流程,利用模型查找语法与逻辑硬伤,但由作者亲自重写。实践中可借助专用提示词库或本地工具提升效率。此外,需警惕长上下文压缩摘要可能引发的指令注入风险。AI 仅是批判性审视的效率放大器,人类创作者必须始终掌握写作主导权。

#AI写作#提示词工程#AI工具
阅读全文
Plugin4Shell 零点击攻破四大编程智能体 SHA 固定
智能体工程
2026年9月18日
0 条评论
小创

Plugin4Shell 零点击攻破四大编程智能体 SHA 固定

安全团队 AIR 披露高危漏洞 Plugin4Shell,影响 Claude Code、Codex 等四大主流 AI 编程智能体。该漏洞利用 Git 分支命名解析歧义绕过 SHA 固定机制,使攻击者可通过插件后台自动更新实现零点击远程代码执行。这是 AI 智能体生态首个分发层供应链漏洞,打破了传统安全审阅的信任假设。目前 Anthropic 和 OpenAI 已修复,Google 建议迁移,Microsoft 尚未发布补丁。开发者需在客户端增加 HEAD 哈希校验以防范风险。

#智能体#AI 编程#安全
阅读全文
Pi 与 HarnessRouter 实操,同一模型成本差 5 倍
智能体工程
2026年9月18日
0 条评论
小创

Pi 与 HarnessRouter 实操,同一模型成本差 5 倍

评测显示,同一模型在不同外壳下编程成本差异可达 2 至 5 倍,源于臃肿框架注入冗余 Prompt 产生的“外壳税”。极简外壳 Pi 通过精简工具与上下文,在保持成功率的同时大幅降本。企业可利用 HarnessRouter 网关动态调度多外壳以优化成本。落地时需遵循测底噪、匹配模型工具语法及加装沙箱三原则。未来核心挑战在于平衡极简外壳的低 Token 消耗与复杂长程任务的容错机制。

#智能体#AI编程#开源工具
阅读全文
互动讨论

评论区

围绕《Google 开源 Agent Executor:你的 AI Agent 终于不用每次断线就从头来了》展开交流,未登录用户可浏览评论,登录后可参与讨论。

评论数
0
登录后参与评论
支持发表观点与回复一级评论,互动后将同步到消息中心。
登录后评论
暂无评论,欢迎成为第一个参与讨论的人。