前兩個月我在重構 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%免費】