让 AI 够得着外部数据：连接器、MCP 与一次自建实践

《WorkBuddy 七层实操笔记》系列第 4 篇 · 作者：当月光落下 · 首发于腾讯云开发者社区。 全系列基于一台真实机器的逐条实测，记录哪些机制符合直觉、哪些相反，以及每条结论是在踩过什么坑之后才成立的。 系列目录：

1. 七层能力模型：把 AI 助手从「能用」拆到「会搭」
2. 信息该放哪：七个存放位置与一条晋升阶梯
3. 技能装了却不被调用：触发机制与四十条清单上限
4. 让 AI 够得着外部数据：连接器、MCP 与一次自建实践 ← 本篇
5. 资料库不是网盘（上）：七种节点、三层 block 与 database
6. 资料库不是网盘（下）：page 发布、检索与 doc 修订流
7. 到点自己干活：自动化的三条执行链与五条军规
8. 专家是角色滤镜，不是记忆分片：兼谈多设备同步的盲区
9. 四十一条实测踩坑清单：每条都标了根因和正解
10. 按收益排序的上手路径，与五份可直接复制的模板

L2 工具与执行：能力与代价

这一层是「能动手」的那部分——读写文件、跑命令、搜索、生成多模态内容。它没有配置项，但要理解它的两种执行形态和环境代价。

两种执行形态：agent 直接做 vs 脚本做

核心判据

「AI 判断」与「机械执行」要拆开。

需要判断的部分（分类、取舍、写文案）交给 agent 用自然语言规则现场做；机械的重复劳动（取数、计算、渲染、批量写）打包成脚本执行。

理由：agent 每一步都是一轮模型思考，几十步叠加就是分钟级；脚本一步跑完是秒级。实测同一个任务，脚本版比纯提示词版快 3 倍。

环境代价：为什么脚本化成了习惯

真实办公环境里，工具层会遇到三类制约，理解它们才能解释「为什么文档里的命令我这儿跑不通」。

加密拦截的正确处置（重要）

判据要点：不要把「被加密杀掉」误判成沙箱问题或脚本 bug——这两种误判都实际发生过。

文件读写的一个隐藏坑：换行符

误解

「我抽出脚本里的核心命令在终端跑一遍，能跑通就说明脚本没问题。」

真相

验证要验交付物本身，不是验它的等价物。

实测：某个 Windows 批处理入口文件，里面的命令是对的，但文件本身是坏的——编辑工具产出了 LF 换行，而该格式要求 CRLF。结果解析异常，实测只执行到最后一行，前面全部被吞掉（标准输出仅 24 字节）。改成正确换行后输出完整（447 字节）。

⇒ 落地形态是哪一种，就验证哪一种。

本节可带走的判据

1. 判断的活给模型，机械的活给脚本——这是效率差 3 倍的分界线。
2. 「零输出 + 非零退出 + 无堆栈」= 外部拦截，不是代码问题，立即停手报告。
3. 交付物是什么形态，就用什么形态验证；别用等价物代替。

L3 连接器与 MCP：让 AI 够得着外部数据

这一层的独有价值

够到本机够不到的数据。

它和资料库是上下游关系——连接器负责「数据从哪来」，资料库负责「取来的放哪」。这也是学习顺序上把连接器排在资料库之后的理由：顺序反了，取来的数还是没处放。

第一件事：MCP 配置有三份，别看错那份

误解（一个典型误判）

「打开 ~/.workbuddy/mcp.json 一看是空的，所以这一层完全没接入。」

实测发现，本机至少存在三份 MCP 配置，身份完全不同：

教训（这是本机第三次因搜索不全导致误判）

判断「某层是否为空」之前，先找全它的配置文件。 只看一个路径就下结论，会得出假的「零接入」。

这与另一条经典错误同类：用一条命令的成败直接推断整体状态。

三种来源：配置里看不见 ≠ 不能用

由此得到一条判据

「配置里看不见」不等于「不能用」。 判断有没有某个 MCP，要看运行时实际可用的工具列表，而不是只看 mcp.json。

反过来的例子很常见：mcp.json 是空的，但会话里照样能调用表格处理、支付等自带 MCP——因为它们来自插件，不写在用户的 mcp.json 里。

状态有四个层次，别只看「装没装」

连接器的状态不是一个布尔值。实测状态文件里能看到完整的四层：

于是准确的表述是：「绑过 2 个，全部被自己关掉了，现在启用数为 0」——不是「没接过」，而是「接过又关了」。

怎么找「有没有我要的连接器」

官方提供了只读的检索工具，一次可返回上百个真实候选。它返回的是当前可安装的连接器——不要用网页搜索代替它。

典型用法：说一句「我要接 XX 系统」，由 AI 查真实候选，再用推荐卡片给出选择。安装与授权始终是你点头的事。

凭据怎么存，以及自建 MCP

凭据是本地加密存放的

连接器目录下有一份明确写着「不要删」的说明文件，规则大意是：

规则

本目录包含连接器的本地凭据。不要单独删除其中的隐藏文件（加密后的授权令牌、连接器状态、本地主密钥）。彻底清理时请整目录删除，不要只删某一个文件。

实测加密方案：AES-256-GCM + HKDF-SHA256，配一个 32 字节的本地主密钥。授权头里的敏感值是密文（由 iv / tag / ct 三段构成）。

自建 MCP：真正该用这一层的场景

这条认知很关键

接连接器不是去市场里挑，是让 AI 够得着你自己的数据。

官方目录里的几百条是通用服务。而你真正需要的，往往是自己的一套数据——某个内部系统、某份定期更新的台账、某个自建网站上的提交记录。

做法是：写一个只读的本地 MCP 服务器（零依赖手写 JSON-RPC 即可），把数据源包成一个可查询接口。一个实测的完整闭环是：

判据：什么时候值得接

不是为了「用了这一层」而接。唯一的判据是：有没有一件事是你现在手动复制粘贴的？

有 → 值得接；没有 → 接了也是摆设。 实测中曾绑过两个外部服务又被关掉，恰恰说明当时没有真实痛点驱动。

连接器 vs 技能 vs 专家：别混

本节可带走的判据

1. 三份配置文件，别看错那份——判断「空不空」前先找全。
2. 目录 ≠ 绑定 ≠ 启用，四层状态要分开说。
3. 插件自带 MCP 不写进用户配置，所以「看不见」不等于「不能用」。
4. 连接器的真正价值是接自己的数据源，不是去市场挑通用服务。

文中所有「实测」「xx KB」「xx 个」这类数量，均来自某一台真实机器的快照，请当作方法示范而非通用阈值；真正通用的是判据与因果关系。

原创声明

本文系「当月光落下」原创，首发于腾讯云开发者社区。内容来自作者在实际使用中的逐条实测整理， 所有结论均有本机实机验证或真实接口调用支撑；文中出现的数量均为特定环境下的实测快照， 仅作方法示范，不作为通用阈值。

如需转载，请注明作者「当月光落下」及首发出处，未经许可不得用于商业用途。