前端圈选框架向来凭感觉，到了 AI 写代码的年代，口号变成了哪个框架对 Agent 更友好。2026 年 10 月 28 日，Web 开发者 Nolan Lawson 决定拿数据戳破这层窗户纸：他让 Opus 5.5（开启 high effort 模式）在沙盒里用 12 种 JavaScript 框架，各自从头构建 5 次相同的宝可梦（PokéAPI）应用。跑完近 60 次构建后，账单给出了一个反常识的结论——社区声量最高、专门给 AI 配齐了官方辅助插件的框架，不仅没帮程序员省钱，反而烧掉了将近翻倍的 Token。
为了保证测试公平，所有框架均配置了官方推荐的 MCP（Model Context Protocol）服务器或专属 skills，禁用 Tailwind 等 CSS 框架，并统一通过无障碍树规范测试与 Lighthouse 验收。按 Claude Code 统计的单次构建中位数 API 等效成本排座次，最便宜的 Hono+htmx 仅需 $2.67（耗时 8.6 分钟，消耗 4.26M tokens），紧随其后的是 Astro（$2.76）与 Nuxt（$2.82）；主流的 Next.js 居中（$3.14）；而 SvelteKit（$4.28）和 Angular（$4.97）成了最吞金的底座，Angular 甚至在 5 次尝试中直接把应用写挂了 2 次。
| 框架 / 技术栈 | 中位数成本 ($) | 中位数耗时 | 消耗 Tokens (含缓存) | 客户端 JS 体积 |
|---|---|---|---|---|
| Hono+htmx | $2.67 | 8.6 min | 4.26 M | 18 KiB |
| Astro | $2.76 | 8.2 min | 4.13 M | 0 KiB |
| Nuxt | $2.82 | 9.0 min | 3.85 M | 84 KiB |
| Vanilla (Vite) | $2.98 | 10.1 min | 5.00 M | 7 KiB |
| Next.js | $3.14 | 10.9 min | 4.99 M | 142 KiB |
| SvelteKit | $4.28 | 10.8 min | 8.53 M | 36 KiB |
| Angular (5次败2次) | $4.97 | 17.2 min | 9.76 M | 93 KiB |
官方喂饭的 MCP，怎么变成了 Token 税？
各大框架团队这两年最热衷的基建，就是给自家工具写官方 MCP 服务器、AGENTS.md 或专属 skills。逻辑听起来很顺：大模型预训练语料滞后，不懂框架最新版 API，只要把官方文档外挂给 Agent，AI 就能少犯错、少走弯路。
实测结果却狠狠打了这套逻辑的脸。
看一眼 Nuxt 和 SvelteKit 的对照就能明白问题出在哪。测试环境里明明给 Nuxt 装好了官方 MCP，但 Opus 5.5 在 5 次运行中一次都没去调它（调用率 0/5），全凭模型自带的训练记忆写代码，结果 Nuxt 跑出了全场最低的 3.85M tokens 消耗。反观 SvelteKit，Agent 堪称三好学生，5 次运行全勤调用了 Svelte 插件，且每次都老老实实把 SvelteKit v3 迁移指南从头读一遍；由于这批统计包含了缓存读取（cache reads）与输入输出，反复吞吐长篇迁移文档直接把 SvelteKit 的 Token 消耗拉高到了 8.53M，账单比 Nuxt 贵出 51%。
Next.js 的情况同样尴尬：Agent 在 5 次任务里只有 1 次读了 skill 文件、2 次读了 AGENTS.md。至于小众的 Gracile+Lit，因为模型语料库里没存货，Agent 干脆直接去克隆源码仓库或者钻进 node_modules 里硬啃编译后的代码，把单次成本拉到了 $4.65。
喂给 Agent 的拐杖越重，上下文窗口里的税单就越长。
韩非子讲“恃人不如自恃也”，放在大模型工程里同样成立。一个框架如果API频繁做破坏性更新，逼着 AI 每次写代码前先去读几万字的迁移说明和外部 MCP，那它在 Agent 时代的隐性门槛就已经高不可攀了。连完全不给 UI 框架的 Vanilla（原生 JS/TS 配 Vite）都要花掉 $2.98 和 5.00M tokens，比 Astro 和 Hono+htmx 还贵，说明恰当的框架抽象确实能帮 AI 省力；但前提是这套抽象本身足够稳定，不需要靠外挂长文档来打补丁。
- 结论.框架维护者与其堆砌面面俱到的 MCP 文档，不如精简触发机制、保持 API 向后兼容，高信噪比的短指令才配得上按量计费的上下文窗口。
当人类停止叮嘱性能，框架的出厂设置就是用户的命
过去十年，前端工程师喜欢拿“开发者体验（DX）”当挡箭牌。就像当年小家电卖场里导购员猛夸某款榨汁机按键手感顺滑，却绝口不提它耗电量大、拆洗要半小时；前端圈也一度为了写 JSX 时的顺手，把成百上千 KB 的运行时塞进用户的手机浏览器里，再用“虚拟 DOM 很快”的事后合理化话术自我安慰。
到了 Agent 编程时代，程序员连键盘都不怎么敲了，也没人在提示词里特意叮嘱“请把首屏性能优化到极致”。Nolan Lawson 在测试里故意只给功能规范，不规定用 SSR（服务端渲染）还是 CSR（客户端渲染），也不提 Lighthouse 跑分要求。
结果所有框架交出的作业，在 Lighthouse 首页性能（97–100 分）和无障碍（全员 100 分）上看起来一片祥和，但掀开引擎盖看客户端传输的 JavaScript 体积和总阻塞时间（TBT），底牌全露出来了。
当人类不再手写代码，框架的“出厂默认倾向”就直接决定了最终用户的命运。Astro 默认不往浏览器发一丁点多余脚本，客户端 JS 传输量是干干净净的 0 KiB，主线程总阻塞时间（TBT）为 0 ms；Hono+htmx 也只发了 18 KiB。而到了 Next.js，同样一个类似维基百科的宝可梦资料站，AI 顺着框架默认路径写出来的应用，直接往客户端砸了 142 KiB 的 JS 脚本，TBT 飙到 71 ms；Angular 的 TBT 更是达到了 103 ms。
这也是为什么 Hono+htmx 和 Astro 能在这次测试里拿下“省钱+高性能”双料冠军。它们的原语足够简单，默认走服务端驱动或多页架构（MPA），AI 不需要处理复杂的客户端状态水合（Hydration），写起来快，跑起来也轻。
不过，要是哪家公司的 CTO 拿着这张表就准备明天把业务全切到 htmx，那也属于另一种盲目。这项基准测试本身有三个明显的方法论边界：
- 测试标的只是一个偏静态的宝可梦图鉴，更接近维基百科而非 Figma 或 Gmail，天然偏袒 Astro 和 htmx 这类多页与轻客户端方案。
- 测试环境里，服务端拉取 PokéAPI 走的是本地
localhost极速通道，而浏览器端请求却被 Lighthouse 加上了移动网络节流限制，而且只测首屏，没测后续的页面内搜索、过滤和路由跳转。 - 账单只算了首次生成那几美元的差价，并且 Angular 失败 2 次所浪费的 Token 并未摊入那 $4.97 的成功均价里；在真实工程中，后续幾十次改需求、修 Bug 的增量维护成本，远比开局省下的两美元重要。
- 风险.切勿拿单一内容型站点的首屏跑分，去指导高交互复杂应用（SPA）的技术选型。
Nolan Lawson 把测试套件开源在 GitHub（nolanlawson/agent-framework-benchmark）的价值，不在于给十二个框架排出一份江湖座次，而在于给盲目吹捧“AI 友好度”的前端圈立了一把尺子。接下来真正值得盯紧的，是哪家框架团队敢用这套开源基准做一次“开启 MCP vs 关闭 MCP”的 A/B 盲测——看看自己耗费心血写的 AI 辅助工具，到底是在帮开发者省时间，还是在帮大模型厂商赚 Token 费。