心法三：演進到 Agent Team + 發現人類價值

心法三：演進到 Agent Team，以及發現人類的價值

前兩篇我們走過了工作流程心法的前三個階段：串接工作流程、設計 Context 交接、診斷精煉與平台思維，這一篇談工作流程的後半段，當工作流程開始長大，他會往哪裡演進？而在這個過程中，人類的角色又是什麼？

第四階段：演進到 Agent Team

透過第三階段的循環 — 診斷、精煉、分類 — 周而復始地進行，你會慢慢改善你的工作流程，但在某個時間點，這個工作流程會開始往 Agent Team 的方向演進，你會發現：某些 Skill 變得太複雜，需要自己的 Agent；某些步驟需要不同的工具集；某些任務需要平行處理。這就是第七篇講的場景 — 從 hub-and-spoke 進入需要協作的階段。

這時候要做兩件事：

第一，依照 Agent Team 的概念重新審視工作流程。回頭看第七篇：哪些步驟適合用 Subagent（獨立任務，做完回報）？哪些需要 Agent Team（互相依賴，需要溝通）？不要因為「感覺比較厲害」就開 Agent Team，記住，成本是 15 倍。The New Stack 的 2026 趨勢分析 [14] 也指出，業界預期多數團隊將採用 human-prompted → agent-executed → human-reviewed 的三階段模型，不是所有事情都需要 Agent Team 來處理，大部分工作在這個三階段模型裡就能很好地運作。

第二，分開工作目錄。我建議把不同的 Agent 放在不同的工作目錄，各自有各自的 CLAUDE.md，但也有全域共用的 CLAUDE.md。這樣做的好處是：每個 Agent 的 Context 更乾淨（不會載入不相關的規則），各自的 Skill 和 Tool 可以獨立管理，全域共用的部分確保一致性。morphllm 的 CLAUDE.md 範例分析 [29] 也驗證了這個模式：CLAUDE.md 支援分層架構 — root level（專案級）、~/.claude/CLAUDE.md（全域）、parent directories（monorepo），這天然支持了多 Agent 的分層治理結構，這其實就是第三篇 Context Engineering 的分層策略，從 Token 層面上升到了工作流程架構層面。

第五階段：擴充，以及發現人類的價值

當你反覆經歷前四個階段，你會發現一件事：人類要做的東西正在改變。 你原本花大量時間在寫程式、寫測試、寫文件，現在這些被 AI 處理了，但新的工作出現了，你在做工作流程設計、Context 架構、品質審核、異常判斷。MIT Technology Review 的分析 [13] 精準地描述了這個轉變：人類已提升為監督者、設計師和策略決策者，負責設定目標、定義倫理邊界、處理真正新穎且高風險的挑戰。Anthropic 的 2026 報告 [10] 也觀察到同樣的趨勢：人類監督正從「審查一切」轉向「審查重要的」。

這些新出現的工作，又可以重新用整個前面說到的流程來檢視：這個新工作，可不可以被 AI 取代？如果可以，回到第一階段，把它串進工作流程；如果不行，那就是你找到了人類在這個工作串中真正的價值。這個反覆的過程，本質上是在做兩件事：精煉工作流程 — 讓 AI 能處理的部分越來越多、越來越好；發現人類價值 — 找到那些 AI 無法取代的判斷、創意、決策。

但這裡有一個非常容易踩到的陷阱：當你發現某個新工作「可以被 AI 取代」時，直覺反應往往是建立一個新的 Agent 來處理它。 別急。

Anthropic 在官方指南 “Building Effective Agents” [31] 中說得非常明確：

“找到最簡單的可行方案，只在必要時才增加複雜度。這可能意味著根本不需要建立 agentic system。”

Google DeepMind 與 MIT 的聯合研究 [32] 更用數據證明了這點：當單一 Agent 已經能以 >45% 的準確率完成任務時，加更多 Agent 會產生 diminishing 甚至 negative returns — 因為管理團隊的 coordination overhead 超過了邊際收益。Towards Data Science 基於 1,642 條執行記錄的分析 [33] 也發現，coordination gains 在超過 4 個 Agent 之後就 plateau，超過這個數量，overhead 會吃掉所有收益。

所以，在你決定「建一個新的 Agent」之前，先問自己一個問題：

現有的架構，有沒有辦法透過調整來完成這件事？

具體來說，你可以依序檢查這些更輕量的選項：

• 調整 Rules — 加一條規則就能讓現有 Agent 處理的事，不需要新 Agent
• 精簡 CLAUDE.md — 也許不是能力不夠，而是 Context 太雜，精簡之後現有 Agent 就能勝任
• 調整 Skill — 把新的知識或方法論包進現有 Skill，而不是另起爐灶
• 調整 Command / Skill 入口 — 新增一個入口點來觸發現有 Agent 的不同行為（2026/3/31 更新：Command 預計合併進 Skills）
• 重新劃分 Context 區域 — 用分層或分區的方式，讓現有 Agent 在不同 Context 下工作

LangChain 的 multi-agent 指南 [34] 也坦承：與其加 Agent，不如先把 context engineering 做好 — 連 Anthropic 自己的多 Agent 研究系統，最終合成步驟也是「刻意由單一主 Agent 在一次統一呼叫中完成」的。

只有當你確認以上所有調整都無法解決問題時，才建立新的 Agent。 這不是保守，而是務實 — 每多一個 Agent，就多一份 coordination tax、多一個失敗點、多一筆 Token 花費。就像軟體工程裡的 YAGNI 原則（You Aren’t Gonna Need It）：不要為了假設的未來需求，現在就蓋一個你還不確定需要的東西。

Fortune 2026 年的一篇分析 [21] 定義了三種人機協作模式：Cyborg（人與 AI 深度融合，每一步都協作）、Centaur（人類選擇性地委託特定子任務給 AI）、Self-Automator（盡可能完全自動化）。大部分人會在這三種模式之間流動 — 有些工作適合 Centaur，有些適合 Cyborg，關鍵是你要清楚知道自己在哪個模式裡，以及為什麼。

這不是一次性的結論，而是一個持續演進的過程。隨著 AI 能力的進步，這條邊界會不斷移動，你今天覺得「只有人類能做」的事情，半年後可能就能交給 AI，而半年後的你，會在做今天根本想不到的新工作。

關於「完整性幻覺」的額外提醒

上面談的是「不要急著加 Agent」，但還有一個更隱蔽的陷阱：即使你沒有過度增加 Agent，整個工作流程本身也可能製造出「一切都很好」的錯覺。

RAD Security 提出了「Cosmetic AI」的概念 [27]：工具看起來現代、摘要聽起來聰明，但底層工作根本沒有推進。這個風險同時存在於兩個層面 — 一個是產出的幻覺：你的工作流程可能「看起來」自動化了很多事情，但實際上只是把問題藏到了更深的地方。另一個是架構的幻覺：你的系統有多個 Agent、漂亮的 topology、看起來很 enterprise-grade，但其實兩個 Agent 加上更好的 Skill 就能做到一樣的事。

designative 的分析 [28] 更進一步指出：AI 快速生成的 HiFi 產出會製造「完整性錯覺」，導致審查傾向於表面層級的批評，而非策略性的深度討論。

對策：定期做全系統性的「壓力測試」。不是只檢查每個步驟有沒有正常運作，而是問更根本的問題：

• 如果某個 Agent 給出完全錯誤的結果，下游的工作流程能不能偵測到？
• 如果某個 Context 來源消失了，整個系統會 graceful degradation 還是直接崩潰？
• 這個系統裡有沒有 Agent，其實可以用更簡單的 Rule、Skill 或 Context 調整來取代？
• 最後一次有人從頭到尾人工審查整個工作流程，是什麼時候？

到這裡，五個階段我們都走完了，但如果你現在就開始動手建工作流程，很快會踩到兩個坑，而且這兩個坑，學術研究已經證實它們幾乎無法避免。MIT Press 的研究 [2] 說：LLM 無法可靠地自我糾正；ICSE 2025 的論文 [4] 說：所有主流 LLM 都會犯下建議已棄用 API 的錯誤，這不是「可能會發生」，而是「一定會發生」。

怎麼辦？下一篇，我們談這兩個坑的對策、貫穿整個心法的核心原則，以及這個螺旋還有哪些你必須知道的限制。

參考連結

[2] Huang et al., “When Can LLMs Actually Correct Their Own Mistakes?” (MIT Press/TACL) https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00713/125177

[4] “LLMs Meet Library Evolution” (ICSE 2025) — 所有測試 LLM 都使用已棄用的 API https://dl.acm.org/doi/10.1109/ICSE55347.2025.00245

[10] Anthropic, “2026 Agentic Coding Trends Report” — 60% 工作使用 AI，0-20% 可完全委派 https://resources.anthropic.com/2026-agentic-coding-trends-report

[13] MIT Technology Review, “Human-AI Collaboration Roadmap” — 人類角色轉變為監督者與策略決策者 https://www.technologyreview.com/2025/12/05/1128730/harnessing-human-ai-collaboration-for-an-ai-roadmap-that-moves-beyond-pilots

[14] The New Stack, “5 Key Trends Shaping Agentic Development 2026” — human-prompted → agent-executed → human-reviewed https://thenewstack.io/5-key-trends-shaping-agentic-development-in-2026/

[21] Fortune, “Cyborg, Centaur, or Self-Automator” (2026) — 三種人機協作模式 https://fortune.com/2026/01/30/ai-business-humans-in-the-loop-cyborg-centaur-or-self-automator/

[27] RAD Security, “The Cost of Cosmetic AI” — Cosmetic AI 與完整性幻覺 https://www.radsecurity.ai/blog/the-cost-of-cosmetic-ai-why-gpt-wrappers-drain-more-than-they-deliver

[28] designative, “Rethinking Design Critiques in the Age of AI” — 高保真產出掩蓋深層問題 https://www.designative.info/2025/11/10/rethinking-design-critiques-in-the-age-of-ai-prototyping/

[29] morphllm, “CLAUDE.md Examples 2026” — CLAUDE.md 分層架構範例 https://www.morphllm.com/claude-md-examples

[31] Anthropic, “Building Effective Agents” (2024) — 先用盡簡單方案，只在必要時才增加複雜度 https://www.anthropic.com/research/building-effective-agents

[32] Google DeepMind + MIT, “Towards a Science of Scaling Agent Systems” (arXiv, 2025) — 量化證明加 agent 的 coordination tax 與 diminishing returns https://arxiv.org/abs/2512.08296

[33] Towards Data Science, “Why Your Multi-Agent System is Failing: The 17x Error Trap” (2026) — Agent sprawl 風險與 4 agent 效能天花板 https://towardsdatascience.com/why-your-multi-agent-system-is-failing-escaping-the-17x-error-trap-of-the-bag-of-agents/

[34] LangChain, “How and When to Build Multi-Agent Systems” (2025) — 何時不該用 multi-agent，context engineering 優先 https://blog.langchain.com/how-and-when-to-build-multi-agent-systems/