1. 为什么要在 Obsidian 里接 Claude 和 Codex如果你平时用 Obsidian 记笔记、写文档同时又习惯用 Claude Code 或 Codex 帮忙改代码、润色文字那你大概率经历过这种来回切换在 Obsidian 里写到一半想让 AI 帮忙整理一下结构得切到终端把内容复制过去等它输出再复制回来。几趟下来原本连贯的思路就断了。我自己的场景更典型一些一边维护一个技术文档库一边还要写点脚本。文档用 Obsidian 管脚本用 Claude Code 和 Codex 写。两边割裂得很厉害。后来我把 AI 能力直接接进了 Obsidian在笔记界面里就能对话、改稿、生成代码块切窗口这个动作基本消失了。这套方案的核心是三样东西Obsidian 负责本地存储和 Markdown 渲染Claude Code 和 Codex 负责 AI 能力中间用一个叫 Claudian 的插件把两者连起来。Claudian 目前没上 Obsidian 官方插件市场得通过 BRAT 这个中转插件来装。整个流程走下来十分钟左右能跑通。这篇文章面向的是想把 AI 接进个人笔记系统的开发者。我会把可复制的插件配置、BRAT 安装步骤、以及统一走 TaoToken 的 Key 和 API 通道的 settings.json 骨架都写出来最后给出验证知识库读写和 AI 调用是否生效的具体动作。你跟着做装完就能在 Obsidian 里直接问 Claude 或 Codex。需要提前说明一点Claude Code 和 Codex 本身是命令行工具Claudian 做的是在 Obsidian 里调用你本地已经装好的 CLI。所以本地得先有这两个命令插件才能找到它们。如果你还没装后面我会给出检查路径的方法。另外很多人卡在“插件装上了但模型不出来”这一步。原因通常不是插件坏了而是 CLI 路径没配对或者对话框没刷新。这些坑我会在排障章节里逐个拆开讲。2. TaoToken 前置统一 Key 与 API 通道在动手装插件之前先把 AI 侧的通道理顺。Claude Code 和 Codex 各自有默认的接入方式但在本地知识库这种长期使用的场景里我建议统一走一个 API 通道好处是 Key 管理集中、模型切换方便、排查问题的时候只需要看一个地方。TaoToken 在这里扮演的就是这个统一通道的角色。它提供兼容的 API 入口Claude 和 Codex 都可以通过它来调用。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。你需要先拿到一个 API Key。进入控制台创建即可地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。创建完之后在 API Keys 页面可以看到你的 Key页面地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。这个 Key 后面要填到 Claude Code 和 Codex 的配置里。这里有个概念要分清Claudian 插件本身不直接管 Key它调用的是你本地的 Claude CLI 和 Codex CLI。所以 Key 是配在 CLI 层面的不是配在 Obsidian 插件里的。这一点很多人一开始会搞混以为在插件设置里填 Key 就行其实不是。Claude Code 的配置通常放在用户目录下的 settings.json 里。Codex 的配置则涉及 auth.json 和 config.toml。下面我给出一个 settings.json 的骨架你可以照着改。注意路径要和你本地的实际路径一致不要照抄我的用户名。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密钥 }, model: claude-sonnet-4-20250514 }这段配置的意思是把 Claude Code 的请求指向 TaoToken 的 API 入口并用你的 Key 做鉴权。model 字段填你实际要用的模型 ID。如果你用的是 Codex配置方式类似但字段名不同通常在 config.toml 里指定 base_url 和 modelKey 放在 auth.json 里。统一通道还有一个实际好处当你想从 Claude 切到 Codex或者换一个模型试试效果只需要改配置里的 model 字段不用重新申请 Key、不用改插件设置。对于长期维护知识库的人来说这种集中管理省心很多。配置改完之后建议先在终端里单独验证一下 CLI 能不能正常调用再去 Obsidian 里测。终端能通、Obsidian 不通问题就在插件层终端就不通问题在 Key 或网络层。这个分层排查思路后面会反复用到。3. 可复制配置BRAT 安装与 Claudian 设置这一节是整篇的核心操作部分我把每一步都写成可以直接复制的形式。你按顺序来不要跳步。3.1 安装 Obsidian 并创建知识库如果你已经有 Vault直接跳到 3.2。没有的话去 Obsidian 官网下载对应平台的安装包。macOS 用户下载后拖进应用程序文件夹Windows 用户直接运行安装程序。首次打开会看到欢迎界面点“创建新库”选一个本地目录作为存放位置。这个目录就是你的知识库根目录后面所有笔记都存在这里。创建完成后你会看到一个空白的库。左侧是文件列表右侧是编辑区。先随便新建一个笔记确认读写正常再继续下一步。3.2 关闭安全模式并安装 BRATObsidian 默认开启安全模式不允许安装第三方插件。进入设置左侧菜单往下滑找到“第三方插件”点进去把顶部的“安全模式”关掉。关掉之后“社区插件市场”就可用可点了。点“浏览”进入插件市场搜索框输入 brat。第一个结果就是 BRAT全称是 Beta Reviewers Auto-update Tool。点进去点“安装”装完点“启用”。如果安装过程中提示失败多半是网络波动重试几次通常能过。启用后重启一次 Obsidian让插件完全加载。3.3 用 BRAT 添加 Claudian 仓库重启后回到设置左侧菜单滑到最底部能看到 BRAT 的入口。点进去在“Repository”输入框里填入 Claudian 的仓库地址https://github.com/YishenTu/claudian点“Add Plugin”BRAT 会去拉取这个仓库的信息。如果提示 GitHub API 限额有两个处理办法一是等几分钟再试二是去 GitHub 生成一个 Personal Access Token 填到 BRAT 设置里提高限额。生成 Token 的路径是 GitHub Settings → Developer settings → Personal access tokens → Tokens (classic)不需要勾选特殊权限生成后复制填进去即可。拉取成功后BRAT 会列出 Claudian点安装。装完确认 Claudian 处于启用状态。此时 Obsidian 左侧边栏应该会多出一个机器人图标那就是 Claudian 的入口。没看到的话去设置里检查 Claudian 是否启用或者重启一次 Obsidian。3.4 配置 Claude CLI 路径插件装好了但它还不知道你的 Claude Code 装在哪。先在终端里查路径which claude # 或者 Windows 下 where claude假设输出是/opt/homebrew/bin/claude把这个路径记下来。回到 Obsidian 设置 → 第三方插件 → Claudian → 切到“Claude”标签页把路径填进去。页面默认是英文可以在设置里改成中文。3.5 配置 Codex 并给出 settings.json 骨架Codex 的套路一样先查路径which codex # 输出示例/opt/homebrew/bin/codex填到 Claudian 的 Codex 配置里并确认“Enable Codex provider”开关是打开的。然后把你 CLI 层的 settings.json 按第 2 节的骨架配好。这里再强调一次三件套Base URL 填https://taotoken.net/apiKey 填你在控制台创建的密钥Model ID 填你要用的模型。三者缺一不可少一个都会导致调用失败。配置完成后重启 Obsidian。重启后在 Claudian 里新建一个对话框Claude 和 Codex 的模型应该都会出现在选择列表里。如果模型没出来先检查开关再新建对话框测试——旧对话框不会自动刷新模型列表这是我自己踩过的坑。4. 验证请求确认知识库读写与 AI 调用生效配置写完不代表生效得实际验证。我一般分两步走先验证 Obsidian 本身的读写再验证 AI 调用。第一步在 Obsidian 里新建一个笔记随便写几行字保存关闭再打开确认内容还在。这一步是确认知识库本身没问题排除掉存储层的干扰。第二步打开 Claudian 对话面板输入一句简单的话比如“你是哪个模型”或者“帮我总结一下当前笔记的要点”。如果它能正常回复说明 AI 调用链路是通的。Claudian 会自动检测本地的 Claude 安装路径正常情况下不需要额外配置。如果你想更严格地验证可以让它读一篇你已有的笔记然后让它基于笔记内容回答问题。比如你有一篇关于某个技术点的笔记问它“这篇笔记里提到的三个要点是什么”。它能准确答出来说明它确实读到了你的本地文件而不只是泛泛而谈。再进一步可以让它帮你改一段文字。选中笔记里的一段话让 Claudian 帮你润色。改完之后内容直接落在笔记里格式还是 Markdown不用二次排版。这一步验证的是写入能力。验证过程中如果遇到报错先看终端里 CLI 单独跑是否正常。终端正常、Obsidian 报错问题在插件配置终端也报错问题在 Key 或 API 通道。这个分层方法能帮你快速定位。5. 常见错误排查401、local proxy failed 与模型不显示这一节我把实际遇到过的报错和对应处理列出来你对照着看。401 未授权这个最常见基本是 Key 的问题。检查 settings.json 里的ANTHROPIC_API_KEY是否填对有没有多余空格Key 是否已过期或被删除。去 API Keys 页面确认一下 Key 的状态。如果 Key 没问题检查 Base URL 是否写成了https://taotoken.net/api注意结尾不要多加斜杠。local proxy failed这个报错通常出现在 CLI 层意思是本地代理连接失败。先确认你的网络能正常访问 API 入口可以在终端里用 curl 测一下连通性。如果网络没问题检查 settings.json 里的 Base URL 是否拼写正确。还有一种情况是本地开了某些网络工具导致端口冲突关掉再试。reading choices 相关报错这类报错一般出现在模型返回格式异常时。检查你填的 Model ID 是否是通道支持的模型。如果 Model ID 写错请求会返回非预期结构插件解析时就报错。换成确认可用的模型 ID 再试。OAuth 相关报错如果你之前用 OAuth 方式登录过 Claude配置里可能残留了旧的认证信息和新的 Key 冲突。检查配置目录下是否有旧的凭据文件清理掉再重新配。模型不显示Claudian 里看不到 Claude 或 Codex 的模型先检查“Enable Codex provider”开关再确认 CLI 路径填对。然后新建一个对话框——旧对话框不会刷新模型列表。如果还不行重启 Obsidian。BRAT 安装失败多半是 GitHub API 限额。等几分钟或者配一个 Personal Access Token。也可能是同时有多个插件在访问 GitHub把限额用完了逐个排查。排查的时候记住一个原则先分层再定位。CLI 层、插件层、网络层分开测不要一上来就乱改配置。6. 长期使用建议与接入入口跑通之后这套组合能做的事情比想象中多。写技术文档的时候让 Claude 帮你补代码示例整理会议纪要让它提炼要点笔记太乱让它自动分类打标签。因为 Obsidian 本身是 MarkdownAI 输出的内容格式直接兼容不用二次排版。如果你打算长期用我建议把 Coding Plan 用起来地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。对于需要长期编码和跑 Agent 的场景套餐形式比按次调用更划算管理也集中。日常想快速验证某个模型的效果可以直接用模型对话页面地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。不用改配置打开就能试。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有各语言的调用示例和参数说明。如果你用的是 Claude Code 的 Anthropic 兼容模式参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 这个页面里面有专门的配置说明。Key 管理还是回到 API Keys 页面地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。建议定期检查 Key 的使用情况避免额度用尽导致调用失败。最后说一个实际经验配置改完之后先在终端里单独跑一次 CLI确认能通再去 Obsidian 里测。这样能把问题范围缩小一半。很多人一上来就在插件里折腾结果发现是 Key 没配对白白浪费时间。分层验证这个习惯能帮你省下不少排查时间。