從 AI 使用者到 AI Orchestrator：我如何把 Claude Code 用成多 Agent 作業系統

如果只用一句話總結我這一個月的變化，那就是：我已經不是在「用 AI」，而是在「調度 AI」。

最近我把自己一整個月的 Claude Code 使用紀錄丟進分析器，本來只是想看一些普通的使用者統計，像是互動頻率、工具呼叫密度、上下文長度，或它會不會給我一個「你是 power user」之類的結論。

結果它給我的，是一句更準、也更讓我停下來想幾秒的判斷：

You operate Claude Code as a high-throughput orchestration layer, not a pair-programming partner.

翻成白話就是：

你不是把 Claude 當成陪你寫程式的 AI 助手。你是在把它當成一個高吞吐的 AI 協同作業平台。

這句話之所以準，是因為它點中的不是工具習慣，而是工作抽象層次的改變。過去一年，特別是最近這一個月，我越來越明顯感覺到：當模型能力已經夠強，真正拉開差距的，不再只是你會不會 prompt，而是你會不會 orchestrate。

為什麼我說自己已經不是在「用 AI」？

以前大多數人的 AI workflow 都比較像單點互動。

• 問 ChatGPT 問題
• 叫 Claude 寫 code
• 用 Gemini 查 Google ecosystem
• 用 Perplexity 做 research

這些做法都沒有錯，我現在也還在用。但真正開始產生質變的，不是某個模型忽然全面超車，而是你開始讓不同模型互相審查、互相補盲、互相對撞。

我現在比較常見的工作流，大概是這樣：

• Claude 負責架構與實作
• Codex 當 adversarial reviewer
• Gemini 做 fact check 與 Google ecosystem 視角補充
• Perplexity Deep Research 當 scout
• local model 處理特定推理、記憶治理，或我不想外放的工作

最後，我自己做人類仲裁者。

這種狀態下，我每天做的事情其實已經不太像在「使用一個 AI 工具」，而更像是在管理一個 AI 工程團隊。模型不再只是回答我，而是被我放進不同角色、不同 trust boundary、不同審查流程裡協同工作。

Multi-Agent 最重要的，真的是自動化嗎？

如果你只看表面，Multi-Agent 最迷人的地方確實像是自動化：輸入一句 prompt，然後一群 agents 自己分工、自己討論、自己完成工作。

但我真的把這件事放進大型 repo、真實開發節奏、長上下文工作流之後，感受反而越來越清楚：Multi-Agent 最重要的，不是自動化，而是可觀測性。

Anthropic 在 2024 年 12 月談 agent building 的文章裡，其實就明確區分了 workflows 與 agents，也提醒開發者先用簡單、可組合的模式，而不是一開始就追求複雜框架（Anthropic, “Building effective agents”, 2024-12-19）。

這件事我非常有感。因為當系統變複雜之後，你最需要知道的根本不是「它有沒有動起來」，而是：

• 我能不能看到每個 agent 怎麼推理？
• 我能不能保留完整 audit trail？
• 我能不能回放前一輪決策？
• 我能不能指定角色與責任？
• 我能不能知道哪個 agent 在亂講話？
• 我能不能把錯誤隔離，而不是讓整條鏈一起污染？

AI 最危險的地方，從來不是它不會做，而是它會非常有自信地做錯。專案越大、流程越長、上下文越深，這件事就越危險。

為什麼 AI 工作流最後會走到治理問題？

很多人一開始會把這件事理解成 prompt engineering：只要 prompt 寫得夠精準，AI 就會更可靠。

但只要你真的把 AI 放進日常工作流程一段時間，最後一定會遇到的問題其實是：

• agent 記憶污染
• 推論漂移
• 假共識
• context 遺失
• tool failure
• MCP timeout
• output token ceiling
• 錯誤的 inferred contract
• AI 自以為懂 spec，但其實根本沒懂

也就是說，當 AI 從聊天介面走進 production workflow，你處理的已經不只是 prompt，而是 governance、risk control、memory architecture、trust boundary 與 review pipeline。

這也是為什麼我後來開始建立自己的治理層，例如：

• SOUL.md
• Council Protocol
• Memory Gateway
• staging → review → commit
• 多層治理架構
• AI constitutional layer

這些東西聽起來像流程設計，但它們本質上都在處理同一個問題：當多個 AI 開始參與真實決策，我要怎麼管理信任、限制風險、保留可回溯性？

MCP、tool use 與 agent 系統，為什麼會讓治理變得更重要？

這一波 agent 工作流之所以加速，背後一個很重要的原因是 tool use 與外部系統連接能力正在成熟。MCP 文件把自己描述成 AI 應用連接外部系統的開放標準，像是 AI 世界裡的 USB-C，讓模型能統一接上資料源、工具與 workflow（Model Context Protocol Docs）。

Anthropic 在 2024 年 11 月正式介紹 MCP 時，也把它定位成讓 AI 系統能安全、標準化連到資料與工具的協定，目標是取代碎片化整合（Anthropic, “Introducing the Model Context Protocol”, 2024-11-25）。

這種能力很強，但也正因為它很強，治理才變得更重要。

因為一旦 agent 不只是回答問題，而是可以呼叫工具、讀寫檔案、操作 repo、接觸內部資料，那它的錯誤就不再只是「回答不準」而已，而是可能直接進入你的工作系統、資產系統，甚至審查與發佈流程。

所以我現在看 agent system，第一個問題通常不是「它能做什麼」，而是：

• 它可以做到哪一層？
• 誰批准它跨過下一個 boundary？
• 哪一層一定要保留 human-in-the-loop？
• 哪個工具可以自動執行，哪個只能 staging？
• 出了錯怎麼 rollback？
• 誰負責 final arbitration？

為什麼我越來越相信「可觀測性」比「幻想中的全自動」更重要？

OpenAI 的 agents 教學文件把 agent 拆成幾個核心元件：instructions、guardrails、tools、state/memory、orchestration（OpenAI Developers, “Building agents”）。我覺得這個拆法很實用，因為它提醒你：agent 不是一個神奇黑盒，它是由規則、工具、記憶與協調層組成的系統。

也因此，真正強的多 Agent 系統，不會只追求更多 agent、更多平行、更多自動化，而是更重視這幾件事：

• 有沒有 guardrails
• 有沒有中間態檢查
• 有沒有可審核的決策軌跡
• 有沒有權限分層
• 有沒有錯誤隔離
• 有沒有可重跑與可 rollback 的流程

這和學界這幾年的方向其實也很一致。ReAct 在 2022 年提出把 reasoning 和 acting 交錯起來，重點之一就是讓模型推理軌跡更可解釋，也降低單純 chain-of-thought 式 hallucination 的問題；論文提到它在 ALFWorld 與 WebShop 分別帶來 34% 與 10% 的絕對成功率提升（Yao et al., “ReAct”, arXiv:2210.03629）。

這也是我自己實作時越來越重視的：不是讓 agent 看起來更聰明，而是讓它更能被觀測、更能被審查、更能被糾錯。

大型軟體任務，真的適合盲目堆疊 agent 嗎？

這裡有一個很值得注意的反直覺訊號。

SWE-bench 在 2023 年提出時，收錄了 12 個 Python repo、2,294 個真實 GitHub issue，當時最佳模型只能解掉 1.96% 的問題（Jimenez et al., “SWE-bench”, arXiv:2310.06770）。這件事本身就很說明問題：真實軟體工程，不是把模型接進 repo 就會自動變成 autonomous engineer。

更有意思的是，2024 年的 Agentless 論文反而提出：很多軟體工程任務不一定需要過度複雜的 agent 架構。它用較簡單、較可解釋的三階段流程，在 SWE-bench Lite 上做到 32.00%、96 個 correct fixes，成本只要 0.70 美元（Xia et al., “Agentless”, arXiv:2407.01489）。

這兩個結果對我的啟發非常大。

1. 真實工程問題非常難，不要被 agent demo 迷惑。
2. 複雜不等於更好；很多時候，先把流程拆清楚、可觀測、可審核，比盲目追求 autonomous 更重要。

這也是為什麼我現在對 multi-agent 的看法很務實：我不是不相信 autonomous，而是不相信沒有治理與可觀測性的 autonomous。

這份報告最可怕的地方，是它猜中了我下一步

這份分析最讓我發毛的，不是它描述了我現在怎麼工作，而是它居然預測我接下來會怎麼演化。

它大意上說，下一步我會把現在很多手動觸發的 multi-agent workflow，逐步變成 autonomous pipeline，例如：

• nightly repo audit
• 自動 PR
• agent self-healing
• TDD loop
• 平行 session 協調器
• governance hooks
• live file locking
• autonomous review council

我看到這段時，第一反應其實不是興奮，而是「它怎麼知道」。

因為這不是幻想，這些東西確實就是我最近正在做的方向。很多工作現在已經不是「要不要用 agent」，而是：

• 這個 agent 放在哪一層？
• 誰先做？
• 誰 review？
• 誰有權 merge？
• 哪一段能自動化？
• 哪一段一定要保留 human approval？
• 哪個 memory 能共享？
• 哪個 context 要隔離？
• 哪裡該有 governance hook？

當這些問題開始成為你的日常，你就很難再把自己理解成單純的 AI 使用者了。你比較像是在設計一個新的工作作業系統。

AI 時代，什麼能力會變得更稀缺？

我現在越來越確定，AI 正在重寫工程能力的排序。

以前工程師的價值，很大一部分建立在：

• syntax 熟悉度
• framework 記憶量
• API 背誦能力

這些能力依然有用，但它們的稀缺性正在快速下降。模型在這些區域變強的速度，比多數人追版本的速度還快。

相反地，接下來真正被放大的能力比較像是：

• 問題拆解
• 系統邊界判斷
• risk modeling
• architecture judgment
• governance
• observability
• debugging intuition
• orchestration

也就是說，真正重要的越來越不是「你能不能寫出某段 code」，而是「你能不能設計一個讓多個 AI 與人類一起可靠工作的系統」。

這也是我最近越來越相信的一件事：

未來真正稀缺的人，不一定是最會寫 code 的人，而是最會管理 AI 系統的人。

最後，一句最好笑但也最真實的註解

整份報告裡，我最喜歡的一句其實是：

Claude confidently misdiagnosed a mem0 bug three times in a row before remembering it could just ask Gemini and Codex for help.

翻譯一下就是：

Claude 很有自信地誤判了同一個 bug 三次，直到後來才想起來，它其實可以找 Gemini 和 Codex 一起看。

我看到這句直接笑出來。

因為這不只是在講 AI，它也很像現在的人類世界。很多時候不是能力不夠，而是太習慣單打獨鬥。

而 AI 時代開始之後，真正強的人，可能不再是最強的那個單體。而是最會 orchestrate 一群 Agent 的那個人。

結語

如果過去幾年，AI 帶來的第一階段變化，是讓每個知識工作者身邊多了一個很強的助手，那接下來幾年的第二階段變化，很可能就是：少數人會開始擁有一整支 AI 團隊。

而差別不在於你用了多少模型，也不只是你有沒有最新工具。

真正拉開差距的，是你能不能建立分工、設計治理、控制風險、維持可觀測性，並在多個 agent 同時運作時，依然持續做出正確判斷。

從這個角度來看，我現在已經不太覺得自己只是 AI 使用者。

我更像是一個 AI Orchestrator。

而且我越來越相信，這可能會是未來幾年最重要、也最稀缺的新角色之一。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。