Python京东价格监控系统源码拆解：爬虫、存储与通知实战
2026/9/23 19:55:28
把 Agent 当集群工作负载管：Google AX 的四个原语和一次"状态大搬家"
TL;DR 速览
- 要解决的问题：Agent不是无状态微服务、也不是跑完就退的批处理——它攒状态、要隔离、会调外部 API，而且没人盯着就会在循环里烧钱
- 四个声明式原语：
Task（隔离沙箱）/Workspace（预连线 Git、MCP、技能包）/Gateway（出站锁到显式白名单）/Model（平台自身用哪个 LLM）- CLI 刻意做成
kubectl的形状：ax apply/get/describe/watch/delete，外加ax ssh钻进沙箱、ax suspend/ax resume挂起恢复- v0.3.0（2026-09-20）拆成三个二进制：
ax-server（gRPC）/ax-controller（Redis Streams）/ax-task-runner（沙箱 worker），任务状态从 K8s 自定义资源搬去了 Redis- 上生产前必须知道：API 是
v1alpha1，README 自带 Warning——核心概念仍在打磨，稳定版之前很可能出破坏性变更
Google 开源了 AX，定位是高吞吐、声明式的编排器，用来在集群里跑"数十亿"自主 Agent 工作负载，底层依赖 Agent Substrate 提供沙箱化执行。它刚发布v0.3.0（2026-09-20），仓库 ★4.2k、Apache-2.0、Go 编写。同时ax这个 CLI刻意做成kubectl的形状——如果你用过 K8s，ax apply那一套不需要重新学。
它值得写，不是因为"又一个 Agent 框架"，而是因为它把一件被大多数框架绕开的事摆到台面上：Agent 在集群里的资源画像和以往任何一种工作负载都不一样，硬塞进 K8s 的既有抽象会同时踩三个坑。这篇文章拆它的原语设计、v0.3.0 那次状态搬家，以及现在能不能上生产。
一、K8s 为什么跑不好 Agent
AX 官方文档里有一段判断很直白：Agent 既不是无状态微服务，也不是跑到结束就退出的批处理作业。
把 Agent 硬塞进这两种抽象，会撞上三个具体的错配：
| 特征 | Agent 的真实行为 | 与既有抽象的冲突 |
|---|---|---|
| 有状态 | 会话中累积上下文、工具结果、中间计划 | 无状态服务假设可以随时被替换、被重建 |
| 突发 + 长等待 | 等模型 API、等工具返回、等人审批，干一分钟挂十分钟 | K8s 的调度与健康检查基于"一直在干活"的假设 |
| 冷启动敏感 | 沙箱要装工具链、拉 Git 仓库、验依赖 | 容器冷启动 + 依赖安装的时间，可能比真正干活的时间还长 |
第三点是最容易被低估的。一个 Agent 任务如果实际执行 30 秒，但环境准备要 90 秒，那集群的吞吐就被准备时间锁死了。所以 AX 把"预连线环境"做成了独立的原语（Workspace），而不是让每个任务自己装一遍。
还有一个 K8s 生态里的隐性成本：把每个 Agent 任务都表达成一个自定义资源，任务数量一大，etcd 会先扛不住。这正是 v0.3.0 那次架构搬家的直接原因，下面第四节细讲。
二、四个原语：一条 YAML 里的四种约束
AX 把所有东西都表达为ax.io/v1alpha1的 manifest，一条命令 apply 下去。四个原语对应四类约束：
| 你想要 | AX 给的 | 约束类型 |
|---|---|---|
| 在隔离沙箱里跑不可信 Agent 代码，带 CPU/内存限制 | Task | 执行边界 |
| 预连线 Git 仓库、MCP 服务器、技能包，让每个 Agent 一启动就是热的 | Workspace | 启动成本 |
| 把出站流量锁到一份显式主机白名单 | Gateway | 网络边界 |
| 配置平台自己用哪个 LLM，凭证从 Kubernetes Secret 取 | Model | 平台自身的模型依赖 |
看一条最小的任务定义，能直观感受这套设计的取舍：
# task.yamlapiVersion:ax.io/v1alpha1kind:Workspacemetadata:name:golangspec:git:-repo:https://github.com/golang/go.gitbranch:"my-fix"---apiVersion:ax.io/v1alpha1kind:Taskmetadata:name:testspec:workspaces:-name:golanggoal:"Ensure that Go tool chain is available and is built from source"debug:true# 打开后才能 ax ssh 进去两个细节值得单独拎出来：
第一，Workspace的goal是自然语言。上面那句"确保 Go 工具链可用且是从源码构建的"不是给脚本解析的指令，是交给 Agent 在首次启动时自己去装工具链、自己验依赖的目标描述。这是这套设计里最激进的一处取舍：环境准备本身也变成一个 Agent 任务。好处是不用为每种技术栈写一份 Dockerfile；代价是环境构建变得不确定——同一份 goal 两次跑出来可能不同。
第二，debug: true是进沙箱的前提。默认状态下你进不去运行中的沙箱，必须先显式打开。也就是说**"可观测"在这里是被设计成一个开关的，而不是默认能力**。生产环境下这个默认值是安全的，但排查问题时别忘了它。
三、CLI：刻意做成 kubectl 的形状
ax通过 gRPC 与控制平面通信，命令集和 kubectl 高度对应。日常动作长这样：
ax apply-fexamples/task.yaml# 一份文件里可以同时放 Task + Workspace + Gateway + Modelax get tasks# 列表axwatchtask task123# 流式看 phase 与 condition 变化axsshtask123 --ls-la/workspace# 钻进沙箱跑一条命令axsuspendtask task123# 检查点并暂停ax resume task task123# 从断点继续ax watch和ax suspend/ax resume是这套 CLI 里最有信息量的两个。
watch输出的是phase 与 condition 的迁移流。这直接对应第一节说的"突发 + 长等待"——一个 Agent 大部分时间在等，你真正需要看的不是它"在不在跑"，而是它卡在哪个阶段：等模型、等工具、等审批，三种状态的处置完全不同。
suspend/resume官方给的是亚秒级的挂起恢复。它的价值不在"省资源"，而在成本控制：一个等人工审批的 Agent 如果一直挂着占沙箱，那条沙箱和它预装好的环境就一直在计费；能挂起就意味着"等待"这段时间可以不占执行资源。
还有ax ctx和后台 tunnel 这两个小设计值得注意：ax跟随当前 kube context，切集群之后它会自动解析并在后台建隧道连到那个集群的控制平面（状态存在~/.ax/tunnels）。这让本地 CLI 不用手配一堆 server 地址，代价是多了一个后台常驻进程——排查连不上控制平面的问题时，记得先看这个隧道。
四、Gateway：网络出口才是成本闸门
Gateway是四个原语里最容易被略过、但在生产里最该先配的一个：
- 出站流量锁定到显式主机白名单
- 凭证注入——Agent 代码不直接持有密钥
为什么这条重要？因为 Agent 最常见的失控形态不是崩溃，而是在循环里调用外部 API。模型调用、搜索 API、第三方工具，只要有凭证、只要没有被拦住，一个写错的循环就能在几十分钟里产生一张很难解释的账单。
把出站限制成白名单，等于给"失控"设了一个物理上限：它最多只能打到你在白名单里放行的那些主机上。这在工程上比事后审计有效得多——审计是发现已经花掉的钱，白名单是让钱花不出去。
判断有没有必要现在就配它，用一个简单的问题：你的 Agent 需要访问的主机，你能不能列清楚？能列清就配白名单，列不清说明这个 Agent 的边界还没设计完。
我给这类平台做接入评估时，第一步不是看它的能力清单，而是列一份"它默认能连到哪、能读到什么、能写回哪里"的三栏表，再逐条问"这一项我需不需要显式关掉"。这份表比读文档快，也比事后审计便宜。我的表模板和几个平台的实测结果攒在 墨衍 里，跟选题素材放一起，回头做选型时直接调出来比。
五、v0.3.0 那次搬家：状态为什么必须离开 etcd
v0.3.0 的核心变化是把单体拆成三个二进制：
| 二进制 | 职责 |
|---|---|
ax-server | 对外 gRPC 服务，CLI 和客户端连的就是它 |
ax-controller | reconciler，基于Redis Streams做横向扩展 |
ax-task-runner | 沙箱内的 worker，负责实际执行 |
最关键的一行信息是：任务状态从 K8s 自定义资源搬到了 Redis。官方给的理由也很直白——为了容纳海量短命任务而不压垮 etcd。
这条经验值得单独记下来。把"每个任务一个自定义资源"当成设计起点很自然，但它有一个隐含的容量假设：任务数量在 etcd 能承受的量级内，且任务寿命不会太短。Agent 负载两条都不满足——数量可能极多，单个寿命可能只有几十秒。用 K8s 存任务状态，等于用一个为"稳定配置"设计的存储去扛"高频短命对象"的写入量，这不是调参能解决的，得换存储。
同时这个版本做了减法：移除了旧的 Python harness、ATE client、SQL 事件日志和 skill 示例。删掉的东西往往比新增的更能说明项目走向——移除 Python harness 意味着他们认定了"runner 只需要一个实现"，而不是维护多语言并行方案。
六、现在能不能上：三个明说的风险
AX 的 README 里自带一段Warning，原文意思是：核心概念、协议与规范仍在积极打磨，在稳定版之前很可能会引入重大破坏性变更。配套的事实是 API 版本号还处在v1alpha1。
具体到落地，风险有三层：
- API 会变。
ax.io/v1alpha1意味着你写的 manifest 在升级时有很大概率要改。现在接入的正确姿势是当容器编排层用，不要把它嵌进自己的产品契约里。 - 依赖一个不算轻的底座。要跑控制平面需要 Kubernetes 集群、
ko、一个集群能拉的镜像仓库，以及一个可达的 Agent Substrate Control API。这是一套完整的集群依赖，不是本地起的单二进制。 - 它是声明"跑数十亿任务"的项目，但公开的稳定能力还在早期。这个规模目标的表述是设计意图，不是当前实测结果，评估容量时不要按这个数去规划。
综合下来的判断：如果你的团队已经在用 K8s、并且已经在为"Agent 任务怎么编排"自己造轮子，AX 现在值得进沙箱环境试——它能省掉的是"自己设计 Task/Workspace/Gateway 语义"这一步，以及 v0.3.0 已经替你做掉的"状态存哪儿"的决策。反过来，如果只是想在自己的笔记本上跑几个 Agent 任务，这套东西的重量级远超需求，一个进程内调度器就够了。
它真正的价值可能不在当下能不能用，而在于它给出了一组候选答案：Agent 的工作负载抽象该叫什么、环境该不该被声明成自然语言目标、网络出口该不该变成一等原语、任务状态该不该离开 etcd。这四个问题，每个做 Agent 平台的人迟早都要回答一遍——有人已经把答案开源出来了，哪怕还带着 alpha 标签。