Comfy Agent 接进 ComfyUI 之后，最该先弄清楚的不是它能聊什么，而是它在一次执行里究竟动了哪一步。判断方式不复杂：准备一条只包含输入、处理、输出三个节点的最小工作流，跑一次，把运行前后的节点参数、控制台输出、会话里出现的动作描述逐项对照。如果参数和执行路径都没变，它当前更接近对话辅助；如果参数被改写、节点被替换或新增，就要先把接管范围写清楚，再考虑往正式工作流里扩。
先做接管边界判断，再决定要不要放进正式工作流。适用场景：刚接入 Comfy Agent、工作流还简单的时候。操作动作：记录入口与开关状态，用三节点最小工作流跑一次，对照参数、控制台与会话记录。验证方式：同一份工作流文件用同样输入连跑两次，看参数与输出是否一致。风险边界：不要在有真实产出的工作流上做首次验证，未确认接管范围前，先不要让它保存或覆盖原工作流文件。
在 ComfyUI 界面里定位 Comfy Agent 入口与开关
这一步只做记录，不做推断。打开 ComfyUI 页面后，按你实际看到的可见位置记录 Comfy Agent 从哪里启动，例如顶部工具栏按钮、侧边面板、设置项页签或独立浮层；入口名称以页面上显示的文字为准，不要凭记忆补一个菜单名。同时确认它是否默认开启：刷新页面后开关状态是否保持，是否需要手动启用。
未登录或后端未连接时，入口通常会有自己的提示形态，可能是灰置按钮、提示文案或点击后弹出连接失败的反馈。把这一条也记下来，因为后面判断“没动作”时，要排除掉根本没连上的情况。可以先用一张表把页面行为固定下来：
- 入口位置（页面上的可见区域与文字）
- 初始开关状态（默认开 / 默认关 / 刷新后是否保持）
- 未登录或未连接时的页面提示原文
- 入口点击后弹出的内容类型（面板 / 对话框 / 无响应）
搭一条只有输入处理输出三个节点的最小工作流
工作流越短，接管痕迹越明显。节点按顺序连成一条直线，不要加分支、循环或二次采样：
- 输入节点：用一个能写死数值或固定文本的节点，避免任何随机来源。
- 处理节点：选一个参数可预期、结果可逆的节点，把随机种子、随机化选项全部关掉或固定。
- 输出节点：用预览或保存节点，保存路径写成固定值，便于对比文件名和内容。
输入值要取那种一眼能认出来的，比如一段固定短文本、一张固定尺寸的小图。期望输出在运行前先写下来，例如“文本原样透传”“图像尺寸不变”。运行之前把当前工作流导出保存一份，例如 minimal_3node_before.json，作为对照基线。可以先记一份节点清单：
node_1 role=输入 param=固定短文本或固定尺寸图像
node_2 role=处理 param=可预期参数，随机项关闭
node_3 role=输出 param=固定保存路径
baseline_file: minimal_3node_before.json运行一次并对照节点参数是否被改写
运行一次，不要连续点多次。执行后做三线对照：
- 参数对照：把运行后的工作流再导出一次，与基线文件逐节点比较。重点看提示词、采样参数、节点连接关系、节点数量是否发生变化。
- 控制台对照：记录终端或浏览器控制台里出现的请求、报错、警告和节点调用顺序，看有没有出现“修改参数”“插入节点”这类动作。
- 会话对照：把 Comfy Agent 会话里出现过的动作描述抄下来，例如它声称改了哪个参数、替换了哪个节点。会话里的声明不能直接当结论，要和上面两条对上才算数。
可以用一份简单记录模板固定对照结果：
run_id: 1
params_changed: 无 | 列出节点与字段
nodes_changed: 无 | 新增/删除/替换
console_actions: 原文摘录
session_claims: 原文摘录
output_match_expectation: 是 | 否如果参数一致、控制台只有正常执行日志、会话里也没有落地的写操作，那么在这条工作流上，Comfy Agent 目前没有介入执行环节。反过来，只要出现一处参数变化，就要把变化的那一步单独拎出来，作为接管范围的起点。
用两个边界用例确认不接管的情形
光看正常路径不够，还要看它在条件不满足时的表现。
用例一：缺少输入。把输入节点的值清空，或断开输入到处理节点的连线，然后再次运行。记录页面反馈和控制台信息：是直接报错并停在本地校验，还是 Comfy Agent 主动补一个默认值、替你把输入填上。前者说明它不介入输入准备，后者说明它至少接管了参数补全这一步。
用例二：输出节点被禁用。把输出节点设为禁用或旁路状态再运行。观察页面反馈、控制台信息，以及 Comfy Agent 是否自行重新启用输出节点、或绕过输出直接执行到某一步。它如果保持禁用、只给出提示，说明它没有改动工作流结构。
两个用例都建议用同一份基线工作流复制出来改，改完不要覆盖原始文件，方便把“正常路径”和“边界路径”分开对比。
把可复现配置写成通用骨架并标注待核验字段
把上面确认过的项目落成一份骨架，字段名用通用占位，具体取值以你实际界面和日志为准。哪些字段在界面上找不到对应开关，就标成待核验，不要先填一个猜测值：
agent_enabled: <true|false> # 以实际界面开关为准
ui_entry: <入口可见位置的文字描述> # 待核验
auth_state: <已登录|未连接|未授权> # 待核验
workflow_scope: <prompt_only|node_params|graph_structure> # 待核验
auto_apply: <true|false> # 是否自动写回参数，待核验
log_source: <控制台|日志文件位置> # 待核验
baseline_file: minimal_3node_before.json其中 workflow_scope 是最关键的待核验字段：如果确认只影响提示词，就记 prompt_only；如果会改节点参数，记 node_params；如果能增删节点或改连线，记 graph_structure。这个值只能靠前面的对照记录填，不能靠推断。填完之后，后续每条正式工作流接入前都按同一套流程复核一次，接管范围变了就更新这份骨架。