去年底，我的 OneUp 自動發文管線在凌晨兩點把同一篇貼文發了八次。八個平台，每個平台八則重複內容。我早上起來看到手機通知的時候，花了四十分鐘手動刪文。

那天我學到的教訓很簡單：Agent 不難做，難的是不讓它失控。

過去一年我建了三套 Agent 系統。辯論引擎讓 GPT-4o、Gemini、Grok 互相辯論再由 Perplexity 事實查核。OneUp 管線從 Google Sheet 讀排程、用 DALL-E 生圖、自動發到八個平台。我們的 AI 平台 的產線監控在凌晨三點自動調參數。每一套都教了我不同的事。

這篇不是理論。是我從踩坑中歸納出的五個原則。

先回答三個問題再動手

在寫任何一行程式之前，我現在會強迫自己回答三個問題：這個 Agent 解決什麼問題？它的權限範圍在哪裡？我怎麼知道它做對了？

聽起來很基本，但我的辯論引擎第一版就是沒想清楚第二個問題。我讓模型可以自由決定辯論輪數，結果某次它跑了二十七輪，把 API 額度燒光。後來我加了硬性上限：最多五輪，超過就強制收斂。

定位不清楚的 Agent 就是一個失控的黑箱。先畫邊界，再寫程式。

API 優先，瀏覽器是最後手段

Agent 的價值在於調用工具完成多步驟任務。但工具整合的複雜度會指數級成長。

我在 OneUp 管線上學到最痛的一課：一開始我試過用瀏覽器自動化來排程發文，結果每次 UI 改版就全部壞掉。後來改走 API，穩定性直接從 60% 跳到 99%。現在我的原則很簡單——API 穩定性永遠優先，瀏覽器自動化只在沒有 API 的情況下才考慮。

資料處理也一樣。輸入資料不乾淨，Agent 就會在垃圾上面做決策。我在〈從 AI 風暴中突圍〉裡談過，結構設計是新的核心競爭力——Agent 的結構設計，從資料清洗那一步就開始了。

拆成模組，出錯才能定位

一個大型 Agent 很難維護。我現在所有系統都拆成四個模組：Input 處理 → 決策邏輯 → 工具調用 → 結果後處理。每個模組獨立可驗證、可回滾。

辯論引擎就是這樣設計的。Input 模組負責解析主題和模式（dialogue/duo/adversarial）。決策模組負責輪次控制和收斂判斷。工具調用模組處理四個模型的 API 呼叫。後處理模組把結果存成 markdown。任何一個模組出問題，不會連帶搞壞其他部分。

這也是我在記憶裡記下的協作原則：複雜工程必須先拆 Phase，每個 Phase 獨立可驗證。一次性處理的結果，通常是中途卡住然後連前面做對的部分一起搞壞。

每一步都要有日誌

Agent 的運作過程必須透明，否則出錯時你根本不知道哪裡壞了。

我的 OneUp 管線八次重複發文事件，就是因為缺少日誌。API 回傳了 timeout，腳本重試了八次，每次都成功排程了一則新貼文。如果我當時有記錄每次 API 呼叫的回傳狀態，就能在第二次重試時發現第一次其實已經成功了。

現在我的所有 Agent 都有三層監控：操作日誌（每一步做了什麼）、決策路徑（為什麼做這個選擇）、成本追蹤（花了多少 API 額度）。透明不是奢侈品，是存活條件。

從最小場景開始

最後一個原則最簡單也最常被忽略：從小開始。

我們的 AI 平台 的監控系統不是一開始就做全產線的。我先讓它只監控一條產線的一個參數，跑了兩週確認邏輯正確，才逐步擴展。我在〈你不是輸在認知〉裡講過「先做個垃圾出來再說」——Agent 也一樣，先跑一個粗糙的 POC，在運轉中優化，比花三個月規劃一個完美系統然後上線就爆炸好一百倍。

Agent 的價值不在於取代人。在於擴展人的能力邊界。但擴展的前提是你先馴服它——定位清楚、模組化、可追蹤、從小開始。每一個原則都是用失敗換來的。