行與子Agent機制解析:線程池并發(fā)如何加速多工具調用)
【免費下載鏈接】CoreCoderMinimal AI coding agent (~1,000 lines of Python) inspired by Claude Code. Works with any LLM. Think NanoGPT for coding agents. Formerly NanoCoder.項目地址https://gitcode.com/gh_mirrors/co/CoreCoder點擊查看免費下載CoreCoder 是一個僅有約一千行 Python 代碼的最小 AI 編程智能體coding agent靈感來自 Claude Code可以連接任意 LLM 自主讀寫文件、執(zhí)行命令。當你讓它看看這三個文件分別寫了啥時它很可能一口氣返回三個工具調用——如果逐個串行執(zhí)行就是干等而 CoreCoder 的解法正是本文的主角線程池并發(fā)加速多工具調用以及用**子Agentsub-agent**隔離重活。下面帶你讀懂這套機制的設計與取舍。背景模型為什么要一次要幾個工具CoreCoder 的核心是一個while循環(huán)把用戶的話交給模型 → 執(zhí)行它要求的工具 → 把結果塞回上下文 → 再問直到模型不再要工具為止corecoder/agent.py。但模型并不總是一次只要一個工具。比如讓它對比三個配置文件它會同時發(fā)出三個read_file調用這三個讀操作彼此獨立串行跑就是白等。于是主循環(huán)里做了一個關鍵的分流if len(resp.tool_calls) 1: # 單個調用直接同步執(zhí)行 result self._exec_tool(tc) else: # 多個調用交給線程池并發(fā)跑 results self._exec_tools_parallel(resp.tool_calls, on_tool)單個調用走最簡單的直跑路徑多個調用則進入_exec_tools_parallelcorecoder/agent.py這是整個并行機制的心臟。線程池并發(fā)多工具調用如何同時跑核心實現(xiàn)只有寥寥數(shù)行with concurrent.futures.ThreadPoolExecutor(max_workers8) as pool: futures {i: pool.submit(run, i, tc, session_cwd) for i, tc in enumerate(tool_calls)} for i, future in futures.items(): i, results[i], worker_cwd future.result()最多 8 個工作線程每個線程跑一個工具最后按原始順序收齊結果——順序一致性對模型很重要結果要能一一對應回它的每個tool_call_id。? 為什么選線程池而不是多進程或協(xié)程工具干的幾乎全是IO 密集的活讀盤、起子進程、等網絡。這種場景下 Python 的 GIL 基本不礙事線程就能跑滿帶寬。ThreadPoolExecutor是標準庫里最省事的并發(fā)原語幾行搞定符合項目能簡則簡的基調。三個文件讀取本來要等三趟 IO現(xiàn)在大致只等最慢的那一趟。并行不是免費的共享可變狀態(tài)會咬人并發(fā)最容易出事的地方是多個任務共享同一份可變狀態(tài)。CoreCoder 里有兩處教科書級的防護。 bash 的 cd 追蹤與線程本地存儲bash 工具需要在多條命令之間記住cd去了哪里corecoder/tools/bash.py。最直覺的存法是一個模塊級全局變量串行時毫無問題可一旦兩個 bash 調用在不同線程里同時讀寫它一個剛改成目錄 A另一個可能正好讀到 A 或覆蓋成 B——典型的競態(tài)平時跑一萬次都對偏偏并發(fā)時給你個莫名其妙還難復現(xiàn)的錯。干凈的解法是用threading.local()把狀態(tài)隔離到每個線程_local threading.local() def get_tracked_cwd(): 取當前線程自己追蹤的 cwd return getattr(_local, cwd, None)此外工作線程啟動時會繼承會話級 cwd批次結束后再把各線程里的cd按調用順序合并回來讓并行的一批 bash對外表現(xiàn)得像串行的一串 bash。相關行為由 tests/test_core.py 中的并行測試守護。 文件寫入的串行鎖并行的另一顆暗雷兩個edit_file同時改一個文件讀-改-寫交錯就會丟編輯。CoreCoder 在工具基類里放了一把全局鎖corecoder/tools/base.pyFILE_MUTATION_LOCK threading.Lock()edit_file/write_file執(zhí)行時都先拿到這把鎖保證同一批并發(fā)里的寫操作串行落地——兩條編輯都不會丟。讀類工具則無需加鎖放心并發(fā)。 這是加并行前必問的一課你的工具扛得住被兩個線程同時調用嗎給 agent 加并行等于給所有帶可變狀態(tài)的工具加了一道并發(fā)正確性要求。權限確認與 Hooks 的前置結算并行還有一個人機交互細節(jié)改文件的工具edit_file、bash、派生子Agent執(zhí)行前要經過用戶確認而且 PreToolUse/PostToolUse hooks 也會圍繞每次調用觸發(fā)。如果讓 8 個線程各自彈確認框終端上會同時冒出好幾個 prompt誰也看不清。CoreCoder 的做法是hooks 和權限判定全部在主線程先行結算完只有放行或拒絕的調用才會提交進線程池。被拒絕的調用不會執(zhí)行其拒絕理由直接作為普通工具結果返回給模型主循環(huán)因此永遠不會卡死在等輸入上。另外即使你在并行批次執(zhí)行中途按下 CtrlC主循環(huán)也會給每個還沒回音的tool_calls補一條占位回復見 corecoder/agent.py保證歷史消息始終合法下一輪請求不會被孤兒消息污染。子Agent機制給主Agent開一個分身如果說線程池解決的是一次多干幾件小事那么agent工具corecoder/tools/agent.py72 行解決的是一件很重的活。獨立上下文把噪音擋在主對話之外想象你讓主 agent把這個陌生代碼庫摸一遍告訴我認證是怎么實現(xiàn)的。它要讀一堆文件、跑一堆搜索這些中間過程全堆進主對話窗口等摸清楚了窗口也塞滿了探索垃圾真正的任務反而沒空間了。子Agent的思路派一個有獨立上下文的分身去干重活它在自己的窗口里折騰干完只交回一句精簡結論sub Agent( llmparent.llm, # 復用同一個模型連接費用并入主會話 tools[t for t in parent.tools if t.name ! agent], # 禁遞歸 max_rounds20, # 輪次上限比主 agent 更緊 ) result sub.chat(task)幾個關鍵的約束設計上下文隔離子Agent擁有全新的messages列表主窗口始終干凈輸出截斷結論超過 5000 字符時截到 4500免得省下的空間又被超長報告吐回去失敗不外溢子Agent拋異常只會變成一段文字結果不會擊穿父循環(huán)狀態(tài)不泄漏子Agent自己cd過的目錄會在返回時恢復不會污染父會話的 shell 狀態(tài)。禁止遞歸分身只能有一層上面那行# no recursive agents是這段代碼里最重要的一句。派生子Agent時工具集被刻意過濾掉agent本身——子Agent手里沒有開分身的能力它干不了的事只能自己硬扛。為什么一刀切因為遞歸 Agent 是一顆隨時失控的炸彈主派子、子派孫……每一層都在燒 token、占線程、加延遲而模型對該不該再拆的判斷并不可靠完全可能陷進越拆越細、永遠收不攏的無底洞。禁掉遞歸要么子Agent自己搞定要么失敗返回沒有第三種走向。很多人以為子Agent是為了并行干更多活其實它最大的價值是上下文管理把別的活的噪音擋在主對話之外其次才是任務分解??焖偕鲜峙芷饋砜纯聪胗H手體驗五分鐘就能跑起來git clone https://gitcode.com/gh_mirrors/co/CoreCoder cd CoreCoder pip install -e .配上OPENAI_API_KEY或 DeepSeek、本地 Ollama 等兩個環(huán)境變量然后corecoder -p 看看這三個文件分別寫了什么a.py b.py c.py注意觀察三個獨立的read_file調用會幾乎同時出現(xiàn)在終端里——那就是線程池在并發(fā)工作。總結從這兩行設計看懂并發(fā)工程機制一句話關鍵文件線程池并發(fā)多個獨立工具調用同時跑IO 密集場景幾行代碼搞定agent.py線程本地 cwd用threading.local消滅競態(tài)tools/bash.py文件寫入鎖并發(fā)批次里寫操作串行落地tools/base.py前置結算權限與 hooks 在主線程完成避免多 prompt 混排agent.py子Agent獨立上下文 禁遞歸 輸出截斷tools/agent.py模型一次返回多個獨立工具調用時線程池并發(fā)是筆劃算的買賣IO 密集場景下它是最省事的并發(fā)原語并行不是免費的它給每個帶可變狀態(tài)的工具都加了一道并發(fā)正確性要求加并行前先問自己扛不扛得住被同時調用子Agent首先是上下文管理手段其次才是任務分解手段禁止遞歸是用一刀切換絕不失控。更多細節(jié)項目里自帶的雙語源碼解讀系列第五篇article/05-parallel-and-subagents.md逐行拆解了這兩塊機制值得一讀。贊分享【免費下載鏈接】CoreCoderMinimal AI coding agent (~1,000 lines of Python) inspired by Claude Code. Works with any LLM. Think NanoGPT for coding agents. Formerly NanoCoder.項目地址https://gitcode.com/gh_mirrors/co/CoreCoder點擊查看免費下載相關推薦DuckDB并行查詢執(zhí)行多線程如何加速復雜分析任務DuckDB并行查詢執(zhí)行多線程如何加速復雜分析任務 你是否經常遇到數(shù)據(jù)分析任務耗時過長的問題當處理百萬甚至上億行數(shù)據(jù)時單線程執(zhí)行往往需要等待數(shù)分鐘甚至更長數(shù)據(jù)庫OLAP嵌入式數(shù)據(jù)庫數(shù)據(jù)分析Forge Task 工具深度解析多 Agent 并行委派、子代理執(zhí)行與會話恢復機制Forge Task 工具深度解析多 Agent 并行委派、子代理執(zhí)行與會話恢復機制 導讀 Forge 的 task 工具是面向復雜多步任務設計的代理型工具人工智能AI Agent代碼智能體AI 應用CLI開發(fā)工具Anomalib 管道并行執(zhí)行ParallelRunner 進程池機制與多 GPU 任務調度實踐Anomalib 管道并行執(zhí)行ParallelRunner 進程池機制與多 GPU 任務調度實踐 本篇指南聚焦 Anomalib 管道pipeline框架人工智能計算機視覺深度學習模型評測創(chuàng)作聲明:本文部分內容由AI輔助生成(AIGC),僅供參考