如何设计可恢复的执行系统AX值得借鉴的5个设计决策【免费下载链接】axGoogles open agentic orchestration runtime项目地址: https://gitcode.com/GitHub_Trending/ax11/axAXAgent Executor是 Google 开源的分布式智能体编排运行时核心能力是可恢复执行Agent 任务即使失败、中断或机器宕机也能从断点自动恢复继续运行。对于想要构建长时运行、高可靠 AI Agent 系统的新手和工程师来说AX 源码里藏着 5 个可以直接借鉴的设计决策——单写者架构、追加事件日志、幂等操作、挂起/恢复的 Actor 模型、可插拔执行边界。下面结合源码目录逐个拆解帮你理解可恢复执行系统到底是怎么设计出来的。先搞清楚AX 解决什么问题Agent 正在从一问一答的助手演变为长时间自主工作的工人。这带来一个基础设施难题一个 Agent 可能高强度计算 1 分钟然后闲置数小时甚至数天等待人工审批有状态的计算单元在闲置期一直占着资源成本高到不可接受传统 Kubernetes 是为无状态微服务和可预测的批处理设计的并不擅长挂起和恢复有状态、沙箱化的 Agent ActorAX 的定位就是补齐这一层从可挂起/可恢复的镜像中动态创建隔离环境执行 Agent 任务并且原生支持失败恢复与执行续接。整体架构可以在 README.md 的架构图中看到客户端通过可恢复流连接 AX ServerServer 负责读写事件日志并调度 Agent Substrate 上的 Actor。决策一单写者架构Single-Writer用简单换一致性多副本写状态是分布式系统里最容易出 bug 的地方。AX 的做法很克制每个会话conversation同一时刻最多只有一个执行者。控制器 internal/controller/controller.go 是全局的单写者编排器协调 Agent 循环、管理执行状态执行边界接口 internal/harness/harness.go 的注释明确写了这个约定控制器必须保证每个 conversation 同时最多存在一个 Execution这个设计的好处非常实际下游实现可以放心地用最后写入胜出的简单存储而不需要复杂的比较交换CAS机制因为根本不存在并发写。如果你在设计多节点 Agent 系统一个会话一个写者是性价比极高的一致性保障。决策二追加式事件日志让状态可以重放恢复这是 AX 可恢复能力的地基。事件日志Event Log是一个持久化、只追加的操作记录日志中的每个条目都是一个原子步骤按顺序重放日志就能让执行器回到一个一致状态并从该状态继续执行。定义见 internal/controller/eventlog/eventlog.go核心接口只有三个方法方法作用Append把一步事件追加到日志末尾Events读取某个会话的全部事件Close释放底层资源日志内容覆盖执行的全生命周期输入、中间输出、PENDING/COMPLETED/FAILED状态。控制器在 controller.go 的ResumptionState中扫描日志就能判断会话处于什么状态、用的是哪个 harness——状态不保存在内存里而保存在日志里。存储层也是可插拔的默认用 SQLite本地开发零依赖生产可切到 PostgreSQL配置见根目录 ax.yaml 的eventlog段实现位于 internal/controller/eventlog/。给新手的启示与其保存当前状态再尝试恢复不如记录所有发生过的事需要时重放。这是事件溯源Event Sourcing模式简单且极其可靠。决策三幂等操作让重试天然安全分布式恢复的前提是任何一步操作重复执行都安全。AX 在 Actor 创建上给出了教科书级的示范。看 internal/harness/substrate/substrate.go 的Start方法它的恢复流程是CreateActor(conversationID)创建 Actor——代码注释明确写道创建是幂等的后续轮次中 Actor 已在上轮创建并挂起返回 AlreadyExists 是预期且正常的于是直接放行ResumeActor把 Actor 调度到 worker 上并拿到可路由的 IP用带指数退避的健康检查最长 60 秒等待 harness 就绪这意味着请求发出去后超时了没关系重发一次CreateActor已经存在就跳过。控制客户端封装在 internal/ate/client.goCreateActor/ResumeActor/SuspendActor三个方法各自独立可重试。幂等设计口诀创建类操作用已存在则视为成功操作类操作用带唯一标识去重。做到了这一点恢复逻辑才能简单粗暴地从头再试一遍。决策四挂起/恢复的 Actor 模型闲置不再烧钱传统容器跑完任务就销毁状态全丢而传统有状态服务又必须一直活着。AX 引入了中间态Suspend挂起与 Resume恢复。执行一轮结束后Close方法substrate.go会立即调用SuspendActor把 Actor 的资源归还到待命池——进程停了但身份和可恢复性还在。下一轮对话到来时再ResumeActor把它调度到某个 worker 上。这正是针对 Agent 工作负载突发式bursty特征的设计计算密集时全力运行等待审批时零成本挂起。配合事件日志恢复时逻辑状态从日志重放、计算环境从快照拉起两层状态各管一摊。对应的 CLI 体验非常简洁一个参数即可续接未完成的执行ax --conversation edf98ef5-4bb1-4a9e-a091-3a77e03727e6 --resume决策五Harness 抽象把执行什么变成可插拔的最后一个决策关乎可扩展性AX 把实际干活的 Agent 框架抽象成Harness执行器接口与运行时彻底解耦。internal/harness/harness.go 定义两个核心接口Harness能启动会话和ExecutionRun流式执行、Queue排队输入、Close释放资源internal/controller/registry.go 提供注册表按 ID 注册、查找 harness并支持设置默认值内置的 Antigravity harness 实现见 internal/harness/antigravity/远程沙箱版实现在 internal/harness/substrate/这个解耦带来两个好处框架无关任何传统 Agent、工具调用循环、甚至大模型本身都能包装成 harness以及一致性校验同一会话不允许中途更换 harnesscontroller.go 中会显式报错拒绝避免恢复时状态对不上。想给 Agent 扩展技能AX 还有独立的 Skills 模块internal/skills/示例见 examples/skills/README.mdharness 启动前技能会被物化到磁盘执行器按需消费。5个决策一张表总结#设计决策一句话价值关键源码1单写者架构每个会话一个写者免去分布式锁的复杂度internal/controller/controller.go2追加式事件日志状态可重放、可审计、可恢复internal/controller/eventlog/3幂等操作失败重试、断点续跑天然安全internal/ate/client.go4挂起/恢复 Actor闲置零成本唤醒即恢复internal/harness/substrate/substrate.go5Harness 可插拔抽象框架无关运行时与执行解耦internal/harness/harness.go如何借鉴给新手的落地清单如果你要在自己的项目里引入可恢复执行建议按这个顺序实践先建事件日志把每次输入、输出、状态变更都追加记录恢复逻辑 重放日志决策 2约束写者数量单会话单写者存储层保持简单决策 1所有外部操作做幂等创建加已存在即成功调用加唯一 ID决策 3给执行单元设计挂起/恢复语义哪怕只是保存状态后释放资源也远胜于常驻决策 4最后再抽象执行接口让业务逻辑可替换、可测试决策 5AX 目前仍处于早期快速迭代阶段核心与恢复协议尚在完善README 顶部有明确说明但上述 5 个决策来自 Google 内部多年分布式执行引擎的沉淀方向上是稳定可靠的。项目配置示例见根目录 ax.yamlKubernetes 部署方案见 manifests/README.md欢迎从 internal/controller/ 的源码开始阅读理解这些决策是如何落地的。【免费下载链接】axGoogles open agentic orchestration runtime项目地址: https://gitcode.com/GitHub_Trending/ax11/ax创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
