Kiso 是一个开源的静态网站发布引擎，由法国投资公司 Oak Invest 开发。它的核心功能是将 Open Knowledge Format (OKF) 格式的知识库 bundle 转换为可供人类和 AI 代理阅读的静态网站。
企业将越来越需要一个既能被人类理解又能被人工智能代理使用的权威信息源。人类和人工智能代理编写 Markdown 文件，Kiso 则发布一个既能被人类（HTML）理解又能被人工智能代理（Markdown）理解的网站。
Kiso 不引入数据库或其他专有知识库，它创建的是静态网站，因此您可以像我之前在 GitHub Pages 上发布 Google Acme 示例一样，直接将其发布到 GitHub Pages 上：https://oak-invest.github.io/kiso/examples/kb-acme-example/
官方将其定位为 "AI 知识库领域的 Hugo" ——Hugo 是知名的静态网站生成器，而 Kiso 则专门针对 OKF 格式和 AI 消费场景做了优化。
Kiso 遵循三条设计原则：
- 结构化 Markdown：知识以纯 Markdown 文件保存，便于编辑、审阅、对比和 Git 版本管理
- 显式元数据：页面携带足够的上下文信息，可被验证、链接和一致渲染
- AI 友好输出：生成的 HTML 保留指向原始 Markdown 文件的清晰链接，便于 AI 代理追溯内容来源
Kiso：一个投资公司为什么要做一个AI知识库的Hugo！
别再问AI怎么读你的文档了，先问问你的文档人类还读不读得懂！
2026年6月，Google Cloud发布了Open Knowledge Format（OKF）v0.1，一个用Markdown加YAML头信息来组织知识的新格式。同一个月，一家法国投资公司Oak Invest发布了Kiso v0.1.2——一个能把OKF知识包变成静态网站的命令行工具。投资公司做开源发布引擎？这事本身就透着古怪。更怪的是，Kiso的官方介绍里第一句话就扔了个炸弹：“For those who know it, Kiso is essentially the Hugo of AI-oriented knowledge bases.”Hugo——那个Go写的、号称“世界上最快”的静态网站生成器——什么时候成了AI知识库的参照系了？
大家都说把知识喂给AI，但Kiso说先让人类读懂
过去两年，但凡跟“企业知识”沾边的产品，口号高度统一：“让AI读懂你的数据”、“为LLM优化知识检索”、“RAG驱动的智能问答”。Vector Database、Embedding、Chunking——这些词成了新宗教的咒语。所有人的注意力都朝着一个方向：怎么把人类知识转化成AI能消化的格式。
Kiso把这件事翻了过来。
它的三条设计原则，第一条是“结构化Markdown”——知识保存在纯Markdown文件里，便于编辑、审阅、对比和Git版本管理。第二条是“显式元数据”——页面带够上下文，能被验证、链接、一致渲染。这两条跟Hugo、Jekyll、MkDocs这些传统静态网站生成器没什么区别。但第三条来了：“Agent-friendly output”——生成的HTML保留指向原始Markdown文件的清晰链接，AI代理可以追溯内容来源。
注意这个顺序：先保证人类能读、能编、能版本管理，再考虑AI怎么消费。
这不是技术选择，这是立场选择。
OKF是什么——Google Cloud在2026年6月扔出的另一个炸弹
要理解Kiso为什么反常识，得先搞懂OKF。
2026年6月12日，Google Cloud宣布了Open Knowledge Format（OKF）v0.1。官方的说法是：“一个开放的、供应商中立的规范，用Markdown文件加YAML头信息来表示知识，专为AI代理消费设计”。更直白的翻译：以后企业的知识库，就是一摞Markdown文件放进一个文件夹，AI代理可以直接走进去读。
OKF v0.1的规格很简单：一个目录，里面全是Markdown文件，每个文件顶部带一段YAML格式的元数据。就这么简单。没有数据库、没有专有API、没有云厂商锁定。Google Cloud随后更新了Knowledge Catalog，可以直接导入OKF格式供自家AI代理使用。2026年7月，OKF更新到v0.2，加入了“信任信号”——来源证明、生命周期、认证信息等。
Markdown又回来了——不是作为“写文档的格式”，而是作为“AI读知识的格式”。
这个反转有点意思：过去两年，所有人都在把知识切碎、向量化、塞进数据库，然后让AI去检索碎片。OKF的做法是：别切了，把整块知识用Markdown写好，让AI直接读。
Kiso跟Hugo到底差在哪——一个具体到能用手摸出来的区别
官方说Kiso是“AI知识库的Hugo”。这比喻听着顺耳，但差在哪？
Hugo吃Markdown，出HTML。Kiso也吃Markdown（OKF格式的Markdown），也出HTML。表面看是一样的流水线。
但打开Kiso生成的网站，你会在每个页面上看到一个东西：指向原始Markdown文件的链接。Hugo不会给你这个——Hugo生成的HTML是“发布态”，Markdown是“源文件”，两者之间没有超链接。读者看到的是渲染后的网页，想看原始Markdown？自己去GitHub找。
Kiso的做法是：每个HTML页面都保留一条回到原始Markdown的路径。人类读者点一下链接就能看到源文件，AI代理爬这个网站也能顺着链接找到原始内容。
这就是那个“能亲手试出来的操作差异”。
这个差异的后果是什么？你的OKF知识库可以同时做两件事：第一，以静态网站的形式让人浏览；第二，以原始Markdown的形式让AI代理直接消费。同一个源，两个出口，不需要转换。
check和build——两个命令解决一个没人说破的问题
Kiso提供两个命令。
kiso check：检查OKF包里Markdown文件的格式和结构错误。这相当于写作时的语法检查——在你发布之前，先把格式问题揪出来。
kiso build：从OKF包生成静态网站，输出包括原始Markdown文件、生成的HTML页面、llms.txt和sitemap.xml。
就这么两个命令。check负责“写对了没”，build负责“发出去了没”。
这背后藏着一个没人说破的问题：当你的知识库既要给人看又要给AI看的时候，你怎么保证两边看到的是同一个东西？
传统的做法是两套系统——一套CMS给人看，一套向量数据库给AI检索。两套系统各自维护，内容不同步是常态。Kiso的做法是一个OKF包管所有——check保证格式正确，build保证人和AI拿到的是同一份内容的不同呈现。
llms.txt这个输出文件值得单独说一句。这是一个专门给大语言模型看的纯文本摘要文件，放在网站根目录。AI代理访问你的网站时，先读llms.txt就知道这个站里有什么，然后决定要不要深入爬取。这相当于给AI代理做了一个“网站地图plus”。
一家投资公司为什么要做这个——Oak Invest的奇怪逻辑
Oak Invest是一家法国投资公司，2011年由Stéphane Traumat和Juanito Gonçalves创立。这两人之前经营一家叫SCUB的Java开发公司，后来卖掉一半股份成立了Oak Invest。公司定位是“不仅出钱，还出战略支持”的科技投资方。
投资公司做开源项目？还不止一个——Kiso之外还有一个叫Mogami的项目。
逻辑可能是这样的：Oak Invest投的科技公司，迟早要面对“怎么管理知识库”这个问题。与其让每家被投公司各自踩坑，不如自己先做一个开源方案扔出来。Kiso解决的是知识库的“发布”环节——从OKF格式到静态网站。被投公司拿来就能用，不用从零开始造轮子。
另一个角度：Traumat本人就是程序员出身。他在Hacker News上亲自回复过“Kiso到底有什么用”这个问题，原话是：“在我的公司里，有些人在构建供LLM使用的文档（不是所有人），但我希望每个人都能检索到它、阅读它，部分内容还能分享到网上”。
翻译一下：不是所有人都用AI，但所有人都应该能读到知识。
这话听着朴实，但在2026年的语境里其实挺叛逆的。
GitHub Action——把“发布”这件事写进CI/CD
Kiso提供了一个现成的GitHub Action：
yaml
- name: Build with Kiso
uses: oak-invest/kiso/applications/kiso-cli-action@v0.1.4
with:
command: build
source: examples/kb-google-example
destination: website/examples/kb-google-example-latest
每次push代码，自动触发OKF到静态网站的构建，结果可以发布到GitHub Pages或任何静态托管服务。
这没什么稀奇的——Hugo、Jekyll、MkDocs都有类似的动作。但Kiso的Action背后有一个隐含的假设：你的知识库是跟代码放在同一个仓库里的。
OKF包就是一堆Markdown文件，放在Git仓库里跟代码一起版本管理。每次修改知识库，提交PR、Code Review、合并、自动构建、自动部署——跟改代码的流程一模一样。知识库不再是CMS后台里的一团乱麻，而是跟代码一样接受版本控制的“一等公民”。
MCP Server——让AI代理直接读你的OKF包
除了CLI和GitHub Action，Kiso还提供了一个MCP Server。
MCP是Model Context Protocol的缩写——一个让AI应用之间共享上下文的协议。Kiso的MCP Server让兼容MCP的AI应用直接访问OKF包里的结构化知识。
这意味着什么？意味着你的OKF知识库有三种消费方式：人类通过静态网站读、AI代理通过llms.txt和sitemap.xml爬、AI应用通过MCP协议直接调用。
同一个OKF包，三个出口，不需要转换，不需要同步。
2026年6月26日——一个刚满两个月的项目
Kiso的仓库创建于2026年6月，第一个公开发布版本v0.1.2在6月26日放出。截至2026年8月底，项目有12个未关闭的Issue，开发分支持续有代码提交。用Java写的，Apache 2.0许可证。
一个两个月大的项目，谈不上成熟。但它的出现本身就是一个信号：当所有人都在讨论怎么把知识喂给AI的时候，有人在讨论怎么让知识先被人类管好。
一个还没答案的问题
Kiso的GitHub仓库里有一个Google Analytics的示例OKF包。你可以拿它跑一遍kiso build，得到一个完整的静态网站——有导航、有页面、有llms.txt、有sitemap.xml。
但有个问题：如果我的OKF包有500个Markdown文件，Kiso能不能扛住？
2026年7月，有人在AI代理的Stack Overflow上问过这个问题：“在超过500个文件的OKF包上，哪个OKF生态工具真正撑住了——kiso、boone、witscode、okfgen还是okf-builder？”。
答案还没出来。Kiso的定位是“静态网站发布器+格式验证器”，不是搜索引擎也不是知识图谱浏览器。500个文件的边界在哪里，没人测试过。