最近几个月围绕 LLM Agent 的讨论明显从“能不能跑通单任务”转向了“能不能持续变强”。今天要聊的这个项目ContinualSkillBench正是冲着这个问题来的LLM Agent 是真的在持续演进自己的能力还是只是在新任务上临时表现好、回头就把旧技能忘光了这个基准把“持续学习”从概念讨论变成了可量化、可对比的评测协议对于做 Agent 应用选型、模型能力评测、以及研究持续学习的人来说都值得认真看一遍。这个项目的核心价值可以概括成三点第一它把 Agent 评测从单任务静态测试扩展到了连续任务序列第二它显式量化了灾难性遗忘和技能迁移而不只是看平均准确率第三它提供了一套统一的评测脚本和结果记录方式方便做多模型横向对比。更重要的是这类基准项目本身不需要太高的硬件门槛因为评测框架只负责调度任务和调用模型真正吃显存的是被测 LLM 本身。这篇文章会带你走一遍完整流程先理解 ContinualSkillBench 的评测设计与指标含义再讲环境准备和项目启动方式然后演示单个任务、双任务序列、多模型对照的测试方法接着说明 API 调用与批量评测思路最后给出常见问题排查和工程化使用建议。如果你正在做 Agent 能力评估、要考虑模型选型或者想研究 LLM 的持续学习表现这篇可以直接收藏。1. ContinualSkillBench 核心能力速览在动手跑项目之前先把关键信息放在前面。以下参数需要以项目仓库和实际运行环境为准我按常见部署方式给出一份参考能力项说明项目类型LLM Agents 持续学习能力评估基准Benchmark研究问题Agent 能否在连续任务中学到新技能、保留旧技能、并实现跨任务迁移主要功能连续任务序列评测、技能遗忘量化、前向/后向迁移分析、多模型结果对照任务数据多个子任务组成任务序列每个任务带有示例、测试集和评估脚本评测方式自动化脚本逐个执行任务记录成功率和技能保持情况运行平台支持 Linux / macOS / Windows主要依赖 Python硬件要求纯评测框架 CPU 可运行调用本地 LLM 时需要 GPU显存按模型版本而定接口支持评测框架可通过 OpenAI 兼容 API 路由到不同模型服务批量能力按任务序列批量执行支持多模型、多轮重复评测适合场景模型选型对比、Agent 能力诊断、持续学习研究、技能库设计验证从这张表能看出来这个项目更像是一个评测基础设施而不是开箱即用的 Agent 应用。你要自己提供被测模型可以是云端 API也可以是本地部署的模型服务。评测框架帮你把任务串起来最后输出结构化的结果便于横向比较。2. 这个基准在回答什么问题现在主流的 Agent 评测方式一般是一次性给模型一个任务然后看它能不能完成。这种方式能反映“单点能力”但有一个明显的盲区** Agent 在连续面对多个任务时能力是叠加的、还是互相干扰的** 现实中的 Agent 应用往往不是只处理一个用户请求而是要在长时间内不断接收新任务比如一个客服 Agent今天处理退货流程明天新增了发票开具功能后天又接入优惠券核销。一个代码助手 Agent先学会项目结构理解再学习接口文档生成接着又要处理测试用例生成。一个数据分析 Agent先会查数据库再学会做图表然后要能写分析报告。如果 Agent 只学新任务、忘了旧任务那长期使用中就会出现“昨天会的今天不会了”的情况。ContinualSkillBench 要量化的就是这种能力曲线随着任务序列不断推进Agent 在新任务上的表现如何对旧任务的保持程度又如何。这个方向之所以值得关注是因为它把“持续学习”和“灾难性遗忘”这两个经典机器学习问题搬到了 LLM Agent 的场景下重新定义。传统持续学习研究的是神经网络在数据流上的权重更新而 LLM Agent 场景下“更新能力”的方式更加多样可以是上下文指令、可以是 few-shot 示例、可以是微调权重、也可以是外部记忆和工具注册。ContinualSkillBench 通过统一的任务序列和评估协议让不同能力的 Agent 能在同一个标尺下比较而不是各说各话。简单说这个基准不是又一个“刷分榜单”而是想回答一个更底层的工程问题如果让 Agent 在一连串任务里持续工作它的能力是越滚越强还是学到后来把前面都丢了3. 数据集与任务序列设计思路这类 Benchmark 的核心设计集中在“任务序列”上而不是单个任务本身。ContinualSkillBench 在任务组织上通常会包含以下几个层次。3.1 任务单元每个任务单元是一个可独立评估的完整任务带有明确的输入、预期输出和验证方式。从常见设计看任务类型可能包括API 工具调用给定用户意图Agent 需要构造正确的 API 请求参数。信息抽取与整理从给定文档中抽取结构化信息。多轮对话在连续多轮中维持上下文并完成目标。代码生成与修复根据需求生成代码或修复带 bug 的代码。结构化输出按 JSON Schema 输出结果供下游系统消费。每个任务都会提供少量示例few-shot demonstrations作为 Agent 学习该任务技能的“数据”。这里的示例数量通常很少目的是模拟真实场景中“给一两个例子就能上手”的效果而不是大规模微调。3.2 任务序列多个任务按一定顺序组成序列。比如任务序列 S1: [任务A - API调用] - [任务B - 信息抽取] - [任务C - 多轮对话]序列设计要能回答几个问题Agent 在完成 A 后进入 B 时A 的技能还能不能保留B 的学习会不会干扰 A 的表现C 出现时能否借助 A 和 B 中已经形成的“工具使用”经验更快上手为了控制变量同一个任务在序列中的位置可以轮换比如 A 在前、B 在后以及 B 在前、A 在后分别评测就能看出顺序对技能保持的影响。这类实验设计在论文中通常叫“任务排序敏感性分析”实际使用时也可以按这个思路做小规模验证。3.3 评测协议评测协议定义了如何执行任务、如何判断结果。比较合理的流程是给 Agent 提供当前任务的说明和示例。Agent 执行任务生成输出。用规则或模型做自动评估判断输出是否正确。记录结果进入下一个任务。在后续的某个位置重新测试前面已经学过的任务检查是否有遗忘。评测协议是否标准直接决定了实验结果的可信度。运行这个基准时要特别注意任务说明和示例提示词是否固定如果不同轮次使用了不同的提示词结果就很难横向比较。4. 评测指标怎么看懂实验输出ContinualSkillBench 这类项目最值得学的部分就是它如何量化“持续学习能力”。如果只看每个任务的平均成功率会掩盖遗忘和迁移问题。更合理的评估体系应该包含以下几个指标。4.1 任务成功率Task Success Rate单个任务独立评估时的完成比例是最基础的指标。它反映 Agent 在“单独面对这个任务”时的能力上限。4.2 遗忘率Forgetting Rate这是持续学习评测的核心指标。计算方式是Agent 在完成新任务后重新测试旧任务看旧任务的成绩相比刚学会时下降了多少。遗忘率 旧任务初始成功率 - 新任务阶段再次测试的旧任务成功率遗忘率越高说明 Agent 学了新技能后对旧技能的保持越差。这个指标对实际工程选型非常有意义因为它直接告诉你这个模型适不适合“长期服役”在一个多任务环境里。4.3 前向迁移Forward Transfer前向迁移衡量的是Agent 在完成前面几个任务后学习新任务的速度是否变快或者最终表现是否更好。比如任务 C 单独第一次跑可能是 40% 成功率但在完成 A、B 之后再来跑 C成功率到了 60%说明 A、B 带来的经验对 C 有正向帮助。4.4 后向迁移Backward Transfer后向迁移衡量的是新任务的学习对旧任务的影响。如果学完任务 C 之后任务 A 的成功率反而提升了说明存在正向后向迁移如果下降了就是负向迁移也就是遗忘的一种表现。4.5 综合能力曲线把任务序列按顺序展开横轴是任务推进纵轴是已完成任务的平均成功率就能画出一条能力曲线。理想的“真正进化”曲线应该是整体走高或者至少保持平稳如果曲线明显下滑说明 Agent 的“学习”实际上是“覆盖”。这五个维度合在一起才能回答标题里那个问题Agent 是不是真的在进化还是只是在新任务上做短期适应。5. 环境准备与项目运行现在进入实际操作部分。这类评估基准项目通常以 Python 仓库形式发布运行流程总体是拉取代码、安装依赖、配置模型、启动评测、读取结果。5.1 基础环境检查无论评测框架本身多轻量你终究需要一个被测 LLM。所以在准备环境时先把下面几项检查完检查项说明操作系统Windows / Linux / macOS 均可建议 Linux 服务器跑长序列任务Python 版本建议 3.10 或以上具体以项目 requirements 为准被测模型可以是云端 API也可以是本地模型本地模型需要 GPUGPU 显存取决于模型量化版本7B 模型通常需要 8G 以上显存13B 以上建议 16G 起磁盘空间代码仓库不大但本地模型权重可能占用数十 GB网络环境调用云端 API 时需要正常网络访问5.2 拉取项目并安装依赖# 克隆项目仓库仓库地址以项目主页为准 git clone https://github.com/your-repo/ContinualSkillBench.git cd ContinualSkillBench # 创建 Python 虚拟环境避免污染系统环境 python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate # 安装依赖 pip install -r requirements.txt如果安装依赖时遇到网络问题可以考虑使用国内 PyPI 镜像pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple5.3 配置被测模型评测框架通常通过环境变量或配置文件来指定模型服务地址。最常见的方式是 OpenAI 兼容接口这样既能接 OpenAI API也能接本地部署的 vLLM、Ollama、Xinference 等服务。以环境变量方式为例export OPENAI_API_BASEhttps://api.openai.com/v1 export OPENAI_API_KEYyour-api-key export LLM_MODEL_NAMEgpt-4o-mini如果是本地 vLLM 服务export OPENAI_API_BASEhttp://127.0.0.1:8000/v1 export OPENAI_API_KEYlocal export LLM_MODEL_NAMEQwen/Qwen2.5-7B-Instruct这段时间接国产模型的开发者越来越多如果你的评测场景在境内网络环境下运行可以考虑使用支持 OpenAI 兼容协议的国产模型服务或本地推理框架部署路径更可控。5.4 运行评测脚本评测脚本的入口一般是一个 Python 或 shell 脚本用于执行指定任务序列并打印结果。假设项目提供的入口是run_evaluation.py一个通用运行方式如下python run_evaluation.py \ --config configs/default_task_sequence.yaml \ --output_dir ./results \ --save_every_step这里的configs/default_task_sequence.yaml是任务序列配置文件包含参与评测的任务、顺序、示例数量和模型参数。输出目录./results会保存每一轮任务的原始输出和评分结果。如果你用的配置格式不同则需要参考项目 README 修改参数名。但整体思路是一致的先确认任务序列配置再启动评测最后在输出目录里看结果。6. 功能测试与效果验证拿到项目后建议不要直接跑满整个任务序列而是按下面这个顺序做验证逐步确认环境没问题、评测逻辑正确、结果可复现。6.1 单任务冒烟测试先挑一个最简单的任务单独运行一次。目的不是测量性能而是确认模型 API 连接正常。提示词能正确传给模型。模型输出能被评测脚本解析。评测脚本能正确判断结果。python run_evaluation.py --task task_a --config configs/smoke_test.yaml这一步跑通后再进入任务序列评测。如果单任务都跑不通先检查 API 地址、密钥、模型名不要急着上完整序列。6.2 双任务序列测试双任务序列是性价比最高的验证实验。选择两个任务 A 和 B先学 A再学 B然后回到 A 重新测试就能同时看到遗忘率信号和迁移信号。预期输出结构类似{ task_order: [task_a, task_b], task_a_success_initial: 0.85, task_b_success_after_a: 0.72, task_a_success_after_b: 0.63, forgetting_task_a: 0.22 }这里forgetting_task_a 0.85 - 0.63 0.22说明 Agent 在学习任务 B 之后对任务 A 的能力下降了 22 个百分点。这个数字直接反映了模型的灾难性遗忘程度是做模型对比时最核心的参考指标之一。判断标准如果遗忘率接近 0说明模型对旧技能保持良好。如果遗忘率很高说明模型可能过于偏向“最近见过的东西”。如果任务 B 学完后任务 A 的成绩比 0.85 还高说明存在正向后向迁移这是一个非常积极的信号。6.3 三任务序列与迁移测试三任务序列可以更细地观察前向迁移。假设任务顺序是 A - B - C重点看B 的表现是否因为 A 的经验而有提升。C 是否能够复用 A、B 中已经形成的工具调用模式。学完 C 之后A 和 B 的保持情况。建议对同一个序列跑 3 遍取平均值。LLM 输出存在随机性单次结果有波动属于正常现象多次重复取平均可以减少噪声对结论的影响。6.4 多模型横向对比当单模型验证通过后就可以开始对比不同模型。把同样的任务序列和评测协议分别跑在不同模型上整理成表格模型初始任务A成功率学完B后A成功率遗忘率新任务C成功率模型-10.850.630.220.71模型-20.820.790.030.68模型-30.780.650.130.75从这张对比表里可以直观看出某些模型可能在单任务成绩上很接近但在遗忘率上的差异非常明显。如果你的应用需要 Agent 长期处理多种任务模型的选择逻辑就不应该只看“平均分最高”还要看“分数是否稳定保持”。7. 结果解读怎样才算“真正进化”评测指标拿到手后最关键的环节是解读。这里要特别注意几个容易误判的地方。7.1 任务顺序会影响结果同一个模型任务顺序不同持续学习表现可能差异很大。比如先学“API 调用”再学“信息抽取”和反过来可能得到完全不同的遗忘曲线。因此使用 ContinualSkillBench 做对比时必须保证所有模型在同一任务序列下评测否则结论没有意义。7.2 少量示例也可能造成指标偏差few-shot 示例的选择会显著影响成功率。有些任务里示例质量高一点成功率可能直接高十几个点。建议不要随便更换示例内容先使用项目提供的默认示例跑一个基线再考虑自定义示例。7.3 评估方式要统一任务结果判断方式对最终指标影响很大。程序化判断严格、规则清晰但可能对输出的格式要求很高模型评分灵活但可能存在评分偏差。一个稳妥的做法是所有被对比的模型都使用同一种判断方式并在发布结果时注明评估方法。换句话说“真正进化”的判断标准应该是综合的新任务成功率保持较高水平。旧任务成功率没有明显下降。前向迁移为正说明技能在积累。能力曲线整体平稳或上行而不是过山车。如果只满足第一点那只是“新任务适应能力强”不一定是“持续演进”。8. API 调用与批量评测实践ContinualSkillBench 这类评测项目常见做法是通过 OpenAI 兼容 API 批量调用模型。这里给出两个通用调用示例实际使用时需要根据项目的接口文档调整路径和参数。8.1 通用 Python 调用模板import openai client openai.OpenAI( base_urlhttp://127.0.0.1:8000/v1, # 替换为你的模型服务地址 api_keylocal, ) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: system, content: 你是评测任务中的 Agent请根据指令完成任务。}, {role: user, content: 今天的任务根据用户需求调用天气查询 API并返回 JSON 结果。} ], temperature0.2, max_tokens1024, ) print(response.choices[0].message.content)这个模板可以用于快速验证模型服务是否正常也可以作为评测框架里底层请求的参考实现。8.2 批量任务序列执行思路批量评测时建议按“任务序列 模型 重复次数”组织目录和日志results/ ├── model_a/ │ ├── run_1/ │ ├── run_2/ │ └── run_3/ ├── model_b/ │ ├── run_1/ │ └── run_2/ └── summary_report.csv每次运行评测后单独保存一份日志文件包含任务顺序、模型版本、提示词版本、耗时和结果。这样一来后续做结果回溯、异常排查就方便很多。批量任务如果跑很长时间建议加一层断点续跑逻辑。评测脚本每次执行完一个任务就把中间结果写入磁盘重新启动时检测到已有结果就跳过或者覆盖避免因为网络抖动或模型限流导致整个序列重跑。8.3 限流与重试调用云端模型 API 时需要注意频率限制。常见的处理方式包括在请求间加入固定延迟例如 1 到 2 秒。遇 429 错误时指数退避重试。每完成一个任务输出一条进度日志方便监控。import time MAX_RETRIES 3 def call_with_retry(client, payload, retriesMAX_RETRIES): for attempt in range(retries): try: resp client.chat.completions.create(**payload) return resp except Exception as e: print(fAttempt {attempt 1} failed: {e}) time.sleep(2 ** attempt) raise RuntimeError(API call failed after retries)如果你的评测任务量大建议先用 5 到 10 个请求做连通性测试确认限流策略和服务稳定性再大规模执行。9. 常见问题与排查方法实际运行评测基准时最容易出问题的点集中在依赖、模型调用和结果复现这三个环节。下表列出一份排查清单可以按图索骥。问题现象可能原因排查方式解决方案启动时提示缺少 Python 依赖包未正确创建虚拟环境或未安装 requirements检查 pip list查看缺失包名称重新执行 pip install -r requirements.txt网络请求超时API 地址不可达或云端模型服务限流用 curl 单独测试模型地址检查网络增加超时时间加入指数退避重试模型返回空输出提示词格式错误或 max_tokens 太小打印发送给模型的完整消息内容检查消息格式适当调大 max_tokens确认 temperature 设置评测结果总是 0 分判断脚本和模型输出格式不匹配查看模型原始输出和解析函数调整输出格式提示或放宽结果解析规则本地模型推理时显存不足模型参数量过大或并发请求过多查看 nvidia-smi 显存占用换用小模型或量化版本降低并发数合并请求两次评测结果波动很大模型采样随机性检查 temperature 设置固定 temperature 为 0 或较低值多次运行取平均任务序列跑到一半崩溃评测脚本缺少断点续跑支持查看崩溃点日志为每个任务单独写结果增加 try/except 容错结果文件和论文差异大评测条件不一致对比任务顺序、示例数量、判断方式严格复现项目 README 里的设置不要随意改参数其中最建议提前做的是第 4 条和第 6 条。格式解析问题在评测项目里几乎必然遇到第一次跑通时先打印原始输出确认模型的回答格式是 JSON、代码还是自然语言再确认解析逻辑。稳定性问题也一样LLM 评测的随机性会直接影响结论固定随机种子、固定参数、多次重复是基本操作。10. 最佳实践与合规建议把 ContinualSkillBench 用在真实项目中时有几个工程化建议值得记下来。10.1 先跑最小化实验第一次接触项目不要直接跑几百个任务的完整序列。先跑一个双任务序列确认评测逻辑正确、结果文件能正常写入再逐步扩大规模。这个习惯能省下大量排错时间。10.2 建立评测配置基线把每次评测的项目版本、模型名称、提示词模板、任务顺序、示例数量、temperature、max_tokens 完整记录下来。评测结束后这些信息比最终分数更重要因为它们决定了结果是否可以复现、可以对比。10.3 合理使用模型 API 与数据合规调用第三方模型 API 做评测时需要注意几点遵守模型服务提供方的服务条款和调用频率限制。评测数据如果涉及用户信息、内部文档、受版权保护的素材要及时脱敏或使用合成数据替代。涉及人脸、声音、个人身份信息的任务场景必须确认数据来源合法并获得必要授权。评测结果对外发布时建议注明模型版本、评测时间、评测条件和潜在偏差避免他人误解结果。10.4 关注本地部署与数据安全边界如果评测数据敏感建议优先选择本地部署的模型服务比如 vLLM、Ollama、Xinference 等推理框架确保数据不出内网。本地部署时需要注意显存规划和服务并发控制避免评测过程中显存溢出导致任务中断。10.5 不要只依赖单一指标做决策遗忘率低很重要但也要结合新任务成功率、迁移表现和任务完成质量综合判断。有些模型在记忆保持上很稳定但新任务的学习速度很慢这种模型在快速迭代的环境中可能并不好用。评测最终目的是服务于场景而不是选一个“分数最高的模型”贴上去。11. 总结与下一步这次我们看的 ContinualSkillBench是一个把 LLM Agent 持续学习能力变成可量化指标的评测基准。它通过连续任务序列、遗忘率计算、前后向迁移分析和多模型对照把“Agent 是否在真正进化”这个问题拆解成一组可以反复验证的数据指标。对做 Agent 应用选型的人来说这比只看单任务成功率更有说服力对做持续学习研究的人来说它提供了一个更贴近真实应用场景的实验框架。如果现在准备上手建议按照这个顺序推进先拉取项目、跑通单任务冒烟测试再运行一个双任务序列观察遗忘率然后用两个模型做横向对比最后再根据你自己的业务场景扩展任务序列。最容易踩的坑集中在格式解析和结果复现上第一次跑的时候先打印模型原始输出确认解析逻辑正确再大规模执行。后续可以持续关注的方向包括项目是否支持自定义任务接入、是否会补充更多 Agent 框架的对照结果、以及评测协议是否会扩展到多模态任务。如果你正在搭 Agent 能力的持续评测体系这个基准值得作为第一块试验田。 LLM Agent持续学习评测：用ContinualSkillBench量化技能遗忘与迁移
最近几个月围绕 LLM Agent 的讨论明显从“能不能跑通单任务”转向了“能不能持续变强”。今天要聊的这个项目ContinualSkillBench正是冲着这个问题来的LLM Agent 是真的在持续演进自己的能力还是只是在新任务上临时表现好、回头就把旧技能忘光了这个基准把“持续学习”从概念讨论变成了可量化、可对比的评测协议对于做 Agent 应用选型、模型能力评测、以及研究持续学习的人来说都值得认真看一遍。这个项目的核心价值可以概括成三点第一它把 Agent 评测从单任务静态测试扩展到了连续任务序列第二它显式量化了灾难性遗忘和技能迁移而不只是看平均准确率第三它提供了一套统一的评测脚本和结果记录方式方便做多模型横向对比。更重要的是这类基准项目本身不需要太高的硬件门槛因为评测框架只负责调度任务和调用模型真正吃显存的是被测 LLM 本身。这篇文章会带你走一遍完整流程先理解 ContinualSkillBench 的评测设计与指标含义再讲环境准备和项目启动方式然后演示单个任务、双任务序列、多模型对照的测试方法接着说明 API 调用与批量评测思路最后给出常见问题排查和工程化使用建议。如果你正在做 Agent 能力评估、要考虑模型选型或者想研究 LLM 的持续学习表现这篇可以直接收藏。1. ContinualSkillBench 核心能力速览在动手跑项目之前先把关键信息放在前面。以下参数需要以项目仓库和实际运行环境为准我按常见部署方式给出一份参考能力项说明项目类型LLM Agents 持续学习能力评估基准Benchmark研究问题Agent 能否在连续任务中学到新技能、保留旧技能、并实现跨任务迁移主要功能连续任务序列评测、技能遗忘量化、前向/后向迁移分析、多模型结果对照任务数据多个子任务组成任务序列每个任务带有示例、测试集和评估脚本评测方式自动化脚本逐个执行任务记录成功率和技能保持情况运行平台支持 Linux / macOS / Windows主要依赖 Python硬件要求纯评测框架 CPU 可运行调用本地 LLM 时需要 GPU显存按模型版本而定接口支持评测框架可通过 OpenAI 兼容 API 路由到不同模型服务批量能力按任务序列批量执行支持多模型、多轮重复评测适合场景模型选型对比、Agent 能力诊断、持续学习研究、技能库设计验证从这张表能看出来这个项目更像是一个评测基础设施而不是开箱即用的 Agent 应用。你要自己提供被测模型可以是云端 API也可以是本地部署的模型服务。评测框架帮你把任务串起来最后输出结构化的结果便于横向比较。2. 这个基准在回答什么问题现在主流的 Agent 评测方式一般是一次性给模型一个任务然后看它能不能完成。这种方式能反映“单点能力”但有一个明显的盲区** Agent 在连续面对多个任务时能力是叠加的、还是互相干扰的** 现实中的 Agent 应用往往不是只处理一个用户请求而是要在长时间内不断接收新任务比如一个客服 Agent今天处理退货流程明天新增了发票开具功能后天又接入优惠券核销。一个代码助手 Agent先学会项目结构理解再学习接口文档生成接着又要处理测试用例生成。一个数据分析 Agent先会查数据库再学会做图表然后要能写分析报告。如果 Agent 只学新任务、忘了旧任务那长期使用中就会出现“昨天会的今天不会了”的情况。ContinualSkillBench 要量化的就是这种能力曲线随着任务序列不断推进Agent 在新任务上的表现如何对旧任务的保持程度又如何。这个方向之所以值得关注是因为它把“持续学习”和“灾难性遗忘”这两个经典机器学习问题搬到了 LLM Agent 的场景下重新定义。传统持续学习研究的是神经网络在数据流上的权重更新而 LLM Agent 场景下“更新能力”的方式更加多样可以是上下文指令、可以是 few-shot 示例、可以是微调权重、也可以是外部记忆和工具注册。ContinualSkillBench 通过统一的任务序列和评估协议让不同能力的 Agent 能在同一个标尺下比较而不是各说各话。简单说这个基准不是又一个“刷分榜单”而是想回答一个更底层的工程问题如果让 Agent 在一连串任务里持续工作它的能力是越滚越强还是学到后来把前面都丢了3. 数据集与任务序列设计思路这类 Benchmark 的核心设计集中在“任务序列”上而不是单个任务本身。ContinualSkillBench 在任务组织上通常会包含以下几个层次。3.1 任务单元每个任务单元是一个可独立评估的完整任务带有明确的输入、预期输出和验证方式。从常见设计看任务类型可能包括API 工具调用给定用户意图Agent 需要构造正确的 API 请求参数。信息抽取与整理从给定文档中抽取结构化信息。多轮对话在连续多轮中维持上下文并完成目标。代码生成与修复根据需求生成代码或修复带 bug 的代码。结构化输出按 JSON Schema 输出结果供下游系统消费。每个任务都会提供少量示例few-shot demonstrations作为 Agent 学习该任务技能的“数据”。这里的示例数量通常很少目的是模拟真实场景中“给一两个例子就能上手”的效果而不是大规模微调。3.2 任务序列多个任务按一定顺序组成序列。比如任务序列 S1: [任务A - API调用] - [任务B - 信息抽取] - [任务C - 多轮对话]序列设计要能回答几个问题Agent 在完成 A 后进入 B 时A 的技能还能不能保留B 的学习会不会干扰 A 的表现C 出现时能否借助 A 和 B 中已经形成的“工具使用”经验更快上手为了控制变量同一个任务在序列中的位置可以轮换比如 A 在前、B 在后以及 B 在前、A 在后分别评测就能看出顺序对技能保持的影响。这类实验设计在论文中通常叫“任务排序敏感性分析”实际使用时也可以按这个思路做小规模验证。3.3 评测协议评测协议定义了如何执行任务、如何判断结果。比较合理的流程是给 Agent 提供当前任务的说明和示例。Agent 执行任务生成输出。用规则或模型做自动评估判断输出是否正确。记录结果进入下一个任务。在后续的某个位置重新测试前面已经学过的任务检查是否有遗忘。评测协议是否标准直接决定了实验结果的可信度。运行这个基准时要特别注意任务说明和示例提示词是否固定如果不同轮次使用了不同的提示词结果就很难横向比较。4. 评测指标怎么看懂实验输出ContinualSkillBench 这类项目最值得学的部分就是它如何量化“持续学习能力”。如果只看每个任务的平均成功率会掩盖遗忘和迁移问题。更合理的评估体系应该包含以下几个指标。4.1 任务成功率Task Success Rate单个任务独立评估时的完成比例是最基础的指标。它反映 Agent 在“单独面对这个任务”时的能力上限。4.2 遗忘率Forgetting Rate这是持续学习评测的核心指标。计算方式是Agent 在完成新任务后重新测试旧任务看旧任务的成绩相比刚学会时下降了多少。遗忘率 旧任务初始成功率 - 新任务阶段再次测试的旧任务成功率遗忘率越高说明 Agent 学了新技能后对旧技能的保持越差。这个指标对实际工程选型非常有意义因为它直接告诉你这个模型适不适合“长期服役”在一个多任务环境里。4.3 前向迁移Forward Transfer前向迁移衡量的是Agent 在完成前面几个任务后学习新任务的速度是否变快或者最终表现是否更好。比如任务 C 单独第一次跑可能是 40% 成功率但在完成 A、B 之后再来跑 C成功率到了 60%说明 A、B 带来的经验对 C 有正向帮助。4.4 后向迁移Backward Transfer后向迁移衡量的是新任务的学习对旧任务的影响。如果学完任务 C 之后任务 A 的成功率反而提升了说明存在正向后向迁移如果下降了就是负向迁移也就是遗忘的一种表现。4.5 综合能力曲线把任务序列按顺序展开横轴是任务推进纵轴是已完成任务的平均成功率就能画出一条能力曲线。理想的“真正进化”曲线应该是整体走高或者至少保持平稳如果曲线明显下滑说明 Agent 的“学习”实际上是“覆盖”。这五个维度合在一起才能回答标题里那个问题Agent 是不是真的在进化还是只是在新任务上做短期适应。5. 环境准备与项目运行现在进入实际操作部分。这类评估基准项目通常以 Python 仓库形式发布运行流程总体是拉取代码、安装依赖、配置模型、启动评测、读取结果。5.1 基础环境检查无论评测框架本身多轻量你终究需要一个被测 LLM。所以在准备环境时先把下面几项检查完检查项说明操作系统Windows / Linux / macOS 均可建议 Linux 服务器跑长序列任务Python 版本建议 3.10 或以上具体以项目 requirements 为准被测模型可以是云端 API也可以是本地模型本地模型需要 GPUGPU 显存取决于模型量化版本7B 模型通常需要 8G 以上显存13B 以上建议 16G 起磁盘空间代码仓库不大但本地模型权重可能占用数十 GB网络环境调用云端 API 时需要正常网络访问5.2 拉取项目并安装依赖# 克隆项目仓库仓库地址以项目主页为准 git clone https://github.com/your-repo/ContinualSkillBench.git cd ContinualSkillBench # 创建 Python 虚拟环境避免污染系统环境 python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate # 安装依赖 pip install -r requirements.txt如果安装依赖时遇到网络问题可以考虑使用国内 PyPI 镜像pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple5.3 配置被测模型评测框架通常通过环境变量或配置文件来指定模型服务地址。最常见的方式是 OpenAI 兼容接口这样既能接 OpenAI API也能接本地部署的 vLLM、Ollama、Xinference 等服务。以环境变量方式为例export OPENAI_API_BASEhttps://api.openai.com/v1 export OPENAI_API_KEYyour-api-key export LLM_MODEL_NAMEgpt-4o-mini如果是本地 vLLM 服务export OPENAI_API_BASEhttp://127.0.0.1:8000/v1 export OPENAI_API_KEYlocal export LLM_MODEL_NAMEQwen/Qwen2.5-7B-Instruct这段时间接国产模型的开发者越来越多如果你的评测场景在境内网络环境下运行可以考虑使用支持 OpenAI 兼容协议的国产模型服务或本地推理框架部署路径更可控。5.4 运行评测脚本评测脚本的入口一般是一个 Python 或 shell 脚本用于执行指定任务序列并打印结果。假设项目提供的入口是run_evaluation.py一个通用运行方式如下python run_evaluation.py \ --config configs/default_task_sequence.yaml \ --output_dir ./results \ --save_every_step这里的configs/default_task_sequence.yaml是任务序列配置文件包含参与评测的任务、顺序、示例数量和模型参数。输出目录./results会保存每一轮任务的原始输出和评分结果。如果你用的配置格式不同则需要参考项目 README 修改参数名。但整体思路是一致的先确认任务序列配置再启动评测最后在输出目录里看结果。6. 功能测试与效果验证拿到项目后建议不要直接跑满整个任务序列而是按下面这个顺序做验证逐步确认环境没问题、评测逻辑正确、结果可复现。6.1 单任务冒烟测试先挑一个最简单的任务单独运行一次。目的不是测量性能而是确认模型 API 连接正常。提示词能正确传给模型。模型输出能被评测脚本解析。评测脚本能正确判断结果。python run_evaluation.py --task task_a --config configs/smoke_test.yaml这一步跑通后再进入任务序列评测。如果单任务都跑不通先检查 API 地址、密钥、模型名不要急着上完整序列。6.2 双任务序列测试双任务序列是性价比最高的验证实验。选择两个任务 A 和 B先学 A再学 B然后回到 A 重新测试就能同时看到遗忘率信号和迁移信号。预期输出结构类似{ task_order: [task_a, task_b], task_a_success_initial: 0.85, task_b_success_after_a: 0.72, task_a_success_after_b: 0.63, forgetting_task_a: 0.22 }这里forgetting_task_a 0.85 - 0.63 0.22说明 Agent 在学习任务 B 之后对任务 A 的能力下降了 22 个百分点。这个数字直接反映了模型的灾难性遗忘程度是做模型对比时最核心的参考指标之一。判断标准如果遗忘率接近 0说明模型对旧技能保持良好。如果遗忘率很高说明模型可能过于偏向“最近见过的东西”。如果任务 B 学完后任务 A 的成绩比 0.85 还高说明存在正向后向迁移这是一个非常积极的信号。6.3 三任务序列与迁移测试三任务序列可以更细地观察前向迁移。假设任务顺序是 A - B - C重点看B 的表现是否因为 A 的经验而有提升。C 是否能够复用 A、B 中已经形成的工具调用模式。学完 C 之后A 和 B 的保持情况。建议对同一个序列跑 3 遍取平均值。LLM 输出存在随机性单次结果有波动属于正常现象多次重复取平均可以减少噪声对结论的影响。6.4 多模型横向对比当单模型验证通过后就可以开始对比不同模型。把同样的任务序列和评测协议分别跑在不同模型上整理成表格模型初始任务A成功率学完B后A成功率遗忘率新任务C成功率模型-10.850.630.220.71模型-20.820.790.030.68模型-30.780.650.130.75从这张对比表里可以直观看出某些模型可能在单任务成绩上很接近但在遗忘率上的差异非常明显。如果你的应用需要 Agent 长期处理多种任务模型的选择逻辑就不应该只看“平均分最高”还要看“分数是否稳定保持”。7. 结果解读怎样才算“真正进化”评测指标拿到手后最关键的环节是解读。这里要特别注意几个容易误判的地方。7.1 任务顺序会影响结果同一个模型任务顺序不同持续学习表现可能差异很大。比如先学“API 调用”再学“信息抽取”和反过来可能得到完全不同的遗忘曲线。因此使用 ContinualSkillBench 做对比时必须保证所有模型在同一任务序列下评测否则结论没有意义。7.2 少量示例也可能造成指标偏差few-shot 示例的选择会显著影响成功率。有些任务里示例质量高一点成功率可能直接高十几个点。建议不要随便更换示例内容先使用项目提供的默认示例跑一个基线再考虑自定义示例。7.3 评估方式要统一任务结果判断方式对最终指标影响很大。程序化判断严格、规则清晰但可能对输出的格式要求很高模型评分灵活但可能存在评分偏差。一个稳妥的做法是所有被对比的模型都使用同一种判断方式并在发布结果时注明评估方法。换句话说“真正进化”的判断标准应该是综合的新任务成功率保持较高水平。旧任务成功率没有明显下降。前向迁移为正说明技能在积累。能力曲线整体平稳或上行而不是过山车。如果只满足第一点那只是“新任务适应能力强”不一定是“持续演进”。8. API 调用与批量评测实践ContinualSkillBench 这类评测项目常见做法是通过 OpenAI 兼容 API 批量调用模型。这里给出两个通用调用示例实际使用时需要根据项目的接口文档调整路径和参数。8.1 通用 Python 调用模板import openai client openai.OpenAI( base_urlhttp://127.0.0.1:8000/v1, # 替换为你的模型服务地址 api_keylocal, ) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: system, content: 你是评测任务中的 Agent请根据指令完成任务。}, {role: user, content: 今天的任务根据用户需求调用天气查询 API并返回 JSON 结果。} ], temperature0.2, max_tokens1024, ) print(response.choices[0].message.content)这个模板可以用于快速验证模型服务是否正常也可以作为评测框架里底层请求的参考实现。8.2 批量任务序列执行思路批量评测时建议按“任务序列 模型 重复次数”组织目录和日志results/ ├── model_a/ │ ├── run_1/ │ ├── run_2/ │ └── run_3/ ├── model_b/ │ ├── run_1/ │ └── run_2/ └── summary_report.csv每次运行评测后单独保存一份日志文件包含任务顺序、模型版本、提示词版本、耗时和结果。这样一来后续做结果回溯、异常排查就方便很多。批量任务如果跑很长时间建议加一层断点续跑逻辑。评测脚本每次执行完一个任务就把中间结果写入磁盘重新启动时检测到已有结果就跳过或者覆盖避免因为网络抖动或模型限流导致整个序列重跑。8.3 限流与重试调用云端模型 API 时需要注意频率限制。常见的处理方式包括在请求间加入固定延迟例如 1 到 2 秒。遇 429 错误时指数退避重试。每完成一个任务输出一条进度日志方便监控。import time MAX_RETRIES 3 def call_with_retry(client, payload, retriesMAX_RETRIES): for attempt in range(retries): try: resp client.chat.completions.create(**payload) return resp except Exception as e: print(fAttempt {attempt 1} failed: {e}) time.sleep(2 ** attempt) raise RuntimeError(API call failed after retries)如果你的评测任务量大建议先用 5 到 10 个请求做连通性测试确认限流策略和服务稳定性再大规模执行。9. 常见问题与排查方法实际运行评测基准时最容易出问题的点集中在依赖、模型调用和结果复现这三个环节。下表列出一份排查清单可以按图索骥。问题现象可能原因排查方式解决方案启动时提示缺少 Python 依赖包未正确创建虚拟环境或未安装 requirements检查 pip list查看缺失包名称重新执行 pip install -r requirements.txt网络请求超时API 地址不可达或云端模型服务限流用 curl 单独测试模型地址检查网络增加超时时间加入指数退避重试模型返回空输出提示词格式错误或 max_tokens 太小打印发送给模型的完整消息内容检查消息格式适当调大 max_tokens确认 temperature 设置评测结果总是 0 分判断脚本和模型输出格式不匹配查看模型原始输出和解析函数调整输出格式提示或放宽结果解析规则本地模型推理时显存不足模型参数量过大或并发请求过多查看 nvidia-smi 显存占用换用小模型或量化版本降低并发数合并请求两次评测结果波动很大模型采样随机性检查 temperature 设置固定 temperature 为 0 或较低值多次运行取平均任务序列跑到一半崩溃评测脚本缺少断点续跑支持查看崩溃点日志为每个任务单独写结果增加 try/except 容错结果文件和论文差异大评测条件不一致对比任务顺序、示例数量、判断方式严格复现项目 README 里的设置不要随意改参数其中最建议提前做的是第 4 条和第 6 条。格式解析问题在评测项目里几乎必然遇到第一次跑通时先打印原始输出确认模型的回答格式是 JSON、代码还是自然语言再确认解析逻辑。稳定性问题也一样LLM 评测的随机性会直接影响结论固定随机种子、固定参数、多次重复是基本操作。10. 最佳实践与合规建议把 ContinualSkillBench 用在真实项目中时有几个工程化建议值得记下来。10.1 先跑最小化实验第一次接触项目不要直接跑几百个任务的完整序列。先跑一个双任务序列确认评测逻辑正确、结果文件能正常写入再逐步扩大规模。这个习惯能省下大量排错时间。10.2 建立评测配置基线把每次评测的项目版本、模型名称、提示词模板、任务顺序、示例数量、temperature、max_tokens 完整记录下来。评测结束后这些信息比最终分数更重要因为它们决定了结果是否可以复现、可以对比。10.3 合理使用模型 API 与数据合规调用第三方模型 API 做评测时需要注意几点遵守模型服务提供方的服务条款和调用频率限制。评测数据如果涉及用户信息、内部文档、受版权保护的素材要及时脱敏或使用合成数据替代。涉及人脸、声音、个人身份信息的任务场景必须确认数据来源合法并获得必要授权。评测结果对外发布时建议注明模型版本、评测时间、评测条件和潜在偏差避免他人误解结果。10.4 关注本地部署与数据安全边界如果评测数据敏感建议优先选择本地部署的模型服务比如 vLLM、Ollama、Xinference 等推理框架确保数据不出内网。本地部署时需要注意显存规划和服务并发控制避免评测过程中显存溢出导致任务中断。10.5 不要只依赖单一指标做决策遗忘率低很重要但也要结合新任务成功率、迁移表现和任务完成质量综合判断。有些模型在记忆保持上很稳定但新任务的学习速度很慢这种模型在快速迭代的环境中可能并不好用。评测最终目的是服务于场景而不是选一个“分数最高的模型”贴上去。11. 总结与下一步这次我们看的 ContinualSkillBench是一个把 LLM Agent 持续学习能力变成可量化指标的评测基准。它通过连续任务序列、遗忘率计算、前后向迁移分析和多模型对照把“Agent 是否在真正进化”这个问题拆解成一组可以反复验证的数据指标。对做 Agent 应用选型的人来说这比只看单任务成功率更有说服力对做持续学习研究的人来说它提供了一个更贴近真实应用场景的实验框架。如果现在准备上手建议按照这个顺序推进先拉取项目、跑通单任务冒烟测试再运行一个双任务序列观察遗忘率然后用两个模型做横向对比最后再根据你自己的业务场景扩展任务序列。最容易踩的坑集中在格式解析和结果复现上第一次跑的时候先打印模型原始输出确认解析逻辑正确再大规模执行。后续可以持续关注的方向包括项目是否支持自定义任务接入、是否会补充更多 Agent 框架的对照结果、以及评测协议是否会扩展到多模态任务。如果你正在搭 Agent 能力的持续评测体系这个基准值得作为第一块试验田。