meng shao(@shao__meng)
一个 “构建开发者工具的框架”:Devframe 来自 Anthony Fu 大佬最新发布,就像 Nuxt/Next.js 是构建 Web 应用的框架一样。Devframe 让你把一个 devtoo...
8.5内容质量

TL;DR · AI 摘要
Devframe 是一个跨宿主框架的开发者工具构建框架,支持多种形态部署并兼容 AI Coding Agents。
核心要点
- Devframe 通过 handler-first 模型实现跨宿主框架兼容(Vite/Next.js/SvelteKit 等)
- 适配器层设计类似 unplugin,提供统一接口实现多形态部署
- 安全默认值机制确保 Coding Agents 仅访问显式暴露的 RPC 接口
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Devframe 框架
- 核心设计
- handler-first 模型
- Web 标准/Connect 中间件适配
- 适配器层
- CLI/静态报告/Vite 插件转换
- 用户界面
- 人类可视化界面
- Coding Agents 接口
金句 / Highlights
值得收藏与分享的关键句。
handler-first 模型统一了 Web 标准请求和 Connect 中间件,实现跨宿主框架兼容
Devframe 适配器层与 unplugin 的关系类比:提供跨宿主框架的统一定义接口
安全默认值机制:RPC 函数必须显式暴露给 Coding Agents,MCP 适配器附加 schema 和安全元数据
#Devframe#开发者工具#框架#AI Coding Agents
打开原文meng shao on X: "一个 “构建开发者工具的框架”:Devframe 来自 Anthony Fu 大佬最新发布,就像 Nuxt/Next.js 是构建 Web 应用的框架一样。Devframe 让你把一个 devtool 只定义一次,就能以 Vite 插件、独立 CLI、静态报告、MCP server 等多种形态运行在任何宿主框架里,并同时服务于人类和 AI Coding Agents。这是把他过去多年构建的一整套 DevTools 背后的公共基础设施抽出来、产品化的结果。 Pluggable, Extensible, and Playful DevTools https:… / X
meng shao
@shao__meng
一个 “构建开发者工具的框架”:Devframe 来自 Anthony Fu 大佬最新发布,就像 Nuxt/Next.js 是构建 Web 应用的框架一样。Devframe 让你把一个 devtool 只定义一次,就能以 Vite 插件、独立 CLI、静态报告、MCP server 等多种形态运行在任何宿主框架里,并同时服务于人类和 AI Coding Agents。这是把他过去多年构建的一整套 DevTools 背后的公共基础设施抽出来、产品化的结果。 Pluggable, Extensible, and Playful DevTools
devfra.me/posts/pluggabl…
核心设计:handler 是工具的边界 Devframe 的可移植性来自一个极简但关键的决策,handler-first 模型(受 Comark Content 启发): · defineDevframe() 定义一个工具:它的 id、能力、RPC 函数、共享状态、SPA、诊断信息、以及面向 Coding Agents 的接口; · initDevframe() 把定义变成实例,产出两个出口:一个 Web 标准的 (Request) => Promise<Response> handler,和一个 Connect 风格的中间件。 handler 背后统一提供 SPA 托管、连接元数据、实时 RPC、认证和可选的 MCP 端点,全部挂在一个命名空间下。这个选择之所以成立,是因为现代生态已经在这条边界上收敛了:Hono 和 Nitro 直接吃 Web 标准请求,Next.js 和 SvelteKit 暴露 route handler,Vite 和 Rsbuild 接受 Connect 中间件。任何满足这两者之一的宿主,都能挂载同一个 devframe,这就是文中说的“几乎全部的可移植性技巧”。 在此之上,适配器只是便利层:createCac(CLI)、createDevServer、createBuild(静态报告)、createMcpServer(stdio 传输的 MCP server)、createPluginFromDevframe(Vite 插件)。一个包可以同时提供多个入口,比如:一个构建检查器可以同时提供独立 CLI(任何项目可用)、CI 中生成静态报告、在 Vite DevTools 里作为 dock 入口出现、还能让 Coding Agents 查询活跃构建,全部基于同一个定义。 一个精准的类比:在适配器层,Devframe 之于 devtools,就像 unplugin 之于打包器插件——unplugin 给了打包插件一个跨 Rollup/webpack/esbuild 的统一接口,Devframe 给了 devtools 一个跨宿主框架的统一定义。 # 为人类和 Agent 而设计 整个发布里最值得认真对待的部分,对两类界面的分工有清醒的论述:可视化擅长探索、总览和对比;Coding Agents 擅长检索聚焦的上下文、与代码库关联、执行多步骤操作。“呈现会变,但事实来源不变。” 具体机制上有几个要点: 1. 安全默认值:RPC 函数默认私有,必须显式暴露给 Coding Agents。MCP 适配器把函数、可读资源和选定的共享状态翻译成接口,并附上描述、schema 和安全元数据,让 Agents 知道何时、如何使用每个能力。 2. json-render 集成(来自 Vercel):UI 用受限组件目录中的可序列化数据来描述,让 Coding Agents 生成的仪表盘保持可预期。这也顺带实现了 node 侧提供的 UI——协议与渲染器无关,各宿主可以用自己的框架渲染同一个视图。 3. 仓库本身就是 agent-native 的:monorepo 里有 skills/devframe 目录和 AGENTS.md/CLAUDE.md,文档站所有页面都提供原始 markdown(还有 llms-full.txt),方便 Coding Agents 直接抓取。 这可能是第一批把 Coding Agents 当作一等公民来设计的开发者工具基础设施。文章还描绘了一个尚未完全实现但方向明确的场景:让 Coding Agents 构建一次性的 devframe(“给我可视化这个应用的网络请求流并标出瓶颈”),用完即弃。
Anthony Fu 🦋 @antfu.me
@antfu7
1h
It's been a while... Introducing Devframe v1.0 🚀 The framework for building DevTools that can run everywhere, for any meta-framework, for both humans and agents. Check out the announcement post and join our Discord 👇
7:53 AM · Sep 16, 2026
·
359
Views
1
4
2