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 就好。

決策背後有四個判斷：

1. 流程是線性的。蒐集→分析→洞察→產出，每一步的輸入是上一步的輸出，不需要條件分支或狀態回溯。線性流程用框架，像是為了寄一封信去建一個郵局。
2. 一個人開發。框架的價值在於團隊協作時提供統一的抽象。一個人用 Claude Code 開發，框架的抽象層是純粹的開銷。
3. LLM 成本為零。我用 Claude Max 訂閱，API 呼叫不另外收費。框架通常有「減少 token 消耗」的優化邏輯，但這個優勢在訂閱制下完全不適用。
4. 作品集的價值在設計決策。面試官看的不是你會不會用 CrewAI，而是你能不能判斷「什麼時候該用、什麼時候不該用」。選擇不用框架本身就是一個有說服力的設計決策。

第二個決策：資料來源的技術限制與調整

需求拆解階段規劃的 MVP 資料來源是：社群媒體 + 當地論壇 + 應用商店評價。實際開始做技術調研後，撞上了現實。

社群媒體 API 的定價問題。官方 API 的免費版只能寫不能讀 — 完全不能用於資料蒐集。付費版的價格從 $200/月到 $5,000/月，對一個 PoC 專案來說不合理。調整方案：改用 Claude 的搜尋能力直接抓取，零成本，但可行性待驗證。

當地論壇的反爬蟲機制。海外 IP 限制加上強力反爬蟲，技術門檻過高。直接放棄，不值得在 MVP 階段花時間攻克。

調整後的 MVP 來源：

• 社群媒體：改用替代方式抓取（可行性待驗證，列為最高技術風險）
• App Store（iOS）：爬取，獨立處理
• Google Play（Android）：爬取，獨立處理。兩個平台分開是因為用戶群不同，而且需要獨立做水軍過濾
• 當地最大的產品資訊網站（月瀏覽量 7.3 億）：從備選升為 MVP 第一批來源，因為結構化程度高、資料量穩定

這裡的判斷邏輯是：MVP 的目標是驗證「從資料到洞察」的核心鏈路有沒有價值，不是追求資料來源的完整性。能穩定取得的來源先上，技術門檻高的延後處理。

第三個決策：四模組線性 pipeline

系統架構長這樣：

蒐集層（Python 爬蟲）→ 分析層（Claude API #1）→ 洞察層（Claude API #2）→ 報告產出（Markdown）

其中一個設計選擇需要解釋：為什麼分析和洞察是兩次獨立的 API 呼叫，而不是合併成一次？

四個原因：

1. 任務性質不同。分析層是「逐則處理，結構化輸出」— 每一則社群內容各自判斷情感、分類話題、標記可信度。洞察層是「全局綜合，產出判斷」— 把所有分析結果統合成趨勢、比較、行動建議。兩個任務的 prompt 設計邏輯完全不同。
2. 合併會降低品質。如果把兩個任務塞進同一個 prompt，prompt 又長又雜，LLM 的注意力被分散，兩個任務的品質都會下降。
3. 中間產物可以存檔。分析層的輸出是結構化數據，存起來之後可以回查 AI 的判斷過程。如果洞察層的結論有問題，可以回到中間產物檢查是分析層就錯了，還是洞察層的綜合有偏差。這對 debug 非常重要。
4. trong>多一次呼叫不增加成本。Claude Max 訂閱制下，API 呼叫次數不影響費用。這個前提下，拆開的好處遠大於合併省下的那一點延遲。

第四個決策：水軍過濾機制

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 但洞察內容沒用，那就是在裝潢一間沒有地基的房子。