Agent Skills时代：强弱模型的差异到底有多大？戳破你的“平替”幻觉｜牛津最新

目前，行业的开发焦点正快速向Openclaw等以Agent Skills为核心的框架收拢。大家已经达成共识：把重复的API链路写成可执行的Agent Skills，是解决长周期任务“上下文爆炸”的唯一途径。但理念确立后，真正的实战深水区才刚刚开始。面对Openclaw的选型配置，您大概率会被以下四个架构问题卡住：

1. Skill的构建，到底该用一个昂贵的强模型（如Claude Opus4.6）一次性解决问题？还是用弱模型堆量试错？差异到底有多大？
2. 多智能体到底怎么协同？如果我有一个Multi Agent龙虾🦞团队，主模型和边缘模型应该如何分配职能？
3. Skill树要不要点满？复杂的嵌套调用会不会超出了LLM的能力极限？边界在哪里？生产环境最稳定的方案是什么？
4. Agent Skills作为泛化接口的隐性认知成本有多高？Agent在什么情况下必须果断放弃Skills？直接裸调底层API？

牛津大学近期发布的《SkillCraft》基准测试，恰好为这四个具体的痛点提供了极其精确的量化解答。

修猫今天的这篇文章不讲空洞的宏观趋势，我们将直接通过该研究拆解出的Token 账单、报错堆栈和调用日志，为您揭示Skills时代多智能体协同的底层设计逻辑。

SkillCraft基准与测试环境构建

为了确保后续所有架构建议的数据可靠性，我们必须首先审查研究者是如何构建测试沙盒与评估标准的。这也是过滤掉毫无工程价值的“跑分玩具”，获取真实工业级数据的关键。

现有工具链评估的系统性缺陷

目前的工具使用基准测试（如WebArena、AgentCompany等）通常在部署时固定工具集，采用单实例的评估逻辑：即测试智能体能否使用给定工具解决当前这单个一次性任务。这种单次测试在长周期任务中暴露出两个核心效率瓶颈：

• 冗余的状态传递：复杂的业务逻辑被分解为一系列原子操作。在这个过程中，中间结果（如庞大的网页DOM树或冗长的JSON API响应）在连续的工具调用之间反复被序列化，并被强制注入到模型的上下文中，产生了极其高昂的Token I/O开销。

• 上下文窗口饱和：漫长的工具调用序列及其海量返回结果占据了大量上下文容量，导致模型在执行后期严重丢失早期信息，甚至完全偏离最初的系统指令。

任务池构建与多维扩展逻辑

研究者构建的SkillCraft基准测试，故意在单个任务中嵌入重复的子结构，迫使智能体在固定的资源预算内多次识别并复用工具组合。构建过程通过严谨的三阶段流水线完成：

• 阶段一与阶段二：从现有基准提取任务设计原则，并基于真实的公共Web API（如GitLab、Open-Meteo、TVMaze等）和本地数据集构建了21个种子任务。

• 阶段三（多维扩展）：研究者沿着两个正交轴扩展了种子任务：数量扩展（例如，从“分析1个仓库”增加到“分析5个仓库”）和复杂性扩展（增加每个子实体所需的底层API调用次数）。

最终，SkillCraft确立了极度标准化的测试用例：

包含跨越6大领域（娱乐、参考、教育、开发者、科学、食品）的126个长周期任务。测试难度被量化为三个绝对标准：Easy级别（包含3个实体，单实体需3次API调用，共9次调用）、Medium级别（4个实体，共16次调用）、Hard级别（5个实体，单实体5次API调用，共计25次复杂调用）。

底层设施：Skill Mode协议栈与安全验证

为了在测试时赋予模型构建工具组合的能力，系统在智能体的工作区维护了一个本地的 skill_cache.json 文件。智能体被严格限制仅能通过以下四个MCP（Model Context Protocol）原语与其交互：

• save_skill：将成功的工作流保存为可执行的代码宏。必须传入 macro_name（唯一标识符）、script_code（Python脚本代码）、parameters（变量名列表）和 description（摘要说明）。

• execute_skill：运行已保存的技能。需传入 macro_name 和具体的参数字典 args，系统将返回状态标识与执行结果字典。

• list_skills：无参调用，列出当前会话中所有的可用技能，供模型决策前检查。

• get_skill：检索目标技能的完整源代码和参数签名，用于复杂场景下的调试验证。

为了保证智能体生成的代码不会引发系统级灾难，研究者部署了带有三阶段防御机制的代码验证器（Coding Verifier）：

• 语法验证：在 save_skill 写入前，底层进行AST解析，拦截基础语法错误并向模型返回具体的错误行号与代码片段。

• 运行时错误报告：当 execute_skill 崩溃时，沙盒拦截系统异常，向模型返回结构化的Tracebacks与输入参数，协助模型定位参数绑定错误。

• 执行后质量检测：为防止静默失败，系统强校验输出字典。若超过50%的字段内容为Unknown、None或0，该脚本将被直接拒绝入库。

在实验边界上，研究者施加了严苛的约束：每个任务硬性限制最多150个对话轮次，超时时间60分钟；全局最多累积消耗1M输入Token和150K输出Token；模型采样参数被彻底锁死在  和  以保证输出的确定性。在评分端，必须同时满足文件生成、JSON结构有效性、数据完整性与字段级准确性（总分超90%）才计入成功。

核心结论：能用强模型不用弱模型

在了解了上述毫无水分的测试环境后，我们来看实战中大家最关心的问题：为了节约成本，我们应该用便宜的弱模型多次尝试，还是用昂贵的强模型一击必中？数据给出的答案是后者。

Token消耗的指数级坍缩

实验对比了关闭技能库接口的Baseline模式与开启技能库的Skill Mode。数据清晰地显示，在复杂的长周期调用中，强模型通过编写代码实现内部逻辑流转，能够极大地抹平由于自身定价较高带来的成本劣势：

• GPT-5.2：平均Token消耗从1.23M暴降至0.26M（缩减79%），单任务平均API成本从1.77美元直接跳水至0.43美元（节省75%）。

• Claude 4.5 Sonnet：基线成功率已高达96%，在技能模式下维持在94%的高水平。其Token消耗从1.36M降至0.40M（缩减71%），纯粹的底层工具调用次数从14.3次降至9.2次。

• DeepSeek-V3.2-EXP：Token消耗下降49%（从1.04M降至0.53M），成本直接减半。

虽然智能体在查询、验证和缓存技能时会消耗少量的决策轮次（如Gemini 3 Pro的平均交互轮次增加了13%），但由于代码引擎直接接管了巨大的数据清洗与中转工作，规避了向Prompt注入无效负荷，系统整体的Token消耗依然呈现出断崖式下跌。

相关性分析：Coding能力就是Skill能力

研究者通过跨指标相关性分析揭示了系统运行的底层规律。技能执行成功率与任务最终成功率呈现强正相关（），同时效率增益与模型的基线能力呈现正相关（）。

这就解释了开源弱模型在此类架构中的工程死穴：当模型在基线Hard任务上的成功率低于60% 时，其代码生成能力同样羸弱。在封装参数化接口时，弱模型会频繁产出包含语法错误或逻辑死锁的劣质代码，随后系统拦截报错，模型被迫进入无限的“查错-重写”死循环。在这个过程中，为了节省算力而引入的框架，反而会大量燃烧Token用于修复代码。

SkillCraft结论一：在构建基础Skill库时，切忌使用弱模型通过堆砌Agent数量来碰运气。强模型的单体代码生成正确率，在系统总成本上具有绝对的碾压优势。

多Agent跨模型协同：创造者大于执行者

在Openclaw等多智能体协同框架中，架构师通常需要将任务拆解分发。系统中的“主模型”和“边缘模型”应该如何分配职能？论文的跨模型测试数据给出了极其明确的工程指南。

跨难度迁移测试（Cross-task Generalization）

在验证技能泛化性时，研究者进行了严格的静态迁移测试（即在复杂任务中直接使用简单任务跑出的技能代码，期间禁止模型修改代码）。数据证实，高质量的参数化代码具备极强的跨级兼容性：Claude 4.5和Gemini 3 Pro在Easy级别中抽取的技能，无缝平移到Hard级别任务中，均维持了97%-100%的极高执行成功率。Claude的Easy->Hard迁移将成功率从基线的95%拉满至100%，同时Token从1.92M压降至1.56M。

跨模型执行热力图解析

研究者设计了一组极其残酷的16组合交叉测试：让Claude、Gemini、GLM和Minimax在8个Hard级别任务中各自创建技能库，然后将这些纯Python脚本交叉下发给所有模型进行纯执行（禁用修改权限）。

这两张热力图的数据对比极为强烈！尤其是第一张，Claude写的代码在所有模型上执行都是 100%成功率。

• 高质量代码的向下兼容绝对性：Claude创建的代码逻辑严密、类型校验完备。当这些脚本被下发给相对轻量的Minimax、GLM或Gemini执行时，全系跑出了100%的满分通过率，并且为所有的执行端模型带来了54%到81%的Token巨额节省。

• 低质量代码的执行反噬效应：反观由Minimax生成的代码，由于内部状态流转混乱和参数接口设计缺陷，即便是交给Claude执行，也会高频触发底层报错。这导致执行端的重试机制被频繁唤醒，计算成本非但没有下降，反而浮动在增加48%到小幅缩减18%之间，彻底摧毁了框架的提效初衷。

• 执行器算力的局限补偿：数据中一个有趣的细节是，Claude强行执行Gemini生成的瑕疵技能库，实现了69.2%的Token节省；而Gemini执行自己的技能库，仅节省了14.8%。这说明顶尖大模型的意图理解和参数补全能力，能在一定程度上“兜底”中等质量的代码缺陷，但这绝不是常规操作。

SkillCraft结论二：因此在设计Openclaw等端云协同的Multi-Agent系统时，最好遵守“创造者 > 执行者”原则。由云端的顶级千亿参数大模型作为“Skill编译器”，负责在少量复杂样本上抽取、验证并封装出高质量的业务脚本；边缘端或低成本私有化模型仅被授权作为“执行引擎”，负责接收参数并运行缓存脚本。绝对禁止弱模型向公共技能库提交代码。

防坑指南：深层嵌套与抽象的认知税

工程师在设计系统架构时，常常带有将代码模块化、层层调用的“面向对象”执念。论文中的微观测试数据，彻底戳破了当前LLM能力在深度代码结构面前的脆弱性。

Hierarchical Mode（层次化模型）的崩溃机制

研究者引入了允许技能调用其他技能的Iteration Mode（最大嵌套深度设为10）。从理论上看，高层技能负责编排，低层技能负责原子操作，似乎极其完美。

然而真实执行日志（Log Trajectories）展示了令人绝望的错误传播（Error propagation）过程。

在一个生成犬类百科的任务中，底层的数据抓取技能 get_breed_profile 碰到了稀有品种数据，其API原始响应中缺失了 temperament 字段，从而返回了包含null的字典。这个底层隐患向上级传递。

当处于中间层级的聚合技能尝试执行字符串操作 profile.temperament.split(',') 时，沙盒直接抛出致命的 TypeError: 'NoneType' has no attribute 'split'。这一行类型错误瞬间击穿了整个调用树，导致顶层组装任务彻底宕机全盘溃败。

实测数据异常惨烈：切换到嵌套模式后，强如GPT-5.2，任务成功率也从扁平模式的90% 跌落至79%，Token开销也从0.26M反弹劣化至0.60M。原因在于，嵌套架构对LLM的边缘情况处理（Edge-case handling）和动态类型校验提出了其能力上限无法企及的要求。高昂的故障追踪成本远远超过了从头执行一次原子操作。

SkillCraft结论三：在工业环境中构建Agent的工具调用树时，最好摒弃复杂的技能相互调用。保持技能架构的扁平化（Flat），确保单个脚本内部包含完备的try-except错误处理，是保证生产环境稳定性的唯一方案。

泛化的认知算力税与“不抽象”的智慧

面对所有的业务流，是不是全都封装成通用接口一定最高效？答案同样是否定的。泛化本身需要交纳高昂的“认知算力税”。

研究者测试了放弃复用和参数接口、直接在单次使用脚本中硬编码数值的Direct Exec模式。在48个任务子集中，数据对比极为极端：

• Claude 4.5 Sonnet在Direct Exec模式下，将Token消耗从基线的1.72M压榨到了极其夸张的0.16M，对话交互仅需5.8轮；而为了兼顾未来复用的标准Skill模式，由于需要设计通用的参数占位符并执行“先保存、后执行”的完整流程，开销为0.34M Token和10.5轮交互。
• GPT-5.2的表现同样极致，Direct Exec将单任务Token燃烧压缩至0.06M，交互轮次骤降至4.5轮。

通过查阅原始调用轨迹（Trajectories），我们可以清晰看到不同级别模型的工程直觉差异。

 在处理只需针对三种猫获取9次简单数据的轻量级任务时，Claude敏锐地判断出“设计通用接口并缓存代码”的抽象开销远大于直接裸调API的收益。它果断放弃调用 save_skill，直接老老实实地完成了34步原子调用，消耗约76万Token顺利交差。而在处理需要分析五种鸡尾酒、共计25次调用的高复杂度任务时，Claude只用1次尝试就精准写出包含5个数据流转通路的完美宏代码 process_cocktail_complete，随后连续循环调用5次，总计仅用8步交互和极低的21万Token完美收工。

相反，DeepSeek-V3.2在执行中完全被系统提示词绑架，陷入了“指令过拟合”。在简单的猫咪任务中，它强行造轮子生成了一个名为 process_cat_breed 的技能。然而代码质量堪忧，输出字典硬生生遗漏了 breed_facts 字段。这导致执行后产生大面积数据空缺，它随后被迫进入漫长的修复期，手动执行了8次局部追加写入（Chunk write）等抢救操作，最终在简单任务上荒谬地燃烧了逾150万Token。在复杂的鸡尾酒任务中，DeepSeek更是连续三次尝试写入脚本（v1, v2, v3），分别因 unexpected token '}' at line 8 和 'return' is invalid outside function 等基础语法错误宣告流产，最终只能降级回全量手动调用，并在超时和上下文混乱中导致任务失败，消耗1.14M Token且毫无产出。

SkillCraft结论四：最高维度的Agent框架设计，不仅要提供代码执行沙盒，更要赋予大模型“何时不使用框架”的自由度与判断力。懂得识别低频孤立任务并选择硬编码一次性脚本，规避处理参数绑定可能引发的幻觉，是系统极致降本的关键。

结语

《SkillCraft》的详实数据彻底改变了我们评估和设计Agent架构的底层视角。在复杂的企业级业务流中，您需要将视野从单纯追逐基准测试的Accuracy，转向极致的算力成本控制。

Agent真正走向落地的商业护城河，在于其利用代码作为中间媒介实现“计算压缩（Token Compression）”的能力。请记住这些真金白银换来的架构法则：用最强的大模型做代码编译器，用边缘端小模型做执行器；克制代码深度，坚守扁平结构；并在设计框架时，永远留出一条允许模型放弃抽象、直接暴力执行的旁路通道。只有这样，您的智能体系统才能真正兼顾工程健壮性与商业可行性。

未来已来，有缘一起同行！