在 AI Agent 的日常使用中，有一类问题出现的频率远高于预期：同样的操作，在不同的时间执行，结果不一样。同样的 Skill，在不同的会话里，成功率有明显波动。更棘手的是，当一个多步骤操作失败的时候，很难快速定位是哪一步出了问题、是 LLM 理解错了还是工具调用出了问题、是环境状态的问题还是逻辑本身的问题。 这不是偶发的边缘 case，而是在相当大量的实践场景里系统性出现的模式。它意味着，我们对 Skill 的设计方式有根本性的认知偏差。

LLM 随机性在工程场景是系统性风险

在创意写作、头脑风暴、开放性问答这类场景里，LLM 的随机性是优点。同一个问题每次得到略有不同的回答，这种多样性是有价值的。 但在工程自动化场景里，随机性的性质完全变了。 假设你有一个 Skill，需要依次执行：读取配置文件、解析参数、调用 API、处理返回值、写入结果。这个链条里，每一步都依赖上一步的输出。如果 LLM 在解析参数这一步因为 temperature 设置或者上下文长度变化，给出了一个格式略有不同的输出，后续步骤就可能全部出错。 这种错误有几个让工程师头疼的特性。首先，它不是确定性的——同样的输入有时成功有时失败，这让调试极其困难，因为你无法稳定复现问题。其次，它是级联的——越靠后的步骤，错误来源越难追溯。第三，它和模型版本、上下文内容、会话历史都可能有关联，这些变量在生产环境里难以控制。 用概率论量化一下：一个十步操作链，如果每步成功率是 90%，整体成功率就只有 35%。这在工程上是不可接受的，而且靠调整提示词无法根本解决。

确定性与不确定性任务的分离原则

解决这个问题的核心思路，来自一个古老的软件工程原则：把确定性任务和不确定性任务分离，分别用最适合的方式处理。 确定性任务，是指给定相同的输入，期望得到相同的输出的操作。读取配置、格式转换、API 调用、文件读写、状态检查——这些操作的正确行为在设计时就完全确定了。把它们交给 LLM 动态生成代码去执行，是错误的工具选型。它们应该被写成固定的脚本，每次执行都走确定的代码路径。 不确定性任务，是指需要根据上下文做出判断、需要在模糊情境里做选择、需要处理自然语言输入的操作。这些任务的核心价值恰恰在于它不能被完全规则化，需要某种程度的语义理解和推理。这才是 LLM 应该专注的地方。 这个分离原则听起来简单，但在 Skill 设计实践里经常被违反。很多 Skill 的写法是：给 LLM 一大段自然语言描述操作步骤，然后期望 LLM 每次都能正确地把它翻译成工具调用。这相当于把确定性任务的执行职责委托给了一个概率性系统。

两层架构的具体设计

基于这个分离原则，一个稳定的 Skill 架构应该分成两层，各司其职。 第一层：知识文档层 这一层的内容是关于「这件事是什么、有哪些背景、边界条件和注意事项在哪里」的结构化知识。它是 LLM 做决策时的参考库，提供的是上下文信息，而不是执行指令。 好的知识文档层应该包括：操作的目标和适用场景、常见的错误模式和排查路径、关键概念的定义和它们之间的关系、历史上踩过的坑和对应的解决方案。这一层的内容应该以人类可读为优先，它既是给 LLM 的参考资料，也是给维护者的文档。 第二层：固化脚本层 这一层是把确定性操作封装成可以直接调用的函数或脚本。每个脚本有明确的输入规格、输出规格、错误处理逻辑和日志输出。LLM 在这个架构里的职责，是根据知识文档层的上下文和当前任务需求，决定调用哪个脚本、用什么参数——而不是去生成脚本内容本身。 这个职责划分带来了几个工程上的好处：脚本层可以独立测试，每个函数的行为是完全确定的，可以写单元测试；LLM 的决策范围被限制在「选哪个脚本、参数是什么」这个相对小的问题空间里；错误追踪变得清晰——脚本执行失败是工具层的问题，调用了错误的脚本是 LLM 决策层的问题，两类问题的排查路径完全不同。

经验沉淀的工程化路径

这个架构的另一个深层价值，是解决了组织里经验难以沉淀的老问题。 传统上，工程经验存在于人的脑子里：有人知道「调这个接口的时候要注意超时设置」、「这个环境变量在测试环境和生产环境不一样」、「这个操作在某个版本之后行为变了」。这些知识在人员流动时大量流失，在新人入职时需要反复口口相传。 在两层架构里，这类知识有了明确的归宿。它进入知识文档层，成为机器可读同时人类可维护的结构化文档。脚本层里的错误处理逻辑，本身就是已知边界条件的编码。每一次踩坑，都可以对应地在某一层留下痕迹。 这个工程化路径的本质，是把隐性知识转化为显性知识，再把显性知识的确定性部分进一步转化为可执行代码。这个转化链条的每一步，都在提升系统的整体可靠性，同时降低对特定人员经验的依赖。 一个好的 Skill 在被使用一百次之后，应该比被使用十次时更稳定、更完善，而不是依然在原地踏步地重复踩同样的坑。这不是理想状态，而是在工程设计上完全可以实现的目标——前提是你把错误反馈和经验沉淀当作 Skill 架构的一等公民，而不是事后才想到的附加功能。