AI Agent 本地 ComfyUI 无头模式实战关闭 IDE 后 AI 独立重启并完成图文生成当 PyCharm 关闭、进程全部杀死、所有 IDE 依赖消失 —— AI 助手还能否独立启动 ComfyUI 并完成出图本文记录一次完整的无头模式测试以及后续修复comfyui_restart超时问题的全过程Comfy MCP 公测把 Claude、Cursor、CodeX、Hermes 和 WorkBuddy 变成你的创意技术专家Comfy Cloud MCP Server 抢先体验申请图文教程QClaw 配置 Comfy Cloud MCP只需简单几步WorkBuddy 接入 Comfy Cloud MCP 完整实录从 DNS 污染到 31 个工具全部启用WorkBuddy 本地 Comfy MCP 实战用自然语言调生成你的第一张 AI 图片WorkBuddy 连接本地 ComfyUI从零到出图的保姆级教程WorkBuddy 本地 ComfyUI Wan2.1 文生视频实战从连续报错到成功出片的完整踩坑记录WorkBuddy 本地 ComfyUI 完全使用手册从出图到视频生成WorkBuddy 本地 ComfyUI MCP免订阅费的自建方案ComfyUI MCP 115 工具全景解析你的 AI Agent 到底能做什么AI Agent PyCharm MCP 连接器配置与自定义 ComfyUI 执行器实战一、什么是无头模式在常规 ComfyUI 工作流中你需要打开 PyCharm / VS Code或终端激活.venv虚拟环境执行python main.py启动 ComfyUI打开浏览器访问 http://127.0.0.1:8188 拖拽节点无头模式Headless Mode指的是ComfyUI 只运行 API 服务不需要浏览器界面AI 助手通过 REST API 提交工作流 JSON轮询结果不依赖任何 IDEPyCharm / VS Code保持运行所有操作通过 MCP 连接器或脚本完成这在以下场景非常有用场景说明服务器部署无 GUI 的 Linux 服务器上运行 ComfyUI自动化流水线CI/CD 中自动生成图片/视频远程调用AI 助手独立操作不需要人工值守资源优化关闭 IDE 释放内存让 GPU 全力用于推理二、测试背景三层 MCP 连接器经过前期的配置详见文章 10我有三个 MCP 连接器┌─────────────────────────────────────────────────────────┐ │ WorkBuddy (AI 助手) │ ├───────────┬───────────────┬───────────────────────────────┤ │ comfyui- │ pycharm │ comfyui-runner │ │ local │ (SSE) │ (stdio) │ │ │ │ │ │ npx 进程 │ PyCharm 内置 │ 自定义 Python MCP 服务器 │ │ :9100 │ :64462 │ WorkBuddy 直接 spawn │ │ │ │ │ │ 115 工具 │ 48 子命令 │ 9 工具 │ ├───────────┼───────────────┼───────────────────────────────┤ │ 依赖 npx │ 依赖 PyCharm │ 独立运行在 .venv 中 │ │ 进程存活 │ 进程存活 │ 不依赖任何外部进程 │ └───────────┴───────────────┴───────────────────────────────┘关键问题如果关闭 PyCharm、杀死所有 npx 进程哪个连接器还能工作答案只有comfyui-runner。它由 WorkBuddy 直接 spawn运行在 ComfyUI 的.venv中与 PyCharm 和 npx 完全无关。三、测试准备清空一切3.1 关闭 PyCharm直接关闭 PyCharm 窗口。pycharmMCP 连接器立刻显示失败。3.2 杀死 MCP 服务器进程bash# 查找占用 9100 端口的进程 netstat -ano | findstr :9100 # 杀死 taskkill /F /PID PIDcomfyui-local连接器也失败了。3.3 杀死 ComfyUI 进程bash# 查找占用 8189 端口的进程 netstat -ano | findstr :8189 # 杀死 taskkill /F /PID PIDComfyUI 服务停止。3.4 连接器状态确认连接器状态原因comfyui-local❌ 失败npx 进程被杀pycharm❌ 失败PyCharm 已关闭comfyui-runner✅ 在线9/9 工具WorkBuddy 直接 spawn这就是comfyui-runner的价值在任何情况下只要 WorkBuddy 还活着它就在。四、重启 ComfyUI4.1 首次尝试comfyui_restart 工具调用comfyui_restart工具工具: comfyui_restart 参数: {}结果MCP 超时60 秒。原因分析当时的comfyui_restart实现有一个致命问题 —— 它在启动 ComfyUI 后会轮询等待端口就绪30 次循环 × 2 秒 60 秒而 MCP 协议本身有 60 秒的超时限制。加载 320 个自定义节点需要的时间经常超过 60 秒导致调用永远超时。4.2 替代方案Bash 后台启动既然 MCP 工具超时改用 Bash 工具直接后台启动bashcd /h/PythonProjects3/Win_ComfyUI .venv/Scripts/python.exe main.py \ --enable-manager \ --enable-assets \ --enable-triton-backend \ --async-offload \ --enable-dynamic-vram \ --use-pytorch-cross-attention \ --port 8189使用run_in_background: true参数Bash 工具会立即返回 task_id不等待命令完成。4.3 验证启动等待约 30-40 秒后通过comfyui-runner的comfyui_status工具检查json{ status: running, port: 8189, version: 0.27.0, python: 3.12.x, pytorch: 2.7.1cu126 }ComfyUI 成功启动4.4 端口混淆踩坑注意8188 端口可能被Comfyui_Comfly_v2插件错误占用并返回 404。ComfyUI 实际服务在8189端口。comfyui_status工具会自动扫描 8188/8189/8190 三个端口找到真正可用的那个。五、图片生成测试Z-Image Turbo5.1 工作流构建通过 ComfyUI REST API 直接提交工作流 JSONjson{ 1: { class_type: UNETLoader, inputs: { unet_name: z_image_turbo_bf16.safetensors, weight_dtype: default } }, 2: { class_type: CLIPLoader, inputs: { clip_name: qwen_3_4b.safetensors, type: qwen_image } }, 3: { class_type: VAELoader, inputs: { vae_name: z-image-ae.safetensors } }, 4: { class_type: TextEncodeZImageOmni, inputs: { clip: [2, 0], prompt: a cute cat sitting on a wooden table, warm sunlight from window, photorealistic, 4K, auto_resize_images: true, vae: [3, 0] } }, 5: { class_type: EmptyLatentImage, inputs: { width: 1024, height: 1024, batch_size: 1 } }, 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, denoise: 1.0 } }, 7: { class_type: VAEDecode, inputs: { samples: [6, 0], vae: [3, 0] } }, 8: { class_type: SaveImage, inputs: { filename_prefix: headless_zimage_cat, images: [7, 0] } } }5.2 关键踩坑TextEncodeZImageOmni 输出TextEncodeZImageOmni节点只输出 1 个 CONDITIONING索引 0不像 SDXL 的 CLIPTextEncode 那样分别输出 positive 和 negative。所以positive和negative都要接到[4, 0]。在 CFG1.0 的情况下positive 和 negative 同源实际上 negative 不起作用。这是 Z-Image Turbo 蒸馏模型的特性。5.3 API 提交方式pythonimport requests, json, time API http://127.0.0.1:8189 # 提交工作流 r requests.post(f{API}/prompt, json{prompt: workflow}) prompt_id r.json()[prompt_id] # 轮询结果 while True: time.sleep(3) h requests.get(f{API}/history/{prompt_id}).json() status h.get(prompt_id, {}).get(status, {}) if status.get(completed): outputs h[prompt_id][outputs] # 提取图片信息 for node_id, out in outputs.items(): for img in out.get(images, []): print(fGenerated: {img[filename]}) break5.4 测试结果指标结果启动参数--use-pytorch-cross-attention不用 flash attention分辨率1024×1024采样参数euler normal, 4 steps, CFG 1.0, seed 42耗时~113 秒首次加载模型较慢输出文件headless_zimage_cat_00001_.png图片质量猫可识别局部轻微伪影对比之前使用--use-flash-attention时输出全是噪声。去掉后改用--use-pytorch-cross-attention质量大幅改善。六、视频生成测试Wan2.1 t2v6.1 模型链组件模型文件路径扩散模型wan2.1_t2v_1.3B_fp16.safetensorsmodels/diffusion_models/文本编码器umt5_xxl_fp8_e4m3fn_scaled.safetensorsmodels/clip/VAEWan2_1_VAE_bf16.safetensorsmodels/vae/6.2 节点链LoadWanVideoT5TextEncoder → WanVideoModelLoader → WanVideoTextEncode ↓ WanVideoEmptyEmbeds ↓ WanVideoSampler → WanVideoDecode → VHS_VideoCombine6.3 API 提交踩坑通过 REST API 提交时多个节点有必填参数未在 UI 中显示需要手动补全节点缺失参数正确值说明WanVideoModelLoaderload_deviceoffload_device模型加载位置WanVideoSamplerriflex_freq_index0RiFlex 频率索引VHS_VideoCombinepingpongFalse是否正反播放VHS_VideoCombinesave_outputTrue是否保存到 output 目录教训通过 API 提交工作流时不能只看 UI 上的参数必须通过/object_info/node_nameAPI 查询完整的必填参数列表。6.4 测试结果指标结果分辨率480×480帧数17 frames采样参数euler, 10 steps, CFG 3.5, shift 5.0, seed 42耗时~24 秒输出文件headless_wan_cat_00001.mp4视频质量低分辨率短视频猫的轮廓可识别注意VHS_VideoCombine 节点的输出格式与 SaveImage 不同。submit_workflow工具返回的files: []不代表失败 —— 视频文件已经落盘到 output 目录只是解析逻辑没有处理 VHS 的gifs输出格式。用list_outputs工具可以确认文件存在。七、修复 comfyui_restartDETACHED_PROCESS 方案7.1 问题根因原始实现的流程1. 停止 ComfyUI~10s 2. sleep(2) 3. 通过 _execute_python 启动子进程~5s 4. 轮询端口 30 次 × 2s 60s等待就绪 ─────────────────────────────────── 总计可能 77s超过 MCP 60s 超时7.2 修复方案核心思路启动后立即返回不等端口就绪。pythonasync def _comfyui_restart(args: dict) - list[TextContent]: extra args.get(extra_args, ) # 1. 停止现有 ComfyUI stop_result await _comfyui_stop({}) await asyncio.sleep(2) # 2. 构建启动命令列表形式避免 shell 转义问题 base_args [ --enable-manager, --enable-assets, --enable-triton-backend, --async-offload, --enable-dynamic-vram, --use-pytorch-cross-attention, --port, 8189 ] start_cmd [str(VENV_PYTHON), main.py] base_args if extra: start_cmd.extend(shlex.split(extra)) # 3. 日志文件覆盖写入 log_file COMFYUI_DIR / comfyui_runner.log # 4. 完全脱离父进程启动 creation_flags 0 if os.name nt: creation_flags (subprocess.DETACHED_PROCESS | subprocess.CREATE_NEW_PROCESS_GROUP) with open(log_file, w, encodingutf-8) as lf: proc subprocess.Popen( start_cmd, cwdstr(COMFYUI_DIR), stdinsubprocess.DEVNULL, stdoutlf, stderrsubprocess.STDOUT, creationflagscreation_flags, env{**os.environ, PYTHONUTF8: 1}, ) # 5. 立即返回不等待端口就绪 return { status: starting, pid: proc.pid, command: .join(start_cmd), log_file: str(log_file), message: Use comfyui_status to check readiness. }7.3 关键改进点改进旧实现新实现启动方式_execute_python→ 子进程 → 子子进程直接subprocess.Popen进程脱离CREATE_NEW_PROCESS_GROUPDETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP日志DEVNULL丢弃写入comfyui_runner.log可排查等待就绪轮询 60s超时立即返回调用方自行轮询命令格式shell 字符串转义地狱列表无转义问题总耗时77s超时~12s停止启动7.4 Windows 进程脱离原理DETACHED_PROCESS (0x00000008) → 子进程不继承父进程的控制台 → 即使父进程退出子进程继续运行 CREATE_NEW_PROCESS_GROUP (0x00000200) → 创建新的进程组 → CtrlC 信号不会传递到子进程 → 适合后台服务两个标志组合使用确保 ComfyUI 进程完全独立于 MCP 服务器进程。7.5 使用方式修复后的调用流程步骤 1: comfyui_restart() → 立即返回 {status: starting, pid: 12345} 步骤 2: 等待 30-40 秒让 ComfyUI 加载 320 个节点 步骤 3: comfyui_status() → 返回 {status: running, port: 8189, version: 0.27.0} 如果 status 仍为 not_running查看日志 read_file(pathcomfyui_runner.log)八、无头模式完整工作流以下是修复后AI 助手在无头模式下的完整操作链路用户: 帮我重启 ComfyUI 并生成一张猫的图片 AI 助手: 1. comfyui_restart() → {status: starting, pid: 12345} 2. (等待 30 秒) 3. comfyui_status() → {status: running, port: 8189} ✓ 4. submit_workflow(workflow_json..., timeout120) → {status: completed, images: [{filename: cat_00001_.png}]} 5. list_outputs(count5) → 确认文件存在 全程无需打开浏览器无需 PyCharm无需人工干预九、总结无头模式的能力边界能做到的能力实现方式启动 ComfyUIcomfyui_restartDETACHED_PROCESS停止 ComfyUIcomfyui_stop端口扫描 taskkill检查状态comfyui_statusREST API 探测提交工作流submit_workflowPOST /prompt 轮询 /history查看输出list_outputs扫描 output 目录读取日志read_file读取 comfyui_runner.log执行任意 Pythonexecute_python在 .venv 中运行执行 Shell 命令execute_shell自动替换 python 路径做不到的限制原因打开浏览器界面无头模式不启动 GUI拖拽节点编辑工作流需要浏览器前端安装自定义节点外科手术式安装需要人工审查依赖安全准则启动 PyCharmGUI 应用沙箱无法启动最佳实践首次启动用 Bash 后台如果comfyui_restart的 MCP 连接器刚重启过用 Bashrun_in_background更可靠后续重启用 comfyui_restart修复后的版本已经稳定支持 DETACHED_PROCESS始终检查状态启动后用comfyui_status确认端口就绪再提交工作流日志是最后防线如果启动失败read_file(pathcomfyui_runner.log)查看 ComfyUI 的完整启动日志工作流参数要完整通过 API 提交时用/object_info/node查询所有必填参数不要只看 UI附录启动参数说明bashpython main.py \ --enable-manager \ # 启用 ComfyUI Manager --enable-assets \ # 启用 Asset Seeder 分布式模型分发 --enable-triton-backend \ # 启用 comfy-kitchen triton 后端 --async-offload \ # 异步模型卸载节省显存 --enable-dynamic-vram \ # 动态 VRAM 管理 --use-pytorch-cross-attention \ # 使用 PyTorch 原生注意力兼容性最好 --port 8189 # 指定端口避免 8188 冲突不要用--use-flash-attention与 Z-Image Turbo 等模型不兼容会导致输出全噪声。本文为 ComfyCloudMCP 系列第 11 篇文章上一篇PyCharm MCP 连接器配置与自定义 ComfyUI 执行器实战环境Windows 11 ComfyUI v0.27.0 Python 3.12 PyTorch 2.7.1cu126 RTX 3090