主 Agent 调度失效？Claude Code 实现 Sub-agent 分工的 4 层工程化架构

1. 主 Agent 调度失效不是故障，是系统超载的明确信号

我上线第一个 Sub-agent 分工架构的第三天，主 Agent 在处理一个含 17 个模块、依赖图深度达 5 层的 Java 微服务重构任务时，连续三次在「生成 Service 层接口定义」环节卡死。它没报错，不崩溃，只是静默——光标停在// TODO: generate UserService contract这行注释上，37 秒后自动跳转到下一个未完成项，把本该由它协调的 4 个 Sub-agent 全部晾在半路。

这不是 prompt 写得不够狠，也不是模型 token 不够用。这是主 Agent 的调度器在真实工程负载下暴露的结构性失能：它被设计成一个「全能型协调员」，但实际项目里，它既要看清全局依赖拓扑，又要判断每个子任务的技术边界，还要实时评估 Sub-agent 的执行质量并动态重调度——这三件事在 Claude Code 当前版本（2026 Q2 稳定版）的上下文窗口与推理路径中，根本无法并行保真。

提示：Claude Code 的主 Agent 并非传统意义上的“调度中心”，它本质是一个上下文敏感的指令分发器。它的“失效”往往发生在任务复杂度突破其隐式状态建模能力阈值时，而非显式报错。这点和 Copilot、Cursor 等工具的主控逻辑有本质区别——它们更偏向单点增强，而 Claude Code 的 Sub-agent 架构天然要求主节点承担轻量级编排职责。

我们团队在三个不同规模的项目中复现了这一现象：当模块数 > 12、跨模块调用链 > 3、且存在至少 1 个需多轮迭代验证的子任