工具做脏活，AI做智能：一个人如何用 40 个 MCP 工具搭出知识操作系统

一句话核心观点

MCP 工具只配做三件事：读、写、搬。所有需要「理解」才能做好的事，全部交给 LLM。

这不是技术选型偏好，这是架构铁律。违反它，你会得到一个看起来很智能、实际上又脆又蠢的系统。

先说反面教材

最常见的 MCP 工具设计错误，是把「智能」塞进工具里。

比如你做一个「收藏文章」的工具。直觉告诉你：工具应该抓网页、提取正文、顺便生成摘要和关键要点、然后存起来。一步到位，多优雅。

错。大错特错。

问题出在「顺便」两个字。当你把摘要生成写进工具代码里，你要么用模板拼凑出一个假摘要（「本文主要讲述了……」），要么在工具内部再调一次 LLM。前者是垃圾，后者是浪费——你的对话里已经有一个 LLM 了，何必再开一个？

更深层的问题是：工具内部的「智能」是不可调试的黑盒。用户看不到中间过程，无法干预，无法纠正。AI 生成了一个烂摘要？对不起，已经存进去了。

「脏活」的精确定义

什么是脏活？问自己一个问题：

这个操作是否需要「理解」才能做好？

不需要理解 → 工具干。文件读写、目录创建、网页抓取、HTML 解析、数据格式转换、索引重建、Frontmatter 注入——这些都是确定性操作，输入确定则输出确定，不需要任何「智能」。
需要理解 → AI 干。生成摘要、提炼要点、设计思考问题、分析项目结构、制定学习计划、撰写复盘报告——这些需要「读懂」才能做好，而「读懂」是 LLM 的核心能力。

这条分界线清晰得令人愉悦。一旦你接受它，系统设计中 90% 的纠结都会消失。

核心架构：Tool → AI → Tool

所有复杂功能都拆成三步：

Step 1: IO 工具（读）→ 返回原始数据给 AI
Step 2: AI（LLM）→ 理解数据，生成智能输出
Step 3: IO 工具（写）→ 把 AI 的输出持久化

这不是理论。ThirdSpace 的 40 个 MCP 工具中，有 9 对遵循这个模式：

读取工具	保存工具	场景
`collect_content`	`save_knowledge_card`	网页收藏 → 知识卡片
`gather_reflections`	`save_reflection`	思考采集 → 深度反思
`create_ship_plan`	`save_ship_plan`	知识素材 → 实践计划
`generate_project_doc`	`save_project_doc`	项目扫描 → 项目文档
`analyze_event`	`save_event_analysis`	事件上下文 → AI 分析
`review_event`	`save_event_analysis`	事件复盘 → 经验沉淀
`weekly_review`	`save_weekly_review`	周数据 → 周报
`monthly_review`	`save_monthly_review`	月数据 → 月报
`draft_article`	`save_article`	素材聚合 → 成型文章

每一对中间那个「→」，就是 LLM 在工作。

为什么不合并成一步？

因为拆开之后，你获得了三个关键能力：

1. 可见性

AI 阅读原始数据后，它的分析过程和结果直接展示在对话中。你看得到它在想什么，它提炼了什么，它遗漏了什么。

这意味着你可以在 Step 2 和 Step 3 之间插手：「这个要点不对，应该强调 XX」「摘要太长了，压缩到三句话」。

如果一步到位，你连纠正的机会都没有。

2. 可替换性

Step 1 和 Step 3 是纯 IO，代码简单，几乎不会出 bug。中间的 AI 是「活的」，它的能力随模型升级而升级。

今天用 Claude，明天换 GPT-5，后天用本地模型——工具层一行代码不用改。因为工具根本不关心谁在中间做「理解」这件事。

3. 可组合性

同一个读取工具可以接不同的 AI 处理逻辑。draft_article 返回的素材，你可以让 AI 写 insight 风格的文章，也可以写 tutorial，也可以写 story。工具不需要知道你想写什么风格——风格是 AI 的事，不是工具的事。

反过来，同一个保存工具也能接不同的输入。save_article 不关心文章是 AI 写的还是你自己写的，它只管存。

一个完整案例：从收藏到闭环

看看「收藏一篇文章」这个最简单的场景，拆开后是什么样：

你说：收藏 https://mp.weixin.qq.com/s/xxxxx

Step 1: collect_content
  → Playwright 打开网页
  → 提取正文（去广告、去导航、去评论区）
  → 解析元数据（作者、发布日期、站点名）
  → 下载配图到本地
  → 原文存入 flux/intake/（溯源备份）
  → 返回正文给 AI

Step 2: AI 阅读正文
  → 一段精练摘要
  → 3-5 个关键要点
  → 3 个深度思考问题（连接层 / 挑战层 / 行动层）

Step 3: save_knowledge_card
  → 生成标准 Frontmatter
  → 写入 space/found/{topic}/{site_type}/
  → Obsidian 兼容格式

Step 1 做的全是脏活：网络请求、DOM 解析、文件写入。这些代码写完就稳了，不需要「聪明」。

Step 2 是纯智能：摘要质量、要点提炼、思考问题的深度——这些全取决于 LLM 的理解能力。换一个更强的模型，同样的工具链立刻产出更好的结果。

Step 3 又是脏活：拼 Frontmatter、创目录、写文件。

这就是「工具做脏活，AI 做智能」的完整含义。

这个原则的边界在哪？

诚实地说，这个原则有一个灰色地带：数据预处理。

比如 weekly_review 工具在返回数据给 AI 之前，需要做聚合：把本周的工作日志、知识卡片、反思记录、Ship 计划进度全部扫描一遍，按时间排序，拼成一个结构化的数据包。

这算「理解」吗？严格说，排序和拼接不算。但「哪些内容值得放进周报素材」这个筛选，已经有点靠近理解的边界了。

当前的处理方式是：宁可多给，不要漏给。工具把所有可能相关的数据都丢给 AI，让 AI 自己判断哪些重要。这会导致 token 消耗偏高，但保证了 AI 有完整的上下文做决策。

未来的优化方向是在工具层加一个轻量级的本地模型做「预筛选」——但注意，这仍然不是让工具「变聪明」，而是让工具「搬运得更精准」。搬运的活，还是脏活。

广义工具层：不只是 MCP

到这里你可能已经注意到一个问题：我一直在说「MCP 工具做脏活」，但系统里干脏活的远不止 MCP。

事实上，「工具」是一个角色，不是一个技术名词。在 ThirdSpace 的架构里，至少有五层东西在扮演工具的角色：

第一层：MCP 工具

这是最显眼的一层。40 个 Python 函数，负责读写搬运。你已经很熟悉了。

第二层：Obsidian

Obsidian 是这个系统里最大的「工具」——只是它太大了，大到你容易忘记它的本质。

想想 Obsidian 做了什么：文件存储和组织、Frontmatter 解析和索引、双向链接渲染、模板应用、习惯打卡的 checkbox 交互。它从不「理解」你的笔记内容，它只是忠实地存储和展示。搜索是机械匹配，Dataview 查询是结构化过滤，Graph View 是链接关系的可视化——没有一个操作需要「读懂」你写了什么。

这正是工具该做的事。Obsidian 是最称职的脏活工人。

第三层：文件系统与目录约定

vault/space/crafted/ vs vault/space/found/ 的分区，flux/intake/ 作为原文溯源区，INDEX.md 作为索引文件——目录结构本身就是一种「工具」。

它用约定替代了编程，用文件夹路径表达了分类逻辑。当你把一篇知识卡片存入 found/ai/wechat/ 时，路径本身就携带了三重信息：这是外部采集的内容（found）、属于 AI 主题（ai）、来源是微信（wechat）。不需要任何 AI 来判断文件该放哪里——路径就是元数据，目录就是分类器。

第四层：Frontmatter 规范

type、topic、origin、status 这套 YAML 字段体系，是人和 AI 之间的数据合约。

MCP 工具按合约写入标准字段，AI 按合约读取和理解上下文，Obsidian 的 Dataview 按合约做聚合查询。三方各自独立运作，唯一的耦合点就是这几行 YAML。

Frontmatter 不聪明，但它让聪明的东西能协同工作。这是基础设施的最高境界。

第五层：AI 自身——当它在搬砖的时候

这听起来矛盾，但仔细想想：当 AI 执行 read_file 读取一个文件，当它调用 replace_in_file 修改一行代码，当它运行一个 shell 命令——这些时刻它就是工具。

AI 在「做脏活」和「做智能」之间不断切换。关键不是谁在干，而是这个操作的性质是什么。同一个 AI，上一秒在帮你分析一篇文章的核心论点（智能），下一秒在把生成的知识卡片写入文件系统（脏活）。角色随操作切换，而不是随身份固定。

重新理解「工具」

所以更准确的表述不是「MCP 工具做脏活」，而是：

任何执行确定性操作的组件都是「工具」，无论它是 MCP 函数、文件系统、Obsidian 插件、还是 AI 自身在执行机械操作时的那个角色。

判断标准只有一个：

问题	回答	角色
需要「理解」才能做好吗？	是	AI 的活
输入确定则输出确定吗？	是	工具的活
换一个更强的模型，结果会更好吗？	是	AI 的活
换一个更强的模型，结果完全一样吗？	是	工具的活

如果你接受这个广义定义，会发现一个有趣的事实：ThirdSpace 里真正「不是工具」的部分其实很少——只有 AI 在对话中阅读、分析、生成的那些瞬间，才是「智能」。其他一切——文件系统、Obsidian、MCP、Frontmatter、目录约定——全是工具层。

这反而解释了为什么这个架构有效：你用大量「笨但稳定」的基础设施，去服务少量「聪明但概率性」的智能输出。智能是稀缺资源，工具是规模化基建。基建越厚实，智能发挥的空间就越大。

对个人开发者的启示

如果你也在用 MCP 搭建自己的工具链，记住两个判断标准：

第一，你的工具代码里，有没有出现「生成一段话」的逻辑？

如果有，停下来。把它拆成两步：工具返回原始数据，AI 生成那段话，然后再调一个工具存起来。

第二，你的系统里，有没有「隐形工具」在默默干脏活？

目录约定、命名规范、Frontmatter 协议、模板文件——这些不起眼的东西，其实是系统最坚实的地基。不要小看它们。一个好的目录结构，顶得上十个花哨的工具。

这不是过度设计。这是你在 AI 时代能做的最正确的架构决策之一。

因为当你把「理解」这件事锁在工具内部，你就把系统的智能上限锁死在了你写代码那天的水平。而当你把「理解」交给 LLM，你的系统会随着模型进步而自动变强。

工具的本分是稳定、可靠、快速地搬砖。至于砖要砌成什么样的建筑——那是建筑师的事。

最后

「工具做脏活，AI 做智能」不是一句口号，它是 ThirdSpace 整个架构背后的统一设计语言。

它回答了一个很朴素的问题：在人、AI、工具三者的协作中，谁该干什么？

工具（MCP + Obsidian + 文件系统 + Frontmatter + 目录约定）：读写搬运，确定性操作，不出错
AI：理解分析生成，概率性操作，越来越好
人：审查决策干预，在 Step 2 和 Step 3 之间把关

三者各归其位，系统才能越用越强。

这就是一个人搭出知识操作系统的秘密——不是工具有多厉害，而是工具知道自己不该做什么。而「工具」这个词，比你以为的要大得多。