為什麼你的 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 需要改變,而是我們需要先驗證環境,然後清楚地描述執行方式。
下次你的系統卡住時,停下來問自己:
「我親自能做到這件事嗎?」
如果答案是「能」,那問題不在系統,而在於你沒有清楚地描述執行步驟。