大家好我是喻勇。前两天我盯着 WorkBuddy 左侧那排连接器看了一会儿忽然觉得有件事挺别扭。我每天都在 Obsidian 里记东西。技术知识、故障分析、公众号草稿、读书摘记零零散散攒了不少。可到了 WorkBuddy 里这些笔记跟不存在一样。每次聊到以前处理过的问题我还得自己翻一遍再把相关内容贴进去。既然 WorkBuddy 支持 MCP我就想给它接一个 Obsidian 连接器。动手前估了估一两个小时应该够。后来这件事折腾了大半天。中间重启了好几次有两回我已经准备收工下一次调用又把我打了回来。最后卡住我的是两个很普通的问题。一个是 401 鉴权失败一个是 Windows 管道里的中文编码。它们单独看都不复杂叠上常驻进程、宿主配置和 Obsidian 的运行状态以后排查起来就很会绕人。我为什么选 Local REST APIObsidian 接外部工具常见做法有两种。最省事的是把 vault 当成普通文件夹MCP 服务器直接读写里面的 Markdown 文件。安装简单也不用额外启动服务。日常需求只涉及读文件、写文件这条路已经够用。我想要的能力更多。除了读写笔记我还想全文搜索、列标签、执行 Obsidian 命令、打开指定笔记也希望以后能操作当前聚焦的笔记。于是我选了 Obsidian 的 Local REST API 社区插件。插件启用以后会在本机提供 HTTP 或 HTTPS 接口。我的配置走 HTTPS使用 27124 端口通过 API Key 鉴权。这样能调用的能力更完整代价也很明确。Obsidian 必须保持运行插件也得处于启用状态。程序退出接口就跟着消失。沙箱没网我写了一个零依赖版本连接器用 Python 写MCP 走 stdio消息采用 JSON-RPC 2.0。我原本准备直接安装 MCP SDK结果运行环境在沙箱里没有外网依赖下载一直超时。我索性用标准库实现了这次需要的最小协议子集。进程从 stdin 接收消息完成初始化握手再按工具名分发请求最后把结果写回 stdout。服务器主体一百来行不需要虚拟环境也省掉了部署第三方依赖的麻烦。这套做法适合能力范围明确、只在自己机器上用的小连接器。MCP 还包含能力协商、错误处理和协议演进等细节。要做成长期维护或分发给别人使用的产品SDK 仍然更省心。我这次手写是沙箱条件下的一次取舍。握手和工具路由写完后我先在命令行测试。手动读取mcp.json里的 Key启动子进程列目录、读标签都能返回。看到这里我以为最麻烦的部分已经过去了。第一个坑是 401我从 WorkBuddy 的连接器入口发起了一次搜索请求马上返回[HTTP 401] Authorization required。有个状态接口还能勉强返回搜索接口的鉴权更严格缺少有效的 Authorization 请求头就直接拒绝。顺着日志往前查我发现 WorkBuddy 在这次启动 MCP 子进程时没有把OBSIDIAN_API_KEY注入子进程环境。我把配置读取顺序改了。服务器启动后先读取~/.workbuddy/mcp.json中obsidian-local-rest这一项拿到 host、api_key 和 verify_tls。文件里缺少某个字段时再去读环境变量。def _load_cfg(): cfg {host: , api_key: , verify_tls: } try: mcp_path os.path.expanduser(~/.workbuddy/mcp.json) with open(mcp_path, r, encodingutf-8) as f: data json.load(f) env ( data.get(mcpServers, {}) .get(obsidian-local-rest, {}) .get(env, {}) ) cfg[host] env.get(OBSIDIAN_HOST, ) cfg[api_key] env.get(OBSIDIAN_API_KEY, ) cfg[verify_tls] env.get(OBSIDIAN_VERIFY_TLS, ) except Exception as e: log(fmcp.json load failed: {e}) if not cfg[host]: cfg[host] os.environ.get(OBSIDIAN_HOST, ) if not cfg[api_key]: cfg[api_key] os.environ.get(OBSIDIAN_API_KEY, ) if not cfg[verify_tls]: cfg[verify_tls] os.environ.get(OBSIDIAN_VERIFY_TLS, ) return cfg我测了三种情况。子进程没有任何相关环境变量环境变量里放一个故意写错的 Key以及环境变量与配置文件都正常。三次都按预期读取了mcp.json中的值搜索接口不再返回 401。这套优先级是按我的使用环境定的因为当前这份mcp.json才是连接器配置的实际来源。换到别的宿主环境变量或系统密钥存储可能更合适。API Key 既然写在本地文件里就要限制文件权限日志也只能记录配置来源和状态码不能把 Key 原文打出来。代码改完我让 WorkBuddy 重新加载连接器。再搜一次还是 401。这一下很容易把人带回代码里继续查。我加了脱敏诊断日志才看出新写的配置读取逻辑根本没有执行。WorkBuddy 在会话开始时已经拉起了一个常驻 MCP 进程连接器界面里的关闭和开启只让前端重新连接到原来的进程没有重新启动服务器。彻底退出 WorkBuddy再打开新的代码才真正加载。这次经历让我多记了两项检查。宿主有没有把配置传给子进程要在真实调用链里验证。服务器代码改动以后也要确认旧进程已经退出。界面显示重新连接不等于操作系统里的进程换过一轮。第二个坑是中文全成了问号401 解决后我搜索了一次K8S。结果能返回文件名却碎成了一串问号。原本的中文目录和笔记标题几乎没法辨认。问题出在 stdio 两端对字符编码的理解不一致。服务器输出经过 Windows 文本层宿主按 UTF-8 读取中文就在管道中损坏了。我先试了sys.stdout.reconfigure(encodingutf-8)。手动启动时显示正常换回 WorkBuddy 的实际启动路径乱码仍然存在。仅靠调整 Python 文本包装层没能把这条调用链里的编码约定统一起来。最后我绕开文本层直接向sys.stdout.buffer写 UTF-8 字节。def send(obj): data (json.dumps(obj, ensure_asciiFalse) \n).encode(utf-8) try: sys.stdout.buffer.write(data) sys.stdout.buffer.flush() except Exception: sys.stdout.write(data.decode(utf-8, replace)) sys.stdout.flush()输入也做了同样处理。我从sys.stdin.buffer按行读取再显式用 UTF-8 解码。这样请求中的中文搜索词和响应中的中文路径都走同一套编码不再依赖 Windows 当前代码页。重启 WorkBuddy 后文件名终于完整显示出来。04_文章/运维技术小记/待发表文章/03 K8s入门与提高/03 K8s入门与提高.md我刚松口气后面两次调用又报连接被拒绝。检查本机端口27124 和 27123 都没有监听。查到这里原因朴素得让人没脾气。Obsidian 当时没开。把 Obsidian 启动起来再搜一次中文路径干干净净地回来了。所以我现在排查这套连接器顺序很固定。先看 Obsidian 和插件有没有运行再看端口是否监听随后看 HTTP 状态码最后才查 MCP 进程和代码。这个顺序能省掉不少无用功。接好以后我每天怎么用现在用起来很简单我只管说正常的话。想读笔记就说读一下07_日记/2026-08-08.md。想找旧记录就说搜所有提到 K8S 调度的笔记。刚处理完一次 OOM也可以让它把排查结论追加到今天的日记末尾。连接器背后放了十三个工具覆盖列目录、读写文件、全文搜索、打开笔记、列标签、执行命令和操作焦点笔记。平时不用记这些工具的名字WorkBuddy 会按需求选择。接通以后变化很直接。以前聊到 K8S它只能根据当前对话和已有知识回答。我自己写过的排障过程它看不到。现在它能先搜 vault再把旧记录拿出来接着用。那些散在日记和技术笔记里的经验终于进入了日常对话。最后再记几句这次折腾留下的代码不多排查过程倒是很值钱。401 出现时先确认鉴权信息有没有沿着宿主、子进程和 HTTP 请求一路传下去。改完 MCP 服务器要确认宿主启动的是新进程。Windows 上走 stdio最好在协议边界明确使用 UTF-8 字节输入输出别让系统代码页替你做决定。还有最容易漏掉的一项。Obsidian Local REST API 依赖 Obsidian 进程和插件本身。Obsidian 关了端口自然没人监听。遇到连接被拒绝先把它打开再考虑改代码。服务器旁边那份脱敏日志我保留了下来。它只记录配置取自哪里、请求到了哪个接口、返回什么状态码。以后再出问题我能先判断 Key 有没有读到端口有没有响应不必每次从头猜。
