用 Multi-Agent 架構管理企業內容生產：三個 AI Agent 的分工設計實錄
用三個專職 AI Agent 建立企業內容產線：文章寫手負責知識輸出、網路資訊專家負責情報轉寫、網站架構師負責技術維運。從素材到上線全流程自動化，單篇產出時間從 3-6 小時壓縮到 30-60 分鐘。這篇完整拆解架構設計的決策邏輯、人機分工的邊界劃定，以及實際踩過的坑。
企業內容生產的真正瓶頸不是「沒人寫」
企業內部有兩種內容需求長期被低效處理。
第一種是內部知識輸出。部門成員有大量經驗和決策邏輯，但從「腦中的想法」到「可溝通的文件」之間轉化成本極高。一篇 2000-3000 字的深度文章，人工撰寫需要 3-5 小時。結果是有價值的知識停留在個人層面，無法被團隊複用。
第二種是外部情報收集。AI 產業每週有數十篇重要發布分散在十幾個英文來源，逐一追蹤、閱讀、理解、轉化為可行動的情報，每篇耗時 3-6 小時。大部分團隊的做法是「有空就看、看到什麼算什麼」，缺乏系統性。
這兩個問題的共同本質：從原始資訊到結構化產出的轉化成本過高。不是沒有人有想法，不是沒有值得追蹤的來源，而是中間的轉化環節 — 結構化、編排、翻譯、格式化 — 吃掉了 80% 以上的時間。而這些環節，恰好是 AI 最擅長的工作。
為什麼用三個 Agent，不是一個？
解法不是「找一個 AI 來寫文章」，而是設計一套 Multi-Agent 分工架構。三個專職 Agent 各司其職：
文章寫手（article-writer）：接收部門成員的散亂素材（筆記、想法、經驗），轉化為有結構、有論點的文章。負責萃取核心論點、規劃文章架構、撰寫內容、事實查核、自動上架。
網路資訊專家（web-intelligence）：自動掃描 14 個英文來源，篩選相關文章，解構重組為繁體中文深度分析。負責來源監控、選題建議、內容轉寫、事實查核、自動上架。
網站架構師（gwarket-site）：維護網站技術架構（Next.js SSG + WordPress headless CMS + Cloudflare Pages）。負責效能優化、架構決策、bug 修復、部署管理。
三個 Agent 共用同一條上架 pipeline：透過 WordPress REST API 自動發布，觸發 Cloudflare Pages Deploy Hook 自動 rebuild 上線。
拆分的判斷邏輯
為什麼不用一個 Agent 做所有事？職責不同需要不同的上下文定義。網站架構師需要理解 Next.js 和 Cloudflare 技術棧；文章寫手需要理解寫作風格和結構規範；資訊專家需要理解來源清單和轉寫邏輯。全塞在一起會讓上下文過載，品質下降。
為什麼不拆更多？例如校閱、上架各自獨立？校閱需要看到原始素材才能比對，拆出去會丟失上下文。上架是機械性動作，不需要獨立角色，做成共用指令更合理。過度拆分反而增加人工搬運成本。
這個拆分原則跟企業組織設計一樣：按職能邊界拆，不按流程步驟拆。每個 Agent 的 CLAUDE.md（技能包）是獨立的，修改一個不影響其他 — 跟軟體工程的模組化設計是同一個概念。
人機分工的線怎麼畫
設計原則只有一條：AI 做重複性高、規則明確的工作。人做策略判斷和品質把關。
以文章寫手為例，分工是這樣的：
- 素材接收：AI 萃取核心論點、主動提問補充；人提供原始素材和觀點
- 結構規劃：AI 規劃文章架構；人確認方向
- 內容撰寫：AI 產出完整文章和 SEO metadata；人審閱內容品質
- 事實查核：AI 自動比對素材、偵測自身填補的資訊；人判斷標記項目
- 上架：AI 透過 API 自動發布；人只需要說「上架」
關鍵在最後一項查核。「發還是不發」是策略決策，不是技術判斷，所以留給人。但查核本身的繁瑣工作 — 逐條比對數據、掃描專有名詞來源 — 交給 AI。
AI 會犯錯，重點是用機制修正而不是靠人補
實際運行中遇到的問題和處理方式：
AI 事實偏差。文章寫手在產出文章時，把部署平台 Cloudflare Pages 寫成了 Vercel — 因為素材中提到 Next.js，AI 根據常見搭配自動推測。發現後不只修正錯誤，而是在查核流程中新增「AI 填補偵測」機制：要求 AI 在交付前掃描所有專有名詞，素材中沒有明確提到的標記為警告，主動詢問確認。用機制堵漏洞，而不是期待 AI 下次不犯錯。
效能退步。加入 Featured Image 後 Lighthouse 從 88 掉到 74。因為每步都跑驗證，及時發現是 2560px 原圖被當縮圖載入。改用 WordPress API 回傳的 medium 尺寸縮圖解決。
Deploy Hook 重複觸發。WordPress 更新文章時觸發了兩次 rebuild。用 WordPress transient 機制加上防重複邏輯修正。
WordPress API 被擋。Build server 呼叫 API 回傳 415 錯誤，追查發現是 Wordfence 安全外掛干擾，調整設定加上 retry 邏輯。
這些問題的共通模式：不是靠人盯著防錯，而是建立機制讓錯誤被自動偵測和系統性修復。
MVP 怎麼切：只做「素材到上線」的最短路徑
第一版做了什麼：三個 Agent 的技能包定義、文章寫手和資訊專家的完整 pipeline（素材 → 文章 → 查核 → 上架）、共用上架自動化、事實查核機制（含 AI 填補偵測）、GEO 優化格式。
第一版不做什麼：
- 圖片自動生成 — AI 產圖品質不穩定，手動設定更可控
- 社群貼文 — ROI 不足，先專注網站內容品質
- 自動排程掃描 — 手動觸發已足夠驗證流程
- 多語言輸出 — 先專注繁中，英文版未來再加
- 協作審稿 — 目前單人操作，多人流程增加複雜度
每一個排除項都是因為它不影響核心流程能否跑通。MVP 的切割邏輯就是聚焦最短路徑 — 先證明「素材 → 文章 → 上線」這條線能自動化運作，再談擴展。
跑通之後的數據
- 內部知識輸出：3-5 小時/篇 → 30-60 分鐘/篇，效率提升 3-5 倍
- 外部情報轉寫：3-6 小時/篇 → 25-45 分鐘/篇，效率提升 5-8 倍
- 上架到上線：15-30 分鐘手動作業 → 1 分鐘自動完成，提升 15-30 倍
- SEO 零損失：URL 結構不變，Google Search Console 無新增 404
時間省下來之後，人力重新分配到 AI 做不了的事：策略判斷、選題決策、品質把關。
我的觀點
這個專案讓我驗證了一件事：AI 導入企業內容流程，本質上是一個組織設計問題，不是技術採購問題。
很多企業的做法是買一個 AI 工具、讓員工「試著用用看」，然後發現效果不如預期就擱置。問題不在工具不好，而是沒有設計好人機分工的架構 — 哪些環節交給 AI、交給哪個 AI、人在什麼節點介入、出錯時怎麼修正。這些決策不做好，再好的工具也只是玩具。
Multi-Agent 架構的價值不在於「用了多少個 AI」，而在於它強迫你把流程拆清楚。當你要定義每個 Agent 的職責邊界和技能包，你就必須回答：這個環節到底在做什麼？輸入是什麼？輸出是什麼？品質標準是什麼？這些問題很多企業在人工作業時從來沒有釐清過。
另一個觀察：AI 的查核機制比 AI 的產出能力更重要。產出品質可以迭代提升，但如果沒有系統性的查核機制，錯誤會被放大 — AI 的產出速度越快，錯誤擴散得越快。事實查核中的「AI 填補偵測」就是這個邏輯的產物：與其期待 AI 不犯錯，不如設計機制讓錯誤在上線前被攔截。
常見問題 FAQ
企業導入 Multi-Agent 架構需要工程團隊嗎？
不一定。這個專案的三個 Agent 都是用 Claude Code 搭建的，核心是每個 Agent 的 CLAUDE.md 技能包定義 — 本質上是在寫規格文件，不是在寫程式。需要的是能把流程拆清楚的人，不一定是工程師。但如果涉及網站架構或 API 串接等技術環節，仍然需要對應的技術判斷力。
怎麼判斷某個環節該交給 AI 還是留給人？
看兩個維度：重複性和判斷複雜度。重複性高、規則明確的環節（結構化、格式化、比對查核）交給 AI。需要策略判斷、價值取捨的環節（選題、定調、發布決策）留給人。灰色地帶的處理方式是讓 AI 先做、人來審 — 比如事實查核由 AI 執行，但標記的警告項目由人判斷。
AI 填補偵測機制具體怎麼運作？
在文章交付前，AI 會掃描文章中所有專有名詞（公司名、產品名、平台名、工具名），逐一比對使用者提供的原始素材。素材中沒有明確提到的名詞，會被標記為「AI 填補」並主動詢問使用者確認。這個機制的設計原則是：寧可留空讓人填，也不要 AI 自己猜錯。
