📌 项目地址：google/ax | ⭐ 7,285 颗星 | 🔧 Go | 📜 未标注
=
Agent 是一种没人会运维的工作负载
写过 Agent 的人都知道，框架已经够多了，LangChain、CrewAI 各有各的写法。但这些框架只管“单个 Agent 怎么思考”，不管“一千个 Agent 在集群里怎么跑”。
Agent 这个东西很怪。它不是无状态微服务，重启就丢了上下文；也不是跑完即退的批处理任务，一个任务可能持续很久，中间还要反复积累状态。更麻烦的是它有钱包属性：会调外部模型 API，没人盯着就能在循环里把预算烧光。所以它需要严格隔离、需要网络围栏、需要能随时暂停恢复。
Google 的 ax（7285 star，Go 编写）就是为这个场景做的：一个高吞吐、声明式的 Agent 编排器，设计目标是单个集群跑十亿级任务。它跑在 Agent Substrate 之上，沙箱执行由后者负责。如果你用过 Kubernetes，ax 的手感几乎一样：写 YAML，一条命令 apply。
先泼一盆冷水：README 顶部挂着醒目的警告，核心概念、协议和规范还在频繁调整，正式版之前大概率有破坏性变更。现在上手的人等于在陪跑，要有心理准备。
四个原语，加上几条运维命令
ax 的思路是把 Agent 运维问题收敛成少量声明式原语：
| 你想做的事 | ax 给你的东西 |
|---|---|
| 在带 CPU/内存限制的沙箱里跑不可信的 Agent 代码 | Task |
| 预配置 Git 仓库、MCP 服务器、技能包，让 Agent 启动就是热身完毕的状态 | Workspace |
| 把出站流量锁到一个显式的主机白名单 | Gateway |
| 配置平台自己用哪个 LLM，凭据放在 Kubernetes secret 里 | Model |
我觉得这个白名单设计值得单独说一句。Agent 的安全边界一直很模糊，它能上网、能调工具，出了事很难追。把出站流量收窄到白名单，是把“信任”从提示词层面挪到了网络层面，这才是基础设施该干的事。
除了这四个原语，还有两条运维命令很实用：
ax suspend/ax resume：暂停一个空闲的 Agent，之后从中断点精确恢复。空闲的 Agent 不占资源也不烧 token，这对大规模跑 Agent 的成本影响很直接。ax ssh：直接 shell 进正在运行的 Agent 沙箱，看它到底在干什么。排查“Agent 卡住了但不知道卡在哪”这类问题，没有比这更直接的办法。
所有东西都写成 ax.io/v1alpha1 的 manifest，一条命令下发。
上手三步
第一步，装 CLI：
go install github.com/google/ax/cmd/ax@latest
二进制会落在 $(go env GOPATH)/bin，确认这个目录在 PATH 里。
第二步，部署控制面。 前置条件不少：一个 Kubernetes 集群、ko（brew install ko）、一个集群能拉取的容器仓库，还要有可达的 Agent Substrate Control API（集群内默认地址是 api.ate-system.svc.cluster.local:443）。然后：
make deploy AX_IMAGE_REPO=
这条命令会先部署 Redis，再用 ko 构建并部署控制面镜像，全部装进 ax-system 命名空间。
第三步，跑第一个任务。 看 README 里的例子：
# task.yaml
apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
name: golang
spec:
git:
- repo: https://github.com/golang/go.git
branch: "my-fix"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
name: test
spec:
workspaces:
- name: golang
goal: "Ensure that Go tool chain is available and is built from source"
debug: true # lets you `ax ssh` into the sandbox
这个文件声明了两样东西：一个 Workspace（克隆 Go 源码仓库的 my-fix 分支）和一个 Task（目标：确保 Go 工具链可用，并且从源码构建出来）。注意 Task 里那行 debug: true，打开它才能 ax ssh 进沙箱。
接着：
ax apply -f task.yaml
ax watch task test
ax ssh test -- ls -al /workspace
apply 下发，watch 看任务起来，ssh 进沙箱列出 /workspace 的内容。三条命令和 kubectl apply / kubectl logs / kubectl exec 一一对应，K8s 用户应该会有肌肉记忆。
实际跑第一个任务时可以直接用仓库里的示例：
ax apply -f examples/task.yaml # Task + Workspace + Gateway + Model in one file
ax get t
我的判断
ax 的对标物是 Kubernetes，不是 LangChain。市面上的 Agent 框架解决 Agent 内部逻辑，ax 解决 Agent 作为基础设施怎么被调度、隔离和观察。这个分层是对的，框架层已经卷得厉害，基础设施层还没人认真做。
但也要看清现状：依赖一个 Kubernetes 集群外加 Agent Substrate 的完整环境，部署门槛不低；核心 API 还在 v1alpha1 阶段，官方明说会有大改。它现在的价值更多在于给出一个参考答案：当 Agent 真的要在集群里大规模跑起来时，原语应该长什么样。如果你在做 Agent 平台方向，这个仓库的 API 设计值得逐行读一遍；如果你只是想跑个单机 Agent，现在还不是入场的时候。