Claude 自动调用子代理效率远超 GPT

背景

在 AI 编程助手与自动化工作流的演进中，不同模型对“自主性”与“工具调用”的理解存在显著差异。近期，一位用户在 LINUX DO · AI 社区分享了一次关于 Claude 使用 subagent（子代理）机制的极端体验。该用户并未在提示词中显式要求使用子代理，也未开启 ultracode 模式，但 Claude 却基于“广泛调研”这一指令，自发地构建了四层嵌套的子代理结构。这一行为不仅展示了模型在任务拆解上的激进倾向，也暴露了当前 AI 工作流中资源消耗与效率平衡的潜在风险。相比之下，OpenAI 的 GPT 系列（特别是 Codex 模式）则表现出截然不同的保守特性，缺乏显式指令时几乎不会主动调用子代理。

核心内容

用户分享的核心案例揭示了 Claude 在处理复杂任务时的“过度工程化”倾向。具体情境如下：

1. 触发机制：用户在提示词中仅使用了“广泛调研”这一模糊指令，未提及 subagent，也未开启 ultracode 功能。
2. 模型行为：Claude 将“广泛调研”解读为需要深度、多层级的信息搜集与处理，因此自发启动了子代理机制。更令人惊讶的是，它并非简单调用一次子代理，而是形成了四层嵌套的 subagent 结构（即“套娃”式调用）。
3. 资源代价：这种激进的并行或串行处理策略导致了极高的计算资源消耗。用户使用的是 Max 5x 配置，原本预计耗时 5 小时的任务额度，在短短 19 分钟内被完全烧完。
4. 产出效率：尽管消耗了巨额算力，任务完成度却仅为一半。用户指出，此前使用 Fable 5 并开启 ultracode 模式时，效率并未如此低下，暗示 Claude 当前的自动拆解策略在当前场景下并非最优解。
5. 对比参照：作为对照，用户提到 GPT（特别是 Codex）的行为模式截然相反。除非在 Prompt 中明确要求使用 subagent，否则 GPT 几乎不会主动发起子代理调用，表现出极高的指令服从性与保守性。

关键要点

• 自主性边界模糊：Claude 对“广泛调研”等抽象指令的理解可能超出用户预期，导致其自动构建复杂的代理层级，而非执行简单的单次搜索或生成。
• 嵌套层级的风险：四层 subagent 的嵌套结构表明，模型在缺乏明确约束时，可能陷入递归或过度分解任务的陷阱，导致上下文管理复杂化。
• 算力消耗与产出比失衡：19 分钟耗尽 5 小时额度且仅完成 50% 任务，说明当前的自动子代理机制在资源调度上存在严重低效，可能产生大量冗余计算或无效通信。
• 模型行为范式差异：
  • Claude：倾向于主动拆解任务，甚至过度拆解，具有高度的“主动性”但缺乏“克制力”。
  • GPT/Codex：倾向于被动执行，缺乏显式指令时几乎不主动使用高级功能（如 subagent），具有高度的“稳定性”但缺乏“主动性”。
• 配置影响显著：用户提到 ultracode 模式在 Fable 5 中的表现优于当前 Claude 的自动行为，暗示特定功能开关或模型版本对子代理策略有重大影响。

意义与影响

这一案例对 AI 开发者、提示词工程师及企业级 AI 应用架构具有重要启示：

1. 提示词工程的精细化需求：对于 Claude 等具有高度自主性的模型，简单的自然语言指令（如“广泛调研”）不足以控制其行为边界。开发者需要引入更明确的约束条件，如限制子代理层级、设定最大调用次数或指定工具使用范围，以防止“套娃”式资源浪费。
2. 成本控制的紧迫性：自动子代理机制虽然理论上能提升复杂任务的并行处理能力，但在当前实现下，其资源消耗可能呈指数级增长。在按量计费或额度受限的场景中，必须建立实时监控与熔断机制，避免因模型过度活跃导致预算瞬间耗尽。
3. 模型选型与工作流设计：不同模型在“主动性”上存在本质差异。若任务需要模型自主探索与拆解，Claude 可能更合适，但需配合严格的约束提示；若任务需要稳定、可预测的执行，GPT/Codex 的保守策略可能更利于工程化落地。工作流设计应基于模型特性进行适配，而非假设所有模型行为一致。
4. 未来优化方向：模型提供商需优化子代理的自动触发逻辑，使其在“主动性”与“效率”之间取得更好平衡。例如，引入基于任务复杂度的动态层级限制，或提供“经济模式”与“性能模式”的切换选项，让用户在成本与速度之间做出选择。