協調多個 Coding Agent 的框架: 從認知負荷理論談起

• source_url: https://blog.aihao.tw/draft/cognitive-load-agent-orchestration/
• published_at: 2026-06-17
• captured_at: 2026-06-29

看到 Kuan-Yu Hsieh 在 Facebook 上一篇很有料的長文，主題是「怎麼協調多個 coding agent」。他開頭講了一句蠻有感的話: 從去年 11 月開始就沒有實際寫過一行 code 了，但花的腦力比以前更多。打字的是 agent，他的日常變成拆任務、看產出、做決策。

這個轉變其實不是個案。CIO 在今年 2 月有一篇報導 How agentic AI will reshape engineering workflows in 2026，講的就是工程師角色正在從「創造者」(creators) 變成「策展人」(curators): 花更少時間寫基礎程式碼，更多時間在協調 AI agent 的工作流。文章還補了一句: 重點不再是 prompt engineering，而是 orchestration，「設計出完美的單一 prompt 會變成一個基礎、次要的技能」。

問題是，「怎麼協調」這件事幾乎沒人教，大家都在自己摸索。Kuan-Yu Hsieh 的切入點蠻特別的: 用 1988 年 John Sweller 提出的「認知負荷理論」(Cognitive Load Theory, 以下簡稱 CLT) 來思考一整套 Agentic System Design。小編覺得這個角度比一般談 orchestration 的文章都更有結構，幫大家把六個重點整理出來。

1. 先搞清楚手上的 agent 是哪一種類型

經典的 Russell & Norvig AI 教科書把 agent 分成五級: simple reflex(看到什麼馬上做)、model-based(有記憶)、goal-based(有目標)、utility-based(有測量器來選最佳路徑)、learning(會學習)。這是從 agent「內部能力」去切的。

不過對實際操作多個 coding agent 的開發者來說，Kuan-Yu Hsieh 提出一個更實用的軸: 「需要介入多少」。這是他自己跑流程歸納出來的三分類: Fire-and-forget給 spec 就能跑到底。例如 lint 修正、unit test、文件生成。幾乎不佔開發者的注意力。Context-dependent要讀其他 agent 的產出才能動。例如 API 整合、前後端串接。需要排序。Decision-requiring跑到一半需要人做架構決策。例如 schema design、auth flow。要 standby。 這個分類重要的地方在於: 它決定了哪些任務能平行跑、哪些要排序、哪些需要人在旁邊待命。其實跟軟體系統設計的直覺一樣，我們不會把兩個 write-heavy 的 process 同時打到同一個 shared resource 上，不然得處理一堆同步問題。

2. 用認知負荷理論重新看自己的腦

CLT 的核心很簡單: 人的 working memory 同時只能處理 2 到 4 個資訊塊 (chunks)。Sweller 把認知負擔分成三種，這三個概念是整篇框架的地基:

• Intrinsic load(內在負荷): 任務本身的複雜度。背乘法表是低複雜度，解聯立方程式是高複雜度。
• Extraneous load(外在負荷): 不必要的雜訊。在不熟的 IDE 裡 debug，跟 IDE 搏鬥的腦力並不貢獻於解 bug。同時追蹤四個 agent 各自寫了哪一行 code，這也是 extraneous load，等於在做 agent 該做的事。
• Germane load(相關負荷): 建立整體圖像的負擔。大腦把零散資訊組織成連貫的心智模型 (Sweller 稱之為 schema) 時消耗的能量。Review 完 agent 的產出後，判斷「這個 API boundary 劃得對不對」，這就是 germane load。

Sweller 在 2010 年修正了定義: germane load 是「可以用來處理 intrinsic load 的 working memory 資源」。白話說，當 extraneous load 被消除，空出來的 working memory 才能真正投入在有意義的判斷上。

所以同時管四個 agent 的時候，追蹤實作細節是該消除的 extraneous load，做架構判斷才是該保留的 germane load。Lumenalta 有一篇實測同時跑四個 feature agent 的文章 Orchestrating Four Features in Parallel，作者的心得很到位: 切換成本之所以很低，是因為切的是 review 和 decision，不是 implementation 的上下文。他把這個轉變講成: 「你的焦點從『我要怎麼實作這個』變成『這個實作正確且完整嗎』。」

切換的「層級」決定了認知成本。這個觀察直接影響 agentic system 的設計: Agent B 應該只需要讀 Agent A 的 output artifact (API contract、test 結果、schema 檔)，不需要讀 Agent A 的推理過程。推理過程就是被放進系統的 extraneous load，多餘的 agent 間 memory 共享，等於在幫下游的開發者或 agent 製造雜訊。

編按: 順帶一提，這套「把認知負荷分散到多個 agent」的想法已經有正式論文在研究了。arxiv 上的 CoThinker 就直接從 CLT 切入 multi-agent LLM 設計，用「指派專門角色降低 intrinsic load」和「結構化溝通 + 共同工作記憶降低溝通負荷」兩個機制，來突破單一模型在複雜任務上的天花板。

3. Element Interactivity: 判斷任務能不能拆的關鍵

CLT 裡有個概念叫 element interactivity(元素互動性)，指元素之間互相依賴的程度。它同時決定三件事: 一個任務的 intrinsic load 有多重、這個任務能不能分解給多個 agent、以及分解之後碎片化的代價有多高。

高互動性代表多個元素必須同時處理，不適合拆; 低互動性代表各元素可以獨立處理，適合平行化。

BPM 2023 有一篇研究專門看 abstraction(抽象) 和 fragmentation(碎片化) 的認知效應，結論是「abstraction over fragmentation」: 隱藏不相關的資訊有利於理解，但把相關資訊分散到多個片段反而提高認知負荷。

用 agent 的語言講就很具體了: 把一個 user CRUD module 拆成五個 agent task (migration、model、controller、route、validation)，每個 agent 各自完成了，但欄位名稱不一致、validation 不知道 controller 期望什麼輸入格式，結果反而要花更多時間 debug 彼此整合不一致的問題。

比較好的粒度是: 讓一個 agent 負責一個完整的 bounded context，比五個 agent 各負責一層更有效。用 CLT 來看，過度分解看似降低了每個子任務的 intrinsic load，但增加了跨 agent 的協調成本，而這個協調成本本身就是 extraneous load，所以總認知負荷反而上升。

那要怎麼判斷該不該拆? Kuan-Yu Hsieh 分成兩層:

• Syntactic dependency(語法依賴): 可以自動化。Harness 在分派任務前先做 static analysis，列出任務影響的檔案，計算 file overlap，自動判斷哪些可以平行。這層可以 encode 進 harness 的 task routing 邏輯。
• Semantic dependency(語意依賴): 需要人判斷。兩個任務可能沒有 file overlap，但有概念上的依賴 (例如 API contract 的設計會影響 frontend 的 data flow)，這種依賴目前只能靠 domain knowledge。這層是開發者不可替代的價值。

4. Spec 精度 = 架構思考的外顯化

Addy Osmani 在 The Code Agent Orchestra 講了一個很重要的觀察: 模糊的需求在平行執行時會被乘法放大。他的原話是「當你平行協調五十個 agent，模糊的思考不只會拖慢你，它會被乘上去」，每個 agent 會往不同方向偏。精確的 spec 才能在整個 fleet 中乘出精確的實作。

Kuan-Yu Hsieh 把 spec 拆成三層:

• 產品意圖層: 「使用者應該能在付款失敗時自動重試。」
• 架構邊界層: 「重試邏輯放在 payment gateway 的 client wrapper，用 exponential backoff，最多 3 次，超過就發 event 給 notification service。」
• 實作細節層: retry library 的選擇、error code mapping、timeout 數值。

Spec 寫到架構邊界層就夠了，實作細節層交給 agent 處理。但如果只寫到產品意圖層 (只說「處理付款失敗」)，五個 agent 會產出五種不同的重試策略。

用 CLT 來看，架構邊界層的 spec 就是在替 agent 消除 extraneous load: 它不需要猜你想要什麼重試策略，只需要把定義清楚的 spec 實作出來。模糊的 spec 等於把 decision-requiring 的 intrinsic load 丟給一個沒有 domain context 的 agent。

這三層也可以 encode 成 harness 的 task schema (product intent / architecture boundary / implementation detail)。Harness 收到任務時先檢查 spec 的層級夠不夠: 有沒有定義 boundary condition、error handling 策略、interface contract; 不夠就 flag 出來讓人補完，而不是讓 agent 自己猜。

這也解釋了為什麼 Osmani 會說，能力強的工程師從 agent 得到的 leverage 更大。不是因為他們寫更好的 prompt，而是他們本來就有更清晰的架構思考。Spec 不再是 prompt，spec 是 product thinking 的外顯化。

5. 把認知外部化: 從 CLT 到 Memory 架構

CLT 的前提是 working memory 有限 (2 到 4 chunks)，但 long-term memory 幾乎無限，schema 的作用就是把多個元素打包成一個 chunk，讓 working memory 能處理更複雜的資訊。

Clark & Chalmers 在 1998 年提出「延伸心智」(Extended Mind) 的概念: 認知過程不限於大腦內部，可以延伸到環境中的工具和 artifact。筆記本、ADR (架構決策紀錄)、AGENT.md，都是延伸心智的實例。

這直接對應到 agentic system 的 memory 設計。Kuan-Yu Hsieh 把 agent memory 分成四類，各自對應不同的外部化檔案 (他特別註明，其中 Strategic Memory 目前還沒有對應的正式學術分類，是他研究 memory 架構時整理的): Memory 類型對應檔案記什麼SemanticAGENT.mddomain knowledge: 這個 agent 需要知道什麼背景Episodicsession log / git historywhat happened: 上次做了什麼Proceduralworkflow script / harness confighow to do: 步驟和流程StrategicMEMORY.mdwhat worked, why, what next: 什麼有效、為什麼、下次怎麼做 用 CLT 的話來說，這四種 memory 的外部化都是在幫開發者和 agent 消除 extraneous load。如果 agent 每次 session 都要重新理解 domain context (沒有 semantic memory)，或每次都重蹈覆轍 (沒有 strategic memory)，那些重複的認知消耗全都是浪費掉的 extraneous load。

這裡有個小編覺得蠻精準的類比: filesystem 是 agent 之間的 shared memory，Agent A 把 output 寫到檔案、Agent B 讀檔案，某種程度上就是 IPC 的 pipe 模式。Context window 是 RAM，filesystem 是 disk，而每一次 LLM call 都是 stateless 的。

其中 Strategic Memory 特別值得拉出來講。它記的是 operational knowledge，例如「上次 payment module 用固定間隔重試，在高流量時造成 thundering herd，改用 exponential backoff 加 jitter」。這不是單純記錄事件的 episodic memory，而是萃取出來的因果關係，讓每個 session 都能接續前一個 session 的成果繼續往下走。

6. Feedback Loop: 用協調 agent 的過程，反過來訓練設計 agent 的能力

最後繞回到一個 meta 的層次。Chris Argyris 在 1977 年區分過兩種學習: single-loop 是修正行動來達成目標 (「這次 spec 寫太模糊，下次寫清楚一點」)，double-loop 是質疑目標本身對不對 (「我對 agent 的分工方式根本設計錯了，需要重新定義 task boundary」)。

在用 agent 的過程中發展出 sense，然後反過來改進 harness 設計，這就是 double-loop。Kuan-Yu Hsieh 點出三條 feedback 路徑:

• 協調 agent 時練出的 decomposition sense，就是 harness 該內建的 task routing 邏輯。
• 用 CLT 判斷認知負擔的框架，就是 agent 之間 memory 共享邊界的設計依據。
• 外部化認知的習慣，就是 Strategic Memory 的 schema 和使用場景。

用協調 agent 的過程，訓練自己設計 agent 的能力。這個 feedback loop 才是真正的 flywheel。

小編的觀察

這篇最有價值的地方，是它把「協調 agent」這件大家都在憑感覺摸索的事，掛回到一個 1988 年就成熟的認知科學理論上，於是很多直覺有了可以討論的語言: 為什麼過度拆解任務反而更累 (協調成本變成 extraneous load)、為什麼 spec 要寫到架構邊界層 (替 agent 消除 extraneous load)、為什麼 agent 之間不該共享推理過程 (那是雜訊)。

跟 ihower 一直強調的方向也很呼應: 真正的瓶頸早就不在「生成 code」。Osmani 那句話講得直白，「瓶頸不再是生成，而是驗證」。O’Reilly 的 Conductors to Orchestrators 也把這個心態轉變總結成一句: 「我們的工作正在從『我要怎麼寫這個』，變成『我要怎麼讓對的 code 被做出來』。」

所以如果你最近也開始同時管多個 agent，可以借這個框架問自己一個問題: 認知瓶頸到底卡在哪裡? 是 decomposition 的判斷、spec 的精度、還是 agent 之間的協調? 找到那個點，大概就知道下一步該優化什麼了。