sent-routing-strategist

Sent 路由策略指南

路由相关的误解会给 Sent 带来最昂贵的后果。几项事实决定了几乎所有选择：

1. channel 数组是广播列表，而不是优先级顺序。 有两个收件人时，["whatsapp", "sms"] 会创建 4 条消息并产生 4 笔费用。不存在 fallback 字段，也没有按顺序优先的语法。
2. 自动路由是回退机制。 省略 channel，或发送 ["sent"]，平台就会选择路由；发生路由级故障时，还会在最多 3 组不同的渠道和提供商组合之间重新路由。

决定渠道值

意图	正确的值	原因
无论哪种方式最合适，都要联系收件人	省略 channel 或使用 ["sent"]	启用路由选择和重新路由
保证使用某个特定渠道	["sms"]、["whatsapp"] 或 ["rcs"]	固定渠道会将匹配限制在该渠道内，绝不会跨渠道
有意在多个渠道上发送相同内容	["whatsapp", "sms"]	广播；每组组合预计会产生 1 条消息和 1 笔费用
“先尝试 RCS，失败后改用 SMS”	省略 channel 或使用 ["sent"]	有序数组会触发广播；自动路由才会执行回退

s​​ent、sms、whatsapp 和 rcs 之外的任何值都会返回 400。当用户要求按顺序回退时，应在编写代码前明确指出这一误解，因为其失败后果是重复投递和重复费用，而不是报错。

固定渠道需要放弃什么

固定渠道会将路由匹配限制在指定渠道内。不含渠道约束的规则仍会匹配，并解析到固定的渠道，因此固定渠道并不要求必须存在渠道专属规则。固定渠道发送绝不会切换到其他渠道，不过规则允许时，仍可能在同一渠道内切换提供商。如果固定渠道上不存在路由，消息会以 FAILED 结束，并显示未匹配到路由——不会悄悄回退。

当合规、合同或内容约束要求使用特定渠道时，才固定渠道。其他情况下，优先使用自动路由。

读取结果

POST /v3/messages 会返回 202，其中包含每位收件人的 message_id 值。对于自动路由，响应中回显的每位收件人渠道并非已解析的路由，之后也不会更新。应根据以下证据查明实际情况：

问题	证据
实际尝试了哪条路由	message.routed 事件，或路由后 GET /v3/messages/{id} 返回的 channel
收件人的设备是否已收到消息	message.delivered
尝试过哪些路由，以及顺序如何	GET /v3/messages/{id}/activities
消息为何停止	终态状态及渠道值

终态状态解读

状态	含义	正确的处理方式
FAILED	一次路由尝试失败；自动路由仍可能将另一次尝试加入队列	在将其视为最终结果前，检查最新消息状态和活动记录
FILTERED	策略门控——同意拦截或路由拒绝	切勿重试；同意拦截属于合规停止
BLOCKED	账户前置条件未满足——余额、开户配额、模板未获批准	修复账户条件，然后重新发送
SCHEDULED	根据免打扰时段策略暂存	等待；消息会自动重新进入处理流程

如果结果中的 channel 为 auto，则表示消息在尝试任何路由之前就已结束。可能的原因包括没有匹配的路由、模板参数无效、同意拦截或账户前置条件未满足。账户前置条件不会导致发送请求被拒绝：请求会以 202 被接受，受影响的消息则会显示为 BLOCKED。

对于这些情况，Sent 会在消息上记录内部的发送时原因代码，但不会在 API 响应或 Webhook 中返回这些代码，因此诊断需要结合状态与渠道值以及活动历史记录。可观察证据与根本原因的对应关系见 references/routing-diagnosis.md。

重新路由行为

只有当最终失败表明存在其他路由可能解决的路由或运营商问题时，才会重试失败的路由：通过此路由无法送达、服务提供商服务不可用、服务提供商超时或传输错误。其他所有失败都会保持为 FAILED。

重新路由会复用**同一个 message_id**并重新运行整个流程，因此 message.queued 和 message.routed 会再次触发，每次尝试都会重新应用同意门控，并排除已尝试过的路由。初始发送和所有重新路由中，不同的渠道与服务提供商组合最多为 3 个。

客户常问的 WhatsApp 转 SMS 行为就是一个具体示例：WhatsApp 消息已被接受，随后因接收方原因失败，系统便会重新路由，并记录一条针对该接收方的规则，表明该号码无法通过 WhatsApp 送达，因此后续自动发送会跳过该接收方的 WhatsApp。此行为需要自动路由；固定使用 WhatsApp 发送不会触发此行为。

自动路由如何选择路由

路由来自平台维护的规则；发送时，系统会根据接收方属性（国家／地区、号码前缀、完整号码、运营商、号码类型、是否已携号转网）、发送方、模板属性、渠道以及目标是否为国际号码来评估这些规则。排序顺序为：精确接收方规则优先，其次是账户范围规则优先于全局规则，然后依次按匹配具体程度、规则优先级、号码前缀长度排序，最后优先采用较早的规则。未激活、已删除、已过期以及低于阈值的规则会被排除。如果模板在该渠道上有明确的非已批准审核状态，则对应候选项会被剔除；若该渠道没有已记录的审核状态，则不会因此受阻。第一个剩余候选项会胜出，其余候选项仍可作为备用路由。

渠道没有固定的偏好顺序，因此绝不要承诺“先 RCS，再 WhatsApp，最后 SMS”。在声称某条特定路由为何被选中之前，请先阅读 references/routing-model.md。

成本和用量影响

由于广播会按接收方数量成倍增加消息数，发送前请根据预期支出审查任何多渠道数组。向 1,000 位接收方发送消息并使用两个渠道，会产生 2,000 条消息。每个请求的接收方上限为 1,000；文档建议将完整批次的发送速度控制在每秒约一个请求，以符合每分钟 200 个请求的限额。

目前，RCS 支持文本和最多 4 个建议按钮（映射自模板按钮），且每条外发 RCS 消息都会附加一个 STOP 按钮。设计固定使用 RCS 的流程时，不要依赖富媒体卡片、轮播或媒体内容。

边界

使用 sent-messaging 执行单次发送并确认，使用 sent-two-way-messaging 处理同意和入站关键词语义，使用 messaging-performance-analyzer 分析整体送达率回归，并使用 sent-webhook-engineer 接收并去重本技能教你读取的事件。