《互联网产品的 AI 架构·多能力编排与任务闭环》目录与学习路径

这一卷在四卷中的位置

《互联网产品的 AI 架构》计划四卷：

卷一建立契约、网关与观测；卷二建立度量、成本与门禁。卷三把单个能力串成任务，回答卷二 13.3 留下的三个问题：跨能力调用传什么、上下文复用回本线在哪、失败如何传播。

全书结构

13 章 39 节，按“结构 → 交接 → 执行 → 状态 → 失败 → 验收 → 治理 → 收口”组织：

逐章篇目

第 1 章 编排问题与结构

先回答“一个产品请求到底需要几个能力”。把回声的三条链路拆成节点与交接，比较串行、并行与条件分支的成本与失败概率，并给出“该编排还是该固定流程”的判据。

• 1.1 一个请求要几个能力：回声的三条真实链路
• 1.2 串行、并行与条件分支
• 1.3 什么该编排，什么该固定流程

第 2 章 编排契约与数据流

编排的失败大多发生在节点之间。本章定义节点间传什么、传多少、怎么校验：结构化结果、引用与游标、交接成本与复用回本线，以及编排层对外的版本契约。

• 2.1 能力之间的数据契约
• 2.2 交接成本与复用回本线
• 2.3 编排层的输入输出与版本

第 3 章 执行图与调度

把编排写成图，执行才有边界。节点、边、终止条件的图模型，DAG 校验、拓扑执行、并行汇合，以及检查点与恢复时的幂等边界。

• 3.1 把编排写成图
• 3.2 拓扑执行与并行汇合
• 3.3 检查点、恢复与幂等

第 4 章 上下文与状态

上下文是编排里最贵的共享资源。全量复制、共享前缀与检索句柄三种形态，各自的成本与失效方式；预算如何分到节点；长任务的会话状态与记忆边界在哪里。

• 4.1 共享上下文的三种形态
• 4.2 节点间的上下文预算分配
• 4.3 长任务的会话状态与记忆边界

第 5 章 失败传播与部分结果

上游失败后下游做什么，是编排设计的核心。失败分类、部分可用的验收标准，以及编排级重试预算与熔断如何避免“越重试越贵”。

• 5.1 失败分类与处理策略
• 5.2 部分可用的验收标准
• 5.3 编排级重试预算与熔断

第 6 章 并发、人工与异步

并行分支带来收益也带来竞争；人工节点把延迟从毫秒拉到小时；异步交付要求任务态、通知与回调都有契约。本章讨论这三类非纯模型节点。

• 6.1 并行分支的收益与竞争
• 6.2 人工介入节点
• 6.3 长任务与异步交付

第 7 章 编排的质量验收

编排的质量不能用单节点指标拼出来。端到端评测集、失败归因到具体节点、以及回放与可复现调试，构成编排的验收闭环。

• 7.1 端到端评测集
• 7.2 失败归因：哪个节点造成的
• 7.3 回放与可复现调试

第 8 章 编排的成本与预算

预算必须分到节点，否则超支时不知道该砍谁。节点预算、超支裁剪顺序与编排经济性复核，把卷二的成本模型落到多条链路上。

• 8.1 把预算分到节点
• 8.2 超支时的裁剪顺序
• 8.3 编排经济性复核

第 9 章 编排的权限与安全

多能力意味着多一次权限传递。跨能力的权限传播、外部动作的授权边界，以及提示注入如何在节点之间扩散，是编排特有的安全面。

• 9.1 跨能力的权限传播
• 9.2 外部动作的授权边界
• 9.3 注入在多能力间的传播

第 10 章 编排的观测与运维

编排的故障定位比单次调用难一个量级。最低观测字段、节点级 SLO 与整体 SLO 的关系，以及事故止血与复盘的最小流程。

• 10.1 编排链路的最低观测字段
• 10.2 节点级 SLO 与整体 SLO
• 10.3 编排事故的止血与复盘

第 11 章 编排平台化

编排最终会变成平台能力。声明式与代码编排的取舍、引擎扩展点的边界、多团队共享能力目录的治理方式。

• 11.1 声明式编排与代码编排
• 11.2 引擎扩展点与插件边界
• 11.3 多团队共享能力目录

第 12 章 演进与边界

编排不是一次设计出来的。从单能力到编排的重构路径、编排版本与灰度，以及什么时候该从固定编排走向自主 Agent。

• 12.1 从单能力到编排的重构
• 12.2 编排版本与灰度
• 12.3 从固定编排到自主 Agent

第 13 章 卷三收口

把前三章的方法合成一条可运行基线：回声的编排清单、交接成本与失败预算，再评审一次真实方案，并把问题交给卷四。

• 13.1 回声的编排基线
• 13.2 一次编排方案评审
• 13.3 进入卷四：平台化与治理

三条阅读路径

不必按顺序读完。按当前问题选一条：

• 第一次做多能力链路：
• 正在实现编排引擎：
• 上线前的编排评审：

第一条用于把一条手工流程改成编排，第二条用于实现执行引擎与状态恢复，第三条用于上线前的失败、成本与安全评审。

读完卷三应能回答的十二个问题

1. 这条链路为什么需要多个能力？少一个能力，产品会损失什么？
2. 每次交接传的是结构化结果、摘要还是引用？谁来校验？
3. 共享上下文的复用率是多少？低于回本线时为什么还要共享？
4. 哪个节点失败可以跳过，哪个必须中止，哪个可以降级为部分结果？
5. 整条链路的成功率和单步失败预算是多少？
6. 重试发生在节点内还是编排层？会不会重复执行外部动作？
7. 人工节点的超时是多久？超时后流程往哪走？
8. 端到端评测集覆盖了哪些失败路径？归因能定位到节点吗？
9. 预算怎么分到节点？超支时先砍哪个节点？
10. 跨能力调用时，权限是放大还是收敛？外部动作谁授权？
11. 一次编排事故，多久能定位到具体节点与版本？
12. 这条编排什么时候应该退回固定流程，或升级为自主 Agent？

答不上来的问题，就是下一次编排评审的输入。

实验工程 ai-lab

卷三在卷一、卷二的基础上新增 src/orch/：链路结构、节点间契约、执行图、上下文预算、失败传播、人工与异步、端到端评测、节点预算、权限传播、观测、平台化与演进。

# 在抽取后的 ai-lab 目录内
node --test test/orch/*.test.ts

三级验证口径：

每章的产出物

每章结束时，团队应该手里多出一样东西，而不只是读完三篇文章：

常见问题

编排是不是就是搭一个工作流引擎？ 不是。引擎只是执行器；本卷讨论的是节点之间传什么、失败怎么传播、预算与权限怎么跟着链路走。

能不能一步到位上自主 Agent？ 大多数产品请求的结构是稳定的。固定编排更便宜、更可测；只有在步骤数量与路径无法预先枚举时，自主决策才划算。

卷三需要卷二的数据吗？ 需要。交接 token、复用回本线、失败预算都直接来自卷二 13.3；没有这些数字，编排决策只能靠感觉。

为什么反复强调失败传播？ 编排的失败会沿链路放大。单步 99% 的成功率，串五步只剩约 95.1%；不加失败预算，承诺就无法兑现。

每节怎么读

每一节的结构是固定的，读的时候可以按同一个顺序推进：

1. 问题：这一节要解决的编排问题是什么，先不看答案。
2. 判据：作者给出哪些可判定的条件，哪些是案例值、哪些是通用规律。
3. 代码：把 // file: 指向的模块抽到 ai-lab，跑一遍测试，看断言是否复现文中数字。
4. 边界：「常见错误与边界」列出的是这一节不适用的情况，比结论更值得记住。

如果时间有限，先读每节的判据表与边界清单；需要动手时再回到代码块。

版本与口径

• 运行时：Node 26.5.0，直接运行 .ts，依赖类型剥离。
• 代码限制：禁用 enum、namespace 与构造函数参数属性；本地导入带 .ts 后缀。
• 依赖：只使用 node: 内置模块，零第三方依赖。
• 成本：整数微元；延迟：毫秒；成功率与复用率写明分母。
• 除明确标注为本机测试输出的数字外，一律是案例假设值。

小结

卷三只做一件事：把多个能力组织成一条可解释、可预算、可从失败中恢复的任务链路。

结构决定成本，交接决定失败面，观测决定能否定位。三者都写进契约，编排才不是把单点问题放大成系统问题。