模式总览
象信一号不是一个"放进去就能自己跑"的智能体，它更像一枚专做判断的芯片：你的程序把材料（状态）和一组带类型的问题交给它，它在一次调用里给出带概率的答案，接下来怎么走，由你的代码决定。
把一件复杂的业务拆成若干个原子判断，再用代码把这些判断拼成完整的系统行为——这是用好象信最关键的思维方式。本节整理了四种在实践中反复出现的拼法。
四种模式
| 模式 | 一句话说明 | 主要收益 | 典型场景 |
|---|---|---|---|
| 推测式扇出 | 一次调用里把可能用到的问题全部问完，由代码事后挑选有用的答案 | 省钱、省时间 | 工单分诊、投诉处理、表单审核 |
| 置信度门控路由 | 把"答案是什么"和"有多确定"当作两个独立维度，确定就自动处理，不确定就升级 | 可靠、安全 | 退款审批、风控、内容审核 |
| 组合评分 | 把一个笼统的综合判断拆成若干原子评分，在代码里加权合成 | 可解释、可调 | 线索评分、简历打分、质检 |
| 意图路由 | 先判断请求属于哪一类，再分发给确定性代码、专用大模型或人工 | 省钱、低延迟 | App 智能助手、热线分流 |
它们如何组合
这四种模式并不互斥，一个真实系统往往同时用上好几种。以一个银行 App 的智能助手为例：
text
用户消息
│
▼
┌─────────────────────────────────────────────┐
│ 一次象信调用（推测式扇出） │
│ · intent Choice 意图分类 │
│ · risk_* Score 若干风险维度 │
│ · needs_human Noul 是否明确要求转人工 │
└─────────────────────────────────────────────┘
│
▼
代码：意图路由 ── 查余额 ──▶ 确定性接口
│ └─ 理财咨询 ──▶ 专用大模型
│ └─ 其他 ─────▶ 人工客服
▼
代码：置信度门控 —— 意图置信度低于阈值 → 先向用户确认
▼
代码：组合评分 —— 多个风险分加权 → 超过红线则拦截- 推测式扇出决定了"怎么问"：所有问题放进同一次调用，状态只传一次。
- 意图路由和置信度门控决定了"怎么走"：先看答案去哪条路，再看置信度够不够直接走。
- 组合评分决定了"怎么算"：多个维度的判断在代码里合成一个可以调参的数。
共同原则
无论使用哪种模式，下面几条原则都适用：
- 每个问题只问一件事。 需要"想一想"才能回答的问题，说明它该被拆开。
- 逻辑留在代码里。 阈值、权重、分支都写成常量，便于审阅和回滚，不要藏进提示词。
- 用你自己的数据定阈值。 文档里的数字都是示意，上线前请在带标注的样本上测一遍。
- 不确定就升级。 低置信度的答案交给人工或更强的模型，而不是硬猜。