技能文档管不住步骤：把流程编译成状态机，平均涨十六个百分点 (2026)

一份技能文档明明就摆在上下文里，模型还是会漏掉里面规定的那一步。九月二十四日提交到预印本平台的一篇论文把原因指到了执行权上：技能文档同时装着知识与流程，整篇塞进上下文只能影响模型的选择，不能强制它执行；办法是把流程从文档里编译出来，变成带条件的显式状态转移。论文题为《HEXIS: Compiling Agent Skills into Extended Finite State Machines》，署名作者 Minghao Li，2026 年 9 月 24 日提交，cs.AI，30 页。1

本期覆盖九月二十四号到二十五号。同一天挂出来的还有第二篇论文（arXiv:2609.30120），它审计一个已经上线的插件升级技能，说明技能带来的分数为什么会骗人；两篇一起听，才是一次完整的判断：该怎么把流程从模型手里拿走，以及怎么确认这段流程真的有用。2

本期听什么

知识给对了，步骤还是漏。 技能文档里的知识可以交给模型读，流程——顺序、条件、循环上限、终止——过去也一起交给它，于是每一步都有一个走偏的概率，任务越长越容易漏。3
四个基准、四个执行器，平均涨十六点一个百分点。 十六个组合里十五个优于原生执行、十一个最好或并列最好；数学推理上的涨幅在三十一点四到三十八个百分点之间。1
编译一次，换模型不重编。 机器只用一个小模型的轨迹编译一遍，原封不动搬到另外三个执行器上，十二个目标设置里十一个变好。3
合规不等于正确。 表格任务上两个方法的流程合规率都是百分之百，成功率却是五十九点六对七十五点四。3
同一天的另一篇在拆台。 技能带来的涨分集中在其中一道题上；换模型族重判，涨幅从四点九二分变成十点六三分和六点零九分；把人工复核过的判定换回去，置信区间跨过了零。2

技能文档里混着两样东西

论文把技能文档拆成两部分：知识，是怎样完成某个操作的说明；控制要求，是这些操作之间的顺序、依赖、分支、重复与终止。二者在自然语言里交错在一起。3

原生执行把两样都当上下文交给模型：模型看到文档、任务输入和历史，自己挑下一个操作和它的参数。论文把这一刻写成概率形式——每一步都有一个「不走规定动作」的概率，它在整条轨迹上连乘，得到累计的偏离概率。结论很直接：把要求写进上下文能影响这个选择，但不能约束它。哪怕模型已经正确识别出「检查没通过」，它仍然可能选择直接汇报，而不是执行文档要求的返工；确定性解码也改变不了这一点。任务越长，这类边界越多。3

这不是孤例。论文引用 AgentIF 说明复杂条件要求与工具规格难以遵守，引用 SOPBench 说明模型越小、按标准流程办事的能力越差。技能本身是有用的：技能基准 SkillsBench 在 87 道题、8 个领域上做配对评测，用 18 个模型与外壳组合对照，加技能把平均通过率从 33.9% 抬到 50.5%（相对提升 25.5%），各组合涨幅从 4.1 到 25.7 个百分点不等，并且模块不超过三个的聚焦型技能优于大而全的技能包。4 这次要解决的不是技能有没有内容，而是内容对得上、步骤却执行不到。

技能本身的形态是公开的：按 Agent Skills 开放规范，一个技能是一个目录，至少包含一个 SKILL.md，前面的 YAML 头写名称与描述，后面是给模型读的指令，脚本、参考资料和素材按需加载。5

机器长什么样：状态、变量、带条件的边

HEXIS 把技能知识和控制流分开装进一台扩展有限状态机。机器由状态集合、初始状态、一组类型化变量、每个状态的指定操作、每个状态按固定顺序排列的出边、终止状态和结束分类组成。3

运行方式是确定的：技能知识留在某个状态自己的本地指令里，模型只在这个状态内推理和生成，产出的字段写进声明的变量；一步正常做完，运行时按顺序检查出边条件，选第一条成立的边作为去向，不再经过模型。需要语义判断的地方——例如「这份修改算不算通过了检查」——编译时插一个判断状态，把判断标准写进它的指令，要求它输出一个事先规定的标签，用标签的值决定去向。循环配计数上限与退出条件，终止状态带上结果分类。3

信息层面的目标也被写成了公式：让机器配置对「技能允许的后续执行」的剩余不确定性最小。落到工程上，它体现为状态、变量读写声明与出边条件的完整性。3

机器怎么造出来：先出初版，再拿轨迹补，最后靠重放验收

编译分两段。第一段从技能文档生成初始机器：把文档按结构拆成编号条款并保留全文；抽取必须的操作、顺序要求、禁止行为与终止条件，每一条都附一句原文引证；引证在文档里找不到、或指向未知工具与标签的条目被删掉。然后生成状态、变量与出边，每个保留的条款都要落到某个状态或本地指令上。生成的候选先过静态检查——字段与类型、条件语法、图结构、条款编号、工具声明——不通过就带着错误清单回炉，重试有次数上限；通过后再查变量依赖、结尾证据与声明的约束，才成为初版机器。3

第二段用开发轨迹增量补齐：把一条轨迹里的工具调用、交付产出和终止事件按顺序与机器对齐，优先复用可达的状态；对不上的操作用新状态承接，把事件意图与相关条款写进它的本地指令；同一个条件通向两个不同去处时插判断状态；循环补上计数上限与退出。3

验收条件是这套方法里最硬的一环：新版本必须通过静态检查，并且能重放当前这条轨迹以及此前所有已被接受的轨迹；只要有一条重放不过，这次改动整条作废，机器与归档保持原样。失败时会把状态复用限制在兼容且可达的范围再试一次，仍不通过就不改。也就是说，机器的演化是被历史轨迹锁住的，不允许为了新样本牺牲旧样本。3

四个基准、四个执行器上的结果

评测用四个基准，各配一份现成技能文档：SpreadsheetBench 的 107 道表格编辑题（50/57 划分）、LiveMathematicianBench 的数学家级选择题（487 道开发、121 道测试，按月分层）、InfiAgent-DABench 的 257 道数据分析题（206/51 划分）、SealQA 的 LongSeal 长文问答（203/51 划分，离线只给素材网页）。执行器四个：云端 qwen3.6-flash 与 GLM-4.7-FlashX，本地 Qwen3.5-9B 与 Qwen3.8-27B。编译与技能优化由 Claude Fable 5.1 完成；机器只用 qwen3.6-flash 的开发轨迹编译一次，随后原封不动搬到另外三个执行器上。对照方法除原生 Skill + ReAct 外，还有 AWM、ReasoningBank、SkillOpt 和 AFlow。指标是「请求级完全合规率」，即一次执行满足全部可机械验证的请求要求（文件交付、输出格式、工具使用），与答案对错无关。3

成功率的对照（每格为「原生 Skill + ReAct → HEXIS」）：

基准	qwen3.6-flash	GLM-4.7-FlashX	Qwen3.5-9B	Qwen3.8-27B
SpreadsheetBench	45.6% → 75.4%	22.8% → 47.4%	33.3% → 38.6%	56.1% → 71.9%
LiveMath	45.0% → 76.7%	12.4% → 48.7%	40.5% → 71.9%	33.9% → 71.9%
DABench	78.4% → 82.4%	78.4% → 82.4%	82.4% → 86.3%	86.3% → 88.2%
LongSeal	7.8% → 21.6%	7.8% → 19.6%	23.5% → 23.5%	17.6% → 23.5%

十六个组合里十五个优于原生执行，十一个取得最好或并列最好，平均提升 16.1 个百分点。数学推理上的提升最大，四个执行器为 31.4 到 38.0 个百分点，且都超过了全部对照方法；论文还报告合规率在 91.7% 到 100% 之间。3

一个容易被忽略的细节：合规与正确并非一回事。在 qwen3.6-flash 的表格任务上，SkillOpt 与 HEXIS 的合规率都是百分之百，成功率却是 59.6% 对 75.4%——差别来自状态里推理与数据传递的质量，而不是流程有没有走完。另外两组数字给出这条方法的边界：技能内容优化与流程编译可以叠加，SkillOpt 优化过的文档再编译，表格任务到 84.2%，比只编译原始文档高 8.8 个百分点；LongSeal 上提升最小，四个执行器里有一个持平。3

成本：谁省，谁更贵

token 账两边都有。Qwen3.8-27B 在四个基准上都以 HEXIS 取得最低消耗，比原生少 38.4% 到 88.9%；GLM-4.7-FlashX 的消耗下降 28.4% 到 94.5%。3

反过来，qwen3.6-flash 在 DABench 与 LongSeal 上分别省下 56.5% 与 90.0%，但在 SpreadsheetBench 和 LiveMath 上分别多花 4.9% 与 8.9%；Qwen3.5-9B 在三个基准上反而更费 token，只有 LongSeal 省下 80.8%。论文的解释是：编译能压低上下文开销，而额外的推理与校验让效率取决于任务和模型。所以这笔账不能提前算，要在自己的任务和自己的执行模型上分别测一次。3

技能内容优化与流程编译叠加在表格任务上的账也具体：84.2% 的成功率、每题 69k 的消耗，对比原生执行优化后文档的 59.6%、257k——成功率提高 24.6 个百分点，token 减少 73.2%。3

同一天的另一篇：技能分数为什么会骗人

第二篇论文审计一个已经上线的插件升级技能：64 份报告、16 个静态迁移任务、每个条件两次尝试，共 328 次判定。加上技能，记录中的平均奖励从 93.83 升到 98.75，提升 4.92 分（95% 任务自助区间 0.31 到 10.86）。但作者把每一次判定追回它对应的契约条款、并深读其中十份报告之后，看到的是另一幅图：这个提升集中在其中一道题上，还有八对任务已经顶到满分天花板。2

他们找到的评分错误是具体的：有一条判定里，一个「能接受父目录」的收束条件照样拿到满分；可执行的探针证实了这个缺陷，也显示一次真正可用的拆除修复，只是因为生命周期条款更窄而被排除在外。把人工复核过的判定换回去，涨幅仍在 4.61 到 5.39 分之间，但区间碰到甚至跨过了零。换两个别的模型族、去掉分组标签与历史分数重判全部 64 份报告，与原判的一致率是 91.8% 与 95.7%（加权 κ 为 0.64 与 0.72），涨幅变成 10.63 分与 6.09 分。作者把可执行的端到端修复、独立人工标注和其他框架留给后续工作，实验产物已经公开在 GitHub（仓库 144 star、27 fork、464 次提交）。2 6

两篇放在一起看，得到的判据是一致的：技能的收益要靠「追到条款和判定」的评测才能站住，否则一个总分既可能被一道题带起来，也可能被评分口径本身决定。

能搬回自己循环的四条

先把技能文档拆成知识和流程两半。 知识交给模型在每一步里读；流程——顺序、条件、循环上限、终止——写成显式的边，让运行时按条件判定，而不是让模型在每一步重新猜。3
流程的来源是轨迹，不是想象；守住它的是重放。 拿成功与失败的执行记录去对齐、补状态，每接受一次改动就把新旧轨迹全部重放一遍，重放不过就不改。3
给真正的判断留一个标签位。 需要语义判断的地方，让模型输出一个固定标签，由标签决定去向，而不是让它直接决定下一步。3
评技能要追到条款和判定上。 总分可能被一道题带起来，判定本身也可能有错；换个模型族重判一次，才知道这个数字还站不站得住。2