1. 为什么要在 PyCharm 里给 AI Agent 接 MCP 连接器如果你正在用 AI Agent 辅助 ComfyUI 开发大概率遇到过这种尴尬AI 能帮你改代码、写工作流 JSON但一到「重启 ComfyUI 服务」「查一下 8189 端口谁占着」「把这张图跑出来」就歇菜了。原因不复杂——AI 助手默认只能读写文件进不了你 IDE 的终端环境更碰不到你那个已经激活了.venv的 Python 解释器。MCPModel Context Protocol就是来解决这件事的。它是一套让外部 AI 工具通过标准协议调用 IDE 或本地服务能力的连接器规范。PyCharm 2025.2 之后内置了 MCP Server你可以把它理解成「给 AI 开了一扇进 IDE 的门」AI 通过这扇门能执行终端命令、跑运行配置、打开和搜索文件。再配合一个自定义的 ComfyUI 执行器 MCPAI 就能在同一个对话里既改代码又跑图。这篇要交付的是一条完整链路在 PyCharm 里启用 MCP Server → 配置连接器 → 写一个跑在 ComfyUI.venv里的自定义执行器 → 把 endpoint 改到 TaoToken 做连通性验证 → 排掉 401 和 local proxy failed 这两类高频报错。适合已经在用 ComfyUI、想让 AI Agent 真正动手干活的人。全程 Windows 11 PyCharm 2025.2 ComfyUI v0.27 Python 3.12 实测命令可以直接抄。先说清楚一个关键认知PyCharm 自带的 MCP 和自定义 ComfyUI 执行器不是二选一而是互补。前者管 IDE 操作编辑器、运行配置、文件搜索后者管 ComfyUI 运维启停、提交工作流、轮询出图。两个都开AI 会按任务自己挑。下面从环境准备开始。2. TaoToken 前置准备与 MCP 连接器 endpoint 规划在动手配连接器之前先把「AI 请求往哪发」这件事定下来。很多 401 报错和 local proxy failed 的根因其实不是 MCP 配置写错了而是 endpoint 和 Key 没对齐。这里统一把模型请求的出口指向 TaoToken它的 API 地址是https://taotoken.net/api官网在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你需要先拿到两样东西一个 API Key以及确认要用的 Model ID。Key 在控制台的 API Keys 页面创建地址是https://taotoken.net/console/api-keys。创建时建议按用途命名比如pycharm-agent方便后面在多个连接器里区分。Model ID 则根据你的任务选纯对话和轻量 Agent 用通用对话模型即可长期编码或跑 Agent 工作流建议走 Coding Plan地址https://taotoken.net/coding-plan。这里有个容易踩的坑MCP 连接器配置里的url字段和模型请求的base_url是两码事。前者指向本地 MCP 服务的 SSE 或 stdio 入口比如http://127.0.0.1:64462/sse后者才是模型 API 的出口。把这两个搞混就会出现「连接器信任成功但一调用就 401」的诡异现象。我试过把 MCP 的 url 直接填成模型 API 地址结果连接器列表里显示已连接实际执行命令时全部超时。规划上建议分三层层级作用endpoint 指向IDE MCP 连接器执行终端命令、跑运行配置本地127.0.0.1:64462/sse自定义 ComfyUI 执行器启停 ComfyUI、提交工作流本地 stdio解释器脚本模型请求出口AI 推理本身https://taotoken.net/api三层各管各的互不干扰。模型出口统一走 TaoToken 的好处是不管你在 PyCharm 里用哪个 AI 助手只要它支持自定义 base_url就能把请求收敛到同一个 Key 上管理配额和日志也集中。接入文档在https://taotoken.net/doc配置字段的准确写法以文档为准别凭记忆填。准备动作就三步创建 Key、记下 Model ID、确认本地 ComfyUI 的端口默认 8188很多人改成 8189。这三样齐了再进配置环节。3. 可复制的 MCP 连接器与 ComfyUI 执行器配置这一节是全文最该收藏的部分所有片段都能直接复制。先配 PyCharm 侧的 MCP Server打开设置CtrlAltS→ 工具 → MCP Server勾选「启用 MCP Server」。在「客户端自动配置」里找到你用的 AI 助手点自动配置PyCharm 会往对应配置文件里写一条 SSE 连接。强烈建议同时勾上「命令执行」下的免确认模式否则 AI 每跑一条命令都要弹窗等你点Agent 工作流基本没法连续跑。自动配置后AI 助手的 MCP 配置文件里会出现类似这样的条目以通用mcp.json为例{ mcpServers: { pycharm: { url: http://127.0.0.1:64462/sse, disabled: false } } }注意url里的端口是 PyCharm 动态分配的以你本机实际生成的为准别照抄 64462。配完进 AI 助手的「连接器管理」找到pycharm条目点「信任」信任后能看到它暴露的工具数。接下来是重点自定义 ComfyUI 执行器。PyCharm MCP 有个架构性限制——它每次执行命令都起一个全新 shell不继承你终端里激活的.venv。所以python --version拿到的是系统 Python不是虚拟环境里的。解决办法是写一个天生跑在.venv里的 stdio MCP 服务器。用 Python 的mcpSDK零额外依赖。先建目录结构假设 ComfyUI 根目录是H:/PythonProjects3/Win_ComfyUIWin_ComfyUI/ ├── .venv/Scripts/python.exe ├── comfyui_mcp_runner/ │ └── server.py └── models/...server.py的核心骨架如下用.venv的解释器启动天然继承整个虚拟环境from pathlib import Path from mcp.server import Server from mcp.server.stdio import stdio_server import httpx COMFYUI_DIR Path(__file__).resolve().parent.parent VENV_PYTHON COMFYUI_DIR / .venv / Scripts / python.exe server Server(comfyui-runner) def _get_comfyui_port() - int: for port in (8188, 8189, 8190): try: r httpx.get(fhttp://127.0.0.1:{port}/system_stats, timeout2) if r.status_code 200: return port except Exception: continue raise RuntimeError(ComfyUI not reachable on 8188/8189/8190) server.call_tool() async def call_tool(name: str, arguments: dict): if name comfyui_status: port _get_comfyui_port() r httpx.get(fhttp://127.0.0.1:{port}/system_stats, timeout5) return {status: running, port: port, raw: r.json()} elif name submit_workflow: port _get_comfyui_port() payload {prompt: arguments[workflow_json]} r httpx.post(fhttp://127.0.0.1:{port}/prompt, jsonpayload, timeout30) return {status: queued, prompt_id: r.json().get(prompt_id)} # 其余工具省略按同样模式扩展 async def main(): async with stdio_server() as (read_stream, write_stream): await server.run(read_stream, write_stream, server.create_initialization_options()) if __name__ __main__: import asyncio asyncio.run(main())然后在 AI 助手的mcp.json里注册这个 stdio 连接器{ mcpServers: { 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是脚本绝对路径。AI 助手会启动「解释器 脚本」子进程通过 stdio 走 JSON-RPC不存在端口冲突进程生命周期由助手托管。这套配置里 Base URL、Key、Model ID 三件套要写全——Base URL 用https://taotoken.net/apiKey 用你在控制台建的Model ID 按任务选。三件套缺一个后面验证必挂。4. 验证请求从连通性测试到跑通一张图配置写完不能直接信得一步步验证。顺序是先验 MCP 连接器本身通不通再验模型出口通不通最后跑一个端到端任务。第一步验证 PyCharm MCP 连接器。在 AI 助手对话里让它执行一条无害命令比如查 Python 版本。注意必须用.venv的绝对路径因为前面说过它不继承虚拟环境H:/PythonProjects3/Win_ComfyUI/.venv/Scripts/python.exe --version正常返回Python 3.12.x就说明 IDE 连接器通了。如果这里报local proxy failed先别急着改配置往下看第五节。第二步验证自定义执行器。让 AI 调用comfyui_status它应该自动扫描 8188/8189/8190 并返回运行中的端口和版本。这一步通了说明 stdio 连接器和 ComfyUI 的 REST API 都活着。第三步验证模型出口。这一步是很多人漏掉的——MCP 连接器通了不代表模型请求能出去。用一个最小请求打 TaoToken 的 APIcurl.exe -X POST https://taotoken.net/api/v1/chat/completions ^ -H Authorization: Bearer YOUR_API_KEY ^ -H Content-Type: application/json ^ -d {\model\:\YOUR_MODEL_ID\,\messages\:[{\role\:\user\,\content\:\ping\}]}返回里带choices字段就说明模型出口正常。如果返回 401是 Key 的问题如果返回reading choices相关错误是响应结构没解析对通常是 Model ID 填错或 endpoint 少了/v1。第四步端到端跑一张图。让 AI 通过comfyui-runner提交一个最小工作流。工作流 JSON 里节点结构要正确比如 Z-Image Turbo 的采样器节点{ 6: { class_type: KSampler, inputs: { model: [1, 0], positive: [4, 0], negative: [4, 0], latent_image: [5, 0], seed: 42, steps: 4, cfg: 1.0, sampler_name: euler, scheduler: normal } } }提交后执行器会轮询/history完成后返回图片文件名。看到zimage_cat_00001_.png这类输出整条链路就算跑通了。实测下来euler normal, 4 steps是相对稳的组合出图约 20 秒左右。5. 本篇常见报错排查401、local proxy failed、reading choices这一节按真实报错对照遇到问题直接查表。401 Unauthorized。九成是 Key 的问题。检查三处Key 是否复制完整前后别带空格、请求头是不是Authorization: Bearer xxx、Key 有没有被禁用或超额。如果 MCP 连接器信任成功但一调用模型就 401说明你把 MCP 的本地 url 和模型 base_url 搞混了回到第二节重新对齐。local proxy failed。这个报错通常出现在 PyCharm MCP 连接器侧含义是 AI 助手连不上本地 SSE 端口。排查顺序PyCharm 是否还开着关掉 IDEMCP Server 就没了、端口是否被防火墙拦、url里的端口是否和 PyCharm 实际分配的一致。如果 PyCharm 重启过端口可能变了重新自动配置一次即可。reading choices 报错。这是响应解析失败典型原因是 Model ID 不存在或 endpoint 路径不对。确认 base_url 是https://taotoken.net/api且请求路径带/v1/chat/completions。另外有些助手要求 base_url 结尾不带斜杠多一个/也可能触发解析异常。OAuth 相关报错。部分 AI 助手在首次连接 MCP 时会走 OAuth 授权流程如果卡在授权页检查助手版本是否支持 MCP以及本地回调端口是否被占。这类问题优先看助手自己的连接器日志。端口占用 EADDRINUSE。自定义执行器用 stdio 不会有这问题但如果你之前用过 SSE 模式的 MCP残留进程会占端口。用 PyCharm MCP 自己杀自己taskkill /F /PID 占用进程PIDPID 通过netstat -ano | findstr :9100查。转义地狱。Windows CMD 里嵌套引号是噩梦curl的 JSON body 多重转义后经常语法错误。解决办法是别在命令行里硬拼把复杂请求写成.py脚本再执行。这也是自定义执行器提供execute_python工具的原因。排障时记住一个原则先分层定位再改配置。MCP 连接器、模型出口、ComfyUI 服务是三层哪层报错改哪层别一上来就推翻全部重配。6. 把 endpoint 收敛到 TaoToken 后的 Agent 工作流建议链路跑通之后真正提升效率的是工作流设计。把模型出口统一到 TaoToken 之后你可以让同一个 AI 助手在一条对话里完成「改代码 → 重启服务 → 跑图 → 看结果」的闭环不用在多个工具间来回切。几个实操建议。第一连接器按任务分工IDE 操作走 PyCharm MCPComfyUI 运维走自定义执行器两者同时开让 AI 自己选。第二复杂命令一律写脚本别在对话里拼转义。第三模型选择按场景切日常问答用轻量模型长时间编码或 Agent 任务走 Coding Plan地址https://taotoken.net/coding-plan配额和稳定性更适合连续跑。第四Key 按用途分开建方便在控制台https://taotoken.net/console/api-keys里看每个连接器的调用量。如果你还没配好 Key先去https://taotoken.net/api-keys建一个再对照接入文档https://taotoken.net/doc把 base_url 和 Model ID 填准。想先试试模型对话效果可以直接在https://taotoken.net/model-chat里发一条消息验证出口通不通再回到 PyCharm 配连接器。最后提醒一句MCP 连接器是给 AI 开权限别把生产库或敏感目录直接暴露给执行器。自定义执行器的工具范围要收窄只开放 ComfyUI 相关的启停、提交、读输出别做成万能 shell。这样即使 AI 判断失误影响面也可控。 
长河君 · 2026/10/18 12:43:17 · 阅读 1.2k AI Agent + PyCharm MCP 连接器配置与自定义 ComfyUI 执行器实战：把 endpoint 改到 TaoToken
1. 为什么要在 PyCharm 里给 AI Agent 接 MCP 连接器如果你正在用 AI Agent 辅助 ComfyUI 开发大概率遇到过这种尴尬AI 能帮你改代码、写工作流 JSON但一到「重启 ComfyUI 服务」「查一下 8189 端口谁占着」「把这张图跑出来」就歇菜了。原因不复杂——AI 助手默认只能读写文件进不了你 IDE 的终端环境更碰不到你那个已经激活了.venv的 Python 解释器。MCPModel Context Protocol就是来解决这件事的。它是一套让外部 AI 工具通过标准协议调用 IDE 或本地服务能力的连接器规范。PyCharm 2025.2 之后内置了 MCP Server你可以把它理解成「给 AI 开了一扇进 IDE 的门」AI 通过这扇门能执行终端命令、跑运行配置、打开和搜索文件。再配合一个自定义的 ComfyUI 执行器 MCPAI 就能在同一个对话里既改代码又跑图。这篇要交付的是一条完整链路在 PyCharm 里启用 MCP Server → 配置连接器 → 写一个跑在 ComfyUI.venv里的自定义执行器 → 把 endpoint 改到 TaoToken 做连通性验证 → 排掉 401 和 local proxy failed 这两类高频报错。适合已经在用 ComfyUI、想让 AI Agent 真正动手干活的人。全程 Windows 11 PyCharm 2025.2 ComfyUI v0.27 Python 3.12 实测命令可以直接抄。先说清楚一个关键认知PyCharm 自带的 MCP 和自定义 ComfyUI 执行器不是二选一而是互补。前者管 IDE 操作编辑器、运行配置、文件搜索后者管 ComfyUI 运维启停、提交工作流、轮询出图。两个都开AI 会按任务自己挑。下面从环境准备开始。2. TaoToken 前置准备与 MCP 连接器 endpoint 规划在动手配连接器之前先把「AI 请求往哪发」这件事定下来。很多 401 报错和 local proxy failed 的根因其实不是 MCP 配置写错了而是 endpoint 和 Key 没对齐。这里统一把模型请求的出口指向 TaoToken它的 API 地址是https://taotoken.net/api官网在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你需要先拿到两样东西一个 API Key以及确认要用的 Model ID。Key 在控制台的 API Keys 页面创建地址是https://taotoken.net/console/api-keys。创建时建议按用途命名比如pycharm-agent方便后面在多个连接器里区分。Model ID 则根据你的任务选纯对话和轻量 Agent 用通用对话模型即可长期编码或跑 Agent 工作流建议走 Coding Plan地址https://taotoken.net/coding-plan。这里有个容易踩的坑MCP 连接器配置里的url字段和模型请求的base_url是两码事。前者指向本地 MCP 服务的 SSE 或 stdio 入口比如http://127.0.0.1:64462/sse后者才是模型 API 的出口。把这两个搞混就会出现「连接器信任成功但一调用就 401」的诡异现象。我试过把 MCP 的 url 直接填成模型 API 地址结果连接器列表里显示已连接实际执行命令时全部超时。规划上建议分三层层级作用endpoint 指向IDE MCP 连接器执行终端命令、跑运行配置本地127.0.0.1:64462/sse自定义 ComfyUI 执行器启停 ComfyUI、提交工作流本地 stdio解释器脚本模型请求出口AI 推理本身https://taotoken.net/api三层各管各的互不干扰。模型出口统一走 TaoToken 的好处是不管你在 PyCharm 里用哪个 AI 助手只要它支持自定义 base_url就能把请求收敛到同一个 Key 上管理配额和日志也集中。接入文档在https://taotoken.net/doc配置字段的准确写法以文档为准别凭记忆填。准备动作就三步创建 Key、记下 Model ID、确认本地 ComfyUI 的端口默认 8188很多人改成 8189。这三样齐了再进配置环节。3. 可复制的 MCP 连接器与 ComfyUI 执行器配置这一节是全文最该收藏的部分所有片段都能直接复制。先配 PyCharm 侧的 MCP Server打开设置CtrlAltS→ 工具 → MCP Server勾选「启用 MCP Server」。在「客户端自动配置」里找到你用的 AI 助手点自动配置PyCharm 会往对应配置文件里写一条 SSE 连接。强烈建议同时勾上「命令执行」下的免确认模式否则 AI 每跑一条命令都要弹窗等你点Agent 工作流基本没法连续跑。自动配置后AI 助手的 MCP 配置文件里会出现类似这样的条目以通用mcp.json为例{ mcpServers: { pycharm: { url: http://127.0.0.1:64462/sse, disabled: false } } }注意url里的端口是 PyCharm 动态分配的以你本机实际生成的为准别照抄 64462。配完进 AI 助手的「连接器管理」找到pycharm条目点「信任」信任后能看到它暴露的工具数。接下来是重点自定义 ComfyUI 执行器。PyCharm MCP 有个架构性限制——它每次执行命令都起一个全新 shell不继承你终端里激活的.venv。所以python --version拿到的是系统 Python不是虚拟环境里的。解决办法是写一个天生跑在.venv里的 stdio MCP 服务器。用 Python 的mcpSDK零额外依赖。先建目录结构假设 ComfyUI 根目录是H:/PythonProjects3/Win_ComfyUIWin_ComfyUI/ ├── .venv/Scripts/python.exe ├── comfyui_mcp_runner/ │ └── server.py └── models/...server.py的核心骨架如下用.venv的解释器启动天然继承整个虚拟环境from pathlib import Path from mcp.server import Server from mcp.server.stdio import stdio_server import httpx COMFYUI_DIR Path(__file__).resolve().parent.parent VENV_PYTHON COMFYUI_DIR / .venv / Scripts / python.exe server Server(comfyui-runner) def _get_comfyui_port() - int: for port in (8188, 8189, 8190): try: r httpx.get(fhttp://127.0.0.1:{port}/system_stats, timeout2) if r.status_code 200: return port except Exception: continue raise RuntimeError(ComfyUI not reachable on 8188/8189/8190) server.call_tool() async def call_tool(name: str, arguments: dict): if name comfyui_status: port _get_comfyui_port() r httpx.get(fhttp://127.0.0.1:{port}/system_stats, timeout5) return {status: running, port: port, raw: r.json()} elif name submit_workflow: port _get_comfyui_port() payload {prompt: arguments[workflow_json]} r httpx.post(fhttp://127.0.0.1:{port}/prompt, jsonpayload, timeout30) return {status: queued, prompt_id: r.json().get(prompt_id)} # 其余工具省略按同样模式扩展 async def main(): async with stdio_server() as (read_stream, write_stream): await server.run(read_stream, write_stream, server.create_initialization_options()) if __name__ __main__: import asyncio asyncio.run(main())然后在 AI 助手的mcp.json里注册这个 stdio 连接器{ mcpServers: { 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是脚本绝对路径。AI 助手会启动「解释器 脚本」子进程通过 stdio 走 JSON-RPC不存在端口冲突进程生命周期由助手托管。这套配置里 Base URL、Key、Model ID 三件套要写全——Base URL 用https://taotoken.net/apiKey 用你在控制台建的Model ID 按任务选。三件套缺一个后面验证必挂。4. 验证请求从连通性测试到跑通一张图配置写完不能直接信得一步步验证。顺序是先验 MCP 连接器本身通不通再验模型出口通不通最后跑一个端到端任务。第一步验证 PyCharm MCP 连接器。在 AI 助手对话里让它执行一条无害命令比如查 Python 版本。注意必须用.venv的绝对路径因为前面说过它不继承虚拟环境H:/PythonProjects3/Win_ComfyUI/.venv/Scripts/python.exe --version正常返回Python 3.12.x就说明 IDE 连接器通了。如果这里报local proxy failed先别急着改配置往下看第五节。第二步验证自定义执行器。让 AI 调用comfyui_status它应该自动扫描 8188/8189/8190 并返回运行中的端口和版本。这一步通了说明 stdio 连接器和 ComfyUI 的 REST API 都活着。第三步验证模型出口。这一步是很多人漏掉的——MCP 连接器通了不代表模型请求能出去。用一个最小请求打 TaoToken 的 APIcurl.exe -X POST https://taotoken.net/api/v1/chat/completions ^ -H Authorization: Bearer YOUR_API_KEY ^ -H Content-Type: application/json ^ -d {\model\:\YOUR_MODEL_ID\,\messages\:[{\role\:\user\,\content\:\ping\}]}返回里带choices字段就说明模型出口正常。如果返回 401是 Key 的问题如果返回reading choices相关错误是响应结构没解析对通常是 Model ID 填错或 endpoint 少了/v1。第四步端到端跑一张图。让 AI 通过comfyui-runner提交一个最小工作流。工作流 JSON 里节点结构要正确比如 Z-Image Turbo 的采样器节点{ 6: { class_type: KSampler, inputs: { model: [1, 0], positive: [4, 0], negative: [4, 0], latent_image: [5, 0], seed: 42, steps: 4, cfg: 1.0, sampler_name: euler, scheduler: normal } } }提交后执行器会轮询/history完成后返回图片文件名。看到zimage_cat_00001_.png这类输出整条链路就算跑通了。实测下来euler normal, 4 steps是相对稳的组合出图约 20 秒左右。5. 本篇常见报错排查401、local proxy failed、reading choices这一节按真实报错对照遇到问题直接查表。401 Unauthorized。九成是 Key 的问题。检查三处Key 是否复制完整前后别带空格、请求头是不是Authorization: Bearer xxx、Key 有没有被禁用或超额。如果 MCP 连接器信任成功但一调用模型就 401说明你把 MCP 的本地 url 和模型 base_url 搞混了回到第二节重新对齐。local proxy failed。这个报错通常出现在 PyCharm MCP 连接器侧含义是 AI 助手连不上本地 SSE 端口。排查顺序PyCharm 是否还开着关掉 IDEMCP Server 就没了、端口是否被防火墙拦、url里的端口是否和 PyCharm 实际分配的一致。如果 PyCharm 重启过端口可能变了重新自动配置一次即可。reading choices 报错。这是响应解析失败典型原因是 Model ID 不存在或 endpoint 路径不对。确认 base_url 是https://taotoken.net/api且请求路径带/v1/chat/completions。另外有些助手要求 base_url 结尾不带斜杠多一个/也可能触发解析异常。OAuth 相关报错。部分 AI 助手在首次连接 MCP 时会走 OAuth 授权流程如果卡在授权页检查助手版本是否支持 MCP以及本地回调端口是否被占。这类问题优先看助手自己的连接器日志。端口占用 EADDRINUSE。自定义执行器用 stdio 不会有这问题但如果你之前用过 SSE 模式的 MCP残留进程会占端口。用 PyCharm MCP 自己杀自己taskkill /F /PID 占用进程PIDPID 通过netstat -ano | findstr :9100查。转义地狱。Windows CMD 里嵌套引号是噩梦curl的 JSON body 多重转义后经常语法错误。解决办法是别在命令行里硬拼把复杂请求写成.py脚本再执行。这也是自定义执行器提供execute_python工具的原因。排障时记住一个原则先分层定位再改配置。MCP 连接器、模型出口、ComfyUI 服务是三层哪层报错改哪层别一上来就推翻全部重配。6. 把 endpoint 收敛到 TaoToken 后的 Agent 工作流建议链路跑通之后真正提升效率的是工作流设计。把模型出口统一到 TaoToken 之后你可以让同一个 AI 助手在一条对话里完成「改代码 → 重启服务 → 跑图 → 看结果」的闭环不用在多个工具间来回切。几个实操建议。第一连接器按任务分工IDE 操作走 PyCharm MCPComfyUI 运维走自定义执行器两者同时开让 AI 自己选。第二复杂命令一律写脚本别在对话里拼转义。第三模型选择按场景切日常问答用轻量模型长时间编码或 Agent 任务走 Coding Plan地址https://taotoken.net/coding-plan配额和稳定性更适合连续跑。第四Key 按用途分开建方便在控制台https://taotoken.net/console/api-keys里看每个连接器的调用量。如果你还没配好 Key先去https://taotoken.net/api-keys建一个再对照接入文档https://taotoken.net/doc把 base_url 和 Model ID 填准。想先试试模型对话效果可以直接在https://taotoken.net/model-chat里发一条消息验证出口通不通再回到 PyCharm 配连接器。最后提醒一句MCP 连接器是给 AI 开权限别把生产库或敏感目录直接暴露给执行器。自定义执行器的工具范围要收窄只开放 ComfyUI 相关的启停、提交、读输出别做成万能 shell。这样即使 AI 判断失误影响面也可控。