上周一个关于微软新研究项目“SkillOpt”的讨论在技术圈里传开。核心的疑问点很直接一个最终只有 857 个 token 的“技能”Skill为什么在训练过程中消耗了高达 2.1 亿个 token这个数字对比乍一看像是一个巨大的“浪费”或“低效”的工程事故。但如果你也这么想可能就错过了这项研究真正想传递的信号。它揭示的远不止是训练一个微小的功能模块那么简单。这背后是大型语言模型LLM从“被动应答”走向“主动规划与执行”的 Agent 化进程中一个被长期忽视但至关重要的成本维度技能发现与优化的成本。我们过去谈论微调、谈论提示工程、谈论 Agent 框架往往默认“技能”是已知且确定的。比如我们知道要调用一个计算器 API或者写一段 SQL 查询代码。但 SkillOpt 要解决的是一个更前置、更根本的问题当面对一个复杂、开放的新任务时如何让 LLM 自己“发明”出最高效、最可靠的技能组合这个过程本质上是在为 LLM 构建其“肌肉记忆”和“工具箱”的元能力。857 个 token 是那个精炼后的、可复用的“成品工具”而 2.1 亿个 token则是探索、试错、评估和优化这个工具所支付的“研发成本”。理解这个成本结构对于任何想要将 LLM Agent 投入实际生产尤其是处理非标准化、长流程任务的人来说都是一个必须跨过的认知门槛。1. 从“调用技能”到“发明技能”LLM Agent 的能力跃迁要理解 SkillOpt首先要跳出“微调一个函数”的思维定式。我们得先看看当前主流的 LLM Agent 是如何工作的。1.1 传统 Agent 的“技能库”困境目前大多数 LLM Agent 框架如 LangChain、AutoGPT 的早期思路的工作模式可以概括为预定义技能库开发者事先编写好一系列工具函数Tools/Skills例如search_web,execute_python,query_database。规划与调度LLM 根据用户请求规划步骤并从技能库中选择合适的工具调用。执行与汇总执行工具将结果返回给 LLMLLM 继续规划或生成最终答案。这个模式的瓶颈非常明显Agent 的能力上限被牢牢锁死在开发者预定义的技能库中。如果遇到技能库之外的任务Agent 要么失败要么只能通过冗长的自然语言推理和多次试错来“模拟”该技能效率极低且不可靠。例如让 Agent “分析本季度销售数据找出异常波动并生成归因报告”。如果技能库里没有“数据清洗”、“异常检测算法”、“报告模板生成”这些具体技能Agent 可能只会回复一段文字描述该怎么做而无法真正执行。1.2 SkillOpt 的核心命题动态技能生成SkillOpt 的研究指向了一个更高级的范式让 LLM 在任务执行过程中动态地发现、抽象并固化可复用的技能。它的目标不是教 LLM 用一个固定方式完成一个具体任务而是赋予 LLM 一种“元学习”能力在解决复杂任务时能识别出其中重复、通用的子模式并将这些子模式抽象、压缩成高效、可验证的“技能”一段代码、一个 API 调用模板等。之后再遇到类似子问题直接调用这个技能即可无需重新推理。这就像是一个程序员在手动处理数据时发现某些操作频繁出现于是将其封装成一个函数。SkillOpt 试图让 LLM 自己完成这个“封装函数”的过程。那么关键问题来了LLM 如何知道什么样的代码片段值得被封装为“技能”封装后的技能其正确性和效率如何保证这就是那 2.1 亿 token 消耗的来源。2. 拆解 2.1 亿 Token技能“研发”的成本究竟花在哪857 vs 2.1 亿这个差距主要源于 SkillOpt 采用的“生成-评估-优化”强化学习RL框架具体来说是近端策略优化PPO。我们可以把这个过程类比为一个高科技实验室研发新材料的流程探索与试错消耗大部分 TokenLLM 作为“策略模型”会针对训练任务尝试生成各种各样的代码片段作为候选技能。这需要大量的采样sampling。每次采样模型都会生成一段代码可能有效可能无效并在模拟环境或验证集上运行它得到一个奖励Reward信号。这个“尝试-反馈”的循环是 token 消耗的大头。它不是在训练最终的 857 token 技能而是在训练一个“技能生成器”的审美和判断力。奖励函数计算密集的交互与评估奖励函数是 RL 的灵魂。SkillOpt 需要评估一个候选技能的好坏标准可能包括功能性代码能正确执行吗通用性这个技能能在多少相似场景下复用效率相比用自然语言指令一步步推理直接调用这个技能能节省多少 token或时间简洁性技能本身是否足够精炼 每一次评估都可能需要运行代码、分析结果、计算指标这个过程本身可能就需要调用 LLM 进行验证或对比产生额外的 token 消耗。策略模型迭代优化根据奖励信号使用 PPO 算法更新“技能生成器”模型的参数。这个过程需要大量的前向和反向传播计算对应着海量的 token 处理。目标是通过优化让模型生成的候选技能质量越来越高越来越接近我们最终想要的、那个高效的 857 token 的“成品”。技能蒸馏与固化在漫长的 RL 训练后“技能生成器”具备了产出高效技能的能力。最终我们从其生成的最优技能中选取那个在验证集上表现最好、最通用、最简洁的版本将其“固化”下来。这个被固化的版本就是那 857 个 token 的最终技能。它本质上是整个训练过程产出的“精华”或“最优解”。一个关键认知这 2.1 亿 token 训练出的主要不是那 857 个 token 的技能代码本身那可能只需要几千 token 的微调而是背后那个能够持续产出此类高效技能的“元能力模型”。857 token 的技能只是这个能力的一次杰出展示。下表概括了 token 消耗的主要去向阶段核心活动消耗 Token 的用途类比探索采样LLM 生成大量候选技能代码模型前向传播产生多样化的输出实验室合成成千上万种候选材料评估反馈运行代码计算奖励功能、通用、效率可能调用 LLM 进行结果验证、对比分析对每种材料进行严格的性能测试策略优化使用 PPO 更新模型参数反向传播、梯度计算需要处理大量数据根据测试结果调整合成配方和工艺技能固化选取并保存最优技能相对少量的 token 用于最终技能的编码将性能最优的材料配方登记为专利所以2.1 亿 token 是“研发成本”857 token 是“专利成品”。这个成本结构告诉我们为 LLM Agent 赋予“发明技能”的元能力其初始投入是巨大的。3. 从研究到实践我们如何借鉴 SkillOpt 的思想对于绝大多数团队来说直接复现一个需要 2.1 亿 token 训练的 RL 系统是不现实的。但 SkillOpt 揭示的思想和流程对我们的工程实践有极强的指导意义。我们可以将其降维应用到实际的 LLM 应用开发中。3.1 建立“技能意识”与成本核算首先必须在团队内建立共识Agent 的长期进化依赖于技能的积累而技能的提炼是有成本的。记录“技能发现”过程当发现工程师或 LLM 在反复处理同一类子任务如“从非结构化文本中提取特定格式的日期”、“清洗某种畸形的 JSON”时就应该意识到这是一个潜在的“技能”候选。量化技能价值估算一下如果把这个子任务固化成一个函数或工具每次调用能节省多少提示词token、减少多少 API 调用次数、降低多少出错概率。如果节省的价值大于封装成本就值得做。3.2 设计一个简化的“技能工厂”流程我们可以设计一个轻量级的、人机协作的“技能工厂”识别模式人工主导在 Agent 运行日志或人工评估中发现重复出现的复杂操作模式。生成候选LLM 辅助将操作模式和示例提供给 LLM如 GPT-4、Claude-3提示其“将这个操作流程抽象并编写成一个可复用的 Python 函数/工具描述”。这里可以生成多个版本。评估与测试自动化人工功能测试在多个历史案例上运行该函数验证正确性。通用性测试构造一些边界案例看函数是否健壮。效率评估对比使用新技能和原有自然语言推理方式的 token 消耗和耗时。优化与入库人工确认选择最优版本进行代码优化、添加注释和错误处理然后将其正式加入 Agent 的技能库并更新 Agent 的工具描述文档。这个流程虽然不如 SkillOpt 的 RL 框架自动但核心思想一致发现 - 抽象 - 验证 - 固化。它显著降低了“研发成本”更适合工程落地。3.3 在提示工程中嵌入技能进化即使在简单的提示词中也可以引导 LLM 进行初步的技能抽象。例如在系统提示System Prompt中可以加入“在处理任务时如果你发现自己在反复执行一系列相同的或高度相似的操作步骤请尝试将这些步骤总结为一个清晰的、可复用的子流程描述。在后续遇到同类问题时直接引用这个子流程描述而不是重新推导。”这相当于在推理层面鼓励 LLM 进行“软技能”的抽象虽然不能生成可执行的代码但能提高其内部推理的效率和一致性。4. 技能优化的边界与挑战为什么不能无限压缩看到 857 token 的技能一个很自然的想法是能不能压缩到 500 token100 token技能是不是越小越好并非如此。技能的优化存在明确的边界和权衡盲目追求极致的压缩会走入误区。4.1 技能信息的“最小完备集”一个有效的技能必须包含足够的信息使得任何具备基本能力的 LLM或执行器在调用它时能明确知道输入是什么参数的名称、类型、格式、约束。输出是什么返回值的类型和含义。它做了什么核心逻辑或调用的外部服务。可能出错的情况关键的异常处理或边界条件至少要在文档或注释中说明。857 个 token 很可能就是当前任务下满足“最小完备性”的一个平衡点。再减少可能会损失清晰度、健壮性或必要的上下文。4.2 通用性与特异性的权衡技能越通用其内部逻辑可能越复杂需要处理更多分支情况或者越抽象需要调用者提供更多上下文。技能越特异则越高效简洁但适用范围越窄。SkillOpt 训练中的奖励函数一定包含了“通用性”和“效率”的权衡。最终的 857 token 技能是在其设定的任务分布上找到的一个帕累托最优点——在保证足够通用性的前提下尽可能提升效率。4.3 技能的可维护性与演化技能不是一成不变的。随着任务需求的变化技能可能需要迭代。一个被过度压缩、像“黑盒”一样的技能会变得难以理解和修改。因此在优化时保留一定的可读性和模块化结构至关重要即使这会略微增加 token 数量。工程建议在封装技能时采用标准的文档字符串Docstring格式明确说明功能、参数、返回值和示例。这增加的 token 对于长期的维护成本来说是值得的。4.4 技能间的依赖与组合复杂的任务往往需要多个技能组合完成。技能之间可能存在依赖关系。优化单个技能时需要考虑它作为“乐高积木”与其他技能拼接的接口是否清晰、稳定。一个被孤立优化的技能可能在组合时产生意想不到的冲突。5. 给开发者的行动路线图从今天开始构建你的技能体系基于对 SkillOpt 的解读我们可以为自己正在开发的 LLM 应用制定一个循序渐进的技能进化策略。5.1 阶段一手动定义与积累当前即可开始行动梳理你的应用场景中最常见、最稳定的操作将其手动实现为工具函数。重点确保工具接口设计良好输入/输出明确、错误处理完善并编写清晰的描述以便 LLM 理解和使用。目标建立一个可靠的“基础技能库”。这是所有高级能力的地基。5.2 阶段二日志分析与模式发现需要基础设施行动为你的 Agent 系统增加详细的运行日志记录每一次用户请求、LLM 的完整思考链Chain-of-Thought、工具调用及结果。分析定期分析日志寻找频繁出现的复杂自然语言推理模式。重复执行的、可通过代码自动化的操作序列。LLM 容易出错的固定环节。目标从真实数据中发现潜在的技能优化点为下一阶段提供候选清单。5.3 阶段三人机协作的技能提炼引入 LLM 辅助行动针对阶段二发现的候选模式构建一个简单的流程将示例输入/输出对和操作描述整理成提示词。调用高级 LLM如 GPT-4要求其生成该技能的代码实现和描述。人工审核、测试并优化生成的代码。将新技能加入库并更新 Agent 的系统提示。目标以较低成本实现技能的半自动化扩充和优化显著提升开发效率。5.4 阶段四向自动化技能优化演进远期展望行动当技能库和任务日志积累到足够规模时可以考虑借鉴 SkillOpt 的思想构建一个内部的、小规模的技能优化循环。例如利用离线任务日志和奖励信号如执行成功率、耗时对技能生成或选择模型进行微调。目标让系统具备有限的自我优化能力能够针对特定的任务流自动发现并固化更高效的技能组合。SkillOpt 那 2.1 亿 token 的训练成本像是一个醒目的路标它指向了 LLM Agent 能力进化的深水区。它告诉我们让 AI 不仅会使用工具更会创造工具需要付出巨大的探索代价。但对于我们而言重要的不是被这个数字吓退而是理解其背后的逻辑——将一次性的、昂贵的探索成本转化为可复用的、高效的技能资产。真正的价值不在于那 857 个 token而在于我们是否能在自己的项目中建立起这种“发现-抽象-固化”的思维和流程。从今天起审视你的 Agent 日志寻找那些隐藏的、重复的“体力活”尝试将其封装成第一个新技能。当你积累的技能库开始让 Agent 的处理速度更快、成本更低、效果更稳时你就已经走在了这条进化的道路上。