用途
inquiry-intake 是服务流程的入口环节，用于在每次服务运行开始时，对客户咨询进行结构化受理，并执行确定性的意图分类。其目标是把非结构化的咨询输入转成带意图标记的结构化数据，供后续环节使用。
主要能力
- 原文捕获：对来自聊天、邮件、语音转写等渠道的咨询文本逐字保留，同时记录渠道与语气。
- 显式诉求标记：把客户明确提出的请求（如立即退款、善意补偿）记为标志位。
- 意图分类：通过 scripts/intent_classify.py 脚本，结合 service-config.json 对咨询进行分类，输出 classified.json。
- 优先级规则：当 DNR 与通用 WISMO 同时匹配时，DNR 优先，因为该矛盾路径涉及安全。
- 置信度处理：低于置信度下限时转为交接处理，而不是给出猜测性回答。
- 流程衔接：受理只是“一跳”，应在同一次运行中继续进入 context-assemble，不因等待随案附带的 records.json 而暂停。
输入
- 原样咨询文本（聊天、邮件、语音转写）
- 渠道、客户 id、订单参考号
- 随案例附带的数据抽取文件 records.json（OMS 订单、承运商扫描、忠诚度信息）
- 配置文件 config/service-config.json
- 输出为入口跳转，其模式定义见 contracts/
使用方式
- 逐字捕获文本，记录渠道与语气，并把显式诉求记为标志位。
- 运行分类脚本： scripts/intent_classify.py --inquiry inquiry.json --config service-config.json --out classified.json
- 若置信度低于下限，则走交接路径，绝不猜测答案。
- 不要停顿等待随案附带的 records.json，直接继续 context-assemble。
- 输出 classified.json（即 {intent} 跳），直接交给 context-assemble。
适用场景
适用于客户服务流程的起始阶段，尤其是需要通过确定性引擎对多渠道咨询做意图分类、并需要严格控制安全相关矛盾路径优先级的场景。
限制与约束
- 受理阶段不产出解决方案内容，也不做任何承诺。
- 意图须引用分类体系，客户原话须逐字保留。
- 无法分类或存在歧义时，走交接数据包路径。
- 收费方式、价格、平台支持详情、具体效果指标暂未提供。