前两个月我在重构 AlgoMooc 网站过程中发现一个问题在 Claude Code 里把一个任务拆给 5 个 Subagent 并行跑结果可能比 1 个 agent 从头干到尾还慢大多数人的第一反应是反过来的活是并行干的5 个 agent 不说快 5 倍快个两三倍总有吧。这个直觉的问题在于它把能同时运行当成了能同时干完。前者是调度器给的后者要任务结构自己配合。我自己的结论可以先写成一个公式并行的收益等于任务里真正能独立拆分的那部分而并行的税有四项重复认路乘以人头数、依赖链把并行退化成串行、共享文件的冲突处理、主 agent 单点的汇总和验收。收益盖不过四项税的时候5 个就是比 1 个慢。它考的不是 Claude Code 的用法是你有没有把分布式系统的常识迁移到 agent 上的能力。把加机器当成加速度的错误后端工程师在消息队列和微服务上犯过一轮现在轮到 agent 了。上下文隔离、结果只回传摘要这些基础机制我之前写 Subagent 的文章已经讲过这篇不再重复。今天只算账依赖、调度、协调、验收一项一项过。五倍直觉与并行税公式任务结构先于agent数量依赖链怎么锁死总时长官方文档对什么时候并行说得很克制并行研究在各条研究路径互不依赖时效果最好。反过来任务之间有依赖怎么办官方给的姿势是串行链一个 subagent 干完结果回到主 agent主 agent 再把相关上下文转交给下一个。注意这个结构的含义。5 个任务里只要藏着一条 A 到 B 到 C 的依赖链你的总时长就被这条链锁死了这就是调度里的关键路径。B 必须等 A 的产出C 必须等 B真正并行的只有旁边那两个散活。而且每一跳还要多付一笔中转费结果先回主 agent主 agent 消化之后重新派单这段时间链上所有人都在等。这套逻辑其实一点都不新。并行计算里它叫阿姆达尔定律不管加多少处理器加速比永远被任务里串行部分的占比压死。Agent 并行只是这条老定律换了张新皮而且条件更苛刻因为 agent 之间的协调成本比 CPU 核心之间高出几个量级每一次等结果、转上下文都是完整的一轮模型调用。所以拿到任务先别数人头先画依赖图。哪些产出是别人的输入哪些文件是多人要碰的哪些结论要等别人的中间结果。依赖图画出来能并行的部分往往比想象中小。Anthropic 的工程博客里有一句很扫兴但很诚实的话大多数编码任务里真正可并行的子任务比研究类任务少而且模型目前也不擅长实时协调和委派其他 agent。依赖链把并行退化成串行第一项税五个白纸agent各自重新认路Subagent 拿不到你主对话里已经建立的认知。官方文档把这一点直接列为什么时候该用主会话的理由延迟敏感的场景别用 subagent因为它们从零开始需要时间收集上下文。从零开始意味着什么你的主对话已经知道项目结构、知道改动目标、知道哪些文件相关。5 个 subagent 各自要重新读 CLAUDE.md、重新摸目录结构、重新 grep 同一批文件。同样的认路工作被做了 5 遍这些 token 和时间在单 agent 方案里只花一次。Anthropic 博客里对应的失败模式描述是任务描述不够详细时agent 会重复劳动、留下空当、找不到必要的信息。他们给 lead agent 的派单要求是四要素齐全目标、输出格式、工具和信息源的指引、明确的任务边界。四要素本身就有成本你得在派单 prompt 里把主对话的认知重新压缩一遍。写得越省事下游重复认路越严重。重复认路税与派单四要素第二项税调度不是魔法上限和阻塞都写在文档里很多人对并行的想象是无限车道实际的调度机制长这样都是官方文档里的白纸黑字。调度事实官方口径默认并发方式v2.1.198 起 subagent 默认后台并发运行阻塞条件需要某个结果才能继续时前台阻塞等待并发上限默认 20 个超限直接报错拒绝不是排队单会话总量默认最多 200 个 subagent嵌套默认关闭subagent 不能再开 subagent相互通信不支持子代理之间不交换信息其中最容易想当然的是第三条超过并发上限不是排队等空位是报错而且官方明确提示不要立即重试要等运行中的数量降下来。把开 50 个总有 20 个在跑当成策略的人会在报错重试里浪费更多轮次。Anthropic 自己复盘早期系统时列过一个失败案例给简单查询开了 50 个 subagent。这不是假想敌是他们真踩过的坑。第一条也值得多说一句。后台并发听起来很美但后台跑完的结果是以完成通知的形式在之后的轮次里陆续到达主对话的。也就是说主 agent 不是实时看着五个人干活它是在收快递收齐了才能开始汇总。至于让 agent 之间直接商量着干活那不是 subagent 的能力子代理之间不通信需要协作通信是另一套叫 agent teams 的机制成本结构完全不同。调度机制的六条事实第三项税共享文件的所有权比你想的难分5 个 agent 只读不写冲突税约等于零这也是为什么检索、审计、调研类任务是并行的最佳场景。一旦要写文件问题就变成谁拥有哪些文件我去年在 AlgoMooc 的题解动画上踩过一次完整的坑。五道题的动画课件页看起来是五个完全独立的任务一题一个 subagent理论上互不相干。实际跑起来才发现它们共享同一个播放器组件其中一个 agent 觉得组件接口缺一个暂停回调顺手把共享组件改了另外四个基于旧接口写的调用等我合并时全对不上。表面上五个独立任务底下压着一个没人认领的共享依赖。那个下午我花在对齐接口、返工调用上的时间比动画生成本身还多。复盘下来写并行任务的第一件事是把文件所有权切干净每个 agent 一块独占地盘共享的部分要么冻结不许动要么单独立一个任务先改好其他人等它。所有权分不干净的任务就不配并行。同一个任务现在让我重排会是这样第一步单独派一个任务把播放器组件的接口补齐、定稿、冻结这一步串行谁也不等谁第二步五道题的课件并行开工派单里写死一条边界只许写各自题目目录共享组件只读第三步验收尽量交给机器课件页能不能构建、资源路径在不在脚本一跑就知道主线只人工看动画效果这种机器判不了的部分。同样五个 agent把依赖前置、所有权切开、验收自动化之后才轮得到并行发挥作用。worktree 能帮上一部分忙。Claude Code 支持给 subagent 配 isolation: worktree让它在一个临时的 git worktree 里干活写操作物理隔离互相踩不到任务结束时没有改动的 worktree 还会自动清理。git 这一层也有内置保护同一个分支默认不允许被第二个 worktree 检出从机制上堵死了两个人同时站在一根分支上互相覆盖的可能。但要认清它的边界git 官方文档里 worktree 只负责多工作树的写隔离从头到尾没有任何自动合并机制分出去的五份改动怎么合回来、语义冲突怎么处理还是主线的活。物理冲突好办git 会报给你看语义冲突才要命两个 agent 各自改了不同文件单看都对合在一起行为就变了这种冲突任何工具都不会替你发现。还有一个很容易中招的细节Claude Code 的临时 worktree 默认从仓库的 default branch 分出来不是你会话当前的 HEAD。你会话里还没合入的改动worktree 里的子代理根本看不见它是基于一个旧世界在干活。worktree 解决什么不解决什么第四项税最后所有路都汇到一个瓶颈上假设前三项税都交完了5 份产出顺利回来最后一关才是大头谁来汇总、谁来验收、谁来合并跑测试答案只有一个主 agent加上屏幕前的你。官方文档专门有一条警告多个 subagent 各自回传详细结果会把主上下文重新吃满。你用隔离省下的上下文在汇总这一步连本带利还回去。Anthropic 描述自家系统时也承认lead agent 是同步执行 subagent 的等一整批完成才走下一步他们也考虑过异步化但代价是要处理结果协调、状态一致性和错误传播这三座山。验收更是纯串行。5 份交付物要一份一份读、一份一份对齐约定、合并后统一跑测试。我那次动画课件的翻车一半时间就耗在这里第三份产出的接口问题是我合并完前两份之后才暴露的返工又牵连着后面两份。并行生产串行验收验收才是流水线的瓶颈。还有一层容易被忽略的风险放大效应。Anthropic 博客里写过agent 的一步出错可能让它走上完全不同的执行轨迹结果不可预测。单 agent 的跑偏你在对话里当场就能看见、当场纠5 个后台 agent 的跑偏你要等它们全部交卷才知道错误在各自的轨迹里已经复利了一路。人越多发现问题的时点越晚返工半径越大。汇总与验收并行生产串行收口成本账官方自己给的数字值不值得开多 agentAnthropic 在工程博客里给过量级参考引用时我把条件说全在他们的统计里agent 类交互的 token 消耗大约是普通对话的 4 倍多智能体系统大约是 15 倍。他们的结论是多智能体架构要用在任务价值高到付得起这笔溢价的地方。同一篇博客还给了规模参考简单的事实查证1 个 agent 加 3 到 10 次工具调用就够直接的对比类任务2 到 4 个 subagent各 10 到 15 次调用只有复杂的研究类任务才值得上 10 个以上。注意这是研究系统的经验编码任务的可并行度还要再打折扣。需要说明的是他们的多智能体系统在内部研究评测上确实比单 agent 好了 90.2%但那是质量分不是速度而且是研究检索场景。拿这个数字论证多开就是快属于拿着别人的账本记自己的账。官方成本账与规模参考面试怎么答这道题60 到 90 秒版本四步。先破直觉十五秒5 个 agent 快 5 倍的前提是任务完全独立可拆这个前提在编码任务里很少成立。并行收益等于可独立拆分的部分剩下的全是协调成本。再列税单三十秒四项。一subagent 从零启动项目认知要重建 5 遍二任务间有依赖链的话关键路径把并行退化成串行每跳还有主 agent 中转三写共享文件要处理所有权和冲突worktree 只管写隔离不管合并四汇总验收是主 agent 单点串行回传的详细结果还会重新吃满主上下文。给数字背书二十秒Anthropic 官方博客的量级是 agent 约 4 倍 token、多智能体约 15 倍他们明确说这架构只配价值足够高的任务还说编码任务里真正可并行的子任务比研究类少。收口十五秒我的做法是先画依赖图再决定人头数文件所有权切不干净的任务不并行只读的调研类任务才放心大胆开并行。60 秒回答框架面试官大概率会追问的三个问题追问一文件所有权具体怎么划要点按目录或模块给每个 agent 划独占写区共享代码冻结或者前置成单独任务拿不准的 agent 一律给只读工具白名单把写权限收在主线合并动作永远只发生在主线一个地方谁分出去的谁负责收。追问二worktree 是不是把冲突问题解决了要点只解决了一半。它给的是物理写隔离代价是两个新问题临时 worktree 默认从 default branch 分出来看不到会话里未合入的改动起点就是旧的合并和语义冲突处理没有任何自动化还是人和主线的活。隔离越彻底合并时的信息差越大。追问三那什么时候 5 个真的比 1 个好要点三个特征同时满足的时候。任务能被切成互不依赖的块过程产物大但结论短隔离能省下真金白银的上下文产出的验收标准客观机器能判对错不用主线逐份人肉审。典型场景是大仓库的多角度检索和审计。反过来多阶段共享大量上下文的活官方文档明说该留在主会话。写在最后第一并行收益不由 agent 数量决定由任务的依赖结构决定先画依赖图再数人头。第二四项并行税各有出处重复认路、依赖串行化、文件冲突、单点验收每一项官方文档或工程博客都白纸黑字写着。第三worktree 是写隔离工具不是合并工具默认从 default branch 出发这个细节坑过的人才记得住。也说一个我旗帜鲜明的看法把多开 subagent当成性能优化手段方向就偏了。它首先是上下文管理手段省的是主对话的注意力不是墙上时钟的时间。真图快先把任务拆干净拆不干净的任务一个 agent 老老实实串行做完往往就是最快的方案。判断准则还是那句话这个任务里能独立拆分的部分值多少四项税加起来要收多少。税比收益高人多就是添乱。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】