将执行路径固化为资产：一种面向长期运行的 AI 架构

发表于

以下根据个人观点及网络资料，并由AI辅助整理

关于 Skill–Script 分层结构的一种思考

在大模型被广泛用于自动化和 Agent 构建之后，一个结构性问题逐渐显现：系统往往仍然是“单次推理型”的。

每次任务执行，都重新规划步骤，重新生成操作路径。即便任务高度重复，成功经验也很少被固化为长期资产。执行依赖的是当下的推理能力，而不是历史上已经验证过的稳定结构。

这种形态在一次性任务中没有问题，但在需要长期运行的系统中，会逐渐暴露局限：相似任务反复消耗推理资源，执行路径存在波动，最优实践难以沉淀。

如果任务具有一定重复性，环境又相对稳定，那么仅依赖即时推理并不是一种长期结构。问题不在模型能力，而在系统形态。

方法与执行的分离

在人类实践中，方法与具体技能天然分层存在。方法相对稳定，变化缓慢；具体操作路径在实践中不断调整与优化。

当前很多大模型系统把“方法”和“执行”压缩在同一次推理中完成——策略、计划、动作生成全部发生在同一层。如果将两者分离，结构会更清晰。

可以抽象出三层：

  • 方法层：描述目标、约束与策略原则
  • 执行层：具体操作路径
  • 评估层：成功判定与退化检测
1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌──────────────────────────────────┐
│            方法层                │
│   目标描述 · 约束条件 · 策略原则  │  ← 人为长期维护的核心
└──────────────┬───────────────────┘
               │ 指导 / 修复
┌──────────────▼───────────────────┐
│            执行层                │
│     Script（可执行代码资产）      │  ← Python / JavaScript 等
└──────────────┬───────────────────┘
               │ 执行结果
┌──────────────▼───────────────────┐
│            评估层                │
│       成功判定 · 退化检测         │  ← 触发修复或重生成
└──────────────────────────────────┘

这里所称的 Script，一般指传统意义上的可执行代码（例如 Python、JavaScript 等脚本或程序文件），而不是模型生成的临时文本。它是可以被版本化、运行、替换与优化的实际代码资产。

关键并不在分层本身，而在于执行层是否成为长期资产。

执行资产的形成与维护

在没有现成执行代码时，系统只能依赖方法层直接完成任务。这一阶段的目标不是效率，而是寻找稳定路径。

当某种操作方式在多次运行中表现出稳定成功，就具备被固化的条件。此时可以将成功轨迹抽象为一份传统代码形式的 Script，并作为默认执行方式。

从这一刻起，系统结构发生转变：执行不再依赖持续推理，Script 成为默认执行主体，推理只在必要时介入。当环境变化或执行退化时，再由方法层对 Script 进行修复或重生成，形成一个循环：

1
2
3
4
5
6
7
8
9
┌─────────────┐       ┌───────────┐
│   Script    │──────▶│  评估结果  │
│  默认执行   │       └─────┬─────┘
└─────────────┘             │ 退化/失败
        ▲                   ▼
        │            ┌───────────┐
        └────────────│   方法层  │
          修复/重生成 │  条件介入  │
                     └───────────┘

推理的角色从“持续操作者”转变为“条件性干预者”。

这一结构也改变了维护方式。在传统软件工程中，人为关注的核心是代码本身，优化、修复、重构都发生在代码层。在这种分层结构下，Script 由系统在方法层指导下生成与优化，人为长期关注的对象转向方法层——目标表达是否清晰，约束是否合理，策略是否稳健，优化原则是否正确。

代码从“持续人工雕刻的主体”转变为“在策略约束下可被替换与重生成的执行产物”。维护的重心上移到了方法与结构表达本身。

与常见 Agent 结构的差异

很多 Agent 系统强调循环推理：观察—思考—行动—再观察，依赖持续推理来保持适应性。

这里的结构不同之处在于：强调执行代码的固化，构建执行代码的生命周期，将推理限定为监督与修复机制。重点不是让系统“持续思考”，而是让系统“逐渐稳定”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
常见 Agent 结构                    Skill–Script 结构
┌─────────────────────┐           ┌─────────────────────┐
│  观察→思考→行动→…   │           │       方法层         │
│    持续推理驱动      │           │    仅在退化时介入     │
│                     │           └──────────┬──────────┘
│  适应性强            │                      │
│  但难以沉淀          │           ┌──────────▼──────────┐
└─────────────────────┘           │   Script 默认执行    │
                                  │   稳定运行·可沉淀     │
                                  └──────────┬──────────┘
                                             │
                                  ┌──────────▼──────────┐
                                  │       评估层         │
                                  └─────────────────────┘

适用前提与边界

这种结构并非适用于所有场景。如果任务完全一次性，或环境高度随机且持续变化，或无法定义明确成功标准，那么执行路径难以稳定，固化也缺乏意义。

它更适合任务重复出现、环境局部稳定、成功可被明确判定的长期系统。

核心判断

可以将这一结构压缩为几个基本判断：

  • 稳定成功路径应被外化为传统可执行代码资产
  • 代码应承担默认执行职责
  • 优化必须在评估约束下进行
  • 人为维护的核心应位于方法层而非代码层

如果成立，系统就不再只是“每次重新解决问题”，而是在时间维度上逐渐形成稳定能力。它的改变不在于模型更强，而在于结构更长期。