Comfy Agent 在 ComfyUI 里没反应，先别急着重装。按“入口加载 → 控制台报错 → 最小工作流 → 配置层级”的顺序走一遍，通常能判断问题卡在哪一层：是入口根本没渲染出来，是前端资源加载失败，还是全局开关被工作流级或会话级配置覆盖了。

判断方向：ComfyUI 页面里看不到 Agent 入口，问题多在加载层，先确认扩展是否被识别；入口可见但点击无响应，重点看前端报错和后端最后几行日志；入口正常、只有某个工作流不触发，多半是工作流或会话级配置覆盖了全局设置。按层排除比反复重启有效，但具体字段名和开关位置要以你本地插件的实际配置为准。

确认 Comfy Agent 入口是否加载

这一步只解决一件事：Agent 的入口有没有出现在页面上。入口没出现，后面查配置基本是白费。

• 记录页面可见入口：菜单项、侧边栏按钮、节点右键菜单里的 Agent 相关项，分别记下“存在 / 不存在”。
• 记录加载状态：入口存在时，是灰色不可点、一直转圈，还是可点击但无反应。
• 打开浏览器开发者工具的 Network 面板，刷新页面，筛选 JS / CSS 请求，看有没有 404 或加载失败的资源。
• 确认扩展目录是否被当前 ComfyUI 实例识别，例如在自定义节点列表或启动日志里能否看到该扩展。

查看浏览器控制台和 ComfyUI 控制台报错

无响应的第一现场是报错时间点。前端和后端要分开看，并且尽量把时间对齐。

1. 浏览器 Console：清空后刷新页面，记录第一条错误和它的时间；重点关注找不到模块、变量未定义、接口 4xx / 5xx。
2. 浏览器 Network：点击 Agent 入口的那一刻，看是否发出了请求、请求是否返回、返回体是什么。
3. ComfyUI 后端控制台：记录无响应时最后几行输出，包括启动日志、插件加载日志和异常堆栈。
4. 把前端报错时间和后端最后一行输出时间并排记下来，判断是前端先挂，还是后端压根没收到请求。

常见分叉是：前端有报错、后端没有对应请求，问题在前端脚本；后端收到请求但抛异常，问题在插件服务或配置解析环节。保留时间点是为了后面能复现，不要只看一次就下判断。

用最小工作流测试是否触发 Agent

目的是区分“全局没反应”和“特定工作流不触发”。做法是绕开一切业务节点。

1. 新建一个最简工作流：只有一个输入节点和一个输出节点，不加自定义节点、不加条件分支。
2. 保存并运行，观察 Agent 是否产生会话消息、日志行或状态变化。
3. 再切回原本出问题的工作流，同样操作一次，对比两次结果。

如果最简工作流也不触发，说明问题在全局配置或插件本身；如果最简工作流能触发，说明是原工作流的节点、作用域或命名命中了某个限制条件。记录要落到“哪次运行、什么时间、有无会话消息”，而不是凭印象。这里的判断只需要页面行为和日志佐证，不需要额外工具。

检查配置项层级：全局、工作流、会话

Agent 类插件的开关通常分布在多层，后一层可能覆盖前一层。先列出你实际能看到的配置位置，再判断覆盖关系。

只记录真实存在的字段和开关，不要凭记忆补字段名。判断覆盖关系时，先确认全局开关是开的，再看工作流级有没有把它关掉，最后看会话是否绑定到当前工作流。三层里任何一层把 Agent 关掉，表现都会是“点了没反应”。

给出通用配置字段占位和验证步骤

下面是一份占位配置，字段名仅用于描述排查思路，不代表你所用插件的真实字段；实际名称请以本地配置文件为准，找不到对应项不要硬改。

{
  "agent_enabled": true,
  "workflow_scope": "*",
  "session_auto_start": true,
  "log_level": "debug"
}

逐项验证的做法：

1. 把 agent_enabled 置为 true 并保存，重启或刷新 ComfyUI，看入口状态是否随之变化。
2. 把 workflow_scope 从具体值改成通配形式，再跑一次最小工作流，观察是否产生会话消息。
3. 把 log_level 调到 debug，重复触发一次，在后端控制台里找 Agent 相关的日志行。
4. 如果改完完全没有日志变化，说明配置文件没被加载，回到第二步查后端启动日志里的插件加载记录。

每改一项只验证一项，避免多改叠加后无法判断是哪一项生效。修改配置属于本地环境操作，若这套 ComfyUI 对外提供服务，建议先在可回退的环境里确认行为，再同步到正式使用的实例。若以上四步都验证过仍无响应，问题大概率不在配置层，需要回到插件版本与 ComfyUI 版本是否匹配这条线继续查。