以下根据个人观点及网络资料,并由AI辅助整理
关于 Skill–Script 分层结构的一种思考
在大模型被广泛用于自动化和 Agent 构建之后,一个结构性问题逐渐显现:系统往往仍然是“单次推理型”的。
每次任务执行,都重新规划步骤,重新生成操作路径。即便任务高度重复,成功经验也很少被固化为长期资产。执行依赖的是当下的推理能力,而不是历史上已经验证过的稳定结构。
这种形态在一次性任务中没有问题,但在需要长期运行的系统中,会逐渐暴露局限:相似任务反复消耗推理资源,执行路径存在波动,最优实践难以沉淀。
如果任务具有一定重复性,环境又相对稳定,那么仅依赖即时推理并不是一种长期结构。问题不在模型能力,而在系统形态。
方法与执行的分离
在人类实践中,方法与具体技能天然分层存在。方法相对稳定,变化缓慢;具体操作路径在实践中不断调整与优化。
当前很多大模型系统把“方法”和“执行”压缩在同一次推理中完成——策略、计划、动作生成全部发生在同一层。如果将两者分离,结构会更清晰。
可以抽象出三层:
- 方法层:描述目标、约束与策略原则
- 执行层:具体操作路径
- 评估层:成功判定与退化检测
1 | ┌──────────────────────────────────┐ |
这里所称的 Script,一般指传统意义上的可执行代码(例如 Python、JavaScript 等脚本或程序文件),而不是模型生成的临时文本。它是可以被版本化、运行、替换与优化的实际代码资产。
关键并不在分层本身,而在于执行层是否成为长期资产。
执行资产的形成与维护
在没有现成执行代码时,系统只能依赖方法层直接完成任务。这一阶段的目标不是效率,而是寻找稳定路径。
当某种操作方式在多次运行中表现出稳定成功,就具备被固化的条件。此时可以将成功轨迹抽象为一份传统代码形式的 Script,并作为默认执行方式。
从这一刻起,系统结构发生转变:执行不再依赖持续推理,Script 成为默认执行主体,推理只在必要时介入。当环境变化或执行退化时,再由方法层对 Script 进行修复或重生成,形成一个循环:
1 | ┌─────────────┐ ┌───────────┐ |
推理的角色从“持续操作者”转变为“条件性干预者”。
这一结构也改变了维护方式。在传统软件工程中,人为关注的核心是代码本身,优化、修复、重构都发生在代码层。在这种分层结构下,Script 由系统在方法层指导下生成与优化,人为长期关注的对象转向方法层——目标表达是否清晰,约束是否合理,策略是否稳健,优化原则是否正确。
代码从“持续人工雕刻的主体”转变为“在策略约束下可被替换与重生成的执行产物”。维护的重心上移到了方法与结构表达本身。
与常见 Agent 结构的差异
很多 Agent 系统强调循环推理:观察—思考—行动—再观察,依赖持续推理来保持适应性。
这里的结构不同之处在于:强调执行代码的固化,构建执行代码的生命周期,将推理限定为监督与修复机制。重点不是让系统“持续思考”,而是让系统“逐渐稳定”。
1 | 常见 Agent 结构 Skill–Script 结构 |
适用前提与边界
这种结构并非适用于所有场景。如果任务完全一次性,或环境高度随机且持续变化,或无法定义明确成功标准,那么执行路径难以稳定,固化也缺乏意义。
它更适合任务重复出现、环境局部稳定、成功可被明确判定的长期系统。
核心判断
可以将这一结构压缩为几个基本判断:
- 稳定成功路径应被外化为传统可执行代码资产
- 代码应承担默认执行职责
- 优化必须在评估约束下进行
- 人为维护的核心应位于方法层而非代码层
如果成立,系统就不再只是“每次重新解决问题”,而是在时间维度上逐渐形成稳定能力。它的改变不在于模型更强,而在于结构更长期。