Next.js 正在为 AI Agent 重新设计自己

Next.js 团队在 2 月 12 日发了一篇博客，标题是"Building Next.js for an agentic future"。文章不长，但信息密度很高 - 它讲的不是某个新功能的发布，而是 Next.js 团队过去一年在"让框架对 AI Agent 友好"这件事上的思考路径和踩过的坑。

作为一个重度依赖 AI 辅助开发的人，这篇文章的每个细节都让我觉得"对，就是这个问题"。以下是我的阅读笔记。

Agent 看不见浏览器

文章开头描述了一个所有用 AI 写前端代码的人都经历过的场景：浏览器里出了个运行时错误，你复制错误信息，粘贴到 AI 编辑器里，然后说"修一下这个 bug"。

问题在于 - Agent 看不见浏览器。运行时错误、客户端警告、渲染后的组件状态，对 Agent 来说都是不存在的。当你说"修一下这个错误"，Agent 甚至不知道你在说哪个错误。

解读：这个问题比看上去更深。我们现在用 AI 写代码的典型流程是：写代码 → 浏览器里看效果 → 发现问题 → 回去跟 Agent 描述问题。中间那个"描述问题"的环节，本质上是人在充当 Agent 和浏览器之间的翻译。Next.js 团队意识到了这一点 - 与其让人当翻译，不如让框架自己把信息递给 Agent。

他们的第一步很小但很聪明：改进了错误页面的复制按钮，让它能捕获结构化的错误数据；然后把浏览器日志转发到终端。这些看起来是小改动，但方向很重要 - 让 Next.js 自身对 Agent 可见。

一个被放弃的实验：Vector

接下来 Next.js 团队做了一个更大胆的尝试 - 在浏览器里直接内置一个 Agent。

这个叫 Vector 的工具类似智能版的 DevTools：你可以在页面上选中一个元素，查看它的源代码，然后直接用自然语言提问或要求修改。它还内置了 Next.js 的最佳实践知识，帮助 Agent 减少"幻觉"。

听起来很酷，但 Next.js 团队最终放弃了它。原因很务实：

Vector 很有用，但它和 Cursor、Claude Code 这样的通用编程 Agent 功能重叠了。大多数开发者已经在所有项目中使用这些工具，不只是 Next.js 项目。

解读：这是一个值得所有框架团队学习的决策。与其从零打造一个自己的 Agent，不如把精力放在让现有的 Agent 更好地理解自己的框架。Vector 的核心价值 - 结构化的可见性和框架专属知识 - 被提取出来，直接融入了 Next.js 本身。

放弃一个投入了大量精力的项目需要勇气，但 Next.js 团队选择了正确的路。

MCP：让 Agent 看到 Next.js 的内部状态

真正的转折点是 MCP（Model Context Protocol）的集成。

在 Next.js v16 发布前后，用户经常遇到一个问题：让 Agent "修复错误"，Agent 会去请求页面的 HTML，然后说"我没看到什么问题"。因为运行时错误、浏览器 JavaScript 错误、异步错误 - 这些都活在浏览器里，不在 HTML 中。页面的路由结构、布局分段、渲染状态 - 这些 Next.js 内部信息对 Agent 完全不可见。

MCP 提供了一个标准化的方式来暴露这些数据。Next.js 的 MCP 服务会把内部状态 - 错误、路由、渲染的 segments - 直接递给 Agent。但光暴露数据还不够，Agent 还需要能发现正在运行的开发服务器并与之通信，于是有了 next-devtools-mcp。

除了实时状态，MCP 还打包了升级指引和缓存组件迁移的提示和工具。这意味着 Agent 不仅能看到"出了什么问题"，还知道"应该怎么修"。

解读：MCP 在这里扮演的角色很关键。它不是 Next.js 独创的协议，而是一个开放标准 - 任何 Agent 都可以通过 MCP 和 Next.js 的开发服务器对话。这比内置一个专属 Agent（比如被放弃的 Vector）要强得多，因为开发者可以继续用自己喜欢的 AI 工具，同时享受框架级别的上下文支持。

核心领悟：像 Agent 一样思考

文章最精华的部分是这段总结：

更深层的教训是把 Agent 当作 Next.js 的一等用户，从他们的视角思考。他们需要什么信息？什么时候需要？他们怎么消费这些信息？

这个思维方式带来了三个具体的改变：

如果 Agent 在开发时读终端输出 - 那就在终端里打印 Server Action 的调用日志，把浏览器错误转发过来。这样 Agent 不需要"看"浏览器，只要读终端就能获得足够的调试信息。

如果 Agent 不了解框架的新概念 - 那就提供一个压缩版的文档索引 agents.md，或者结构化的工作流（Next.js skills）。这比让 Agent 自己去翻文档要高效得多，也能减少因为训练数据过时导致的幻觉。

如果 Agent 需要发现和连接开发环境 - 那就通过 MCP 暴露服务发现能力。

解读：这里有一个很深的洞察。传统的框架设计只考虑两类用户：开发者（写代码的人）和用户（用产品的人）。Next.js 团队在说，现在有第三类用户 - Agent。Agent 的需求和人类开发者不一样：它不需要漂亮的 UI，但需要结构化的数据；它不看浏览器，但读终端和 MCP；它不逛文档网站，但能消费 agents.md。

当你开始为 Agent 设计开发体验时，整个框架的信息架构都需要重新想。

接下来会发生什么

Next.js 团队透露了几个方向：

• 运行 npx @next/codemod 可以为你的项目生成最新的文档索引
• 正在扩展评估套件以覆盖更多 Next.js 16 API，用来衡量"什么信息真正帮助了 Agent"
• 长期目标是把这些能力直接内置到 next dev 里，Agent 自动获得正确的上下文，不需要任何配置

读完之后

这篇文章让我意识到一件事 - "AI 友好"正在成为框架竞争的新维度。

过去框架比的是性能、DX（开发者体验）、生态。现在多了一个：AX（Agent Experience）。哪个框架能让 AI Agent 更好地理解自己的概念、看到自己的运行状态、遵循自己的最佳实践，哪个框架就能在 AI 辅助开发的时代吸引更多用户。

Next.js 团队走过的路径也很有参考价值：先做一个大而全的方案（Vector），发现方向不对，果断放弃，转而做小而准的事情（MCP、agents.md、终端日志）。这种"做减法"的思路在 AI 工具领域特别重要 - 不是给 Agent 越多信息越好，而是在正确的时间给正确的信息。

对于我们这些用 Next.js 的开发者来说，实际的行动很简单：升级到最新版本，配置好 MCP，让你的 AI 搭档获得它应该拥有的上下文。你会发现，调试体验会好很多。