先记住这个答案
在执行过程中发现新依赖，应首先判断其影响范围：若只涉及当前步骤及后续未执行步骤，则增量插入节点并局部重排；若影响前期已完成步骤或目标本身，才考虑整体重规划。局部更新需基于依赖图，确保新节点插入后不破坏既有顺序约束。
- 新依赖仅影响未执行步骤时，增量更新
- 整体重规划代价高，应避免滥用
- 依赖图是局部重排的关键依据
增量插入的机制：依赖图与局部更新
执行中产生新依赖，典型情况是某一步骤的结果又暴露出额外前置条件。例如，生成报告时发现需要数据源B，而B需先由清洗任务获取。此时若采取整体重规划，不仅浪费已执行步骤的成果，还可能因重新规划引入不一致。增量插入的核心是维护一个动态依赖图，其中节点代表子任务，边表示完成顺序。新依赖表现为一个或多个新节点，需找到其在图中的插入点。
插入过程需要验证：新节点依赖的所有数据是否已存在或可获取？新节点是否会阻塞已开始的并行任务？通过遍历依赖图，找到所有受新节点影响的路径——即那些依赖新节点或为新节点所依赖的未执行节点。局部重排只调整这些路径上的顺序，不影响已完成子任务。在一些支持动态修改工作流的框架中，可通过修改图结构（如添加节点和边）并保留状态来实现；但在LangGraph等编译后图固定的框架中，通常需要重新编译整个图并借助状态持久化恢复已完成步骤，或预先设计通用节点和条件路由来模拟动态行为，但无法在运行时真正添加新节点。无论哪种方式，都需确保状态中保存了关键中间结果。
场景：数据处理管道中突发字段缺失
假设Agent负责构建用户画像。计划是：抓取用户资料 → 解析字段 → 生成摘要。执行到解析步骤时，发现原始数据缺少关键字段“行业”，该字段可从用户历史行为日志中提取，但日志尚未下载。新依赖：下载日志并解析行业。此时已完成“抓取用户资料”，但解析尚未完成。Agent将新任务“下载日志”和“提取行业”插入依赖图：它们应位于“解析字段”之前，并且必须串行执行（它们不能与“生成摘要”并行，因为“生成摘要”依赖于“解析字段”的输出）。
处理方式：在“解析字段”节点前插入两个新节点，并建立边：下载日志 → 提取行业 → 解析字段。同时需更新受影响路径：“解析字段”及之后的所有未执行节点都依赖于新节点，故它们都需推迟。已完成“抓取资料”状态保留，不重跑。验证依赖图：下载日志不依赖其他未完成项，提取行业依赖下载完成。最终执行顺序变为：抓取资料（完成）→ 下载日志 → 提取行业 → 解析字段 → 生成摘要。局部重排完成，未影响已完成步骤。
适用边界：何时不可局部更新
局部更新并非永远可行。若新依赖要求重做已完成步骤，比如新依赖是一个清洗过程，而该清洗本应在抓取前执行，但抓取已完成且已存储了未清洗数据，则必须重跑抓取。此时增量插入可能导致状态不一致，应进行整体重规划。另一种情况：新依赖揭示了原始目标理解错误，比如用户要周报而非日报，这涉及目标重定义，当属重规划。
此外，新依赖可能带来资源或时序冲突。例如，新增任务需要外部API调用，但调用次数已达预算限制，局部更新无法解决预算约束，必须重新规划以重新分配资源。判断原则：若新依赖只影响未执行步骤且不违反硬约束（时间、成本、权限），则增量；否则需重规划。代价是额外计算依赖图遍历，但通常远小于重新生成整个计划的开销。
容易答错的地方
- 看到新依赖就整体重规划
- 整体重规划会导致已完成步骤作废，且新计划可能引入原本不存在的风险。正确做法是先评估影响范围，仅当已完成步骤被推翻或目标改变时才重规划。
- 把新节点插在计划末尾
- 新依赖往往有前置关系，必须按依赖顺序插入。随意追加会导致后续步骤缺少输入。应基于依赖图找到正确插入点。
面试官还会怎么问？
局部重排如何处理正在执行中的并行任务？
若新依赖影响某个并行分支，应暂停该分支直到依赖满足，但其他独立分支可继续。在 LangGraph 中，由于 interrupt 是全局暂停，实现分支级暂停需将并行分支拆分为独立子图或使用自定义异步控制；checkpointer 可持久化状态以支持恢复。
增量插入后如何保证不会产生循环依赖？
插入新节点时，需在依赖图中检测是否形成环，即新节点通过依赖链能否回到自身。可使用深度优先搜索等环检测算法对整个依赖图进行检查（已执行节点的依赖边仍在图中）。若发现环，则拒绝插入并报错。
新依赖多次出现时如何避免频繁调整？
可将新依赖暂存入待处理队列，批量处理或设定阈值，比如累积一定数量后再更新。但需确保延迟迭代不会导致关键路径阻塞。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。