1. 为什么多个 AI 之间总是各说各话我最初用 AI 处理业务问题时习惯把同一个问题分别丢给 Codex、Workbuddy、元宝和 DeepSeek想听听不同角度的意见。结果很快就发现一个尴尬的事实每换一个工具我都要从头讲一遍背景。客户主数据怎么建的、SAP 和 MES 各自管什么、上一轮已经排除了哪些方案这些信息在 A 工具里讲完到了 B 工具又得重新输入。更麻烦的是A 工具里那十几轮讨论的结论B 工具根本读不到。这不是模型能力的问题而是上下文归属的问题。每个 AI 工具的会话记录都锁在自己的产品里互相之间没有读取权限。你分享一个链接过去对方打开也是空的。时间一长我发现自己不是在用 AI 消除信息孤岛而是在制造一批新的知识孤岛——每个工具都只掌握问题的一个碎片。真正让我下决心解决的是一次 CRM 系列的写作。六篇文章从客户触点识别一路延伸到订单履约和业务架构中间涉及大量历史项目细节。如果每换一个 AI 就要重新交代一遍背景效率低到无法接受。我需要的是一个不跟着 AI 工具走的长期知识底座让 Codex 和 Workbuddy 都能从同一份本地资料里检索背景再把整理好的材料带到不同 AI 的讨论中。Obsidian 就是这个底座的载体。它把笔记以纯 Markdown 文件存在本地任何能读文件的工具都能访问。而 TaoToken 解决的是另一件事让 Codex 和 Workbuddy 通过统一的 API 通道接入共享同一套 Base URL 和 Key 配置不用为每个工具单独维护一套接入参数。下面我把这套结构拆开讲包括目录怎么组织、Key 怎么配、怎么验证两个工具读到的是同一份知识。2. TaoToken 前置统一 Key 与 API 通道怎么准备在动手改 Obsidian 目录之前先把 TaoToken 的接入信息准备好。这一步不复杂但顺序不能乱先拿 Key再确认 Base URL最后才是往各个工具里填配置。TaoToken 的官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。你需要注册后到控制台生成一个 API Key这个 Key 就是后面 Codex 和 Workbuddy 共用的凭证。具体操作路径打开官网进入控制台页面找到 API Keys 管理区域新建一个 Key。建议给这个 Key 起一个能识别的名字比如 obsidian-codex-workbuddy方便以后排查是哪个工具在用。生成后立刻复制保存页面刷新后通常不再完整显示。拿到 Key 之后你需要确认两件事Base URL 填什么、Model ID 用哪个。Base URL 统一填 https://taotoken.net/api Model ID 根据你实际要调用的模型来定。如果你不确定当前有哪些可用模型可以到模型对话页面先试一下确认模型名称和响应正常再写进配置文件。这里有一个容易踩的坑很多人把 Base URL 填成官网首页地址结果请求一直 404。记住 API 地址和官网地址是两个不同的东西配置里只填 https://taotoken.net/api 。另外Key 不要直接写在会提交到 Git 的文件里后面我会讲怎么用环境变量隔离。如果你打算长期用 Codex 做本地知识检索和整理建议同时了解一下 Coding Plan 的额度规则避免高频调用时突然被限流。接入文档里有完整的参数说明和示例请求配置前扫一遍能省很多排查时间。3. 可复制配置Obsidian 目录结构与工具接入片段Obsidian 库的目录结构直接决定了 Codex 和 Workbuddy 能不能高效检索到相关背景。我的做法是分三层主题知识层、原始资料层、索引层。主题知识层放经过整理的判断和规则原始资料层放项目文件和历史档案索引层放主题之间的关联和来源标注。一个可用的目录结构大概长这样obsidian-vault/ ├── 00-主题知识/ │ ├── 客户主数据.md │ ├── CRM与OMS边界.md │ └── 订单履约三本账.md ├── 10-原始资料/ │ ├── 项目档案/ │ ├── 会议纪要/ │ └── AI对话记录/ ├── 20-索引/ │ ├── 主题关系.md │ └── 来源标注.md └── 90-模板/ └── 主题背景模板.md主题知识层的每个文件开头用固定格式写清楚现状、关键对象、已确认事实和未解决问题。这样 Codex 检索时能快速判断这个文件跟当前问题是否相关。原始资料层不需要全部塞进 Obsidian大文件可以放在外部目录Obsidian 里只保留链接和摘要。接下来是 Codex 的配置。Codex 通常读取~/.codex/config.toml或项目级的配置文件你需要写入 Base URL、Key 和 Model ID 三件套# ~/.codex/config.toml model 你的Model ID base_url https://taotoken.net/api api_key 你的TaoToken Key如果你用的是环境变量方式可以改成api_key ${TAOTOKEN_API_KEY}然后在 shell 里 exportexport TAOTOKEN_API_KEY你的TaoToken KeyWorkbuddy 的配置类似它一般读取项目根目录下的workbuddy.json或全局设置文件{ baseUrl: https://taotoken.net/api, apiKey: 你的TaoToken Key, model: 你的Model ID, knowledgeBase: /path/to/obsidian-vault }注意knowledgeBase指向你的 Obsidian 库根目录这样 Workbuddy 在检索时能直接定位到主题知识层。两个工具填的是同一个 Base URL 和同一个 KeyModel ID 可以相同也可以不同取决于你希望它们各自调用哪个模型。配置完成后不要急着跑复杂任务。先用一个简单请求验证通道是否通。Codex 可以用命令行发一条测试消息Workbuddy 可以在界面里发一句“读取 00-主题知识/客户主数据.md 并总结”。如果两边都能正常返回说明统一 Key 和 API 通道已经生效。4. 验证请求用同一个问题分别调用两个工具配置写完只是第一步真正要验证的是Codex 和 Workbuddy 读到的是不是同一份知识。我的做法是准备一个只有 Obsidian 库里才有的细节然后分别问两个工具看它们能不能给出相同的事实。先准备一个测试问题。比如在00-主题知识/订单履约三本账.md里写一段只有你知道的历史案例某张外贸订单在销售端显示取消成功但工厂制造任务没有真正取消最后产生了 31 套半成品。这个细节不在任何公开资料里只有你的 Obsidian 库有。然后分别调用两个工具。Codex 这边可以用命令行codex 读取 obsidian-vault/00-主题知识/订单履约三本账.md回答销售端取消成功后工厂为什么还在生产Workbuddy 这边在界面里发同样的指令读取 00-主题知识/订单履约三本账.md回答销售端取消成功后工厂为什么还在生产如果配置正确两个工具都应该返回类似“复制订单时继承了旧订单的内部行 ID销售端取消没有关闭新订单对应的真实制造任务”这样的答案。如果其中一个答不出来或者答的是通用软件定义而不是你库里的具体案例说明它的知识库路径没指对或者检索范围没覆盖到主题知识层。我实测下来最容易出问题的是路径写法。Codex 对相对路径的解析依赖当前工作目录Workbuddy 可能要求绝对路径。建议在配置里统一用绝对路径避免因为启动目录不同导致检索失败。验证通过后你可以进一步测试跨主题检索。比如问“CRM 和 OMS 在订单取消场景下的责任边界是什么”看两个工具能不能同时引用CRM与OMS边界.md和订单履约三本账.md两个文件的内容。这一步能确认它们不只是读到了单个文件而是理解了主题之间的关联。5. 本篇常见错排查401、local proxy failed 与 reading choices配置过程中最常见的报错有三个我按出现频率排一下。第一个是 401 Unauthorized。这个基本就是 Key 的问题。检查三件事Key 有没有复制完整、有没有多余空格、环境变量有没有正确 export。如果你用的是${TAOTOKEN_API_KEY}这种写法先在终端里echo $TAOTOKEN_API_KEY确认变量真的有值。另外注意 Key 是否过期或被撤销到控制台重新生成一个再试。第二个是 local proxy failed。这个报错通常出现在工具试图走本地代理但代理没启动或端口不对的时候。如果你没有特意配置代理检查配置文件里有没有残留的 proxy 字段把它删掉。Base URL 直接填 https://taotoken.net/api 就行不需要额外的代理层。如果公司网络环境有特殊要求确认你的网络能正常访问这个地址。第三个是 reading choices 相关报错。这个一般出现在模型返回格式不符合工具预期的时候。常见原因是 Model ID 填错了或者调用的模型不支持当前工具要求的返回结构。解决办法是到模型对话页面确认模型名称然后换一个兼容性更好的 Model ID 试试。另外检查请求里有没有多余的参数比如同时传了 stream 和 non-stream 的冲突配置。还有一个容易被忽略的问题OAuth 相关报错。如果你之前用某个工具登录过官方账号它可能缓存了旧的 token导致新配置不生效。这时候需要清除工具的本地缓存或重新登录。Codex 可以删掉~/.codex/下的缓存文件Workbuddy 一般在设置里有清除缓存的选项。排查顺序建议是先确认 Key 和 Base URL 正确再确认 Model ID 可用最后检查工具本身的缓存和路径配置。大部分问题在前两步就能解决。6. 让知识底座持续生长从一次验证到长期使用验证通过之后这套结构才算真正开始工作。我现在的习惯是每次用 Codex 或 Workbuddy 处理完一个问题把新产生的结论、证据和未解决问题写回 Obsidian 的主题知识层。下次再遇到相似问题两个工具都能直接检索到这次积累的内容不用我重新交代背景。如果你也想搭一套类似的底座不用一开始就追求大而全。先选一个你反复遇到的问题比如客户主数据怎么建、CRM 到底负责什么然后只做四件事保存相关原始材料、建一份主题背景、区分事实和判断、每次形成结论后写回。跑通一次 Codex 和 Workbuddy 的交叉验证你就知道这套结构能不能解决你的问题。需要提醒的是Obsidian 库里的敏感信息不要直接提交到公开仓库。Key 用环境变量隔离项目档案如果涉及客户数据做好本地加密或访问控制。TaoToken 的 API Keys 页面可以随时撤销和重新生成 Key如果怀疑泄露第一时间换掉。这套底座的价值不在于同时用了多少个 AI而在于无论以后换成哪个工具你都不用再从零介绍自己。新的 AI 可以站在你过去的项目、经验和判断之上继续工作而每一次新的实践也会反过来让这套知识继续生长。
我用Obsidian，给多个AI搭了一个共同的知识底座：TaoToken统一Key接入Codex与Workbuddy
1. 为什么多个 AI 之间总是各说各话我最初用 AI 处理业务问题时习惯把同一个问题分别丢给 Codex、Workbuddy、元宝和 DeepSeek想听听不同角度的意见。结果很快就发现一个尴尬的事实每换一个工具我都要从头讲一遍背景。客户主数据怎么建的、SAP 和 MES 各自管什么、上一轮已经排除了哪些方案这些信息在 A 工具里讲完到了 B 工具又得重新输入。更麻烦的是A 工具里那十几轮讨论的结论B 工具根本读不到。这不是模型能力的问题而是上下文归属的问题。每个 AI 工具的会话记录都锁在自己的产品里互相之间没有读取权限。你分享一个链接过去对方打开也是空的。时间一长我发现自己不是在用 AI 消除信息孤岛而是在制造一批新的知识孤岛——每个工具都只掌握问题的一个碎片。真正让我下决心解决的是一次 CRM 系列的写作。六篇文章从客户触点识别一路延伸到订单履约和业务架构中间涉及大量历史项目细节。如果每换一个 AI 就要重新交代一遍背景效率低到无法接受。我需要的是一个不跟着 AI 工具走的长期知识底座让 Codex 和 Workbuddy 都能从同一份本地资料里检索背景再把整理好的材料带到不同 AI 的讨论中。Obsidian 就是这个底座的载体。它把笔记以纯 Markdown 文件存在本地任何能读文件的工具都能访问。而 TaoToken 解决的是另一件事让 Codex 和 Workbuddy 通过统一的 API 通道接入共享同一套 Base URL 和 Key 配置不用为每个工具单独维护一套接入参数。下面我把这套结构拆开讲包括目录怎么组织、Key 怎么配、怎么验证两个工具读到的是同一份知识。2. TaoToken 前置统一 Key 与 API 通道怎么准备在动手改 Obsidian 目录之前先把 TaoToken 的接入信息准备好。这一步不复杂但顺序不能乱先拿 Key再确认 Base URL最后才是往各个工具里填配置。TaoToken 的官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。你需要注册后到控制台生成一个 API Key这个 Key 就是后面 Codex 和 Workbuddy 共用的凭证。具体操作路径打开官网进入控制台页面找到 API Keys 管理区域新建一个 Key。建议给这个 Key 起一个能识别的名字比如 obsidian-codex-workbuddy方便以后排查是哪个工具在用。生成后立刻复制保存页面刷新后通常不再完整显示。拿到 Key 之后你需要确认两件事Base URL 填什么、Model ID 用哪个。Base URL 统一填 https://taotoken.net/api Model ID 根据你实际要调用的模型来定。如果你不确定当前有哪些可用模型可以到模型对话页面先试一下确认模型名称和响应正常再写进配置文件。这里有一个容易踩的坑很多人把 Base URL 填成官网首页地址结果请求一直 404。记住 API 地址和官网地址是两个不同的东西配置里只填 https://taotoken.net/api 。另外Key 不要直接写在会提交到 Git 的文件里后面我会讲怎么用环境变量隔离。如果你打算长期用 Codex 做本地知识检索和整理建议同时了解一下 Coding Plan 的额度规则避免高频调用时突然被限流。接入文档里有完整的参数说明和示例请求配置前扫一遍能省很多排查时间。3. 可复制配置Obsidian 目录结构与工具接入片段Obsidian 库的目录结构直接决定了 Codex 和 Workbuddy 能不能高效检索到相关背景。我的做法是分三层主题知识层、原始资料层、索引层。主题知识层放经过整理的判断和规则原始资料层放项目文件和历史档案索引层放主题之间的关联和来源标注。一个可用的目录结构大概长这样obsidian-vault/ ├── 00-主题知识/ │ ├── 客户主数据.md │ ├── CRM与OMS边界.md │ └── 订单履约三本账.md ├── 10-原始资料/ │ ├── 项目档案/ │ ├── 会议纪要/ │ └── AI对话记录/ ├── 20-索引/ │ ├── 主题关系.md │ └── 来源标注.md └── 90-模板/ └── 主题背景模板.md主题知识层的每个文件开头用固定格式写清楚现状、关键对象、已确认事实和未解决问题。这样 Codex 检索时能快速判断这个文件跟当前问题是否相关。原始资料层不需要全部塞进 Obsidian大文件可以放在外部目录Obsidian 里只保留链接和摘要。接下来是 Codex 的配置。Codex 通常读取~/.codex/config.toml或项目级的配置文件你需要写入 Base URL、Key 和 Model ID 三件套# ~/.codex/config.toml model 你的Model ID base_url https://taotoken.net/api api_key 你的TaoToken Key如果你用的是环境变量方式可以改成api_key ${TAOTOKEN_API_KEY}然后在 shell 里 exportexport TAOTOKEN_API_KEY你的TaoToken KeyWorkbuddy 的配置类似它一般读取项目根目录下的workbuddy.json或全局设置文件{ baseUrl: https://taotoken.net/api, apiKey: 你的TaoToken Key, model: 你的Model ID, knowledgeBase: /path/to/obsidian-vault }注意knowledgeBase指向你的 Obsidian 库根目录这样 Workbuddy 在检索时能直接定位到主题知识层。两个工具填的是同一个 Base URL 和同一个 KeyModel ID 可以相同也可以不同取决于你希望它们各自调用哪个模型。配置完成后不要急着跑复杂任务。先用一个简单请求验证通道是否通。Codex 可以用命令行发一条测试消息Workbuddy 可以在界面里发一句“读取 00-主题知识/客户主数据.md 并总结”。如果两边都能正常返回说明统一 Key 和 API 通道已经生效。4. 验证请求用同一个问题分别调用两个工具配置写完只是第一步真正要验证的是Codex 和 Workbuddy 读到的是不是同一份知识。我的做法是准备一个只有 Obsidian 库里才有的细节然后分别问两个工具看它们能不能给出相同的事实。先准备一个测试问题。比如在00-主题知识/订单履约三本账.md里写一段只有你知道的历史案例某张外贸订单在销售端显示取消成功但工厂制造任务没有真正取消最后产生了 31 套半成品。这个细节不在任何公开资料里只有你的 Obsidian 库有。然后分别调用两个工具。Codex 这边可以用命令行codex 读取 obsidian-vault/00-主题知识/订单履约三本账.md回答销售端取消成功后工厂为什么还在生产Workbuddy 这边在界面里发同样的指令读取 00-主题知识/订单履约三本账.md回答销售端取消成功后工厂为什么还在生产如果配置正确两个工具都应该返回类似“复制订单时继承了旧订单的内部行 ID销售端取消没有关闭新订单对应的真实制造任务”这样的答案。如果其中一个答不出来或者答的是通用软件定义而不是你库里的具体案例说明它的知识库路径没指对或者检索范围没覆盖到主题知识层。我实测下来最容易出问题的是路径写法。Codex 对相对路径的解析依赖当前工作目录Workbuddy 可能要求绝对路径。建议在配置里统一用绝对路径避免因为启动目录不同导致检索失败。验证通过后你可以进一步测试跨主题检索。比如问“CRM 和 OMS 在订单取消场景下的责任边界是什么”看两个工具能不能同时引用CRM与OMS边界.md和订单履约三本账.md两个文件的内容。这一步能确认它们不只是读到了单个文件而是理解了主题之间的关联。5. 本篇常见错排查401、local proxy failed 与 reading choices配置过程中最常见的报错有三个我按出现频率排一下。第一个是 401 Unauthorized。这个基本就是 Key 的问题。检查三件事Key 有没有复制完整、有没有多余空格、环境变量有没有正确 export。如果你用的是${TAOTOKEN_API_KEY}这种写法先在终端里echo $TAOTOKEN_API_KEY确认变量真的有值。另外注意 Key 是否过期或被撤销到控制台重新生成一个再试。第二个是 local proxy failed。这个报错通常出现在工具试图走本地代理但代理没启动或端口不对的时候。如果你没有特意配置代理检查配置文件里有没有残留的 proxy 字段把它删掉。Base URL 直接填 https://taotoken.net/api 就行不需要额外的代理层。如果公司网络环境有特殊要求确认你的网络能正常访问这个地址。第三个是 reading choices 相关报错。这个一般出现在模型返回格式不符合工具预期的时候。常见原因是 Model ID 填错了或者调用的模型不支持当前工具要求的返回结构。解决办法是到模型对话页面确认模型名称然后换一个兼容性更好的 Model ID 试试。另外检查请求里有没有多余的参数比如同时传了 stream 和 non-stream 的冲突配置。还有一个容易被忽略的问题OAuth 相关报错。如果你之前用某个工具登录过官方账号它可能缓存了旧的 token导致新配置不生效。这时候需要清除工具的本地缓存或重新登录。Codex 可以删掉~/.codex/下的缓存文件Workbuddy 一般在设置里有清除缓存的选项。排查顺序建议是先确认 Key 和 Base URL 正确再确认 Model ID 可用最后检查工具本身的缓存和路径配置。大部分问题在前两步就能解决。6. 让知识底座持续生长从一次验证到长期使用验证通过之后这套结构才算真正开始工作。我现在的习惯是每次用 Codex 或 Workbuddy 处理完一个问题把新产生的结论、证据和未解决问题写回 Obsidian 的主题知识层。下次再遇到相似问题两个工具都能直接检索到这次积累的内容不用我重新交代背景。如果你也想搭一套类似的底座不用一开始就追求大而全。先选一个你反复遇到的问题比如客户主数据怎么建、CRM 到底负责什么然后只做四件事保存相关原始材料、建一份主题背景、区分事实和判断、每次形成结论后写回。跑通一次 Codex 和 Workbuddy 的交叉验证你就知道这套结构能不能解决你的问题。需要提醒的是Obsidian 库里的敏感信息不要直接提交到公开仓库。Key 用环境变量隔离项目档案如果涉及客户数据做好本地加密或访问控制。TaoToken 的 API Keys 页面可以随时撤销和重新生成 Key如果怀疑泄露第一时间换掉。这套底座的价值不在于同时用了多少个 AI而在于无论以后换成哪个工具你都不用再从零介绍自己。新的 AI 可以站在你过去的项目、经验和判断之上继续工作而每一次新的实践也会反过来让这套知识继续生长。