# AI Agent 規劃指引：從踩過的坑到可複製的框架

> 導入 AI Agent 之前，必須明確定位與邊界，否則極易淪為失控的黑箱。從 OneUp 自動發文到辯論引擎到 我們的 AI 平台 監控，我踩過的每一個坑都指向同一件事：模組化、可追蹤、從小開始。這篇是我從實戰中歸納出的五個落地原則。

- Author: Paul Kuo（郭曜郎）
- Date: 2025-10-05
- Pillar: 創造與建構 / Creation & Enterprise
- Tags: AI Agent, 自動化, 流程設計, 風險管理, 模組化, Multi-Agent
- Canonical: https://paulkuo.tw/articles/ai-agent-planning-guide/
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

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

<div class="listen-summary" style="margin:1.25rem 0;padding:0.75rem 1rem;border:1px solid var(--border);border-radius:var(--radius);background:var(--bg-section);">
  <div style="font-size:0.9rem;font-weight:600;color:var(--text-secondary);margin-bottom:0.5rem;letter-spacing:0.02em;">▶ 聽摘要</div>
  <audio preload="none" controls style="width:100%;display:block;">
    <source src="https://audio.paulkuo.tw/ai-agent-planning-guide-zh.mp3" type="audio/mpeg" />
    您的瀏覽器不支援音訊播放，請點此 <a href="https://audio.paulkuo.tw/ai-agent-planning-guide-zh.mp3">下載音檔</a>。
  </audio>
  <div style="font-size:0.75rem;color:var(--text-secondary);opacity:0.75;margin-top:0.4rem;">AI 合成語音・作者本人聲線克隆</div>
</div>

那天我學到的教訓很簡單：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 風暴中突圍](/articles/personal-strategy-in-ai-storm/)〉裡談過，結構設計是新的核心競爭力：Agent 的結構設計，從資料清洗那一步就開始了。

## 拆成模組，出錯才能定位

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

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

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

## 每一步都要有日誌

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

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

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

## 從最小場景開始

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

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

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