Jev 四个官方 pattern 怎么选：fan-out 到 confidence 路由

先说结论

1. 这四个模式不互斥，也不是同一层“路由”。它们分别解决并行候选、多维合成、意图分流、置信门控。
2. 官方只给每个模式一句话定义，没有规定四者组合顺序；本文后面的组合链路是我的工程判断。
3. 如果业务是“一次调用多问几个问题，避免串行往返”，优先看 fan-out；如果业务是“多个信号合成一个分数排序”，看 composite scoring；如果是“先判意图再决定走哪个 handler”，看 intent routing；如果是“高风险动作要置信度兜底”，看 confidence-gated routing。
4. fan-out 的主要官方收益是降低延迟和往返次数，不是降低 token 成本；它可能增加问题数量和 token 消耗。
5. 官方示例里的阈值如 0.5、0.6、0.85、1.5、0.7，都是示例场景参数，不能当成全局默认推荐。

官方汇总页如何给这四个模式定位

Patterns 汇总页 对这些模式的定位很短。官方原文是：

“TypeSafe is designed to sit within a larger system, powering decisions with AI. Learning to think in terms of discrete, atomic decisions that compose into complex system behavior is a key skill for getting the most out of TypeSafe.”

它把四个 pattern 并列列出，各自的 what it does 分别如下：

模式	官方汇总页定义
Speculative fan-out	“Send many questions in a single call, including speculative ones, and let your code decide what’s relevant”
Confidence-gated routing	“Utilize confidence as a second decision axis to build safer systems”
Composite scoring	“Combine several dimensions of analysis into a single score”
Intent routing	“Classify a user’s intent and route to the appropriate handler”

这里可以看出：它们不是四个并列的“路由算法”，而是四种不同的决策形态。下面逐个展开。

Speculative fan-out：一次调用铺开，代码后置筛选

官方 fan-out 页面 的首句是：

“Send many questions in a single call, including speculative ones, and let your code decide what’s relevant.”

这个模式的关键不是模型内部路由，而是减少 API 往返。官方写明：

“Because TypeSafe supports sending many questions in a single API call, we recommend putting all of the questions your system needs in a single request, and then using code to decide what is relevant after the fact. All questions are evaluated in parallel, so adding more questions usually has little effect on response time.”

官方 support ticket triage 示例里，系统一次询问 category、bug_severity、has_reproducible_steps、refund_requested 和 frustration。如果分类结果不是 bug report，那么 bug_severity 和 has_reproducible_steps 就是 speculative answers，代码路径直接忽略它们。示例代码大概是：

category = response.answers["category"]
bug_severity = response.answers["bug_severity"]
bug_repro = response.answers["has_reproducible_steps"]
if category.choice == "bug_report":
    if bug_severity.score > 1.5 and bug_repro.noul > 0.6:
        escalate_to_engineering(ticket_id, severity="high")

这里 choice、score、noul 都是官方示例里出现的字段用法。要注意，这些字段在官方示例里怎么用，和 Primitives 字段表里完整定义是两件事；本文没有单独核对 Primitives 字段表。

Composite scoring：多维评分拆开，加权留在代码里

官方 composite scoring 页面 的首句是：

“Break a complex judgment into atomic scores, combine with weights you control in code.”

这个模式解决的是“多个信号合成一个分数”。官方简历筛选示例把复杂判断拆成 python_depth、team_leadership、system_design、generalist 几个维度，分别打分，再在代码里归一化和加权。官方示例代码简化后如下：

py = response.answers["python_depth"].score / 4
lead = response.answers["team_leadership"].score / 4
arch = response.answers["system_design"].score / 4
general = response.answers["generalist"].score / 4

# Senior IC
ic_score = (0.40 * py) + (0.10 * lead) + (0.40 * arch) + (0.10 * general)
# Engineering Manager
em_score = (0.15 * py) + (0.40 * lead) + (0.20 * arch) + (0.25 * general)

官方页面对这个过程有解释：

“Each dimension is normalized to 0–1 and weighted. The weights give you an easy way to adjust the relative importance of each dimension, without losing any of the nuance of the individual scores.”

复合评分适合排序场景。它不负责“分流”，而是把多个维度合成一个可解释、可调节的排名分数。

Intent routing：先分类，再走不同 handler

官方 intent routing 页面 的首句是：

“Classify incoming requests and route each to the optimal handler: deterministic logic, a specialist LLM, or a human.”

这个模式解决的是“先判意图，再决定走哪条业务分支”。官方客服路由示例里，先分类 intent 和 complexity，然后按分支走到确定性代码、专业 LLM 或人工。官方示例代码里出现了 intent.confidence < 0.5 转人工；intent.choice 分别到 order_status、product_question、return_exchange、complaint；投诉分支再用 complexity.score > 1 or low_confidence 判断是否升级人工。

官方还特别提醒：

“Note the additional confidence check on the complexity score. As discussed in Confidence, it is always important to consider the meaning of a low confidence score in the context of the system and the stakes of the decision.”

因此，intent routing 并不只是看 choice 分支。工程上它经常需要和 confidence 搭配，尤其是分类信心不足或复杂度判断不可靠的时候。

Confidence-gated routing：答案给什么，置信决定动不动手

官方 confidence-gated routing 页面 的首句是：

“Use confidence as a second axis. The answer tells you what; confidence tells you whether to act.”

这个模式的核心是把 confidence 当成第二决策轴。语音银行示例中，任何 action.confidence < 0.6 都会转人工；check_balance 在 0.6 以上即可执行；但 approve_transfer 必须 action.confidence > 0.85，否则先向用户确认。

官方对示例的解释是：

“The 0.6 floor catches anything the model is genuinely uncertain about. Above that floor, each action type has its own threshold based on the consequences of acting on a wrong classification.”

这句话很重要：0.6 是官方示例里的下限，不是平台全局默认阈值。不同动作的阈值应当按错误后果单独设定。

四模式对照表

模式	要解决的问题	典型输入	输出形态	什么时候别用
Speculative fan-out	一次调用同时铺开多个候选/追问，代码后置筛选，避免串行往返	一组问题，例如 category、bug_severity、has_reproducible_steps、refund_requested	response.answers 多个答案，代码忽略无关的 speculative 答案	问题有强依赖、分支极少、token 预算很紧
Composite scoring	多个独立信号合成一个可解释分数，用于排名	多个评分维度，例如 python_depth、team_leadership、system_design	每个维度归一化后加权得到 composite score	维度不独立，或业务只需要二元阈值
Intent routing	先分类用户意图/复杂度，再决定走哪条 handler	用户消息或 ticket 文本	intent.choice、confidence、complexity.score 驱动代码分支	意图空间很小，单一 handler 足够
Confidence-gated routing	用 confidence 做第二轴，低置信升级、高置信自动	用户答案 action 及其 confidence	行动分支：自动执行、确认、转人工	错误后果一致且都低风险，不需要差异化阈值

表格中“什么时候别用”是我基于官方示例做的工程判断，不是官方页面的原文禁令。

组合关系：我的判断

官方没有给出这四个模式的标准组合顺序。汇总页只是并列介绍；四个独立页面各自演示了不同场景，没有一页说“应先 intent routing 再 confidence-gated routing”。因此下面的组合关系是我的工程判断，不是官方推荐。

常见链路可以这样搭：

1. 先用 intent routing 把入口请求分流：这个请求属于 order_status、product_question、return_exchange 还是 complaint。
2. 在关键分支里加 confidence-gated routing：高风险动作 confidence 不够时升级人工或二次确认。
3. 对需要排序或筛选的复杂对象，用 composite scoring：拆出独立评分维度，再加权排名。
4. 如果一次决策里需要同时铺开多个可能相关的问题，用 Speculative fan-out 减少串行往返；但只在问题彼此不阻塞时用。

这个顺序不是固定的。官方 fan-out 示例里已经混合了分类、noul 门槛和后续代码路由；intent routing 示例里也混合了 confidence 和 complexity score。官方文档给的是模式工具，不是流水线模板。

和 primitive 的字段关系：只从官方示例代码观察

从四个官方页面的示例代码里可以看到这些字段用法，但这里只是官方示例里的用法，不等于完整 Primitives 字段表：

• choice 出现在 intent routing 和 confidence-gated routing 示例中，用来做行动/意图分支：例如 intent.choice == "order_status"、action.choice == "check_balance"。
• score 出现在 composite scoring 示例中，用来做评分输入：例如 response.answers["python_depth"].score。
• noul 出现在 fan-out 示例中，用来做门槛判断：例如 bug_repro.noul > 0.6、refund.noul > 0.7。这个用法看起来像护栏式门控，但官方页面没有把 noul 直接称为“护栏式门控”；这是我从示例代码里得出的理解。
• confidence 出现在 intent routing 和 confidence-gated routing 示例中，作为第二轴阈值判断。

由于本文没有单独打开 Primitives 字段表，我不能把 choice、score、noul 的完整语义写死。需要字段定义时，应去 TypeSafe 官方文档的 Primitives 页面核实。

成本提示：fan-out 省往返，但可能增 token

官方 fan-out 页面明确说：

“All questions are evaluated in parallel, so adding more questions usually has little effect on response time.”

这是【官方数据/官方描述】。但它讨论的是响应时间，不是 token 成本。并行执行不会让输入 token 免费；fan-out 增加了问题数量，通常会增加单次调用的输入 token 消耗。API 调用次数未必成倍增加，甚至可能因为合并一次调用而减少，但 token 成本需要按问题数量和提示词长度重新评估。

# 自己推算：fan-out 的 token 增量，只写关系，不写具体金额
# 单次输入 token 增量 ≈ Σ 每个 speculative question 的额外输入 token
# 总成本影响 = 单次输入 token 增量 × 输入单价（单价需另行核实）
# 官方页面只保证 latency 通常变化不大，不等同于成本不变

关于“官方定价 $42/十亿输入 token”这个说法，写作前收集到的信息里出现过，但本次可引用的一手来源里没有定价页，我未能核实该数字。因此本文不把它写成已核实的官方数据，具体金额请以定价页为准。

我的落地清单

• 先问：这是“分类后分派”“多信号排名”“并行候选”，还是“高风险自动/人工”问题？四者是不同决策形态。
• 有明确业务分支、handler 类型不同，用 intent routing；不要为了路由把每个问题都做成 LLM。
• 如果动作错了会亏钱、误操作或引起投诉，给 confidence-gated routing 加一道阈值；阈值按风险设，不直接抄示例。
• 多维评分排序时，用 composite scoring 把维度拆开；权重在代码里调，便于解释。
• 只有在多个问题独立、可以并行且能接受 token 增加时，才用 fan-out 合并一次调用。
• 组合顺序我倾向 intent → confidence → composite → fan-out 做扩展，但这不是官方推荐，按场景剪裁。
• 阈值 0.5、0.6、0.85、1.5、0.7 都是官方示例里的值，只能当作起点，不能当作平台默认阈值。

这次没核实的

• Primitives 完整字段表未能核实，本文只从四个 pattern 官方示例代码里观察 choice、score、noul、confidence 的用法。
• “官方定价 $42/十亿输入 token”未能从本次给定的一手来源核实，因此没有把该数字写进成本推算。
• 官方文档未给出四个 pattern 的组合顺序；本文的组合链路是作者工程判断。
• 官方示例中的阈值不是普适标准；是否适合其他风险等级需自行测试或查阅 Confidence 页。
• “noul 常用于护栏式门控”这一总结是本文从示例代码得出的理解，不是官方页面直接给出的术语定义。

参考来源

• Patterns 汇总页
• Speculative fan-out
• Composite scoring
• Intent routing
• Confidence-gated routing