以下根据个人观点及网络资料，并由AI辅助整理
关于 Skill–Script 分层结构的一种思考
在大模型被广泛用于自动化和 Agent 构建之后，一个结构性问题逐渐显现：系统往往仍然是“单次推理型”的。
每次任务执行，都重新规划步骤，重新生成操作路径。即便任务高度重复，成功经验也很少被固化为长期资产。执行依赖的是当下的推理能力，而不是历史上已经验证过的稳定结构。
这种形态在一次性任务中没有问题，但在需要长期运行的系统中，会逐渐暴露局限：相似任务反复消耗推理资源，执行路径存在波动，最优实践难以沉淀。
如果任务具有一定重复性，环境又相对稳定，那么仅依赖即时推理并不是一种长期结构。问题不在模型能力，而在系统形态。
方法与执行的分离
在人类实践中，方法与具体技能天然分层存在。方法相对稳定，变化缓慢；具体操作路径在实践中不断调整与优化。
当前很多大模型系统把“方法”和“执行”压缩在同一次推理中完成——策略、计划、动作生成全部发生在同一层。如果将两者分离，结构会更清晰。
可以抽象出三层：
- 方法层：描述目标、约束与策略原则
- 执行层：具体操作路径
- 评估层：成功判定与退化检测
1 | ┌──────────────────────────────────┐ |
这里所称的 Script，一般指传统意义上的可执行代码（例如 Python、JavaScript 等脚本或程序文件），而不是模型生成的临时文本。它是可以被版本化、运行、替换与优化的实际代码资产。
关键并不在分层本身，而在于执行层是否成为长期资产。
执行资产的形成与维护
在没有现成执行代码时，系统只能依赖方法层直接完成任务。这一阶段的目标不是效率，而是寻找稳定路径。
当某种操作方式在多次运行中表现出稳定成功，就具备被固化的条件。此时可以将成功轨迹抽象为一份传统代码形式的 Script，并作为默认执行方式。
从这一刻起，系统结构发生转变：执行不再依赖持续推理，Script 成为默认执行主体，推理只在必要时介入。当环境变化或执行退化时，再由方法层对 Script 进行修复或重生成，形成一个循环：
1 | ┌─────────────┐ ┌───────────┐ |
推理的角色从“持续操作者”转变为“条件性干预者”。
这一结构也改变了维护方式。在传统软件工程中，人为关注的核心是代码本身，优化、修复、重构都发生在代码层。在这种分层结构下，Script 由系统在方法层指导下生成与优化，人为长期关注的对象转向方法层——目标表达是否清晰，约束是否合理，策略是否稳健，优化原则是否正确。
代码从“持续人工雕刻的主体”转变为“在策略约束下可被替换与重生成的执行产物”。维护的重心上移到了方法与结构表达本身。
与常见 Agent 结构的差异
很多 Agent 系统强调循环推理：观察—思考—行动—再观察，依赖持续推理来保持适应性。
这里的结构不同之处在于：强调执行代码的固化，构建执行代码的生命周期，将推理限定为监督与修复机制。重点不是让系统“持续思考”，而是让系统“逐渐稳定”。
1 | 常见 Agent 结构 Skill–Script 结构 |
适用前提与边界
这种结构并非适用于所有场景。如果任务完全一次性，或环境高度随机且持续变化，或无法定义明确成功标准，那么执行路径难以稳定，固化也缺乏意义。
它更适合任务重复出现、环境局部稳定、成功可被明确判定的长期系统。
核心判断
可以将这一结构压缩为几个基本判断：
- 稳定成功路径应被外化为传统可执行代码资产
- 代码应承担默认执行职责
- 优化必须在评估约束下进行
- 人为维护的核心应位于方法层而非代码层
如果成立，系统就不再只是“每次重新解决问题”，而是在时间维度上逐渐形成稳定能力。它的改变不在于模型更强，而在于结构更长期。
附录
原思考整理
在这种结构中，首先需要有明确且稳定的验收标准。只要结果是否正确可以被判断，系统就具备了自动运行和自我修复的基础。
在执行层面，大模型根据提示词自动分析网页结构并生成对应的操作脚本。脚本被定时运行，一旦运行过程中发现错误或执行结果不符合验收标准，系统就会重新调用大模型分析问题并自动修改脚本，然后继续运行。整个过程可以长期持续，而无需人为频繁介入。
在这种模式下，真正长期稳定存在的“代码”其实是提示词本身。提示词描述的是方法论和策略，例如任务目标、约束条件、成功判定方式等。这些内容不会频繁改变，但它可以驱动系统自动生成和维护实际执行的脚本。因此，一旦执行路径稳定下来，系统就会优先运行已经固化的脚本，从而减少对大模型推理的依赖，显著降低 token 消耗。
这种结构和人的工作方式其实非常相似。人完成一次复杂思考之后，往往会把结论或路径记录下来，例如写成笔记、总结出一条方法论，或者直接写成代码。方法论本身通常不会频繁改变，但具体执行方式会不断被修正和完善。
在运行过程中，人会通过方法论不断验证结果。如果发现结果有问题，就会调整执行方式，例如修改代码、修订笔记，或者优化具体步骤。方法论本身仍然保持稳定，但执行层会不断演化。
在 AI 系统中，这一层“方法论”正对应今天的提示词、Skill 或策略描述。这些文本不需要频繁修改，但它们可以驱动系统自动运行已经固化的代码，并在环境变化或执行失败时重新调整脚本。
之所以需要将执行路径固化下来，是因为大量任务本身具有重复性。对于重复工作，人不需要每次都重新思考。同样，如果每次都重新生成执行方案，也可能得到不同结果，甚至错过曾经达到过的最佳方案。
可以用一个简单的例子理解这一点：假设花了三天时间写出了一份很好的方案，如果电脑突然死机，虽然仍然具备重新写方案的能力，但重新写出来的版本可能加入了一些新想法，也可能遗漏了原来方案中的一些关键细节。最理想的情况其实是在原有方案的基础上持续改进，而不是每次都从零开始重新思考。
在系统结构上也是类似的逻辑。
方法论层（提示词 / Skill）只描述整体策略，并不包含具体细节；
而执行层（Script / 代码）则会具体到操作级别，例如网页的按钮、输入框、流程顺序等。
两者的抽象层级不同：方法论负责指导方向，而代码负责完成具体执行。
正是通过这种分层结构，系统才能在长期运行过程中不断积累稳定的执行路径，同时保持方法层的简洁与稳定。