AI Engineer onepage/ Chrome DevTools MCP
Michael Hablich, Google · 22:38
這支影片在講：Agent 工具不是拆越細就越好
Chrome DevTools MCP 的團隊把一個巨大工具拆成 25 個小工具後，發現 agent 仍然會迷路。真正要設計的是 agent 的「決策介面」：它看到什麼摘要、如何理解錯誤、怎麼知道下一步該做什麼。
Published: 2026-06-05Video ID: _B4Pv9ttFgY
01 / 問題
一個工具太粗
第一版只有 debug_webpage。Agent 知道要 debug，卻無法把任務拆成可操作步驟，所以常常安靜失敗。
02 / 反轉
25 個工具也不夠
拆細後，問題變成 agent 不知道該選哪個工具。工具數量增加，沒有自動等於可用性增加。
03 / 解法
改設計決策面
用語意摘要、可自癒錯誤訊息、tokens per successful outcome 與安全摩擦，讓 agent 能選對下一步。
Watch for this
影片最值得抓的四個訊號
Tool shape
1 → 25
從單一 debug 工具拆成 25 個 focused tools，但選擇問題還在。
Trace input
50k lines
Raw JSON trace 對 agent 太吵，應轉成 semantic summaries。
Error design
Self-heal
錯誤訊息要說出失敗條件，讓 agent 能自己換路徑。
Metric
TPSO
用 tokens per successful outcome 看介面效率，而不是只看工具能不能 call。
Core story
Chrome DevTools MCP 做錯的三件事
錯 1
把人類的 DevTools 經驗包成一個大工具
人類可以在 DevTools 裡四處點、切 panel、自己判斷線索；agent 不行。它需要每一步都有明確狀態、下一步選項與可行動資訊。
錯 2
以為拆成 25 個工具就會變好用
小工具解決了「太粗」的問題，卻製造了「選擇」的問題。Agent interface 必須告訴模型何時用哪個工具，而不是只把工具清單丟出去。
錯 3
把完整資料當成有用資料
50,000 行 trace 很完整，但不代表適合模型推理。對 agent 來說，經過壓縮的語意摘要往往比原始 dump 更能推進任務。
Why it matters
這支影片對做 agent 產品的啟發
錯誤訊息是 agent 的下一步提示「Cannot navigate back, no previous page in history」比「Unable to navigate back」更好，因為它直接講出失敗條件。
工具描述要幫 agent 做選擇工具名稱、輸入輸出、適用情境、失敗條件，都應該是 selection hints，而不是只寫給人類看的 API 文件。
評估要看成功成本
tokens per successful outcome 把 token 消耗和任務成功綁在一起，比單看工具 call 次數更接近 production 成本。安全摩擦不是都該移除Autoconnect friction 被保留，是因為 prompt injection 與 lethal trifecta 會讓「自動接上工具」變成安全邊界問題。
Use this checklist
如果你正在做 MCP / agent tooling，先檢查這五點
工具是否太粗，導致 agent 無法拆步驟？如果 agent 只能說「debug」但不知道先查 console、network 還是 navigation state，介面還不夠好。
工具是否太多，卻缺少 selection hints？拆工具後要補足描述、狀態摘要與選擇條件，不然 agent 只是從一種迷路換成另一種迷路。
你給的是 raw data，還是可決策摘要？保留 raw trace 給系統，但給 agent 的輸入要能指出問題、相關線索與下一步。
錯誤訊息能否讓 agent 自己修正？錯誤訊息要說明原因，而不是只說失敗。原因越具體，agent 越有機會 self-heal。
你有沒有量 tokens per successful outcome？好介面不是讓模型多 call 幾個工具，而是用更少 token、更少錯路，完成更多真實任務。
Source video