Typecho MCP Workbench 开发手记 01：从一个想法到能被 AI 推送的博客

这篇是《Typecho MCP Workbench 开发手记》的第一篇。它不是一篇正式的产品发布稿，更像是一份边做边记的开发日志：我们从一个很朴素的愿望开始，把一个远程 Typecho 博客改造成可以被本地工作台和 AI Agent 一起操作的写作系统。

我准备把这个过程拆成 5 期：

  1. 从需求到架构：为什么不是再做一个博客后台，而是做本地控制台加 MCP。
  2. SSH 零操作部署：本地连接服务器、自动探测 Typecho、自动部署轻量 agent。
  3. MCP 工具层：让 AI Agent 能创建草稿、更新文章、发布、回滚。
  4. 人类工作台：Markdown 编辑、预览、媒体插入、审计和发布确认。
  5. 图床、文件床和安全策略：让图片文件走外部存储，同时保留审计、快照和权限边界。

这个项目想解决什么

传统博客后台更适合人手动写文章：打开网页、登录后台、点新建、写正文、传图、预览、发布。这个流程很稳定，但当 AI Agent 开始参与内容生产之后，它就有一点别扭了。

Agent 更擅长连续操作：整理素材、起草大纲、补充章节、检查错别字、生成摘要、给旧文补链接。它需要的是一组可靠的工具，而不是一个必须用鼠标点击的后台页面。

所以这个项目一开始没有被定义成“漂亮一点的 Typecho 客户端”，而是被定义成：

让 Typecho 成为一个本地可控、AI 可操作、远端尽量轻量的发布目标。

人类界面负责检查、微调和确认；MCP 负责主要操作；远端服务器只需要 SSH，不额外暴露公网 API。

第一版长什么样

先看本地工作台。它不是一个花哨后台，而是一个能快速完成写作和审核的控制面：左边看文章和媒体，中间写 Markdown，右边预览，下面能看到快照和审计记录。

Typecho MCP Workbench 本地工作台截图

这个界面只是入口之一。更关键的是，所有核心能力都下沉成了本地操作和 MCP 工具。也就是说，人可以点按钮，AI Agent 也可以直接调用工具完成同样的事。

架构：本地重一点，远端轻一点

当前方案分成三层：

  • 本地工作台：给人看的 Markdown 编辑和审核界面。
  • 本地 MCP Server：给 AI Agent 调用的工具入口。
  • 远端 PHP Agent：通过 SSH 自动部署，只在需要时执行。

Typecho MCP Workbench 架构图

我喜欢这个结构的一点是，它没有要求远端 Typecho 改造成一个新系统。远端不需要手动安装插件，也不需要长期跑一个新服务。第一次连接时，本地程序通过 SSH 探测 Typecho 目录，识别 Docker 或宿主机 PHP 环境，然后上传一个很小的 agent。

在这个真实环境里，Typecho 跑在 Docker 里，站点目录挂载到容器的 /app，SQLite 数据库是 /app/usr/typecho.db。本地只需要知道 SSH 主机别名 sg1，剩下的探测、部署和调用都由工作台处理。

这次 vibe coding 做到了哪一步

目前第一版已经跑通了一条真实链路：

  • 通过 SSH 连接远端服务器。
  • 自动识别 Docker 里的 Typecho。
  • 自动部署远端 PHP agent。
  • 读取站点信息和文章列表。
  • 创建草稿、更新文章、发布文章。
  • 发布前写本地快照。
  • 支持回滚。
  • 支持上传 Typecho 本地媒体。
  • 支持注册外部图床和文件床 URL。
  • 本地记录审计日志，方便回看每次操作。

这篇文章本身，也是用这套流程创建出来的：先把配图通过媒体工具上传到 Typecho，再由 MCP 创建草稿。发布这一步默认需要显式确认，所以我先把它留在草稿状态，让人类最后看一眼。

为什么第一步先做 MCP

因为这个项目真正的主角不是编辑器，而是 Agent 工作流。

如果只是做一个本地 Markdown 编辑器，那它和很多现成工具差别不大。但如果 Typecho 能被 MCP 工具稳定操作，AI 就能完成更多连续任务：创建系列文章、维护标签、插入外部图片、检查旧文、补链接、发布前生成摘要。

更重要的是，MCP 把“能做什么”和“怎么展示”拆开了。人类工作台可以继续变好看，CLI 可以继续变顺手，AI Agent 也可以直接调用同一组能力。它们不需要互相抢主入口。

这版里最重要的安全边界

我不想让“AI 能发博客”变成“AI 一不小心就发出去了”。所以第一版里有一个很硬的默认策略：

  • 创建草稿可以直接做。
  • 更新文章前先写本地快照。
  • 发布必须显式确认。
  • 发布、更新、上传媒体都会写审计日志。
  • 回滚从本地快照恢复，不依赖人脑记忆。

这套策略目前还很朴素，但已经足够支撑一个重要原则：Agent 可以帮我做很多事，但最后一步必须有清晰边界。

下一篇写什么

下一篇会拆 SSH 零操作部署这一层：本地如何探测远端目录，如何识别 Docker 容器，为什么让 agent 通过 stdin/stdout 通信，以及这样做比公开 HTTP API 更适合一个私人博客工作台。

这个系列不会写成宏大的发布稿。我更想保留真实开发过程里的纹理：哪里顺，哪里踩坑，哪里临时折中，哪里突然发现“这条路可以继续往前走”。