将军赶路不追小兔：多 Agent 调度体系的架构与实践
将军赶路不追小兔 这篇的底稿是一段 80 分钟的语音分享。依然延续这个系列的传统——作为人类，你只需要读懂思路和架构逻辑；所有具体的执行细节，把文章丢给你的 Claude Code 或 Codex，让它去做就行。 开头：为什么要聊调度体系 在人生的塞尔达时期那篇文章里，我用了一张架构图和一段概述提过"多 Agent 调度"这个话题——主脑负责规划、执行层负责干活、门禁负责把关。但那篇的重心在 Token 经济学和模型军火库，调度体系本身只是一笔带过。 这篇就是展开讲。 先回到一句话原则：Agent 的注意力是非常宝贵的东西，你应该把它用在解决高质量的不确定性上面，而不是琐碎的事情。 怎么理解这句话？你可以把 Agent 的注意力想象成一个人的工作精力。如果它花一个小时去处理登录验证码，就少一个小时去干正事。我在 Context is All You Need 里用过一个比喻：注意力就像你的工作台面——台面就那么大，放了杂物就没地方干正事。在那篇文章里聊的是管好一个 Agent 的"工作台"；这篇是——当你同时有 Claude Code、Codex、Kimi、Grok 这一堆 Agent 的时候，怎么把每个 Agent 的工作台面都利用好。 这完全可以类比 CEO 的精力分配。CEO 的精力是有限的，应该只用来决策、高价值的方向判断、找资源——而不应该浪费在一线执行层的细节上。将军赶路，不追小兔。 一、这套体系是怎么长出来的 很多人看到"多 Agent 调度"可能觉得这是个很重的架构设计，但它最开始其实是一个非常朴素的想法。 那时候 Fable 5（Claude 家目前最顶级的模型）还是限量内测，不知道以后还有没有机会再用。所以我用得抠抠搜搜：Fable 5 只负责规划设计，所有具体的执行任务全外包给 Sonnet 5（一个便宜且能力均衡的模型）。成本倒逼出了最初的分工逻辑。 后来的演化路径是这样的： 起点：多个 Coding Agent 各有各的配置文件，维护起来很麻烦，单独建了个代码仓库（可以理解为一个项目所有文件集中存放的地方）来统一管理。 第一步：既然配置文件都集中了，能不能试着把其他 Coding Agent 变成执行层？ 第二步：执行层能自动跑了，需要知道各家套餐还剩多少额度——于是写了个监控面板。 第三步：监控面板有数据了，能不能根据剩余额度自动选执行器？于是有了配额感知调度。 每一步都不是预先设计的，而是在使用过程中"长出来的"。你会发现建好一个组件之后，它会产生意想不到的新用途： 监控面板一开始只是统计各套餐的用量，后来加了 Token 消耗统计（分模型、分项目、分设备），又加了开发机的内存和工作区清洁度监测，再加了 CI 测试机的健康状况——最终它变成了调度系统的"仪表盘"，辅助决策"这个任务该分给谁"。 ...