子任务失败或返回空数据时，工作流如何重试和降级？

核心回答

我会先判断失败属于哪一类、结果是否足够、重试是否安全，再决定重试、修正输入、切备用路径，还是返回部分结果或停止。

网络抖动、短期限流等瞬时故障可以在总预算内有限重试，使用退避和抖动；参数错误要带着具体反馈修正，缺少必要信息就补齐，权限或业务拒绝不能靠原请求反复重跑。

**空数据不一定是异常。**确实没有记录、查询条件不合适、解析失败或上游服务故障，要分别识别。下游是否继续则取决于任务成功条件：可选资料缺失可以标注后降级，关键证据或必需输入缺失就不能继续硬生成。

展开说明

1. 先把结果语义表达清楚

节点不应只返回一个列表，让下游凭 [] 猜原因。应用可以给结果增加状态、数据、来源、查询条件、错误类型和必要的质量信息，区分以下情况：

• 正常无数据：查询成功，但指定范围确实没有匹配记录，按业务含义返回即可。
• 输入需要修正：日期、标识或必填条件错误，校验后修正，或请用户补充信息。
• 暂时不可用：连接失败、短期限流或部分服务异常，适合有限重试。
• 权限或业务拒绝：按授权和业务规则处理，不能换一种提示词绕过。
• 数据质量不足：页面抓回来了但正文未解析、字段不完整或缺少证据，需要修复提取、换来源或停止相应下游。

这些是应用设计的结果语义，不要求所有工具使用同一组固定状态名。关键是把“没有记录”和“没有成功取得记录”分开，也不要把错误文本伪装成正常材料交给汇总节点。

2. 技术重试与改变策略是两件事

技术重试是在条件基本不变时，再尝试一次可能恢复的请求。设置单次超时、最大尝试次数和整段任务的截止时间，重试前检查剩余预算，并使用退避、抖动及下游限流信号控制节奏。

例如可以为某次查询设定“最多共尝试三次，即首次加两次重试”，但具体次数应按下游和任务要求选择。SDK、工具执行器和工作流不能各自独立重试，把一次故障放大成多层调用；由一个主要策略持有者统计总尝试和耗时。

如果问题是查询关键词过窄，修改查询属于策略调整；如果是参数格式错误，根据校验反馈重新生成参数属于纠错。两者都要记录原因并限制次数，不能把每次改写都当成新任务，绕过总预算。连续没有新增证据时，应收敛、澄清或结束，而不是无限换词搜索。

3. 降级必须看依赖和成功条件

以“同时查询官方资料和补充案例，生成技术说明”为设计示例：官方资料是必需证据，案例只是补充。

如果案例检索超时，有限重试后仍失败，可以继续使用官方资料，并说明案例部分缺失。如果官方资料查询正常但无结果，先核对产品、版本和关键词，再按计划补查可信来源；若仍缺关键依据，就只交付已经确认的内容和缺口，不能用模型猜测补齐。如果抓取成功但正文为空，则应检查页面与解析结果，而不是把同一请求立即重发很多次。

备用工具、数据源或缓存需要保持相同任务含义、访问范围和必要时效。对实时状态问题，过期缓存可能无法满足要求；对必须依赖上游字段的下游节点，输入不完整就跳过或等待。部分分支完成后可以保留产物，但整体状态仍应表达“部分完成”，不能把缺失项抹掉当作全量成功。

4. 在图状态中留下可恢复的处理结果

记录失败节点、尝试次数、错误类型、已完成结果、当前策略和待执行分支，让编排器据此选择重试、备用路径、澄清或终止。成功分支在结果仍有效且已经保存时可以复用，通常不需要把整条工作流从头重跑。

以 LangGraph 为例，节点异常可以交给相应重试策略；正常返回的空数据则需要应用检查，并通过状态和条件路由决定下一步。**如果节点把异常捕获成普通返回值，框架也不会自动知道应当重试。**应在工具适配和节点契约中统一这种边界。

超时和取消也不等于远端操作没有发生。涉及写入的任务应核对实际结果，并使用业务幂等机制；旧尝试迟到后返回，还要检查任务和尝试归属，避免覆盖新的结果。状态保存机制可结合State 与 Checkpoint说明。

常见追问

返回空列表，直接抛异常让框架重试可以吗？

只有已经确认它表示某种可恢复故障时才适合。合法的“无匹配记录”应作为业务结果，条件不明确应补信息，解析器坏了要修解析。把所有空值抛成同一种异常，往往只会重复消耗和掩盖原因。

主工具失败后，直接换一个工具就行吗？

先检查备用工具是否满足相同语义、权限、数据范围和时效要求，再转换输入并校验输出。主工具若已发起写操作但结果未知，要先核对终态，不能立刻换个服务再执行一次。

失败节点重试时，其他节点怎么办？

独立且成功的分支可保留结果；依赖失败结果的节点等待或跳过。若最终任务必须全部成功，就不能提前交付成功状态。是否取消其他分支，还要看它们继续运行是否仍有价值和剩余预算。

生成代码第一次不对，整个流程要断吗？

不一定。先根据真实编译、测试或行为反馈定位问题，在当前任务范围内有限修正，再验证。遇到确定性配置错误、未知异常或没有进展时，保留现场并停止相应分支；涉及已有修改和业务状态时，按明确范围恢复或补偿，不能用“回退”概括所有操作。

怎么知道重试和降级有没有用？

分别看失败类型、重试后的恢复率、额外调用与耗时、降级后的任务质量及缺失项。还应检查无数据是否被误判成故障、备用数据是否过期、是否发生重复业务动作，避免只看最终有答案的比例。

对应教程

参考资料

DB-GPTPython

基于 DB-GPT

核心回答

DB-GPT 当前数据分析链路由主 Agent 执行 SQL 和 Python 分析，把结果保存为带标识的产物，再交给专职报告子 Agent 组织报告。报告缺数据时，先区分未捕获结构化结果、缺少计算、报告格式或引用错误，以及子 Agent 执行失败，再选择补结果、交回补算、局部修复或停止。 不需要把所有分析从头重跑，也不能把空数据或草稿当成完整成功。

报告子 Agent 与主 Agent 共享产物及报告状态，但有独立会话、记忆和执行步数预算。它的工具用于读取证据、渲染报告和请求补算，没有直接执行 SQL、Python 分析的工具；缺少退款率等计算时，交回主 Agent 处理。子 Agent 构建与工具范围。

空数据和缺少结构化结果怎样区分

generate_report() 检查已成功执行的 SQL、Python 产物：如果存在这些产物，但它们的 result 全部为 None，返回 needs_analysis，要求主 Agent 捕获可绑定的结构化结果。只有打印文本，即使内容看起来像计算结果，也不足以让报告按字段取数。生成入口的结果检查。

这不是“业务无数据”的通用判断器：空列表本身不等于 None。某门店活动期间确实没有退款、筛选条件错误、分析只打印了进度，需要主分析链根据查询条件和执行结果分别解释，不能都补成零，也不能都用同一请求重试。

缺少计算怎样交回和恢复

报告子 Agent 调用 request_report_calculation()，提交计算名称、计算步骤和源产物标识。程序要求名称、步骤非空，输入必须指向真实、成功的 SQL 或 Python 产物；随后读取其结果，保存补算输入和检查点，向主 Agent 返回 needs_analysis。补算请求与检查。

同一个未完成请求再次到来时，直接返回已有请求，不新增计数；已有请求完成后再提出请求仍会消耗预算。这是待处理请求保护，并非根据公式内容实现了跨请求语义去重。当前实现累计最多交回三次缺失计算，每个待补算请求又限制最多三次代码执行尝试，两个限制分别控制不同阶段。

主 Agent 用 code_interpreter 只完成缺失计算，并把结果赋给 REPORT_RESULT。代码成功、捕获到成功的 Python 产物且其结果不是 None 后，程序才回填 result_artifact_id、保存检查点；再次生成报告时，子 Agent 使用这个真实产物继续绑定。仅向标准输出打印一段 JSON 不满足这个捕获条件。补算执行预算、结构化结果捕获、补算完成条件。

产物状态和输入标识的检查能确认计算确实产生了可读取结果，不能证明退款率公式、时间归属或分母选择已经正确；这些仍需按业务口径核对。

修复失败时怎样停止和降级

报告修复分别记录预检、文档组装、渲染和无效调用的失败，并设置总调用上限。错误与候选内容的指纹用于识别重复失败；没有进展时可以提前停止，不必等所有次数耗尽。修复主要针对已保存的报告结构与引用，保留成功产物，不重新执行整套分析。修复预算与无进展判断。

若子 Agent 超时或抛出执行异常，程序先尝试从已保存内容确定性渲染；仍不能完成时，返回 failed、retryable=False，保留检查点和可能存在的草稿，提示本轮停止反复调用。执行异常与最后一次渲染错误分别记录，避免把所有问题都当成模板错误交给模型继续改。异常与失败返回、异常后的保存内容恢复。

受控降级也会明确留下缺口：部分不可核验的显示数值可以标为 --，不可用的图表可以省略，并在报告和 warnings 中说明。它不会把缺失值替换成其他数字；其余引用与报告要求仍需通过校验。引用降级、警告与最终校验。

最终状态根据正式报告内容与错误状态产生：未完成时返回 partial，预算耗尽时返回 failed；草稿预览不能变成正式报告。completed 也可能带降级警告，因此业务验收还要查看缺失项是否允许。报告完成状态。评估时应分别统计补算恢复、带缺口交付和停止失败，不能把所有“有报告输出”都计为任务完整成功。JavaGuide：错误恢复与最终状态评估。