1. workBuddy 调研时 local proxy failed 到底卡在哪一层WorkBuddy 是腾讯出品的全场景 AI 办公工作台能读写本地文件、跑脚本、生成文档、操作桌面应用很多人拿它做调研、写报告、批量处理表格。但只要你把它的模型通道从默认配置改成自定义 endpoint大概率会撞上一个报错local proxy failed。这个报错最坑的地方在于它不告诉你到底是网络层断了、代理层没起来还是鉴权层被拒了只丢一句“本地代理失败”让人无从下手。我这次调研的目标很明确把 WorkBuddy 的模型请求从本地代理链路切到统一的 API 通道让 endpoint、Key、Model ID 三件套集中管理避免每个工具各配一套、改一处漏一处。适合谁看正在做 WorkBuddy 调研、准备接自定义模型、或者已经被local proxy failed卡住半天的开发者。核心检索词就是 WorkBuddy local proxy failed 排查下面按“先定位层、再改配置、最后验证”的顺序走一遍。先说结论local proxy failed九成不是 WorkBuddy 本身坏了而是它启动的本地代理进程没能把请求转发出去。WorkBuddy 的架构里桌面端不直接拿你的 Key 去请求模型而是先起一个本地代理通常是127.0.0.1上的某个端口由这个代理负责拼鉴权头、转发请求。代理起不来、端口被占、Base URL 写错、Key 无效都会统一报成这一句。所以排查的第一步不是改代码而是分层确认代理进程活着吗端口通吗转发目标对吗鉴权头带对了吗我试过最笨但最有效的办法就是把这四层拆开单独测。先curl本地代理端口看它是否响应再curl目标 endpoint看鉴权是否通过两边都通问题就在 WorkBuddy 的配置映射上。这样能把“代理层问题”和“鉴权层问题”彻底分开不用在一堆日志里猜。下面几节会把每一层的具体命令和配置片段都给出来你可以直接复制改。2. TaoToken 前置准备统一 Key 与 API 通道在动手改 WorkBuddy 之前先把统一通道准备好。TaoToken 的作用是把模型请求收敛到一个 endpoint 和一把 Key 上这样 WorkBuddy、Cline、Codex 这些工具都指向同一个 Base URL排查时只需要看一处配置。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 根地址是 https://taotoken.net/api 注意这个地址后面不加任何查询参数。你需要准备三样东西我把它叫“三件套”后面每一节都会反复用到项目值说明Base URLhttps://taotoken.net/api所有请求的根地址不要带尾斜杠API Keysk-开头的一串在控制台生成只显示一次复制保存Model ID例如claude-sonnet-4-5按你实际要调的模型填大小写敏感生成 Key 的路径是进控制台后找 API Keys 页面https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。点新建命名随便写比如workbuddy-test生成后立刻复制。这里有个坑Key 只在创建时完整显示一次关掉弹窗就再也看不到全量了只能重新生成。所以别急着关。如果你只是想先验证模型通不通不想配任何本地工具可以直接用模型对话页面发一条消息https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。这一步能快速确认 Key 有效、模型可用排除掉“Key 本身是坏的”这种低级问题。等对话页面能正常出结果再回头配 WorkBuddy心里就有底了。对于长期做编码或 Agent 任务的场景可以考虑 Coding Plan它把额度和通道打包省得每次单独配https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各工具的配置示例遇到不确定的字段名可以对照。注意Base URL 一定写https://taotoken.net/api不要写成https://taotoken.net/api/v1或带尾斜杠。很多local proxy failed就是因为多写了一层路径代理转发到了不存在的路由直接 404 被吞成代理失败。3. 可复制配置WorkBuddy 与本地代理的 endpoint 映射这一节是重点直接给可复制的配置片段。WorkBuddy 的模型通道配置通常落在一个 JSON 文件里路径类似~/.workbuddy/config.json或应用数据目录下的settings.json。不同版本路径可能略有差异你可以在 WorkBuddy 设置里找“模型配置”或“自定义模型”看它指向哪个文件。下面这份是通用结构字段名按你实际版本对齐。{ model: { provider: custom, baseUrl: https://taotoken.net/api, apiKey: sk-你的Key粘贴在这里, modelId: claude-sonnet-4-5, proxy: { enabled: true, host: 127.0.0.1, port: 8787, timeoutMs: 60000 } } }这里proxy段就是本地代理的配置。enabled为 true 时WorkBuddy 会在127.0.0.1:8787起一个本地转发进程把请求转给baseUrl。local proxy failed最常见的原因就是这个端口被别的程序占了或者代理进程因为权限没起来。你可以先把port改成8899之类不常用的端口试试。如果你用的是 TOML 风格的配置部分版本或插件用 TOML等价写法如下[model] provider custom base_url https://taotoken.net/api api_key sk-你的Key粘贴在这里 model_id claude-sonnet-4-5 [model.proxy] enabled true host 127.0.0.1 port 8899 timeout_ms 60000三件套在这里的对应关系要记牢base_url是 Base URLapi_key是 Keymodel_id是 Model ID。三者缺一不可少任何一个都会在鉴权层被拒然后被本地代理包装成local proxy failed。我踩过的坑是只填了 base_url 和 api_key忘了 model_id结果代理转发出去收到 400日志里只显示代理失败查了半天。改完配置后重启 WorkBuddy让它重新拉起本地代理进程。重启后先别急着发任务用下一节的命令验证代理是否真的起来了。4. 验证请求一次 curl 确认代理层与鉴权层配置改完怎么确认是代理层通了还是鉴权层通了分两步 curl。第一步测本地代理端口是否活着curl -v http://127.0.0.1:8899/health如果返回Connection refused说明本地代理进程根本没起来问题在代理层。这时候检查 WorkBuddy 是否真的重启了、端口是否被占lsof -i :8899、防火墙是否拦了本地回环。如果返回 200 或任何 HTTP 响应说明代理活着进第二步。第二步绕过本地代理直接测目标 endpoint 的鉴权curl -X POST https://taotoken.net/api/v1/messages \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, max_tokens: 64, messages: [{role: user, content: ping}] }这条命令直接打 TaoToken 的 API不经过 WorkBuddy 的本地代理。如果返回正常的 JSON 内容说明 Key 有效、模型可用、鉴权层没问题那local proxy failed就一定是代理层或配置映射的问题。如果返回 401说明 Key 错了或没带对返回 404说明路径写错了返回reading choices之类的解析错误说明返回体结构和 WorkBuddy 预期的不一致通常是 model_id 填错或接口版本不对。两步都通之后再回到 WorkBuddy 里发一个最简单的任务比如“用一句话介绍你自己”。如果这次成功说明整条链路打通。如果还是local proxy failed把 WorkBuddy 的日志级别调到 debug看代理进程实际转发到了哪个 URL、带了什么头。日志里通常会有一行forwarding to https://...对照你的 base_url 看是否一致。提示验证时把max_tokens设小一点比如 64避免一次请求消耗太多额度也加快返回速度。确认通了再跑正式任务。5. 常见报错对照排查401、local proxy failed、reading choices、OAuth这一节把几个高频报错和真实原因对上方便你按图索骥。401 Unauthorized鉴权层问题。Key 错了、Key 过期、或者请求头没带Authorization: Bearer。检查三件套里的 Key 是否完整复制有没有多空格。如果 Key 是从控制台复制的注意别把前后引号也带进去。local proxy failed代理层问题为主但也可能是鉴权失败被代理吞了。先按第 4 节两步 curl 定位。如果直连 endpoint 成功、本地代理端口也活着那就是 WorkBuddy 的配置映射错了重点查 base_url 是否多写了/v1、端口是否和代理实际监听的一致。reading choices或类似解析错误返回体结构和预期不符。常见于 model_id 填错或者接口版本不匹配。确认 model_id 拼写正确确认 base_url 没有多余路径。有些工具期望 OpenAI 格式的choices字段而你调的是 Anthropic 格式的content字段就会报这个。这时候要么换对应格式的模型要么在工具里切换接口协议。OAuth相关报错如果你用的是需要 OAuth 的工具比如某些 Codex 配置检查auth.json里的 token 是否过期。Codex 的配置通常在~/.codex/auth.json里面存 access token。OAuth 过期后需要重新授权或者改用 API Key 方式。如果你同时用 CC Switch 管理多个工具确认切换后 Base URL、Key、Model ID 三件套都同步更新了别只切了 Key 忘了 URL。报错大概率层级首要检查401鉴权层Key 是否完整、请求头格式local proxy failed代理层端口占用、代理进程、base_urlreading choices协议层model_id、接口格式OAuth鉴权层token 过期、auth.json排查顺序建议固定为先直连 endpoint 确认鉴权再测本地代理端口确认代理最后看 WorkBuddy 日志确认映射。这个顺序能保证你每次只动一个变量不会越查越乱。6. 把通道固定下来后续接入与文档对照链路打通之后建议把这次验证过的配置固化下来别每次调研都重配一遍。三件套写进一个统一的配置文件WorkBuddy、Cline、Codex 都引用同一份改一处全生效。Cline 的 MCP 配置里如果出现 Base URL、Key、Model ID也按同样规则填保持语义一致。后续如果遇到新的报错先对照接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面按工具分类列了配置示例和常见问题。需要重新生成 Key 就去 API Keys 页面https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。想快速验证模型是否可用用模型对话页面发一条消息即可https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。长期做编码或 Agent 任务Coding Plan 能把额度管理省掉https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后留一个实用习惯每次改完配置先跑第 4 节那两条 curl再发正式任务。这个动作花不到一分钟但能帮你把 90% 的local proxy failed挡在正式任务之前。