借鉴编译器思路，让Agent技能跨模型稳定运行

一、技能“水土不服”：一个高频却常被误诊的问题

如果你在日常开发中经常使用各类智能体（Agent）框架与编程助手，大概率经历过以下几种“不稳定”：

• 同一个技能，搭配旗舰商用大模型时执行得行云流水，换成参数量较小的本地模型后，不是在某个步骤反复打转，就是输出与预期大相径庭；
• 同一条工作流，在某个命令行编程助手里表现稳定，迁移到另一款智能体框架后，输出格式直接崩坏，下游解析随之失效；
• 技能作者机器上一切正常的脚本，到了你的环境里，因为缺少某个命令行工具或依赖库，陷入“报错—重试—再报错”的循环。

这类问题的第一嫌疑人往往被认为是“模型不够聪明”。但大量实践指向另一个结论：模型通常具备完成任务的基础能力，真正拖后腿的，是技能本身对模型能力、工具接口、路径规则、依赖环境和输出格式做出了太多未经声明的“隐含假设”。

强模型可以靠临场推理绕开这些坑：路径不存在就自己搜，依赖缺失就自己装，格式错了就自我修正。能力弱一些的模型则容易卡死在这些非核心环节上。更值得警惕的是，即便强模型每次都能自救，代价也真实存在，更多的token消耗、更多的工具调用轮次、更长的端到端延迟。隐含假设带来的失稳，最终都会折算成成本与等待，侵蚀智能体系统应有的效率收益。

二、根因剖析：技能中的五类隐含假设

把失稳的技能拆开看，隐含假设大体可归为五类：

1. 对模型能力的假设。 技能默认执行模型具备强指令遵循能力、足够的上下文窗口、稳定的工具调用与结构化输出能力。一旦换用能力较弱的模型，“一步到位”式的长流程描述就容易失控，技能没有变，是假设的前提塌了。

2. 对工具接口的假设。 技能默认某个工具一定存在、参数名称与返回结构保持一致。但不同框架对同一能力的工具命名、参数组织方式往往并不相同，技能中写死的接口细节，会成为迁移时的第一道断裂点。

3. 对文件系统与操作系统的假设。 绝对路径、路径分隔符、shell方言、可写目录、可执行权限，这些在作者机器上成立的细节，换一台机器、换一个操作系统就可能全部失效，而技能对此只字未提。

4. 对依赖环境的假设。 语言运行时版本、第三方库、命令行工具、内外网可达性，都是技能的“隐形地基”。地基缺一块，模型往往只能在反复报错中摸索，白白消耗预算。

5. 对输出契约的假设。 技能默认模型会稳定输出某种Markdown结构或合法JSON，供下游程序解析。而格式漂移恰恰是大模型最常见的不稳定面之一，弱模型尤甚。

五类假设的共同点是：它们都不写在技能里，却真实作用于技能的每一次执行。强模型“兜底”掩盖了问题，弱模型把问题暴露出来；而无论哪种模型，都在为此支付额外成本。

三、视角转换：技能是程序，模型是处理器，框架是运行时

近期一项来自高校研究团队的系统性研究，把这个问题从“提示词工程”重新定义为“系统工程”：技能本质上是自然语言编写的程序；不同的大模型相当于异构处理器，各自支持的“指令集”（推理深度、工具调用、格式遵循等）参差不齐；各类智能体框架则相当于运行环境，提供不同的工具注册机制、上下文管理策略与调度方式。这一思路常被称为“语言虚拟机”——即在技能与底层异构环境之间，抽象出一台稳定、统一的虚拟机。

这个类比的价值在于，它把一个看似新颖的问题，接到了一门非常成熟的学科上。软件工业在过去几十年里，正是依靠“编译器—中间表示—虚拟机—标准运行时库”的分层体系，解决了“一次编写、到处运行”的跨硬件兼容难题。今天技能所面临的跨模型、跨框架、跨环境问题，与当年的跨硬件问题在结构上高度同构，编译器领域的既有经验可以直接平移过来。

四、借鉴编译器设计的四个关键机制

1. 中间表示：把“意图”与“适配”分层。 编译器从不把高级语言直接翻译成某款处理器的机器码，而是先生成与硬件无关的中间表示，再由后端面向不同平台生成目标代码。对应到技能工程：技能中“要完成什么任务、遵循什么流程”的业务意图，应当与“面向哪个模型、哪个框架、哪个环境”的平台适配分离。意图层保持稳定，适配层按需生成，为多个模型维护多份长篇技能，就变成了维护一份意图描述加若干薄适配层，维护成本呈数量级下降。

2. 能力探测：为模型建立“指令集画像”。 处理器世界早已习惯在启动阶段通过标准指令探测硬件特性。类似地，技能执行前可以先做轻量探测：当前模型是否支持工具调用？是否支持结构化输出？上下文窗口多大？据此动态选择执行路径，支持结构化输出就走严格Schema路径，不支持就切换为带解析容错的文本协议；上下文紧张就改用分步执行加检查点。核心原则是：让执行路径适配模型，而不是苛求模型适配技能。

3. 运行时适配：把依赖与前置条件显式化。 用声明式元数据描述环境假设，并在执行前做前置自检（preflight），示意如下：

# skill.yaml —— 把隐含假设"写出来"，而不是"藏起来"
name: repo-code-review
description: 对指定代码仓库执行静态检查并生成评审报告
runtime:
  os: [linux, darwin]
  shell: bash
  python: ">=3.9"
dependencies:
  - command: [git, jq]
  - pip: ["pyyaml>=6.0"]
io:
  input:
    repo_path: { type: path, must_exist: true }
  output:
    format: json
model:
  min_context_tokens: 32000
  requires: [tool_call, json_mode]

def preflight(ctx) -> Report:
    checks = [
        check_python(">=3.9"),
        check_commands(["git", "jq"]),
        check_pip(["pyyaml>=6.0"]),
        check_path(ctx.repo_path, must_exist=True),
    ]
    failed = [c for c in checks if not c.ok]
    if failed:
        # 不把原始报错丢给模型反复试探，
        # 而是生成带修复指引的结构化反馈
        return Report(status="blocked", guidance=[c.hint for c in failed])
    return Report(status="ready")

前置自检的意义在于：把“让模型在报错中摸索”变成“程序化地提前拦截并给出修复指引”。一次探测的固定成本，远低于多轮试错的边际成本。

4. 输出契约：校验—反馈—重试闭环。 输出格式不应只靠提示词“叮嘱”，而应由机器可校验的Schema硬约束；校验失败时，把结构化的错误信息回传给模型做定向重试，并设置有限重试与降级出口。“生成—校验—反馈”构成闭环后，格式问题被拦截在技能边界之内，而不会漂移到下游造成连锁故障。

五、可落地的工程实践清单

把上述机制落到日常开发中，可以归纳为一份清单：

• 假设清单先行。 动笔前先按模型、工具、路径、依赖、格式五类列出全部隐含假设，逐一显式化到文档或元数据中，让“没说出口的前提”无处藏身。
• 依赖与版本进元数据。 语言版本、库版本、命令行工具全部声明化，由运行环境统一安装，而不是指望模型现场排障。
• 前置自检不可省。 环境探测放在执行之前，失败即返回结构化修复指引，从源头掐断“报错循环”。
• 给工具调用配示例。 对能力较弱的模型，为每个工具附带一到两个调用示例（few-shot），可显著降低参数组装的出错率。
• 输出用Schema硬约束。 定义输出JSON Schema并做机器校验，失败带错误信息定向重试，超过阈值降级为人工处理，避免无限循环。
• 分步执行与检查点。 长流程拆为离散步骤，每步落盘检查点，一步失败可从断点恢复，避免全盘重来带来的重复开销。
• 建立模型矩阵回归测试。 技能发布前，至少在“强模型—中等模型—本地小模型 × 不同框架”的组合上做一轮冒烟回归，把失稳消灭在发布之前。
• 像管理代码一样管理技能。 技能纳入版本控制、评审与变更记录，迁移、回滚与归因都有迹可循。

六、企业视角：技能资产的可持续性

对企业而言，这套方法论的意义不止于“少报错”。技能沉淀了组织的流程知识，是重要的知识资产；如果每份技能都与某个模型、某个框架深度绑定，企业实质上是在持续积累“迁移负债”，模型供应商调价、能力变化或引入新模型时，资产转换成本会非常高。

可移植的技能也是多模型策略的前提：复杂任务交给能力更强的模型，简单任务交给成本更低的模型，这种分工只有当技能与具体模型解耦时才能真正落地，降本才有确定性。在云上落地这套体系时，通用的模型推理服务、标准化的容器运行环境、日志与监控告警等基础设施能力都可以直接复用，以百度智能云为例，其模型服务与云原生运行环境适合承载技能的运行时适配层与回归测试基线，执行日志与失败率指标沉淀下来，就是技能可移植性持续改进的数据依据。

七、结语

技能稳定性问题，正在从“写好一段提示词”演进为“做好一套工程”。核心转变只有一句话：把隐含假设显式化，把临场推理程序化。借鉴编译器数十年沉淀的分层与抽象经验——中间表示、能力探测、运行时适配、输出契约，技能完全可以像经过良好编译的程序一样，跨模型、跨框架、跨环境稳定运行。对开发者，这意味着更少的返工与更低的token浪费；对企业，这意味着一份真正可积累、可迁移的智能体知识资产。