别给 AI 穿西装：Steve Yegge 为什么坚持在那个黑乎乎的终端里调度 320 个 Agent？

Steve Yegge 这两天放出来一段视频，屏幕里一台机器同时挂着 320 个 Claude Code 实例，他像玩 RTS 一样在不同的会话之间来回切。视频在朋友圈、推特、小红书都火了，转发的人配的话基本一样——「AI 写代码的范式真的变了」「黑框终端要重新统治世界」。

3 月底我写过一篇《软件界面正在倒退回 40 年前》（最后 89668 阅读），讨论过 CLI 为什么在 AI 时代回潮。这次看到 320 这个数字，第一反应不是兴奋，而是想再往下挖一层：320 个实例并排跑，真正难的不是开 320 个终端，是这 320 个 agent 互相之间用什么协议说话。

我自己最近就在搭一个 small-scale 的版本，所以这点感受是亲手摸出来的，不是评论员姿态。

320 不是 CLI 的胜利，是协议的考题

很多人把 Steve Yegge 这事解读成「GUI 死了，CLI 万岁」，我觉得读错了重点。

CLI 只是入口层。一个人坐在终端前能盯几个会话？三五个已经手忙脚乱，320 个绝对不是靠人眼盯出来的。真正撑得起 320 实例并行的，是后面那一层——每个 agent 当下能做什么、不能做什么、谁的输出能流到谁的输入里、出错了哪一个 agent 负责回滚。

这层东西不在终端里，在配置文件里。

上周（5/11）我写过 Anthropic 那个 financial-services 开源仓的拆解——18630 stars 的 KYC cookbook，把整个多 agent 系统的能力边界、调用关系、输出 schema 全部压成了一组声明式 YAML。当时我下的判断是：「衡量 multi-agent 工程化的真实进展，重点应转向整套系统的可分析性、可重构性、可审计性。」

Steve Yegge 这个 320 实例，是同一个原则推到极端的另一面。Anthropic 把它做成模板给企业用，Steve Yegge 把它做成单兵装备给自己用。中间的工程问题完全一样。

没声明式协议的话，320 就是 320 个失控的孩子

这话听着夸张，但我自己踩过缩小一千倍的版本。

最近我把自己跑了 60 多天的 daily-digest pipeline 重构成了一个 5 阶段的 multi-agent 小系统——目前 corpus 入库 1128 篇，做过 7 次完整爆款拆解。规模跟 Steve Yegge 差三个数量级，我必须老实说清楚，但麻烦的种类是一样的。

最开始我没有把每个 agent 的能力边界写出来，就让 fetch、select、write、audit 几个角色用「自然语言提示词」彼此协作。第三天就出问题了——audit agent 跑着跑着开始改文章；write agent 顺手把 fetch 的缓存清了；最离谱的一次，select agent 直接跑去发布。三个 agent 视角里看起来都「在做正确的事」，合在一起就是失控。

后来我老老实实把每个 agent 的工具集、可调用的下游 agent、输出 schema 全部写进配置文件——跟 KYC cookbook 那种 YAML 同思路，只不过我用的是 Claude Code 的 skill capabilities 目录。配置写完以后，事故率立刻降下来，因为「能不能做」这件事被搬到了 agent 视野之外，不再依赖 agent 自己想明白。

5 个 agent 协作时我就花了这么大力气。320 个，如果没有声明式协议层，光是想清楚谁不能调谁，就得画一张几千条边的图。

CLI 是表象，YAML 才是骨头

回头看 Steve Yegge 的视频，那个黑乎乎终端确实抢眼，但只是 UI 这一层。

真正决定他能不能控住 320 个实例的，是终端背后那套调度策略：每个 agent 默认能不能写文件、能不能调外网、它的输出要不要先经过一层校验才能传给下游、超时了由谁兜底。这些东西不是终端的功能，是协议层的功能。Anthropic 那个 cookbook 之所以值 18630 stars，不是因为它给了 10 个业务模板，是因为它示范了「能力边界用配置而不是用代码写出来」这件事。

判断一个 multi-agent 系统的工程化成熟度，比起看跑多少实例、看 demo 多炫，更直接的看法是——它有多少东西被声明在配置文件里，又有多少东西藏在 Python 的 if-else 里。 前者越多，后者越少，这个系统越接近工程产品，离玩具越远。

CLI 回归只是把界面这层简化了。下面那层有没有真做出来，跟开几个终端无关。

我自己的 5 个 agent，就是这条路上的第一步

回到自己的小系统。1128 篇入库、7 次完整拆解，相对于 320 实例都是小数，我不打算装作自己也在那个量级。

但我现在能体会的是：把 fetch、select、write、audit 这几个角色的能力声明出来以后，整个 pipeline 第一次像传统软件一样可以被 review——哪个 agent 改了、改了什么权限，git diff 就能看到；哪一步出错，audit log 用 event ID 就能反查。这是写自由文本提示词换不来的东西。

Steve Yegge 那 320 个实例如果真能稳定跑下去，背后一定也有同样的东西。CLI 不是答案，配置文件才是。我们今天看到的「调度 320 个 agent 像玩 RTS」，本质上是一次 K8s manifest 之于容器编排那种工程进化的微型重演——只不过这次被编排的不是容器，是一堆 LLM。

那个黑乎乎的终端没那么重要。重要的是终端打开之前，有没有一份能让 320 个 agent 各司其职的 YAML。