Blume 2.0：零配置文档站框架，从一开始就为 AI Agent 而写
阅读时间: 大约 11 分钟
Blume 2.0：零配置文档站框架，从一开始就为 AI Agent 而写
文档站框架并不新鲜——Docusaurus、Mintlify、Fumadocs、Starlight、Nextra 各有拥趸。Blume 2.0 的差异化不在”又一个框架”，而在它的自我定位：the open-source docs framework for humans and agents（面向人类和 Agent 的开源文档框架）。它主张每个页面都要有两个读者——人看渲染后的网页，AI Agent 看旁侧的 Markdown 孪生体。本文基于其官方站点做一次拆解。
一、出发点：文档正在被两种读者消费
过去文档只服务一种读者——打开浏览器的人。但随着编码 Agent 普及，越来越多的”读文档”其实发生在机器里：Agent 需要搜索、抓取、理解 API 文档来写代码。传统文档站把内容渲染成 HTML，对 Agent 来说要从一堆标记和样式里抠正文，成本高、易错。
Blume 的回应是：让文档站同时对人友好和对 Agent 友好。它的 slogan 是”Fast, AI-ready, and zero-config. Drop Markdown into a folder and ship a production-grade docs site”——把 Markdown 丢进文件夹，零样板代码、零维护，直接产出生产级站点，且永远免费开源。起步命令只有一行：
npx blume init二、Agent-native：一个页面，两个读者
这是 Blume 最核心的设计。官方用一张图说明：同一个文档页 docs.acme.dev/docs/webhooks，人看到的是排版后的标题、正文和代码块；Agent 在 text/markdown 协商下拿到的是同内容的 Markdown 源。具体提供了四条机器读取通道：
- llms.txt：一个索引加完整语料
llms-full.txt，每次构建自动重建； - 每个 URL 的 Markdown 孪生体：页面在其
.md路径提供纯 Markdown 版本，在 Vercel/Cloudflare 服务端构建上支持Accept: text/markdown内容协商； - 一个 MCP 服务器：可选开启的工具，让编码 Agent 直接搜索和读取你的文档；
- Agent skills：把 Blume 指向你的 skills，它会发布到 Agent 会去查找的位置。
官方还拿两个独立扫描器的打分做宣传（数据为 2026 年 9 月 20 日口径）：在 Vercel 的 is-agentic.com 上，useblume.dev 取得领先，Mintlify 78/100、Fumadocs 63/100；在 Cloudflare 的 isitagentready.com 上，useblume.dev 同样领先，Mintlify 40/100、Fumadocs 20/100。需要注意的是，这些分数由第三方站点打出，且官方自承”可能已经变化”，属于营销口径而非独立实测。
三、电池包：零配置到底”零”在哪
Blume 强调”batteries included, no plugins to install”，即一个 Markdown 文件夹就是完整项目，不需要 clone starter、不需要和上游同步模板：
- 导航从文件推断：按文件夹结构自动生成侧边栏，无需手写侧边栏配置；
- 搜索、主题、OG 图默认开启：本地搜索在开发和生产都可用；
- 交互式 API 参考：丢进 OpenAPI、AsyncAPI 或 GraphQL spec，自动渲染端点、schema 和可”Try it”的 playground，也可用
scalar()直接接 Scalar UI； - 内置 changelog：每个发布写成一个 Markdown 条目，或直接指向 GitHub Releases，自动聚合到
/changelog时间线，默认带 RSS； - 30+ 无障碍组件：callout、card、steps、tabs、file tree、code group、diff、type table 等，在
.mdx里直接用，无需 import； - Markdown 增强：
:::tip/:::warning指令自动渲染成提示框；package-install代码块自动生成 npm/pnpm/yarn/bun 安装命令标签页；Shiki 在构建期高亮代码；KaTeX 数学公式构建期渲染且无客户端 JS；Mermaid 只在用到的页面加载。
四、内容来源：本地、远程仓库、CMS 混用
一个文件夹就是一个站点，但内容不必只在本地：
- 本地 Markdown/MDX：零配置；
- 远程仓库：
mdxRemote()在构建时从另一个 GitHub 仓库拉 MDX； - Headless CMS：Notion、Sanity、Contentful、Payload、Strapi 通过 API 接入，外加 Obsidian vault；
- 自定义：
custom()适配器接入任何后端。
配置文件 blume.config.ts 里用 content.sources 数组把多个来源并列，本地文件、Notion 数据库、Sanity 查询可以混在一个站点里。
五、CLI 与迁移：连”改文档”都交给 Agent
Blume 的命令行覆盖文档站全生命周期。两个最有特色的命令：
blume audit --codex：官方示例对 128 个页面跑出 9728 项审计、32 个错误、56 个警告，然后把结果（JSON，每条含 check code、message、url、file、line、suggestion）交给 Codex，让 Agent 按建议逐条修 frontmatter 和页面；blume migrate <来源> --codex：从 Mintlify、Fumadocs、Docusaurus、Starlight、Nextra 迁移时，Agent 自动把docs.json转成blume.config.ts、把配置驱动的导航改成文件夹+标签页、把 admonition 改写成 directive、把 Font Awesome 图标映射成 Lucide。用 Claude Code 就把--codex换成--claude。
也就是说，Blume 不只把文档”写出来”给 Agent 读，还把”审计和迁移文档”这件事本身也设计成了 Agent 可执行的工作流。
六、客观分析：优势与边界
优势：
- 真零配置起步：文件夹即项目，导航/搜索/主题/OG 图默认全开，省去模板同步负担；
- Agent 友好是架构级而非补丁：llms.txt、Markdown 孪生体、MCP、内容协商四件套，是从路由层设计的，不是事后加的 meta 标签；
- 内容来源灵活：本地、GitHub 远程、Notion/Sanity 等 CMS 可混用，不绑死一种写作位置；
- 迁移路径现成：五大主流框架都有带 Agent 的迁移命令，降低切换成本。
边界与存疑：
- 打分是营销口径：两个扫描器的高分由 Blume 自己引用且标注”可能已变”，实际 agent 友好度需自己用喜欢的 Agent 实测；
- 年轻项目：2.0 仍在快速迭代，生态、主题定制深度、插件机制未必比得上 Docusaurus 这种老牌；
- 零配置的另一面是控制力：当默认满足不了时，自定义主题/布局的灵活性如何，需要读文档验证；
- 构建与部署绑定：
text/markdown内容协商官方提到 Vercel/Cloudflare 服务端构建，纯静态托管（如 GitHub Pages）上部分能力可能打折； - “Agent 修文档”依赖外部模型：audit —codex / migrate —claude 的效果取决于你本地的 Agent 能力，不是 Blume 自己保证的。
七、谁该关注
- 正在为开源项目或 SaaS 产品搭文档站，且讨厌维护侧边栏配置的人；
- 希望自己的文档能被编码 Agent 准确抓取、减少”Agent 瞎猜 API”的团队；
- 已有 Mintlify/Fumadocs/Docusaurus 文档、想零成本迁一次的人。
如果你的文档需求非常简单（几个静态页面），Astro Starlight 之类也够用；但当你开始在意”Agent 能不能正确读我的文档""能不能丢个文件夹就上线”时，Blume 2.0 是这一波 agent-native 文档框架里值得跟踪的代表。