1. 从一次漏调说起：AI 工作流为什么总在“最后一公里”掉链子

MiMo V2.6 这个模型我是从开放平台刚放出接口那阵子就开始用的，当时最直观的感受是：单轮对话的指令遵循能力确实比上一代稳了不少，尤其是长上下文里对格式约束的保持，明显没那么容易“跑偏”。但真正把它塞进一条完整的 AI 工作流里跑起来之后，问题就暴露了——不是模型不行，而是技能（skill）该被调用的时候没被调用。

这个现象我管它叫“漏调”。具体表现是：工作流里明明挂了三四个 skill，比如一个负责查数据、一个负责格式化输出、一个负责写回文件，结果模型在某一轮里自顾自地把活儿全用自然语言“说”完了，该触发的 skill 一个都没动。你去看日志，模型输出得漂漂亮亮，但下游节点拿不到结构化结果，整条链路直接断在那儿。更气人的是，同样的输入你重跑一遍，它可能又正常调用了。这种非确定性才是工作流落地最头疼的地方。

我后来复盘了很久，发现漏调根本不是单一原因造成的。它可能是提示词里 skill 的描述和当前任务语义距离太远，可能是工具列表太长导致模型注意力被稀释，也可能是工作流编排层没有做强制校验，模型“偷懒”用纯文本糊弄过去也没人拦。这三个层面分别对应三道护栏：语义护栏、编排护栏、校验护栏。缺任何一道，漏调就会像打地鼠一样，按下一个又冒出一个。

这篇东西适合两类人看：一类是正在用 MiMo V2.6 或者类似模型搭 agent 工作流的开发者，另一类是被“AI 工作流不稳定”折磨过、想找一套可复现治理方案的工程师。我不打算讲空泛的方法论，而是把这三道护栏拆成能直接抄的配置、能直接跑的校验逻辑，以及我在实际项目里踩过的坑。你哪怕只用其中一道，漏调率都能肉眼可见地降下来。

2. 第一道护栏：语义护栏，让 skill 在正确的时间被“想起来”

2.1 漏调的本质是语义匹配失败，不是模型笨

很多人一遇到漏调就怪模型，其实大部分情况下是 skill 的触发语义没设计好。模型决定调不调一个 skill，本质上是在做一次语义匹配：当前对话上下文和这个 skill 的描述之间，相似度够不够高。你如果只写一句“查询数据”，模型在遇到“帮我看看上周的订单情况”时，未必能立刻把这两者联系起来。

我做过一个对比实验，同一个查询任务，skill 描述分别用两种写法，跑 50 次统计调用率：

差距就是这么直白。第二写法做了三件事：明确了触发条件（当用户需要……时）、列举了同义场景（获取、查询、统计）、限定了输入形态（自然语言查询意图）。这三件事本质上是在给模型“划重点”，降低它做语义匹配的难度。

2.2 skill 描述的三段式模板

我现在写 skill 描述基本固定成一个三段式结构，你可以直接套：

1. 触发条件段：用“当……时调用”开头，把用户可能的表达方式尽量覆盖。比如“当用户提到时间范围、数据维度、筛选条件，或表达出想要了解某类业务指标时”。
2. 能力边界段：说清楚这个 skill 能做什么、不能做什么。边界不清是漏调和误调的共同根源。比如“本 skill 仅负责数据检索，不负责数据可视化，可视化请调用 chart skill”。
3. 输入输出契约段：明确输入是什么形态、输出是什么结构。模型看到清晰的契约，调用意愿会明显提升，因为它知道“调了之后下一步该干嘛”。

提示：触发条件段里不要堆太多同义词，否则会稀释核心语义。我的经验是控制在 5 到 8 个高频表达即可，剩下的靠模型泛化。

2.3 用“负样本”反向加固语义护栏

光写正向描述还不够，我还会在 skill 描述里加一小段负样本说明，告诉模型什么情况下不要调用。这招是从测试用例设计里借来的。比如数据查询 skill 里我会加一句：“如果用户只是闲聊或询问概念定义，不要调用本 skill。”

为什么负样本有用？因为漏调很多时候不是“该调没调”，而是模型在“调”和“不调”之间犹豫，最后选了不调。你给它一个明确的排除条件，反而帮它快速做了决策。实测下来，加了负样本说明之后，误调率下降的同时，漏调率也没有上升，整体调用决策的稳定性提升很明显。

2.4 上下文窗口里的“位置效应”不能忽视

MiMo V2.6 支持很长的上下文，但长上下文有个绕不开的问题：中间位置的信息容易被忽略。如果你把 skill 列表放在一个超长 prompt 的中段，模型对它的注意力会下降。我的做法是把 skill 定义放在系统提示的靠前位置，并且用清晰的分隔符（比如三个等号或者 XML 标签）把它和普通对话内容隔开。

另外，如果 skill 数量超过 8 个，我会考虑做分组。比如把“数据类 skill”放一组，“文件类 skill”放一组，“通信类 skill”放一组，每组给一个组级描述。模型先选组、再选具体 skill，决策路径变短，漏调率也会降。这个思路和人类处理复杂菜单是一样的：先选大类，再看细项，比一次性面对几十个选项要靠谱得多。

3. 第二道护栏：编排护栏，用工作流结构兜住模型的“随性”

3.1 为什么光靠提示词不够

语义护栏解决的是“模型想不想调”的问题，但模型终究是概率系统，你没法保证它 100% 按预期走。这时候就需要编排层来兜底。编排护栏的核心思想是：不把 skill 调用完全交给模型自由决定，而是在工作流结构上做约束，让某些关键 skill 变成“必经节点”。

我见过太多人把工作流搭成一条纯线性的 prompt 链，每个节点都是“模型自由发挥”，结果就是链路越长、漏调概率越高。正确的做法是在关键位置插入强制节点。比如数据查询这个动作，如果下游的格式化节点强依赖它的输出，那它就不应该由模型“决定调不调”，而应该由编排层直接路由过去。

3.2 三种编排模式与适用场景

我在实际项目里常用的编排模式有三种，各有各的适用场景：

大部分业务场景其实适合半强制路由。比如一条“用户提问 → 查数据 → 生成报告 → 写回文件”的链路，查数据和写回文件这两个是强依赖节点，必须强制；生成报告这一步可以给模型一定自由度，让它决定用哪种表达风格。

3.3 用状态机管理 skill 调用状态

编排护栏里最实用的一个技巧是引入状态机。给工作流定义一个状态变量，比如current_stage，取值是idle、data_fetched、report_generated、file_written。每个 skill 调用前先检查当前状态，调用后更新状态。这样即使模型某一轮漏调了，下一轮编排层发现状态没推进，就可以主动触发补偿调用。

这个思路在 CI 流水线里很常见：每个 stage 有明确的进入条件和产出物，条件不满足就不让往下走。把 AI 工作流当成 CI 流水线来管，漏调问题一下子就从“玄学”变成了“工程问题”。我在一个项目里加了状态机之后，整条链路的端到端成功率从 71% 提到了 96%，而且失败的时候能精确定位到是哪个 stage 卡住了。

3.4 重试与补偿：给漏调留一条后路

状态机之外，还要有重试机制。我的做法是：每个强制 skill 节点配置最多 2 次重试，重试时在 prompt 里显式提醒模型“上一步未检测到 skill 调用，请重新判断是否需要调用”。这个提醒很关键，它相当于给模型一个“你刚才漏了”的信号，实测重试成功率能到 80% 以上。

补偿机制则是针对那些重试也救不回来的情况。比如数据查询 skill 连续两次没调成功，编排层可以降级到一个兜底 skill，用更简单的参数去查，或者直接返回一个“数据暂不可用”的结构化结果，让下游节点至少能继续跑，而不是整条链路崩掉。工作流设计里有个原则：宁可降级，不可中断。漏调不可怕，可怕的是漏调之后没有任何兜底。

4. 第三道护栏：校验护栏，用 CI 思维把不确定性关进笼子

4.1 把 AI 工作流当成代码来测

前两道护栏都是在“运行时”做文章，第三道护栏则是把视角拉到“运行前”和“运行后”。我现在的习惯是：任何一条 AI 工作流上线前，都要像代码一样过一遍 CI。具体来说，就是准备一批回归测试用例，每条用例包含输入、期望调用的 skill 序列、期望的输出结构。每次改动 prompt 或 skill 描述，都跑一遍这批用例，看调用序列有没有变化。

这套东西听起来重，但搭起来其实很快。我用一个简单的 YAML 文件管理测试用例，每条用例长这样：

- name: "查询上周订单并生成报告" input: "帮我看看上周的订单情况，整理成一份报告" expected_skills: - data_query - report_generate expected_output_schema: type: object required: ["summary", "details"]

跑测试的时候，把工作流实际调用的 skill 序列和期望序列做对比，不一致就报警。这套机制帮我抓出了好几次“改了 A skill 描述导致 B skill 漏调”的隐蔽问题。

4.2 输出结构校验：漏调的照妖镜

除了调用序列，输出结构校验是发现漏调最灵敏的手段。漏调的一个典型特征是：模型用自然语言把本该由 skill 产出的结构化数据“说”了出来。比如本该返回 JSON 的地方，它返回了一段“根据查询结果，上周订单共有 1234 笔……”。这种输出人看着没问题，但下游节点解析不了。

我的做法是在每个关键节点后面加一个结构校验器，用 JSON Schema 或者 Pydantic 模型去校验输出。校验不通过就判定为疑似漏调，触发重试或告警。这个校验器的成本很低，但收益极高，因为它把“漏调”从一个模糊的语义问题变成了一个明确的格式问题，排查起来快得多。

4.3 监控指标：漏调率、重试率、降级率

要让校验护栏真正发挥作用，还得有可观测性。我现在固定监控三个指标：

• 漏调率：期望调用但实际未调用的 skill 次数 / 总期望调用次数。这个指标直接反映护栏效果。
• 重试率：触发重试的节点次数 / 总节点执行次数。重试率高说明语义护栏或编排护栏还有优化空间。
• 降级率：走到兜底逻辑的次数 / 总执行次数。降级率是最后的底线指标，理想情况下应该接近 0。

这三个指标我一般接到一个简单的看板上，按天看趋势。有一次我发现漏调率突然从 3% 涨到 15%，排查下来是某个 skill 的描述被同事改短了，触发条件被删掉了一半。如果没有监控，这种问题可能要等线上出事故才会被发现。

4.4 灰度发布：别让新 prompt 直接上生产

最后分享一个流程上的护栏：灰度发布。任何对 prompt、skill 描述、编排逻辑的改动，都不要直接全量上线。我的做法是先拿 10% 的流量跑新版本，观察漏调率和重试率有没有异常，稳定跑一天再逐步放量。AI 工作流的不确定性决定了它比传统代码更需要灰度，因为很多问题在测试用例里跑不出来，只有真实流量的多样性才能暴露。

灰度期间我还会做双跑对比：同一批输入同时跑新旧两个版本，对比 skill 调用序列的差异。差异大的样本单独拎出来分析，往往能发现一些边界情况。这套流程跑熟之后，工作流的迭代速度反而变快了，因为大家心里有底，知道有护栏兜着，敢改也敢发。

5. 三道护栏怎么配合：一套可复现的落地顺序

5.1 先上校验护栏，再补语义和编排

如果你现在手上已经有一条跑得不太稳的工作流，我建议的落地顺序是：先上校验护栏，再补语义护栏，最后加编排护栏。为什么这个顺序？因为校验护栏是“观测手段”，你得先能看见漏调发生在哪、有多频繁，才能有针对性地优化。没有观测就盲目改 prompt，很容易按下葫芦浮起瓢。

校验护栏的最小可用版本其实很简单：一个结构校验器加一个调用序列记录。结构校验器用现成的 JSON Schema 库就行，调用序列记录就是在每个 skill 调用点打一条日志。这两样加起来半天就能搭好，但能让你对整条链路的健康状况一目了然。

5.2 语义护栏的迭代节奏

语义护栏的优化是个持续迭代的过程。我的做法是每周看一次漏调日志，把漏调样本按“语义距离远”“描述有歧义”“上下文被稀释”分类，然后针对性改 skill 描述。改完跑一遍回归测试，确认没有引入新的漏调，再灰度上线。这个节奏不用太快，每周一次足够，关键是坚持。

5.3 编排护栏的取舍

编排护栏不是越多越好。强制节点加太多，工作流会变得僵硬，模型该发挥的灵活性发挥不出来。我的经验是：只有当下游节点强依赖某个 skill 的输出时，才把它设为强制。其余节点保持自由路由，给模型留出决策空间。这个取舍标准很实用，能帮你避免把工作流搭成一条死板的流水线。

5.4 一个完整的配置示例

把三道护栏串起来，一条典型的工作流配置大概长这样：

workflow: name: "订单报告生成" stages: - name: "data_query" skill: "data_query" enforcement: "mandatory" retry: 2 fallback: "data_query_simple" output_schema: "schemas/query_result.json" - name: "report_generate" skill: "report_generate" enforcement: "optional" retry: 1 output_schema: "schemas/report.json" - name: "file_write" skill: "file_write" enforcement: "mandatory" retry: 2 output_schema: "schemas/write_result.json" monitoring: metrics: ["miss_rate", "retry_rate", "fallback_rate"] alert_threshold: miss_rate: 0.05 retry_rate: 0.15

这份配置里，enforcement控制编排护栏，retry和fallback是补偿机制，output_schema是校验护栏，monitoring是可观测性。三道护栏各司其职，配合起来就能把漏调率压到一个可接受的水平。

6. 实操中踩过的坑与排查速查表

6.1 那些文档里不会写的教训

第一个坑是skill 描述改短了反而漏调变多。我一开始以为描述越简洁越好，后来发现简洁到丢失触发条件，模型就不知道该什么时候调。描述长度要服务于语义清晰度，该长的地方不能省。

第二个坑是重试时没有更新上下文。早期我做重试就是原样再跑一遍，结果模型看到一模一样的输入，还是做出一样的漏调决策。后来我在重试的 prompt 里加了一句“上一轮未检测到 skill 调用，请重新评估”，重试成功率立刻上去了。重试必须给模型新信息，否则就是无效重试。

第三个坑是状态机状态没有持久化。有一次服务重启，状态变量丢了，工作流从idle重新开始，导致重复调用。后来我把状态存到了外部存储里，重启也能恢复。工作流的状态管理要当成正经的工程问题来做，不能图省事放内存里。

6.2 常见问题速查表

6.3 一个容易被忽略的细节：skill 命名

skill 的命名也会影响调用率。我试过把query_data改成fetch_business_metrics，调用率居然有变化。原因是命名本身携带语义信息，模型在做匹配时会参考 skill 名称。命名要尽量动词加名词，语义明确，避免用helper、util这种模糊词。这个细节很小，但在漏调率卡在最后几个百分点下不去的时候，往往就是这种小细节在起作用。

7. 关于这套护栏，我个人的几点体会

这套三道护栏的方案，我在三个不同规模的项目里跑过，最小的只有两个 skill，最大的有二十多个 skill 跨五个业务域。体感最明显的一点是：漏调问题从来不是靠某一个技巧解决的，而是靠一套组合拳。语义护栏让模型“想调”，编排护栏让模型“必须调”，校验护栏让漏调“无处藏身”。三者缺一，漏调就会从缺口里钻出来。

另一个体会是，不要追求零漏调。概率系统里零漏调是不现实的，追求零漏调只会让你把工作流搭得越来越僵硬，最后失去 AI 该有的灵活性。合理的目标是把漏调率控制在一个可接受的范围，比如 5% 以下，并且保证漏调发生后有补偿机制兜底。工程上讲究的是可控，不是完美。

最后说一个我最近在试的方向：把漏调日志喂回给模型做few-shot 示例。具体来说，就是把历史上典型的漏调样本整理成“输入 + 正确调用序列”的示例，放在系统提示里。实测下来，对于反复出现的同类漏调，这个手段效果很好。不过这招会增加 prompt 长度，需要权衡。如果你也在折腾 AI 工作流的稳定性，不妨从校验护栏开始，先把问题看见，再一步步收紧。