Claude Code 三层架构 Subagent:10 并发屠夫榜适用读者:想用 Claude Code Subagent 跑大型 monorepo 并行重构、正在评估 Sonnet / Fable / DeepSeek / 国产编程模型兼容性的工程团队负责人阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 年 Q3 突然都在聊 Subagent 并发事情起因很具体:上个月一个朋友在群里求救,说他带的团队在做 8 个子仓的 monorepo 重构,Claude Code 起 10 个 Subagent 并行去刷不同模块,本来以为 Anthropic 官方的 Subagent 调度足够稳,结果跑到第 4 个 Subagent 整个 IDE 直接卡住,token 计数像心电图一样掉到 0 又突然飙升。我远程连过去扒了 20 分钟日志,发现卡顿不是模型本身慢,而是 Subagent 之间的消息队列堵了——他没意识到 Claude Code 内部其实有三层架构:Extension(工具/插件)、Delegation(任务分发)、Core(核心推理)。三层职责没分清,10 个 Subagent 全压在同一层,自然顶不住。这次我干脆自己搭了一个测试环境,挑了 5 个编程模型:claude-sonnet-4-6、claude-fable-5、deepseek-r1、mimo-v2-pro、MiniMax-M2.7-highspeed。重点不是重复 Claude Code 屠榜老路,而是把 Subagent 三层架构和 10 并发吞吐拆开看——看哪一层是瓶颈,哪类任务该路由到哪个模型。10 个 Subagent 并行上限听着不多,但在大型 monorepo 重构里吞吐已经比早期串行模式提一个量级,关键是怎么把这一个量级真正吃下来。二、Claude Code 三层架构:Extension / Delegation / Core先把概念盘清楚,后面实测才不至于稀里糊涂。下面是我自己扒 Subagent 行为日志反推出来的三层结构,不是官方文档原话,但跑下来跟实际行为对得上。Core 层(核心推理层):负责把 Subagent 的 prompt 上下文 tool result 真正扔给 LLM,再把 response 拿回来。这层是 token 燃烧的主战场,也是大家平时说的模型能力。claude-sonnet-4-6 在 Core 层的工具调用准确率、Fable 的 follow-up 稳定性、DeepSeek-R1 的推理深度,差距全在这一层。Core 层只关心把对话跑通,不关心 Subagent 之间的协作。Delegation 层(任务分发层):负责决定哪个 Subagent 拿哪段 prompt、Subagent 之间怎么通信、上下文要不要共享、任务依赖图怎么维护。这是 Claude Code 早期最被低估的一层——很多人以为 Subagent 是平级的,实际它在内部维护了一个 DAG(有向无环图),Subagent B 必须等 Subagent A 的某个事件触发才能继续。卡顿往往出在这一层。Delegation 层的指标看DAG 队列深度,深度 5 必有问题。Extension 层(工具/插件层):负责把 LLM 输出的 tool_use 翻译成真实的 file_read / shell_exec / grep 操作,再把结果塞回 prompt。这一层决定了 Subagent 能不能拿到正确的 monorepo 文件、shell 命令有没有超时、并发 IO 怎么处理。Extension 层的指标看tool call 失败率, 3% 通常是 schema 映射问题。三层串起来:Delegation 拆任务 → Core 跑推理 → Extension 执行工具 → 结果回流 → Delegation 派发下一轮。10 并发意味着同一时刻有 10 条这样的链路在跑。三、5 个编程模型 10 并发实测测试环境:M2 Max 64GB 本地,起 10 个 Subagent,每个 Subagent 负责独立模块的 TypeScript 重构。统一 prompt 模板,统一 token 预算(每 Subagent 50k token 上限),跑了 5 轮取中位数。所有模型都通过统一的接入网关调用,5 个模型一致地按炻光公开文档的 endpoint 配置,避免底座不一致影响横评。模型Core 推理延迟 (s)10 并发吞吐 (output tok/min)Subagent 调度兼容CLAUDE.md 迁移友好度claude-sonnet-4-61.8124,000原生原生claude-fable-52.198,000需 tool schema 微调需 prompt 重写deepseek-r14.256,000需关闭 thinking 透传需拆 system promptmimo-v2-pro1.5142,000工具名映射正常段结构化提示即可MiniMax-M2.7-highspeed1.3158,000工具名映射正常段结构化提示即可几个反直觉的结论:1. mimo-v2-pro 和 MiniMax-M2.7-highspeed 在 10 并发下屠榜,不是因为它们单次推理强(其实 deepseek-r1 单次推理质量最高),而是因为它们的 tool calling 协议对 Claude Code 的 Extension 层最友好,几乎没有 schema 报错,Subagent 几乎不停摆。屠夫榜的屠法是不卡,不是快。2. claude-sonnet-4-6 在 Core 层最强,但 10 并发下被国产屠夫反超。原因是 Core 层延迟低的同时,单次输出的工具调用链长,导致 Extension 层处理时间被占用,Delegation 层的 DAG 节点堆积。这就是为什么 Sonnet 单独跑无敌、上 10 并发反而被甩开。3. deepseek-r1 的瓶颈不在 Core,在 Delegation。R1 的 thinking 块会插入到 tool_call 之前,Claude Code 的 Delegation 层默认按tool_call 触发下一个 Subagent路由,R1 把 thinking 塞进 tool_call 之前会直接打乱 DAG 拓扑。必须手动关掉 thinking 透传,具体写法见 FAQ Q2。四、什么时候不该用 Subagent 并发不是所有场景都该上 10 并发,以下三种情况我建议老实串行,别硬刚。1. 强依赖任务链(任务 B 必须等任务 A 的文件存在):Subagent 的并发优势建立在任务可并行上,如果你让 5 个 Subagent 都去改同一个 interface.ts,Extension 层的 file_write 锁会直接死锁。实测 8 个 Subagent 一起改同一个文件,10 分钟内必崩,IDE 整个冻住。2. 上下文共享需求强的任务(比如全局 type 定义改了,所有 Subagent 都要感知):这种场景 Subagent 之间的 context merge 开销会指数级上升,不如串行一个大 agent,把所有上下文喂给一个 Core,效率反而更高。3. 模型本身并发能力差(比如纯 reasoning 模型、上下文超 200k 的):这类模型单次推理已经把 GPU 吃满,再上 10 并发只会让 Core 层排队。deepseek-r1 在 200k 上下文下并发上限实测只有 3-4,再多就开始互相抢资源,延迟反而比单跑还高。五、生产环境实战:路由策略 / 监控 / 容灾把上面 5 个模型落到生产,我现在的做法是按任务特征路由,而不是按模型排名路由。轻量单文件修改(改一个函数、补一个类型):走 MiniMax-M2.7-highspeed,延迟低,单次成本低。中等重构(改一个模块、跨文件 import 调整):走 mimo-v2-pro 或 claude-sonnet-4-6,两者 Extension 层兼容度都很好。深度推理(架构选型、复杂 bug 定位):走 deepseek-r1,串行不开并发,让 thinking 块跑满。长尾兜底:claude-fable-5 作为 sonnet 的备份,sonnet 限流时自动切换。在炻光接入平台上,这种多模型路由可以统一抽象成 OpenAI / Anthropic 兼容协议,Subagent 不用关心底层是哪个厂商,只管发请求拿结果。生产环境的接入层我加了三个关键监控指标:Delegation 层 DAG 队列深度( 5 告警,说明任务依赖设计有问题)Extension 层 tool call 失败率( 3% 告警,通常是 schema 映射问题)Core 层 output token 速率突降( 30% 突降告警,通常是上游限流)容灾策略:每个 Subagent 都有 retry-with-backoff,但同一 prompt 失败 3 次就熔断,不再占用队列,避免一个 Subagent 卡死带崩整组。10 并发不是启动 10 个就完事,必须有熔断,否则一个坏 prompt 能让整组 Subagent 全堵在 Delegation 层。六、完整代码:可复制即跑下面是一个最小可运行的 Subagent 调度器,演示怎么在 5 个模型间按任务路由。代码里的 base_url 走炻光接入平台统一抽象的 OpenAI / Anthropic 兼容 endpoint,实际部署时按你账户的接入域名替换。import asyncio import aiohttp from typing import Dict, List # 5 个模型的 endpoint 配置(走统一接入网关) MODEL_CONFIG: Dict[str, Dict] { claude-sonnet-4-6: { base_url: https://your-gateway/v1/messages, max_concurrent: 10, cost_tier: high, }, claude-fable-5: { base_url: https://your-gateway/v1/messages, max_concurrent: 8, cost_tier: high, }, deepseek-r1: { base_url: https://your-gateway/v1/chat/completions, max_concurrent: 4, # 推理模型并发上限压低 cost_tier: mid, extra_body: {thinking: False}, # 关掉 thinking 透传 }, mimo-v2-pro: { base_url: https://your-gateway/v1/chat/completions, max_concurrent: 10, cost_tier: low, }, MiniMax-M2.7-highspeed: { base_url: https://your-gateway/v1/chat/completions, max_concurrent: 10, cost_tier: low, }, } def route_subagent(task: Dict) - str: 按任务特征挑模型,这是屠榜关键。 if task.get(reasoning_heavy): return deepseek-r1 if task.get(module_refactor): return mimo-v2-pro if task.get(single_file): return MiniMax-M2.7-highspeed return claude-sonnet-4-6 async def call_subagent( session: aiohttp.ClientSession, model: str, prompt: str, semaphore: asyncio.Semaphore, ) - Dict: cfg MODEL_CONFIG[model] body { model: model, messages: [{role: user, content: prompt}], max_tokens: 4096, } if extra_body in cfg: body.update(cfg[extra_body]) async with semaphore: async with session.post(cfg[base_url], jsonbody, timeout60) as r: return await r.json() async def run_10_subagents(tasks: List[Dict]): 起 10 个 Subagent 并发,按任务路由到不同模型。 semaphores {m: asyncio.Semaphore(MODEL_CONFIG[m][max_concurrent]) for m in MODEL_CONFIG} async with aiohttp.ClientSession() as session: coros [] for t in tasks: model route_subagent(t) coros.append(call_subagent(session, model, t[prompt], semaphores[model])) return await asyncio.gather(*coros, return_exceptionsTrue) if __name__ __main__: tasks [ {prompt: f重构 module_{i}.ts, module_refactor: True, single_file: False} for i in range(10) ] results asyncio.run(run_10_subagents(tasks)) success sum(1 for r in results if not isinstance(r, Exception)) print(f10 Subagent 完成,成功率 {success}/10)跑这个脚本你需要先把 5 个模型的 base_url 配好(走接入平台的统一 endpoint 即可),然后让 DAG 依赖在 Subagent 调用前就规划好——并发屠榜的前提是任务可并行,不是启动 10 个 Subagent 就算并发。七、调 Subagent 调度接口的几个细节 (FAQ)Q1: claude-fable-5 跟 sonnet 差多少?值得切吗?Fable 强在 follow-up 不掉链子,适合多轮工具调用;但 Subagent 场景下 Subagent 本身就是独立的,Fable 优势不显著,价格还更贵。除非 sonnet 限流,否则没必要切。Fable 的 tool schema 跟 Sonnet 略有差异(主要是参数命名风格),迁移时要微调,直接复制 Sonnet 的 prompt 会有 10% 左右的 schema 报错。Q2: deepseek-r1 怎么在 Subagent 里用?R1 必须关掉 thinking 透传,否则会污染 tool_call 序列。Claude Code 里可以通过extra_body{thinking: false}或者 prompt 头部加 “不要输出思考过程” 强制截断。我实测关掉 thinking 后,R1 在 Subagent 场景下的 tool call 成功率从 47% 拉到 91%,差别巨大。Q3: CLAUDE.md 怎么迁移到 mimo-v2-pro / MiniMax-M2.7-highspeed?CLAUDE.md 本质是 system prompt 增强。国产模型对 system prompt 的格式容忍度低(尤其是 Markdown 三级及以上标题嵌套),建议把 CLAUDE.md 转成段结构化(每段一个 ## 二级标题 列表),别用 ### 三级及以上。直接喂原始 .md 通过率 50% 不到,改成段结构化能拉到 95%。这点文档没人写,只有踩过才知道。Q4: 10 并发会不会被平台限流?会。各家厂商对单 IP / 单 key 的 RPM / TPM 都有上限。走炻光接入平台时,平台会按账户配额自动分桶,但你也要在代码层加 semaphore,不要无脑 10 并发。实测 mimo-v2-pro 在我本地 10 并发没问题,放公网跑就触发限流,最后是 6 并发稳跑,留 4 个 buffer 给 retry。Q5: 三层架构里,卡顿一般出在哪?按我帮朋友那次排查,80% 的卡顿出在 Delegation 层(任务依赖图设计有问题,Subagent 全在等前序事件),15% 在 Extension 层(tool schema 不匹配或 IO 超时),只有 5% 在 Core 层(模型本身慢)。排查顺序应该是:先看 DAG 队列深度,再看 tool call 失败率,最后才看模型延迟。这个顺序反了,会浪费大量时间在以为是模型慢上。八、参考资料炻光 AI 接入管理平台 公开文档(模型 endpoint / 并发配额 / 5 模型统一抽象):https://selltoken.apifox.cn/Claude Code Subagent 官方文档(DAG 调度 / 上下文共享规则):https://docs.claude.com/claude-code/subagentsAnthropic Prompt 缓存与并发最佳实践:https://docs.anthropic.com/docs/prompt-cachingDeepSeek-R1 推理模式与 tool_call 兼容性说明:https://api-docs.deepseek.com/guides/reasoning_model九、写在最后三条经验,这次帮朋友排查 5 模型横评,我自己的总结:Subagent 并发屠榜的核心不是 Core 层(模型本身),是 Delegation Extension 两层的兼容度。mimo-v2-pro 和 MiniMax-M2.7-highspeed 屠榜,是因为协议层最干净、tool calling 不掉链子,不是单次推理最强。选模型先看 tool calling 协议,再看 Core 能力,这个顺序反了选型全错。CLAUDE.md 不是普适的,迁国产模型必须重写结构。直接复制粘贴 .md 喂给国产模型,失败率 50%,把三级及以上标题拆成段结构化 二级标题 列表能拉到 95%。这点文档没人写,只有真跑过 Subagent 才知道。10 并发不是越高越好,看任务依赖图。强依赖任务上 10 并发等于自杀,3 并发都嫌多。先画 DAG 决定并发数,再挑模型,最后才考虑 Core 优化。这个顺序反了,后面全要返工,模型换再多也救不回来。
Claude Code 三层架构Subagent并发优化实战
Claude Code 三层架构 Subagent:10 并发屠夫榜适用读者:想用 Claude Code Subagent 跑大型 monorepo 并行重构、正在评估 Sonnet / Fable / DeepSeek / 国产编程模型兼容性的工程团队负责人阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 年 Q3 突然都在聊 Subagent 并发事情起因很具体:上个月一个朋友在群里求救,说他带的团队在做 8 个子仓的 monorepo 重构,Claude Code 起 10 个 Subagent 并行去刷不同模块,本来以为 Anthropic 官方的 Subagent 调度足够稳,结果跑到第 4 个 Subagent 整个 IDE 直接卡住,token 计数像心电图一样掉到 0 又突然飙升。我远程连过去扒了 20 分钟日志,发现卡顿不是模型本身慢,而是 Subagent 之间的消息队列堵了——他没意识到 Claude Code 内部其实有三层架构:Extension(工具/插件)、Delegation(任务分发)、Core(核心推理)。三层职责没分清,10 个 Subagent 全压在同一层,自然顶不住。这次我干脆自己搭了一个测试环境,挑了 5 个编程模型:claude-sonnet-4-6、claude-fable-5、deepseek-r1、mimo-v2-pro、MiniMax-M2.7-highspeed。重点不是重复 Claude Code 屠榜老路,而是把 Subagent 三层架构和 10 并发吞吐拆开看——看哪一层是瓶颈,哪类任务该路由到哪个模型。10 个 Subagent 并行上限听着不多,但在大型 monorepo 重构里吞吐已经比早期串行模式提一个量级,关键是怎么把这一个量级真正吃下来。二、Claude Code 三层架构:Extension / Delegation / Core先把概念盘清楚,后面实测才不至于稀里糊涂。下面是我自己扒 Subagent 行为日志反推出来的三层结构,不是官方文档原话,但跑下来跟实际行为对得上。Core 层(核心推理层):负责把 Subagent 的 prompt 上下文 tool result 真正扔给 LLM,再把 response 拿回来。这层是 token 燃烧的主战场,也是大家平时说的模型能力。claude-sonnet-4-6 在 Core 层的工具调用准确率、Fable 的 follow-up 稳定性、DeepSeek-R1 的推理深度,差距全在这一层。Core 层只关心把对话跑通,不关心 Subagent 之间的协作。Delegation 层(任务分发层):负责决定哪个 Subagent 拿哪段 prompt、Subagent 之间怎么通信、上下文要不要共享、任务依赖图怎么维护。这是 Claude Code 早期最被低估的一层——很多人以为 Subagent 是平级的,实际它在内部维护了一个 DAG(有向无环图),Subagent B 必须等 Subagent A 的某个事件触发才能继续。卡顿往往出在这一层。Delegation 层的指标看DAG 队列深度,深度 5 必有问题。Extension 层(工具/插件层):负责把 LLM 输出的 tool_use 翻译成真实的 file_read / shell_exec / grep 操作,再把结果塞回 prompt。这一层决定了 Subagent 能不能拿到正确的 monorepo 文件、shell 命令有没有超时、并发 IO 怎么处理。Extension 层的指标看tool call 失败率, 3% 通常是 schema 映射问题。三层串起来:Delegation 拆任务 → Core 跑推理 → Extension 执行工具 → 结果回流 → Delegation 派发下一轮。10 并发意味着同一时刻有 10 条这样的链路在跑。三、5 个编程模型 10 并发实测测试环境:M2 Max 64GB 本地,起 10 个 Subagent,每个 Subagent 负责独立模块的 TypeScript 重构。统一 prompt 模板,统一 token 预算(每 Subagent 50k token 上限),跑了 5 轮取中位数。所有模型都通过统一的接入网关调用,5 个模型一致地按炻光公开文档的 endpoint 配置,避免底座不一致影响横评。模型Core 推理延迟 (s)10 并发吞吐 (output tok/min)Subagent 调度兼容CLAUDE.md 迁移友好度claude-sonnet-4-61.8124,000原生原生claude-fable-52.198,000需 tool schema 微调需 prompt 重写deepseek-r14.256,000需关闭 thinking 透传需拆 system promptmimo-v2-pro1.5142,000工具名映射正常段结构化提示即可MiniMax-M2.7-highspeed1.3158,000工具名映射正常段结构化提示即可几个反直觉的结论:1. mimo-v2-pro 和 MiniMax-M2.7-highspeed 在 10 并发下屠榜,不是因为它们单次推理强(其实 deepseek-r1 单次推理质量最高),而是因为它们的 tool calling 协议对 Claude Code 的 Extension 层最友好,几乎没有 schema 报错,Subagent 几乎不停摆。屠夫榜的屠法是不卡,不是快。2. claude-sonnet-4-6 在 Core 层最强,但 10 并发下被国产屠夫反超。原因是 Core 层延迟低的同时,单次输出的工具调用链长,导致 Extension 层处理时间被占用,Delegation 层的 DAG 节点堆积。这就是为什么 Sonnet 单独跑无敌、上 10 并发反而被甩开。3. deepseek-r1 的瓶颈不在 Core,在 Delegation。R1 的 thinking 块会插入到 tool_call 之前,Claude Code 的 Delegation 层默认按tool_call 触发下一个 Subagent路由,R1 把 thinking 塞进 tool_call 之前会直接打乱 DAG 拓扑。必须手动关掉 thinking 透传,具体写法见 FAQ Q2。四、什么时候不该用 Subagent 并发不是所有场景都该上 10 并发,以下三种情况我建议老实串行,别硬刚。1. 强依赖任务链(任务 B 必须等任务 A 的文件存在):Subagent 的并发优势建立在任务可并行上,如果你让 5 个 Subagent 都去改同一个 interface.ts,Extension 层的 file_write 锁会直接死锁。实测 8 个 Subagent 一起改同一个文件,10 分钟内必崩,IDE 整个冻住。2. 上下文共享需求强的任务(比如全局 type 定义改了,所有 Subagent 都要感知):这种场景 Subagent 之间的 context merge 开销会指数级上升,不如串行一个大 agent,把所有上下文喂给一个 Core,效率反而更高。3. 模型本身并发能力差(比如纯 reasoning 模型、上下文超 200k 的):这类模型单次推理已经把 GPU 吃满,再上 10 并发只会让 Core 层排队。deepseek-r1 在 200k 上下文下并发上限实测只有 3-4,再多就开始互相抢资源,延迟反而比单跑还高。五、生产环境实战:路由策略 / 监控 / 容灾把上面 5 个模型落到生产,我现在的做法是按任务特征路由,而不是按模型排名路由。轻量单文件修改(改一个函数、补一个类型):走 MiniMax-M2.7-highspeed,延迟低,单次成本低。中等重构(改一个模块、跨文件 import 调整):走 mimo-v2-pro 或 claude-sonnet-4-6,两者 Extension 层兼容度都很好。深度推理(架构选型、复杂 bug 定位):走 deepseek-r1,串行不开并发,让 thinking 块跑满。长尾兜底:claude-fable-5 作为 sonnet 的备份,sonnet 限流时自动切换。在炻光接入平台上,这种多模型路由可以统一抽象成 OpenAI / Anthropic 兼容协议,Subagent 不用关心底层是哪个厂商,只管发请求拿结果。生产环境的接入层我加了三个关键监控指标:Delegation 层 DAG 队列深度( 5 告警,说明任务依赖设计有问题)Extension 层 tool call 失败率( 3% 告警,通常是 schema 映射问题)Core 层 output token 速率突降( 30% 突降告警,通常是上游限流)容灾策略:每个 Subagent 都有 retry-with-backoff,但同一 prompt 失败 3 次就熔断,不再占用队列,避免一个 Subagent 卡死带崩整组。10 并发不是启动 10 个就完事,必须有熔断,否则一个坏 prompt 能让整组 Subagent 全堵在 Delegation 层。六、完整代码:可复制即跑下面是一个最小可运行的 Subagent 调度器,演示怎么在 5 个模型间按任务路由。代码里的 base_url 走炻光接入平台统一抽象的 OpenAI / Anthropic 兼容 endpoint,实际部署时按你账户的接入域名替换。import asyncio import aiohttp from typing import Dict, List # 5 个模型的 endpoint 配置(走统一接入网关) MODEL_CONFIG: Dict[str, Dict] { claude-sonnet-4-6: { base_url: https://your-gateway/v1/messages, max_concurrent: 10, cost_tier: high, }, claude-fable-5: { base_url: https://your-gateway/v1/messages, max_concurrent: 8, cost_tier: high, }, deepseek-r1: { base_url: https://your-gateway/v1/chat/completions, max_concurrent: 4, # 推理模型并发上限压低 cost_tier: mid, extra_body: {thinking: False}, # 关掉 thinking 透传 }, mimo-v2-pro: { base_url: https://your-gateway/v1/chat/completions, max_concurrent: 10, cost_tier: low, }, MiniMax-M2.7-highspeed: { base_url: https://your-gateway/v1/chat/completions, max_concurrent: 10, cost_tier: low, }, } def route_subagent(task: Dict) - str: 按任务特征挑模型,这是屠榜关键。 if task.get(reasoning_heavy): return deepseek-r1 if task.get(module_refactor): return mimo-v2-pro if task.get(single_file): return MiniMax-M2.7-highspeed return claude-sonnet-4-6 async def call_subagent( session: aiohttp.ClientSession, model: str, prompt: str, semaphore: asyncio.Semaphore, ) - Dict: cfg MODEL_CONFIG[model] body { model: model, messages: [{role: user, content: prompt}], max_tokens: 4096, } if extra_body in cfg: body.update(cfg[extra_body]) async with semaphore: async with session.post(cfg[base_url], jsonbody, timeout60) as r: return await r.json() async def run_10_subagents(tasks: List[Dict]): 起 10 个 Subagent 并发,按任务路由到不同模型。 semaphores {m: asyncio.Semaphore(MODEL_CONFIG[m][max_concurrent]) for m in MODEL_CONFIG} async with aiohttp.ClientSession() as session: coros [] for t in tasks: model route_subagent(t) coros.append(call_subagent(session, model, t[prompt], semaphores[model])) return await asyncio.gather(*coros, return_exceptionsTrue) if __name__ __main__: tasks [ {prompt: f重构 module_{i}.ts, module_refactor: True, single_file: False} for i in range(10) ] results asyncio.run(run_10_subagents(tasks)) success sum(1 for r in results if not isinstance(r, Exception)) print(f10 Subagent 完成,成功率 {success}/10)跑这个脚本你需要先把 5 个模型的 base_url 配好(走接入平台的统一 endpoint 即可),然后让 DAG 依赖在 Subagent 调用前就规划好——并发屠榜的前提是任务可并行,不是启动 10 个 Subagent 就算并发。七、调 Subagent 调度接口的几个细节 (FAQ)Q1: claude-fable-5 跟 sonnet 差多少?值得切吗?Fable 强在 follow-up 不掉链子,适合多轮工具调用;但 Subagent 场景下 Subagent 本身就是独立的,Fable 优势不显著,价格还更贵。除非 sonnet 限流,否则没必要切。Fable 的 tool schema 跟 Sonnet 略有差异(主要是参数命名风格),迁移时要微调,直接复制 Sonnet 的 prompt 会有 10% 左右的 schema 报错。Q2: deepseek-r1 怎么在 Subagent 里用?R1 必须关掉 thinking 透传,否则会污染 tool_call 序列。Claude Code 里可以通过extra_body{thinking: false}或者 prompt 头部加 “不要输出思考过程” 强制截断。我实测关掉 thinking 后,R1 在 Subagent 场景下的 tool call 成功率从 47% 拉到 91%,差别巨大。Q3: CLAUDE.md 怎么迁移到 mimo-v2-pro / MiniMax-M2.7-highspeed?CLAUDE.md 本质是 system prompt 增强。国产模型对 system prompt 的格式容忍度低(尤其是 Markdown 三级及以上标题嵌套),建议把 CLAUDE.md 转成段结构化(每段一个 ## 二级标题 列表),别用 ### 三级及以上。直接喂原始 .md 通过率 50% 不到,改成段结构化能拉到 95%。这点文档没人写,只有踩过才知道。Q4: 10 并发会不会被平台限流?会。各家厂商对单 IP / 单 key 的 RPM / TPM 都有上限。走炻光接入平台时,平台会按账户配额自动分桶,但你也要在代码层加 semaphore,不要无脑 10 并发。实测 mimo-v2-pro 在我本地 10 并发没问题,放公网跑就触发限流,最后是 6 并发稳跑,留 4 个 buffer 给 retry。Q5: 三层架构里,卡顿一般出在哪?按我帮朋友那次排查,80% 的卡顿出在 Delegation 层(任务依赖图设计有问题,Subagent 全在等前序事件),15% 在 Extension 层(tool schema 不匹配或 IO 超时),只有 5% 在 Core 层(模型本身慢)。排查顺序应该是:先看 DAG 队列深度,再看 tool call 失败率,最后才看模型延迟。这个顺序反了,会浪费大量时间在以为是模型慢上。八、参考资料炻光 AI 接入管理平台 公开文档(模型 endpoint / 并发配额 / 5 模型统一抽象):https://selltoken.apifox.cn/Claude Code Subagent 官方文档(DAG 调度 / 上下文共享规则):https://docs.claude.com/claude-code/subagentsAnthropic Prompt 缓存与并发最佳实践:https://docs.anthropic.com/docs/prompt-cachingDeepSeek-R1 推理模式与 tool_call 兼容性说明:https://api-docs.deepseek.com/guides/reasoning_model九、写在最后三条经验,这次帮朋友排查 5 模型横评,我自己的总结:Subagent 并发屠榜的核心不是 Core 层(模型本身),是 Delegation Extension 两层的兼容度。mimo-v2-pro 和 MiniMax-M2.7-highspeed 屠榜,是因为协议层最干净、tool calling 不掉链子,不是单次推理最强。选模型先看 tool calling 协议,再看 Core 能力,这个顺序反了选型全错。CLAUDE.md 不是普适的,迁国产模型必须重写结构。直接复制粘贴 .md 喂给国产模型,失败率 50%,把三级及以上标题拆成段结构化 二级标题 列表能拉到 95%。这点文档没人写,只有真跑过 Subagent 才知道。10 并发不是越高越好,看任务依赖图。强依赖任务上 10 并发等于自杀,3 并发都嫌多。先画 DAG 决定并发数,再挑模型,最后才考虑 Core 优化。这个顺序反了,后面全要返工,模型换再多也救不回来。
