用户说的是一句话，系统执行的是几十个步骤。真正把 AI agent 做成平台，不是让模型多回答几轮，而是把对话意图稳定编译成可执行 DAG（有向无环图）。
为什么必须做 Conversation to DAG
仅靠对话轮次推进任务，会遇到三个问题：
- 执行边界不清：系统不知道哪一步已经完成。
- 回滚困难：出错时无法定位该撤销哪个副作用。
- 观测失真：无法按节点统计耗时、失败率和人工接管点。
DAG 的价值是把“语义任务”映射成“可治理执行单元”。
最小编译模型
| 层级 | 输入 | 输出 |
|---|---|---|
| Intent Parser | 对话上下文 | 任务目标与约束 |
| Planner | 目标与约束 | DAG 节点与依赖 |
| Runtime | DAG + 环境状态 | 节点执行结果 |
这三层要解耦。不要把 planner 和 runtime 混在同一条提示词里。
节点设计原则
每个节点至少有四项契约：
- 输入 schema
- 输出 schema
- 副作用声明
- 失败动作（retry、replan、human_review）
没有副作用声明的节点，后续几乎不可能做可靠回滚。
失败案例：图生成正确但执行顺序错误
某团队把“证据收集”和“审批提交”放在并行分支，导致审批节点先于证据节点完成，产生空证据审批。修复后把审批节点依赖明确绑定为 evidence_ready=true，并在 runtime 增加前置条件检查。
上线 Checklist
- conversation 到 DAG 的编译结果可审计
- 每个节点有输入输出 schema
- 高风险节点有副作用声明和补偿动作
- 运行时可展示 DAG 当前路径与阻塞点
- 图版本变化支持灰度与回滚
延伸阅读：
