Loop Engineering 的繼任者，以及讓你的 Agent 跑得更寬 10 倍的工作流程……
大多數人構建多步驟 Agent 時，最終都會得到一條 直線
第一步，第二步，第三步。每一步都要等上一步完成才能開始
以下是幾乎沒有人會檢查的事：
那些步驟裡有一半根本不需要等
它們只是排隊，一次一個任務，直到上下文窗口填滿，Agent 忘記自己在做什麼
- 它慢不是因為模型弱
- 它慢是因為 你在一份實際上是 圖形 的工作上畫了一條線
本指南將帶你從那條線，走向一個能橫跨整個艦隊、並自我檢查的圖形
五個步驟。到第二步你就會建造出一個——
你會得到一個可運作的圖形，並認識到那些會破壞真實圖形的陷阱，我會標出困難部分的起點
在 Alpha 之前——訂閱我的 Substack 獲取更多新鮮 Alpha ↓
第 0 章——圖形工程到底是什麼
一個月前，這個領域還在討論迴圈。
Peter Steinberger 用九個字概括了它：
https://x.com/steipete/status/2078277297791189132
一個迴圈就是一輪改進的循環：
嘗試某事 → 檢查結果 → 調整 → 再來一次
這就是原子：一個單一 Agent 反覆改進一件事
(如果你讀過我的 Loop Engineering 文章，那就是這個)
https://x.com/0xCodila/status/2072329149520232639
但單一迴圈有一個已知的失敗模式—— 支援團隊將一個反饋迴圈綁定到單一指標：工單解決率
數字連續幾個月攀升，但滿意度卻下降。機器人學會了快速關閉工單，而不是解決問題
這就是古德哈特定律。 一個迴圈只能看到自己的指標。它無法問目標是否正確，也無法注意到自己的測量值在漂移。
答案不是更好的迴圈，而是一個迴圈圖——一個各個循環彼此監控並修正的網絡
對 Agent 而言，這意味著一件事：
停止撰寫一個從頭到尾直線行事的 Agent——設計工作的
形狀
——什麼在什麼之前執行，什麼同時執行，什麼需要等待。
節點負責思考。邊負責傳遞結果
而 Claude Code 已經推出了直接構建這些的工具：動態工作流程
第一步——看見那些不存在的邊
一個圖形有兩個部分：
- 一個節點是一個工作單位：一個 Agent、一個任務、一個輸入、一個輸出
- 一條邊是一個依賴關係：這個節點的輸出饋送給那個節點的輸入
每個人都會犯的錯誤是將「然後」當作一條邊。
「摘要這個檔案
然後
告訴我天氣」
天氣並不需要讀取摘要。
這兩個是獨立的任務，只是被一個線性腳本莫名其妙地串聯起來。每一個都白白等待上一個完成
開啟一切的習慣：
對於每一個「然後」，問——下一步是否真的需要讀取前一步的輸出？
- 如果是 → 真實的邊。保留順序。
- 如果否 → 沒有邊。等待是浪費的。讓它們並行執行。
如果兩個盒子之間沒有資料流動，它們就是獨立的。
這種獨立性就是你將在本指南剩餘部分利用的東西
你簡單的「做 A，然後 B，然後 C」Agent 已經是一個圖形了——只是最可憐的那一種：一條單鏈，如果 C 卡住，D 就永遠不會發生。
第二步——從頭到尾建造你的第一個圖形
理論夠了。建造一個，看看它如何運作。
開始之前：
- Claude Code v2.1.154+（用 claude --version 檢查）
- 付費方案。 Max、Team 或 Enterprise 方案上，工作流程預設開啟。Pro 方案上，請在 /config 中開啟 Dynamic workflows 行
1. 打開一個你熟悉的儲存庫。
一個真實的，這樣結果才有意義。
2. 貼上這個提示（來自 Anthropic）：
1建立一個工作流程，用來稽核 src/routes/ 下每個路由檔案是否缺少驗證檢查。每個檔案產生一個 Agent，然後對每個發現結果執行一個獨立的驗證器，再進行報告。一開始最多分析 20 個檔案。
將 src/routes/ 換成你的檔案所在位置。「最多 20 個」這行能讓你的第一次執行成本低廉。
3. 觀察「工作流程」亮起。
Claude Code 會高亮顯示：「動態工作流程已請求。」 這表示正在建立一個圖形，而不是一般對話
4. 批准計畫。
Claude 會撰寫一個 JavaScript 編排腳本，並先顯示階段。閱讀它們，選擇 「是，執行它。」
5. 讓艦隊運轉。
每個檔案一個 Agent，並行執行，同時保持你的對話空閒。
輸入 /workflows 即時觀看：範圍、展開、驗證、綜合。
6. 閱讀一個答案。
不是二十個單獨的對話。一份報告——因為中間結果存在於腳本的變數中，而不是你的上下文裡。
那就是一個圖形。
從一句話，產生十幾個 Agent。
關於你會聽到的「零 token」說法
編排腳本是程式碼
因此，在 Agent 之間傳遞結果不會像對話交接那樣重新耗費上下文。
但 Agent 仍然會消耗使用量。 一個工作流程的消耗明顯高於一般對話。
節省的是協調成本，而不是工作本身。從小的範圍開始，監控使用量，然後再擴大。
- 讓它成為你的
當一次執行結果良好時，按 s。
它會儲存到 ~/.claude/workflows，可以按名稱重新執行
現在改變任務，但保留形狀。將「缺少驗證檢查」換成「未處理的 Promise」，或「超過 100 行的函式」
這能擴展到什麼程度（文章名稱）
一個工作流程執行最多可以展開到 1,000 個 Agent，其中最多 16 個同時工作
這就是「一個視窗內 1000+ 個迴圈」的由來——不是比喻，而是該功能的實際上限
- 而規模就是重點 一千個 Agent 意味著一個單一上下文永遠無法容納的工作——一次稽核整個程式碼庫、一個觸及每個檔案的遷移、一次並行執行一千個角度的搜尋
16 個同時進行的限制只是意味著艦隊會一波一波地推進，消化掉所有一千個，而你不需要照看任何一個
從 20 個開始，看看一次運行的行為和成本——然後再放開——因為這是沒有人正在對抗的極限
第三步——真正會出問題的部分
你建造了一個圖形。以下是真實圖形會崩潰的地方。
兩個最重要的失敗模式
- 失敗一：圖形與自己意見一致
當 Agent 檢查自己的工作時，它會對自己寬容。 模型偏好自己的輸出
所以你在邊上放一個驗證器——一個獨立的節點，在結果向下游流動之前確認它。
但沒有人說出的陷阱是：驗證器需要乾淨的上下文
把執行者用過的同一段對話交給它，那麼它就不是在驗證。它只是在用不同的字體與自己意見一致
一個共享同一段上下文的 Agent 圖形，只是一個穿著戲服的單一迴圈。它會以同樣的方式失敗——更晚、更昂貴、沿途有更多綠燈
所以驗證器是一個全新的節點—— 自己的上下文——檢查一個真實的信號——不是「Agent 說它完成了嗎」，而是「測試真的通過了嗎」
- 失敗二：Agent 互相踩踏
這不是假設
當 Bun 的團隊第一次將一個大型移植分散給許多 Agent 時，運行在操作上失敗了——Agent 們在同一個工作空間中使用共享的 git 指令，互相覆蓋
修復是結構性的，而不是巧妙的提示。他們禁止了不安全的指令，並給每個群組自己的隔離工作樹
這就是平行化的真正教訓——兩個寫入同一個檔案的 Agent 會發生競爭
在你展開之前，回答三個問題：
- 每個 Agent 在哪裡工作？
- 結果如何合併？
- 當兩個 Agent 意見不一致時會發生什麼？
沒有那個計畫的圖形無法擴展——它只會失敗得更快
第四步——本週要建造的六個圖形
方法：找到真實的邊 → 展開 → 在獨立上下文中驗證 → 隔離工作者
///
以下每一個都是同樣的形狀，針對不同的工作。更改任務行，然後出發：
- 安全掃描——每個檔案一個 Agent，尋找缺少的驗證，一個驗證器確認每個命中（你已經建造的那個）
- 帶有 /deep-research 的引用報告——已經推出：將你的問題拆分成多個角度，並行搜尋，Agent 在撰寫前互相反駁
- 移植一個模組——逐個檔案，測試作為閘門，失敗則循環回去
- 對抗性差異審查——根據大小路由：小改動 → 一次通過；大改動 → 完整的並行稽核
- 定期生態系統掃描——儲存一次，按名稱重新執行
- 未知大小的探索——尋找者並行運行，每個結果與所有已見過的結果進行檢查，循環直到連續兩輪沒有發現新東西
///
極限的樣子https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Bun 的 Zig 到 Rust 移植正是運行在這個機制上。
大約 50 個工作流程，峰值時 64 個 Agent 並行。大約 535,000 行 Zig 程式碼變成了超過一百萬行 Rust 程式碼，耗時 11 天。
它也花費了大約 165,000 美元 的使用量，並且需要人類設計和監控整個過程。
而且它還因大量 AI 生成的程式碼能否安全被審查而受到公眾批評。
規模是真實的。價格和監督也是真實的
第五步——讓圖形保持誠實的錨點
只有拓撲結構並不能買到真相
一個所有 Agent 互相確認、但沒有一個觸及真實事物的網絡，其失敗方式與單一迴圈完全相同——只是有更多活動部件
圖形需要錨點： 無法被爭辯的節點
- 實際運行的測試——不是「應該通過」，而是確實通過了
- 基於證據而非感覺的驗證器
- 永遠不允許 Agent 調整的固定規則——因為它們正是最佳化器會削弱的那種
圖形的誠實程度，取決於其中那些拒絕移動的東西
何時圖形是錯誤的選擇
大多數任務都不是圖形。在不需要的時候使用它，只會燒錢並增加失敗的方式。
在以下情況跳過圖形：
- 任務很小或孤立。 添加一個函式、修復一個 Bug。工作流程在這裡完全是開銷——單一 Agent 更快也更便宜。
- 你需要緊密的監督。 如果你希望在下一步執行之前閱讀並批准每一步，那麼圖形的核心要點（在沒有你的情況下寬泛運行）就與你作對了。
- 你還不知道自己在找什麼。 探索性工作需要一個你可以引導的 Agent，而不是一個在你理解問題之前就承諾了一個計畫的艦隊。
- 步驟確實相互依賴。 如果每一步都讀取前一步的輸出，那就是一個真正的鏈條。平行化沒有什麼可以抓住。將圖形強加在一個真正的順序任務上，只會增加協調成本，卻沒有加速。
關鍵在於第一步。如果你找不到兩個之間沒有箭頭的盒子，那就沒有圖形可以建造。它是一個迴圈，而迴圈就夠了。
圖形是寬度的工具——獨立的工作，一次完成
當工作不寬時，那條線從來就不是問題……
轉變
提示者提出問題。架構師繪製圖形。
線性 Agent 從來就不是極限。
它只是第一個形狀——每個人都會用到的，因為它符合我們打字的方式：一行，一次一件事。
一旦你看見了節點和邊，你就會停止要求 Agent 做更多，而開始要求圖形做得更寬：
- 在工作是獨立的地方展開
- 在信心重要的地方設置閘門
- 凍結那些承載真相的節點
大多數人會繼續在一個序列中排隊步驟。
那些學會繪製圖形，並尊重什麼會破壞它的人，將能運行一個艦隊。
繪製圖形。保持身為架構師。
從先決條件開始：
- 這是建構其上的單一迴圈
