IDE 能換 coding agent，別把「接得上」當成「做得一樣」
同一個 Android 專案裡，兩個 coding agent 都能接進 IDE，也都交回了修改檔案。只看對話紀錄，很容易覺得它們完成了同一件事。但如果其中一次曾查看建置錯誤和畫面預覽，另一次只改了程式碼，這兩份「完成」就還不能放在一起比較。
這是我會拿來檢查工具的假設情境，不是哪個 agent 的實測結果。Android Studio 的 Bring Your Own Agent 功能已在 Canary 提供預覽，透過 ACP 接入其他 agent；IDE 可以提供專案結構、建置設定，以及建置診斷、Compose Preview、模擬器等 Android 工具。JetBrains Air 也把開放 agent 接入與在 IDE 裡理解、驗證成果列為發展方向。入口變多是好事，只是入口沒有替我們回答：這一次，agent 到底在什麼條件下工作？
先讓任務小到能看出差別
假設小團隊要修一個訂單頁：付款狀態切換後，文字變了，畫面的其他狀態卻沒有跟著更新。比較兩個 agent 時，我會先寫下預期的畫面、要動的範圍，以及最小驗收方式。然後從同一個程式庫版本，各開一份乾淨工作樹，分別交出相同的任務。不要讓第二個 agent 接在第一個尚未驗證的改動後面跑；那樣測到的還有前一份 patch 的影響。
我會留一張很簡單的工作紀錄，分成三欄：「IDE 提供」、「agent 使用」、「人工驗收」。這三欄分開，才不會把工具清單誤寫成工作成果。
第一欄寫當下的條件。這個 Canary 環境能提供哪些專案資訊？建置診斷、畫面預覽與模擬器工具是否可用，相關權限有沒有開？官方列出可提供的能力，不表示我手上的設定全部具備，也不表示另一款 IDE 有一模一樣的工具。
第二欄才看 agent 這次做了什麼：它查了哪些資訊、實際呼叫了哪些工具、在哪一步被權限擋下，最後留下哪些檔案變更與檢查結果。如果預覽工具可用卻沒被使用，先查是任務要求不清楚，還是 agent 略過了它；如果工具根本無法使用，換一個模型也不會憑空補上權限。沒有工具呼叫紀錄，也不能直接推論改動必然無效。
第三欄由人填。打開兩份改動，針對各自的程式庫狀態重跑相關建置或窄範圍測試，必要時看 Compose Preview 或模擬器中的畫面。每項結果寫成「通過」、「失敗」或「未執行」。agent 回覆「已完成」不能代填；但一個小小的 UI 修正，也不必為了做比較而跑遍整個專案的測試。
有了紀錄，才知道該修哪裡
假如一份修改沒有讀到正確的專案脈絡，我會先檢查 IDE 接入與設定。若工具可用、核准也通過，agent 卻跳過必要檢查，下次就把檢查寫進任務條件。若工具確實跑了、畫面仍不對，問題回到程式碼與預期行為；此時增加 agent 名單幫助不大。
這種試跑只能說明團隊這個任務的摩擦在哪裡，不能排出所有 agent 的普遍名次。ACP 讓連接有共同入口，卻沒有保證兩次執行會取得相同權限、使用相同工具，或產生同樣可信的結果。尤其預覽版工具的可用性會隨環境而變，沒跑過的部分就留白，不用想像中的畫面補齊紀錄。
下次想因為「它也接得上 IDE」而換 agent，我會先用一個小任務填完那三欄。若缺的是工作條件，先修接入；若缺的是實際檢查，改派工方式；若檢查失敗，就繼續修程式碼。否則只換了工具，連哪一步沒做完都說不清。