原文内容

用多个 Agent 协作完成一个 AI Native 开源博客系统

项目案例：Inkwell
开源仓库：https://github.com/Amoswuuuu/Inkwell
项目标语：Readable by humans. Resolvable by machines.

这是我在 2026 年使用 AI Agent 从 0 到 1 实现的一个开源项目。

它叫 Inkwell，一个面向 AI 时代重新设计的开源博客系统。

我给它写的标语是 Readable by humans. Resolvable by machines.

翻译过来就是，人可读，机可解。

因为传统博客主要是给人看的。页面要舒服，文章要好读，目录、代码高亮、暗色模式、评论系统这些体验都很重要。

但到了 Agent 时代开始大量读取网页、总结内容、调用接口、整理知识的阶段，博客只给人看，好像就不太够了。

它还应该能被机器稳定解析，被 Agent 准确引用，被自动化流程持续维护。

所以我做 Inkwell，不是想再写一个普通博客模板。

它更像是在回答一个问题：

当博客进入 AI Native 阶段，内容系统应该长什么样？

我具体做了什么

Inkwell 的目标可以拆成两层。

一层是 给人看的阅读体验。

它使用 Astro 6、TypeScript、Vanilla CSS scoped styles、CSS custom properties，配合 Astro Content Collections 管理内容。

页面体验上，它做了三栏布局、文章详情页、AI summary card、TOC、阅读进度、暗色模式、Zen Mode、KaTeX、Shiki 代码高亮、一键复制、Giscus 评论和图片灯箱。

这些都是很「人类读者」的功能。

另一层是 给机器看的数据结构。

我给 Inkwell 做了 /llms.txt、/api/posts.json、/api/posts/{slug}.json、/api/search.json、/api/status.json、/feed.json、/rss.xml 等机器可读入口，也支持 JSON-LD Article schema。

它还有 inkwell export、AI summaries 写回 frontmatter、基于 Pagefind 的搜索、config.yml 单一配置源、Obsidian workflow、Markdown linter、AI summary generation 和 GitHub Pages deploy workflow。

这两层合在一起，才是这个项目真正有意思的地方。

我的核心判断是，AI Native 不是在页面上贴一个「AI 摘要」就完事了，而是要把 「AI Agent 能不能读懂、能不能稳定使用、能不能参与内容工作流」 放进系统设计里。

多 Agent 协作不是一句口号

这个项目的一个特殊之处是，它不是单靠一次提示词生成出来的。

更准确地说，Inkwell 是我用好几个 Agent，加上不同底座模型，一轮一轮协作做出来的。

但我觉得真正值得分享的，不是具体哪一轮对话怎么写，也不是哪一个模型输出了哪段代码。

真正值得分享的是协作方式。

复杂项目里，AI 最好不要被想象成一个「一口气写完整个系统」的万能角色。

更可行的方式，是把它当成一组可以分工的工程协作者，让不同 Agent 在不同阶段承担不同任务，再由人做产品判断、边界控制和最终验收。

在 Inkwell 这样的项目里，我最后发现任务天然可以拆开。

这里最关键的一点是，人不是从流程里消失了。

恰恰相反，人变得更像主编、产品经理和验收工程师的结合体。

Agent 可以很快给出实现方案，但「这个功能该不该做」「这个接口是不是会长期稳定」「这个页面是不是符合项目气质」「这段文档会不会误导第一次使用的人」，这些判断还是要人来拍板。

一个更接近真实的协作流程

我理解中的多 Agent 工程协作，大概是这样：

flowchart TD
    A[人提出产品方向<br/>AI Native 开源博客系统] --> B[需求拆解 Agent<br/>拆成功能模块与验收点]
    B --> C[架构与数据 Agent<br/>设计内容集合、配置源、API 与机器可读出口]
    B --> D[前端体验 Agent<br/>实现阅读布局、暗色模式、Zen Mode、代码高亮等]
    B --> E[CLI 与自动化 Agent<br/>整理导出、摘要生成、lint、部署工作流]
    C --> F[交叉审查 Agent<br/>检查边界、遗漏和实现风险]
    D --> F
    E --> F
    F --> G[人类验收<br/>产品判断、体验判断、开源可维护性判断]
    G --> H[持续迭代<br/>修复问题、补文档、调整体验]

这里有两个细节，我觉得挺重要。

第一个细节，拆分要按系统边界拆，不要只按文件拆。

如果让一个 Agent 只负责某个文件，它很容易陷入局部最优。比如只看页面组件，可能会把体验做得很花，但忘了这个项目的核心是人可读、机可解。

更好的拆法是按问题域拆：前端体验是一块，API 和数据层是一块，CLI 与自动化是一块，文档和开源上手体验是一块。

第二个细节，不同模型交叉验证很有价值。

不同底座模型的强项不一样。有的更适合快速给实现候选，有的更适合解释架构，有的更适合整理文档，有的更容易发现边界条件。

把同一个问题交给不同模型看一遍，不一定是为了投票，而是为了拿到不同视角。

最后还是人来决定。

这件事听起来有点慢，但真实工程就是这样。不是每个建议都采纳，不是每个补丁都合并，不是每个「看起来很 AI Native」的功能都值得做。

Token Plan 在这里解决的不是一次调用成本

这类项目对 Token 的需求，不只发生在写代码那一刻。

它会发生在需求讨论里，发生在架构反复推敲里，发生在 API 结构设计里，发生在 README 和配置文档的整理里，也发生在一次次看起来很小的修复里。

比如做 Inkwell 这样的系统，我会反复问这些问题：

• /api/posts.json 应该输出哪些字段，才方便 Agent 使用？
• /llms.txt 应该怎样组织，才能让机器快速理解站点结构？
• AI summary 写回 frontmatter，会不会破坏原有写作流？
• config.yml 作为单一配置源，会不会让新用户更容易上手？
• Zen Mode、阅读进度、TOC、代码复制这些功能，是共同服务阅读体验，还是只是功能堆叠？

这些问题都不是一次生成能解决的。

它们更像一组持续的小判断。每次判断可能只花一小段交互，但加起来就是一个真实项目的工程迭代成本。

各家的 Token Plan 对我最大的价值，不是让我敢让 AI 多写几行代码，而是让我敢把 AI 放进完整的软件生产流程里。

需求可以多拆几版。

架构可以多问一个模型。

文档可以多修一轮。

边界条件可以多检查一次。

这些「多一次」在单次调用里看不显眼，但对开源项目质量很关键。

我从这个项目里学到的几件事

1. AI Native 不等于把 AI 功能贴到产品表面

Inkwell 真正 AI Native 的地方，是它把机器可读性做成了数据架构的一部分。

/llms.txt、JSON API、JSON-LD、feed、search、status，这些能力让 Agent 可以更稳定地理解和使用博客内容。

2. 人类体验不能被牺牲

如果一个博客只对机器友好，人读起来很难受，那它就不是一个好博客。

Inkwell 同时做了三栏布局、暗色模式、Zen Mode、TOC、阅读进度、KaTeX、Shiki 代码高亮、Giscus 和图片灯箱，说明它没有把「给 Agent 看」当成放弃人类体验的理由。

3. 多 Agent 协作的核心不是数量，而是分工

开很多窗口、问很多模型，本身没有意义。

真正有意义的是让它们围绕不同问题域工作，然后用交叉验证降低盲区。

4. 人的角色会更重要

AI 可以承担大量执行工作，但项目的品味、边界、取舍、验收，还是要人负责。

尤其是开源项目，最终别人看到的是仓库、文档、接口和体验，不是背后某一次对话有多精彩。

5. 不要神化一次性生成

Inkwell 更像是一个持续迭代出来的项目。

需求拆解、架构设计、前端体验、API/数据层、CLI/自动化、文档整理、缺陷修复和多模型交叉验证，每一步都可以有 AI 参与，但每一步都需要人来收束。

如果重新做一遍

我会继续沿用这种方式。

先让一个 Agent 帮我把产品目标拆成可验收模块，再让另一个 Agent 从架构角度挑问题。

把前端体验和机器可读接口分开推进，因为这两个方向的评判标准完全不同。

让一个模型负责实现候选，再让另一个模型做审查，尤其检查接口字段、构建流程、文档是否自洽。

最后保留一个很笨但很有效的动作：

自己跑起来，自己读一篇文章，自己打开 API 看返回，自己从新用户视角读 README。

因为最终用户不会在意这个项目用了几个 Agent。

用户只会在意它好不好用。

而成长营给我的启发正是在这里。

Token 不是为了让 AI 替我完成一个炫技动作，而是让我可以把 AI 当作稳定的工程协作资源，在一个真实项目里反复调用、比较、修正、验收。

这个项目让我更确定一件事：

AI Native 的开源项目，不该只是「AI 生成的项目」。

它应该是一个人和多个 Agent 一起工作之后，仍然能被人读懂、被机器解析、被后来者维护的项目。

这可能才是「人可读，机可解」真正有价值的地方。

也欢迎大家直接用

最后打个广告。

如果你也想做一个自己的博客，或者想试试 AI Native 内容系统 到底应该怎么设计，可以直接去看 Inkwell：

https://github.com/Amoswuuuu/Inkwell

它不是一个只能看截图的玩具项目，而是一个可以实际 fork、配置、写文章、部署的开源项目。

你可以用它写普通博客、做实验室主页、项目简介甚至其他你能想到的网站，也可以把它当成一个实验场，看看一个同时面向人和 Agent 的内容系统应该长什么样。

我会继续把它往前推。

也欢迎大家提 Issue、提 PR，或者直接拿去魔改。