先记住这个答案
可以把可验证的子任务建成节点，把必需的前置产物建成有向依赖边，并记录输入、输出、完成条件与执行状态。调度器只释放前置产物已经确认有效的节点，多个就绪节点还要经过权限和资源冲突检查。一次性产物的前置关系通常可建成 DAG；带反馈的迭代应另外描述循环状态和退出条件，不能把所有运行控制都硬塞进一个无环图。
- 依赖来自数据和必要条件，不来自列表里的前后位置
- 前驱结束不等于产物满足要求，释放下游需要验证
- 图的修改要带版本，并处理旧结果是否仍适用
从交付物反推真实依赖
例如制作性能报告，收集页面指标与读取构建包体可以独立进行，分析瓶颈要等待相关数据，撰写最终结论则依赖分析结果。若简单排成五步串行列表，会错过并行机会；若无条件同时启动全部任务，又会让结论在证据到来之前生成。
每条依赖边最好能说清需要哪个版本、哪种格式的产物。任务节点只写已完成不够，下载过程结束却没有可解析文件，不能满足分析任务。将产物校验和业务接受条件写清楚，模型输出的计划才有机会转成可靠调度。
区分数据依赖与资源冲突
两个检查任务互不使用对方结果，可以同时读取不同文件；两个修改任务即使没有数据依赖，也可能写同一配置造成冲突。资源锁、并发额度或合并策略属于调度约束，不能仅凭入度为零就认为同时执行一定安全。
状态可以区分等待、就绪、运行、成功、失败和取消，并明确失败传播规则。一个分支失败未必需要取消无关分支，但依赖它的下游不能直接读取空结果继续。实际系统还需处理工具超时与重复回调，避免节点被重复释放。
让动态计划保持可核查
Agent 调查后发现还缺一个前置检查，可以在新计划版本中增加节点和边。变更前要确认现有运行任务使用的输入是否失效，不能一边改图一边让旧任务写入新状态。已完成产物如果仍满足新条件可以复用，不需要全部从头执行。
图的结构检查应覆盖重复标识、未知依赖、自依赖和环路。结构合法只是必要条件，还要检查任务是否真正覆盖目标。模型可能生成一个漂亮的 DAG，但遗漏最终验收；因此整体目标的接受条件必须独立存在，不能只以所有节点变绿作为完成依据。
容易答错的地方
- 把下一步当作必须依赖
- 描述顺序不一定是数据顺序。给每条边补上所需产物，才能发现多余串行和遗漏依赖。排查“Agent 子任务依赖图 DAG 建模”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
- 所有就绪节点立即并行
- 共享写入、工具配额和审批条件可能限制并发，需要在依赖判断之外做调度决策。排查“Agent 子任务依赖图 DAG 建模”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
面试官还会怎么问？
Agent 工作流能有环吗？
可以有带退出条件的反思或修订循环。要区分运行状态机的循环与一次性交付物互相等待的死锁。针对“Agent 子任务依赖图 DAG 建模”，还应保留最小复现、预期结果和失败路径，避免只凭一次现象下结论。
父任务完成如何判断？
既要确认必需子任务的产物有效，也要核查父任务的整体验收条件，子任务列表本身可能不完整。针对“Agent 子任务依赖图 DAG 建模”，还应保留最小复现、预期结果和失败路径，避免只凭一次现象下结论。
图更新后旧结果能直接用吗？
需要检查输入版本与接受条件是否变化。仍兼容的结果可以复用，条件失效的结果应标记过期并重新处理。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。