Refly CLI 节点命令实战refly workflow run node-* 节点级运行、查询与调试指南【免费下载链接】reflyThe first open-source agent skills builder. Define skills by vibe workflow, run on Claude Code, Cursor, Codex more. Build Clawdbot · APIs for Lovable · Bots for Slack Lark/Feishu · Skills are infrastructure, not prompts.项目地址: https://gitcode.com/GitHub_Trending/re/refly本文基于 Refly 仓库中的 节点命令参考文档系统讲解 Refly CLI 中节点Node维度的全套操作命令从「从指定节点开始运行」的 Run From Here 模式到节点执行结果、工具调用明细的逐层下钻查询再到节点列表与单节点信息的获取方式。读完后你将能够把一次工作流运行拆解到单个节点、单条工具调用级别进行定位与调试并理解每条命令背后的 API 调用链与输出结构。1. 文档定位与适用场景node.md 是 Refly 基础 SkillSKILL.md引用的五份参考文档之一与 workflow.md、file.md 等并列专门回答一类问题当一次工作流运行出现异常或需要复跑局部流程时如何针对其中的某个节点做精确操作。Refly 的核心使用约定见 SKILL.md 的 Rules 部分对理解本文所有命令都很关键CLI only始终通过refly command操作不直接调 APITrust JSON只信任 CLI 输出的 JSON 结构ok、payload、error、hintNo fabricated IDs绝不编造 workflow/run/node ID一切 ID 必须来自前一条命令的真实返回Stop on error当okfalse时停止操作并展示hint字段。2. 节点类型start 与 skillResponse参考文档以两种最常见的节点类型为例节点类型作用start工作流入口节点负责捕获用户输入skillResponseAI 响应节点可调用工具tool完成实际任务skillResponse是节点调试的重点对象——它的执行过程由多个 step 组成每个 step 内可能携带推理内容、token 用量与若干工具调用这正是后续node-result、node-toolcalls命令要下钻的数据。从源码看后端对这类节点的识别贯穿工作流、技能调用等模块例如 skill-invoker.service.ts 与 workflow.service.ts 均涉及skillResponse节点的处理逻辑。3. 节点执行命令总览节点执行类命令已统一收敛到refly workflow run子命令组下参考文档给出的完整命令表如下# Run From Here从指定节点 其下游节点开始运行 refly workflow run node-start [options] --from nodeId # 起始节点自动包含下游节点 --run-id runId # 复用已有运行上下文 --workflow-id id # 从工作流发起新运行 # 中止正在运行的节点 refly workflow run node-abort resultId [options] --version number # 中止特定版本 # 获取节点执行结果 refly workflow run node-result resultId [options] --include-steps # 附带 step 明细 --include-messages # 附带聊天消息 --include-tool-calls # 附带工具调用明细 # 获取工作流运行中的节点详情 refly workflow run node-detail runId nodeId [options] --include-messages # 附带 AI 消息 --raw # 禁用输出脱敏 # 列出节点执行中的工具调用 refly workflow run node-toolcalls resultId [options] --status status # 过滤executing / completed / failed --tool-name name # 按工具名过滤 --toolset-id id # 按 toolset ID 过滤 # 单条工具调用详情 refly workflow run node-toolcall callId [options] --raw # 输出完整工具返回不脱敏参数选择要点如果你已经处于一次具体的运行上下文中使用--run-id如果你要从某个节点发起一次全新的运行则使用--workflow-id。3.1 node-startRun From Here 的实现run-node-start.ts 展示了这条命令的完整行为校验--workflow-id与--run-id至少提供一个否则以INVALID_INPUT错误退出并给出hint提示若只给了--run-idCLI 会先请求/v1/cli/workflow/run/{runId}反查出对应的workflowId最终向后端POST /v1/cli/workflow/{workflowId}/run请求体为{ startNodes: [nodeId] }成功时输出runId、workflowId、startNode、status等字段并附带nextSteps建议的后续命令。「包含下游」的语义由服务端保证。从 workflow.service.ts 的源码看后端会先校验传入的startNodes是否都真实存在于画布节点集合中不存在的节点 ID 会被判定为非法随后prepareNodeExecutions以这些节点为起点组织执行计划。也就是说node-start不是「只跑这一个节点」而是「从该节点出发沿边流向下游继续执行」的局部重跑机制。值得注意的还有 run.ts 中完整工作流运行命令提供的--from-node nodeId选项它同样会组装body.startNodes [options.fromNode]走同一个后端接口——node-start子命令可以理解为这一能力的独立、聚焦版本便于在已锁定resultId工作流时精确操作。3.2 node-abort中止节点执行run-node-abort.ts 的实现很直接以resultId定位执行可选--version指定中止的具体版本Number.parseInt解析然后POST /v1/cli/action/abort成功返回message与resultId。这里的入参是resultId节点执行结果 ID而非 runId这与node-detail的输出形成衔接见第 7 节的交互链路。3.3 node-result读取节点执行结果run-node-result.ts 通过GET /v1/cli/action/result?resultId{resultId}拉取节点结果其输出组装逻辑值得细看主内容取 steps 数组最后一个 step 的content作为content字段即「节点最终产出」token 汇总遍历所有 step 的tokenUsage累加inputTokens/outputTokens/reasoningTokens输出为tokenUsage: { input, output, reasoning }——这为评估单节点成本提供了直接依据可选字段--include-steps输出每个 step 的索引、名称、内容、推理内容与toolCallsCount--include-messages输出消息列表messageId、type、content--include-tool-calls汇总全部 step 中的工具调用摘要callId、toolName、status、error错误透出若结果携带errors会原样放入输出。接口层的NodeResult类型run-node-result.ts还包含resultId、version、title、status、createdAt、updatedAt字段表明节点结果是版本化的——这与node-abort --version按版本中止的设计相呼应。3.4 node-detail从运行中定位节点refly workflow run node-detail runId nodeId用于按「运行 节点」两个维度定位节点执行情况--include-messages可附带 AI 消息--raw可禁用输出脱敏。它是整条调试链路的第一跳输出中的resultId是后续node-result/node-abort/node-toolcalls命令的公共入参。该命令与 workflow.md 中工作流级命令构成互补workflow run start返回runIdnode-detail再用runId nodeId下钻到节点粒度。3.5 node-toolcalls工具调用列表与统计run-node-toolcalls.ts 复用了与node-result相同的结果接口但聚焦于工具调用维度从结果的所有 step 中收集toolCalls支持三个过滤条件--statusexecuting/completed/failed、--tool-name、--toolset-id三者按 AND 语义逐条过滤输出totalCount与每条调用的callId、toolsetId、toolName、stepName、status、error、durationMs额外给出summary聚合统计byStatus按状态计数、byToolset按工具集合计数、byTool按工具名计数。durationMs字段的透出意味着可以在此层面识别慢调用summary则让「这一节点到底跑了哪些工具、各成功/失败多少」无需肉眼扫描明细即可回答。3.6 node-toolcall单条工具调用详情run-node-toolcall.ts 以callId为入参请求/v1/cli/tool-call/{callId}。两个实现细节值得注意--raw选项会附加查询参数sanitizeForDisplayfalse即关闭输出脱敏展示工具原始返回。默认输出经过 sanitization适合阅读排查工具原始数据时才应使用--raw输出按语义分块contextresultId、resultVersion、workflowExecutionId、nodeId、tooltoolsetId、toolName、stepName、input、output、status/error与timingcreatedAt、updatedAt、durationMs。context块回带了该调用归属的节点与运行 ID使单条工具调用可以反查回所属执行上下文与「Trust JSON、不编造 ID」的原则形成闭环。4. 列出工作流中的节点node listrefly workflow node list workflowId [options] --include-edges # 附带边/连接信息 --include-position # 附带节点坐标 --include-metadata # 附带完整节点元数据node/list.ts 的实现说明数据源为GET /v1/cli/workflow/{workflowId}返回工作流的完整nodes与edges默认每个节点输出id、type、title优先取data.title回退到data.metadata.title--include-edges追加edges数组id、source、target、sourceHandle、targetHandle与edgeCount——Handle信息在需要理解多分支端口如条件节点的输出分叉时很有用--include-position追加position: {x, y}画布坐标--include-metadata追加data.metadata全量元数据顶层还输出workflowId、workflowName、nodeCount方便脚本直接消费。错误处理上有个小而实用的细节失败时会把hint中的workflowId占位符替换为真实 ID 再输出list.ts使错误提示可直接复制执行。5. 获取单个节点信息node getrefly workflow node get id nodeId [options] --include-connections # 附带入边/出边连接参考文档指出id可以是工作流 IDc-xxx或运行 IDwe-xxx。node/get.ts 的实现证实了这一点通过 utils.ts 中的detectIdType自动识别 ID 类型若识别为 run先请求/v1/cli/workflow/run/{runId}换取workflowId再取工作流画布数据在nodes数组中查找目标nodeId找不到则以NODE_NOT_FOUND报错并提示refly workflow node list {id}作为下一步输出包含节点的id、type、title、position、metadata、data全量定义--include-connections时基于edges计算incoming/outgoing连接列表含sourceHandle/targetHandle及incomingCount/outgoingCount一眼看清节点在图中的上下游。这里的 ID 前缀约定与 SKILL.md 的 ID 类型表一致c-xxx是工作流 IDwe-xxx是运行 IDdf-xxx是文件 ID——命令参数用错前缀是常见错误来源node get的自动识别正好同时兼容两者。6. 命令协同resultId 链与文件处理参考文档的 Interaction 一节定义了各命令间的衔接关系整理成一条完整的下钻链路refly workflow run workflowId → 得到 runId (we-xxx) refly workflow run node-detail runId nodeId → 得到 resultId refly workflow run node-result resultId → 节点输出内容 / 文件 ID (df-xxx) refly workflow run node-toolcalls resultId → 工具调用列表与 callId refly workflow run node-toolcall callId → 单条工具调用完整输入/输出 refly workflow run node-abort resultId → 中止指定执行要点node-detail是链路的钥匙——它产出的resultId是node-result、node-abort、node-toolcalls的公共入参node-result负责取产出——节点的主内容、可选的文件 ID 都从这里获取node-toolcalls负责过程审计——工具执行情况按状态/工具名/toolset 过滤文件 ID 交给 file 命令——节点结果中的df-xxx文件 ID 应通过 file.md 描述的refly file download等命令处理本文不再展开。7. 迁移说明从 refly node 到 refly workflow run node-*参考文档同时保留了重要的迁移对照表记录了独立refly node命令组被移除的破坏性变更旧命令新命令refly node run --type t已移除— 改用refly workflow run node-start --type trefly node result idrefly workflow run node-result idrefly node abort idrefly workflow run node-abort resultIdrefly workflow run node runId nodeIdrefly workflow run node-detail runId nodeIdBreaking Change独立的refly node命令组已经不存在。若你在旧脚本或自动化流程中见过refly node ...需要整体迁移。针对「单节点调试」这一诉求文档给出的标准做法是用refly workflow run node-start --type t从目标节点发起局部运行在已有运行上下文中用node-start --from nodeId --run-id runId从该节点及其下游重跑。8. 典型调试场景组合示例综合上述命令一次「工作流某节点输出异常」的完整排查流程大致如下# 1. 列出工作流节点确认问题节点 ID refly workflow node list c-xxx --include-edges # 2. 查看该节点定义与上下游 refly workflow node get c-xxx nodeId --include-connections # 3. 从已有运行定位节点执行拿到 resultId refly workflow run node-detail we-xxx nodeId # 4. 读取节点结果主内容 步骤 工具调用摘要 refly workflow run node-result resultId \ --include-steps --include-tool-calls # 5. 按状态过滤出失败的工具调用 refly workflow run node-toolcalls resultId --status failed # 6. 查看失败调用的完整输入输出必要时关闭脱敏 refly workflow run node-toolcall callId --raw # 7. 确认原因后从该节点及其下游重跑 refly workflow run node-start --from nodeId --workflow-id c-xxx每一步的入参都严格来自上一步的 JSON 输出这正是 SKILL.md 强调的「Trust JSON、No fabricated IDs」原则在节点级调试中的落地。9. 参考路径索引内容仓库路径节点命令参考文档本文主体packages/cli/skill/references/node.md基础 Skill 规则与 ID 约定packages/cli/skill/SKILL.md工作流命令参考配合阅读packages/cli/skill/references/workflow.md文件命令参考处理 df-xxxpackages/cli/skill/references/file.mdnode-start 实现packages/cli/src/commands/workflow/run-node-start.tsnode-abort 实现packages/cli/src/commands/workflow/run-node-abort.tsnode-result 实现packages/cli/src/commands/workflow/run-node-result.tsnode-toolcalls 实现packages/cli/src/commands/workflow/run-node-toolcalls.tsnode-toolcall 实现packages/cli/src/commands/workflow/run-node-toolcall.tsnode list 实现packages/cli/src/commands/workflow/node/list.tsnode get 实现packages/cli/src/commands/workflow/node/get.tsID 类型识别c-xxx / we-xxxpackages/cli/src/commands/workflow/utils.ts工作流完整运行与 --from-nodepackages/cli/src/commands/workflow/run.ts服务端 startNodes 校验与执行编排apps/api/src/modules/workflow/workflow.service.tsCLI 端工作流控制器startNodes 入参apps/api/src/modules/workflow/workflow-cli.controller.tsstartNodes DTO 定义apps/api/src/modules/workflow/workflow-cli.dto.ts适用前提以上命令要求已安装并完成认证的refly/cli可先用refly status检查认证与连接状态所有示例中的c-xxx、we-xxx、resultId、callId均需替换为前序命令真实返回的 ID且 ID 前缀不可混用工作流、运行、文件各有独立前缀体系。【免费下载链接】reflyThe first open-source agent skills builder. Define skills by vibe workflow, run on Claude Code, Cursor, Codex more. Build Clawdbot · APIs for Lovable · Bots for Slack Lark/Feishu · Skills are infrastructure, not prompts.项目地址: https://gitcode.com/GitHub_Trending/re/refly创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Refly CLI 节点命令实战：refly workflow run node-* 节点级运行、查询与调试指南
Refly CLI 节点命令实战refly workflow run node-* 节点级运行、查询与调试指南【免费下载链接】reflyThe first open-source agent skills builder. Define skills by vibe workflow, run on Claude Code, Cursor, Codex more. Build Clawdbot · APIs for Lovable · Bots for Slack Lark/Feishu · Skills are infrastructure, not prompts.项目地址: https://gitcode.com/GitHub_Trending/re/refly本文基于 Refly 仓库中的 节点命令参考文档系统讲解 Refly CLI 中节点Node维度的全套操作命令从「从指定节点开始运行」的 Run From Here 模式到节点执行结果、工具调用明细的逐层下钻查询再到节点列表与单节点信息的获取方式。读完后你将能够把一次工作流运行拆解到单个节点、单条工具调用级别进行定位与调试并理解每条命令背后的 API 调用链与输出结构。1. 文档定位与适用场景node.md 是 Refly 基础 SkillSKILL.md引用的五份参考文档之一与 workflow.md、file.md 等并列专门回答一类问题当一次工作流运行出现异常或需要复跑局部流程时如何针对其中的某个节点做精确操作。Refly 的核心使用约定见 SKILL.md 的 Rules 部分对理解本文所有命令都很关键CLI only始终通过refly command操作不直接调 APITrust JSON只信任 CLI 输出的 JSON 结构ok、payload、error、hintNo fabricated IDs绝不编造 workflow/run/node ID一切 ID 必须来自前一条命令的真实返回Stop on error当okfalse时停止操作并展示hint字段。2. 节点类型start 与 skillResponse参考文档以两种最常见的节点类型为例节点类型作用start工作流入口节点负责捕获用户输入skillResponseAI 响应节点可调用工具tool完成实际任务skillResponse是节点调试的重点对象——它的执行过程由多个 step 组成每个 step 内可能携带推理内容、token 用量与若干工具调用这正是后续node-result、node-toolcalls命令要下钻的数据。从源码看后端对这类节点的识别贯穿工作流、技能调用等模块例如 skill-invoker.service.ts 与 workflow.service.ts 均涉及skillResponse节点的处理逻辑。3. 节点执行命令总览节点执行类命令已统一收敛到refly workflow run子命令组下参考文档给出的完整命令表如下# Run From Here从指定节点 其下游节点开始运行 refly workflow run node-start [options] --from nodeId # 起始节点自动包含下游节点 --run-id runId # 复用已有运行上下文 --workflow-id id # 从工作流发起新运行 # 中止正在运行的节点 refly workflow run node-abort resultId [options] --version number # 中止特定版本 # 获取节点执行结果 refly workflow run node-result resultId [options] --include-steps # 附带 step 明细 --include-messages # 附带聊天消息 --include-tool-calls # 附带工具调用明细 # 获取工作流运行中的节点详情 refly workflow run node-detail runId nodeId [options] --include-messages # 附带 AI 消息 --raw # 禁用输出脱敏 # 列出节点执行中的工具调用 refly workflow run node-toolcalls resultId [options] --status status # 过滤executing / completed / failed --tool-name name # 按工具名过滤 --toolset-id id # 按 toolset ID 过滤 # 单条工具调用详情 refly workflow run node-toolcall callId [options] --raw # 输出完整工具返回不脱敏参数选择要点如果你已经处于一次具体的运行上下文中使用--run-id如果你要从某个节点发起一次全新的运行则使用--workflow-id。3.1 node-startRun From Here 的实现run-node-start.ts 展示了这条命令的完整行为校验--workflow-id与--run-id至少提供一个否则以INVALID_INPUT错误退出并给出hint提示若只给了--run-idCLI 会先请求/v1/cli/workflow/run/{runId}反查出对应的workflowId最终向后端POST /v1/cli/workflow/{workflowId}/run请求体为{ startNodes: [nodeId] }成功时输出runId、workflowId、startNode、status等字段并附带nextSteps建议的后续命令。「包含下游」的语义由服务端保证。从 workflow.service.ts 的源码看后端会先校验传入的startNodes是否都真实存在于画布节点集合中不存在的节点 ID 会被判定为非法随后prepareNodeExecutions以这些节点为起点组织执行计划。也就是说node-start不是「只跑这一个节点」而是「从该节点出发沿边流向下游继续执行」的局部重跑机制。值得注意的还有 run.ts 中完整工作流运行命令提供的--from-node nodeId选项它同样会组装body.startNodes [options.fromNode]走同一个后端接口——node-start子命令可以理解为这一能力的独立、聚焦版本便于在已锁定resultId工作流时精确操作。3.2 node-abort中止节点执行run-node-abort.ts 的实现很直接以resultId定位执行可选--version指定中止的具体版本Number.parseInt解析然后POST /v1/cli/action/abort成功返回message与resultId。这里的入参是resultId节点执行结果 ID而非 runId这与node-detail的输出形成衔接见第 7 节的交互链路。3.3 node-result读取节点执行结果run-node-result.ts 通过GET /v1/cli/action/result?resultId{resultId}拉取节点结果其输出组装逻辑值得细看主内容取 steps 数组最后一个 step 的content作为content字段即「节点最终产出」token 汇总遍历所有 step 的tokenUsage累加inputTokens/outputTokens/reasoningTokens输出为tokenUsage: { input, output, reasoning }——这为评估单节点成本提供了直接依据可选字段--include-steps输出每个 step 的索引、名称、内容、推理内容与toolCallsCount--include-messages输出消息列表messageId、type、content--include-tool-calls汇总全部 step 中的工具调用摘要callId、toolName、status、error错误透出若结果携带errors会原样放入输出。接口层的NodeResult类型run-node-result.ts还包含resultId、version、title、status、createdAt、updatedAt字段表明节点结果是版本化的——这与node-abort --version按版本中止的设计相呼应。3.4 node-detail从运行中定位节点refly workflow run node-detail runId nodeId用于按「运行 节点」两个维度定位节点执行情况--include-messages可附带 AI 消息--raw可禁用输出脱敏。它是整条调试链路的第一跳输出中的resultId是后续node-result/node-abort/node-toolcalls命令的公共入参。该命令与 workflow.md 中工作流级命令构成互补workflow run start返回runIdnode-detail再用runId nodeId下钻到节点粒度。3.5 node-toolcalls工具调用列表与统计run-node-toolcalls.ts 复用了与node-result相同的结果接口但聚焦于工具调用维度从结果的所有 step 中收集toolCalls支持三个过滤条件--statusexecuting/completed/failed、--tool-name、--toolset-id三者按 AND 语义逐条过滤输出totalCount与每条调用的callId、toolsetId、toolName、stepName、status、error、durationMs额外给出summary聚合统计byStatus按状态计数、byToolset按工具集合计数、byTool按工具名计数。durationMs字段的透出意味着可以在此层面识别慢调用summary则让「这一节点到底跑了哪些工具、各成功/失败多少」无需肉眼扫描明细即可回答。3.6 node-toolcall单条工具调用详情run-node-toolcall.ts 以callId为入参请求/v1/cli/tool-call/{callId}。两个实现细节值得注意--raw选项会附加查询参数sanitizeForDisplayfalse即关闭输出脱敏展示工具原始返回。默认输出经过 sanitization适合阅读排查工具原始数据时才应使用--raw输出按语义分块contextresultId、resultVersion、workflowExecutionId、nodeId、tooltoolsetId、toolName、stepName、input、output、status/error与timingcreatedAt、updatedAt、durationMs。context块回带了该调用归属的节点与运行 ID使单条工具调用可以反查回所属执行上下文与「Trust JSON、不编造 ID」的原则形成闭环。4. 列出工作流中的节点node listrefly workflow node list workflowId [options] --include-edges # 附带边/连接信息 --include-position # 附带节点坐标 --include-metadata # 附带完整节点元数据node/list.ts 的实现说明数据源为GET /v1/cli/workflow/{workflowId}返回工作流的完整nodes与edges默认每个节点输出id、type、title优先取data.title回退到data.metadata.title--include-edges追加edges数组id、source、target、sourceHandle、targetHandle与edgeCount——Handle信息在需要理解多分支端口如条件节点的输出分叉时很有用--include-position追加position: {x, y}画布坐标--include-metadata追加data.metadata全量元数据顶层还输出workflowId、workflowName、nodeCount方便脚本直接消费。错误处理上有个小而实用的细节失败时会把hint中的workflowId占位符替换为真实 ID 再输出list.ts使错误提示可直接复制执行。5. 获取单个节点信息node getrefly workflow node get id nodeId [options] --include-connections # 附带入边/出边连接参考文档指出id可以是工作流 IDc-xxx或运行 IDwe-xxx。node/get.ts 的实现证实了这一点通过 utils.ts 中的detectIdType自动识别 ID 类型若识别为 run先请求/v1/cli/workflow/run/{runId}换取workflowId再取工作流画布数据在nodes数组中查找目标nodeId找不到则以NODE_NOT_FOUND报错并提示refly workflow node list {id}作为下一步输出包含节点的id、type、title、position、metadata、data全量定义--include-connections时基于edges计算incoming/outgoing连接列表含sourceHandle/targetHandle及incomingCount/outgoingCount一眼看清节点在图中的上下游。这里的 ID 前缀约定与 SKILL.md 的 ID 类型表一致c-xxx是工作流 IDwe-xxx是运行 IDdf-xxx是文件 ID——命令参数用错前缀是常见错误来源node get的自动识别正好同时兼容两者。6. 命令协同resultId 链与文件处理参考文档的 Interaction 一节定义了各命令间的衔接关系整理成一条完整的下钻链路refly workflow run workflowId → 得到 runId (we-xxx) refly workflow run node-detail runId nodeId → 得到 resultId refly workflow run node-result resultId → 节点输出内容 / 文件 ID (df-xxx) refly workflow run node-toolcalls resultId → 工具调用列表与 callId refly workflow run node-toolcall callId → 单条工具调用完整输入/输出 refly workflow run node-abort resultId → 中止指定执行要点node-detail是链路的钥匙——它产出的resultId是node-result、node-abort、node-toolcalls的公共入参node-result负责取产出——节点的主内容、可选的文件 ID 都从这里获取node-toolcalls负责过程审计——工具执行情况按状态/工具名/toolset 过滤文件 ID 交给 file 命令——节点结果中的df-xxx文件 ID 应通过 file.md 描述的refly file download等命令处理本文不再展开。7. 迁移说明从 refly node 到 refly workflow run node-*参考文档同时保留了重要的迁移对照表记录了独立refly node命令组被移除的破坏性变更旧命令新命令refly node run --type t已移除— 改用refly workflow run node-start --type trefly node result idrefly workflow run node-result idrefly node abort idrefly workflow run node-abort resultIdrefly workflow run node runId nodeIdrefly workflow run node-detail runId nodeIdBreaking Change独立的refly node命令组已经不存在。若你在旧脚本或自动化流程中见过refly node ...需要整体迁移。针对「单节点调试」这一诉求文档给出的标准做法是用refly workflow run node-start --type t从目标节点发起局部运行在已有运行上下文中用node-start --from nodeId --run-id runId从该节点及其下游重跑。8. 典型调试场景组合示例综合上述命令一次「工作流某节点输出异常」的完整排查流程大致如下# 1. 列出工作流节点确认问题节点 ID refly workflow node list c-xxx --include-edges # 2. 查看该节点定义与上下游 refly workflow node get c-xxx nodeId --include-connections # 3. 从已有运行定位节点执行拿到 resultId refly workflow run node-detail we-xxx nodeId # 4. 读取节点结果主内容 步骤 工具调用摘要 refly workflow run node-result resultId \ --include-steps --include-tool-calls # 5. 按状态过滤出失败的工具调用 refly workflow run node-toolcalls resultId --status failed # 6. 查看失败调用的完整输入输出必要时关闭脱敏 refly workflow run node-toolcall callId --raw # 7. 确认原因后从该节点及其下游重跑 refly workflow run node-start --from nodeId --workflow-id c-xxx每一步的入参都严格来自上一步的 JSON 输出这正是 SKILL.md 强调的「Trust JSON、No fabricated IDs」原则在节点级调试中的落地。9. 参考路径索引内容仓库路径节点命令参考文档本文主体packages/cli/skill/references/node.md基础 Skill 规则与 ID 约定packages/cli/skill/SKILL.md工作流命令参考配合阅读packages/cli/skill/references/workflow.md文件命令参考处理 df-xxxpackages/cli/skill/references/file.mdnode-start 实现packages/cli/src/commands/workflow/run-node-start.tsnode-abort 实现packages/cli/src/commands/workflow/run-node-abort.tsnode-result 实现packages/cli/src/commands/workflow/run-node-result.tsnode-toolcalls 实现packages/cli/src/commands/workflow/run-node-toolcalls.tsnode-toolcall 实现packages/cli/src/commands/workflow/run-node-toolcall.tsnode list 实现packages/cli/src/commands/workflow/node/list.tsnode get 实现packages/cli/src/commands/workflow/node/get.tsID 类型识别c-xxx / we-xxxpackages/cli/src/commands/workflow/utils.ts工作流完整运行与 --from-nodepackages/cli/src/commands/workflow/run.ts服务端 startNodes 校验与执行编排apps/api/src/modules/workflow/workflow.service.tsCLI 端工作流控制器startNodes 入参apps/api/src/modules/workflow/workflow-cli.controller.tsstartNodes DTO 定义apps/api/src/modules/workflow/workflow-cli.dto.ts适用前提以上命令要求已安装并完成认证的refly/cli可先用refly status检查认证与连接状态所有示例中的c-xxx、we-xxx、resultId、callId均需替换为前序命令真实返回的 ID且 ID 前缀不可混用工作流、运行、文件各有独立前缀体系。【免费下载链接】reflyThe first open-source agent skills builder. Define skills by vibe workflow, run on Claude Code, Cursor, Codex more. Build Clawdbot · APIs for Lovable · Bots for Slack Lark/Feishu · Skills are infrastructure, not prompts.项目地址: https://gitcode.com/GitHub_Trending/re/refly创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
