从 ContinualSkillBench 看 LLM Agent 的能力进化为什么“技能沉淀”比“上下文长度”更决定智能体上限如果你正在做 LLM Agent 相关的开发一定遇到过这样一个场景昨天你花了一下午让智能体学会了从接口文档中自动抽取参数、组装请求、校验响应运行效果非常理想。今天换了一批新接口你期待它能“举一反三”结果它又像第一次见面一样开始问你基础问题甚至重复犯昨天已经犯过的错误。这不是模型不够聪明而是你的 Agent 没有“能力沉淀”的机制。绝大多数 LLM Agent 仍然是一个“无状态执行器”每次任务都从零开始模型权重不变对话上下文清空之后上一个任务积累的经验、拆解思路、工具调用模式全部归零。你教过它的东西它没有真正“学会”只是在上一轮对话里暂时“记住了”。这正是 ContinualSkillBench 这篇工作真正戳中的问题LLM Agent 真的能进化自己的能力吗还是说它只是在上下文窗口里临时拼凑答案本文从论文视角、核心概念、评估思路和工程实践四个层面展开并给出一个可以立刻上手的“技能记忆层”最小实现帮助你理解技能持续学习应该怎么做。1. 为什么“能力不进化”是 LLM Agent 最被低估的瓶颈先说一个判断当前 LLM Agent 的瓶颈已经从“单次任务能不能做对”转移到了“多次任务能不能越用越好”。早期大家关注 Agent 时讨论最多的是“要不要用 ReAct”“工具调用返回格式怎么解析”“长上下文怎么管理”。这些问题本质上是单次任务内的工程问题给定一个用户请求链路能不能跑通结果能不能稳定。但随着 Agent 从 Demo 走向真实业务一个新的问题浮出水面Agent 在重复出现相似任务时能不能复用上一次的经验举一个真实场景。假设你在做一个“智能运维助手”它需要读取监控指标、定位异常、执行排查命令。第一轮任务里你给它配置了完整的监控系统文档它学会了看某个指标的趋势图第二轮任务监控指标变了但它依然要你重新提供文档甚至会把上一轮学到的告警阈值误用到新系统上。问题出在哪里因为 Agent 的能力都“活在上下文里”。上下文窗口是临时记忆不是长期能力。模型权重是固定的上下文是易失的。只要你清空对话、切换会话、或者上下文被截断之前沉淀下来的技能就消失了。更重要的是这种“无状态”模式会带来三个连锁问题经验无法复用同类任务每次都需要重新解释和引导成本线性增长。错误会重复上一次犯错后你纠正了它下一次它大概率还会犯同样的错误。无法形成复杂度跃迁单任务的执行上限由模型本身决定Agent 无法通过积累把“会做一件事”变成“能做一类事”。如果你想构建一个真正长期运行的 Agent 系统单次准确率只是起点技能持续积累能力才是决定智能体天花板的关键变量。ContinualSkillBench 的核心价值正是把这个问题从“工程感言”推到了“可评测、可对比”的位置。2. ContinualSkillBench 到底在评测什么从“一次性正确”到“持续进化”由于论文原文尚未提供完整的实验细节这里我基于标题“Can LLM Agents Truly Evolve Their Capabilities?”和持续学习领域的主流研究思路做解读。2.1 “技能Skill”在这里指什么在 LLM Agent 语境下技能不是传统软件工程里的函数或接口而是**“能够反复被调用的任务解决模式”**。它可以表现为一段经过验证的 Prompt 模板一个工具调用的步骤序列一个从数据中抽取规则的方法一个处理异常分支的决策逻辑。技能的关键特征是“可复用”。如果每次都要重新推理一遍“怎么调用这个 API”那不是技能如果形成了“看到这类 API 先取鉴权 token再按字段映射关系组装请求体”的固定流程这才是技能。2.2 持续进化Evolve Capabilities包含哪几个层次从论文标题推测ContinualSkillBench 中的“进化”至少包含四个层次层次含义核心问题技能获取Agent 能否从新任务中提炼出可复用的技能任务做完了经验能不能留下来技能迁移已经学会的技能能否用于新任务有点相似的任务能不能少教一遍技能重组已有技能能否组合成更复杂的解决流程单点技能会不会变成组合能力抗遗忘学习新技能时旧技能会不会退化学了新的会不会忘了旧的这四个层次对应持续学习Continual Learning里经典的能力与稳定性权衡Stability-Plasticity Dilemma。太偏向稳定性Agent 会固守旧技能学不进新东西太偏向可塑性Agent 学习新技能时会覆盖旧技能出现灾难性遗忘Catastrophic Forgetting。ContinualSkillBench 的真正看点是它把评测焦点从“单任务成功率”转移到了“能力随任务序列的变化曲线”连续做 10 个相关任务第一个任务正确率 80%第二个 85%到第五个能不能到 90%还是说一直在 60% 到 80% 之间震荡这个曲线才真正反映一个 Agent 是否具备进化能力。2.3 与普通 Benchmark 的关键差别传统评测比如通用的多任务 benchmark关注的是“平均分”十个任务各测一遍算平均正确率。ContinualSkillBench 这类持续学习评测关注的是“变化轨迹”按顺序给智能体派发任务观察它在第 N 个任务上的表现是否受益于前 N-1 个任务的经验。这就像考试和工作的区别。考试考的是“你当前会不会”工作要看“你能不能越干越熟练”。一个 Agent 可以在一次评测中拿到高分也可能在连续任务中毫无进步。前者评测的是模型能力后者评测的是智能体的学习机制。从工程角度看这种评测思路更接近真实业务没有哪个生产系统会只会处理一种任务任务总是源源不断、形状相似又各有差异地出现。3. 为什么通用评测解决不了“持续进化”问题把话题稍微拉远一点。2023 年以来LLM Agent 领域的评测体系层出不穷但大多数评测都存在同一个盲区它们把 Agent 当作“一次性回答器”来测。这类评测的基本流程是准备一批任务样本每个任务给 Agent 一段全新的上下文看 Agent 能不能完成计算平均正确率。这种流程能测出什么它能测出模型本身的推理能力、指令遵循能力、工具调用能力。但它测不出Agent 系统在多次交互中是否积累了能力。原因很简单每个任务都是独立样本智能体没有机会把上一个任务的经验带到下一个任务。评测设计上就把“学习过程”删掉了。ContinualSkillBench 这类评测的贡献在于它把“任务序列”和“技能持续沉淀”这两个变量加了回来。你不再问“这 100 个任务里对了多少个”而是问第 1 个任务的经验有没有让第 11 个任务做得更好第 50 个任务做完后第 2 个任务的能力还在不在如果任务类型发生变化旧技能会不会拖累新任务这才触及了 LLM Agent 从“工具”走向“助手”的核心一个值得长期使用的助手必须能记得你教过它的事情并把它们变成可迁移的能力。4. 一个可以立刻动手的迷你实验为 Agent 添加技能记忆层理解了 ContinualSkillBench 的评测思路我们可以回到工程侧。先不讨论复杂的持续学习算法用一个最小系统演示“技能沉淀”的核心机制。这套迷你系统包含三层技能注册层任务成功后将解决流程提炼为结构化技能技能检索层新任务到来时从技能库中检索最相关的历史技能技能执行层将检索到的技能注入 Prompt辅助 Agent 完成新任务。4.1 技能定义与存储格式技能本质上是一份结构化文档。这里用 JSON 存储包含任务类型、触发条件、执行步骤、示例输入输出等字段。{ skill_id: skill_rest_api_invoke, name: REST API 调用技能, description: 适用于通过 REST 接口获取数据的任务包含鉴权、请求封装和错误处理, trigger_conditions: 任务包含 HTTP 请求、API 调用、获取接口数据等关键词, steps: [ 从配置中读取 API Base URL, 使用 API Key 生成鉴权头, 构造请求参数映射, 发起请求并检查 HTTP 状态码, 解析响应并提取 target_field, 失败时重试一次并记录错误原因 ], examples: { input: 获取用户 ID 为 1001 的订单列表, output: 调用 GET /users/1001/orders返回订单数组 }, tags: [api, rest, http] }为什么技能信息要包含description和trigger_conditions因为检索阶段主要依赖这两项。真实的技能库还可能包含更丰富的字段比如前置条件、依赖工具、版本约束、质量评分、被调用次数等这些在工程化落地时非常重要。4.2 技能检索用向量相似度召回技能库维护好之后新任务到来时要做“技能匹配”。简单方案是计算任务文本与技能描述、触发条件的向量相似度。# 文件路径skill_memory.py # 依赖pip install sentence-transformers numpy import json import numpy as np from sentence_transformers import SentenceTransformer # 加载模型。生产环境建议使用本地部署的 embedding 服务 encoder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) def load_skills(skill_store_path: str): with open(skill_store_path, r, encodingutf-8) as f: return json.load(f) def retrieve_skills(task_input: str, skills: list, top_k: int 3): task_vec encoder.encode(task_input) scored_skills [] for skill in skills: candidate_text f{skill[description]} 触发条件{skill[trigger_conditions]} skill_vec encoder.encode(candidate_text) score float(np.dot(task_vec, skill_vec) / ( np.linalg.norm(task_vec) * np.linalg.norm(skill_vec) )) scored_skills.append((score, skill)) scored_skills.sort(keylambda x: x[0], reverseTrue) return [skill for _, skill in scored_skills[:top_k]]代码说明每次对任务和技能分别编码会损失部分性能实际项目会预计算并缓存技能向量这里只演示核心逻辑。检索到技能后接下来是把技能内容注入 Prompt。4.3 Agent 调用循环让技能真正影响行为这一步是整个链路的“最后一公里”。很多技能库项目会在这里出问题技能检索出来了但 Prompt 拼接方式不对或者模型没有真正“使用”技能结果技能形同虚设。一个有效的注入方式是在系统提示词末尾追加“可用技能”区块并要求模型按步骤执行。# 文件路径agent_with_skill.py import json from skill_memory import load_skills, retrieve_skills def build_prompt_with_skills(task_input: str, skills: list): skill_text_block [] for idx, skill in enumerate(skills, 1): steps \n.join(f Step {i}: {step} for i, step in enumerate(skill[steps], 1)) skill_text_block.append( f技能{idx}{skill[name]}\n f适用条件{skill[trigger_conditions]}\n f执行步骤\n{steps}\n f示例{json.dumps(skill[examples], ensure_asciiFalse)}\n ) skill_section \n.join(skill_text_block) system_prompt f 你是具备持续学习能力的智能体。你会获得历史技能库中的相关技能参考。 当任务与技能描述匹配时请严格参考技能步骤执行如果技能不适用请说明原因并尝试常规推理。 ## 可用技能 {skill_section} ## 当前任务 {task_input} 请遵循以下要求 1. 优先使用可用技能中的步骤 2. 如果技能缺少信息补充合理推理 3. 最终输出结果。 return system_prompt def run_agent(task_input: str, skill_store_path: str skill_store.json): skills load_skills(skill_store_path) related_skills retrieve_skills(task_input, skills, top_k2) prompt build_prompt_with_skills(task_input, related_skills) # 这里是伪代码示意接入 LLM SDK 时请使用自己的配置 # response llm_client.chat(messages[{role: system, content: prompt}]) print( 注入技能后的 Prompt ) print(prompt) print( Prompt 输出完毕 ) return prompt if __name__ __main__: run_agent(帮我获取用户 1001 的订单列表)注意上面这段代码没有真正调用大模型接口只是演示了“技能检索 → 技能注入 → 任务执行”的链路骨架。接入真实模型时只需把注释部分的 LLM 调用补上即可。4.4 技能注册任务成功后的经验沉淀技能从哪来有两种方式人工编写或者任务完成后自动提炼。自动提炼是更接近 ContinualSkillBench 研究目标的做法让 Agent 在执行任务后把经验浓缩成技能。一个基本的技能注册函数可以这样设计# 文件路径skill_register.py import json import uuid from datetime import datetime def register_skill(task_input: str, execution_trace: str, result_summary: str, name: str, tag: str general, skill_store_path: str skill_store.json): # execution_trace 是 Agent 完成任务后回填的执行步骤摘要 skill { skill_id: fskill_{uuid.uuid4().hex[:8]}, name: name, description: result_summary[:200], trigger_conditions: task_input[:100], steps: [line.strip() for line in execution_trace.strip().splitlines() if line.strip()], examples: { input: task_input[:200], output: result_summary[:200] }, tags: [tag], created_at: datetime.now().isoformat() } try: with open(skill_store_path, r, encodingutf-8) as f: skills json.load(f) except FileNotFoundError: skills [] # 简单去重策略任务描述相似度过高则跳过注册 for old in skills: if old[trigger_conditions] skill[trigger_conditions]: print(相似技能已存在跳过注册) return skills.append(skill) with open(skill_store_path, w, encodingutf-8) as f: json.dump(skills, f, ensure_asciiFalse, indent2) print(f技能已注册{skill[skill_id]})这个注册逻辑在生产环境还很粗糙真实系统里需要更多判断什么任务值得沉淀技能技能之间冲突怎么处理自动生成的步骤可信度如何验证但哪怕只有这样一个雏形它已经能支撑一条“任务执行 → 经验提炼 → 技能存储 → 后续任务复用”的完整链路而这正是能力进化的最小工程闭环。5. 工程实践中的常见误区与排查思路持续学习 Agent 的工程实现有不少坑下面按问题现象、可能原因、排查方向和解决方案整理。问题现象可能原因排查方式解决方案技能库越来越大检索准确率反而下降技能之间描述高度相似向量检索区分度不足打印检索结果的相似度分数看 Top 结果是否有冗余增加技能去重机制用标题步骤摘要替代全文编码定期合并相似技能Agent 拿到技能但不执行Prompt 中技能区块位置太靠后或被模型忽略查看完整 Prompt确认技能是否在指令区域前部在系统提示词中明确“必须按技能步骤执行”把技能放在用户任务描述之前新任务正确旧任务开始变差技能注册策略过宽新技能污染了老场景建立任务回归集记录每个技能被哪些任务命中设置技能版本和生效范围新技能先灰度后全量自动提炼的技能步骤有幻觉成分让 Agent 自己总结执行轨迹可能编造未执行的步骤核对 execution_trace 是否来自真实工具调用日志用结构化日志替代自然语言总结只记录真实发生过的工具调用序列技能库冷启动困难初始技能为空无法支撑新任务人工录入 20 到 50 条种子技能覆盖高频任务先跑半个月人工沉淀期再放开自动注册技能互相冲突不同技能对同一场景给出相反建议检索结果中增加冲突检测信号引入技能优先级和适用条件排除逻辑这里特别强调一个高发问题很多人把技能库当成 RAG 知识库来做。RAG 解决的是“检索相关资料供模型参考”技能库解决的是“检索可复用操作流程供模型执行”。两者不冲突但也不能混为一谈。知识库回答的是“是什么”技能库回答的是“怎么做”。如果技能库里存的全是业务文档没有可操作的步骤序列Agent 还是无法形成能力进化。6. 从评测到工程落地持续学习 Agent 的最佳实践ContinualSkillBench 代表的是“评测视角”。如果它证明了某个 Agent 设计具备持续学习能力工程师真正要做的是在生产环境中复现这种能力。下面几条实践经验来自持续学习系统和 Agent 工程交叉领域具有通用性。6.1 先定义“技能”的标准格式技能格式不统一是持续学习第一大工程障碍。Agent 从任务 A 中沉淀的技能是 JSON 格式从任务 B 中沉淀的是自然语言步骤后续检索和执行都会出问题。建议在团队内定义一套技能 Schema至少包含唯一标识名称与描述触发条件执行步骤结构化输入输出示例依赖的工具或资源质量评分版本号。这套 Schema 应当由平台团队统一制定而不是每个 Agent 各写各的。6.2 技能评估闭环注册不代表有效自动技能注册最大的风险是“无效技能进库”。一个技能看起来结构完整执行时却可能错误百出。建议建立三层过滤线上验证技能注册前用历史任务回归一次看成功率是否提升人工抽检每周抽检一定比例的自动注册技能确认步骤可理解、可执行淘汰机制技能被检索到但多次执行失败自动降低权重或移入回收站。没有评估闭环的技能库最终会变成垃圾场。这与 ContinualSkillBench 的出发点完全一致能力是否进化必须用后续任务的完成质量来验证而不是看技能库里存了多少条记录。6.3 区分会话记忆、长期记忆与技能记忆很多 Agent 系统会把三种记忆混在一起会话记忆当前任务的上下文用完即毁长期记忆用户偏好、事实性信息跨会话保留技能记忆操作流程和执行模式可迁移到相似任务。三者的存储方式、更新频率和检索策略都不同。把用户偏好存进技能库或者把操作流程存进向量记忆库都会造成混乱。ContinualSkillBench 所评测的“技能”偏向第三种。6.4 安全边界技能执行必须可控持续学习意味着 Agent 会不断积累新的操作流程这带来一个容易被忽视的问题技能的权力边界会随着积累而扩大。一个只被授权读取日志的 Agent如果学会了执行写操作又恰好被检索到了相关技能就可能越权。建议每个技能声明最小权限域技能调用前校验权限高风险技能默认禁用需人工审批启用记录技能的来源和调用链便于审计。6.5 循序渐进地落地如果团队刚接触这个方向不要一次性做完整的持续学习系统。分阶段推进更稳妥。第一阶段人工技能库 检索注入。先人工整理高频任务的解决方案做成技能格式Agent 执行时自动检索和注入。第二阶段自动注册 人工审核。为 Agent 增加完成任务后的技能提炼能力但全部走人工审核后入库存.第三阶段自动评估 自动淘汰。接入回归任务集让技能库自动优化。第一阶段通常会带来最明显的效果提升因为高频任务的经验被显式复用了。后续阶段的收益更平缓但因为解决了自动化和更新问题长期价值更高。7. 从“单次任务正确”到“持续进化”Agent 评测的下一个分水岭回到题目本身LLM Agent 能否真正进化自己的能力从模型层面看当前的大模型在推理时并不会改变自身权重每次调用本质上都是同一套参数的不同输入输出。所以“进化”一定发生在模型之外的系统层通过技能库、记忆、工具配置和外部环境反馈让 Agent 的行为模式随着任务序列不断优化。这正是 ContinualSkillBench 这类评测的关键价值。它把“智能体是否具备持续学习能力”从一句口号变成了一个可以量化对比的指标。虽然论文细节还待公布但评测方向本身已经足够值得我们重视Agent 好不好不仅要看它第一次做得怎么样还要看它第十次能不能比第一次做得更好。对于正在做 Agent 工程化的团队建议从今天开始做一件事为你当前的高频任务建立技能模板并用“连续任务成功率”替代“单任务成功率”作为系统指标。这不只是评测方式的改变更是对 Agent 系统定位的升级——它不再是一个一次性工具而是一个可以随着使用越来越懂你的数字同事。值得继续深入的方向包括技能之间的冲突检测与自动合并技能注册的信用评分机制基于强化学习的技能选择策略技能库与多 Agent 协作体系的结合评测任务序列的设计方法与任务难度的曲线控制。这些方向无论哪一个做深都会离“LLM Agent 真正进化能力”这一目标更近一步。如果你正在构建长期运行的 Agent 系统建议先把技能记忆层从概念落实到代码。哪怕只是用一个 JSON 文件记录几十条技能、写一个向量检索函数、在 Prompt 里加一段技能引用区块你也会很快看到行为质量的变化。能力进化不是模型的事而是系统的事。