用户说的是一句话，系统执行的是几十个步骤。真正把 AI agent 做成平台，不是让模型多回答几轮，而是把对话意图稳定编译成可执行 DAG（有向无环图）。
问题是，大多数团队把这件事做成了“提示词工程扩写”：让模型先列步骤，再顺着步骤执行。这个方案在 demo 阶段看起来能跑，但一到生产就暴露四个结构性缺陷：
- 目标漂移：同一用户意图，模型每次拆出的步骤不一致。
- 状态断裂：执行中断后无法精确恢复到正确节点。
- 风险失控：涉及外部副作用时难以做可验证补偿。
- 成本失真：不知道 token 和工具调用到底花在了哪条路径上。
把对话转换成 DAG，不是“格式更工程化”，而是把执行系统从概率行为拉回可治理系统。
什么时候必须上 Conversation-to-DAG
并非所有 agent 都要上 DAG。以下场景优先级最高：
| 场景 | 不上 DAG 的代价 |
|---|---|
| 跨工具多步骤任务 | 步骤顺序和依赖关系不稳定 |
| 有审批/策略节点 | 难证明“为什么放行” |
| 有外部副作用 | 出错后无法精确补偿 |
| 有 SLA 和预算要求 | 无法做路径级时延与成本治理 |
如果你的 agent 只做单轮问答、无副作用、无审计要求，可以先不上 DAG；但一旦进入“执行系统”范畴，DAG 基本是必选项。
编译链路：从语义到执行图
建议将编译过程拆成三段，每段都可独立观测和回滚：
| 阶段 | 输入 | 输出 | 失败动作 |
|---|---|---|---|
| Intent Parsing | 对话上下文 | goal、constraints、non-goals | ask_user |
| Plan Synthesis | goal+constraints | node list + edge list | replan |
| Graph Validation | plan graph | executable DAG | human_review |
这里有个关键约束：Graph Validation 必须独立于大模型自由生成。换句话说，模型可以“提议图”，但系统必须“验证图”。
节点建模：把节点当成可审计合约
每个节点至少要包含以下字段：
- nodeId
- inputSchema
- outputSchema
- preconditions
- sideEffects
- failurePolicy
- compensationPolicy
其中最容易被省略的是 sideEffects 和 compensationPolicy。省略它们，意味着你默认“失败可以重试”，这在有写操作的场景里几乎总是错的。
运行时语义：不是“按顺序执行”这么简单
一个可用的 DAG runtime 至少需要支持：
- 前置条件守卫：节点可执行前，强制检查依赖状态。
- 幂等执行：重复调度不会重复产生副作用。
- 检查点恢复：中断后从稳定节点继续，而不是整图重跑。
- 分支合并策略：冲突字段有明确优先级或人工合并规则。
这四项决定了你的系统在高并发和故障场景下是否可控。
失败案例：计划正确，执行不可恢复
某内容审核平台将“生成摘要 -> 证据检索 -> 风险评分 -> 审批提交”编译为 DAG，看起来路径清晰。但 runtime 没有 checkpoint。一次外部检索超时后，系统从头重跑，导致摘要版本变化、审批证据不一致，最终人工无法确认哪份结果可信。
修复动作：
- 在“证据检索完成”节点写入稳定检查点。
- 审批节点绑定检查点版本号。
- 重试仅允许在检索子图内进行，不允许整图重跑。
修复后，恢复时间下降，人工争议显著减少。
观测与指标：看图，不看平均值
建议最少跟踪以下指标：
| 指标 | 目的 |
|---|---|
| 编译成功率 | 衡量 conversation-to-graph 稳定性 |
| 节点失败分布 | 定位故障集中节点 |
| 关键路径时延 | 优化用户体感等待时间 |
| 人工接管率 | 评估自动化边界是否合理 |
| 补偿成功率 | 评估副作用治理质量 |
不要只看“整任务完成率”。完成率高但补偿失败高，意味着你在“带伤完成任务”。
落地路线图（建议四周）
- 第 1 周：确定 1 个高价值任务，定义节点契约与失败策略。
- 第 2 周：实现最小 DAG runtime（前置条件、幂等、检查点）。
- 第 3 周：接入观测和 run ledger，建立路径级指标看板。
- 第 4 周：灰度上线，优先验证恢复与补偿链路。
这条路线避免一次性大改，能在每周看到可验证增量。
一个真实的图应该长什么样
以“根据客户问题生成一份可发送的技术方案”为例，如果只让 agent 对话式执行，系统很容易把信息收集、方案生成、风险审核和外发动作混在一起。更稳的做法是把它拆成一张明确的图：
| nodeId | 责任 | 依赖 | 关键输出 |
|---|---|---|---|
| parse_request | 解析客户问题与目标 | none | goal、audience、constraints |
| collect_context | 拉取客户行业、历史沟通、产品资料 | parse_request | evidencePack |
| draft_solution | 生成方案草稿 | collect_context | draftArtifact |
| risk_review | 检查承诺、价格、合规风险 | draft_solution | riskDecision |
| human_approval | 高风险时人工确认 | risk_review | approvalResult |
| publish_response | 写入 CRM 或发送邮件 | human_approval / risk_review | sideEffectRecord |
这张图的重点不是“步骤多”，而是每一步都有独立的输入、输出、失败策略和审计价值。publish_response 是唯一真正产生外部副作用的节点，所以它必须比 draft_solution 有更严格的幂等键、权限校验和补偿记录。
Planner 不能直接拥有最终决定权
很多早期系统会让模型一次性输出完整执行计划，然后 runtime 照单执行。这种设计最大的问题是：模型既是计划者，又像是规则引擎，还顺手成了审批者。职责混在一起后，任何一次提示词漂移都会影响生产动作。
更稳的分工是：
- 模型负责提出候选图。
- Validator 负责检查图是否合法。
- Policy engine 负责判断哪些节点需要审批或禁止执行。
- Runtime 负责按图执行，不临场重新解释规则。
这种分工看起来更重，但它能让团队在出问题时知道该修哪一层。计划不合理，修 planner；图不合法，修 validator；策略误放行，修 policy；执行重复，修 runtime。
图验证要覆盖四类错误
在上线前，建议把图验证做成独立测试套件，而不是埋在 prompt 里：
| 验证类型 | 要拦截的问题 |
|---|---|
| 结构验证 | 是否有环、是否有孤立节点、依赖是否存在 |
| 契约验证 | 节点输入输出是否能连接 |
| 风险验证 | 高风险节点是否有审批或补偿策略 |
| 预算验证 | 关键路径是否超过时延或成本预算 |
尤其要注意预算验证。一个图在语义上正确，但如果把三个慢工具串在关键路径上，用户仍会觉得系统不可用。
什么时候不要把对话编译成单张大图
不是所有任务都应该一次性生成完整 DAG。以下情况更适合分段编译：
- 用户目标本身不清晰，需要先探索问题。
- 外部依赖结果会显著改变后续路径。
- 涉及多个高风险人工审批点。
- 图规模过大，超过团队当前观测能力。
分段编译的原则是：每一段图都必须能独立提交检查点。否则“分段”只是把一张大图切碎，恢复能力并不会变强。
与 Run Ledger 的关系
DAG runtime 记录的是“怎么执行”，Run Ledger 记录的是“哪些事实需要被长期引用”。两者不要混成一个表。一个实用边界是：
- DAG event 记录每个节点的细节。
- Ledger 记录可审计、可计费、可追责的事实。
- Trace 记录调试细节和调用链。
例如 draft_solution 的完整生成过程可以放在 trace 和 artifact；但 publish_response 是否真的发送、用了哪个审批结果、产生了什么外部 ID，必须进入 ledger。
上线 Checklist
- conversation 到 DAG 的编译结果可审计
- 每个节点有输入输出 schema 与失败策略
- 高风险节点声明副作用与补偿动作
- runtime 支持检查点与幂等执行
- 关键路径时延和补偿成功率可观测
- 图版本支持灰度与回滚
延伸阅读：
