最后更新：2026-08-15

LLM-first Runtime：让模型做语义判断，让规则守住边界

前两篇我们讲了两件事。

第一，下一代 AI 销售系统不是聊天机器人，而是销售操作系统。

第二，要让 Agent 真正参与销售流程，企业必须把销售经验沉淀成可运行的业务资产，比如 State、Intent、Slot、Skill、Tool、SOP 和话术包。

但资产准备好了以后，还有一个更关键的问题：

运行时到底由谁来做判断？

客户说一句话，系统怎么知道他是在问价格、表达兴趣、提出异议，还是准备预约？

客户给了一段信息，系统怎么知道哪些是联系方式，哪些是预算，哪些是需求，哪些只是上下文？

Agent 什么时候应该继续回答，什么时候应该追问，什么时候应该调用工具，什么时候应该转人工？

这些问题背后，都是运行态决策。

今天这篇，我们讲下一代 AI 销售系统里的一个核心原则：

LLM-first Runtime。

简单说，就是：

让模型在业务资产边界内做语义判断，让规则负责候选召回、强结构保护、安全门禁和可观测兜底。

这句话看起来有点技术，但它决定了一个 AI 销售系统是真理解客户，还是只是在用规则模拟理解。

一、为什么传统规则运行态不够用？

很多早期销售机器人都是规则驱动。

比如：

出现“多少钱”就判定为价格咨询
出现“电话”就判定为联系方式
出现“不需要”就判定为拒绝
当前状态是“需求收集”，就只识别需求相关字段
当前状态是“价格说明”，就只走价格话术

这种方式看起来稳定，但一进入真实销售现场，很快会遇到问题。

因为客户表达并不标准。

客户可能说：

你们这个贵不贵？

这是价格咨询，还是价格异议？

客户可能说：

我们现在企微客户比较多，销售经常跟不过来。

这是业务场景、痛点，还是需求信号？

客户可能说：

先不用了，最近比较忙。

这是明确拒绝，还是暂缓推进？

客户可能说：

你先发我看看吧。

这是要资料、表达兴趣，还是想结束对话？

这些判断，不能只靠关键词。

销售对话的语义，经常藏在上下文里、语气里、前后轮关系里、当前阶段目标里。

如果运行态只靠规则，就会出现三类典型问题。

第一，误判。

客户只是问价格，系统当成价格异议；客户只是暂时忙，系统当成彻底拒绝。

第二，漏判。

客户已经表达了需求，但没有说出标准关键词，系统就没记录；客户已经给了联系方式，但格式不标准，系统没提取。

第三，流程僵硬。

客户跳着问问题，系统却被当前状态锁住，只能按照预设顺序继续追问。

这就是传统规则运行态最大的问题：

它能执行流程，但很难理解真实对话。

二、LLM-first 不是不要规则，而是重新定义规则的位置

一提 LLM-first，很多人会误解：

是不是所有事情都交给大模型？

不是。

LLM-first 不是“没有规则”，也不是“让模型随便发挥”。

恰恰相反，真正成熟的 LLM-first Runtime，规则非常重要。

但规则不再替代语义判断，而是站在更合适的位置。

我们可以把运行态决策分成四层。

第一层，业务资产提供边界。

模型不是凭空判断，而是在当前 Agent 绑定岗位可用的 Intent、Slot、State、Skill、Tool、话术包边界内判断。

第二层，候选召回提供视野。

规则、关键词、向量检索、资产关系可以先召回候选，比如可能相关的意图、槽位、技能和话术。

第三层，LLM 做语义裁决。

模型结合客户消息、上下文、当前阶段目标、候选定义和业务边界，判断本轮真正应该采用什么。

第四层，规则做门禁和兜底。

比如自动发送策略、风险审批、人工交接、工具权限、强结构字段、fallback 记录，都由规则和策略守住。

所以 LLM-first 的准确表达是：

模型负责理解，规则负责约束。模型做判断，规则守边界。

这和传统机器人正好相反。

传统机器人是规则先决定业务含义，模型最多润色回复。

下一代 Agent 是模型先理解业务语义，规则负责保证它不会越界。

三、为什么 State 不能硬过滤用户表达？

在销售流程里，State 很重要。

State 告诉 Agent 当前处于哪个阶段，比如新线索接待、需求发现、方案介绍、异议处理、预约推进。

但一个常见错误是：

把 State 当成用户表达的硬过滤器。

比如当前在“需求发现”阶段，就只识别需求相关 Intent；当前在“价格说明”阶段，就只识别价格相关 Intent。

这在真实对话里会出问题。

因为客户不会严格按照我们的流程说话。

客户可能还在需求发现阶段，就突然问：

多少钱？

客户可能在价格阶段，又补充：

我们主要是做私域的，客户都在企微里。

客户可能在预约阶段，突然问：

数据安全吗？

如果 State 把 Intent 和 Slot 硬过滤掉，系统就会看不见这些表达。

所以我们的运行态原则是：

用户表达不受 State 限制。

Intent 和 Slot 应该在当前 Agent 绑定岗位的资产边界内全局召回和理解。

State 的职责不是限制客户能说什么，而是提供任务上下文：

当前阶段目标是什么
当前缺哪些信息
哪些转移候选更相关
哪些话术包在当前阶段允许使用
哪些 Skill 在当前阶段更适合

换句话说：

Intent/Slot 负责理解客户说了什么，State 负责决定接下来怎么推进。

这是一条非常重要的边界。

如果搞反了，Agent 就会变成流程机器人。

如果分清楚，Agent 才能既灵活理解客户，又稳定推进销售。

四、一次 LLM-first 决策是怎么发生的？

我们用一个例子来看。

客户说：

你们怎么收费？我们现在销售主要在企微上跟客户，感觉经常漏跟。

这句话里有好几层信息：

客户在问价格
客户提供了渠道：企微
客户表达了痛点：销售漏跟
客户可能适合“多渠道接待 + SOP 跟进”的方案

传统规则可能只命中“收费”两个字，然后进入价格话术。

LLM-first Runtime 会做得更细。

第一步，构建决策上下文。

系统会把当前客户消息、最近对话、当前状态、已收集 Slot、可用 Intent/Slot/Skill/Tool 候选、当前阶段目标压缩成模型可读的 decision context。

第二步，召回候选。

可能召回：

ask_price
describe_channel
describe_pain_point
sales_discovery_reply
pricing_explanation_reply
wecom_channel_solution

第三步，模型判断。

模型不是只选一个关键词，而是判断这一轮主意图、辅助意图、可抽取信息和下一步动作。

可能结论是：

主意图：问价格
辅助语义：企微渠道场景、销售漏跟痛点
抽取 Slot：channel=企微，pain_point=销售漏跟
推荐 Skill：价格说明 + 场景诊断
回复策略：先解释计费维度，再把价格和客户场景关联，不要直接要求留电话

第四步，运行态门禁。

系统检查当前状态允许哪些话术包，是否需要审批，是否能自动发送，是否需要工具查询，是否触发人工交接。

第五步，生成回复并记录 Trace。

最后 Agent 给出回复，同时记录为什么这样判断。

你会发现，LLM-first 不是“模型直接生成一段话”。

它是一套结构化决策链。

模型负责在业务资产中做语义选择，运行态负责把选择变成可执行、可审计的动作。

五、哪些事情应该交给模型，哪些事情必须交给规则？

LLM-first Runtime 的难点，不是把所有东西都交给模型，而是分清边界。

适合交给模型的，是语义判断。

比如：

客户这句话主要意图是什么
客户是否在表达真实需求
客户的顾虑属于价格、信任、效果，还是复杂度
客户给出的信息能否作为某个 Slot
当前更适合用哪个 Skill
候选话术里哪条更贴合上下文
当前是否可以推进到下一阶段

这些判断需要理解上下文，适合由 LLM 完成。

必须由规则或策略保护的，是边界和安全。

比如：

手机号、邮箱、具体日期时间等强结构字段
明确辱骂、投诉、风险升级
工具调用权限
高风险写操作审批
是否允许自动发送
是否越过当前 State 的话术包边界
是否越权调用组织外 MCP 工具
LLM 超时、低置信、空输出时如何兜底

这些不能完全依赖模型自由发挥。

所以，一个好的运行态不是“模型越自由越好”，而是：

在该理解的地方充分理解，在该收敛的地方严格收敛。

六、为什么 fallback 必须可观测？

AI 系统上线后，最怕的不是降级。

模型可能超时，知识库可能没命中，工具可能失败，候选可能不足，这些都正常。

真正可怕的是：

系统降级了，但没有人知道它为什么降级。

比如客户说：

你们能不能查一下我上次的试用进度？

正常情况下，Agent 应该调用业务系统工具查询。

但如果工具不可用，系统可能退回普通回复：

您可以联系顾问确认试用进度。

这句话本身可以接受，但 Trace 里必须记录：

原本召回了哪个 Tool
为什么没有调用
是权限问题、超时、缺参数，还是模型没有选择
最终采用了什么 fallback
fallback 来源是规则、默认 Skill，还是低置信兜底

否则运营会误以为 Agent 业务能力不行，技术会不知道问题出在哪里。

所以我们坚持：

所有 fallback 都必须可观测。

这包括：

LLM 不可用
LLM 超时
模型输出为空
置信度不足
候选召回为空
工具调用失败
审批拦截
状态跳转门禁失败
话术候选被边界过滤

只有这样，Agent 才能被诊断、被运营、被持续优化。

七、LLM-first Runtime 对业务团队意味着什么？

对业务团队来说，LLM-first Runtime 最大的价值不是技术更先进，而是让业务经验能真正进入模型视野。

如果一个 Intent 资产写得很模糊，模型就容易误判。

如果一个 Slot 没有正负例，模型就容易乱抽。

如果一个 Skill 的能力边界不清楚，模型就不知道什么时候该选它。

如果一个话术包没有使用场景和风险说明，模型就很难选出最合适的表达。

所以 LLM-first 对业务配置提出了更高要求：

Intent 要写清楚定义、正例、负例和混淆边界
Slot 要写清楚抽取目标、格式、追问策略和记忆范围
Skill 要写清楚能力边界和执行策略
State 要写清楚阶段目标、缺槽条件和退出条件
话术包要写清楚适用阶段、风格、风险和变量

这不是增加配置负担，而是把过去隐藏在销售主管经验里的判断标准显性化。

显性化之后，模型才能学会按企业的销售方法工作。

八、LLM-first Runtime 的三个判断标准

判断一个 AI 销售系统是否真的做到了 LLM-first，可以看三个问题。

第一，模型是否看到了正确候选？

如果客户在问价格，但价格 Intent 根本没有进入候选，模型再强也选不到。

第二，模型是否看到了判别证据？

如果上下文压缩把关键对话丢掉了，比如客户前面已经说过预算和行业，模型就很难正确判断。

第三，模型判断是否被运行态正确采纳？

有时模型判断对了，但运行态因为硬编码规则、状态过滤或候选边界错误，没有采纳模型结果。

所以排查 Agent 问题，不能只看最终回复。

要先问：

候选召回对不对
上下文压缩有没有丢关键信息
模型选择是否合理
采纳逻辑有没有覆盖模型判断
fallback 是否记录清楚

这也是我们在系统设计里强调 Trace 和 Eval 的原因。

九、从规则机器人到 LLM-first Agent 的变化

最后总结一下。

传统规则机器人是：

规则定义业务含义，模型负责补充表达。

LLM-first Agent 是：

业务资产定义边界，模型负责语义判断，规则负责候选、门禁和兜底。

传统机器人关心的是：

这句话命中了哪个规则？

下一代 Agent 关心的是：

模型是否在正确业务上下文里理解了客户？

这就是根本区别。

如果说岗位是把销售经验变成可运行资产，那么 LLM-first Runtime 就是让这些资产在真实对话中活起来。

它让 Agent 不再只是按流程走，而是能在复杂、跳跃、不标准的客户表达里，理解客户、收集信息、选择能力、推进销售。

结语

AI 销售系统真正难的地方，不是让模型生成一段流畅回复。

真正难的是：

让模型在企业定义的业务资产边界内，做出可解释、可约束、可复盘的销售判断。

这就是 LLM-first Runtime 的意义。

它不是放弃规则，而是让规则从“假装理解客户”退回到“保护业务边界”。

它也不是让模型自由发挥，而是让模型在岗位、Agent 实例、Skill、Tool、State、Slot 和话术包共同组成的业务空间里，做真正的语义决策。

下一篇，我们会继续讲：

从会聊天到会办事：AI 销售 Agent 的 Skill、Tool 与 MCP 架构。