recordings-43.txt

# Mobile Capture 20260510T131118+0000-local-1df64e0455dc

Captured: 2026-05-10T13:11:18+00:00
Source: local
From: macbook

Original files:
- Recordings-43-.txt

## Content

# Recordings-43-.txt

Recordings
從去年 11 月開始就沒有實際寫過一行 code 了 — 但我花的腦力比以前更多

Claude Code 從去年九月之後強到一個程度，我的日常變成拆任務、看產出、做決策。打字的是 agent，不是我

CIO 今年有一篇報導說：2026 的工程師角色正在從 creators 變成 curators — 花更少時間寫基礎程式碼，更多時間在協調 AI agents 的 workflow；重點不再是 prompt engineering，是 orchestration

我很同意，但「怎麼協調」這件事完全沒人教，大家都在自己摸索…

我想從 Cognitive Load Theory 來思考一套 Agentic System Design 跟 Orchestration 框架，今天把最有用的幾個概念整理出來

——

【第一步：搞清楚手上的棋子是什麼類型】

Russell & Norvig 的經典 AI 教科書把 agent 分五級：
 - simple reflex agent
 - model-based agent
 - goal-based agent
 - utility-based agent
 - learning agent (以上四類，都可以演化成這類）

用白話說就是：
 - 看到什麼馬上做(reflex)什麼的
 - 有記憶(model)的
 - 有目標(goal)的
 - 有測量器（utility)來選擇最佳路徑到目標的
 - 會學(learning)的

這是從 agent 內部能力切的

對實際操作多個 coding agent 的開發者來說，更實用的軸是「需要介入多少」：

・Fire-and-forget — 給 spec 就能跑到底（lint fix、unit test、文件生成）
・Context-dependent — 需要讀其他 agent 的產出才能動（API integration、前後端串接）
・Decision-requiring — 跑到一半需要人做架構決策（schema design、auth flow）

這個分類超重要，因為—— 
決定了哪些能平行跑、哪些要排序、哪些需要 standby

跟軟體系統設計一模一樣 — 我們不會把兩個 write-heavy process 同時打到同一個 shared resource 上 （這樣要處理同步問題）

用 Cognitive Load Theory （CLT) 來說（下一段會展開），fire-and-forget task 幾乎不佔開發者的 working memory，而 decision-requiring task 才是真正消耗 germane load 的地方 — 分類本身就是在做認知資源的檢傷

——

【第二步：用 Cognitive Load Theory 重新看自己的腦】

John Sweller 1988 年提出 CLT

核心很簡單：人的 working memory 同時只能處理 2-4 chunks of information （我們也沒這麽會平行化，是吧😂）

他把認知負擔分三種：

Intrinsic load — 任務本身的複雜度。Sweller 用一個概念叫 element interactivity：元素之間互相依賴越多、維度越多，intrinsic load 越重。背乘法表是低 interactivity，解聯立方程式是高 interactivity

Extraneous load — 不必要的雜訊。在不熟的 IDE 裡 debug，跟 IDE 搏鬥的腦力不貢獻於解 bug。同時追蹤 4 個 agent 各自寫了哪一行 code — 這就是 extraneous load，我們在做 agent 該做的事

（這個有趣，我們是不是常常搞不清楚 Coding Agent 或是 AI 有哪些功能可以用？對，應該先把該學的指令、操作方式學一學）

Germane load — 建立 overall picture 的負擔。大腦在把零散資訊組織成 coherent 的 mental model（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（該保留）

有人實測同時跑四個 feature agent，心得是：「切換成本很低，因為切的是 review 和 decision，不是 implementation context」

切.換.的.「層級」.決.定.了.認.知.成.本.

這個框架直接影響 agentic system 的設計：
Agent B 應該只需要讀 Agent A 的 output artifact（API contract、test result、schema file），不需要讀 Agent A 的推理過程；推理過程就是被放進系統的 extraneous load — 多餘的 agent 間 memory sharing 等於在幫開發者（或下游 agent）製造雜訊

——

【第三步：Element Interactivity — 判斷任務能不能拆的關鍵】

element interactivity 這個概念值得單獨拉出來講，因為它同時決定了三件事：

1. 一個 task 的 intrinsic load 有多重
2. 這個 task 能不能被分解給多個 agent
3. 分解之後 fragmentation 的代價有多高

高 interactivity = 多個元素必須同時處理 = 不適合拆
低 interactivity = 各元素可以獨立處理 = 適合平行化

BPM 2023 有一篇研究專門看了 abstraction 和 fragmentation 的認知效應，結論是 ——

“abstraction over fragmentation”

隱藏不相關資訊有利於理解，但把相關資訊分散到多個片段反而提高認知負擔

用 agent 的語言說：把一個 user CRUD module 拆成 5 個 agent task（migration、model、controller、route、validation），每個 agent 各自完成了，但 field 名稱不一致、validation 不知道 controller 期望什麼 input format，結果是 — 

我們花更多時間 debug 彼此整合不一致的問題

適當粒度：讓每個 agent 有足夠的 context 做出 coherent 的產出 — 1 個 agent 負責一個完整的 bounded context — 比 5 個 agent 各負責一層更有效

用 CLT 的話來說：過度分解看似降低了每個子任務的 intrinsic load，但增加了跨 agent 的 coordination cost — 這個 coordination cost 本身就是 extraneous load

所以 total cognitive load 反而上升了

判斷 decomposition 的兩層 practice：
・Syntactic dependency — 可以自動化。Harness 在 dispatch 前做 static analysis，列出 task 影響的 files，計算 file overlap，自動判斷哪些可以平行
・Semantic dependency — 需要人判斷。兩個 task 可能沒有 file overlap，但有 conceptual dependency（API contract 的設計影響 frontend 的 data flow）；這種 dependency 目前只能靠 domain knowledge （oh yeah! 👍)

前者可以 encode 進 harness 的 task routing logic
後者是開發者不可替代的價值

過度分解反而製造碎片
Abstraction over Fragmentation

——

【第四步：Spec 精度 = Architectural Thinking 的外顯化】

Addy Osmani 講了一個超重要的觀察：模糊的需求在平行執行時會被乘法放大 — 每個 agent 往不同方向偏。精確的 spec 才能在整個 fleet 中乘出精確的實作

我把 spec 分成三層：

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

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

用 CLT 來看：架構邊界層的 spec 就是在替 agent 消除 extraneous load — 它不需要猜測我們想要什麼 retry 策略，它只需要把 well-defined 的 spec 實作出來。模糊的 spec 等於把 decision-requiring 的 intrinsic load 丟給了一個沒有 domain context 的 agent

三層抽象也可以 encode 成 harness 的 task schema：

 - product intent
 - architecture boundary
 - implementation detail

Harness 在收到 task 時，檢查 spec 的層級是否足夠 — 有沒有定義 boundary condition、error handling strategy、interface contract；不夠的話就 flag 出來讓人補完，而不是讓 agent 自己猜

Strong engineers get MORE leverage from agents — 不是因為他們寫更好的 prompt，是因為他們本來就有更清晰的 architectural thinking

Spec 不再是 prompt，spec 是 product thinking 的外顯化

——

【第五步：認知外部化 — 從 CLT 到 Memory Architecture】

CLT 的前提是 working memory 有限（2-4 chunks），但 long-term memory 幾乎無限。Schema 把多個元素打包成一個 chunk，讓 working memory 處理更複雜的資訊

Clark & Chalmers 在 1998 年提出 Extended Mind Thesis — 認知過程不限於大腦內部，可以延伸到環境中的工具和 artifacts

 - 筆記本
 - ADR（Architecture Decision Records）
 - AGENT.md

— 都是 extended mind 的實例

這個概念直接對應到 agentic system 的 memory 設計。
把 agent memory 分成四類，每一類對應不同的外部化需求：

・Semantic memory → AGENT.md — domain knowledge，這個 agent 需要知道什麼背景
・Episodic memory → session log / git history — what happened，上次做了什麼
・Procedural memory → workflow scripts / harness config — how to do，步驟和流程
・Strategic memory → MEMORY.md — what 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 到 file，Agent B 讀 file — 某些程度這是 IPC 的 pipe 模式 — Context window = RAM，filesystem = disk，每次 LLM call 都是 stateless 的

Strategic Memory 特別值得一提 — 它記錄的是 operational knowledge：「上次 payment module 用 fixed interval retry，在 high traffic 時造成 thundering herd → 改用 exponential backoff + jitter」

這不是 episodic memory（記錄事件），是 distilled causality（萃取因果）

讓每個 session 都能站在前一個 session 的肩膀上

——

【第六步：Feedback Loop — 用 Agent 的過程訓練設計 Agent 的能力】

最後繞回來

Chris Argyris 在 1977 年區分了兩種學習：single-loop 是修正行動來達成目標（「這次 agent 的 spec 寫太模糊，下次寫清楚一點」），double-loop 是質疑目標本身是否正確（「我對 agent 的分工方式根本設計錯了，需要重新定義 task boundary」）

在用 agent 的過程中發展出 sense，然後反過來改進 harness 設計 — 這就是 double-loop

更常聽到的是 — Meta-cognition

三條 feedback 路徑：

 — 我們在協調 agent 時練出的 decomposition sense → 就是 harness 該內建的 task routing logic
 — 我們用 CLT 判斷認知負擔的框架 → 就是 agent 之間 memory sharing boundary 的設計依據
 — 我們外部化認知的習慣 → 就是 Strategic Memory 的 schema 和使用場景

用 agent 的過程訓練我們設計 agent 的能力

這個 feedback loop 才是真正的 flywheel 

-----

同時管多個 agent 是現在必學的 — 認知瓶頸出現在哪裡？是 decomposition 判斷、spec 精度、還是 agent 之間的 coordination？

Having fun? Nah nah….🧘🧘🧘