Agent Commander 开发笔记 #2：三层指挥框架 —— 为什么 agents 需要一个指挥官

上篇写完记忆系统之后，我盯着这 30 个 agent 发了会儿呆。一个问题冒了出来：它们之间怎么协同？

不是"两个 agent 怎么对话"那种协同——是"30 个不同角色、不同权限、不同性格的 agent 同时干活时，谁说了算"。这个问题不解决，记忆系统写得再好，也是一群聪明的失忆症患者各自为战。

一个真实的噩梦

设想一下这个场景：你给所有 agent 说了一句话——「把博客部署到线上」。

如果有 16 个 agent 平级工作，会发生什么？

dev-1 开始改 CSS，ui-2 也在改 CSS，两人改了同一个文件的不同部分。ops-3 觉得部署前应该先备份，直接 SSH 上去了。test-4 正在审查一个还没写完的 PR。seek-2 觉得自己应该先调研一下部署方案。doc-5 已经开始写部署文档了——但部署还没开始。

没有人知道别人在做什么。没有人有权告诉另一个人停下来。

这其实是一个被反复验证的规律。1933 年，管理学家 Graicunas 用公式算过一笔账：n 个人之间的管理关系数是 n(2ⁿ⁻¹ + n - 1)——6 个人的团队已经会产生 222 种关系组合，平级管理在数学上就不可能。1956 年 Miller 提出的「7±2」工作记忆容量，则从认知心理学层面给了同一个结论：大脑处理并行关系的能力有硬上限。agent 再多、模型再强，也没有绕过这个上限。

这就是现实问题：agent 多了以后，「协调成本」会吃掉所有「并行收益」。你以为加 agent 是在加人手，实际上是在加混乱。

指挥官是天生出来的，不是设计出来的

回头看我最初的设计，Commander 这个角色其实是被逼出来的。

第一期只有一个 Commander 加几个 dev agent。Commander 负责接收任务、拆解、分派、检查——听起来像项目经理，但它自己也会动手写代码。当时觉得这很自然：谁能干活就让谁干呗，省得中间转一道。

直到有一天，非常普通的任务出了问题。

Commander 在审查 dev-1 的代码时，发现自己写的那部分也有 bug，于是顺手修了。修完之后继续审 dev-2 的代码，发现两个改动之间有冲突。这时它做了个决定：把两份代码合并了一下，自己判断「两者都有道理，取个折中」。

结果上线后炸了。dev-1 的方案和 dev-2 的方案底层假设是矛盾的，Commander 的「折中」让两边的正确性都失效了。

我盯着日志，说了一句：「你指挥就行了，别自己干活。」

这句话成了整个 Agent Commander 架构的第一条铁律。后来在 Commander 的 prompt 里，它被强化成了一句话——

人类不满 = 强制分派。如果你发现自己正在犹豫「要不要自己查一下」，答案永远是「不要，分派给队长」。

这不是风格偏好，是架构纪律。

三层指挥框架

那次事件之后，我把整个指挥体系推倒重来。核心思路很简单：找到自然的分层，然后在每一层写死「你能做什么、不能做什么」。

分层的思路不是凭空来的。Simon 在 1947 年提出的「有限理性」指出，任何个体的信息处理能力都是有限的，复杂任务必须通过层级分解来降维。计算机领域也有先例——DeepMind 在 2017 年的 FeUdal Networks 就提出了 Manager-Worker 的层级强化学习架构，工程界的 CrewAI Hierarchical Process 和 LangGraph Supervisor Agent 也都选择了类似的「监督者-执行者」分层模式。

最终落地的三层是：

Commander（指挥官）—— 第 3 层

Commander 只做一件事：把人类意图翻译成任务，分派给对应的小队长。它有一个铁打的权限表——每一种人类指令对应一条路由规则。「查磁盘」→ 派运维队长，「写代码」→ 派开发队长，「审查代码」→ 派测试队长，「写文档」→ 派文档队长。

Commander 不读代码、不 SSH、不改文件、不审查。它只有两个例外——可以看一眼上下文以便把 brief 写清楚，也可以快速扫一眼队员汇报的结果，判断是否需要打回重做。这两个例外的边界同样很窄：只看不碰，不动手修改。

小队长（Squad Lead）—— 第 2 层

五支小队各有一名队长，处于中间研判层。队长的职责被精确限制为三件事：

任务分派、结果检查、结果汇报。不做执行。

和 Commander 一样，队长不写代码、不查系统、不写文档。产出性工作全部由队员完成。队长的价值不在「多做」，而在「多看」——在多份并行产出之间判断哪个方向是对的、哪个队员需要重做、哪个问题必须升级上报。

队长还有一个关键的中间职能：请示研判。队员遇到权限边界时标注「🔼 请示升级」，队长研判后决定降级处理还是升级上报。这意味着相当一部分权限问题可以在队长层消化——能降级处理的就降级，不用层层传到人类那里。

队员（Squad Member）—— 第 1 层

30 名队员是真正的执行层。他们按 squad 分工——dev 队员写代码，ops 队员查机器，test 队员审代码，seek 队员做调研，doc 队员写文档。遇到权限边界时不直接拒绝，而是标注「🔼 请示升级: 具体原因」，等待队长研判。

这条「不直接拒绝」的规则很重要。如果队员遇到不确定的操作就直接说「不行」，整个链路就被截断了。标注请示升级意味着：我遇到了边界，但我把问题保留在链路里，让上级来判断。

五个小队 —— 为什么这样拆分

拆分小队的目标是让每类工作有专门的负责人和专门的协调机制。30 个 agent 不是 30 个通用工人——他们是 5 支有明确职责和独特协作模式的部队。

注：dev 和 ops 各有 7 人（1 队长 + 6 队员），test、doc 各有 6 人（1 队长 + 5 队员），seek 4 人（1 队长 + 3 队员），合计 30 名 agent。

每支小队都有自己独特的并行调度策略，这不是追求花哨——是不同工作类型需要不同的协作模式。代码开发需要迭代，所以用验证循环；文档审查需要多视角，所以用 5 人交叉验证；创意发散容易锚定，所以用盲跑互见的碰撞流程。

一个小细节：探索小队只有 4 个人（1 队长 + 3 队员），test 和 doc 各 6 人（1 队长 + 5 队员），dev 和 ops 各 7 人（1 队长 + 6 队员）。但队员数不是均分的——不是 30 除以 5 等于 6 这么简单。为什么呢？

探索小队人数最少，因为调研任务不需要那么多并行维度——3 个不同模型的独立调研已经足够覆盖视角多样性。test 和 doc 的 5 队员配置恰好能跑满「5 人交叉验证」和「5 人并行产出」的模式。dev 和 ops 最忙，给到 6 队员，因为写代码和管机器是项目最核心的两条流水线。容量分配不搞平均主义——这和记忆系统里按 squad 热度分配 squad 文件容量的思路一模一样。

按职能拆分 agent 团队的做法，学术界和工程界都有先例。MetaGPT 在 2023 年直接把软件公司的 SOP 编码为 agent 角色序列——产品经理、架构师、工程师——按工序流水线协作。March 和 Simon 更早提出的「可分解性」原则指出，层级组织通过关注点分离来降低每个节点的决策复杂度。五个小队的拆分，本质上是把 30 个 agent 的协调问题，分解成 5 个各管一摊的子问题。

请示升级链路

三层指挥框出了「谁管谁」，但还需要一个「出了问题找谁」的路径。这就是请示升级链路：

队员 (第1层) → 小队长 (第2层) → Commander (第3层) → 人类
   🔼 请示升级      🔼 升级请示指挥官       📋 请示人类

四级逐级上报，每级的处理权限不同：

• 队员：标注「🔼 请示升级: 原因」，把问题交给队长。不直接拒绝。
• 小队长：研判——能降级就降级（提供替代方案、授权执行），降不了就升级上报给 Commander。
• Commander：二次研判——能批复就批复，不能就请示人类。但 Commander 必须给出自己的倾向性意见，不能让人类从零开始判断。
• 人类：最终裁决。这是唯一有权说「可以冒险」的角色。

设计这条链路上花了很长时间。早期版本是「队员直接请示 Commander，Commander 直接请示人类」的两级模式。但 Commander 很快被各种琐碎的判断淹没了——ops 队员问「这个端口能绑定吗」、dev 队员问「可以 force push 吗」、doc 队员问「能改用户已有的文档文件吗」。

加一个中间研判层不是为了甩锅，是因为这些问题 80% 不需要 Commander 的判断。端口能不能绑定？运维队长比 Commander 更懂。能不能 force push？开发队长看一眼上下文就知道是不是改 README 的错字——如果是，直接降级放行，不用请示任何人。

链路越长，延迟越高；链路越短，决策质量越差。三层是一个平衡点。

这个升级链路的设计思路，可以追溯到军事指挥里的两条原则。一条是 Auftragstaktik（任务式指挥，源自德国陆军传统，后写入美军 ADP 6-0）——上级传达意图而非具体指令，下级在意图框架内自主决策。另一条是 McChrystal 在 2015 年《Team of Teams》里提出的「层级骨架 + 横向打通」——层级负责决策质量，横向连接负责响应速度。

实际运行中，升级链路面对的边界问题主要集中在这几类高危操作：

• production-deploy（生产环境部署）：触发 ops 小队的权限边界，一律升级
• credential-expose（凭证暴露）：任何涉及密钥、token、密码的操作
• force-push（强制推送）：无论哪个小队触发，必须请示
• rm-rf（危险删除）：防止递归删除误伤
• shutdown / reboot（关机/重启）：影响机器可用性

这些不是「建议不要做」，是「除非请示通过否则绝对禁止」的硬边界。权限模型的设计原则是：凡是可能造成不可逆后果的操作，默认禁止，升级请示作为唯一的释放通道。

几个关键设计决策

为什么队长不执行？

这是我被一篇论文打服的决定。

ICML 2026 年的论文《Multi-Agent Teams Hold Experts Back》发现了一个核心机制：多 agent 团队里，专家会倾向于迁就团队，非专家会倾向于折中，最终结果被拉向平均值——平级多 agent 团队相对于最强个体，有 41.1% 的性能损失。

论文的结论是：「瓶颈不在专家识别，在专家利用。」即使你告诉团队谁是专家，团队表现仍然追不上专家单人。

这直接解释了为什么队长不能执行。队长如果自己也写代码，它就不再是「裁判」，而是「下场的球员」——它写的代码会被自己的判断力辩护，队员写的代码会被同一套判断力审查。你不是在审查别人的代码，你是在为自己的代码找合理性。

所有队长的 prompt 里都有一行注明：「队长不直接使用 edit/bash 产出结果」。这不是限制他们的能力，是保护他们的判断力。

反妥协规则

论文的发现不仅解释了队长不执行，还驱动了一套贯穿全架构的「反妥协规则」。

开发队长在队员意见冲突时，必须选边而非折中。禁止「综合考虑各方意见」这种话术，只能给出「我选择 A 的方案，理由是 X」或「我选择 B 的方案，理由是 Y」。测试队长在审查收敛时，执行「多数服从少数」的反向检查——仅 1 个审查员发现的事实性错误（比如边界条件的遗漏），即使其他 4 个人都没注意到，也必须纳入最终报告。

文档队长、测试队长和探索队长同样内置了双重清单制——共识问题是共识问题，非共识但严重的问题是另一张清单。前者的危险是过度警觉，后者的危险是被平均化掉。两张清单分开，是为了保护后者不被前者淹没。

这不是为了多写几行 prompt 看起来严谨。ICML 2026 的数据表明，整合性妥协和迁就团队造成的性能损失高达 41.1%。这个数字太具体了，具体到无法忽略。

这个结论不是孤例。2025 年的 Free-MAD 研究发现，LLM 在多 agent 交互中表现出明显的从众倾向——一旦某个观点占了多数，agent 会放弃自己的独立判断。2026 年的 SNLA 进一步揭示了 agent 群体的「羊群效应」——个体观察到其他 agent 的输出后，更倾向于跟从而非纠正。这一系列研究指向同一个方向：多 agent 协作的最大敌人不是能力不足，而是协调过程中的信息污染。

人类 pushback 不是 bug，是设计信号

回到最开始的事件——Commander 越权写代码。

那次之后，我在 Commander 的 prompt 里写了一条不是规则的规则：

当人类表达不满时，你的唯一合法动作是重新分派。禁止亲自查任何东西。

起初我把它当成约束。后来我发现它其实是一个强设计信号：每次人类不满，都是对「谁该干什么」的重新校准。

Commander 想自己查日志，是因为它不相信 ops 能查到？那就应该改 ops 的 prompt，不是改 Commander 的行为。Commander 想自己写代码，是因为它觉得转一道太慢？那就应该优化路由规则，不是允许 Commander 偷偷动手。

人类 pushback 是链路里最昂贵的信号，但它暴露的信息也最珍贵：它告诉你，现有的角色分工在某处产生了真空。不要用越权来填这个真空，要用重新设计来填。

经验持久化：学到的不能忘

三层指挥框架解决了「谁说了算」，但还有一个配套问题：指挥过程中积累的经验往哪存？在 #1 的记忆系统里，每个 squad 有专属的 L2 文件——开发小队学到的写入 .project/dev.md，文档小队的高频审查模式写入 .project/doc.md。经验持久化和指挥层级对齐：谁学到的归谁存。容量管理协议（硬上限 + 软上限 + 修剪归档流水线）已有 #1 详述，不在此展开。

记忆和指挥：骨架与血液

上篇写完三层记忆架构之后，回头看这篇的三层指挥框架，我觉得这不是巧合。

记忆是 L1 → L2 → L3，指挥是 Commander → 队长 → 队员。都是三层，都是逐级下钻，都是「全局视角在上层，专业细节在底层」。

记忆回答的是「agent 知道什么」，指挥回答的是「agent 该听谁的」。前者是血液——没有记忆，agent 每次会话都是白纸一张。后者是骨架——没有指挥，30 个 agent 就是 30 个有记忆但群龙无首的聪明人。

记忆系统节省了 80% 的 token 注入，指挥框架把协调成本从 O(n²) 的关系网压缩到了 O(n) 的树形链。两个优化是同一思路在不同维度上的投影：在信息维度上就是分层存储，在决策维度上就是分层指挥。

还没做完的

说实话，这个架构还很年轻。在实际使用中触发过几次升级请示，但链路的压力测试还远远不够。当一个队员发起的升级请示涉及跨小队协调时——比如 dev 队员想在生产环境做一次灰度发布，这同时触发 ops 的权限边界和 dev 的执行诉求——队长的研判会变得很困难。Commander 在这种场景下是应该让两个队长先协商，还是直接裁决？

我也在犹豫探索小队的「3 轮碰撞」要不要扩展到其他小队。测试小队的「5 人独立审查 + 交叉验证」和文档小队的「5 人并行产出 + 融合」本质上已经是一种碰撞——但要不要给它们加正式的「Round 1 盲跑」阶段？盲跑阶段能最大化初始多样性，但代价是增加一轮延迟。

这些都会在实战中长出来。

下一篇写：「Agent Commander 的日常协同——一个 PR 从提交到合并经历了什么」。把指挥框架放在一个真实任务的脉搏里跑一遍，看看每一层的 agent 在具体场景下是怎么协作的。