《互联网产品的 AI 架构·多能力编排与任务闭环》序

一个请求，四个能力

「回声」的客服助手收到一句话：「这款商品能不能退，帮我下单。」

一句话里有四个动作：先查这件商品和这笔订单的退货政策，再判断用户到底想退货还是想下单，然后组织一段能解释条件的答复，最后如果用户确认，还要真的发起下单或退款。四个动作分别对应检索、意图判断、答复生成与外部动作四类能力。

单看每一个能力，团队都很熟：检索有召回率指标，意图判断有分类准确率，答复有语气规范，下单有幂等与权限。卷一与卷二已经把每个能力的契约、预算、延迟与成本拆得很细。

但把四个能力串起来，问题变了。

检索没有命中政策时，意图判断还要不要跑？答复已经告诉用户「可以退」，下单却因为库存或权限失败，前面那段话算不算错？用户中途改口说「那算了，先别下单」，已经发生的检索与答复要不要计入这次任务的成功率？

这些问题不属于任何一个单能力。它们属于能力之间的连接。

编排不是把单能力相加

「回声」在卷二末尾做过一个三能力实验：检索重排、文档摘要、私信回复依次执行，每个能力都已经单独优化过。

按单能力账单相加，一条请求的预估成本是 4,240 微元。实际编排执行后，成本是 3,786 微元，降了 10.71%。看起来是好事。

但延迟从 1,200ms 涨到 1,269ms，多了 5.79%。失败时的表现也更难解释：摘要失败以后，回复该跳过、重试，还是拿着半截摘要继续？这个问题在单能力视角下根本不存在。

成本降了，延迟涨了，成功率变成一个需要重新计算的数。三个变化同时发生，说明编排不是一次加法，而是一次结构变换。

结构变换会改变三样东西：钱的流向、时间的分布、失败的形状。

四类新增成本

把三能力实验拆开，多能力编排至少新增四类成本。

四类成本里，只有第一类容易被看见，因为它对应一笔明确的调用费。后三类都藏在 token 与概率里：上下文复用决定省多少，结果传递决定加多少，失败传播决定这些节省能不能兑现。

这四类成本也构成了卷三的四个基本问题：传什么、复用多少、怎么传、失败怎么办。

编排的三种形状

同样是多能力，连接的形状不同，成本结构也不同。

串行最容易理解，也最容易低估延迟。并行能压缩墙钟时间，但会放大峰值并发，汇合时还要处理部分结果。条件分支把选择权交给判断节点，判断准确率不够时，后面的能力再强也没有用。

第 1 章会把三种形状放进同一个请求里对比，第 3 章再把它们写成执行图。这里先建立一个直觉：编排的成本不只看有几个能力，还看它们怎么连。

交接税：820 token 与 35ms

编排的第一笔固定开销发生在每次交接。

三能力场景里，每个能力独立调用时都要携带完整的 3,200 token 共享上下文。编排时，首跳携带完整上下文，后续只传 600 token 增量上下文与 220 token 上一跳结果，合计每次交接 820 token。

820 token 不是免费的。它要按输入单价重新计费，还要占下一跳的上下文窗口。交接越多，这笔税越重。

延迟同理。每次交接额外 35ms。三能力链路有两次交接，约 70ms；开头那个四能力请求有三次交接，就是 105ms。单看一次 35ms 很小，放进一条长链路就不再可以忽略。

交接税的关键在于：它不随能力变聪明而下降。模型再快，交接仍然要传数据、要序列化、要重新计费。它是编排结构自带的成本。

上下文复用与 28.47% 回本线

编排也有省钱的一面：共享上下文不必每次全价重算。

三能力场景假设前缀复用率 60%，缓存输入单价是全价的 10%，也就是缓存折扣 90%。共享上下文在首跳全价，后续按复用比例计价。

但复用不是无条件的。交接 token 为 820，共享上下文为 3,200，缓存折扣为 90%，回本复用率是：

820 ÷ (3,200 × 0.9) = 28.47%

复用率低于 28.47% 时，共享上下文不如每次直接复制；高于它，编排才开始省 token。这个数字与单价无关，只与 token 结构有关。

这也是卷三要反复强调的一件事：复用率不是一个可以拍脑袋填 100% 的参数。提示改版、租户隔离、缓存容量、上下文顺序都会让它下降。复用率跌破回本线，编排的成本优势会先消失，延迟劣势却仍然存在。

失败传播与 13.02% 单步预算

编排的第三笔开销来自失败。

单能力的失败是局部失败：重试一次，或者降级返回。编排里的失败会沿着链路传播：上游失败，下游可能没有输入；下游重试，上游可能已经计费；一条链路三步，每步 1% 的失败率，整体成功率不是 97%，而是三个成功概率的乘积。

三能力场景、每步允许 1 次重试、目标整体成功率 95% 时，单步失败率上限是 13.02%。超过这个值，整条链路就守不住 95%。

这个数字解释了一个常见现象：编排在实验室里总是更省，因为实验室只测成功路径；上线后可能更贵，因为失败路径的重试与浪费没有进模型。

失败传播不能靠一句「加重试」解决。重试会同时放大成本与延迟，必须有全局预算；跳过能省钱，但可能没有结果；用部分结果继续，则需要先定义什么叫「部分可用」。

卷二留下的三个问题

卷二 13.3 把单能力优化收口时，给卷三留了三个必须回答的问题。

第一，跨能力调用：哪些上下文必须随调用传递，哪些可以只传引用、摘要或游标？传得越多，越不容易丢信息，也越贵。

第二，上下文复用：共享前缀的复用率低于多少时，传递成本会超过复制成本？28.47% 是一个可计算的起点，不是一个通用常数。

第三，失败传播：上游失败后，下游应该跳过、重试，还是用部分结果继续？跳过省钱但可能没有结果，重试提高成功率但放大成本，部分结果则需要定义验收标准。

这三个问题贯穿卷三的十三章。每一章至少回答其中一个侧面，第 13 章再把它们收束成一套可评审的编排基线。

四卷的分工

这套书按「边界—效率—协同—治理」四层展开。

前两卷优化的是节点，卷三优化的是边。

节点优化有明确的局部指标：一个能力的 p95、单次成本、成功率。边的优化没有局部指标，只有端到端指标：一条任务是否完成、完成得对不对、花了多少、失败时用户看到了什么。

这就是卷三的位置：它把前两卷的节点结论组装成任务，同时把任务层面的新问题暴露出来，交给卷四治理。

一个反例：把所有能力塞进一个 Agent

面对多能力，最诱人的方案是「让模型自己规划」：把所有工具描述交给一个 Agent，让它决定调用顺序。

这个方案在演示里很好看，在任务闭环里通常先撞三堵墙。

第一，权限。Agent 可以决定调用退款接口，但它不知道该用谁的权限、要不要二次确认、失败后能不能重放。权限不是工具描述能表达的。

第二，成本。自主规划会探索分支，探索意味着额外调用。固定编排跑一次的成本，Agent 可能跑三次才收敛，而且每次路径不同，成本无法预估。

第三，验收。固定编排的失败可以归因到具体节点；Agent 的失败往往是一段轨迹，回放与复现都更难。

卷三不反对 Agent，但把边界放在第 12.3 节：先用固定或半固定编排把任务闭环跑稳，再讨论哪些环节可以交给自主规划。顺序反过来，团队会在权限、成本与验收上同时失控。

本卷回答什么

卷三的十三章分成五段。

第一段是结构与契约（第 1–2 章）：一个请求需要几个能力，串行、并行与条件分支怎么选，能力之间传什么，交接成本与复用回本线怎么算。

第二段是执行与状态（第 3–4 章）：把编排写成图，做拓扑执行与并行汇合，处理检查点与幂等；共享上下文有哪几种形态，节点之间怎么分预算，长任务的会话状态放在哪里。

第三段是失败与并发（第 5–6 章）：失败怎么分类，部分结果怎么验收，编排级重试预算与熔断怎么设；并行分支的收益与竞争，人工节点怎么插入，长任务怎么异步交付。

第四段是验收与成本（第 7–8 章）：端到端评测集、失败归因、回放调试；节点预算、超支裁剪顺序、编排经济性复核。

第五段是安全、观测、平台与演进（第 9–13 章）：权限传播、外部动作授权、注入传播；追踪字段、节点 SLO、事故止血；声明式与代码编排、扩展点、能力目录；重构路径、灰度、Agent 边界；最后用「回声」的编排基线与一次方案评审收口。

十三章覆盖的不是十三个工具，而是同一条任务链路上的十三个判断点。

本书不承诺 L3

卷一建立的三级可运行性，卷三继续沿用。

卷三以 L1、L2 为主。所有关于下单、退款、发券的外部动作，在实验工程里都是模拟器，不连接任何真实业务系统。

不承诺 L3 不是偷懒，而是边界。真实外部动作涉及权限、幂等、审计与回滚，任何一项都与具体公司的系统强绑定。书里能给出的是判据与结构：什么时候该授权、失败后能不能重放、部分结果能不能对外展示。具体怎么接，必须由读者在自己的系统里完成。

数字从哪里来

书里的数字只有三个来源。

没有第四种来源。没有生产环境的数据，也不写「业内通常」。

序里出现的 4,240 → 3,786 微元、1,200 → 1,269ms、820 token、3,200 token、90% 缓存折扣、28.47% 回本线、13.02% 单步失败预算与 35ms 交接延迟，全部来自三能力示例样本的运行与推导。换一套 token 结构，这些数字都要重算；不变的是算法与判据。

怎么读

三条路径，按问题选。

1. 建设路径：1.1 → 2.1 → 2.2 → 3.1 → 3.2 → 4.1 → 4.2 → 5.1 → 7.1 → 8.1 → 13.1。适合第一次把多个能力串起来。
2. 排障路径：5.1 → 5.2 → 5.3 → 7.2 → 7.3 → 10.1 → 10.3。适合已经在线上遇到「整条链路失败但不知道是哪个节点」。
3. 平台路径：3.1 → 9.1 → 10.2 → 11.1 → 11.3 → 12.1 → 12.2 → 13.1。适合要把一条编排复制给多个团队。

三条路径都建议先读第 1 章与 2.1。结构没定，契约没定，后面的成本与失败分析没有对象。

写给谁

• 已经把单能力接进产品，开始被「多步任务」拖住交付的团队。
• 正在设计客服、运营、交易类闭环，需要在固定流程与自主 Agent 之间做选择的架构师。
• 负责网关或平台，需要把多个能力组织成可复用编排的工程师。
• 准备做编排评审，需要一套可判定标准的负责人。

如果还没有能力契约与基础观测字段，建议先读卷一；如果还没有单能力的成本与延迟口径，建议先读卷二。卷三的所有判据都建立在这两层之上。

任务闭环的三个判据

一条多能力链路是否闭环，可以用三个问题验收。

第一，任务有没有明确的完成态？是「答复已发送」，还是「订单已创建」？完成态不同，成功率的定义就不同。

第二，每一步的输入输出有没有契约？上游给下游的是完整对象、摘要还是引用？没有契约，交接就只能靠约定俗成。

第三，失败时有没有可展示的结果？完整失败、部分可用、降级答复，三者对用户意味着完全不同的体验，必须提前定义。

三个判据分别对应第 2 章、第 5 章与第 7 章。它们不保证编排一定成功，但能保证失败时团队知道失败在哪。

一个可以立刻做的检查

读完这篇序，不必等读完正文，可以先挑一条自己产品里的跨能力请求，回答四个问题。

第一，这条请求经过几个能力？把每一步写下来，标出哪些是串行、哪些可以并行。

第二，每次交接传了什么？是完整上下文、摘要、引用，还是一个游标？如果答不上来，说明交接契约还没有被显式设计。

第三，如果中间一步失败，用户看到什么？是错误、是降级答案，还是半截结果？这个答案有没有被产品确认过？

第四，这条链路的成功率怎么算？是每一步成功率的乘积，还是只看最后一步？分母不同，结论会完全不同。

四个问题都答不上来，正说明卷三有存在的必要。它们也是后面所有编排设计的起点。

最后的提醒

多能力编排的难点，不是把调用串起来，而是让连接处的成本、状态与失败都可解释。

一次编排是否值得，不取决于单个能力便宜多少，而取决于三件事：交接 token 有没有越过复用回本线，单步失败率有没有守住整体预算，失败时用户拿到的结果是完整、部分还是错误。

这三件事都能被计算，也都能被验收。卷三要做的，就是把它们从经验判断变成可复用的判据。

小结

从一个「能不能退、帮我下单」的请求出发，可以看到编排新增的四类成本：跨能力调用、上下文复用、结果传递与失败传播。三能力示例里，编排把成本从 4,240 降到 3,786 微元（-10.71%），把延迟从 1,200 拉到 1,269ms（+5.79%）；回本复用率是 28.47%，单步失败预算是 13.02%，每次交接 35ms。

卷三不追求「更复杂的编排」，而追求「连接处可解释的编排」。能解释每一次交接传了什么、省了多少、失败后怎么办，编排才敢进入真实任务。