清单的定位
编排评审最容易开成“架构图讲一遍”的汇报会。图讲得再漂亮，也回答不了一个问题：这条链路失败时，谁承担、损失多少、多久能恢复。
这份清单把评审拆成十三组、六十五问。每组给通过判据与常见驳回理由。不必每次问完，按方案风险挑三到五组深问；但结构、失败、权限三组，建议每次必问。
一、结构
- 这条链路为什么需要多个能力？单能力是否足够？
- 串行、并行、条件分支、人机混合、异步交付，选了哪种？为什么？
- 哪些步骤是固定流程，哪些真的需要模型判断？
- 最长路径是哪一条？关键路径上有哪些节点？
- 如果去掉一个节点，质量、成本、延迟各变化多少？
通过判据：有一张结构图，节点、边、汇合点、人工点都标注；每个节点能说出去留理由。
常见驳回：“业界都这么做。”结构不是模仿来的，节点数要能从需求推出来。
二、契约
- 节点之间传什么？字段、类型、必填项写在哪？
- 交接 token 预算多少？820 是上限还是观测值？
- 契约版本如何标识？不兼容变更如何发现？
- 空值、超长、格式错误分别如何处理？
- 哪些字段是证据，哪些是模型生成的摘要？
通过判据：每条边有 schema 与示例；契约变更走版本；非法输入有拒绝路径。
常见驳回：“模型会自己理解。”理解不是契约，下游无法据此做校验。
三、执行图
- 图是有向无环的吗？环在哪里被阻止？
- 拓扑序是否稳定？同样输入是否走同样路径？
- 并行汇合用 all、any 还是 quorum？失败分支如何标记？
- 检查点存在哪里？恢复时从哪一步继续？
- 每个节点是否幂等？重复执行会不会产生第二次副作用？
通过判据：图可导出、可校验；检查点与幂等键有定义；恢复演练做过。
常见驳回：“重跑一遍就行。”重跑不是恢复，副作用可能已经发生两次。
四、上下文
- 共享上下文 3,200 token 包含什么？谁维护？
- 每个节点拿到的是全量还是切片？依据是什么？
- 缓存折扣 90% 是否真实命中？缓存键是否稳定？
- 上下文超预算时先裁什么？裁完如何验证关键信息还在？
- 跨租户或跨用户的数据是否可能进入同一上下文？
通过判据：上下文预算表存在；裁剪有事实探针；租户隔离有明确边界。
常见驳回：“上下文越长效果越好。”成本和泄漏风险都不支持这个结论。
五、失败
- 失败分为哪几类？哪些可重试，哪些绝对不可？
- 单步失败预算 13.02% 如何得出？关键节点是否更严？
- 整链成功率目标是多少？分母是任务数还是成功交付数？
- 部分结果能否交付？交付时如何标注缺失？
- 重试预算谁持有？重试是否会击穿下游配额？
通过判据：失败分类表、重试预算、部分交付规则三件齐备。
常见驳回：“失败就重试三次。”重试不是失败策略，只是把失败推迟。
六、人工与异步
- 哪些节点必须人工？依据是错误代价还是合规要求？
- 人工审核的 SLA、队列上限、超时处理是什么？
- 人工修改如何回写？是否影响下游契约？
- 长任务如何提交、查询、取消、通知？
- 异步任务丢失或重复交付时如何发现？
通过判据：人工节点有 SLA 与回写协议；异步任务有终态、幂等键与补偿路径。
常见驳回：“加个人看一眼。”看一眼不是控制，没有 SLA 的人工节点就是新瓶颈。
七、评测
- 端到端评测集覆盖哪些链路形态？各多少条？
- 通过标准是整体判定，还是分节点判定？
- 失败归因能否定位到具体节点与版本？
- 回放是否使用当时的模型、提示与上下文？
- 评测集多久更新一次？是否包含新出现的失败模式？
通过判据：评测集版本化；归因可下钻；回放可复现。
常见驳回：“抽检感觉还行。”感觉不是评测，样本量与判据都说不清。
八、成本
- 每次成功交付成本是多少？分母是任务数还是成功数？
- 交接、重试、人工、固定开销是否都计入？
- 节点预算如何分配？超支先裁谁？
- 复用回本线 28.47% 是否达到？未达到的节点为何还共享上下文？
- 成本异常时，多久能定位到节点与版本？
通过判据：成功交付成本可算；裁剪顺序有文档；归因可下钻到节点。
常见驳回：“单价降了就算优化。”单价不等于总成本，失败与重试会把省下的钱吃回去。
九、权限
- 用户权限如何传到每个节点？是否有节点用服务账号越权？
- 外部动作（写库、发消息、退款）由谁授权？
- 注入内容能否从一个节点传播到另一个节点？
- 工具调用的白名单与参数校验在哪里？
- 审计日志是否记录“谁授权了什么动作”？
通过判据：权限随请求传播；外部动作二次授权；注入有隔离与检测。
常见驳回：“内部服务不用鉴权。”编排放大了越权，一个节点被污染，整条链路都可能执行越界动作。
十、运维
- 每条链路的最低观测字段是什么？trace_id 能否串起所有节点？
- 节点级 SLO 与整体 SLO 的关系是否清楚？
- 哪个指标先报警？告警接收人是谁？
- 止血时先关哪个开关？降级后是否仍满足最低质量？
- 上一次事故的防复发措施是否落地？
通过判据：追踪字段齐全；SLO 可分解；止血开关有演练记录。
常见驳回：“有监控。”有监控不等于能定位，字段不全的 trace 只是一串时间戳。
十一、平台化
- 编排用声明式还是代码？边界在哪？
- 新节点如何注册？能力目录是否有一致的契约？
- 扩展点是否允许绕过权限与预算？
- 多团队共享节点时，版本与 SLA 如何约定？
- 平台升级是否会破坏已有编排？
通过判据：扩展有边界；目录有 owner；升级有兼容策略。
常见驳回：“先接进来再说。”接进来容易，治理与下线难。
十二、演进
- 这条编排的下一个版本要改什么？退出条件是什么？
- 灰度按什么维度切？观察期多长？
- 回滚只回编排版本，还是也要回节点版本？
- 从固定编排到自主 Agent 的边界在哪里？
- 哪些节点未来可能被模型能力吞并？
通过判据：有版本与灰度计划；回滚演练过；Agent 边界有可判定的条件。
常见驳回：“以后再说。”没有退出条件的编排，会变成下一任维护者的历史包袱。
十三、收口
- 基线数字（成本、延迟、成功率）是否可复现？
- 评审结论是否写成可验证的条件，而不是“同意”？
- 每个条件是否有负责人和复查日期？
- 上线后复盘表由谁填？差异超过 20% 怎么办？
- 这次评审暴露的系统性缺口是什么？谁来补？
通过判据：结论有条件、有 owner、有日期；复盘表已预填。
常见驳回：“先上线，有问题再复盘。”复盘不是事后补文档，条件必须在放行前写死。
进评审前的三个快速判据
时间不够时，先用三问筛掉准备不足的方案：
- 能不能一句话说清“为什么不是单能力”？ 说不清，说明结构还没成立。
- 失败时用户看到什么，团队能否在十分钟内说清？ 说不清，说明失败路径没设计。
- 这次改动的退出条件是什么？ 说不清，说明方案没有回滚预案。
三问有一问答不上来，方案先回去补材料，不进入详细评审。它们不保证方案正确，但能挡掉大部分“先画一张图再说”的方案。
四十五分钟评审流程
| 时间 | 动作 | 产出 |
|---|---|---|
| 0–5 分钟 | 方案方讲结构、基线、目标与改动 | 一句话结论 |
| 5–15 分钟 | 按风险挑三组深问 | 三到五个待确认项 |
| 15–30 分钟 | 逐项给结论 | 通过 / 有条件通过 / 驳回 |
| 30–40 分钟 | 核对失败路径、权限与回滚 | 门禁与回滚条件 |
| 40–45 分钟 | 指定负责人、复查日期与证据 | 行动项 |
评审的产出不是“同意”，而是“可验证的条件”。没有条件的通过，等于把风险留给上线之后。
结论模板
方案: 回声售后编排 v3（拆分为小模型 + 校验两节点）
结论: 有条件通过
基线: 2026-10-27 至 2026-11-03，按链路拆分，含重试与失败任务
改动: 拆节点、共享上下文 3,200 token、新增两次交接
预期: 成本 4,240 → 3,786 微元（-10.71%）
端到端 1,200 → 1,269ms（+5.79%）
整链成功率不低于 49.8%，单步失败预算 13.02%
条件: 1) 交接契约补齐版本与空值处理（负责人：编排组）
2) 校验节点保留独立预算下限（负责人：平台）
3) 灰度 10% 观察 48 小时，失败率超标自动回滚（负责人：平台）
复查: 2026-11-12，带成功交付成本、整链成功率与回放样本
模板里的数字是示例值，不是承诺值。评审要确认的是“这些数字怎么算出来”，而不是“数字好不好看”。
上线后复盘表
| 项目 | 预期 | 实际 | 差异原因 |
|---|---|---|---|
| 每次成功交付成本 | 8,004 微元 | ||
| 整链成功率 | ≥49.8% | ||
| 单步失败率 | ≤13.02% | ||
| 交接 token | 820/次 | ||
| 端到端 p95 | 1,269ms | ||
| 复用率 | ≥28.47% | ||
| 人工介入率 | 基线不变 | ||
| 部分交付率 | 基线不变 |
复盘表在灰度结束后一周填写。差异超过预期 20% 的项目必须给出原因；给不出原因的，视为实验设计有缺陷，而不是“模型不稳定”。
评审中最常见的三个误区
误区一：只审结构图，不审失败路径。 图能说明“正常情况下怎么走”，说明不了“某个节点超时后谁来收尾”。评审要把每条边的最坏情况问一遍。
误区二：只审单节点，不审交接。 每个节点单独看都达标，接在一起却失败，问题通常出在契约、上下文与重试预算。交接是编排特有的成本，也是最容易漏审的部分。
误区三：只审这一次，不审退出条件。 编排会随模型、提示、业务规则一起漂移。没有灰度、回滚与复查日期的方案，上线那天就是它最后一次被认真检查。
小结
编排评审的本质，是问四个问题：结构是否成立、失败是否可控、成本是否算清、权限是否收得住。
六十五问不必一次问完。先问结构、失败与权限三组，大多数方案的风险会在这三组里暴露；成本与评测放在第二轮，演进与平台化留到方案稳定之后再谈。
评审结束前，把结论写成条件，把条件写进复盘表。清单只有被下一次复盘引用，才算真正生效。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。