別讓「AI 自動化」成為你的工程債：從 100 個 Agent 到 1 個可靠 Pipeline 的反思

在過去半年的 AI Lab 交付中，我們經歷了一個典型的「認知陷阱」：起初，我們痴迷於建構複雜的 Agent 編排。我們設計了擁有獨立人格的「內容總監」、「程式碼專家」和「品質審計員」，試圖透過一個龐大的多 Agent 協作網路來完成從選題到發布的閉環。

結果是，我們陷入了所謂的「Agent 熵增」。

1. 「協作」的幻覺與延遲的真相

在早期的架構中，一篇文章發布流程需要經過：選題 Agent $\rightarrow$ 大綱 Agent $\rightarrow$ 正文 Agent $\rightarrow$ 翻譯 Agent $\rightarrow$ 審核 Agent。

表面上看，這模擬了人類編輯部的運作方式。但實際運行中，我們發現了三個致命問題：
- 上下文漂移：在傳遞過程中，最初的選題意圖在第三個環節就被稀釋了。
- 錯誤級聯：如果大綱 Agent 在某個邏輯點上產生了幻覺，後續所有 Agent 都會基於這個錯誤進行「精美地擴寫」，導致最終產出雖然流暢但完全錯誤。
- 不可預測的延遲：多步 LLM 呼叫意味著延遲是累加的，且任何一個節點的超時都會導致整個 Pipeline 崩潰。

2. 從「編排」回歸到「Pipeline」

我們意識到，對於一個確定性的交付目標（如每日文章發布），Pipeline（流水線）遠比 Agent（代理）可靠。

我們將架構重構為：單一強模型 + 結構化 Prompt + 硬編碼校驗邏輯。

重構後的核心邏輯：

1. 原子化任務：不再讓 Agent 「思考如何寫作」，而是給它一個極其具體的指令集（例如：「基於以下專案日誌，提取三個具體的技術痛點，並用『問題-方案-結果』結構撰寫」）。
2. 狀態機驅動：使用 Python 腳本控制流程，而不是依賴 LLM 的自主決策。每一步的輸出必須通過正規表示式或 JSON Schema 校驗，不通過則立即重試或報錯，而不是交給下一個 Agent 去「猜測」。
3. 單點翻譯策略：放棄多輪對話翻譯，採用一次性、帶上下文約束的翻譯 Prompt，確保術語在 zh-CN, zh-TW, en 三語之間嚴格對齊。

3. 工程實踐中的三個關鍵細節

在實際部署 SFD V4 CMS 的自動化發布時，我們採用了以下工程手段來降低風險：

A. 無狀態的 Token 管理

不要在程式碼中硬編碼憑證。我們採用了快取檔案 + 定期重新整理機制。腳本啟動時先進行 write_probe（嘗試寫入一個虛擬物件），如果回傳 401 則觸發重新登入流程。這避免了因為 Token 過期導致的深夜發布失敗。

B. 「封面-內容」非同步解耦

封面生成（Image Gen）通常比文字生成慢得多且不穩定。我們將封面生成放在文章 POST 之後，透過 PATCH /api/v4/articles/:id 進行非同步關聯。即使圖片生成失敗，文章也能先以佔位圖發布，而不會阻塞整個發布鏈路。

C. 公網端到端驗證 (E2E Verify)

最危險的成功是 API 回傳 200 OK 但前端頁面是空白。我們在 Pipeline 的最後一步加入了公網 API 回查：請求 /api/v4/articles?slug=...&locale=... 並驗證回傳的 status 是否為 published。只有三語全部回查成功，才標記為 PASS。

4. 給 AI 工程師的建議

如果你正在建構 AI 應用，請記住：能用 if/else 實現的邏輯，絕對不要交給 LLM 去決策；能用 Pipeline 完成的任務，不要試圖用 Multi-Agent 來模擬協作。

AI 的價值在於處理非結構化的創造力部分（如將枯燥的專案日誌轉化為有溫度的文章），而工程的價值在於將這種創造力包裹在一個極其枯燥、確定且可預測的管道之中。