WorkBuddy 挂 PyCharm MCP 跑 ComfyUI，模型通道改到 TaoToken 行不行
把 PyCharm 2025.2 的 MCP Server 打开、让 WorkBuddy 信任 pycharm 连接器、再自建一个 comfyui-runner 走 stdio 提交工作流——这套链路我跑通了，Z-Image Turbo 的图也出来了。但跑完才发现一个被忽略的问题：MCP 只解决了"工具怎么连"，没解决"模型通道的 Key 从哪来"。每一轮工具调用背后都在消耗模型通道的 Token，而原文只写了连接器配置，模型配置那一步是空的。这篇就把取 Key 的那一步补上，入口放在 TaoToken 官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ，在控制台创建 Key，回到 WorkBuddy 的模型配置里把 Base URL 填成 https://taotoken.net/api ，mcp.json 里的 url 与 command 保持原样不动。配完先验证 pycharm 工具数，再用绝对路径的 .venv Python 打通通道，最后让 comfyui-runner 的 comfyui_status 和 submit_workflow 跑一遍，确认从模型通道到本地 ComfyUI 出图整段可用。
一、原问题与场景：MCP 连上了，模型通道却是空的
先说清楚这套东西的组成。PyCharm 2025.2 内置了 MCP Server，在 设置 → 工具 → MCP Server 里勾选启用，再把"命令执行"开到可免确认模式，PyCharm 就会在本地起一个 SSE 服务，地址是 http://127.0.0.1:64462/sse 。WorkBuddy 的 ~/.workbuddy/mcp.json 会被自动写入这个地址，信任 pycharm 连接器之后，就能拿到 pycharm_execute_tool 这个通用入口，它下面挂着 48 个子命令，覆盖打开文件、搜索、替换、执行终端命令等 IDE 操作。
但 PyCharm MCP 有个架构性的坑：execute_terminal_command 每次执行都会启动一个全新的 shell 进程，不继承你在 PyCharm 终端标签里已经激活的 .venv 。这意味着直接写 python --version 拿到的是系统 Python，不是虚拟环境里的。所以我又自建了一个 comfyui-runner，用 stdio 传输，command 指向 .venv/Scripts/python.exe ，args 指向 server.py ，天生就跑在 ComfyUI 的虚拟环境里，内置了 comfyui_status 、comfyui_restart 、submit_workflow 等工具，专门处理 ComfyUI 运维和工作流提交。
链路跑通之后问题来了：WorkBuddy 作为 AI Agent，它自己也要调模型。每一次工具调用、每一轮推理，背后都在烧模型通道的 Token。原文只交代了 MCP 怎么连、连接器怎么信任、工作流怎么提交，唯独没写模型 Key 从哪来、Base URL 填什么。如果模型通道没配好，工具链再完整，Agent 也跑不起来。这就是本篇要补的那一步。
二、TaoToken 前置：先把模型通道的 Key 拿到
在动 mcp.json 之前，先把模型通道配好。顺序很重要——先有 Key，再回填配置，最后才验证工具链。
第一步，打开 TaoToken 官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ，注册并登录。第二步，进控制台，找到 API Keys 页面，创建一个新的 Key。创建完先复制保存，页面刷新后完整 Key 不会再显示。第三步，回到 WorkBuddy 的模型配置界面，把 Base URL 填成 https://taotoken.net/api 。
这里有两个细节必须说清楚。第一，Base URL 不要带 /v1 ，就填 https://taotoken.net/api ，多写路径反而会导致请求 404。第二，这个地址不要加任何 UTM 参数，UTM 只用于官网入口的统计，API 地址保持干净。Key 就填你刚创建的那串，形如 YOUR_API_KEY 。
模型配置和 MCP 配置是两条独立的线，互不干扰。mcp.json 里的 url 和 command 保持原样不动，pycharm 的 SSE 地址还是 127.0.0.1:64462，comfyui-runner 的 command 还是那个 .venv 里的 python.exe。你改的只是 WorkBuddy 调模型时用的通道，不是工具连接器。
三、可复制配置：模型通道 + 两个连接器
先看模型配置。在 WorkBuddy 的模型设置里，填入：
Base URL: https://taotoken.net/api
API Key: YOUR_API_KEY
Model: 按你控制台可用的模型 ID 填写
再看 mcp.json 。这个文件在 ~/.workbuddy/mcp.json ，pycharm 那段是 PyCharm 自动写入的，保持不动；comfyui-runner 那段是手动加的 stdio 配置：
{
"mcpServers": {
"pycharm": {
"url": "http://127.0.0.1:64462/sse",
"disabled": false
},
"comfyui-runner": {
"command": "H:/PythonProjects3/Win_ComfyUI/.venv/Scripts/python.exe",
"args": ["H:/PythonProjects3/Win_ComfyUI/comfyui_mcp_runner/server.py"],
"disabled": false
}
}
}
关键点：command 是解释器路径，args 是脚本路径，WorkBuddy 会启动"解释器 + 脚本"的子进程，通过 stdio 做 JSON-RPC 通信。因为解释器就是 .venv 里的 python.exe，所以 comfyui-runner 天生继承整个虚拟环境，不存在 PyCharm MCP 那种"每次新进程丢 venv"的问题。
如果你更习惯命令行方式管理，也可以装 CLI：
npm i -g @taotoken/taotoken
taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m MODEL_ID
这条命令适合在终端里快速验证模型通道是否通，和 WorkBuddy 里的模型配置是同一套 Key 和 Base URL。
四、验证请求：从工具数到出图整段跑通
配置写完，按三步验证，顺序不要乱。
第一步，验证 pycharm 连接器。回到 WorkBuddy 的连接器管理，找到 pycharm 条目点信任。信任后界面会显示这个连接器拥有的工具数，正常情况下能看到 pycharm_execute_tool 这个通用入口，它下面挂着 48 个子命令。如果工具数显示为 0 或者连接器报错，先别往下走，回到第五节排查。
第二步，验证模型通道 + venv 通道。用 execute_terminal_command 调绝对路径的 .venv Python：
execute_terminal_command --command "H:/PythonProjects3/Win_ComfyUI/.venv/Scripts/python.exe --version"
预期输出 Python 3.12.x。这一步同时验证了两件事：模型通道能正常发起工具调用（否则命令根本发不出去），以及 PyCharm MCP 能执行终端命令。注意必须写绝对路径，写 python --version 会落到系统 Python 上。
第三步，验证 comfyui-runner 到本地 ComfyUI 的链路。先调 comfyui_status ：
comfyui_status()
预期返回类似 {"status": "running", "version": "0.27.0", "port": 8189} 。如果 ComfyUI 没起，先 comfyui_restart 拉起来。状态正常后，调 submit_workflow 提交一个 Z-Image Turbo 工作流：
submit_workflow(workflow_json='{"1": {...}}', timeout=120)
预期返回 {"status": "completed", "images": [{"filename": "zimage_cat_00001_.png"}]} 。到这一步，从模型通道发起调用 → WorkBuddy 调度工具 → comfyui-runner 提交工作流 → 本地 ComfyUI 出图，整段链路可用。
五、本篇常见错排查
错误 1：模型通道 401 或 404。 先检查 Base URL 是不是多写了 /v1 。正确写法是 https://taotoken.net/api ，不带 /v1。再检查 Key 有没有复制完整，创建后刷新页面 Key 就不再完整显示，需要重新创建。如果还不行，去控制台的 API Keys 页面确认这个 Key 的状态是否正常。
错误 2：pycharm 工具数显示为 0。 说明 WorkBuddy 没连上 PyCharm 的 SSE 服务。检查 PyCharm 里 MCP Server 是否勾选启用，地址是不是 127.0.0.1:64462/sse 。如果 PyCharm 重启过，SSE 端口可能变化，回 mcp.json 确认 url 是否还是自动写入的那个。另外确认连接器已经点了信任，没信任的连接器不会加载工具。
错误 3：execute_terminal_command 报 python 找不到或版本不对。 这是 venv 不继承导致的，必须用绝对路径。把 H:/PythonProjects3/Win_ComfyUI/.venv/Scripts/python.exe 换成你自己的实际路径。Windows 下路径用正斜杠或双反斜杠，单反斜杠会被当转义符。
错误 4：comfyui-runner 启动失败或工具不显示。 检查 mcp.json 里 command 指向的 python.exe 是否存在，args 指向的 server.py 路径是否正确。stdio 模式下 WorkBuddy 会自动管理进程生命周期，如果 server.py 里有语法错误或依赖缺失，进程会直接退出，工具列表就是空的。可以先用命令行手动跑一遍 .venv/Scripts/python.exe server.py ，看有没有报错。
错误 5：submit_workflow 超时或返回噪声图。 超时先看 ComfyUI 是否在跑、端口对不对，comfyui_status 能自动扫描 8188/8189/8190。如果出的是纯噪声图，检查 ComfyUI 启动参数里有没有 --use-flash-attention ，这个参数和 Z-Image Turbo 的注意力实现不兼容，去掉它或显式换成 --use-pytorch-cross-attention 。另外 Z-Image Turbo 对 seed 和 scheduler 比较敏感，euler + normal、4 steps 是相对稳的组合。
错误 6：端口冲突 EADDRINUSE。 旧的 MCP 进程残留占着端口。可以用 PyCharm MCP 自己杀自己：execute_terminal_command --command "taskkill /F /PID 进程号" 。或者直接重启 WorkBuddy，stdio 模式下进程会随 WorkBuddy 一起退出，比 SSE 省心。
六、把模型通道和工具链分开管
回到标题的问题：WorkBuddy 挂 PyCharm MCP 跑 ComfyUI，模型通道改到 TaoToken 行不行？行，而且应该这么分。MCP 连接器管的是"工具怎么连"，模型通道管的是"Agent 用哪个大脑调工具"，两者是独立的配置层。原文只写了前者，后者空着，Agent 就跑不起来。
具体做法就三步：去 TaoToken 官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 控制台创建 Key，回 WorkBuddy 模型配置填 Base URL https://taotoken.net/api ，mcp.json 原样不动。配完按"信任 pycharm 看工具数 → 绝对路径 Python 验证通道 → comfyui_status 和 submit_workflow 跑通出图"的顺序验证。
如果你只是偶尔跑一次工作流，按上面的 API Keys 和接入文档配好模型通道就够了。如果你打算长期用 WorkBuddy 做编码和 Agent 任务，反复调工具、反复提交工作流，那模型通道的消耗会持续累积，可以看看 Coding Plan 这类长期方案，把通道成本固定下来。工具链这边，pycharm 连接器负责 IDE 操作，comfyui-runner 负责 ComfyUI 运维和工作流提交，两个同时开着，WorkBuddy 会根据任务自动选合适的连接器。模型通道配一次，工具链配一次，之后就是稳定出图。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
