AI Agent 不聽指令怎麼辦？12 個常見失敗與排錯順序

AI Agent 不聽指令、一直重複同一件事、選錯工具或明明沒完成卻回答「完成」，通常不能只靠把 Prompt 再寫長一點解決。Agent 是一條包含任務、Context、工具、狀態、權限與驗證的執行鏈，其中任何一層出錯，最後看起來都可能像「模型變笨」。

比較有效的排錯方式，是找到第一個開始偏離預期的節點。先確認產品與權限，再縮小任務，接著檢查 Context、Tool Call、State 與完成條件，最後才考慮換模型。

先用這張表判斷問題在哪裡

症狀	最可能先檢查
完全不執行，只回答文字	工具／模式／權限
明明寫了規則還是不照做	Instructions／衝突規則
一直問已經回答過的問題	Context／State
一直重複相同步驟	Loop／Retry／State
選錯工具	Tool description／工具太像
Tool Call 一直報錯	Schema／參數／Permission
做到一半忘記前面	Context／長任務狀態
明明沒完成卻說完成	Definition of Done／Verifier
查到錯誤或過期資料	Source scope／Freshness
修改超出要求	Scope／權限／工作區
每次跑結果差很多	Eval／環境／模型非確定性
昨天正常今天突然變差	版本、系統 Prompt、服務異常

排錯時先找到最接近的一列，不要同時改十個設定。

1. Agent 只回答，但根本沒有執行

最先確認的不是 Prompt，而是目前這個產品入口到底有沒有行動能力。

例如同一個 AI 產品可能同時有：

Chat
Work
Agent
Coding Agent
Deep Research
Browser／Computer Use
Connected Apps

如果目前模式只能回答文字，再精準的指令也不會自己修改檔案、查 Calendar 或建立 WordPress 草稿。

接著檢查：

Tool 是否真的已連接。
帳號是否有權限。
Agent 是否允許使用該工具。
Read 與 Write 是否為不同權限。
是否卡在等待 Approval。

如果工具從未出現在執行紀錄，問題通常發生在工具可用性之前。

2. Agent 明明看到規則，還是不照做

先把「不聽話」改寫成一個可測試的問題。

不要只說：

它沒有照我的意思。

改成：

我要求只能使用官方來源，但結果引用了第三方新聞。

這時才能檢查是哪條指令失效。

常見原因包括：

規則寫得太抽象。
兩條指令互相衝突。
重要限制藏在很長的背景文字裡。
任務後面又給了新的相反要求。
不同層級的系統或專案指令具有更高優先級。

例如：

資料要完整。

與：

只能使用官方來源。

可能產生衝突。

當官方資料不足時，Agent 必須知道哪一條優先。

更清楚的版本是：

只使用官方來源。資料不足時標示「無法確認」，不要為了完整而補入第三方資料。

排錯的核心是把形容詞改成具體動作。

3. Agent 一直問你已經回答過的問題

這通常開始涉及 Context 或 State。

對話紀錄很長，不代表模型一定會在每一步完整利用所有資訊。

尤其長任務可能同時累積：

使用者訊息
系統指令
Tool Result
網頁內容
文件
Agent 中間產物
Memory
歷史錯誤

Anthropic 將這類問題稱為 Context Engineering：Agent 運作時間越長，需要管理的資訊越多，而 Context 本身仍然是有限資源。

先檢查：

關鍵條件是否只在很久以前說過一次。
中間有沒有大量 Tool Result 淹沒重要資訊。
Task State 是否只存在聊天紀錄。
Agent 是否真的有持久化 Memory。
舊資料與新資料是否互相矛盾。

對長工作，重要決策最好另外保存成結構化狀態，例如：

目標：
目前進度：
已完成：
尚未完成：
已確認決策：
禁止事項：
下一步：

不要要求 Agent 永遠自己從一萬行對話中重建工作狀態。

4. Agent 一直重複相同步驟

例如：

搜尋
↓
找不到
↓
再搜尋
↓
找不到
↓
換一個相似 Query
↓
再搜尋

這是典型 Loop 問題。

需要加入停止條件，例如：

同一工具最多重試 3 次。
三次搜尋仍無可靠來源就標示未知。
相同錯誤不得使用完全相同參數重試。
達到時間或成本上限後停止。
沒有新證據時交回人類。

Retry 本身不是恢復策略。

如果原因是權限不足，重試 20 次仍然會失敗。

因此應先區分：

暫時失敗 → 可以 Retry

參數錯誤 → 修正後再試

權限不足 → 停止

資料不存在 → 回報

需求不清楚 → 問人

5. Agent 老是選錯工具

如果一個 Agent 同時擁有：

search_customer
find_customer
lookup_customer
get_customer
customer_query

模型選錯並不奇怪。

Anthropic 在 Tool Design 的經驗中指出，Agent 可能選錯工具、正確工具配錯參數、少用工具，或錯誤解讀結果；工具名稱與描述是否清楚，直接影響工具使用品質。

先檢查：

工具名稱是否太相似。
Description 是否只描述功能名稱，沒有使用時機。
Read／Write 是否混在同一個工具。
Tool 數量是否過多。
回傳結果是否塞進大量無關資料。

例如：

customer_manage

不如：

customer_orders_read

與：

customer_refund_preview

更容易判斷。

工具介面本身也是 Agent Prompt 的一部分。

6. 工具明明正確，卻一直 Tool Call 失敗

這時不要換模型。

先讀真正的 Error。

常見問題包括：

Required field 缺失。
Schema 型別錯誤。
日期格式錯誤。
Resource ID 不存在。
Authentication 過期。
Permission 不足。
Rate limit。
Timeout。
Tool 本身服務異常。

一個好的 Tool Error 應該告訴 Agent：

發生什麼錯誤
能不能重試
需要修正哪個欄位
是否要交給使用者

只有：

Error

或：

Something went wrong

很難讓 Agent 自我恢復。

7. 長任務做到後面開始失憶或品質下降

先確認任務是否太大。

Anthropic 在 long-running agent 實驗中觀察到兩個典型失敗：

第一種是 Agent 想一次完成太多工作，最後在 Context 快耗盡時留下半完成狀態。

第二種是後續 Agent 看到已有大量成果，就錯誤認為任務已完成。

解法通常不是「換更長 Context 模型」，而是增加：

Milestone
Checkpoint
階段產物
TODO
Progress state
每階段驗收

例如：

Phase 1：研究
↓
驗收來源

Phase 2：建立資料表
↓
驗收欄位

Phase 3：撰寫
↓
驗收內容

Phase 4：發布前檢查

讓每一階段都能獨立確認。

8. Agent 明明沒完成，卻自己說「完成了」

這是最容易被忽略的問題。

Agent 的文字不能當作任務狀態。

例如 Coding Agent 說：

Bug 已修復。

應該檢查 Tests。

研究 Agent 說：

已完成五家公司研究。

應該檢查五家公司是否都有來源。

WordPress Agent 說：

草稿已建立。

應該重新讀取 Post ID 或 slug。

驗證應放在模型外部：

Agent claim
↓
Environment check
↓
Verifier
↓
Pass / Fail

沒有 Verifier，Agent 很容易把「我已經產生了答案」誤認為「環境中的工作已完成」。

9. Agent 搜到很多資料，但答案還是錯

這時問題可能不是搜尋能力，而是 Source Policy。

先看：

來源允許範圍。
日期是否過期。
搜尋結果是不是二手轉述。
官方來源之間是否版本不一致。
Agent 有沒有把搜尋摘要當成原始資料。
是否把尚未確認資訊寫成事實。

可以直接要求：

claim
source
source date
event date
confidence

重要資料變成 Claim-level 檢查後，比「附三個參考連結」更容易排錯。

10. Agent 改了太多東西

例如只要求修改一個 Button，結果 Agent 重構整頁。

這通常是 Scope 問題。

可以設定：

只修改指定檔案。
只更新指定欄位。
不動 slug。
不修改其他段落。
最大 Diff 範圍。
寫入前先 Preview。
高風險操作要求 Approval。

尤其 Agent 已有 Write Permission 時，最重要的安全措施通常不是「叫它小心」，而是讓它根本碰不到不該修改的範圍。

Anthropic 2026 年談 Agent containment 時也強調：模型層的行為控制是機率性的；filesystem boundary、sandbox、network egress 與最小權限則能直接限制 blast radius。

11. 同一個任務每次跑結果都不一樣

Agent 本來就包含非確定性。

因此不能只用：

昨天這次跑得很好。

判斷品質。

至少建立一小批固定 Case：

正常案例
缺資料案例
錯誤資料案例
工具 Timeout
權限不足
來源衝突
超出 Scope
需要人工確認

每次修改：

Prompt
Model
Tool
Workflow
Context
Permission

都用相同 Case 重跑。

Anthropic 2026 年的 Agent eval 指南也強調，Agent 跨多輪使用工具並改變環境，因此只檢查最後一句回答不足以判定系統品質。

12. 昨天很好用，今天突然變笨

這種情況真的可能不是你的錯覺。

2026 年 4 月，Anthropic 公開說明 Claude Code、Claude Agent SDK 與 Cowork 曾因三項不同產品變更出現品質退化，包括 reasoning effort 調整、session thinking 清理 bug，以及 system prompt 修改；部分使用者感受到健忘、重複或 Coding 品質下降。

因此突然退化時，至少記錄：

日期與時間。
Model。
Product version。
Reasoning／Thinking 設定。
Prompt version。
Tools。
Context。
同一個可重現 Case。

再測：

相同任務
+
相同資料
+
相同設定

如果多次一致退化，再查產品公告、Status、Release Note 或社群 issue。

不要在服務端異常時瘋狂重寫自己的整套工作流。

一套固定的 Agent 排錯順序

如果不知道從哪裡開始，可以固定按照以下順序。

Step 1：先確認環境

確認：

產品入口
Model
Tools
Login
Permission
Quota
Service status

Step 2：把問題縮成一個 Case

不要排：

整個 Agent 不好用。

改成：

使用 A 輸入時，Agent 在第三步選了 B Tool，但預期應該使用 C。

Step 3：找第一個錯誤節點

p class=”wp-block-paragraph”>檢查：

Goal
↓
Context
↓
Decision
↓
Tool
↓
Tool Result
↓
State
↓
Verification

第一個偏離預期的位置，通常才是 Root Cause。

Step 4：一次只改一件事

例如只改：

Tool description。

然後重新跑原 Case。

不要同時：

換模型＋重寫 Prompt＋新增 MCP＋加三個 Agent。

否則即使成功，也不知道是哪一項改動有效。

Step 5：把失敗案例留下來

每次遇到新的真實失敗，都加入 Regression Set。

久了你會得到一套自己的：

Agent failure library

這比收集「神 Prompt」更有長期價值。

什麼時候應該換模型？

把換模型放在排錯流程的後面。

以下問題通常換模型幫助有限：

Permission 不足
Tool schema 錯
Source 過期
Context 污染
沒有 State
沒有完成條件
API Timeout
Product bug

以下狀況才比較值得測更強模型：

長距離推理明顯失敗。
複雜 Tool routing 持續選錯。
多來源整合能力不足。
Code reasoning 不足。
在相同 Harness 下較強模型穩定通過更多 Case。

比較時使用同一批測試。

新手最重要的原則：不要先怪 Prompt

一個 Agent 的輸出來源其實是：

Model
+
Instructions
+
Context
+
Tools
+
State
+
Permissions
+
Environment
+
Verifier

所以「Prompt 寫不好」只是其中一種可能。

當 Agent 出問題時，先找到哪一層開始偏離，再修改那一層，排錯會快很多。

如果需要理解整體架構，可以延伸閱讀 YOLO LAB 的〈AI Agent 是什麼？工具、脈絡、權限、評估與人類介入指南〉；Context 問題可以閱讀〈AI 記憶怎麼分層？Context、任務狀態、RAG 與長期記憶指南〉；Tool 問題則可接〈Agent Tool Contract怎麼設計？Schema、Exit Code、Plan／Apply與冪等〉。

常見問題

AI Agent 為什麼一直重複？

最常見原因包括缺少 State、Retry 沒有限制、工具一直回傳相同失敗，或沒有明確停止條件。先看每一輪是否真的產生新資訊。

AI Agent 為什麼會忘記我前面說的話？

可能是 Context 太長、重要資訊被大量工具結果稀釋、Session 狀態未持久化，或產品本身發生 Context／Session 問題。

Prompt 寫越長越好嗎？

不一定。Prompt 越長，規則衝突與重要要求被淹沒的機會也可能增加。優先保留目標、限制、工具規則、完成條件和例外處理。

Agent 為什麼不用我給它的工具？

先確認工具是否真的被提供給目前 Agent，再檢查名稱、Description、Schema、Permission，以及是否存在功能相近的其他工具。

怎麼知道是模型問題還是系統問題？

固定輸入、Context、Tools、Prompt 和環境後重跑，再比較不同 Model。若所有模型都在相同節點失敗，通常先查系統層。

Agent 怎麼判斷真正完成？

使用外部 Evidence，例如 Test、API State、檔案、Database、Citation 或人工 Acceptance，不使用模型自己的「已完成」作為唯一證據。

資料來源

OpenAI：A practical guide to building agents。
OpenAI Academy：Workspace agents。
Anthropic：Building Effective Agents。
Anthropic：Demystifying evals for AI agents。
Anthropic：Effective context engineering for AI agents。
Anthropic：Writing effective tools for AI agents。
Anthropic：Effective harnesses for long-running agents。
Anthropic：An update on recent Claude Code quality reports，2026 年 4 月 23 日。
Anthropic：How we contain Claude across products，2026 年 5 月 25 日。

AI Agent 的排錯方法和一般軟體其實有一個共同原則：先找到第一個出錯的地方，再修 Root Cause。

最後回答看起來很怪，並不代表最後一個模型輸出才是問題來源。

把「AI Agent 不聽指令怎麼辦？12 個常見失敗與排錯順序」拆成可驗證的系統問題

這篇文章的主題不只是一個名詞或產品名稱，而是一套由資料、流程、資源與限制共同組成的系統。讀完主要敘述後，可以把焦點往前推一步：系統邊界在哪裡、關鍵機制如何運作、指標改善是否伴隨新的成本，以及哪些說法仍需要原始資料核對。

分析面向	要追問什麼	可查找的證據
系統邊界	本文的主題由哪些元件、角色與外部條件共同構成？	架構圖、供應鏈、時間線與官方規格
運作機制	結果是由哪個流程、模型、設計或制度選擇造成？	流程步驟、參數、介面、測試與案例
指標與代價	效率、速度或規模提升後，哪種成本或風險被轉移？	功耗、延遲、可靠性、價格、勞動與環境資料
可驗證性	哪些結論可以重現，哪些仍只是公司說法或推測？	原始文件、版本、第三方測試與反例

用這四個問題閱讀，能把技術敘事從「看起來很強」轉成可比較的證據鏈，也能看見一個系統真正改變的是什麼。

AI Agent 不聽指令怎麼辦？12 個常見失敗與排錯順序