AI 系統架構設計：為什麼我選純 API 不用 Agent 框架
上一篇把跨語言社群聲量分析的需求拆完了，這篇記錄下一步：怎麼從需求長出系統架構、每個技術選型背後的判斷邏輯。結論先講 — 我沒有用任何 Multi-Agent 框架，四模組線性 pipeline 加純 Claude API 就夠了。這個決策本身就是這篇文章最重要的內容。
為什麼不用 Multi-Agent 框架：線性流程不需要圖引擎
設計系統架構的第一個問題：要不要用現成的 AI Agent 框架？
我評估了三個選項：
CrewAI。角色導向的設計很直覺 — 定義幾個 Agent 角色、分配任務、讓它們協作。GitHub 45K+ stars，社群活躍，上手快。但看完文件後的判斷：對我這個場景過度設計。我的流程是線性的（蒐集→分析→洞察→產出），不需要 Agent 之間互相對話或動態分配任務。用 CrewAI 等於為了一條直線引入一個處理複雜網路的框架。
LangGraph。流程控制能力最強 — 條件分支、並行執行、斷點恢復都支援。但學習曲線陡峭，即使是簡單的線性流程也需要定義 state schema、nodes、edges。對一個人開發的專案來說，框架的抽象層不會加速開發，反而增加 debug 成本。出了問題你要在框架的抽象層裡找 bug，而不是直接看你自己的程式碼。
純 Claude API + Python 腳本。這是我最終的選擇。零學習成本、完全控制、無額外依賴、debug 的時候直接看 input/output 就好。
決策背後有四個判斷：
- 流程是線性的。蒐集→分析→洞察→產出，每一步的輸入是上一步的輸出，不需要條件分支或狀態回溯。線性流程用框架，像是為了寄一封信去建一個郵局。
- 一個人開發。框架的價值在於團隊協作時提供統一的抽象。一個人用 Claude Code 開發，框架的抽象層是純粹的開銷。
- LLM 成本為零。我用 Claude Max 訂閱，API 呼叫不另外收費。框架通常有「減少 token 消耗」的優化邏輯，但這個優勢在訂閱制下完全不適用。
- 作品集的價值在設計決策。面試官看的不是你會不會用 CrewAI，而是你能不能判斷「什麼時候該用、什麼時候不該用」。選擇不用框架本身就是一個有說服力的設計決策。
資料來源的技術限制：API 定價和反爬蟲迫使 MVP 範圍調整
需求拆解階段規劃的 MVP 資料來源是：社群媒體 + 當地論壇 + 應用商店評價。實際開始做技術調研後，撞上了現實。
社群媒體 API 的定價問題。官方 API 的免費版只能寫不能讀 — 完全不能用於資料蒐集。付費版的價格從 $200/月到 $5,000/月，對一個 PoC（Proof of Concept）專案來說不合理。調整方案：改用 Claude 的搜尋能力直接抓取，零成本，但可行性待驗證。
當地論壇的反爬蟲機制。海外 IP 限制加上強力反爬蟲，技術門檻過高。直接放棄，不值得在 MVP 階段花時間攻克。
調整後的 MVP 來源：
- 社群媒體：改用替代方式抓取（可行性待驗證，列為最高技術風險）
- App Store（iOS）：爬取，獨立處理
- Google Play（Android）：爬取，獨立處理。兩個平台分開是因為用戶群不同，而且需要獨立做水軍過濾
- 當地最大的產品資訊網站（月瀏覽量 7.3 億）：從備選升為 MVP 第一批來源，因為結構化程度高、資料量穩定
這裡的判斷邏輯是：MVP 的目標是驗證「從資料到洞察」的核心鏈路有沒有價值，不是追求資料來源的完整性。能穩定取得的來源先上，技術門檻高的延後處理。
分析和洞察拆成兩次 API 呼叫的四個理由
系統架構長這樣：
蒐集層（Python 爬蟲）→ 分析層（Claude API #1）→ 洞察層（Claude API #2）→ 報告產出（Markdown）
其中一個設計選擇需要解釋：為什麼分析和洞察是兩次獨立的 API 呼叫，而不是合併成一次？
四個原因：
- 任務性質不同。分析層是「逐則處理，結構化輸出」— 每一則社群內容各自判斷情感、分類話題、標記可信度。洞察層是「全局綜合，產出判斷」— 把所有分析結果統合成趨勢、比較、行動建議。兩個任務的 prompt 設計邏輯完全不同。
- 合併會降低品質。如果把兩個任務塞進同一個 prompt，prompt 又長又雜，LLM（大型語言模型）的注意力被分散，兩個任務的品質都會下降。
- 中間產物可以存檔。分析層的輸出是結構化數據，存起來之後可以回查 AI 的判斷過程。如果洞察層的結論有問題，可以回到中間產物檢查是分析層就錯了，還是洞察層的綜合有偏差。這對 debug 非常重要。
水軍過濾：可疑評論不刪除，降權比硬刪更安全
App Store 和 Google Play 的評論有大量水軍，如果不處理，分析結果會被嚴重污染。
我在分析層增加了第五個分析維度：credibility（可信度）。每則評論被標記為「可信」或「可疑」。
判斷依據：
- 內容過於簡短且千篇一律
- 用語模板化（像是從同一個模板生成的）
- 評分與內容矛盾（給 5 星但內容在抱怨）
- 同一時間段大量相似評論
- 缺乏產品具體內容（只有泛泛的讚美或批評）
設計上有一個刻意的選擇：可疑評論不刪除，而是在洞察層計算時降權。原因是水軍判斷不可能 100% 準確，硬刪可能誤殺真實用戶的簡短評論。降權是更安全的做法 — 可疑評論的影響力被降低但不是歸零，如果某個趨勢連可疑評論都在講，那它的信號強度反而更高。
配置驅動設計：換產業改配置，不改程式碼
所有可調參數集中在一個配置檔案裡。換產業只改配置，核心分析邏輯不動：
本案的配置：社群媒體 + App Store + Google Play + 產品資訊網站 / 當地語言→中文 / 使用者情感與話題熱度。
如果換到科技硬體產業：社群媒體 + Reddit + 技術論壇 / 英文→中文 / 用戶滿意度與產品缺陷。
配置層和邏輯層分離，意味著換一個產業不需要改程式碼，只需要改資料來源、語言對、分析維度這些參數。這是一次建置、多次複用的前提。
五個技術風險，社群媒體抓取可行性排第一
每個設計決策都有風險，提前列出來才知道驗證的優先順序：
最高風險：社群媒體抓取可行性。替代方案能不能穩定取得資料還沒驗證。這是進入開發階段後第一件要測的事 — 如果這條路不通，需要馬上找替代方案。
中風險：當地語言情感誤判。目標語言的表達方式高度依賴語境，同一句話在不同場景下情感可能完全相反。需要在實測後針對高頻誤判模式調整 prompt。
中風險：商店評論水軍比例。如果水軍佔比過高（例如超過 50%），降權後剩餘的真實評論樣本量可能不足以產出有意義的洞察。
低風險：產品資訊網站結構變動。爬蟲依賴網頁結構，結構改版需要更新爬蟲。但這個網站結構穩定，短期內風險低。
低風險：未上市競品資料量不足。未上市產品的社群討論本來就少，可能不夠產出有意義的分析。但這在 MVP 階段可以接受 — 有多少資料做多少分析。
我的觀點
這次架構設計讓我確認了一個判斷標準：工具選擇的唯一標準是「解決問題」，不是「展示技術」。
CrewAI 很酷，LangGraph 很強，但對我的場景來說，它們不會讓系統更好，只會讓開發更慢。選擇不用它們不是因為不懂，而是因為懂了之後判斷不需要。
同樣的邏輯適用於資料來源的調整。原本規劃的來源更完整，但面對 API 定價和反爬蟲的現實，堅持原方案只會卡死進度。MVP 的目標是驗證核心價值，不是追求完美覆蓋。能穩定取得的先上，有風險的標記出來分階段驗證。
我在工作中見過太多這樣的情況：團隊花了三個月研究框架選型，最後發現業務需求用一個 Python 腳本就能解決。不是說框架沒有價值 — 當你有複雜的多 Agent 協作、需要狀態管理和錯誤恢復的時候，框架是必要的。但很多時候，你的流程就是一條直線，而一條直線不需要一個圖引擎。
能判斷「什麼時候不需要」，比「什麼都會用」更有價值。
常見問題 FAQ
純 API 方案在什麼情況下會不夠用？
當流程從線性變成非線性的時候。例如：Agent 之間需要互相傳遞資訊做動態決策、某一步失敗需要自動回退重試、多個分析任務需要並行執行並合併結果。這些場景下框架的狀態管理和流程控制能力才有真正的價值。我的系統目前是線性的，但如果未來要加入「根據分析結果動態決定是否深入調查某個話題」這類邏輯，就需要重新評估。
水軍過濾用 AI 判斷夠準嗎？
單獨看每一則的準確率不會到 100%，但系統層面夠用。原因是我不靠單則判斷做決策 — 降權機制讓少量的誤判不會影響整體洞察。而且水軍的模式通常是批量的（同時間大量相似內容），這種模式 AI 很容易辨識。真正難判斷的是介於真實和水軍之間的灰色地帶，但這些內容本來就不應該有太高的權重。
為什麼報告用 Markdown 而不是做成 Dashboard？
MVP 階段的優先級是驗證「洞察內容有沒有價值」，不是驗證「呈現方式好不好看」。Markdown 產出最快、最容易檢視和修改。如果洞察內容驗證有價值，再投資做 Dashboard 也不遲。反過來，先做了漂亮的 Dashboard 但洞察內容沒用，那就是在裝潢一間沒有地基的房子。