Claude Code 源码十大亮点05|Leader-Centered Permissions:多 Agent 系统最容易忽略的控

Digital Strategy Review | 2026

Claude Code 十大亮点解读 05｜Leader-Centered Permissions：多 Agent 系统最容易忽略的控制设计

文 / 果叔 · 阅读时间 / 8 Min

写在前面

很多多 Agent 产品一开始都把注意力放在“能不能并发跑更多 worker”上，真正把系统做稳的人，反而会先盯住权限怎么收口。Claude Code 这一层最有价值的地方，就在于它把控制权放回了用户真正能理解的位置。

Leader-Centered Permissions：多 Agent 系统里最容易被忽略、却最关键的控制设计

多 Agent 很容易做出“并发很强”的样子。但只要多个 Agent 都开始真正调用工具，问题立刻出现：

• 谁来审批权限？

• 用户面对的是哪个 Agent 的请求？

• 多个 worker 同时请求权限时，界面怎么不崩？

Claude Code 在这个问题上的答案非常成熟：执行可以分散，但权限裁决要尽量回到 leader 的统一控制面。

这个思路主要体现在：

• src/utils/swarm/inProcessRunner.ts

• src/screens/REPL.tsx

• 权限相关的 bridge / mailbox 机制

一、为什么这是多 Agent 最容易翻车的地方

如果你做过多 Agent 产品，就会很快意识到一个残酷现实：

多个 Agent 并发做事很容易，多个人类同时理解多个 Agent 的权限请求却很难。

常见糟糕情况包括：

• 每个 worker 弹自己的审批框

• 用户根本分不清谁在请求什么

• 一个 worker 的权限模式污染另一个 worker

• 权限请求散落在多个不同 UI 中

最后结果通常是：

• 用户关闭权限

• 产品变得不可控

• 团队只能把多 Agent 能力阉割掉

Claude Code 明显是认真处理了这个问题。

执行可以分散，审批最好集中；fallback 的存在，决定这套设计是不是长期可用。

二、它的基本原则：执行分散，控制集中

Claude Code 的多 Agent 权限设计可以压缩成一句话：

Worker 负责提出动作，Leader 负责统一与用户交互。

这个原则非常重要，因为它让多 Agent 系统不会失去“单一用户控制面”。

具体表现

在 in-process teammate 路径里，worker 的 canUseTool(...) 并不是简单自己决定 ask/allow，而是：

01 先跑权限判断

02 若是 allow/deny，直接返回

03 若是 ask，优先通过 leader 的 ToolUseConfirm UI

04 如果 bridge 不可用，再退回 mailbox 流程

这意味着 worker 自己不拥有“弹窗权”，它只拥有“发起请求权”。

三、为什么这个设计这么对

1. 用户只需要理解一个审批入口

无论哪个 worker 触发请求，用户最终看到的是统一的权限审批体验。

这极大降低了多 Agent 系统的认知负担。

2. 可以给每个请求打上 worker 身份

源码里会带上 worker badge、identity 等信息。这样用户既能知道“是谁在请求”，又不需要跳出主控制面。

3. 它保留了权限策略的一致性

如果每个 worker 都自己维护一套权限状态，很快就会出现规则漂移。 Claude Code 的做法是尽量把权限更新写回 leader 的共享上下文，从而维持统一策略面。

四、mailbox fallback 说明了系统的成熟度

很多系统做到第一步：UI 可用时走统一弹窗。 Claude Code 还往前做了一步：如果 UI bridge 不可用，就退回 mailbox。

这非常重要，因为真实环境里总会有：

• 某些模式没有直接 UI bridge

• 某些 worker 运行在不同上下文里

• 某些路径下只能走消息同步

如果没有 fallback，多 Agent 权限模型就会在边缘场景失效。 Claude Code 则做到了：

• 最优路径：leader UI

• 退化路径：mailbox 请求-响应

这让系统不是“某些场景下工作”，而是“在不同协作形态下仍能保持控制权统一”。

五、它不仅是 UI 设计，更是安全设计

很多人会把这个亮点理解成交互体验优化。但本质上，它也是安全边界设计。

因为多 Agent 最大的风险之一就是：

• 一个 worker 获得了超出用户预期的工具能力

• 用户并不知道是谁做了决策

• 权限更新在多个执行体间不一致

Leader-centered permissions 的好处正是：

• 最终决策回到用户可见主界面

• worker 只负责请求，不负责自己做最后决策

• 权限更新尽量落在共享上下文中

这能显著减少“多 Agent 自主性过强导致失控”的风险。

六、为什么这件事会直接影响产品可用性

多 Agent 产品不是比谁能同时跑更多 worker，而是比谁能在多 worker 同时跑的时候仍然保持可用。

权限系统恰恰是最容易把产品可用性拖垮的一环。 Claude Code 这里的处理等于做了一个关键取舍：

• 不追求每个 worker 都像独立终端那样自治

• 而是让自治停在执行层，把控制权保留在人类可理解的位置

这会让系统在真实使用中更“稳”。

七、一张图看懂这个亮点

八、结论

Leader-centered permissions 是典型的那种“不够 flashy，但非常决定成败”的设计。

它解决的不是某个局部功能，而是多 Agent 系统能否真正长期可控：

• 执行可以并发

• 权限不能分裂

• worker 可以很多

• 用户控制面必须只有一个核心入口

Claude Code 在这里给出的答案很清楚：

多 Agent 的自由度必须建立在统一的人类控制面之上。