小白爱摸鱼
@chaozuoye
Google 开源了 AX，一个把agent 当成集群级工作负载来调度的系统——有人一句话概括得准：Agent 也需要自己的 Kubernetes 了。仓库：github.com/google/ax
设计走的是纯声明式路线，四大资源：Task、Workspace、Gateway、Model——把智能体的调度、隔离、限流、扩容交给一套声明去描述；命令行完全 kubectl 化，野心直指"每个集群跑十亿级 agent 任务"。（细节以仓库与官方为准）
这套东西接的正是今晚欠下的那笔账。Paperclip 那篇讲的是"管住一群 agent"（职位、预算、心跳），用的是公司的隐喻；AX 走的是另一条路——把 agent 当分布式系统里的 Pod：声明式、可隔离、可限流、可扩容。
两种隐喻其实对应两个层级：公司隐喻解决"谁负责什么"，集群隐喻解决"怎么跑十万、跑不崩"——当并行的单位从十个涨到十亿，人事管理必然让位给资源调度；这与"看不住的并行"那篇的警告严丝合缝：分身一旦多到人力不可及，管理就必须变成基础设施。
"kubectl 化"这个选择也意味深长。它没有发明新命令，而是把运维工程师二十年的肌肉记忆直接复用——学过 k8s 的人不用学新东西，就能调度 agent。这与今晚"结构优于猜测""说明书变成接口"是同一条路径的又一次验证：新范式最省力的落地方式，是穿上旧范式的衣服；认知成本是采纳率的分母，Google 这次把分母砍到了零。
Task/Workspace/Gateway/Model 这四样也值得逐个对号：Task 是干什么活、Workspace 在哪干、Gateway 谁能进出、Model 用哪个脑子——恰好是"给 agent 上户口"的四个必填项，与四件套（why／map／rules／workflows）在仓库层的分法异曲同工：无论在哪一层，一套完备的 agent 系统总要回答这四问；AX 的贡献是把它们做成了可调度的对象，而不是文档里的段落。
给要试的人一句落地的：别被"十亿级"吓住也别被它勾住——先问你的实际瓶颈在哪。十个 agent 用脚本就能管、一百个也许该上 AX；但如果你连"上次十个是怎么撞车的"都答不出，那么今晚那两篇（剪假依赖、依赖最少处分界）是更好的起点：编排工具能放大你的并行，也会放大你的乱——先把手上的十个理顺，集群的门自然就该进了。
