為代理式未來打造 Next.js

2026 年 2 月 12 日，星期四

為代理式未來打造 Next.js

在過去的一年裡，我們致力於提升 Next.js 的代理（Agent）體驗。在此過程中，我們開發並停用了一個瀏覽器內代理，發佈了 MCP 整合，並體會到提升代理支援的真正答案在於：從代理的角度思考。

代理無法看見瀏覽器

去年夏天早些時候，我們在改進 Next.js 開發者工具（devtools）時發現了一個模式。開發者會在瀏覽器中看到錯誤，複製詳細資訊，將其貼到 AI 編輯器中，然後要求代理修復它。

問題在於代理看不見瀏覽器。執行階段錯誤、用戶端警告以及渲染後的組件對它們來說都是不可見的。當使用者說「修復這個錯誤」時，代理並不知道他們指的是哪個錯誤。

我們的第一個反應是更新複製按鈕以擷取結構化的錯誤數據。接著，我們增加了一個將瀏覽器日誌轉發到終端機的功能。雖然這些只是小修小補，但它們指向了一個更大的體悟：我們需要讓 Next.js 本身對代理可見。

實驗瀏覽器內代理

這催生了一個雄心勃勃的想法。如果我們直接在 Next.js 內部構建一個像智慧開發者工具一樣運作的代理會怎樣？

我們開發了一個名為 Vector 的瀏覽器內聊天代理。類似於 react-grab 但與 Next.js 整合，Vector 讓你能在頁面上選擇元素、查看其原始碼，並提示進行更改。它內建了 Next.js 的最佳實踐，以幫助代理避免幻覺。

副標題：Vector 的介面顯示錯誤偵測與建議修復。

Vector 很有用，但它與 Cursor 和 Claude Code 等通用編碼代理的功能重疊。大多數開發者已經在他們所有的項目中使用這些工具，而不僅僅是 Next.js。UI 選擇功能雖然讓精確指定修改目標變得容易，但這並非人們每天都需要的東西。

我們停用了 Vector，但保留了使其發揮作用的核心（結構化可見性和框架特定知識），並決定將這些功能內建到 Next.js 本身。

MCP 讓 Next.js 狀態對代理可見

在 2025 年 10 月 Next.js v16 發佈前後，使用者在利用代理進行除錯時遇到了困難。常見的提示語是「修復錯誤」，要求代理從瀏覽器覆蓋層（overlay）解決問題。但代理請求頁面 HTML 後卻發現沒有任何異常。

執行階段故障、瀏覽器 JavaScript 錯誤和非同步錯誤都存在於瀏覽器中，而非 HTML 裡。渲染後的頁面、佈局分段（layout segments）、路由和其他內部狀態對代理來說都是不可見的。

MCP（模型上下文協定）為我們提供了一種公開這些數據的方法。第一個版本呈現了錯誤、路由和渲染分段等內部狀態，但僅僅公開數據是不夠的。代理還需要發現正在運行的開發伺服器並與之通訊，這促成了 next-devtools-mcp 的誕生。

副標題：Next.js MCP 回應「什麼是 use cache？」並提供文件與上下文。

MCP 還封裝了提示詞和工具，以協助升級和快取組件遷移。如果你想了解更多，有一場關於 MCP 整合的詳細演講。

答案是像代理一樣思考

MCP 證實了 Vector 教給我們的事。代理需要了解 Next.js 正在做什麼，但這只是故事的一部分。更深層的教訓是將代理視為 Next.js 的一等公民使用者，並從它們的角度思考。它們需要什麼資訊？何時需要？它們如何消化這些資訊？

這種思維方式帶來了實際的改變。如果代理在開發過程中讀取終端機輸出，那麼記錄 Server Action 調用並轉發瀏覽器錯誤就能提供它們所需的線索。如果代理對其訓練數據中未包含的框架概念感到困惑，那麼嵌入壓縮的文件索引 agents.md 或提供結構化工作流（Next.js 技能），能比單純的文件提供更好的上下文。

這些問題貫穿了我們構建的一切。對可見性的需求促成了更好的日誌記錄，對知識的需求促成了 agents.md，而對發現的需求促成了 MCP。當你將代理視為一等公民並在它們所在之處與之交匯時，除錯就變成了程式碼、執行階段與 AI 之間緊密的意見回饋循環。

未來展望

我們現在正致力於降低採用門檻。你已經可以執行 npx @next/codemod 來為你的項目生成最新的文件索引，我們也正在擴展評估套件以涵蓋更多 Next.js 16 API，以便衡量哪些措施真正對代理有幫助。長遠來看，我們希望將此功能內建於 next dev 中，讓代理無需任何設定即可自動獲得正確的上下文。

我們渴望聽到您的回饋和想法，了解如何讓 Next.js 與代理的協作更加出色。