AI agent 空回應不是電腦壞掉：大型任務要拆小，才不會卡死
AI agent 執行大型任務時，有時候不是報錯，而是直接空回應。這篇記錄一次真實踩坑：舊系統研究、印刷知識庫、風險避開策略混在一起後，agent 讀太多、想太多、輸出太重，最後什麼都沒回。
AI agent 最麻煩的失敗，不一定是報錯。
有時候它不會說錯。
不會說失敗。
不會明確告訴你哪裡卡住。
它只是安靜。
畫面看起來像還在跑。
工具可能也有動過。
檔案可能也讀了一些。
但最後沒有正常輸出。
這種狀況，我們稱為：
empty response（空回應）。
對人來說，這很容易誤判。
會以為是電腦壞了。
會以為是網路斷了。
會以為是模型不行。
會以為是系統完全當掉。
但實際上，它常常是任務設計太大、上下文太重、輸出要求太複雜造成的。
事情怎麼發生的？
在整理 SEO7 新系統時，我們曾經讓 AI agent 做一個大型任務：
同時研究舊 SEO 發文系統、印刷知識庫、風險避開策略，然後整合成新系統規劃。
這個任務看起來合理。
因為 SEO7 確實需要理解：
- 舊系統有哪些優點
- 印刷知識庫有哪些內容
- 哪些風險要避開
- 新系統如何規劃
- 哪些東西能保留
- 哪些東西不能復活
但問題是，這些事情不應該一次塞給 AI agent。
因為它會需要同時：
- 找檔案
- 讀舊程式
- 讀資料庫或知識庫
- 分析風險
- 整理架構
- 輸出報告
- 避免敏感資訊
- 遵守語言規則
- 不修改 runtime
- 不誤碰舊系統
這已經不是單一任務。
這是一大包任務。
結果就是：AI agent 卡住了。
空回應不是單純的模型爛
遇到 empty response 時，很容易罵模型不行。
但這樣不完整。
模型穩定性當然可能是原因之一，但實際上還有很多可能因素。
例如：
- 任務一次讀太多檔案
- 上下文太長
- 工具輸出太多
- 要求同時分析太多主題
- 輸出格式太重
- 安全限制太多
- agent 不知道先做哪一件事
- provider（模型服務提供端）回應逾時
- 串流中斷
- reasoning（推理內容）有產生，但 visible response（可見回應）沒有成功輸出
- fallback（備援模型）沒有設定
- 長上下文請求包裝失敗
所以 empty response 不應該只歸因於「電腦壞掉」或「AI 太笨」。
更準確地說，它是：
軟體、API、AI agent 編排與任務切分共同造成的失敗。
最大問題：一個任務裡塞太多東西
AI agent 很怕任務範圍不清楚。
人類看起來是一件事：
「幫我研究舊系統，整理成新系統規劃。」
但對 AI agent 來說，裡面可能包含十幾件事：
- 找舊系統檔案。
- 判斷哪些是 runtime。
- 判斷哪些是歷史資料。
- 找印刷知識庫。
- 分析文章素材。
- 找風險設定。
- 避開密碼與憑證。
- 整理新架構。
- 寫報告。
- 提出 patch。
- 確認不修改正式環境。
- 回報下一步。
如果這些全部放在同一輪，AI agent 很容易讀到一半就失去穩定輸出。
它不是沒有做事。
而是做太多，最後沒有把結果吐出來。
這對使用者來說最痛苦。
因為你不知道它到底做到哪裡。
工具有動，不代表任務成功
AI agent 執行任務時，常常會有工具紀錄。
例如：
- read（讀檔）
- grep（搜尋）
- find（找檔）
- patch（修改）
- shell command（終端機指令）
看到這些工具有動，人會以為任務正在順利進行。
但工具有動，不代表最後有完成。
真正的完成要看：
- 有沒有輸出報告
- 有沒有明確結果
- 有沒有測試
- 有沒有 git 狀態
- 有沒有風險判定
- 有沒有下一步
- 有沒有可追溯紀錄
如果工具跑了一堆，但最後 empty response，那仍然不能算完成。
這也是為什麼後來我們把規則改成：
沒有測試紀錄，不算完成。
沒有可追溯輸出，不算完成。
怎麼避免 empty response？
後來我們找到比較穩的做法：
大型任務拆小。
不要叫 AI agent 一次做完整研究。
要拆成多個小任務。
例如：
第一輪：只找候選路徑
只做：
- 找舊系統可能在哪裡
- 找印刷知識庫可能在哪裡
- 不讀太多內容
- 不寫整合報告
- 不修改檔案
第二輪：只讀少量檔案
只做：
- 讀指定 3 到 5 個檔案
- 摘要重點
- 不做整合
- 不做 patch
第三輪：只產出 partial report（部分報告）
只做：
- 整理目前證據
- 寫一份中間報告
- 標示不確定部分
第四輪：再做整合建議
只在前面資料穩定後，才做架構建議。
這樣每一輪都比較小。
AI agent 比較不會卡死，人也比較容易追蹤。
不要讓 AI agent 一次讀太多舊資料
舊系統資料最危險。
因為裡面可能有：
- 舊密碼
- 舊 token
- 舊 API key
- 舊 WordPress 設定
- 舊 XML-RPC 發布能力
- 舊排程
- 舊 runtime
- 舊測試檔
- 舊錯誤紀錄
- 不該公開的 evidence
如果讓 AI agent 一次大量讀舊資料，很容易把不該帶出來的東西也一起帶出來。
所以後來規則變成：
舊系統只研究，不復活 runtime。
證據擷取要遮蔽敏感資料。
原始 evidence 不得進 repo。
大型舊資料研究要分段。
這些規則不是理論。
是踩過坑後留下來的。
partial report 比完整報告更可靠
很多人會要求 AI：
「給我完整報告。」
但在大型任務中，完整報告反而容易失敗。
因為 AI 要同時處理太多資訊，最後容易空回應或內容不穩。
比較好的方式是：
先要 partial report（部分報告）。
例如：
- 目前找到哪些檔案
- 哪些檔案尚未讀
- 哪些內容有風險
- 哪些結論已確認
- 哪些地方還不確定
- 下一輪應該讀哪裡
partial report 的好處是：
- 比較短
- 比較容易產出
- 比較容易檢查
- 可以中途保存
- 失敗時損失比較小
AI 協作不是每次都要一步到位。
有時候穩定地拆成多步，反而更快。
小企業導入 AI agent 要避免「一口吃太多」
小企業很容易期待 AI agent 一次完成很多事。
例如：
「幫我看整個網站。」
「幫我整理所有舊資料。」
「幫我做完整 SEO 系統。」
「幫我接所有 AI 工具。」
「幫我自動化全部流程。」
這些方向可以做，但不能一次做。
因為 AI agent 不是人類專案經理。
它需要明確範圍。
比較好的任務應該像這樣：
- 只查，不改
- 只讀 3 個檔
- 只產出摘要
- 只新增一個文件
- 只改一個欄位
- 只跑一次 build
- 只回報 git status
- 不 commit
- 不 deploy
這些限制不是降低效率。
是讓 AI agent 更穩。
空回應也要記錄
empty response 不能當作沒發生。
它應該被記錄。
至少要記：
- 什麼任務造成
- 任務範圍有多大
- 讀了哪些檔案
- 有沒有輸出
- 卡在哪一步
- 是否有工具動作
- 是否造成修改
- 是否需要回滾
- 下次如何拆小
這樣 empty response 才能變成治理資料，而不是單純浪費時間。
如果不記錄，下次又會重複犯同樣錯。
這次留下的規則
這次踩坑後，留下幾條規則：
- 大型任務必須拆小。
- 每輪只做一個主題。
- 每輪限制讀檔數。
- 先做 partial report，再做整合報告。
- 不要一次研究舊系統、知識庫、風險策略。
- 不要讓 AI agent 大量讀舊 runtime。
- 原始敏感 evidence 不得保存。
- 每輪都要有測試或狀態紀錄。
- empty response 要記錄為事故。
- 任務失敗不能只怪硬體或模型。
這些規則看起來很瑣碎，但對長期使用 AI agent 很重要。
結語：AI agent 要靠任務設計穩定，不是靠祈禱
AI agent 不會因為我們希望它穩，就自然穩。
它需要好的任務設計。
任務太大，它會卡。
上下文太重，它會慢。
讀檔太多，它會亂。
輸出太長，它可能空回應。
風險邊界不清楚，它可能把不該帶出的東西帶出來。
所以真正成熟的 AI agent 協作，不是一直叫它：
「幫我全部做完。」
而是學會說：
「這一輪只做這一件事。」
大型任務拆小。
每輪留下紀錄。
失敗也要保存原因。
再一步一步往前推。
這樣 AI agent 才能從黑盒，慢慢變成可管理的工作流程。