為什麼你的 Agent 總是失敗？我們的 DBA 驗證 Agent 每一次都失敗。直到有人停下來問一個簡單的問題：「我們有沒有親自驗證過 SQL 環境是可用的？」答案是：沒有。這是一次真實的根本原因分析故事。
問題症狀：Agent 重複失敗的模式
我們的 DBA 驗證 Agent 每一次都失敗，不是「有時候失敗」，而是每一次都失敗。
2026-03-11 14:22 - dba-sonnet agent 啟動
2026-03-11 14:23 - ModuleNotFoundError: analyst.data.db
2026-03-11 14:24 - Agent 卡住，無輸出
2026-03-12 09:00 - 重試，同樣失敗
2026-03-12 15:30 - 又失敗
2026-03-13 08:00 - 還是失敗模式很清楚：Agent 每次都卡在同一個地方，沒有任何進展。
傳統調試法為什麼失敗
我們試過改參數、改配置、改 Agent 模型……什麼都試過了：
- 檢查 Agent 配置 → 配置看起來沒問題
- 改 Agent Prompt → 改了 5 次，還是失敗
- 換更強的模型 → Opus、Sonnet，都失敗
- 加更多上下文 → 還是失敗
- 等待用戶反饋 → 毫無進展
結果：花了 3 小時，毫無進展。我們陷入了「猜測地獄」。
轉折：PUA Debugging 的 5 維度法
當意識到傳統方法行不通後，我們採用了結構化的根本原因分析框架。這改變了一切。
維度 1-3：搜索 + 確認
我們發現 Agent Prompt 中引用的模塊 analyst.data.db 根本不存在。
維度 4：驗證前置假設 ← 關鍵轉折
這是傳統調試永遠到不了的地方。我們停下來問：
「我親自能連接到數據庫嗎？讓我現在就試試。」
結果發現了可行的執行方式：
PGPASSWORD='tdcc1234' psql -U tdcc -h localhost -d analyst -c "YOUR SQL QUERY"這一步改變了一切。
維度 5：反轉假設
- 原假設：「問題出在 Agent」
- 新假設：「問題出在 Prompt 沒有教正確的方式」
- 結果：Agent 一次成功，生成完整報告
失敗 vs 成功的對比
| 項目 | 失敗的 Prompt | 成功的 Prompt |
|---|---|---|
| 說法 | 「使用 SQL 查詢檢查每個表」 | 「執行此命令：PGPASSWORD=… psql …」 |
| 具體性 | 無具體命令 | 20+ 個完整命令 |
| 認證信息 | 無 | 含 DB 用戶名和密碼 |
| 結果 | Agent 失敗 | Agent 成功 |
核心教訓：正確的調試思路
傳統方法會把你困在「猜測地獄」裡：
改 Prompt → 改模型 → 改配置 → 重試 → 還是失敗 → 回到第一步（無限迴圈）
正確的方法是：
- 「環境本身可以做到這件事嗎？」
- 親自測試（不信任 Agent 的假設）
- 記錄可行的執行方式
- 寫詳細的 Prompt（含具體命令）
- Agent 執行 ← 通常一次成功
你的職責不是「讓 Agent 聰明」，而是「給 Agent 正確的路徑」。
驗證結果 — 實證數據
| 表名 | 筆數 | 最新日期 | 狀態 |
|---|---|---|---|
| symbols (TWSE) | 1,344 | — | ✓ |
| symbols (TPEX) | 996 | — | ✓ |
| daily_prices | 232,897 | 2026-03-13 | ✓ |
| institutional_trading | 0 | — | ✗ 缺失 |
| tdcc_distribution | 4,634 | 2026-03-13 | ✓ |
| daily_market_index | 255 | 2026-03-13 | ✓ |
關鍵發現：三大法人數據完全缺失（0 筆），需立即補齊。
應用場景
這個根本原因分析方法適用於：
- 數據庫驗證 ✓
- API 集成 ✓
- 自動化腳本 ✓
- 任何「系統重複失敗」的場景
結語
我們花了 3 小時調試，最後發現答案很簡單：
不是 Agent 需要改變，而是我們需要先驗證環境，然後清楚地描述執行方式。
下次你的系統卡住時，停下來問自己：
「我親自能做到這件事嗎？」
如果答案是「能」，那問題不在系統，而在於你沒有清楚地描述執行步驟。
發佈留言