Skill本质是“按需注入的上下文”，不是确定性自动化，模型仍然决定是否遵循，什么时候该接受这一点、什么时候该上代码而不是Skill？

一、导言：一个被普遍误读的机制

过去两年，“Skill”“Agent 技能”“提示词资产”这类词在工程团队里快速流行。流行的叙事大致是：把领域知识、操作步骤、输出规范写成一份结构化文档，挂到系统里，模型在需要时自动加载，于是复杂任务就被“自动化”了。这个叙事在演示环节往往成立，在生产环节却频繁失效——同样的 Skill，昨天执行得一丝不苟，今天漏掉了第三步；上周对某类输入稳定输出 JSON，这周开始夹带解释性文字。工程团队的第一反应通常是“再改改提示词”，第二反应是“换个更强的模型”，很少有人回到最根本的问题：Skill 到底改变了系统的哪个部分？

本文的核心判断是：Skill 的本质是“按需注入的上下文”，它作用于模型的条件输入分布，而不是执行路径本身。注入之后，模型仍然以自回归采样的方式逐 token 生成，是否遵循、遵循到什么程度、在冲突指令之间如何取舍，都由模型在解码时决定。这意味着 Skill 带来的是概率性的行为偏移，而非确定性的流程控制。承认这一点并不悲观，恰恰相反，它是把系统做稳的前提：只有先承认控制权在模型手里，才能判断哪些环节应该把控制权收回来，交给代码。

本文的分析主线是“控制权分配”。围绕这条主线，我们把问题拆成四层：第一层是机制层，Skill 如何被检索、裁剪、注入，注入物在上下文中占据什么位置、受什么约束；第二层是测量层，遵循率是否可以定义、采样、置信区间如何估计；第三层是决策层，在什么边界条件下应当接受概率性遵循，在什么条件下必须改用确定性代码；第四层是架构层，两者如何在同一系统内共存并互相兜底。四层之间是递进关系：机制决定测量的可行域，测量决定决策的证据基础，决策决定架构的形态。

一个容易被忽略的推论：如果 Skill 是上下文注入，那么“Skill 写得越长越详细”并不单调地提升可靠性。上下文窗口是有限资源，注入物之间存在注意力竞争，过长或结构混乱的 Skill 反而会稀释关键约束的权重。可靠性的提升来自“约束的可执行化”，而不是“描述的完备化”。

为了让讨论可验证，本文会给出可复现的测量方法、判定矩阵和落地步骤，并在涉及数据的地方标注来源或明确标注为模拟数据。需要提前说明的是，本文引用的部分行业统计来自公开报告与论文，部分数值为笔者基于公开信息的整合估算，凡属后者均会注明“整合估算”，读者应以原始文献为准。

二、背景与问题定义：Skill 到底是什么

2.1 一个操作性定义

在本文语境下，Skill 指一段在特定触发条件下被系统检索并注入到模型上下文中的结构化文本资产，通常包含适用场景、操作步骤、约束条件、输出格式与示例，可能附带少量可被调用的脚本或工具声明。这个定义有三个要点：其一，Skill 是“资产”而非“程序”，它没有自己的控制流；其二，Skill 的生效依赖“触发—检索—注入”这条链路，链路上任何一环失效，Skill 就等于不存在；其三，Skill 可以包含代码，但代码在 Skill 内部通常以“被模型决定是否调用”的形式存在，而非由宿主程序直接调度。

与之相对，确定性自动化指由宿主程序按固定控制流调度的执行路径：输入经过校验、分支由条件表达式决定、外部调用有超时与重试、输出经过 schema 校验。两者的根本差异不在“是否用了大模型”，而在“谁持有分支决策权”。Skill 把分支决策权留给模型，确定性自动化把分支决策权收归程序。

2.2 为什么这个区分在实践中被模糊

模糊来自三个方向的合力。第一是演示偏差：在少量、典型、短链路的样例上，强模型的遵循率确实很高，演示效果接近确定性，但生产流量是长尾的，长尾上的遵循率会显著下降。第二是工具生态的措辞：不少框架把“技能”“工作流”“编排”混在同一层抽象里，用户在配置界面看到的是流程图，底层实际是“模型决定下一步调哪个工具”，视觉上的确定性掩盖了执行上的概率性。第三是评估方式的粗糙：多数团队只用“最终答案对不对”做验收，不区分“答案对但路径错”和“路径对但答案错”，而后者恰恰是概率性遵循的典型症状。

笔者认为，这种模糊在早期是可以容忍的，因为快速验证的价值高于严谨性；但当系统进入有 SLA 要求的场景，模糊就会转化为事故。一个可操作的判别方法是问一句：“如果模型这次决定不遵循，系统有没有第二道防线？”如果没有，那这套东西本质上仍是概率性的，不能按确定性系统来做容量规划与故障预案。

2.3 问题重述

把上述讨论收敛，本文要回答的问题可以精确化为三个子问题：

（1）机制问题：Skill 注入后，模型的行为在多大程度上、以何种方式受其约束？约束的强度受哪些因素调节？

（2）测量问题：如何定义和估计“遵循率”，使其成为可比较、可回归的工程指标，而不是主观印象？

（3）决策问题：在给定任务的风险、频率、可验证性与变更节奏下，应当把控制权留在模型侧（继续用 Skill），还是收回到程序侧（改上代码），抑或采用混合形态？

这三个问题分别对应后文的原理、数据与判定矩阵三章。需要强调的是，三者不是并列关系，而是链式依赖：机制不清，测量就没有效度；测量不立，决策就没有依据。很多团队跳过前两步直接做架构选型，结果是在错误的证据基础上做正确的决策，长期看仍会返工。

三、原理与技术路线：从检索注入到解码采样

3.1 注入链路：四个可能失效的环节

一条完整的 Skill 生效链路包含四个环节：触发判定、检索排序、上下文裁剪、注入位置。每个环节都有自己的失效模式，且失效往往是静默的。

触发判定决定“这次请求要不要加载某个 Skill”。常见做法是基于规则的关键词匹配、基于向量相似度的召回，或让模型自己判断。规则匹配的失效模式是漏触发与误触发；向量召回的失效模式是语义漂移，尤其在领域术语与通用语义不一致时；让模型自判的失效模式是不稳定，同一请求在不同温度下可能给出不同判断。

检索排序决定“加载哪几个 Skill、按什么顺序”。当多个 Skill 同时命中时，排序直接决定模型看到的第一份指令是什么。这里存在一个常被低估的问题：多个 Skill 之间的约束可能冲突，而冲突消解的责任被隐式地交给了模型。

上下文裁剪决定“Skill 的哪些部分真正进入窗口”。长 Skill 通常会被截断或摘要，截断策略如果按位置而非按重要性，就可能把关键约束裁掉。这个环节的失效最难排查，因为日志里往往只记录了“注入了某 Skill”，没记录“注入了它的哪一段”。

注入位置决定 Skill 在上下文中的相对权重。已有研究反复观察到，长上下文中间位置的信息利用率低于首尾位置，这一现象在多项“大海捞针”式评测中被报告（如 Liu 等 2023 年的 Lost in the Middle 研究）。这意味着同一份 Skill，放在系统提示开头与放在用户消息之后，实际约束强度可能不同。

# 注入链路的可观测性最小集（示意，非某框架真实 API）
trace = {
  "request_id": "...",
  "trigger": {"matched": True, "rule": "billing_refund_v3", "score": 0.91},
  "retrieved": [{"skill": "refund_policy", "rank": 1},
                {"skill": "tone_guide",    "rank": 2}],
  "injected": [{"skill": "refund_policy", "tokens": 812,
                "truncated": False, "position": "system_tail"},
               {"skill": "tone_guide", "tokens": 233,
                "truncated": True,  "position": "system_tail"}],
  "conflicts": ["refund_policy.step3 vs tone_guide.rule2"],
}

上面这段伪代码的重点不是具体字段，而是思路：把“注入了什么、注入了多少、放在哪里、有无冲突”变成结构化日志。没有这层可观测性，后续的遵循率测量无从谈起。本文评述：多数团队在 Skill 治理上的第一笔投入应该花在这里，而不是花在反复重写提示词上，因为前者产生的是可复用的诊断能力，后者产生的是不可迁移的经验。

3.2 解码阶段：为什么“遵循”是概率事件

注入完成后，模型进入自回归解码。每一步在词表上产生一个概率分布，采样策略（温度、top-p、top-k）决定实际取哪个 token。Skill 的作用是改变这个分布的形状——让符合约束的续写概率更高——但不能把某个续写的概率变成 1。这就是“概率性遵循”的数学根源。

可以用一个简化的形式描述。设上下文为 C（含 Skill），已生成前缀为 y<t，模型参数为 θ，则下一步分布为 p(·|C, y<t; θ)。Skill 的注入相当于把 C 从 C₀ 变为 C₀⊕S，从而把分布从 p₀ 变为 p₁。遵循某个约束，意味着在关键决策点上，符合约束的 token 集合的累计概率超过采样阈值。这个累计概率受三类因素调节：约束在上下文中的显著度、约束与模型先验的一致性、以及解码时的随机性强度。

由此可以推出几个工程上可检验的推论。其一，降低温度会提高单次遵循的稳定性，但会牺牲多样性，且在需要探索的任务上可能降低整体质量。其二，当约束与模型先验冲突时（例如要求输出与模型“常识”相反的结论），仅靠 Skill 描述的遵循率会显著低于约束与先验一致的情形，此时需要更强的信号，例如少样本示例、结构化输出约束或外部校验。其三，多步任务中每一步的遵循概率相乘，长链路的端到端遵循率会随步数指数衰减——这是“演示很顺、生产很崩”的主要数学解释之一。

设单步遵循概率为 q，链路有 n 个必须遵循的决策点，则端到端遵循概率约为 qⁿ。当 q=0.97、n=20 时，端到端约 0.54；n=50 时约 0.22。这个粗算模型忽略了错误恢复，但足以说明：长链路任务不能只靠 Skill 保证正确性，必须在中间设置确定性检查点。

笔者认为，这个乘法模型是理解“何时该上代码”的最有用的心智工具。它把模糊的“感觉不太稳”转化为可计算的量：先估计单步遵循率，再数关键决策点，端到端可靠性就有一个数量级上的判断。当然，真实系统有错误恢复与重试，实际值会高于纯乘法估计，但量级判断依然有效。

3.3 三条技术路线的定位

围绕“让模型按预期行事”，业界实际存在三条技术路线，它们对控制权的分配不同，适用边界也不同。

路线 A：纯 Skill 注入。控制权完全在模型侧。优点是灵活、变更成本低、能处理开放式任务；缺点是遵循率不可保证、长链路衰减、冲突消解不可控。适合低频、可人工复核、输出可容错的场景。

路线 B：结构化输出约束与工具调用。控制权部分收回。通过 JSON Schema、函数调用签名、语法约束解码等手段，把“格式”这一层变成确定性；但“选哪个工具、传什么参数”仍由模型决定。适合格式要求严格但内容开放的任务。

路线 C：代码编排。控制权基本收回。由宿主程序定义状态机、分支条件、重试策略与校验规则，模型只在被调用的节点内做局部生成。适合高频、高风险、可形式化验证的任务。

本文评述：这三条路线不是替代关系，而是分层关系。成熟系统的形态通常是 C 包住 B、B 内嵌 A：外层用代码保证流程与安全边界，中层用结构化约束保证接口契约，内层用 Skill 注入处理需要语言理解的开放部分。把三者对立起来讨论“哪个更好”，是选型讨论中最常见的范畴错误。

四、关键数据与案例：遵循率能被测量吗

4.1 把“遵循”操作化

要让遵循率成为工程指标，第一步是把它拆成可判定的原子命题。笔者建议采用三层定义：格式遵循（输出是否符合 schema）、步骤遵循（是否按 Skill 规定的顺序执行了必要步骤）、约束遵循（是否违反了禁止性条款）。三层可以分别测量，也可以加权合成一个综合分。分开测量的价值在于诊断：格式问题通常可以用结构化约束解决，步骤问题往往需要代码编排，约束问题则要看约束是否可被外部校验。

判定的自动化程度决定了测量的可持续性。格式遵循可以完全自动判定；步骤遵循需要执行轨迹，若系统记录了工具调用序列，也可以自动判定；约束遵循最难，部分约束（如“不得承诺退款金额”）可以用规则或小模型分类器判定，部分约束（如“语气专业”）只能抽样人工评估。工程上可行的做法是：前两层全量自动，第三层分层抽样，抽样比例按风险等级设定。

层级	判定对象	自动化手段	典型失效
格式遵循	输出结构	Schema 校验、解析器	夹带解释文字、字段缺失
步骤遵循	执行轨迹	轨迹比对、状态机校验	跳步、顺序颠倒、重复调用
约束遵循	语义边界	规则 + 分类器 + 人工抽样	越界承诺、语气漂移

4.2 样本量与置信区间

遵循率是一个比例估计，必须报告置信区间，否则“97%”和“97%±3%”在决策上是两回事。对于二项比例的近似，常用 Wald 区间，但在比例接近 1 时 Wald 区间会失真，建议使用 Wilson 区间。工程上更实用的做法是直接给出“要证明遵循率不低于 p₀，需要多少样本”的公式化估算。

# Wilson 区间（示意）
def wilson(k, n, z=1.96):
    p = k / n
    d = 1 + z*z/n
    c = p + z*z/(2*n)
    r = z * ((p*(1-p)/n + z*z/(4*n*n)) ** 0.5)
    return ((c - r)/d, (c + r)/d)

# 观测 194/200 遵循，点估计 0.97
# Wilson 95% 区间约为 [0.936, 0.987]
# 若要求区间下界 >= 0.95，样本量需显著增加

这里的工程含义是：小样本上看到的“几乎都遵循”不足以支撑高风险场景的决策。若要把 95% 置信下界做到 0.99，所需样本量在数百到上千量级，具体取决于真实比例。这也是为什么很多团队在灰度期觉得“很稳”，放量后问题集中爆发——灰度样本量根本不足以区分 0.97 和 0.99。

4.3 一个可复现的评测设计（模拟数据）

下面给出一个评测设计的骨架，数据为模拟数据，仅用于说明方法，不代表任何真实系统性能。设计要点是：固定 Skill 版本、固定模型版本、固定解码参数，对同一批任务做多次重复采样，分别统计三层遵循率，并记录失败模式分布。

配置	格式遵循	步骤遵循	约束遵循
短 Skill + 低温	0.99	0.96	0.94
长 Skill + 低温	0.98	0.91	0.88
长 Skill + 默认温度	0.95	0.84	0.80

（上表为模拟数据，用于演示测量方法，非真实实验结论。）从模拟结果可以读出两个方向性判断：长 Skill 对格式层影响不大，但对步骤层与约束层有明显稀释；温度对三层都有影响，且对后两层影响更大。这两个判断与 3.2 节的机制分析一致，说明测量设计与机制模型是自洽的。笔者认为，评测设计的价值不在于得到某个具体数字，而在于让团队对“哪些因素在调节遵循率”形成共同语言，从而在讨论架构时不再各说各话。

关于长上下文利用率的实证，可参考 Liu 等 2023 年的 Lost in the Middle 研究，以及后续多项针对长上下文检索与推理的评测工作；关于指令遵循的评测方法，可参考 IFEval 等公开基准。这些工作提供了方法论基础，但需要注意它们多在通用任务上评测，迁移到具体业务 Skill 时仍需自建评测集。拓展阅读可访问 Lost in the Middle 论文页 与 IFEval 论文页。

五、判定矩阵：什么时候接受，什么时候上代码

5.1 五个判定维度

决策不能靠直觉，需要可讨论的维度。笔者建议用五个维度来刻画一个任务：风险（错误代价是否可逆）、频率（调用量级）、可验证性（输出能否被程序校验）、链路长度（关键决策点数量）、变更节奏（规则多久变一次）。这五个维度共同决定控制权应当放在哪里。

风险高、可验证性低、链路长，三者叠加时，纯 Skill 方案几乎必然出问题，因为错误不可逆、无法自动拦截、且概率衰减严重。反之，风险低、可验证性高、链路短时，Skill 的灵活性与低变更成本就是净收益。频率与变更节奏影响的是投入产出比：高频任务值得为确定性付出开发成本，低频任务则未必；变更节奏快的规则，写死在代码里会带来持续维护负担，此时把规则放在 Skill 里、用评测兜底，反而是更经济的选择。

条件组合	建议形态	理由
低风险 + 短链路 + 高频变更	纯 Skill	灵活性收益最大，错误可人工兜底
中风险 + 格式严格	Skill + 结构化输出	格式层确定性，内容层保留弹性
高风险 + 可验证	代码编排 + 模型局部生成	校验可自动拦截，控制权必须收回
高风险 + 不可验证 + 长链路	拆解为可验证子任务 + 人工复核	整体不可控，只能分段控制
低频 + 长尾输入	Skill + 输出后置校验	开发成本不划算，用校验兜底

5.2 三个必须上代码的信号

矩阵给出的是倾向，实践中还需要更硬的触发条件。笔者认为，以下三个信号出现任意一个，就应当把对应环节改为代码实现，而不是继续调 Skill。

信号一：错误不可逆且无人工复核。例如资金操作、权限变更、对外承诺。这类环节的失败代价无法通过重试或道歉弥补，概率性遵循在此处不可接受。即便模型遵循率很高，剩余的不确定性也足以构成风险敞口。

信号二：约束可以被形式化表达。如果一条规则能用正则、schema、状态机或简单断言表达，那么把它交给模型去“理解并遵守”就是不必要的风险转移。可形式化的规则应当由代码执行，模型只在规则无法形式化的部分发挥作用。这条信号的反面同样重要：如果规则本身模糊、依赖语境判断，强行写成代码会带来大量误判，此时 Skill 反而更合适。

信号三：链路中关键决策点超过阈值且必须全部正确。结合 3.2 节的乘法模型，当必须全部正确的决策点数量使端到端遵循概率低于业务可接受水平时，就必须引入确定性检查点，把长链路切分成若干短段，每段结束后由代码校验并决定是否继续。

反过来，也有三个“不必上代码”的信号：规则变更频率高于代码发布频率；规则本身依赖语义判断、难以形式化；任务量级不足以摊薄开发与维护成本。忽视这三个信号，会导致过度工程化——用几百行代码实现一条本可以用一段 Skill 加人工抽检解决的规则，维护成本反而更高。

5.3 一个判定流程

把矩阵与信号整合成一个可执行的流程，大致如下：第一步，列出任务的全部关键决策点；第二步，对每个决策点判断是否可形式化，可形式化的直接标记为“代码”；第三步，对不可形式化的决策点评估风险与可验证性，高风险且不可验证的标记为“人工复核”，其余标记为“Skill”；第四步，统计 Skill 标记的决策点数量，若端到端遵循概率估计低于阈值，则在中间插入代码检查点，把链路切短；第五步，为所有 Skill 标记的决策点建立评测集与回归机制。这个流程的价值在于它把“要不要上代码”从整体判断变成了逐点判断，避免了“全上代码”和“全靠 Skill”两个极端。

本文评述：逐点判断的方法论与软件工程中的“关注点分离”一脉相承，但有一个新意——它把“模型能否可靠遵循”作为一个可测量的属性纳入了设计决策，而不是把它当作实现细节。这意味着架构评审时需要多问一句：这个环节的遵循率是多少，证据是什么，回归机制在哪里。没有这三个答案的架构方案，在笔者看来是不完整的。

六、工程落地：混合架构的七个步骤

6.1 步骤一至三：盘点、切分、定契约

步骤一，盘点现有 Skill 与失败案例。把线上失败按三层遵循分类，统计各层占比。这一步的产出是一张失败模式分布表，它直接告诉你治理重点在哪一层。很多团队跳过这一步，凭印象认为“主要是格式问题”，实际统计后往往发现步骤跳转才是主因。

步骤二，按决策点切分任务。把端到端流程拆成若干段，每段包含少量决策点，段与段之间定义明确的输入输出。切分的粒度以“单段端到端遵循概率可接受”为准，可参考 3.2 节的乘法模型估算。

步骤三，为每段定义契约。契约包括输入 schema、输出 schema、超时、重试策略与失败降级路径。契约一旦确定，段内实现是用 Skill 还是用代码，对上下游就是透明的。这一步是混合架构的关键，它让“换实现”成为局部变更而非全局重构。

6.2 步骤四至五：实现与注入治理

步骤四，按判定结果实现各段。可形式化的段用代码，不可形式化且风险可控的段用 Skill，高风险不可验证的段加人工复核。实现时注意一个细节：Skill 段内部如果调用了工具，工具的参数校验应当在工具侧做，而不是依赖 Skill 里的文字约束。工具侧校验是确定性的，文字约束是概率性的，把校验放在确定性一侧是基本原则。

步骤五，治理注入链路。包括：为每个 Skill 定义明确的触发条件并记录触发日志；控制单次注入的 Skill 数量与总 token 预算；对冲突约束建立优先级规则并在注入前消解，而不是留给模型；把关键约束放在上下文的首尾位置而非中段。这些措施不能把遵循率变成 1，但能显著改善分布。

# 注入治理的检查清单（伪配置）
injection_policy:
  max_skills_per_request: 3
  max_skill_tokens: 1200
  conflict_resolution: explicit_priority   # 不交给模型
  critical_constraints_position: head_tail # 首尾优先
  truncation: by_section_priority          # 不按位置截断
  log_fields: [trigger, ranks, tokens, truncated, position, conflicts]

6.3 步骤六至七：评测与回归

步骤六，建立分层评测集。评测集应覆盖典型输入、边界输入与历史失败案例，三层遵循分别有对应指标。评测频率与变更挂钩：Skill 变更、模型升级、解码参数调整都必须触发回归。这里有一个容易被忽视的点——模型版本升级会改变遵循率，即便 Skill 一字未改。把模型版本作为评测维度固定下来，是避免“升级后悄悄退化”的必要措施。

步骤七，建立线上监控与漂移告警。线上监控应至少包含：各层遵循率的滚动统计、失败模式分布的变化、注入 token 数的分布、以及人工复核的拦截率。漂移告警的阈值应基于历史方差设定，而非拍脑袋。当某层遵循率出现统计显著下降时，先查注入链路（是否漏触发、是否截断、是否冲突未消解），再查模型侧（是否版本变更、是否流量分布变化）。

关于评测与可观测性的工程实践，可参考 OpenAI 评测最佳实践文档 与 Anthropic 工程博客，其中关于提示工程与评测的讨论对理解注入治理有直接帮助。视频类拓展可参考 上下文工程相关技术分享（检索时请注意甄别来源可靠性）。

七、对比与局限：Skill、工具调用、代码编排的三角关系

7.1 三者的能力边界

Skill、工具调用与代码编排常被放在一起比较，但它们解决的问题不同。Skill 解决的是“模型不知道领域知识或操作规范”的问题；工具调用解决的是“模型需要与外部世界交互”的问题；代码编排解决的是“流程需要确定的控制流”的问题。三者可以独立存在，也可以组合。把 Skill 当作流程控制手段，是三者错位中最常见的一种。

从控制权角度看，三者的谱系是连续的：纯 Skill 完全让渡控制权，工具调用让渡“选哪个、传什么”但保留格式确定性，代码编排收回绝大部分控制权。工程上选择哪一点，取决于 5.1 节的五个维度。本文评述：把这条谱系画出来之后，很多争论会自然消解——争论双方往往只是在谱系上站的位置不同，而不是对事实有分歧。

7.2 局限与未解问题

本文的分析框架有三个明显局限。第一，遵循率的测量依赖评测集质量，而评测集的构建本身带有主观性，覆盖不足的评测集会系统性高估遵循率。第二，乘法模型是粗粒度近似，忽略了错误恢复、上下文累积效应与模型在不同任务上的异质性，实际系统需要更精细的建模。第三，判定矩阵的维度权重需要按业务校准，本文给出的是定性框架而非定量公式，直接套用可能产生偏差。

未解问题同样值得记录。其一，多 Skill 冲突的自动消解仍缺乏通用方法，目前主要靠人工定义优先级。其二，长上下文中的注意力分配机制尚未被完全理解，注入位置的最优策略更多来自经验而非理论。其三，模型升级带来的遵循率漂移缺乏标准化的评估协议，业界各做各的，结果不可比。其四，如何在保证确定性的同时保留语言模型的灵活性，仍是架构层面的开放问题。笔者认为，这些问题的解决不会来自单一突破，而会来自评测方法、架构模式与模型能力的共同演进。

7.3 与既有研究的对话

指令遵循研究方面，IFEval 等工作提出了可验证的指令遵循评测方法，为本文的三层定义提供了方法论参照；但 IFEval 侧重单轮、可自动判定的指令，对多步、跨轮、依赖工具的场景覆盖有限。长上下文方面，Lost in the Middle 揭示了位置效应，后续多项工作从检索增强、位置编码、注意力机制等角度提出改进，但工程上最直接有效的仍是“把关键信息放首尾、控制注入总量”这类朴素手段。Agent 架构方面，ReAct、Toolformer 等经典工作确立了“推理—行动”交替的范式，本文的工具调用定位与其一脉相承。本文评述：既有研究多在通用基准上验证机制，本文的价值在于把这些机制映射到具体业务的决策流程上，给出可操作的判定与落地路径——这既是工程化的必要一步，也是检验理论是否真正有用的试金石。

八、结论与展望

回到标题的问题：Skill 是不是确定性自动化？答案是否定的。Skill 是按需注入的上下文，它改变模型的条件输入分布，而模型在解码阶段仍以概率方式决定是否遵循。承认这一点，不是否定 Skill 的价值，而是把它放在正确的位置上——它是处理语义判断、领域知识与开放任务的合适工具，但不是流程控制与安全边界的合适工具。

什么时候该接受概率性遵循？当任务风险可控、输出可人工或程序复核、链路较短、规则变更频繁时，Skill 的灵活性与低变更成本是净收益，此时应当接受概率性，并把精力投入到评测与监控上。什么时候该上代码？当错误不可逆、约束可形式化、或长链路必须全部正确时，控制权必须收回，代码编排是唯一可靠的选择。两者之间的大片地带，属于混合架构：代码保证流程与边界，结构化约束保证接口契约，Skill 处理需要语言理解的局部。

展望未来，笔者认为有三个方向值得关注。第一是评测标准化：如果业界能就遵循率的定义、采样方法与报告格式形成共识，架构决策就有了可比证据。第二是约束解码与结构化生成的进一步成熟：它能把一部分“概率性遵循”转化为“确定性满足”，从而移动那条分界线。第三是混合架构模式的沉淀：类似设计模式之于面向对象，混合架构也需要可复用的模式语言，让团队不必每次都从零推导。这三条路径都不依赖某个模型的突破，而依赖工程共同体的积累——这也意味着，今天就可以开始做。

最后给出一条可立即执行的建议：挑一个正在用 Skill 的线上流程，按 4.1 节的三层定义统计一周的失败分布，再按 5.3 节的流程逐点判断控制权归属。这个练习通常只需几天，但它带来的认知变化，往往比读十篇文章更直接。

九、主要参考文献