Comfy Agent 调用失败时，直接重装往往把最该保留的现场一起清掉：首条报错、出错的时间点、请求到底发没发出去、工作流执行到哪个节点断了，这些信息重装后通常很难再复现。更稳妥的顺序是先按“控制台 → 会话记录 → 工作流”三层逐级定位，确认失败发生在网络、配置还是工作流逻辑上，再决定要不要动安装环境。
遇到 Comfy Agent 调用失败，建议先别重装。按控制台拿首条错误和堆栈，再去会话记录确认请求发出与返回的位置，最后把失败节点拉回工作流用固定输入复现。三层都指向环境或配置再考虑重装；若只是业务参数或节点输入问题，重装不会改变结果，还会丢失原始报错。
在控制台找到调用失败的首条错误
控制台是离根因最近的一层，但容易被满屏日志淹没。要做的不是截最后一条红字，而是回滚到触发动作前后，找到第一条由这次调用引起的报错。
操作上可以按下面的顺序记录：
- 首条错误：从触发那一刻往上翻，第一条 ERROR 或异常栈，通常比后面连锁失败更有信息量。后面的超时、连接重置很多是它的结果。
- 时间点：记录精确到秒的本地时间和日志时区，便于和会话记录、服务端日志对齐。时区不一致会直接影响判断失败发生在哪一段。
- 堆栈前几行：不要只抄最后一行的错误信息，前几行往往标出是哪个模块、哪个连接、哪个参数解析出的问题。
- 触发按钮或节点：记录当时点的是哪个按钮、跑的是哪个工作流节点，否则同一时间段多个请求会互相干扰，无法确认错误归属。
如果控制台只显示“调用失败”而没有细节，先把日志级别调到能看到异常栈，再重新触发一次。注意：重新触发前先记住原时间点，避免新日志覆盖旧现场。
在会话记录确认请求发出和返回位置
控制台看的是服务侧，会话记录看的是这次对话本身。目标是判断失败卡在三个位置中的哪一段：请求发出前、返回中、还是返回后处理。
- 请求消息：先确认发出去的请求内容里参数、输入、会话 ID 是否完整。如果请求消息本身就没生成，问题多半在客户端或工作流前置节点，不在远端调用。
- 返回消息：看返回是空、是错误体，还是根本没有返回。空返回常和连接中断或超时有关，错误返回多半带状态码或错误字段，能直接指向配置或权限。
- 空返回或错误返回的位置：把会话时间线和控制台时间点对齐。如果请求已发出但无返回，重点查网络和远端；如果返回了但内容异常，重点查参数和解析。
会话里若能看到请求 ID 或追踪 ID，把它和控制台日志里的同名字段对应起来，能省掉大量猜测。这个 ID 在多数接入方式里都会出现在请求头或响应体，属于可验证的字段。
在工作流里复现失败节点和输入
会话层只能告诉你“失败了”，工作流层才能告诉你“为什么失败”。这一步的目的是把对话问题还原成可重复执行的工作流运行。
- 固定输入值：把出问题那次调用用到的输入原样保留，不要随手改提示词或图片参数，否则变量太多无法归因。
- 逐步启用节点：先只跑失败节点之前的链路，确认前置节点能正常出结果，再逐个打开后续节点。
- 记录哪一步开始失败：每启用一个节点就记录输出是否正常，失败第一次出现的那个节点就是嫌疑对象。
常见的可验证信号包括：节点报缺少必填输入、类型不匹配、模型或资源路径不存在、超时。类型不匹配通常是工作流内部连线问题，路径不存在通常是配置问题，这两类重装都解决不了。只有确认是环境依赖缺失或组件损坏时，重装才有意义。
用通用请求骨架替换业务参数并验证
如果怀疑是业务参数把请求带偏，可以先用一个最小骨架单独跑通链路，确认“通路”本身是否正常。下面是通用结构示例，字段名用占位符，实际字段需要按你的接入方式替换。
POST {API_BASE}/{ENDPOINT}
Headers:
Content-Type: application/json
Authorization: Bearer {TOKEN}
Body:
{
"session_id": "{SESSION_ID}",
"input": "{MINIMAL_INPUT}",
"workflow_id": "{WORKFLOW_ID}",
"options": {}
}替换时只保留最小必填字段，把复杂业务参数先删掉。执行位置可以是命令行 curl、Postman，或接入方自带的调试入口，只要保证用的是同一套地址和凭证即可。
判断方式很直接：
- 返回成功：说明链路、凭证、地址基本可用，问题回到业务参数或工作流逻辑。
- 返回失败：看状态码和错误字段。鉴权类错误指向凭证配置，连接类错误指向网络或地址，参数类错误指向请求体结构。
- 无返回：先核对地址和端口是否可达，再看是否需要调整超时时间，最后才怀疑服务本身。
最小骨架能过、业务请求不过，基本可以排除重装的必要性。若最小骨架也不过，再往网络和配置方向排查。
整理失败分层：网络、配置、工作流
把前面三层的观察结果归到下面三类，才能排出修复顺序。建议先修最外层，再往里收。
网络层
- 观察信号：连接超时、连接被重置、无返回、DNS 解析失败。
- 下一步动作：确认地址、端口、DNS 和出站规则；检查是否需要放行对应域名或网段。
- 不应误判：业务参数错误也会表现为超时，不要一看到超时就去改网络配置。
配置层
- 观察信号：鉴权失败、模型或资源路径不存在、环境变量缺失、版本不匹配。
- 下一步动作：核对凭证、路径、环境变量和依赖版本，与能正常工作的环境做差异对比。
- 不应误判：工作流节点输入写错可能报出类似“找不到资源”的信息，先在工作流里确认再改配置。
工作流层
- 观察信号：节点输入类型不匹配、必填项为空、连线断开、单个节点报错。
- 下一步动作：固定输入后逐节点复现，修正连线或输入，再跑完整链路。
- 不应误判：工作流本身没问题时，这类报错可能来自上游返回了非预期结构，需要结合会话记录一起看。
三层都排除后，如果仍然失败，并且控制台显示组件缺失或环境损坏，再考虑重装。到这一步，首条错误、会话时间线和工作流复现记录都还在，重装后也能用来对比验证，不至于两眼一抹黑。