# 对齐车机方案的实施流程复审 ## 1. 目标 本文档用于重新审视当前项目的实现方向，并将“对齐小鹏车机类方案”的核心流程、分支决策和典型场景演示明确下来。 目标不是做一个普通聊天机器人，而是做一个面向车机/客服/前台场景的低延迟执行型 Agent： - 简单请求本地快速闭环 - 复杂请求云端增强处理 - 多轮短句能够恢复上下文 - 多命令能够拆分为 workflow 执行 - 超出能力边界时明确拒绝或澄清 --- ## 2. 对齐车机方案的核心原则 结合前面参考的小鹏公开专利，可以抽象出下面几个工程原则： - 本地优先，云端增强，不是所有请求都直接走远端大模型 - 本地不是单模型，而是多支路并发 - 快反馈和最终反馈分离，首反馈必须短而稳 - 多轮短句优先靠上下文改写和缓存恢复，不是每轮重做完整规划 - 高风险动作必须确认 - 超能力边界时必须拒答，不能强行分类执行 --- ## 3. 总体流程图 ```mermaid flowchart TD A[用户语音输入] --> B[ASR 转文本] B --> C[文本归一化] C --> D[本地多支路并发] D --> D1[keyword / rule / trie] D --> D2[local bert classifier] D --> D3[context rewrite / cache] D --> D4[retrieval matcher] D1 --> E[本地融合分级器] D2 --> E D3 --> E D4 --> E E -->|高置信| F[直接执行或直接生成 workflow] E -->|中置信| G[等待 100~300ms 观察补充分支/云端结果] E -->|低置信| H[云端 planner / LLM / RAG] G --> H H --> I[生成 intent / workflow / clarify / reject] F --> J[插件执行] I --> J J --> K[首反馈 ack / progress] J --> L[最终反馈 result / clarify / reject] ``` --- ## 4. 本地与云端分工 ### 4.1 本地快链路 本地负责： - 高频固定控制类命令 - 已知业务集合内的快速意图识别 - 短句、省略句、连续调节的上下文恢复 - 简单任务的直接执行 - `<1s` 以内的首响应 本地组件： - `keyword / rule / trie` - `local bert classifier` - `context rewrite / cache` - `retrieval matcher` - `fusion grader` ### 4.2 云端慢链路 云端负责： - 多命令拆分 - 条件型请求理解 - 歧义消解 - 复杂问答 - planner 级 workflow 生成 --- ## 5. 本地分级决策图 ```mermaid flowchart TD A[本地多分支结果] --> B{融合分级} B -->|high| C[直接执行] B -->|medium| D[等待 100~300ms] B -->|low| E[不直接执行] D --> F{云端是否及时返回} F -->|是| G[采用云端结果或覆盖本地] F -->|否| H{本地是否达到最低执行阈值} H -->|是| I[执行本地结果] H -->|否| J[澄清或拒答] E --> K[云端理解 / clarify / reject] ``` 关键修正点： - 不是“本地 BERT 有结果就执行” - 不是“云端没返回就一定执行本地” - 必须先判断本地结果是否达到最低可执行阈值 - 高风险动作即使高置信，也不能直接执行 --- ## 6. 用户反馈状态图 ```mermaid stateDiagram-v2 [*] --> Received Received --> Ack: 已接收请求 Ack --> ExecutingFast: 本地快执行 Ack --> WaitingCloud: 等待云端/复杂规划 Ack --> Clarify: 缺关键槽位 Ack --> Confirm: 高风险动作 Ack --> Reject: 超能力边界 ExecutingFast --> Result WaitingCloud --> Result Clarify --> Result Confirm --> Result Reject --> [*] Result --> [*] ``` 反馈规则： - `ack`：收到，马上处理 - `progress`：正在为你处理 - `result`：执行完成或查询完成 - `clarify`：信息不足，补一个关键字段 - `confirm`：高风险动作确认 - `reject`：能力边界拒答 --- ## 7. 反馈模板策略 ### 7.1 快执行 适用： - 打开车窗 - 调低空调 - 播放音乐 - 导航去公司 推荐反馈： - 首反馈：`好的，正在打开车窗` - 最终反馈：`车窗已打开` 如果设备动作极快，也可以直接播报最终反馈： - `车窗已打开` ### 7.2 慢执行 适用： - 查订单 - 查物流 - 多命令复杂规划 - 条件型任务 推荐反馈： - 首反馈：`收到，我先帮你查一下` - 最终反馈：`订单还没发货` ### 7.3 复合命令 例如： - `打开车窗，空调调低至20度` 推荐反馈： - 首反馈：`好的，正在为你打开车窗并调低空调` - 最终反馈：`车窗已打开，空调已调到20度` ### 7.4 边界外请求 例如： - `打开飞机门` 推荐反馈： - `这个我暂时做不了，但我可以帮你导航、查订单、调空调或播放音乐` --- ## 8. 多轮上下文恢复流程 ```mermaid flowchart TD A[当前轮输入: 再低一点] --> B[读取 session context] B --> C{是否命中高频改写缓存} C -->|是| D[改写为完整句] C -->|否| E[轻量改写模型/规则补全] D --> F[进入 router] E --> F F --> G[意图识别 + 槽位提取 + 执行] ``` 说明： - 这里的“上下文能力”不是 BERT 自己缓存的 - 而是 Agent 在 `session state` 中保存上轮任务和关键槽位 - 再由 `rewrite engine` 完成短句恢复 --- ## 9. 典型场景流程演示 ### 9.1 场景一：快执行单命令 用户输入： - `打开车窗` 处理流程： 1. ASR 转文本：`打开车窗` 2. 文本归一化 3. 本地多支路并发 4. 若本地高置信命中 `cabin_open_window` 5. 直接执行车窗插件 6. 播报：`车窗已打开` 时序演示： ```mermaid sequenceDiagram participant U as 用户 participant A as ASR participant R as 本地路由 participant P as 插件执行 participant T as TTS U->>A: 打开车窗 A->>R: 打开车窗 R->>P: 执行 open_window P-->>R: success R->>T: 车窗已打开 T-->>U: 车窗已打开 ``` ### 9.2 场景二：复合命令快执行 用户输入： - `打开车窗，空调调低至20度` 处理流程： 1. 文本进入本地路由 2. 判断为多命令 3. planner 或本地 splitter 输出两个 step 4. 生成 sequence workflow 5. 顺序执行： - 打开车窗 - 空调调到 20 度 6. 汇总反馈：`车窗已打开，空调已调到20度` 时序演示： ```mermaid sequenceDiagram participant U as 用户 participant A as ASR participant F as 融合分级器 participant W as Workflow participant P as 插件层 participant T as TTS U->>A: 打开车窗，空调调低至20度 A->>F: 规范化文本 F->>W: 输出 sequence workflow W->>P: step1 open_window P-->>W: success W->>P: step2 set_ac(20) P-->>W: success W->>T: 车窗已打开，空调已调到20度 T-->>U: 车窗已打开，空调已调到20度 ``` ### 9.3 场景三：慢执行查询 用户输入： - `帮我查一下订单A123456` 处理流程： 1. 本地高频分支命中订单查询 2. 首反馈先给： - `收到，我帮你查一下` 3. 调用订单查询插件 4. 最终反馈： - `订单A123456当前待发货` ### 9.4 场景四：条件型请求 用户输入： - `查一下订单A123456，如果还没发货就取消` 处理流程： 1. 本地识别该请求复杂，进入云端 planner 2. planner 输出 conditional workflow： - step1: query_order - step2: cancel_order - condition: order_status == pending_shipment 3. 先执行 step1 4. 若满足条件，则进入确认 5. 用户回复确认后，再执行取消 6. 最终反馈： - `订单A123456已取消` 时序演示： ```mermaid sequenceDiagram participant U as 用户 participant R as 本地融合器 participant C as 云端 Planner participant W as Workflow participant P as 插件层 participant T as TTS U->>R: 查一下订单A123456，如果还没发货就取消 R->>C: 复杂条件请求 C-->>W: conditional workflow W->>P: step1 query_order P-->>W: order_status=pending_shipment W->>T: 即将取消订单，仅在订单未发货时取消。请回复确认或取消 T-->>U: 确认提示 U->>W: 确认 W->>P: step2 cancel_order P-->>W: success W->>T: 订单A123456已取消 T-->>U: 订单A123456已取消 ``` ### 9.5 场景五：多轮短句恢复 对话过程： 1. 用户：`把空调调到22度` 2. 系统：`空调已调到22度` 3. 用户：`再低一点` 4. 系统读取 `last_intent=cabin_set_ac` 和 `last_temperature=22` 5. rewrite engine 改写为：`把空调调到21度` 6. 再进入意图识别和执行 7. 系统反馈：`空调已调到21度` ### 9.6 场景六：边界外请求 用户输入： - `打开飞机门` 正确处理： 1. 本地分支都无法稳定支持 2. 若低于执行阈值，不得直接执行已有意图 3. 进入： - reject - 或云端澄清 4. 反馈： - `这个我暂时做不了，但我可以帮你导航、查订单、调空调或播放音乐` 这类场景必须通过 `unknown / out_of_scope` 机制处理，不能靠封闭集分类硬选。 --- ## 10. 当前项目与目标方案的对应关系 ### 10.1 已经具备的能力 - 本地 `keyword / classifier / retrieval / fusion` - 本地 BERT 分类器 - `session state` - `context rewrite` - `planner` - `sequence / conditional workflow` - 高风险确认 - demo 调试面板 ### 10.2 还需要补齐的关键能力 - `unknown / out_of_scope` - 低分拒识策略 - 明确的 `execute / reject / route_to_cloud` 决策建议 - 更多真实车机意图 - 真实插件接入 - 语音前端与 ASR/TTS 完整接入 --- ## 11. 当前阶段的正式实施结论 当前方向可以继续，但必须明确： - 本地 BERT 是本地快分支之一，不是整个系统的唯一裁决者 - 最终执行依据应来自“本地融合分级器 + planner + 风险规则” - 用户体验的关键不只是识别正确，还包括： - 首反馈是否快 - 多轮是否顺 - 边界是否清楚 - 风险是否可控 因此，当前正式方案应定义为： ```text 车机型 Agent = 本地并发快链路 + 上下文改写缓存 + 分级融合决策 + 云端 planner + workflow 执行 + 风险确认 + reject / clarify / fallback 策略 ``` --- ## 12. 下一步执行优先级 建议按以下顺序继续实现： 1. 补 `unknown / out_of_scope` 和拒识阈值 2. 输出统一执行建议： - `execute` - `clarify` - `reject` - `route_to_cloud` 3. 扩真实车机场景意图： - 车窗 - 车门 - 座椅 - 灯光 - 后视镜 - 除雾 4. 强化 rewrite/cache 高频模式 5. 接真实插件与真实语音链路