Conversation 信号
概览
conversation 检测传入 chat-completion 请求形态的结构事实:用户消息数量、是否存在 developer 消息、定义的工具数量、assistant 工具调用次数、已完成的工具周期,以及当前请求是否仍处于活跃工具循环中。它映射到 config/signal/conversation/,并在 routing.signals.conversation 下声明。
该信号族为启发式:无需任何模型推理,直接检查请求的 messages[] 和 tools[] 数组。
主要优势
- 无需关键词启发式规则,即可将智能体型(大量使用工具的)请求路由到能力更强的模型。
- 在结构层面区分单轮和多轮会话。
- 零延迟:对已经解析的请求字段进行快速内存扫描即可完成评估。
- 生成命名信号,投影和决策可像处理其他信号族一样使用这些信号。
解决什么问题?
现代 LLM 请求的形态差异很大。简单的“2+2 等于多少?”与包含 developer 指令、三个工具定义和多个工具调用周期的智能体编码会话在结构上截然不同。conversation 将这些结构差异转换为稳定的命名信号,使决策树能够将每种形态路由到合适的模型层级。
何时使用
在以下情况使用 conversation:
- 路由取决于会话深度(单轮与多轮)
- 带工具定义的智能体型请求应转到能力更强的模型
- developer 消息是否存在会改变路由策略
- 需要统计工具调用周期以检测复杂的智能体工作流