核心论点：参数可靠性不只取决于"抽得准不准"，还取决于"什么时候抽、抽来的结果存在哪、谁来保证它不被模型改写"。前置规则、运行期触发、执行时查询是三种时机，平台化 Slot（槽位）是把它们统一治理的成熟形态——但它替代不了硬强制，两者管的是不同环节。

问题定义：抽准了，但"何时抽"仍是盲区

直觉上，参数抽取就是"模型从话里抽值 + 校验兜底"——这套对低后果字段（如退款原因）完全成立，也是很多人（包括笔者早期）的默认心智模型。但高后果字段（订单号、手机号）不能押在"模型大概率抽对"上：校验只能保证"安全可执行"，拦不住"合法格式的错号"；一次采样偏移或历史订单号混杂，就可能张冠李戴造成资损。正解是把定稿权从模型外移——模型只负责识别槽位、定位疑似片段并触发确定性代码定稿，值的最终产出交给代码或查询。本文与《参数硬强制注入》篇要补的，正是这个"定稿外移"的视角。

《参数抽取可靠性》篇讲了怎么把订单号、手机号抽准：正则优先，模型只当候选，校验与反问兜底。但那篇默认了一个前提——参数在进 Agent 之前就已经抽好了。

现实里这个前提会漏。用户一句话里订单号藏在口语里、格式不规则，前置规则没匹配上；或者多轮对话进行到一半，用户才抛出"就是那笔 AB12 的订单"，此时前置抽取早已跑完。

于是出现一个尴尬：值明明后来能拿到，却因为"抽取只发生在入口"而拿不到，只能让模型去填——而《参数硬强制注入》篇已论证过，让模型填高后果字段是失守点。

抽取不只有"方法"（正则还是模型），还有"时机"（入口前置还是运行期）和"落点"（抽到哪、谁保管）。后两者决定了硬强制能不能真正用上可信值。

三种提取时机：前置、触发、查询

参数进入可信上下文，有三条互补的路径，成熟系统通常并行使用而非单选。

前置规则抽取：请求入口用正则/结构化解析直接拿格式固定的字段（订单号、手机号）。零延迟、零幻觉，是首选。缺点是覆盖率有限——表达一变就容易漏。

运行期触发抽取：规则没命中时，让模型在对话中发现"这里有个像订单号的东西"，主动调用一个只做解析、不改业务的特殊工具；该工具用确定性代码归一化并校验，再把干净值写回会话上下文。模型只负责"语义发现"，定稿权在确定性代码。这补了前置规则的盲区，又不破坏"模型不填业务字段"的原则。

执行时查询补全：最稳的一条路——不依赖用户表达，而是用已确定的身份（如用户 ID）去订单系统查"最近一笔待退订单"，直接得到可信值。凡是能从权威系统查到的，优先查，不靠抽。

三条路径最终都汇入同一个落点：会话上下文里的一个可信值，业务工具执行时从那里取，而非从模型的工具调用参数里取。

离模型越远越可靠：能查补全的优先查，能规则抽的优先规则，规则漏了再由模型触发确定性解析兜底。模型在整个链条里始终不持有业务字段的定稿权。

场景锚点：多轮查订单里的"运行期补全"

运行期触发最容易被忽略的一种形态，是跨轮补全——值不在入口给全，而是在后续轮次里补齐。典型链路是：第一轮用户说"查订单"，意图已识别但订单号槽位为空，系统主动反问并把该意图标记为激活且挂起；第二轮用户说"订单号 12345"，系统优先判定这是上一轮反问的回答（而非新意图重判），由解析管道用确定性代码归一化并写入槽位，填满后业务工具经硬强制锁定下发。完整消息流转如下：

注意这里模型只做了"语义发现"——识别"这句话是在补之前问的订单号"，值的定稿仍由代码完成。意图本身在第一轮就激活挂起，后续靠状态机补全而非重新识别，这正是"槽位补全优先于意图重判"的设计。补来的参数和入口直给的参数，从上下文进后端时都过同一道硬强制；后端只拿到一个被锁定的可信值，并不知情它究竟来自第几轮、哪种策略。

为什么需要 Slot：把"抽来的结果"当一等公民

上面三条路径都往"会话上下文"写值。如果只把它当临时变量，会出两个问题：值从哪来、准不准，没人记得；多轮对话里新旧值打架，模型无从判断用哪个。

Slot（槽位）是把参数提升为"有状态、可治理"的设计：每个关键字段在上下文里是一个带元信息的槽位，记录它的来源（规则 / 触发抽取 / 查询 / 用户澄清）、置信度、以及是否已被锁定不可被覆盖。业务工具只声明"我要从 Slot 取订单号"，完全不关心是谁、什么时候、用哪种策略填的。

这带来两个收益。其一，可追溯：排障时能看清最终值是谁给的、靠不靠谱。其二，冲突可治理：两个来源给出不同值，平台能按来源优先级或置信度裁决，而不是默默用错的那一个。

Slot 解决的是"可信值怎么存、怎么管"，而不是"模型能不能改它"。后者是另一道闸。

Slot 管理替代不了硬强制

一个常见误解：有了 Slot 管理平台，是不是就不需要《参数硬强制注入》篇那套了？不是。

Slot 把干净值存进了上下文，但模型在生成工具调用时，仍然会自己生成一个 order_id 参数。如果框架只把 Slot 当作"提示"或"默认值"喂给模型，模型照样能生成不同的值并传进工具——上游抽准的努力在 tool-calling 这一步被悄悄推翻，正是硬强制要灭的退化。

要避免退化，平台必须额外声明该字段来自上下文且锁定：框架在模型调用工具时，要么不把这个槽位暴露给模型，要么用 Slot 值强制覆盖模型生成的值。

Slot 管理保证"上下文里有个可信值"，硬强制保证"这个值离开上下文进后端时不被模型替换"。一个管进，一个管出；缺了后者，Slot 里的干净值仍会在最后一步被模型顶掉。平台化只是把硬强制从手写闭包变成框架配置，机制本身一点不少。

平台化的完整形态：解析管道 + Slot 生命周期

把前面所有点拼起来，成熟系统的参数治理是一个标准化平台能力，而非散落在各业务工具里的手写逻辑。

解析管道负责"运行期触发"那一环：规则正则、NER（命名实体识别，从文本里识别订单号/时间等实体的轻量模型）、LLM（大语言模型）抽取、上游系统查询，多策略串行，任一命中即定稿写 Slot。模型触发只是管道里的一档，产出候选后仍需确定性校验。

Slot 生命周期负责"管"：来源标记、置信度、过期时间（多轮里多久失效）、锁定状态（一旦硬强制锁定，低优先级来源不可覆盖）。这补上了手写方案的两个短板——值从哪来可审计、抽错时有降级与冲突裁决空间。

图中每条路径对应前文：解析管道对应"三种时机"，Slot 生命周期对应"为什么需要 Slot"，硬强制对应"替代不了"那一节，模型生成的值在 L 节点被覆盖或根本不可见。

手写方案（前置抽取 + 闭包覆盖 + 格式校验）是这套平台能力的轻量等价物；平台化把"抽取时机、Slot 治理、锁定覆盖"三者产品化，并补上生命周期与审计。两者思想同源，成熟度不同。

投入顺序：先手写，后平台

小团队不必一上来建 Slot 平台。务实路径是：先用前置规则 + 闭包覆盖 + 格式校验把"抽准"和"用稳"两道关跑通（即本系列前一篇与《参数硬强制注入》篇已落地的形态）；当字段规则变多、冲突变频繁、需要审计时，再把抽取时机从"纯前置"放开到"运行期触发"，并引入 Slot 式的来源/锁定治理。

判断基准只有一条：参数错了会不会出事，以及当前手写方案是否已经开始管不住"值从哪来、谁覆盖谁"。

核心要点

• 抽取有时机：前置规则、运行期触发、执行时查询三条路径互补，都汇入会话上下文再被业务消费，而非让模型直接填。
• 模型触发仍需确定性定稿：运行期抽取里模型只做语义发现，归一化与校验由确定性代码完成并写回上下文，模型不持定稿权。
• Slot 管"进"，硬强制管"出"：Slot 治理可信值的来源与生命周期，硬强制保证值离开上下文时不被模型改写，两者不可互相替代。
• 平台化 =《参数抽取可靠性》+ 本篇 +《参数硬强制注入》的产品化：解析管道覆盖提取时机，Slot 生命周期补审计与冲突治理，锁定覆盖复用硬强制机制。
• 先手写后平台：小团队用闭包覆盖跑通两道关即可，字段变多、冲突频发时再演进到 Slot 式治理。