OpenWiki:文档写给 agent 看的,也是 agent 写的

7 月 2 日前后,LangChain 在 GitHub 悄悄推了一个新仓库 langchain-ai/openwiki,定位只有一句话——“built specifically for agents”。一个 npm 命令、一个 GitHub Action、一个把文档写进 openwiki/ 的工作流,把”代码库文档”这条产品线从「人写给人读」直接推到「agent 写、agent 维护、agent 参考」。

@ yibie 7-2 首发中文解读时,这个仓库还只有 477 star;到 7-4 早报截稿时,star 已经涨到约 1.8k、143 fork、24 open issue、23 open PR、53 commits(WebFetch 实测,主语言 TypeScript 54.6% / JavaScript 45.4%,MIT 协议)——三天放大约 3.7 倍。这不是普通”又一个开源工具”的热度曲线,这是「agent 工业化在文档层成形」的速度。

一行定义:文档的受众切换

OpenWiki 的产品定义极简,一行命令搞定:

npm install -g openwiki
openwiki --init       # 配模型、API key,生成 openwiki/ 文档
openwiki --update     # 基于仓库变更刷新已有 wiki
openwiki -p "..."     # 单次执行后退出(适合 CI/Action)

openwiki 启动时会自动往 AGENTS.md / CLAUDE.md(不存在则创建)追加一段 prompt,告诉 coding agent:先读 openwiki/quickstart.md,再按链接展开架构、工作流、领域概念、运维、集成、测试、源码映射。这是把 wiki 变成 agent 的 RAG 替代品——不再依赖模糊的语义检索,而是显式引导 agent 走分层阅读。

维度	传统文档工具(Mintlify / ReadTheDocs / Docusaurus)	OpenWiki
主要受众	人类开发者	coding agent
触发机制	开发者手写 / 文档站 build	GitHub Action 每天 08:00 UTC 自动 --update --print 开 PR
存储位置	docs/、README.md	专门的 openwiki/ 目录
注入到 agent 上下文的方式	无,需手动配置	自动追加到 AGENTS.md / CLAUDE.md
模型选择	N/A(静态渲染)	OpenRouter / Fireworks / Baseten / OpenAI / Anthropic + GLM 5.2 / Kimi K2.6 / Sonnet 5
License	各异	MIT(LangChain 这次彻底开放)
输出文件格式	MDX / HTML(给浏览器)	Markdown + AGENTS.md / CLAUDE.md 协议(给 LLM 上下文)

关键数字 1:OpenWiki 默认 GitHub Action 跑 OpenRouter + z-ai/glm-5.2,每天 08:00 UTC 一次。这是个细节但有信号意义——LangChain 没有默认锁 Anthropic,而是把模型中立做成默认,GLM 5.2 作为 README 的「TODO: Replace with your preferred inference provider and model」的第一个被点名的示例。这跟 LangChain 历史上偏 Anthropic 的姿态不一样,跟 GLM 5.2 在编程基准上 7 月初的可用度吻合。

一个 CLI、四种模式

把 README 翻完会发现,OpenWiki 的 CLI 表面只有四个动作,但每一种对应一个明确的使用场景:

模式	调用方式	典型场景	退出/停留行为
交互	openwiki / openwiki "..."	本地开发者探索、追问架构细节	CLI 保持打开,可继续发 follow-up
单次	openwiki -p "..." / --print	CI / GitHub Action 无人值守	打印到 stdout 后退出
初始化	openwiki --init	首次安装、配置 provider/key/model	写入 ~/.openwiki/.env 后退出
更新	openwiki --update	仓库有变更、刷新已有 wiki	diff 写入 openwiki/,交互模式继续打开

「CLI 默认保持打开」是容易被忽略但极重要的设计——这是 OpenWiki 跟传统一次性文档生成器(比如老版 Docusaurus build script)的根本差异:开发者可以连续追问「这个 auth flow 怎么改」「retry 机制在哪里实现」「哪段代码对应文档第三节」,agent 在交互窗口里逐条应答。这意味着 OpenWiki 不只是「文档生成器」,它同时是**「agent-onboarding coach」**——新加入项目的 coding agent 在前 30 分钟里跟 OpenWiki 对话就能拉齐上下文,而不必从零爬仓库。

AGENTS.md vs CLAUDE.md:两套协议,一次注入

OpenWiki 同时往两个文件追加 prompt,这不是冗余,而是对接两套编码 agent 协议:

• AGENTS.md 是 agent-neutral 的开放标准,被 Codex CLI、Aider、Goose 等多家 agent 实现共同支持——任何遵守该标准的 agent 在 session 启动时会自动读取;
• CLAUDE.md 是 Anthropic 的私有约定,Claude Code 在每次 session 开始时读取此文件获取上下文。

OpenWiki 同时往两个文件注入「read the OpenWiki quickstart first」的指引,确保开发者无论用哪家 agent(Claude Code / Codex CLI / Aider / Cursor)都能享受到同一份分层阅读引导。这是vendor-neutral 的刻意设计——跟 Mintlify(深度绑定 Next.js + Vercel)/ DeepWiki(深度绑定 Devin 平台)/ Cursor Docs(深度绑定 Cursor IDE)的「单家绑定」路径形成鲜明对比。

OpenWiki 押注的是 AGENTS.md 这一类「agent 文件协议」会变成 agent 时代的 package.json——像 npm 用 package.json 标准化依赖描述一样,未来 coding agent 用 AGENTS.md / CLAUDE.md 标准化「如何理解这个仓库」的第一手信息。这是 agent infra 的「标准件」机会,而不是 SaaS 机会。

一份 YAML,把 LangChain 的产品观写明白了

examples/openwiki-update.yml 是这份工具链最值得读的一份文档。它不长,但每一行都透露产品意图:

on:
  workflow_dispatch:
  schedule:
    - cron: "0 8 * * *"        # 08:00 UTC,注释写「midnight PST」
permissions:
  contents: write
jobs:
  update:
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "22" }
      - run: npm install --global openwiki
      - run: openwiki --update --print
        env:
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
          OPENWIKI_MODEL_ID: z-ai/glm-5.2
          LANGSMITH_API_KEY: ${{ secrets.LANGSMITH_API_KEY }}
          LANGCHAIN_PROJECT: openwiki
          LANGCHAIN_TRACING_V2: "true"
      - uses: peter-evans/create-pull-request@v7
        with:
          add-paths: openwiki
          branch: openwiki/update
          commit-message: "docs: update OpenWiki"

读这一份 YAML 能拆出 LangChain 的三层意图:

1. 「文档 = LLM 制品」流水线化——schedule + create-pull-request 把「agent 改文档」变成 cron 任务,PR 是天然的人类 gate;
2. LangSmith 漏斗的入口——LANGSMITH_PROJECT=openwiki + LANGCHAIN_TRACING_V2="true" 显式把 OpenWiki 的运行轨迹打到 LangSmith 项目名为 openwiki 的空间里,LangChain 拿到了 agent 维护文档这一类工作流的全量 telemetry;
3. 模型中立——Provider 选 OpenRouter 而非 Anthropic 直连,意味着 LangChain 不再把模型绑定到自家供应商偏好,而是承认文档维护任务应该跑在性价比最高的模型上(GLM 5.2 在这一档任务上目前最优)。

关键数字 2:LangSmith 项目名默认就叫 openwiki。这不是偶然——LangChain 把 OpenWiki 的运行 trace 作为一个独立的 LangSmith 项目,等于把 agent 维护文档的整套调用链数据(Latency、Token、模型切换、成功率)全部纳入自己的可观测产品。LangChain 的 LangSmith 付费转化率,很可能从 OpenWiki 这个看似不相关的文档工具里吃到一波。

三月前的预言:Karpathy 的 LLM Knowledge Base

把 OpenWiki 单看是低估了它。把 Karpathy 4-2 那条 2151 万阅读、6 万+ 赞 的「LLM Knowledge Base」长推拿出来对比,这条工具链的概念血统就清楚了。

Karpathy 那条原推把「LLM 维护的 wiki」拆成了五个阶段:

1. Data ingest:raw/ 目录存原始资料(论文、repo、图片),LLM 增量编译成 .md wiki;
2. IDE:Obsidian 作为「frontend」,人几乎不直接编辑 wiki;
3. Q&A:wiki 到了 ~100 篇文章 / ~40 万字规模,LLM agent 直接在上面做复杂问答;
4. Output:输出物是 .md / Marp slide / matplotlib 图,再回灌 wiki;
5. Linting:LLM 自己跑 health check,补缺失、查矛盾、提新选题。

他在推文最后一句话几乎是在点名 OpenWiki 这种产品:“I think there is room here for an incredible new product instead of a hacky collection of scripts.”

4-4 的跟进推更直接,给出四条原则——Explicit / Yours / File over app / BYOAI,字字都是 OpenWiki 的设计依据:

• Explicit:memory artifact 是 wiki,人能 inspect;
• Yours:数据在本地,不在某家 AI 厂商的私有系统里;
• File over app:文件即接口,所有 Unix 工具都能直接 operate;
• BYOAI:可以插任何模型,可以微调让 LLM 把知识内化到权重里。

关键数字 3:Karpathy 原始推文阅读量 2151 万 / 6 万+ 赞。这是 2026 年到目前为止关于「agent 维护文档」这个话题的最高量级公开论述。OpenWiki 不是凭空冒出来的——它是 Karpathy 三个月前点名的「incredible new product」的具体落子,LangChain 只是把脚本集合打成了 npm 命令。

不是孤例:文档品类的代际切换

把视角拉远,OpenWiki 出现在文档品类正在被重新切分的窗口:

工具	主要受众	触发机制	维护成本	协议层 vs SaaS 层
Mintlify	人类开发者	手工写 MDX + 自动 build	中(仍是人类作者)	SaaS 层
DeepWiki(Devin)	人类问答 + Agent 检索	平台托管,人类只读	低,但不可自托管	SaaS 层(深度绑 Devin)
Sourcegraph Cody	IDE 内的 Agent	实时索引,按需检索	中,需 Sourcegraph 后端	SaaS 层(深度绑 Sourcegraph)
Cursor Docs	Cursor 内的 Agent	IDE 内自动索引	低,但绑死 Cursor	SaaS 层(深度绑 Cursor)
OpenWiki	任意 Coding Agent(Claude Code / Codex / Cursor)	仓库自带 + GitHub Action	极低,自托管 MIT	协议层(无人锁定)

OpenWiki 跟这四家的核心差异是解耦——不绑 Sourcegraph 后端、不绑 Cursor IDE、不绑 Devin 平台;它就是「在仓库里多一个 openwiki/ 目录 + 多两个 markdown 文件(AGENTS.md / CLAUDE.md)」。任何 coding agent 看到 AGENTS.md 都会去读 quickstart,这是一种协议层的产品而不是 SaaS 层的产品。

LangChain 产品矩阵:OpenWiki 的战略位置

OpenWiki 在 LangChain 的产品矩阵里不是孤立项目,而是「免费文档层 + LangSmith 付费漏斗」组合的标准化复制:

层	产品	角色	商业模式
模型编排	LangChain / LangGraph	Agent runtime,链与状态管理	OSS + LangSmith 云
可观测	LangSmith	Trace,eval,prompt 管理	SaaS(付费)
文档层	OpenWiki	Agent-owned documentation	OSS(MIT)
SDK	langchain-python / langchain-js	把 LangSmith 嵌入任意技术栈	OSS

OpenWiki 是这套矩阵里唯一 MIT 协议的组件,而它正是 telemetry 喂回 LangSmith 的入口。商业逻辑很清晰:免费文档层驱动采用率(MIT 意味着任何团队都能装),可观测层捕获付费转化(LangSmith 项目 = 付费 SKU)。这跟 GitHub 用 Actions+Codespaces、Datadog 用 OpenTelemetry、MongoDB 用 Community Server→Atlas 的「OSS 当漏斗、SaaS 当变现」打法同型——LangChain 现在正在把同一剧本搬到 agent infra 领域。

关键数字 4:License = MIT + 0 个 SaaS 依赖 + 0 个 IDE 锁定。这三点同时成立,在 2026 年的 agent 工具里相当稀有。LangChain 这次不是在做 SaaS 转化漏斗,而是在做 agent infra 的标准件——赌的是「OpenWiki 文档协议」成为 coding agent 的事实标准。

隐患:agent 拿自己编的旧解释继续干活

@ UncleJAI 在 yibie 推下的回复,把这条工具链的最大软肋说清楚了:

“我喜欢 agent 自维护文档这个方向,但也怕它越写越顺。文档不是写出来就完了,得有 diff、来源、过期时间和人类确认,不然 agent 以后会拿自己编的旧解释继续干活。”

这条警告不无道理。看 OpenWiki 当前实现:

• --update --print 是单向写入,文档结构上没有 last_verified / source_lines / expires_at 字段;
• README 没承诺 wiki 跟代码的「事件溯源」关系,只是「基于仓库变更刷新」;
• 唯一的人类 gate 是 GitHub Action 模式下的 PR review,但如果用户绕过 Action 直接 openwiki -p 落本地,审核环节完全消失;
• 没有「wiki 自检」机制——Karpathy 推文里的 Linting 步骤,在 OpenWiki 里还没有对应命令。

关键数字 5:目前 24 open issue / 23 open PR 中,大概率会有 staleness / diff / source / expiry 相关的 proposal 出现。这是 OpenWiki 0.x → 1.0 必经的工程债务——「让 agent 写」已经解决,「让人类 gate agent 写的文档」还是空白。

早报观点

OpenWiki 真正有意思的不是「能自动写文档」——Mintlify + 任何 LLM API 早就能做。它有意思的是LangChain 把「文档 = agent 制品」这件事从概念(3 月 Karpathy 长推)→ 协议(AGENTS.md 注入规范)→ 工程(npm + Action)→ 商业(LangSmith 漏斗)四件套在 90 天内拼齐了。这是一个完整的「infra 标准件 + 商业转化漏斗」组合拳——LangSmith 的 LangChain 项目名 openwiki 这一行 YAML,是这条商业逻辑里最值钱的一行。

但更深层的判断:OpenWiki 把「文档层」正式纳入了 agent infra 范畴,这是 2026 年中 AI 工程化的一个明显拐点。之前我们说 agent infra,默认是模型 / 编排 / 工具调用 / 记忆,可观测。现在文档作为「agent 的长期记忆 + RAG 替代品」被产品化,意味着任何想做 coding agent 的团队,都不可避免地要在「文档生成 + 文档版本化」上押注。Mintlify、DeepWiki、Cursor Docs 这些”为人类服务”的文档产品,如果不快速转身做”agent 优先”版本,会在 2026 年底被 OpenWiki 这种轻量协议型工具稀释掉品类心智。

反面 caveat:OpenWiki 的设计哲学有一个未被验证的隐含假设——agent 维护的文档会比人类写的更准。这一点 Karpathy 自己也只敢说”在 ~100 篇 / ~40 万字规模下还行”,超出这个规模后 wiki 自身的健康度(linting、矛盾检测、新选题提议)会不会崩塌,OpenWiki 还没给出答案。如果一个 5000 万行代码库的 openwiki 在 6 个月后变成 agent 互相复读的幻觉池,这条工具链的「文档债」会比传统文档更危险——因为没有人类写者的经验直觉来兜底。

对从业者的实际含义:如果你在做 coding agent,把 OpenWiki 的 openwiki/ + AGENTS.md 协议抄进自己的工具链几乎是零成本的正向收益;如果你在做企业内 Agent 试点,把 OpenWiki 接进 GitHub Action 跑一周就能拿到「agent 维护文档 vs 人类维护」的可量化对照数据——这是 2026 年下半年最值得跑的一个 PoC。

接下来看什么

• 7-11(一周内):OpenWiki star 能否突破 5k,issue 能否突破 50。这是「agent 工业化在文档层成形」的最直观指标。
• 7 月底前:LangChain 是否放出 LangSmith Trace Explorer 中 openwiki 项目的首批聚合数据——agent 读 wiki vs 直接读代码的命中率、token 消耗、维护成功率。这批数据将是 OpenWiki 商业逻辑的硬验证。
• v0.2 发布:OpenWiki 是否引入 last_verified / source_lines / expires_at 字段,把 UncleJAI 提出的 staleness 风险降到结构化可处理。
• 第一批企业 PoC 报告:哪些公司把 OpenWiki 接进了主仓,PR review 流程如何配置。这会决定 OpenWiki 在企业内是「默认 review 后合入」还是「合入后再补人类 review」,后者就是 UncleJAI 警告的故障模式。
• 8 月前:Mintlify / DeepWiki / Sourcegraph Cody 是否推出对位的「agent 优先」文档产品。如果它们选择接入 OpenWiki 协议,意味着 OpenWiki 已经赢下标准件之争;如果它们选择另起协议,agent 文档标准会进入战国时代。

附录:OpenWiki 仓库 7-4 状态快照

• star:~1.8k(7-2 时 477,三天 ×3.7)
• fork:143
• open issue:24
• open PR:23
• commits:53
• 主语言:TypeScript 54.6% / JavaScript 45.4%
• 协议:MIT
• 依赖:pnpm
• Node 要求:Node.js 20+
• 预置模型:GLM 5.2、Kimi K2.6、Sonnet 5
• Provider:OpenRouter、Fireworks、Baseten、OpenAI、Anthropic
• 仓库自维护文件:AGENTS.md、CLAUDE.md、DEVELOPMENT.md