Chainguard 推出 MCP Server，让 AI 代理读取系统手册页

2026年11月3日 所有文章 这是一个男人的、男人的、男人的世界：Chainguard OS 中的每一页手册，现在都能被你的 agent 读取 Dustin Kirkland 2008 年，我还是 Canonical Ubuntu Server 团队的一名新工程师，我的起步项目是 Ubuntu Manpage Repository：一个把 Ubuntu 中所有手册页渲染为静态、可搜索 HTML 的网站。它至今仍然在线，地址是 manpages.ubuntu.com。 那个网站是为搜索引擎优化时代而建的。我们设想的读者，是往搜索框里敲问题的开发者，目标是让答案落在某个 Ubuntu 手册页上。它奏效了。它对 Ubuntu 给人的可访问性、易用性和开发者友好度产生了巨大且可衡量的影响——因为你所运行的东西，其文档只差一次搜索，而不是埋在你没安装的某个包里。 所以，我思考网络上的手册页这件事，已经快 20 年了。而读者已经变了。今天，一个拿着搜索框的人，是最不可能去文档里找答案的。更可能的是一个 agent——在你的编辑器或终端里，代表你工作——它需要那个网站曾给人的东西，但要以机器可用的形式。 James Brown 告诉我们，这是一个男人的、男人的、男人的世界。二十年过去，依然如此。只不过现在，读者是 agent。 这就是我们构建 man.cgr.dev 的原因。它把 Chainguard OS 中的每一页手册都渲染成 HTML，这在你意料之中。它还有每一页的原始 roff 源码和 Markdown 版本。更重要的是，它带有一个 MCP server，因此同一份文档可以被机器读取，并能在你自己的 AI 开发环境中、由你的 agent 进行搜索。 man.cgr.dev 发布了 Chainguard OS 中的每一页手册——来自我们全部三个软件包仓库的 1,286 个包、共 59,419 份文档（且还在增加），每晚从真正构成该发行版的已签名 apk 重新构建。 短地址 man.cgr.dev/man/bash.1 会带你到当前页面。每个页面还都有一个永久地址，从那里你可以通过四种方式访问它： JSON manifest——包含包名、版本、内容摘要 把版本替换为 latest 即可跟随当前发布，或者固定版本，明年得到同样的答案。 交叉引用是有效的。git-commit(1) 提到 git-add(1)，那处提及就是一个可点击的链接。链接是依据语料库本身解析的，而不是在构建页面时猜测，91% 的引用都指向了真实页面。一页手册引用了另外 12 页却一个都不链接，那就是死胡同，而网络在 1993 年就解决了这个问题。 以下是它与 manpages.ubuntu.com、以及 Debian 同样出色的对应物不同的地方：它是为 agent 优先构建的。 在 man.cgr.dev/mcp 有一个 MCP server，提供五个工具： search_docs 在整个语料库中查找页面 get_man_page 获取某一页，精确到版本 resolve_xref 像人一样解析一个交叉引用 list_package_docs 某个包记录的所有文档 get_package_info 某个包的哪些版本有文档 把 Claude，或任何其他支持 MCP 的东西指向它，模型就不再猜测参数了。随便问哪个助手：“这个工具的 --exclude 是做什么的？”，你得到的答案来自可能已经过时两年的训练数据，对应的是你并未运行的版本，而且没有任何信号告诉你这是哪个版本。更糟的是，助手越来越多地运行在极简容器镜像内。而恰恰是这些环境，文档被有意留在了外面，因为手册页位于 -doc 子包中，没人会把它们装进生产环境。 所以 agent 恰恰是在没有手册的地方工作。man.cgr.dev 把准确的答案——对应镜像所附带的精确版本——放在一次查询之外。 互联网上的大多数文档描述的是某个版本的软件。我们的文档描述的就是那个版本，因为每一份文档都提取自一个特定的已签名 apk，包名和版本记录在每一页和每一个 JSON manifest 中。 文档只有一条途径进入语料库：作为一个 apk，在任何解析之前先对照已签名的 APKINDEX 校验。没有上传 API，没有爬虫，没有手工整理的内容。如果某个页面在网站上，它出自我们构建并签名的包。 精确性必须在两个方向上都成立。当包新增一个页面时，把页面加进来很容易。更难的情况是，当包不再附带某个页面时。一次没有手册页的构建没有任何东西可供摄取，所以朴素的流水线根本不会注意到，并继续把旧页面当作当前页面提供。我们的流水线会注意到。当一次构建丢弃了某个页面，latest 就不再提供它，而旧版本在其固定地址上仍然可读——因为你们中有些人还在运行它。 “每一页手册”是一个既关于打包、也关于网站的承诺。手册页应当放在 -doc 子包中。当一个包把它们放在别处时，它们要么从网站上缺失，要么在整个网站上重复。所以我们梳理了整个发行版并修正了打包：超过 150 个配方现在正确地拆分它们的文档。这包括从 14 到 23 的每个 LLVM 流的 clang(1)，以及 Rust 工具链。我们还移除了被混入无关包中的手册页副本。 然后我们确保它保持修好。现在每次包定义的改动都会运行一个 lint，因此一个被正确拆分的包不会悄悄回退。我们还修复了 melange——我们的包构建工具——中的手册页检测，使得构建本身就能标记出放错位置的手册页。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）