文档版本 v1.0 ｜ 环境 Halo 2.26.0+ / MCP Server 插件 ｜ 最后更新 2026-10-12
作者 小林 ｜ 站点 https://blog.zxiaolin.com

目录

一、先说结论：接上之后到底能干什么

一句话概括：把「开后台 → 翻列表 → 逐个字段核对」这套动作，换成「用嘴说一句」。

我原本的工作流是：登录控制台，翻到文章列表，一页页点进去看标题、摘要、别名，遇到可疑的重复内容就手动比对——全站体检一遍，半小时起步，还容易漏。

接上 MCP 之后，同样的动作变成了一段对话。下面这张表是我这两个月实际用下来的高频场景：

💡 注意一个细节：AI 负责「查」和「拟」，你负责「批」。 尤其是发布、删除这类动作，一定要捏在自己手里，原因见第五节。

二、我为什么要接 MCP

在说怎么装之前，先说清我为什么愿意折腾这一步——不然只是又一个「看起来很酷但用不上」的玩具。

痛点一：查改分离，来回跳。 想检查一批文章的摘要是否缺失，得在列表和详情之间反复横跳。列表页看不到摘要，详情页又要一个个点开，检查 50 篇就是 50 次点击。

痛点二：批量问题肉眼看不见。 我博客里有一批从别处迁移过来的文章，同一篇内容在「已发布」和「回收站」里各躺了一份。这种成对重复，靠人眼在分页列表里比对，基本不可能找全——我是接了 MCP 之后一次性才揪出来的。

痛点三：临时需求写脚本太重。 偶尔想统计一下各分类的文章数、找出零文章的空标签，为这个去翻 Halo 的 API 文档、写个脚本、配个 token，成本远高于收益。而 MCP 就是「开箱即用的脚本层」。

简单说：MCP 解决的不是「AI 能不能写文章」，而是「AI 能不能看见你的站点」。 看不见，就只能你口述给它；看得见，它才能自己发现你没想到的问题。

三、准备工作：三步走

3.1 环境要求

3.2 安装并启用 MCP Server 插件

1. 打开 Halo 控制台，进入 「插件 → 应用市场」。
2. 搜索 「MCP Server」，安装并启用。
3. 确认 Halo 版本满足要求，插件启用后左侧会多出 MCP 相关入口。

插件本身不产生任何外部连接——它只是把站点的操作封装成一组标准工具，等待客户端来调用。不签发密钥，它就一直处于「待机」状态。

3.3 创建访问密钥（这一步最关键）

进入 「工具 → MCP 服务」，创建一个访问密钥。这个入口只有超级管理员能看见。

创建时最重要的一个动作是：勾选这个密钥可以调用的工具范围。这里请务必守住「最小权限」原则：

除了工具权限，密钥还支持设置有效期、禁用状态、IP 白名单，以及密钥轮换。我的做法是：给审计类需求单独发一个只读密钥，写作用另一个，有效期都设短一点。

⚠️ 密钥只在创建或轮换后显示一次，关掉弹窗就再也看不到了。请当场复制保存到密码管理器里。

3.4 配置 AI 客户端

密钥创建完成后，页面会给出可以直接复制的配置片段。它的本质就是一个走 HTTPS 的远程 MCP 端点：

{
  "mcpServers": {
    "halo": {
      "type": "http",
      "url": "https://你的域名/mcp",
      "headers": {
        "Authorization": "Bearer hmcp_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_yyyyyyyy"
      }
    }
  }
}

以 WorkBuddy 为例：打开连接器配置，添加上述片段，然后在连接器管理页对新服务器点一次「信任」，MCP 才会真正激活——这一步很容易漏，漏了就表现为「配置好了但工具数为 0」。

🔒 不要把 token 直接写进会被提交的文件里。 如果你的客户端支持环境变量注入，优先用环境变量；实在要写进配置文件，确保该文件在 .gitignore 里，并且不要截图发到任何公开场合。

四、四个真实使用场景

下面全部是我在自己站点上的实际操作记录，数据都是真实的。

4.1 一句话做全站体检

直接问：「看一下我博客的状态」。返回的是一份结构化总览：

这些数字在后台当然也能看到，但后台不会告诉你「它们之间的比例是否健康」。比如我一眼注意到两件事：标签 171 个远超分类 41 个，说明标签体系已经失控；未发布文章（60）比已发布（50）还多，说明草稿箱积压严重。

4.2 内容审计：一次揪出重复文章

接着让它做重复内容比对，结果很触目惊心——至少有 15 组以上文章同时存在于「已发布」和「回收站 / 草稿」两侧。抽取几组示例：

这批几乎可以确定是早期迁移时重复导入的产物。对我的实际意义是：回收站那边可以直接清掉，不用再留着占索引。而这种「成对重复」如果只靠后台分页翻，我是永远找不全的。

4.3 SEO 诊断：重名分类、重名标签、异常别名

这是我觉得性价比最高的一步。让 AI 把分类、标签、别名字段整体过一遍，它直接给出了三类问题：

这三类问题有个共同点：在后台的视觉界面上几乎看不出来。列表里两个「Adobe全家桶」长得一模一样，你不点进去比对别名，根本不知道它们是两条记录。

修复方向也很明确：重名的合并成一条，异常别名改成纯 ASCII 短横线形式，空标签（有 0 篇文章的）批量清掉瘦身。

4.4 写文章：从大纲到草稿

最后是发文链路。给它一个主题和几条要点，它会把正文、摘要、分类、标签一起拟好，并以「草稿」状态入库——注意，是草稿，不是直接发出去。

我自己的习惯是：草稿出来之后先在后台过一遍，改掉语气不顺手的地方、换掉不合适的配图，确认没问题再点发布。让 AI 无限接近成品，但把「发布」这个按钮留在自己手上。

五、五条安全红线

1. 密钥最小化。 只读的活只给只读密钥。别为了省事给一个「全权限」密钥，然后所有客户端共用它。
2. 密钥不当明文资产。 不写进公开仓库、不贴在聊天记录里、不截图发群。上环境变量或密码管理器。
3. 设有效期和 IP 白名单。 密钥支持这两项，别浪费。定期轮换，旧的就作废。
4. 发布 / 删除动作必须人工确认。 这两类操作不可逆，务必自己点。
5. 定期查调用记录。 控制台能看到工具来源和最近的调用记录。隔段时间看一眼，确认「AI 到底动了什么」。

把 MCP 理解成给 AI 开的一张临时门禁卡：卡上写着能进哪几个房间、几点失效、从哪个门进。门禁卡开得越窄，你越睡得着。

六、MCP 方案 vs CLI 方案，怎么选

我的结论：如果你只是想「让 AI 帮我看看站点、写写草稿」，直接上 MCP。 只有当你要把站点管理嵌进一套复杂的自动化流水线时，CLI 方案才划算。

七、常见问题 FAQ

Q1：配置好了，但客户端显示工具数为 0？
大概率是漏了「信任」这一步。远程 MCP 服务器首次接入通常需要手动确认一次；另外检查客户端是否支持 Streamable HTTP。

Q2：一直连不上 / 握手失败？
按顺序排查：① 站点是否 HTTPS 访问；② URL 是不是https://你的域名/mcp，注意结尾路径；③ Authorization 头的格式是否严格是 Bearer <token>，中间一个空格。

Q3：报权限错误 / 工具调用被拒？
回到「工具 → MCP 服务」检查该密钥勾选了哪些工具。只读密钥去调发布类工具，必然被拒——这是设计如此，不是 bug。

Q4：密钥找不到了怎么办？
密钥只在创建或轮换后显示一次。找不回就直接轮换生成新的，然后把旧密钥禁用。

Q5：AI 会不会把文章改坏？
内容有快照机制，后台能看到历史版本，误改可以回溯。但更稳的做法是——从源头就不给它发布和删除权限。

Q6：附件是怎么存的？
上传沿用 Halo 系统设置里配置的 Console 附件策略与分组，也就是你站点原本的存储策略，不会另起一套。

八、小结

回头看，接 MCP 这件事最大的价值不是「省了几次点击」，而是让我看见了原来看不见的东西。

15 组重复文章、2 个重名分类、2 个重名标签、一批带全角符号的别名——这些问题不是今天才出现的，它们可能已经在那儿躺了大半年。只是过去缺少一个「能把全站一口气读完」的视角，所以一直没人发现。

现在这个视角有了。剩下的就是一件件去修。

最后留个问题给看到这里的你：你有没有给自己的站点接过 MCP，或者类似的自动化管理方案？用下来最大的坑是什么？ 评论区聊聊，我先把上面那批重复文章清完。