帮助中心如何被外部 AI 助手读到：MCP、llms.txt 与权限边界
帮助中心的「对外 AI 入口」，是把已发布（并受权限约束）的帮助文章，以 MCP 服务器或 llms.txt 等机器可读接口提供给 ChatGPT、Claude、Cursor 等外部助手检索和引用，而不是只在帮助站点内部做对话式搜索。本文对照 Document360、Mintlify 与 GitBook 在 2026 年已公开的机制，区分读者侧检索 MCP、管理侧写入 MCP，以及 llms.txt / Markdown 镜像，并说明隐藏页、鉴权与反馈回流的边界。读完可以判断该开放哪一类入口、权限应跟谁走，以及它与站内语义搜索、答案引擎优化的分工。
浏览 5
巴克励步
导语：帮助中心不只给人点开，还要被外部助手调用
帮助中心的对外 AI 入口，是把已经发布、并受权限约束的帮助文章，以机器可读的方式提供给 ChatGPT、Claude、Cursor 等外部 AI 助手去检索、引用，有时还包括起草和发布；它要回答的不是「要不要再做一个站内聊天框」，而是：当读者或内部人员待在自己常用的助手里时，你的帮助内容怎样被找到、以什么身份被读取，以及不该被读到的页面会不会漏出去。
这和已有几篇支柱、簇内文正好接上。语义搜索和对话式帮助中心处理的是读者进入你的站点或 Widget 之后，如何命中可核验答案；SEO / AEO处理的是搜索引擎和答案引擎如何发现公开文档；外部知识源处理的是把别的系统同步进帮助中心。本文看的是相反方向：帮助中心如何作为一份可被外部助手连接的知识源走出去。
Model Context Protocol（MCP） 是一套开放协议，用来把 AI 应用连到外部系统、工具和工作流，官方用「AI 应用的 USB-C」来形容它：先实现一次标准接口，再接到多种助手上。与此并行，llms.txt 则是一份放在站点路径下的 Markdown 索引，告诉智能体这个站点有哪些适合阅读的页面，并通常配合各页的
.md 镜像。2026 年，文档和知识库产品已经不只是「支持一下协议」，而是把这两类入口写进正式功能：Document360 提供面向知识库的 MCP 服务器（文档页标注更新于 2026 年 11 月 13 日）；Mintlify 为每个站点托管检索用 MCP，并另有写入用的管理端 MCP；GitBook 则让每个已发布文档站自动带上 MCP 服务器，同时自动生成 llms.txt 与 Markdown 页面。对帮助中心团队，这改变的是分发面，而不是「又多了一个聊天机器人」。过去，对客口径主要出现在门户、嵌入组件和工单台；现在还可能出现在员工的 IDE、客户自己的 ChatGPT，以及会主动抓取
llms.txt 的智能体里。如果公开索引、按人鉴权的检索，和带发布权的写作接口被当成同一件事打开，漏出去的就不再只是「多了一个搜索入口」，而是草稿、隐藏页或内部说明被写进别人的对话。先分清三条通道：索引文件、读者 MCP、写作 MCP
对外 AI 入口看起来都叫「让 AI 读文档」，机制却不是同一层。先按谁来连、能做什么、凭证跟谁走分成三条，后面的产品对照才有意义。
第一条是 llms.txt 与页面的 Markdown 镜像。Jeremy Howard 提出的 llms.txt 方案在 2026 年 8 月 10 日更新到 v2：在站点根路径或某个子路径放置一份 Markdown 文件，用标题、摘要和分类链接，指引智能体去取适合模型阅读的内容；同时建议为需要被引用的页面提供同 URL 的
.md 版本，并用 rel="alternate"、rel="describedby" 等链接关系帮助发现。它的定位是「按需查阅的导览」，不是 sitemap 的替代品，也不等于访问控制。优点是实现轻、适合公开文档被广泛发现；限度也很清楚：文件本身通常没有会话级鉴权，一份写得过全的索引或 llms-full.txt，可能把你只想从目录里拿掉、并不想公开分发的页面一并列出。第二条是 读者侧（检索）MCP。助手在对话过程中调用搜索、读取正文、有时还能提交「这页写错了」之类的反馈，但默认不应改你的文稿。Mintlify 把它写成站点域名下的
/mcp（需要登录的内容则走 /authed/mcp），并提供搜索、按虚拟文件系统读取页面，以及把问题写回分析后台的反馈工具。GitBook 把服务器放在 {文档站 URL}/~gitbook/mcp，强调只读、只暴露已发布内容。这条通道的目标读者，往往是正在写代码或排障的终端用户：他们不必打开你的帮助站点，也能在自己的助手里引用现行文档。第三条是 管理侧（写作）MCP。它连的是编辑后台，而不是对客站点。Document360 的 MCP 在检索之外，还包括创建和更新文章与分类、把内容推过审核工作流、发布或取消发布，以及维护术语表、审阅提醒和任务。Mintlify 的管理端 MCP 托管在
https://mcp.mintlify.com，用来改页面、调整导航和设置，并打开拉取请求或发布变更。2026 年 10 月 19 日，Mintlify 在 Improved Admin MCP 中宣布：代理可以留下评论和建议，小修复可以直接发布到主分支，而不必再为每一次修改等待合并拉取请求。对内容团队，这意味着助手能缩短「从发现过时段落到提交修改」的路径，也意味着发布权一旦授予，治理必须跟上去。三条通道可以同时存在，但不要共用一套权限假设。公开的
llms.txt 面向不登录的抓取；读者 MCP 应该只返回该用户有权查看的已发布内容；写作 MCP 必须绑定真实的编辑身份，并保留审阅和撤回。把它们混成「打开 AI 开关」，是后面多数越权问题的起点。三家已经写进文档的做法
下面只对照三家公开文档里已经写清的机制，用来判断该开放哪一层，而不是给产品打分。Document360 的营销页还出现过「发布快一倍」「内容更新快 75%」等数字，但未给出可核对的统计口径，本文不引用。
Document360：一条 MCP，覆盖检索与写作，且目前只支持 OAuth
Document360 在 MCP 概览里把服务器定义为：让 ChatGPT、Claude 等助手直接与知识库的底层内容交互，而不是只去解析渲染后的网页。能力覆盖语义检索和精确文本查找、按版本 / 语言 / 分类 / 状态筛选、读取文章与分类树，以及创建、更新、发布、工作流、术语表、审阅提醒、任务和文章反馈。产品介绍页把这些能力汇总为 29 个工具，并写明 MCP 是建立在既有 API 之上的标准层，并不取代 API。
治理规则同样写得很硬。启用或关闭 MCP 需要 Project Owner 或 Admin 角色；功能在 Business 和 Enterprise 方案提供，项目计划不符时，设置页会要求升级。鉴权目前只支持 OAuth，连接绑定完成授权的那一个 Document360 账号，并继承该账号的角色、版本、语言和可见性。文档明确写了两条后果：第一，尚未支持机器对机器（M2M / client credentials）方式，因此不适合「一个服务账号代表许多没有 Document360 账号的终端用户去取内容」——那种场景应改用 Ask Eddy AI Public API；第二，读者账号可以通过 MCP 提交文章反馈，但不能使用其他写入工具。新工具发布后，助手不会自动发现，需要刷新工具列表或重新连接。
区域可用性也要单独核对。Document360 写明：托管在美国区域的项目，目前无法使用 ChatGPT 的一键连接器；面向美国区域的 Claude 直接连接器仍在等待 Anthropic 审批，没有已公布的时间表。自定义 MCP（Cursor、Copilot 等）仍可通过服务器 URL 或 JSON 配置接入。换句话说，这里的 MCP 首先是内部知识工作的接口：搜索现行文稿、在权限内改稿并走发布流。若你的目标是让广大客户的助手只读公开文档，需要另看它是否提供与 Mintlify / GitBook 类似的、挂在站点域名上的只读检索端点，而不能把这一条「写作 MCP」直接当成对客分发。
Mintlify：检索 MCP 和写作 MCP 分开，并自动生成 llms.txt
Mintlify 把两条 MCP 写进了不同文档。检索 MCP 托管在站点的
/mcp，面向终端用户的助手，提供三个工具：搜索（返回带标题和链接的片段）、用类 shell 命令阅读站点的虚拟文件系统（可一次读取多页或某个章节），以及提交文档问题——问题会作为「无帮助」反馈进入分析后台。站点若启用了登录，还会多一个 /authed/mcp：未登录只能搜到公开页，登录后按用户组返回其有权访问的内容。Mintlify 还在 /.well-known/mcp（以及 .mcp.json、server card）提供发现文档，方便助手在未预先配置时找到端点。对需要程序化接入、无法走浏览器登录的场景，它为 /authed/mcp 提供 client credentials，并可在创建凭证时指定用户组；这与管理后台的 REST API 密钥不是同一套凭证。检索范围并不等于「仓库里的全部文件」。匹配
.mintignore 的文件不会被处理，因而也不会出现在 MCP 里；默认只索引导航（docs.json）中的页面，隐藏页要另设 seo.indexing: "all" 才会进入检索；单页也可在 frontmatter 里写 noindex: true 排除。搜索还可以按版本、语言过滤。为了保护可用性，文档公布了按小时滚动的限额，例如单 IP 每小时 5,000 次请求，站点级搜索和文件系统读取各 10,000 次，鉴权后的同类调用各 5,000 次；超出返回 HTTP 429。Pro 或 Enterprise 还可以使用 WebMCP：在支持该浏览器接口的访问里，把搜索、读页、取 llms.txt 等工具直接挂到当前页面，而不必先去连接托管的 /mcp。与检索 MCP 分开的，是写入用的管理端 MCP。它是托管在
https://mcp.mintlify.com 的同一入口，用你的 Mintlify 账号完成 OAuth，并继承控制台权限：浏览者只能使用只读工具，受保护的配置变更需要管理员角色。2026 年 10 月 19 日的产品更新把「每次修改都必须先合并拉取请求」改成了：分支会自动提交并出现在网页编辑器里，代理可以留下评论和建议，小修复也可以直接发布到主分支。官方提醒应只从受信任的工具连接，并审阅变更——因为项目管理类修改会立即生效，而不经过拉取请求。在 MCP 之外，Mintlify 还为每个站点自动生成 llms.txt 与 llms-full.txt，并在站点根路径和
/.well-known/ 下提供；页面可取 Markdown 版，响应头里带有发现用的 Link 与 X-Llms-Txt。认证会影响这两份文件：全站需要登录时，两者都要认证才能访问；部分页面需要登录时，文件可公开访问，但只列出公开页。自动生成的 llms.txt 超过 100,000 字符时，会把分组索引拆到 /_llms/ 下，以免一份文件塞不进上下文。对帮助中心团队，这套组合的清晰之处在于：对客检索、对内写作和面向抓取的索引，是三条可以分别配置的通道。GitBook：每个已发布站点默认带只读 MCP，但「隐藏」不等于「MCP 不可见」
GitBook 的选择更接近「发布即分发」：每个已发布的文档站都会自动生成 MCP 服务器，地址是
{文档站 URL}/~gitbook/mcp；若站点是部分需要登录、仍有公开或分享链接内容，则使用 /~gitbook/mcp/auth。完全需要登录的站点，客户端通过 MCP 发现和 OAuth（含 Dynamic Client Registration）登录，文档列出的后端包括 Auth0、Azure AD、Okta、AWS Cognito、OIDC，以及配置了 Fallback URL 的自定义后端；它不支持只靠请求头里静态访客令牌做 MCP 鉴权。传输只支持 HTTP，不支持 stdio 和 SSE。有两项产品规则特别容易被忽略。第一，站点自定义里的 Page actions 必须把「Connect with MCP server」放在已启用列表中，否则
~gitbook/mcp 会返回 404；把该动作拖回「可用」以隐藏复制链接，等于同时关掉服务器。第二，也是运营上更需要写进清单的一条：MCP 只读、只提供最新已发布版本，草稿和未发布变更仍保持私密；但是，隐藏页仍可通过 MCP 访问——隐藏只是把页面从已发布目录中拿掉。同一句话也出现在 LLM-ready docs 对 llms-full.txt 的说明里：隐藏页会被写进这份全文文件。GitBook 同时自动提供各页 .md 镜像和站点级 llms.txt / llms-full.txt，并在站点分析里提供 Agents & MCP 报告，用来观察来自大模型和 MCP 客户端的访问。这意味着：在 GitBook 上，「不想出现在侧栏」和「不对外部助手开放」是两件必须分开配置的事。若某篇故障排查只想给已登录客户从目录里找到，却被设成「隐藏但仍已发布」，它仍可能出现在 MCP 和
llms-full.txt 里。要限制访问，应使用站点的鉴权与可见性，而不是只靠隐藏。把三家放在一张表里，差异会更清楚。
| 检查项 | Document360 MCP | Mintlify 检索 MCP + 管理端 MCP | GitBook 已发布站点 MCP |
|---|---|---|---|
| 主要给谁用 | 已登录的内部账号（作者、编辑、有权限的读者）通过助手操作知识库 | 检索 MCP 面向读者的助手；管理端 MCP 面向文档团队 | 读者的助手连接已发布文档站 |
| 默认能力 | 检索 + 写入 + 工作流 + 发布等，共 29 个工具 | 检索侧：搜索、读页、提交反馈；管理侧：改稿、导航、发布 | 只读已发布文档 |
| 端点怎么暴露 | 在项目中启用 MCP，再以一键连接器或自定义 URL 接入 | 站点 /mcp 与 /authed/mcp；管理端为 https://mcp.mintlify.com |
{站点}/~gitbook/mcp（部分鉴权时加 /auth） |
| 鉴权 | 目前仅 OAuth，绑定个人账号；不支持 M2M | 公开检索可不登录；受保护内容走 OAuth 或 client credentials；管理端为账号 OAuth | 公开或分享链接按站点规则；完全鉴权站走 OAuth / DCR |
| 隐藏页与草稿 | 受项目可见性、未发布规则和角色约束 | 默认不索引导航外页面；可用 noindex / .mintignore 排除 |
草稿不暴露；隐藏页仍可被 MCP 和 llms-full.txt 读到 |
| 与 llms.txt 的关系 | 文档站本身提供 llms.txt 索引，但 MCP 是另一条已登录工作流 | 自动生成 llms.txt / llms-full.txt，并与检索 MCP、WebMCP 并存 | 自动生成 llms.txt / llms-full.txt / .md，与站点 MCP 并存 |
| 使用前提（文档已写明） | Business / Enterprise；Owner 或 Admin 启用；美国区域的一键连接器有限制 | 检索 MCP 随站点提供；WebMCP 需 Pro 或 Enterprise | 站点须已发布，且 Page actions 启用「Connect with MCP server」 |
对帮助中心团队，表里最有用的不是「哪一家 MCP 更多」，而是三个必须先写进方案的决定：这条入口是给客户的助手只读公开文档，还是给内部作者改稿；凭证是跟每一位真实用户走，还是用服务账号；「从目录隐藏」是否被误当成了访问控制。
权限、泄露与反馈：开放入口之后真正要守的边界
对外 AI 入口一旦打开，内容运营要同时盯三件事：谁能连上、连上之后能看见什么、发现问题时如何回到编辑流程。
第一，可见性必须跟「对浏览器的可见性」使用同一套规则，而不是另做一份「给 AI 的白名单」。Document360 强调检索和写入都走既有 RBAC 与可见性；Mintlify 把公开
/mcp 和需登录的 /authed/mcp 分成两个端点，避免未登录用户搜到分组内页面。反过来，GitBook 对隐藏页的处理说明：只改导航不够。开放前应做一次抽样：用未登录客户端请求公开 MCP 或 llms.txt，确认没有内部说明、定价例外、仅限付费客户的步骤；再用一个权限最低的登录账号，确认不能读到更高权限的文章。簇内文 知识健康 里讨论的「AI 可读性」，在这里要补上半句——可读，不等于应对所有智能体可读。第二，写作权与检索权分开授权。管理端 MCP 能把「更新过时段落」的时间压得很短，但也把误发布的半径放大了。较稳妥的默认是：读者侧连接只开放只读工具；写入连接只发给需要改稿的人，并保留发布前的审阅。Document360 要求先取回文章再更新、创建前要确认，并且发布遵循与门户相同的权限；若助手以管理员身份完成 OAuth，这些保护会被同一高权限一并带入对话。Mintlify 已经允许小修复直接进入主分支，更需要约定：哪些变更可以自动发布，哪些必须留在编辑器里等人接受。
第三，给服务账号或「代表一群客户去读文档」单独选接口。Document360 写明 MCP 目前不适合 M2M，应改用公开 API；Mintlify 则把 client credentials 限制在鉴权后的检索端点，并按凭证上的用户组裁剪结果。不要为了图省事，把一个管理员 OAuth 会话分享给自动化流程或客户成功团队的公共助手。
第四，把智能体发现的问题接回内容运营。Mintlify 的检索 MCP 可以把「过时、含混、不完整」写成分析后台里的反馈；Document360 允许通过 MCP 提交文章反馈，并由有权限的人更新处理状态。这与 帮助中心进工单台 里讨论的「反馈如何回流」是同一条回路，只是信号来源从页面上的「有用 / 无用」，变成了外部助手在引用时留下的问题单。如果只开放检索、不接收这类反馈，对外分发会让过时内容传播得更快，却更难被编辑看见。
第五，把额度、发现方式和站点行动开关当成可用性配置，而不只是开发细节。Mintlify 公布了明确的小时级限额；GitBook 用一个 Page action 同时控制「复制 MCP 链接」和服务器是否在线。这些都会让「昨天还能连上」变成「今天 404 或 429」，需要写进变更检查，而不是等客户在自己的 IDE 里报错。
选型与运营：先守住单一口径，再决定向哪些助手开放
在决定「要不要上 MCP」之前，更稳妥的顺序是：先指定对客口径的单一事实来源，划清公开、登录客户与内部文稿的边界，再选择要开放的通道。支柱文 帮助中心如何支撑 AI Agent 已经说明，文章一旦进入智能体作答，发布就不能只等于「站点上线」；对外 MCP 和 llms.txt 是同一逻辑的另一条分发面——你点发布，别人的助手可能在几分钟后读到它，也可能因为索引或开关配置，比站点更晚或更早看到。
对使用 Baklib Help Center 的团队，这份对照的落点不在「也去实现一个同名的 MCP 开关」，而在先把将要被任何助手引用的口径收拢到同一套内容里。FAQ、产品文档、更新日志和视频如果分散在不同工具，外部助手很容易在一次检索里混用不同时效、不同权限的段落。Baklib 把这些内容统一托管，并按访客 / 客户 / 内部做权限分级，再通过门户、Widget、API 和 Iframe 把同一份正文分发到官网和产品路径；出海场景还可以按多站点、多语言组织。AI/LLM 语义搜索解决的是读者在你的站点或嵌入组件里，用自己的问法找回可核验正文。llms.txt 或未来的检索型 MCP，解决的是读者不到你的站点、却仍应读到同一份现行公开文档。两者都依赖：公开层不含内部说明，登录层按人过滤，写作与发布仍走人可以审阅的流程。工具可以缩短「从提问到读到原文」的路径，不能代替发布前对可见性和单一事实来源的设计。
可以先用五个很具体的动作做一次对照：
- 列出将要开放的通道属于哪一类：公开索引（llms.txt / Markdown）、读者侧只读 MCP，还是管理侧写作 MCP；不要用一个开关同时打开三类能力。
- 用未登录和最低权限账号各做一次抽样，确认公开端点与
llms.txt/llms-full.txt不包含仅目录隐藏、实则仍已发布的内部页，以及任何需登录才能看的步骤。 - 规定写入连接必须绑定个人账号和真实角色，发布保留审阅；自动化或「代表一群客户去读」另选支持服务凭证、且默认只读的接口。
- 打开对外入口时，同时打开反馈回流：智能体标注过时或含混的页面，应能回到与文章投票、工单缺口同一套内容队列。
- 把对外分发纳入已有的知识健康和SEO / AEO检查：页面更新、下线或改权限之后，站点、嵌入组件、llms.txt 和 MCP 是否在同一份口径上同步，而不是各记各的索引。
做完这五步，再决定要不要把帮助中心做成「可被外部助手连接的知识源」，会比只比较「哪一家已经自动生成了
/mcp」更接近读者真正需要的那次引用：在他们自己的助手里，读到的仍是你允许公开、并且仍然现行的那一篇。想要了解更多?
数字内容新基建白皮书
常见问题
MCP 和帮助中心站内的 AI 搜索有什么区别？
站内语义搜索或对话式回答，发生在你自己的帮助站点、Widget 或客服渠道里，由你决定入口、引文和升级路径。MCP 则是把帮助内容作为一组标准工具，接到读者或内部人员自己使用的 ChatGPT、Claude、Cursor 等外部助手上。两者都要遵守同一套可见性规则，但分发面、鉴权方式和你能观察的会话都不一样。
llms.txt 能否替代 MCP？
不能互相替代。llms.txt 是一份给智能体看的 Markdown 索引，通常再配合各页的
.md 镜像，适合被抓取和按需打开；MCP 提供可调用的搜索、取文，有的产品还包括写入和发布。没有登录会话时，llms.txt 更适合公开文档；需要对人鉴权、要限制工具能力或要把问题反馈写回后台时，应单独评估 MCP。把页面从导航里隐藏，外部 AI 助手就读不到了吗？
不一定。GitBook 写明：隐藏页只是从已发布目录中拿掉，仍可通过站点 MCP 访问，也会进入
llms-full.txt。Mintlify 的检索 MCP 默认只索引导航中的页面，但若把 seo.indexing 设为 all，隐藏页也会进入检索；需要排除时，应使用 noindex 或 .mintignore。不要把「不在目录里」当成访问控制。该不该给 AI 助手开通「写入 / 发布」权限？
应把读者侧检索和管理侧写入分成两条连接，并让写入继承真实的人员角色，而不是共用一把高权限账号。Document360 的 MCP 只支持 OAuth、不支持机器对机器凭证；Mintlify 的管理端 MCP 在 2026 年 10 月后可以把小修复直接发布到主分支。没有审阅、没有撤回手段时，不要把发布权交给助手。
还没有 MCP 的帮助中心，现在能做些什么？
先保证对客口径只有一份：结构清楚、权限分级、发布与下线同步到所有分发面。再补机器可读的公开层（如 llms.txt 与 Markdown 镜像，且不包含受限内容），同时用站内语义搜索、Widget / API / Iframe 把同一套正文送到产品和官网。MCP 可以后加，但不能补上「内容不统一、权限没划清」的缺口。
