一个任务把结果交给另一个任务后者又反过来等待前者这种依赖环适合在执行前发现。但即使图没有环工具仍可能超时、递归生成新任务或在外部系统等待锁。DAG只能约束明确建模的依赖不能自动消除所有死锁和循环行为。先定义节点完成的含义节点不是一段可以无限自我续写的提示词而是有输入、输出和终止状态的工作单元。依赖边表达“先获得什么结果”工具调用权限和资源锁需要另外建模。把失败写成success再让下游用空结果继续会让图看起来完成而任务事实上失败。图中蓝色是成功路径两条检查都成功后才能汇总红色Rejected表示该分支失败时停止不应继续当作完成。并列分支表达可以并发的依赖关系不代表本文实测了并行加速。先让非法图无法启动下面用标准库graphlib验证依赖和顺序。示例中的两项检查只是固定教学函数执行是顺序的代码不实现分布式队列、抢占或外部工具授权。from graphlib import TopologicalSorter, CycleError deps {retrieve: set(), check_a: {retrieve}, check_b: {retrieve}, summarize: {check_a, check_b}} order tuple(TopologicalSorter(deps).static_order()) assert order.index(retrieve) order.index(check_a) assert order.index(summarize) order.index(check_b) bad {a: {b}, b: {a}} try: tuple(TopologicalSorter(bad).static_order()) except CycleError: print(cycle rejected before execution) else: raise AssertionError(cycle accepted) print(valid dependency order, order)这段检查会拒绝显式循环但不会发现节点函数内部无限等待。因此执行器还要限制总步数、每节点重试、总时长、费用与并发数并把预算从受信的运行时传入。模型不能靠再创建一个子任务重置预算。失败需要可见重试需要有边界故障可执行的处理依赖环启动前拒绝并返回环上节点单节点超时取消可取消任务阻止下游消费半成品重试造成重复写入按业务操作使用幂等键并验证服务端效果预算耗尽停止接新工作保留已完成结果和未完成项外部锁等待超时、锁顺序与补偿单独设计微软研究院10月22—23日公布的议程把长任务和多Agent协作列为评估议题。这说明评估视角需要超出单轮答复但不能据此声称某个DAG框架已有完整安全保证。议程交付时应保留一次成功、一次依赖失败和一次超时的轨迹并核对下游是否真的停止。拓扑图负责回答先后关系运行时负责让真实动作服从终止条件。
