2026 年每個正在打造多智能體系統的人，仍然在畫直線。第一步，然後第二步，然後第三步——每一步都等著前一步。這就是為什麼它很慢，以及如何解決這個問題。
沒人檢查的問題
你建立了一個多步驟的 Agent。它能運作，但也慢。
你以為瓶頸是模型。其實不是。
瓶頸是你畫的形狀。一條鏈——步驟 1 等步驟 2，步驟 2 等步驟 3——即使一半的步驟彼此毫無關聯，也強制順序執行。
「摘要這份文件，然後查天氣」是兩個獨立任務，卻穿著一件工作流程大衣。天氣任務不需要摘要。從來不需要。但如果你把它寫成一條鏈，它還是得等。
這種浪費的等待，乘以幾十個步驟，就是你大部分執行時間消失的地方。
第一章——迴圈 vs 圖形
一個迴圈是一個自我改進的單位：
1嘗試某件事 → 檢查結果 → 調整 → 再試一次
這就是原子。一個 Agent，一個指標，持續循環直到收斂。
迴圈有一個已知的失敗模式：它們只優化你測量的東西，其他一概不管。一個為了快速關閉工單而調校的支援機器人，確實會快速關閉工單——同時滿意度悄悄崩盤。迴圈看不到自己指標以外的東西。這就是古德哈特定律（Goodhart's Law）在你的 Agent 架構中顯現。
圖形透過設計解決了這個問題。與其用一個迴圈追逐一個數字，你建立一個由迴圈組成的網路，讓它們互相監視和校正。節點 A 的輸出餵給節點 B。節點 C 獨立執行，並檢查兩者。沒有單一指標驅動整個系統——結構本身來驅動。
對於 Agent 系統而言，這意味著一個具體的轉變：不要再寫一個從頭到尾包辦一切的 Agent。先設計工作的形狀——什麼必須在什麼之前發生，什麼可以同時執行，什麼實際上需要等待。
第二章——節點、邊，以及分辨它們的測試
一個圖形只有兩個組成部分：
節點（Node）——一個工作單位。一個 Agent、一個任務、一個輸入、一個輸出。
邊（Edge）——一個真正的依賴關係。節點 B 的輸入需要節點 A 的輸出。
幾乎每個人都會犯的錯誤：預設把「然後」當作一條邊。
1「閱讀這段程式碼，然後撰寫變更日誌」2「抓取定價頁面，然後摘要競爭對手功能」
針對工作流程中的每一個「然後」，問一個問題：
下一步驟真的會讀取上一步驟的輸出嗎？
如果是 → 真正的邊。保留順序執行。 如果否 → 沒有邊。等待是浪費的。讓它們平行執行。
如果兩個任務之間沒有資料跨越邊界，它們就是獨立的——而你順序執行的每一對獨立任務，都是你白白丟掉的執行時間。
以下是套用在程式碼中的測試：
1from dataclasses import dataclass23@dataclass4class TaskNode:5 id: str6 prompt: str7 depends_on: list[str] # 此節點實際需要的節點 ID89def has_real_edge(node_a: TaskNode, node_b: TaskNode) -> bool:10 """11 核心圖形工程測試：12 node_b 的提示是否真的需要 node_a 的輸出？13 """14 return node_a.id in node_b.depends_on1516# 範例：大多數「鏈」會收縮成 2-3 個真正的依賴群組17nodes = [18 TaskNode("audit_routes", "列出所有 API 路由檔案", []),19 TaskNode("check_auth", "檢查認證中介層覆蓋率", []),20 TaskNode("fetch_weather", "取得今天的天氣", []),21 TaskNode("summarize", "摘要路由 + 認證發現",22 depends_on=["audit_routes", "check_auth"]),23]2425# audit_routes、check_auth、fetch_weather 之間沒有邊26# 它們平行執行。只有「summarize」有真正的邊——它需要等待。
你目前「先做 A，再做 B，然後做 C」的 Agent，技術上已經是一個圖形了。只是它是最糟的那種——一條單鏈，如果 C 卡住，下游就永遠無法執行。
第三章——建立你的第一個圖形
需求：
- Claude Code（支援 Dynamic Workflows 的最新版本）
- Max、Team 或 Enterprise 方案——工作流程預設開啟。Pro 方案需手動啟用。
打開一個真實的儲存庫。不是玩具範例——效益只在真實規模中顯現。
啟動你第一個圖形的提示：
1建立一個工作流程，用來稽核這個程式碼庫中的每個路由檔案。23針對每個路由檔案，獨立檢查：4- 是否有認證中介層5- 所有參數是否有輸入驗證6- 是否已設定速率限制7- 錯誤處理不會洩漏堆疊追蹤89在所有路由檔案中平行執行這些檢查——10它們彼此之間沒有依賴關係。1112所有檔案檢查完畢後，產生一份整合報告，依嚴重程度分組：重大、警告、資訊。1314彙整步驟應等待所有檢查完成。15在此之前的所有步驟則不應等待。
注意提示本身嵌入的結構：明確指出平行工作，明確命名唯一真正的依賴關係（彙整等待所有檢查完成）。你不是在期望 Agent 推斷出圖形——你是在描述它。
底層發生的事情——編排的簡化版本：
1import asyncio2from anthropic import Anthropic34client = Anthropic()56async def audit_route_file(filepath: str) -> dict:7 """一個節點。獨立於其他所有路由檔案執行。"""8 response = await client.messages.create(9 model="claude-sonnet-5",10 max_tokens=1000,11 messages=[{12 "role": "user",13 "content": f"""稽核此路由檔案，檢查：14 - 認證中介層、輸入驗證、15 速率限制、錯誤處理1617 檔案：{filepath}1819 回傳 JSON：{{"file": "", "issues": [], "severity": ""}}"""20 }]21 )22 return {"file": filepath, "result": response.content[0].text}2324async def consolidate(results: list[dict]) -> str:25 """唯一真正的邊——等待每個稽核節點完成。"""26 response = await client.messages.create(27 model="claude-opus-4-8",28 max_tokens=2000,29 messages=[{30 "role": "user",31 "content": f"""將這 {len(results)} 個路由稽核結果32 整合成一份依嚴重程度分組的報告：3334 {results}"""35 }]36 )37 return response.content[0].text3839async def run_graph(route_files: list[str]):40 # 扇出——所有獨立節點同時執行41 audit_tasks = [audit_route_file(f) for f in route_files]42 results = await asyncio.gather(*audit_tasks)4344 # 扇入——唯一具有真正依賴的節點45 report = await consolidate(results)46 return report4748# 40 個路由檔案，一個提示，一次平行掃描49results = asyncio.run(run_graph([50 f"routes/{f}.py" for f in ["auth", "users", "billing", "orders"]51 # ... 還有 36 個
40 次順序 API 呼叫，每次約 8 秒，總共超過 5 分鐘。同樣 40 次呼叫扇出平行執行：不到 15 秒，時間由最慢的單一檔案決定，而非所有檔案的總和。
第四章——圖形實際上在哪裡失敗
圖形工程在三個可預測的地方會失敗。在遇到之前先了解它們。
上下文崩潰。 扇出 1,000 個節點，然後試圖將全部 1,000 個輸出餵進一個彙整步驟，在合成開始之前就會超出任何上下文視窗。 修復： 分層扇入。將節點分組為 20-50 個一批，摘要每一批，然後彙整這些摘要——而不是原始輸出。
1async def layered_consolidate(results: list[dict], batch_size: int = 30):2 """分層扇入——永遠不要在規模下合成原始輸出。"""3 batches = [results[i:i+batch_size]4 for i in range(0, len(results), batch_size)]56 batch_summaries = await asyncio.gather(*[7 summarize_batch(batch) for batch in batches8 ])910 # 最終彙整針對摘要進行，而非 1,000 個原始結果11 return await consolidate(batch_summaries)
虛假獨立性。 你會假設兩個節點是獨立的，因為它們的提示沒有互相參考——但它們都寫入同一個檔案，或命中同一個有速率限制的 API。那是隱藏的邊。修復： 審查共享資源，而不只是共享資料。兩個有寫入衝突的節點，即使沒有資料依賴，也需要一條邊。
靜默節點失敗。 在鏈中，一個失敗會停止一切——惱人但明顯。在圖形中，200 個節點中有一個失敗，可能會消失在看似完整的報告中。修復： 每個扇入步驟在合成前，將節點數量與預期數量進行比對，並明確標記缺口，而不是靜默地使用部分資料。
1async def safe_consolidate(results: list[dict], expected_count: int):2 if len(results) < expected_count:3 missing = expected_count - len(results)4 print(f"警告：{missing} 個節點靜默失敗。"5 f"報告將不完整。")6 return await consolidate(results)
第五章——擴展到真正的規模
一旦模式在 40 個節點上運作，擴展到幾百個就只是設定變更，而非重新設計——前提是你從第二章開始就正確建立了圖形。
完整的生產形狀：
1 編排器2 |3 +--------+-------+-------+--------+4 v v v v v5 節點 1 節點 2 節點 3 ... 節點 N6 (平行，它們之間沒有任何邊)7 | | | |8 +--------+-------+-------+-------+9 v10 批次摘要 <- 分層扇入11 (每組 30 個)12 v13 最終報告 <- 唯一真正的邊
編排器唯一的任務：將任務分解為節點，識別真正的邊，並分派。它本身不做任何工作——它負責畫圖形。
1async def orchestrate(task: str, resources: list[str]):2 """3 編排器節點——負責分解，不負責執行。4 """5 plan = await client.messages.create(6 model="claude-opus-4-8",7 max_tokens=2000,8 messages=[{9 "role": "user",10 "content": f"""任務：{task}11 可用資源：{resources}1213 分解成一個圖形：14 - 列出每個獨立節點（無共享邊）15 - 列出節點之間的任何真正依賴16 - 如果節點數超過 50，將節點分組為扇入批次1718 回傳 JSON，包含：nodes, edges, batch_groups"""19 }]20 )2122 graph = parse_plan(plan.content[0].text)2324 # 平行執行獨立節點25 node_results = await asyncio.gather(*[26 execute_node(n) for n in graph["nodes"] if not n["depends_on"]27 ])2829 # 然後執行依賴節點，僅尊重真正的邊30 final = await execute_dependent_chain(graph["edges"], node_results)3132 return final
這就是圖形工程所代表的實際轉變：你不再是一步步撰寫所有步驟的人，而是成為設計依賴結構的人。Agent 填滿節點。你掌管邊。
當你以圖形而非線條思考時，會發生什麼改變
一個有 40 個步驟的線性 Agent，有 40 個順序失敗點，且延遲是其最慢單一步驟的 40 倍。
一個包含相同 40 個工作單位的圖形，其平行失敗點數量等同於你真正的依賴關係數量——大多數工作流程中通常是 3 到 5 個——且延遲由你最慢的層決定，而非步驟總數。
這不是邊際加速。在執行完全相同底層工作的情況下，這是工作流程花 5 分鐘與花 15 秒的差別。
模型從來不是瓶頸。你畫的那條線才是。
這是截至 2026 年 7 月的多智能體編排模式的技術解析。程式碼範例僅供說明——在部署到生產環境之前，請根據你的環境調整錯誤處理、速率限制和重試邏輯。
感謝閱讀。
![[備忘錄] 主管正在放棄表現不佳的下屬](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1784827522698_408j7z_HN3Kb76awAAvvjF.jpg)
