这次我们来看一个有点特别的 LLM Agent 项目ContinualSkillBench。它不解决“怎么让 Agent 写代码更准”这种单点任务而是直接问一个问题LLM Agent 能不能像人一样在一个任务序列上持续学习越用越强而不是每接一个新任务就把旧技能忘光如果你关心 LLM Agent 评测、持续学习、技能积累、灾难性遗忘这些方向或者你正在做 Agent 层面的产品需要一套能连续考核“技能进化”的评估框架这篇文章可以直接收藏。我会从基准设计、运行流程、功能验证、批量评测、结果指标、常见坑位这几个角度完整拆一遍。先说结论这类的评估基准重点不是“跑起来难不难”而是“怎么让 Agent 在连续任务上展示出可量化的能力增长”。下面展开。1. 核心能力速览能力项说明项目类型LLM Agent 持续学习能力评估基准Benchmark核心问题Agent 能否在连续任务流上持续获取新技能、避免旧技能遗忘、实现跨任务迁移评测对象各类 LLM AgentGPT、Claude、Llama 等通过 API 或本地模型接入主要功能连续任务评测、技能遗忘检测、跨任务迁移测试、分阶段指标评估对比对象传统单任务静态评测集、固定 prompt 的 Agent 测试、一次性 skill benchmark推荐硬件纯 API 调用模式对本地 GPU 要求不高本地模型推理需要按模型规模配置显卡显存占用不确定取决于被测模型是云端 API 还是本地模型支持平台Linux / macOS / Windows需按实际评测脚本适配启动方式Python 脚本 数据集配置 Agent 后端接入是否支持 API支持评测框架通过 API/Agent SDK 与被测模型交互是否支持批量任务支持可按任务序列批量跑多个模型、多个随机种子适合场景学术研究、Agent 能力追踪、模型选型、持续学习算法验证从项目标题看这个工作的核心价值不是“又一个 Agent 应用”而是把评测视角从静态能力转向动态进化。连续任务、技能增长、遗忘控制这三个词是理解整个基准的钥匙。2. 适用场景与使用边界2.1 适合谁用第一类是做 LLM Agent 学术研究的人。如果你想验证“我的 agent 能不能在学习新任务后保留旧技能”传统评测集给不了答案因为它只测单次快照。ContinualSkillBench 这类基准会设计一个任务序列让同一个 Agent 实例连续做完多个任务再回测旧任务这样“会不会忘”就变成可测指标。第二类是在业务里做 Agent 长周期运行的人。只要 Agent 不是单次问答而是要在多轮、多天、多任务中长期服务能力衰减、指令冲突、旧任务劣化都是真实风险。拿这个基准跑一遍能发现 Agent 在哪种连续任务模式下退化最严重。第三类是做模型选型和 prompt 策略对比的人。同一套任务序列换不同底层模型、不同 agent 框架、不同 memory 策略看曲线差异选最稳的配置。2.2 不适合什么场景它不适合用来测“单轮推理能力”“知识问答准确性”这类静态指标。这些问题应该用 MMLU、GSM8K、HELM 等常规基准。它也不适合当作 Agent 应用的线上监控系统。这是一个离线评测框架不是运行时观测平台。2.3 使用边界与合规提醒评测过程会调用 LLM必须注意被测数据集的版权和使用许可项目自带数据集和评测内容请先确认 License不要拿去做论文以外的商业用途。API Key 安全大批量评测会消耗 token不要把 Key 写进公开配置建议用环境变量。隐私风险如果你评测的 Agent 会读取真实用户对话、文档、代码库请先脱敏。不要拿线上真实用户数据当评测集。输出内容可控性Agent 可能生成不合规文本评测任务要设计好输出过滤和人工抽检。如果是用本地模型评测注意模型开源协议生成代码可能涉及版权问题商用前必须复核。3. 理解 ContinualSkillBench 的基准设计要跑通一个 Benchmark先要理解它的设计逻辑。虽然我们没有拿到原始论文的完整细节但从标题和这个大类的学术脉络可以还原关键模块。3.1 从“单任务评测”到“连续任务评测”传统的 Agent Benchmark 大致是给一堆独立任务每个任务从头开始测Agent 每次都是同一个初始状态。这种测法只能回答“这个 Agent 现在会不会这项技能”。持续学习评测不一样。它会把任务组织成序列任务1 - 任务2 - 任务3 - ... - 任务NAgent 需要先解决任务 1再继续解决任务 2、任务 3直到任务 N。评测重点包括学习任务 N 时任务 1、2 的技能有没有退化任务 N 的解决效率是不是因为前面任务的经验而变高学完所有任务后回测全部任务平均能力是上升还是下降这就是 ContinualSkillBench 这类基准的价值把“有没有变强”变成一个可以量化的过程指标。3.2 典型评测模块拆解一个完整的持续技能评测通常包含以下部分模块作用验证点任务序列生成器按顺序产出任务任务间有技能关联或干扰任务是否连续、难度是否递增Agent 后端适配层将评测框架的请求转为模型可执行的 prompt 或 API 调用同一套任务能否接入不同 Agent技能沉淀模块让 Agent 在任务之间保留经验memory、配置文件、工具缓存是否真的“记住了”回测模块学完新任务后回测旧任务灾难性遗忘程度指标计算器输出平均能力、遗忘率、迁移率等指标结果是否可复现整体运行逻辑可以近似表达成评测框架本身提供一个任务序列然后让 Agent 在其中“活”一段时间而不是“答”一道题。理解这一点后面操作时就不会纠结“为什么数据集这么少、为什么还有序列顺序”。3.3 与普通 LLM 评测的最大区别普通评测是“静态题单”跑完得分即结束。持续学习评测是“动态游戏”Agent 的状态会在任务之间延续后续任务可能故意引入与旧任务冲突的目标考察 Agent 如何权衡。这也是为什么针对 LLM Agent 会不会“真的进化”的评价会比单点准确率更复杂。4. 环境准备与前置条件按当前主流研究型评测框架的惯例这套基准的运行环境可以按下面方式准备。具体版本和依赖以项目 README 为准。4.1 基础软件环境操作系统Linux 最稳妥macOS 也可以Windows 可能需要处理路径和并发差异。Python建议 3.10 或 3.11。太低的版本容易出现依赖兼容问题太高可能有个别库还没跟上。包管理conda 或 venv 都行更推荐 conda方便隔离不同 python 版本。Git用来克隆项目代码。# 创建独立环境避免污染系统 Python conda create -n continualbench python3.11 -y conda activate continualbench4.2 硬件与模型接入如果被测 Agent 使用 OpenAI、Anthropic、Gemini 等云端 API本机不需要独立显卡。评测的瓶颈主要在 API 调用频率、网络延迟和 token 预算。如果你打算用本地开源模型如 Llama 3、Qwen 系列做被测 Agent就需要 GPU。显存要求取决于模型参数量、量化方式和上下文长度。7B~8B 模型用 16GB 显存比较宽松70B 模型即使量化到 4bit也需要 32GB 以上显存。这些数字只是经验参考实际以模型运行时的峰值占用为准。4.3 磁盘空间评测数据本身通常不大但日志、中间结果、模型输出快照会膨胀尤其是多模型、多轮任务连续跑的场景。建议预留 20GB 左右的磁盘空间如果包含本地模型权重额外按模型体积预留。4.4 环境变量大模型 API 通常通过环境变量读取 Key不要硬编码到评测代码里。export OPENAI_API_KEYsk-xxxxxxxxxxxxxxxx以实际使用的模型服务商为准有的用ANTHROPIC_API_KEY有的用DASHSCOPE_API_KEY。5. 安装部署与运行评测由于我们目前只有标题和公开信息下面给出一套可执行的通用运行框架具体路径、脚本名称、参数需要按 ContinualSkillBench 项目仓库里的 README 调整。5.1 克隆项目与安装依赖git clone https://github.com/your-repo/ContinualSkillBench.git cd ContinualSkillBench # 安装依赖具体以 requirements.txt 或 pyproject.toml 为准 pip install -r requirements.txt如果项目使用 poetry 或 uv可以替换为poetry install # 或 uv sync这里不要盲目跑安装命令先看仓库根目录有没有requirements.txt、pyproject.toml、environment.yml优先按官方给的安装方式。5.2 查看项目目录结构评测类项目一般长这样ContinualSkillBench/ ├── configs/ # 评测配置 ├── data/ # 任务数据集 ├── agent/ # Agent 接入层 ├── evaluator/ # 评测器 ├── metrics/ # 指标计算 ├── scripts/ # 一键运行脚本 ├── results/ # 输出结果 └── README.md先跑tree -L 2或直接看 README 的目录说明了解评测入口文件。5.3 准备配置文件一个典型的评测配置会指定被测模型、Agent 类型、任务序列、回测开关、结果输出目录。可以用 YAML 或 JSON 格式下面是一个通用示例# configs/eval_demo.yaml注意字段以实际项目为准 model: provider: openai name: gpt-4o-mini agent: type: react # ReAct / Plan-and-Solve / ToolUse 等 memory: simple # 任务间是否保留记忆 evaluation: task_sequence: [task_a, task_b, task_c, task_d] enable_backtest: true repeats: 3 # 每个任务重复次数用于稳定指标 timeout_per_task: 300 log_level: info output: save_dir: results/demoenable_backtest很重要。如果没开回测就只能看到新任务得分看不到“旧任务忘没忘”。5.4 启动评测假设项目提供了命令行入口常见方式可能是python scripts/run_benchmark.py --config configs/eval_demo.yaml或者python -m continual_skill_bench.run --config configs/eval_demo.yaml以实际仓库为准。如果是面向研究者的基准项目通常还会有“先跑一个小规模 demo”的说明。第一次运行永远先跑最小任务集和最小模型验证链路通不通。5.5 检查输出结构运行完成后results/demo目录下应该能看到每个任务的原始模型输出任务序列上的逐步得分回测旧任务的得分变化汇总成 CSV 或 JSON 的指标表。拿到这些文件就可以做能力趋势分析了。6. 功能测试与效果验证部署跑通以后下一步是理解“评测结果到底说明什么”。下面按 5 个维度给出验证思路。6.1 验证任务序列能否正常执行目的确认 Agent 可以按顺序完成多个任务而不是单任务快照。操作选一个 2~3 个任务的短序列用简单模型跑一遍看任务是否逐个完成有没有因上下文累积导致的报错、超时、死循环。预期Agent 能完成任务 1带着任务 1 的状态进入任务 2不出现 API 报错或超时。常见失败单任务正常多任务连续跑时上下文过长导致模型超时。此时需要检查评测框架有没有上下文截断机制。6.2 验证新技能获取能力在任务序列里添加一个 Agent 之前不会的新任务类型跑完看成功率。例如任务 1 是“读取文件并总结”任务 2 是“根据总结写测试用例”。如果 Agent 在任务 2 的成功率明显高于从头直接测任務 2 的对照组说明迁移学习在起作用。# 示例对比连续序列得分 vs 单任务独立得分 import json with open(results/demo/sequence_scores.json) as f: seq_scores json.load(f) with open(results/demo/independent_scores.json) as f: indep_scores json.load(f) for task in seq_scores: print(task, sequence:, seq_scores[task], independent:, indep_scores[task])这里的关键不是一次得高分而是连续任务得分是否高于独立任务基线。如果是说明 Agent 在任务间“学到了”东西如果两者基本一样说明 Agent 没有从历史任务中获取技能增益。6.3 验证旧技能是否遗忘这是 ContinualSkillBench 这类项目最核心的一环。学习完任务序列后回测任务 1、任务 2。比较刚学完任务 1 时的得分学完任务 3 后再测任务 1 的得分。如果第二次明显变低就是发生了灾难性遗忘。如果持平甚至更高说明 Agent 有较好的技能保持能力。# 计算遗忘率示例逻辑 def forgetting_rate(initial_score, final_score): return (initial_score - final_score) / initial_score if initial_score else 0在评测结果中重点关注这个数值。很多 Agent 框架声称“能记住”一上连续任务就露馅。6.4 验证跨任务迁移如果任务 2 和任务 3 有技能重叠比如都要调用同一类工具那么任务 3 完成时间应该更短、尝试次数更少。操作对每个任务记录“完成所需轮次”“工具调用次数”“错误次数”比较任务间的这些过程指标预期随着任务推进同类任务的完成效率上升。注意如果任务间的技能冲突较多迁移率可能是负的这也是一种有价值的结果。6.5 验证稳定性在相同配置下用不同随机种子重复 3 次以上看结果的标准差。for seed in 42 43 44; do python scripts/run_benchmark.py --config configs/eval_demo.yaml --seed $seed done标准差过大的任务说明 Agent 对该任务的输出不够稳定可能是 prompt 对样例顺序太敏感也可能是模型随机性太强。这个指标对线上使用非常重要。7. 评测指标与结果分析7.1 常用指标持续学习评测一般看四类指标指标内涵怎么判断Task Success Rate每个任务的成功率越高越好Cumulative Score整个序列的累计得分体现整体能力增长Forgetting Rate旧任务能力下降幅度越低越好Transfer Rate相邻任务互益程度正数表示迁移成功负数表示干扰7.2 结果可视化评测结果最好画成两条线序列任务得分曲线每个任务在序列结束后的回测得分曲线。如果回测曲线在后期明显下弯说明 Agent 学新忘旧。可以用 Matplotlib 简单画图但最终结果还是以项目自带的指标计算脚本输出为准。如果你要发论文或者做报告可以额外输出一份 CSV包含每个任务、每个模型、每个 seed 的原始得分。7.3 显存与性能观察如果你用本地模型跑评测需要时刻关注显存。评测时显存占用和普通单任务推理不同因为任务序列越长上下文和工具调用记录会累积占用会逐步上升。建议用nvidia-smi监控watch -n 1 nvidia-smi如果发现显存持续上升直到 OOM应该排查评测框架是否每轮都保存全量历史如对话历史、工具输出、中间文件Agent 是否把太多内容塞进上下文而非外部记忆是否缺少对历史消息的截断或摘要机制。8. 批量评测任务这个项目如果要支撑多模型对比一定会进入批量评测场景。下面给出两种常用批量思路。8.1 脚本批量跑多个配置for cfg in configs/model_gpt4o.yaml configs/model_claude.yaml configs/model_qwen.yaml; do echo Running: $cfg python scripts/run_benchmark.py --config $cfg --seed 42 done跑完后结果会自动落在各配置指定的输出目录。8.2 多 seed 批量跑为了拿到稳定指标建议每个配置至少跑 3 个 seedfor seed in 42 43 44; do python scripts/run_benchmark.py --config configs/eval_demo.yaml --seed $seed done8.3 批量任务的管理建议每个运行实例单独建输出目录命名规则用{model}_{agent_type}_{task_sequence}_{seed}每个运行写一个日志文件并记录开始/结束时间结果统一汇总到一个results_summary.csv方便后续画图批量任务可能因为 API 限流失败配置重试机制。# 通用重试示例 import time def call_with_retry(func, retries3, delay5): for i in range(retries): try: return func() except Exception as e: print(fretry {i1}, error: {e}) time.sleep(delay) raise RuntimeError(failed after retries)9. 常见问题与排查方法问题现象可能原因排查方式解决方案跑完任务 1任务 2 就报错上下文超长或 API 超时查看日志里的 token 数和耗时开启上下文截断或换更长上下文的模型回测旧任务分数反而更高任务间提示词信息泄漏检查任务构建逻辑是否把答案写进了新任务改用无泄漏的任务隔离生成方式同一任务多次跑结果波动大模型采样随机性固定 temperature 或加 seed调低 temperature多次重复取均值批量任务跑到一半卡住API 限流或网络问题查看是否有 429/5xx 报错加指数退避重试或降低并发数显存持续上涨后 OOM上下文累积历史过多nvidia-smi监控显存曲线开启摘要机制定期压缩历史评测结果文件为空配置中的输出路径不存在检查脚本是否有mkdir -p先手动建目录或添加自动创建逻辑Agent 在某个任务上死循环工具调用没有终止条件查看日志中工具调用次数设置最大调用轮次超时强制结束10. 最佳实践与使用建议10.1 先小后大逐步扩展第一次跑永远用最小任务集、最小模型、最短超时。先确认链路再跑全量。不要一上来就全模型、全任务、多 seed否则排错成本会很高。10.2 建立可复现实验目录结构experiments/ ├── configs/ ├── logs/ ├── results/ └── summary/每次实验记录模型版本、Agent 类型、任务序列、seed、温度、上下文截断策略。以后写报告或复现时才不会混乱。10.3 控制 Agent 的上下文策略持续学习评测最大的工程难点是上下文累积。建议短任务序列先跑通长序列开启摘要历史工具输出要裁剪不要完整塞进下一轮尽量把长期知识放在外部存储而不是对话上下文里。10.4 合规与授权提醒评测内容只用公开、已授权数据企业内部的评测结果不要直接外发涉及代码、文档、用户数据时先脱敏使用开源模型时遵守模型 License商用前需额外确认。10.5 不要迷信单一指标持续学习评测是多维的成功率、遗忘率、迁移率、稳定性要一起看。一个 Agent 可能成功率高但遗忘率也高另一个模型可能成功率略低但几乎不失忆。具体选哪个取决于你的业务更看重“上限”还是“稳定”。11. 总结与下一步ContinualSkillBench 这类基准把这个领域里被忽略的问题摆到了台面上LLM Agent 在连续任务上到底会不会积累技能它不再用单任务题单给 Agent 打分而是让 Agent 在一个任务序列里“生活”一段时间看它是否越用越强、有没有学新忘旧。建议拿到项目后第一步先跑通一个小规模 demo确认任务序列能否连续执行回测开关是否生效批量运行和结果输出是否正常。最值得重点验证的功能是“回测旧任务”因为这直接反映 Agent 的遗忘程度。最容易踩的坑是上下文累积和 API 限流这两点会在长序列和批量任务中被放大。接下来可以做的方向把不同模型在同一任务序列上的曲线对比出来换成不同 Agent 框架看技能迁移差异或者引入 memory 策略来压低遗忘率。如果你也在研究 LLM Agent 的持续能力进化这个基准值得认真跑一遍。建议收藏备用等动手部署时可以少走弯路。