問題不在模型，而在你只給了它一半的事實
你的 coding agent 打開了整個 repository，看得到失敗的測試、commit 歷史，還有你貼上的 stack trace。它還是會給你一個聽起來很對、實際錯掉的修法。
Firecrawl 的 Hiba Fathima 在 2026 年 9 月 6 日的文章裡把原因講得很直白：你問的是「某台伺服器上發生了什麼」，卻只給了它筆電裡的檔案。錯誤發生在某個特定使用者、某個特定 release，而底層某個 library 在十一天前發了壞掉的更新。這些都不在 repo 裡。
她的結論不是換一個更強的 agent，而是把你手上那個接上更多資訊。
Agent 看不到的三件事，各自對應一種錯誤答案
第一，它看不到伺服器上實際發生什麼：哪個 release 在跑、多少使用者中招、錯誤多常出現、當下系統其他部分在做什麼。少了這塊，它會去修「一般情況下最常見」的 bug，而不是你真正遇到的那個。
第二，它看不到 repo 以外的世界。有些最貴的 incident，是你的程式碼完全沒問題，只是下面某個 library 變了。討論發生在別人的 GitHub issue 裡。
第三，它看不到自己的修法有沒有效。如果 agent 從來沒跑過這個 app，它分不出真正的修復和看起來合理的編輯——兩種情況它都會跟你說修好了。
Fathima 建議照順序補：先看伺服器上發生什麼，這決定你在追哪隻 bug；再看外部世界，因為這一步可能在動任何程式碼之前就結束調查；最後才進自己的程式碼。
接上 Sentry 與 Datadog 的實際做法
Sentry 代管 MCP server，不用安裝，一行指令就能讓 Claude Code 知道它：
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp如果你只查一個服務，就把範圍指到單一 project，減少雜訊，也避免 agent 逛到不相關的資料。
Datadog 的 MCP server 補上另一半：logs、metrics、traces。安裝 plugin 後跑 /ddsetup 選區域並登入。Fathima 特別提醒一個多數人會跳過的步驟：Datadog 的工具按產品線分組，可以用 /ddtoolsets 開關，也可以在連線 URL 裡指定。把沒用到的全部關掉——一個能存取整個 Datadog 的 agent，會在你修 null pointer 的時候跑去翻 dashboard，白白吃掉它有限的工作記憶。
安全模型值得記住：Datadog 的 server 會把已驗證使用者的憑證轉發給 Datadog API，也就是 agent 以你的身分登入，看到的就是你看到的，不多不少。要改東西（例如編輯 monitor）需要另外授權的權限。文中提到截至 2026 年 9 月的限制是每 10 秒 50 個請求、每月 100,000 次 tool call，且不支援政府雲站點。
讓 agent 自己證明修好了
不會跑 app 的 agent，分不出能用的修復和看起來合理的編輯。Devin 的做法是把驗證拆成三步：讀 PR 與程式碼、找出專案專屬指示；挑出「最能證明功能可用的那一條 end-to-end 流程」並先給你看計畫；然後開螢幕錄影、點過整個 app，把關鍵時刻標出來。
回來的東西是證據，不是一句聲稱：一份帶標註截圖的短報告，加上有章節的完整影片和逐項通過／失敗清單。
指令怎麼寫決定這一切有沒有用。Devin 文件裡的好例子是「test checkout flow: add item to cart, proceed to checkout, fill form, verify order confirmation shows correct total」；壞例子是「test everything」和「make sure the app works」。差別在於：好的那句講出一條路徑，並說出正確結果長什麼樣。
同樣的邏輯可以用在 CSS 這種沒有測試覆蓋的地方。先請 agent 在改動前截圖，用 1280 像素和 375 像素兩種寬度；修完再用同樣兩個寬度截一次，四張圖連同 console 輸出一起附在 PR 上。審查的人比對四張圖，而不是讀一句「已修復」。
這裡有個誠實的限制：這只證明頁面載得起來、流程跑得過，不證明修法寫得好，也不證明下個月還站得住。它殺掉的是「說修好了、其實從沒跑過」這種失敗，不會取代 code review。
當 bug 根本不在你的程式碼裡
最貴的除錯時段，是你在追一隻從來不屬於你的 bug。你的程式碼沒問題，是底層 library 變了，而別人上個月就撞過同一道牆，解釋那件事的討論串躺在 agent 從沒打開過的 repository 裡。
Fathima 指出模型在這裡救不了你，原因很單純：它有固定的訓練截止日，之後才發布的東西它看不到。她的解法是接上一個可搜尋的開發者索引，覆蓋 GitHub issue、PR 與文件，並引用 Firecrawl 自己的數據：正確答案落在前十名的比率是 63%，一般網頁搜尋是 45%。這類「先確認這是不是已知問題」的查詢，和我們在圖片模型比價的陷阱裡談的計價單位問題其實同一種毛病——你以為在比同一件事，其實基準不同。
從哪裡開始
如果你現在只有一個 agent 和一個 repo，先做兩件事就好：把錯誤追蹤接上，讓它自己去看真正爆掉的是什麼；然後要求它在宣告修好之前，跑一次並留下可檢查的證據。其餘的順序，等這兩步變成習慣再說。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。