AI 幫你把東西都做完了，但你覺得方向有點歪 — 要重跑一次嗎？不，這時需要的是拉「新訊號」進來

當你的 Scaffolding 已經跑完（通常是一個你習慣的、固定的 AI 工作流程），Agent 給你結果，你看了覺得「還 ok，但有些地方不太對」。

這時候不要砍掉重跑，可以做的是：直接在當前 session 中 spawn 一個 sub-agent，用不同的 context 針對你不確定的部分再驗證一次，結果拉回來跟原本的 output 對照。

學術界有人稱之為 Dynamic Decomposition — 跟事先定義好的 Static Scaffolding 相對。arXiv 上今年三月有兩篇重量級的 survey 都在講這件事：一篇是 UIUC、Stanford、Berkeley 等 34 位研究者聯合發的《Adaptation of Agentic AI》，把 agent 跟 tool 的 adaptation 統一成四個 paradigm — 哪個元件被優化、signal 從哪來；另一篇《From Static Templates to Dynamic Runtime Graphs》專門討論 in-execution editing — 計畫在執行過程中被即時修改。兩篇都在上個月更新，方向一致。

簡單說就是：你的 Scaffolding 是本金，但你可以在工作過程中即興加碼。

所以當 —

Code Review 覺得不夠深：

「請幫我 spawn 一個 sub-agent，專門用 security 的角度重新 review 剛才那段 auth module，不要用原本的 context，獨立分析完之後把結果拉回來跟剛才的 review 對照」

Verification 做完 coverage 發現有 gap：

「目前 coverage 有幾個 gap，請在獨立的 context 下做 fix，不要動到目前的驗證結果。修完之後我要拿回來對照 diff」

旅遊規劃想參考外部行程：

「先保留目前的行程不要動，另外去看一下 KKday 跟 Klook 上面同目的地的熱門行程，抓重點回來跟現在的行程對照，看有沒有漏掉的景點」

市場調查觀點不夠有力：

「目前的分析先保留，幫我去查 HBR 跟 McKinsey 最近有沒有相關觀點，找到的話拉回來補強 market opportunity 那一段」

核心邏輯都一樣：保留原本的 context → 開新路出去驗證 → 結果拉回來對照整合。

那為什麼這件事需要你自己來做？

因為 Static Scaffolding 這一層，2026 年的 coding agent 已經幫你做了大半。三月底 Claude Code 原始碼外洩，static scaffolding pattern 一清二楚：

ReAct Loop — while-loop 跑 tool call 收結果再決定下一步，loop 本身 20 行，512K 行全是搭配的 harness
Sub-agent Spawning — 把 sub-agent 當一般 tool call 來爽用
Self-healing Compaction — context 快爆時自動壓縮
ULTRAPLAN — 複雜 planning 外包到遠端跑 Opus 4.6

用《Adaptation of Agentic AI》的框架來看，這些全部屬於 T1 — Agent-Agnostic Tool Adaptation — 工具獨立訓練好，agent 直接當 plug-and-play module 用。Cursor、Codex 同一條路線。所有主要 AI 公司都收斂到同一個核心 pattern — Agent = LLM + Memory + Planning + Tool Use。

再加上社群瘋狂開源 — Claude Code Skills 有上百個專門化 sub-agent，Cursor 有 Rules，Codex 有 AGENTS.md，Anthropic 甚至把 Agent Skills 推成開放標準。這些也全是 T1。

Agent 內建一層，社群再疊一層。Static Scaffolding 幾乎滿到溢出一堆軟體的 AI Slop。

Developer Judgment 作為 adaptation signal

但論文框架裡還有一個 T2 — Agent-Supervised Tool Adaptation — 工具根據 agent 的 output 來調整自己。T2 在論文裡主要講的是自動化的 adaptation，像 reward-driven retriever tuning、adaptive memory modules。

但在開發中做的事情其實更進一步 — 我們是那個 supervision signal。當看到 Agent 的 output，判斷「這個方向偏了」或「這裡需要更深的驗證」，然後即時決定要不要 spawn sub-agent、用什麼 context 去查、結果怎麼整合回來。

這就是「Developer Judgment」作為 adaptation signal 的落地方式。

大家都同意人類要留在 loop 裡面，但留在哪裡？

OpenAI 二月的《Harness Engineering》開頭就寫「Humans steer. Agents execute.」人類排優先順序、驗證結果、agent 卡住時找出缺了什麼餵回 repo。

Anthropic 在《Building Effective Agents》也做了同樣的區分 — Workflows 是預定義路徑，Agents 可以在 checkpoint 暫停等人類 feedback。

大家都同意人類要留在 loop 裡面。但留在哪裡？

Martin Fowler 團隊發的系列文《Patterns for Reducing Friction in AI-Assisted Development》裡面有個概念叫 Feedback Flywheel — 每次你修正 Agent 的 output，就是一個 signal，這個 signal 要被捕捉並回饋到你的開發流程裡，讓下一次更好。

同一個團隊的 Kief Morris 提出三種人跟 AI 的互動位置：

In the loop — review 每一行 code
Out of the loop — 完全放手讓 agent 跑
On the loop — 你不 review 每一行，但你設計並維護引導 agent 行為的機制

On the loop 就是 Dynamic Decomposition 的工程落地。你不是在裡面一行一行看，也不是在外面完全不管 — 你在 loop 上面，設計 scaffolding、觀察 output、在需要的時候即時介入展開新的驗證路徑。

Morris 提了一個很實際的原則：在犯錯成本高的地方插入 friction，在犯錯成本低的地方減少 friction（friction 我是想成「可介入的節點」）。Static Scaffolding 處理低風險的自動化流程，Dynamic Decomposition 處理需要你判斷的高風險時刻。

所以我們開發流程可以直接這樣落地

Static 層 — 用 CLAUDE.md / Skills / AGENTS.md 把團隊標準、架構決策、命名慣例全部編碼進去（Knowledge Priming + Encoding Team Standards 雖然是 fancy word 但顯然不是新東西）
Feedback Flywheel — 每次你修正 agent 的 output，把修正的原因寫回 CLAUDE.md 或 Skills 裡。這不是額外的工作，這是讓你的 Static Scaffolding 越來越準的機制
Dynamic 層 — 當 agent 給你結果你覺得不對的時候，用 Developer Judgment 即時展開：spawn sub-agent、拉外部視角、cross-context 驗證。這個沒辦法自動化，是你 on the loop 的核心價值

讓 AI 自己跑，永遠就做出那 90 分。剩下的 10 分我認為在：

你拿手領域的核心洞察力
你知道什麼時候該從 Static 切換到 Dynamic

on the loop