最近在和团队做 LLM Agent 项目时，我一直在思考一个问题：我们经常说“Agent 会调用工具、会分解任务、会自己反思”，但如果让它接触一批新技能，它到底是真的学会了，还是只是记住了当前任务的答案？如果后续任务变了，它还能不能把这些能力迁移过来？如果前面学过的技能因为学了新东西而被遗忘，这个 Agent 还称得上“持续进化”吗？
带着这些问题去翻资料，会发现大多数评测只是“一次考试定成绩”，只要在同一批 prompt 上表现不错，就觉得模型能力很强。但在真实生产环境里，Agent 面对的永远是新的问题、新的流程、新的工具。所以把“持续技能学习”作为统一评测视角来审视 LLM Agent，是非常必要的。ContinualSkillBench 这个名字，其实就点出了这套思路：它想回答的不只是“这个模型强不强”，而是“LLM Agent 在持续任务流里，是否真正积累了可复用的能力”。
这篇文章会从概念出发，整理一套可落地的评估思路。我们会搭建一个接近 ContinualSkillBench 的三阶段评测流程，用代码实现一个可运行的简化版实验，并讨论如何解读指标、如何避免踩坑。新手可以通过这篇文章理解 LLM Agent 评估的基本框架，正在做 Agent 评测的同学也可以直接参考里面的实验代码和指标设计。
1. 背景与核心概念
要理解 ContinualSkillBench，先要理解两个基础词：LLM Agent 和 Continuual Learning。
1.1 从“会聊天”到“会干活”的 LLM Agent
LLM Agent 指的是以大语言模型为核心决策单元，具备观察环境、调用工具、执行动作、记忆状态等能力的系统。它不只是生成文本，而是可以完成一个又一个实际任务。
举个例子：
- 一个普通 LLM 对话框，你问“帮我查一下天气”，它只能给你一个文本回答。
- 一个 Agent 化应用，你问“帮我查明天的天气，如果降雨概率超过 50% 就提醒我带伞”，它可以完成多步动作：调用天气 API、查询概率、判断条件、设置提醒。
这背后通常有 ReAct、Plan-and-Execute、Reflexion 等提示词或框架设计。Agent 的价值在于“行动闭环”。
但是，Agent 能力和底层模型能力不是一回事。底层模型只需输出文本，Agent 还需要在大量状态中做出选择。比如“调用哪个工具”“参数填什么”“失败后重试几次”“历史记忆怎么整理”，这些都不是靠单次生成能解决的。
所以当我们在说“Agent 进化”时，实际指的是：这个系统在经历多个任务之后，是否形成了一套越来越强的决策习惯和工具使用能力。
1.2 持续学习与灾难性遗忘
Continual Learning 中文叫持续学习，也叫增量学习或终身学习。它研究的问题是：模型在依次学习多个任务时，如何做到“学新不忘旧”。
传统深度学习里有一个非常经典的问题——灾难性遗忘。也就是说，当模型在任务 A 上训练好，再拿去训练任务 B，它在任务 B 上表现提升，但回到任务 A 上可能“忘记”了以前的规律，表现大幅下降。
LLM Agent 也存在类似问题，但表现形式更隐蔽：
- Agent 可能在大量新任务中调整了提示词、调整了思维链模板，然后对旧任务的判断方式发生变化。
- Agent 内部缓存或短期记忆可能被新的上下文覆盖。
- 微调版本对模型权重造成影响，导致旧能力退化。
- 外部工具接口更新后，Agent 对新接口更熟悉，旧接口调用反而出错。
ContinualSkillBench 的核心，就是把这些问题放到一个可控的评测环境里，用一套标准流程去度量。
1.3 它和其他评测集有什么区别
我们常见的评测集有两种：
- 知识型评测：比如问历史、科学、数学题，核心是考察模型记住了多少知识。
- 推理型评测：比如代码生成、逻辑推理，核心是考察模型在给定输入下的推理质量。
这两种评测通常是“一次性”的。今天测 A 任务，明天测 B 任务，互不干扰。它们可以衡量模型当前的能力，但没法衡量“能力是否在持续增长”。
ContinualSkillBench 这类评测不一样，它的核心设定是“任务流”。模型不是只考一次，而是要经历多个阶段的持续学习，评测重点包括：
- 新技能是否真的获得。
- 旧技能是否被遗忘。
- 知识是否能迁移到新任务。
- 模型是“机械记忆”还是“抽象理解”。
简单总结：传统评测是“成绩单”，持续技能评测是“成长档案”。
2. 评估框架的核心维度
要设计一个接近 ContinualSkillBench 的评测，不能只做“前测后测”这么简单。我认为至少需要覆盖下面四个维度。
2.1 技能获取能力
在持续学习第一阶段，我们给 Agent 提供一批新任务。每个任务都会定义：
- 输入形式：用户问题、结构化数据、环境状态。
- 工具列表：Agent 可以调用的函数或 API。
- 预期输出：最终答案、动作序列、状态变化。
- 判断标准：精确匹配、规则匹配、模型打分。
技能获取能力就是看 Agent 在当前任务上的学习表现。如果 Agent 连新任务都没学会，那后面谈迁移和遗忘就没有意义。
注意这里的“学习”不一定是权重更新。对 LLM Agent 而言，学习更多表现为：
- 在上下文里积累了使用新工具的经验。
- 在长期记忆里保存了任务相关模板。
- 在系统 prompt 中动态调整了决策规则。
所以评测时要区分“模型本身能力”和“Agent 系统能力”，这一点后面会强调。
2.2 持续学习与抗遗忘能力
真实环境中的任务不是静态的。Agent 学完技能 A，接着学技能 B，然后可能又遇到技能 C，最后还要回头看 A。
这要求评测流程设计成多个连续轮次，而不是“每个任务独立测试”。比如：
- 第一轮只提供任务 A 的数据。
- 第二轮同时提供任务 A 和任务 B 的数据。
- 第三轮加入任务 C，并随机穿插 A、B、C。
之后在最终评测里，我们分别统计 Agent 在 A、B、C 三个任务上的表现，重点看旧任务上的衰减率。
如果 Agent 在任务 B 上学得很好，但任务 A 的准确率从 90% 掉到 50%，那就说明它存在严重的灾难性遗忘。
2.3 跨任务泛化能力
有些 Agent 表面上看每个任务都能完成，但实际上只是停留在“模式匹配”层面。比如在一个日历助手任务里，它学会了“明天”代表当前日期加一天；但如果换到另一个类似的日程安排任务，它还能不能把“昨天”“下周”等概念正确解析？
跨任务泛化要考察的点是：Agent 是否从单一任务中抽象出可复用能力，而不是死记硬背输入输出。
设计思路是“同族不同任务”。例如：
- 训练阶段任务：判断邮件是否紧急，优先级高/中/低。
- 测试阶段任务：判断工单是否紧急，优先级高/中/低/跳过。
两个任务结构相似，但领域不同。好的 Agent 应该能把“紧急度判断规则”迁移过去。
2.4 评测流程设计示意
这里用文字简单描述一个评测流程：
- 准备 N 个任务集合，每个任务包含训练样本和测试样本。
- 按顺序让 Agent 学习任务 A、B、C。
- 每学完一个任务，立即用当前 Agent 测试该任务的测试集。
- 所有任务学完后，再统一测试全部任务的测试集。
- 统计平均准确率、遗忘率、迁移增益。
这个流程不需要依赖复杂框架，用 Python 脚本就可以完成。
3. 环境准备与版本说明
下面我们开始构建一个简化版的持续技能评估实验。这套代码主要做两件事：
- 构造多个任务的数据。
- 调用外部大模型 API 让 Agent 逐任务“学习”并评测。
3.1 开发环境
我建议使用 Python 3.10 或 3.11，操作系统不限。本文示例基于以下环境：
- Ubuntu 22.04 / macOS / Windows 均可。
- Python 3.10+。
- OpenAI SDK 或其他兼容 OpenAI 接口的 SDK。
- 需要网络访问大模型 API。
由于不同版本之间接口差异较大，如果你使用的 SDK 版本较新，代码里少数参数需要微调，但整体思路不变。
3.2 安装依赖
创建一个虚拟环境并安装依赖。
python -m venv .venv source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate pip install openai>=1.0 pandas numpy pyyaml这里安装的库分别是：
openai：用于调用 GPT 系列模型接口。pandas、numpy：用于数据处理和指标计算。pyyaml：用于读取配置文件。
3.3 模型接口准备
你需要准备一个 API Key。如果使用 OpenAI 官方接口，可以设置环境变量：
export OPENAI_API_KEY="sk-xxxx"如果你的网络环境不能访问官方接口，可以使用国内云厂商或本地部署模型提供的 OpenAI 兼容接口。此时需要额外配置base_url和api_key。下面的代码会统一封装一个chat_completion函数，方便切换。
# file: config.py import os MODEL_NAME = os.getenv("EVAL_MODEL_NAME", "gpt-4o-mini") BASE_URL = os.getenv("EVAL_BASE_URL", "https://api.openai.com/v1") API_KEY = os.getenv("OPENAI_API_KEY", "") EVAL_TEMPERATURE = 0.0这里把temperature设置为 0，是为了降低模型输出随机性，让评测结果更稳定。真实评测中，你还需要对同一个样本多次采样取平均，后面会讲到。
4. 标准化三阶段评估实验
现在开始写核心实验代码。
4.1 实验任务设计
为了让实验更容易理解，我们构造两个同族任务和两个异族任务。
任务 A：邮件紧急度分类。
输入是一封邮件文本，输出是“紧急”或“不紧急”。这个任务很简单，适合作为首个技能。
任务 B：工单优先级分类。
输入是一段工单描述，输出是“P0”、“P1”或“P2”。这个任务和邮件紧急度分类结构类似，但优先级更多，用于观察跨任务迁移。
任务 C：SQL 查询生成。
输入是一个自然语言问题和一个表结构，输出是 SQL。这个任务和文本分类完全不同，用于观察新增异质技能对旧任务的影响。
每个任务都分为“训练样本”和“测试样本”。在持续学习评测里，Agent 先看到训练样本，然后再做测试。
4.2 构造数据
我们用代码生成一批简单的样本。
# file: data/tasks.py TASK_A_TRAIN = [ {"text": "服务器在凌晨宕机，需要立即处理", "label": "紧急"}, {"text": "本周四需要提交季度报告", "label": "不紧急"}, {"text": "客户投诉渠道无法访问", "label": "紧急"}, {"text": "请更新一下会议室预约名单", "label": "不紧急"}, {"text": "线上支付接口异常，大量订单失败", "label": "紧急"}, ] TASK_A_TEST = [ {"text": "数据库连接池耗尽，业务中断", "label": "紧急"}, {"text": "新同事入职资料准备", "label": "不紧急"}, {"text": "财务系统批量导出失败", "label": "紧急"}, {"text": "年度团建地点意见征集", "label": "不紧急"}, ] TASK_B_TRAIN = [ {"text": "所有用户无法登录系统", "label": "P0"}, {"text": "某页面加载较慢", "label": "P2"}, {"text": "导出报表数据缺失", "label": "P1"}, {"text": "多租户数据串号，属于严重事故", "label": "P0"}, ] TASK_B_TEST = [ {"text": "主服务崩溃，无法启动", "label": "P0"}, {"text": "上传文件偶尔失败", "label": "P1"}, {"text": "按钮样式错位", "label": "P2"}, {"text": "用户反馈偶发白屏", "label": "P1"}, ] TASK_C_TRAIN = [ {"question": "统计用户表中年龄大于30的人数", "schema": "users(id, name, age)", "sql": "SELECT COUNT(*) FROM users WHERE age > 30"}, {"question": "查询订单表中金额最高的前5个订单", "schema": "orders(id, user_id, amount)", "sql": "SELECT * FROM orders ORDER BY amount DESC LIMIT 5"}, ] TASK_C_TEST = [ {"question": "统计订单表中的总金额", "schema": "orders(id, user_id, amount)", "sql": "SELECT SUM(amount) FROM orders"}, {"question": "查询用户表中名字包含'张'的用户数量", "schema": "users(id, name, age)", "sql": "SELECT COUNT(*) FROM users WHERE name LIKE '%张%'"}, ]这只是一个示例，真实评测里样本量会大很多。但通过这个结构，你可以看到任务类型和评估思路。
4.3 封装模型调用
我们写一个简单的调用函数。这里以 OpenAI 兼容接口为例，重点看它如何把任务样本构造成 prompt。
# file: model_api.py from openai import OpenAI from config import MODEL_NAME, BASE_URL, API_KEY, EVAL_TEMPERATURE client = OpenAI(base_url=BASE_URL, api_key=API_KEY) def chat(messages): resp = client.chat.completions.create( model=MODEL_NAME, messages=messages, temperature=EVAL_TEMPERATURE, ) return resp.choices[0].message.content.strip()注意：不同版本 SDK 的参数名基本一致。如果使用的是老版本openai.ChatCompletion.create，则需要改为新写法。这里以openai>=1.0为例。
4.4 构建 Agent 的记忆机制
为了让 Agent 展示“持续学习”能力，我们使用一个很简单的上下文记忆机制：把训练样本中的正确答案以 few-shot 示例形式放进 prompt。
- 第一阶段，Agent 只携带任务 A 的训练示例。
- 第二阶段，Agent 携带任务 A 和任务 B 的训练示例。
- 第三阶段，Agent 携带任务 A、B、C 的训练示例。
这样模拟了一个“随着任务增加，Agent 的知识库逐步扩张”的过程。真实 Agent 可能会有向量记忆、长期记忆、外部知识库，但这里的思路是一致的。
# file: agent.py from model_api import chat def build_few_shot_examples(task_name, examples): if task_name == "A": lines = ["判断下面邮件是否紧急，只回答“紧急”或“不紧急”。"] elif task_name == "B": lines = ["判断下面工单的优先级，只回答 P0、P1 或 P2。"] else: lines = ["根据问题和表结构生成 SQL，只输出 SQL 语句。"] for ex in examples: if task_name in ("A", "B"): lines.append(f"输入：{ex['text']}") lines.append(f"输出：{ex['label']}") else: lines.append(f"问题：{ex['question']}") lines.append(f"表结构：{ex['schema']}") lines.append(f"SQL：{ex['sql']}") return "\n".join(lines) def predict_with_history(task_name, sample, history_prompt): if task_name in ("A", "B"): user_content = f"{history_prompt}\n\n输入：{sample['text']}\n输出：" else: user_content = f"{history_prompt}\n\n问题：{sample['question']}\n表结构：{sample['schema']}\nSQL：" messages = [ {"role": "system", "content": "你是一个擅长完成任务并给出精简答案的助手。"}, {"role": "user", "content": user_content}, ] return chat(messages)这里有一个很关键的地方：history_prompt是带历史知识的。Agent 在第三个阶段判断任务 A 时，也是带着任务 A、B、C 的示例去判断的。这样就模拟了“持续学习后的状态”。
4.5 编写评测主循环
评测分三轮进行：
第一轮：只用任务 A 训练示例，测任务 A 测试集。
第二轮：用任务 A + B 训练示例，测任务 A 和 B 的测试集。
第三轮：用任务 A + B + C 训练示例，测全部三个任务的测试集。
这样我们就能看到：
- 任务 A 的准确率是否随着任务增加而下降。
- 任务 B 引入后是否影响任务 A。
- 任务 C 引入后是否灾难性遗忘前面学到的东西。
# file: evaluate.py from data.tasks import TASK_A_TRAIN, TASK_A_TEST, TASK_B_TRAIN, TASK_B_TEST, TASK_C_TRAIN, TASK_C_TEST from agent import build_few_shot_examples, predict_with_history def evaluate(task_name, test_set, history_prompt): correct = 0 for sample in test_set: prediction = predict_with_history(task_name, sample, history_prompt) expected = sample["label"] if task_name in ("A", "B") else sample["sql"] if prediction and expected and prediction.strip().lower() == expected.strip().lower(): correct += 1 return correct / len(test_set) if __name__ == "__main__": # 阶段 1：只学任务 A history_a = build_few_shot_examples("A", TASK_A_TRAIN) acc_a_stage1 = evaluate("A", TASK_A_TEST, history_a) # 阶段 2：学任务 A + B history_ab = build_few_shot_examples("A", TASK_A_TRAIN) + "\n" + build_few_shot_examples("B", TASK_B_TRAIN) acc_a_stage2 = evaluate("A", TASK_A_TEST, history_ab) acc_b_stage2 = evaluate("B", TASK_B_TEST, history_ab) # 阶段 3：学任务 A + B + C history_abc = ( build_few_shot_examples("A", TASK_A_TRAIN) + "\n" + build_few_shot_examples("B", TASK_B_TRAIN) + "\n" + build_few_shot_examples("C", TASK_C_TRAIN) ) acc_a_stage3 = evaluate("A", TASK_A_TEST, history_abc) acc_b_stage3 = evaluate("B", TASK_B_TEST, history_abc) acc_c_stage3 = evaluate("C", TASK_C_TEST, history_abc) print("Stage 1: A acc =", acc_a_stage1) print("Stage 2: A acc =", acc_a_stage2, "B acc =", acc_b_stage2) print("Stage 3: A acc =", acc_a_stage3, "B acc =", acc_b_stage3, "C acc =", acc_c_stage3)这样就能跑出一个最基本的“任务流准确率”输出。
4.6 运行与预期结果
运行脚本的方式：
python evaluate.py预期输出可能如下：
Stage 1: A acc = 1.0 Stage 2: A acc = 1.0 B acc = 0.75 Stage 3: A acc = 0.75 B acc = 0.75 C acc = 1.0但需要注意，由于模型、prompt、数据量都很小，这个结果并不稳定。真实评测中，样本量和任务量都需要扩大，并且通常要跑多轮取均值。
5. 评价指标与结果解读
只打印准确率还不够，我们还需要把指标抽象出来。ContinualSkillBench 这类评估通常关注三个指标。
5.1 平均准确率（Average Accuracy）
平均准确率是所有任务准确率的算术平均。如果我们在第 k 阶段评测，此时已经训练了 k 个任务，那么平均准确率可以定义为：
Avg Acc_k = (1 / k) * sum(Acc_i_k)其中Acc_i_k表示在第 k 个训练阶段，模型在第 i 个任务上的准确率。
这个指标衡量的是 Agent 在当前阶段的总体能力。它的问题在于，如果后面学了很多简单任务，即使旧任务遗忘严重，平均分也可能被拉高。所以单个平均分不能说明“进化”。
5.2 遗忘率（Forgetting Rate）
遗忘率衡量旧任务表现下降了多少。
假设任务 i 第一次评测（即学完任务 i 后立刻评测）的准确率是Acc_i_base，最终阶段（学完所有任务后）的准确率是Acc_i_final，那么遗忘率可以定义为：
Forgetting_i = Acc_i_base - Acc_i_final遗忘率越大，说明灾难性遗忘越严重。一个真的能持续进化的 Agent，遗忘率应该很低，甚至可能出现负值，也就是旧任务能力因为学了新任务而提升了。
5.3 迁移增益（Transfer Gain）
迁移增益关注的是学习新任务之后，旧任务表现是否提升。也就是：
Transfer_i = Acc_i_after_new_task - Acc_i_base如果大于 0，说明正向迁移发生。如果小于 0，可能是干扰或遗忘。
这在 Agent 场景里很常见，比如 Agent 学会了一个更通用的工具调用模板，旧任务反而更稳定了，这就是正向迁移。
5.4 示例结果表
下面构造一张示例结果表，用来帮助理解指标解读。
| 阶段 | 任务 A 准确率 | 任务 B 准确率 | 任务 C 准确率 | 平均准确率 | 遗忘率(A) |
|---|---|---|---|---|---|
| 学习 A 后 | 90% | - | - | 90% | - |
| 学习 B 后 | 85% | 80% | - | 82.5% | 5% |
| 学习 C 后 | 60% | 75% | 70% | 68.3% | 30% |
从这个表可以看出，任务 C 加入后，任务 A 的准确率从 90% 掉到 60%，遗忘率高达 30%。这说明 Agent 在持续学习过程中没有很好地保持旧技能。
如果用 ContinualSkillBench 的视角来审视，这个 Agent 就不能被评价为“真正进化”，因为它只是学会了新任务，却丢掉了旧能力。
5.5 怎么判断“真正进化”
我个人建议看三个条件：
- 新任务准确率要高于随机或粗基线。
- 旧任务准确率下降幅度要在一个可接受阈值内，比如不超过 5%。
- 同类新任务应帮助旧任务提升，至少不能明显恶化。
只有同时满足这三个条件，才可以说 Agent 在持续学习中表现良好。
6. 常见问题与排查思路
在实现持续技能评估时，会遇到下面几类问题。
6.1 API 返回结果不稳定
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 同一份测试集跑两次，结果差异大 | 模型采样随机性、温度过高 | temperature 设置为 0，多次采样取多数投票 |
| 不同模型版本结果不可比 | 模型版本默认变化 | 固定 model 名称和时间戳，保存结果 |
| 输出格式经常多出解释性文字 | prompt 约束不够 | 在 prompt 中强调“只输出 XX”，并用后处理解析 |
6.2 数据泄漏导致分数虚高
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| Agent 在没见过样本的情况下准确率接近满分 | 训练样本被混入 prompt，成为测试集上下文 | 严格区分训练样本与测试样本 |
| 同一个文本在多个任务中出现 | 任务构造时复用数据 | 做文本去重和相似度过滤 |
| Agent 能从 prompt 历史里直接找到测试答案 | 历史示例里包含测试样本 | 只允许训练样本进入历史 |
6.3 小样本导致指标不可信
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 测试集只有 10 条，准确率波动非常大 | 样本量不足 | 每个任务至少准备 100 条以上测试样本 |
| 某条样本格式解析错误，整体准确率骤降 | 后处理规则太严格 | 增加容错，例如去除空格、大小写归一化 |
| 人类评估和自动评估差异大 | 任务本身具有主观性 | 使用双人标注或者模型 judge，并计算一致性 |
6.4 工具调用类任务评测困难
很多 Agent 任务并不是输出文本，而是调用工具。这时候精确匹配文本会失效，更推荐记录“动作序列”，然后判断动作顺序和参数是否合理。
你可以定义一个ToolCall结构，例如：
@dataclass class ToolCall: name: str arguments: dict评测时，将 Agent 的一串ToolCall与参考答案做序列匹配。如果只关注最终结果，也可以用结果状态来判断。
7. 从 Benchmark 到工程实践
这部分我想聊聊工程落地。ContinualSkillBench 不只是一个评测游戏，它反映的是真实 Agent 系统在长期运营中的稳定性问题。
7.1 不要把评测分数当作唯一目标
持续评测的最终目的是发现 Agent 的脆弱点。比如遗忘率很高，那么下一步应该调整记忆模块或者做定期回放，而不是继续堆更多提示词。
建议在项目里维护一个固定基准集，每次升级 Agent 结构或模型版本时都跑一遍完整评测。这个基准集要像单元测试一样长期维护。
7.2 数据隔离与权限控制
在执行持续评测时，要严格遵守数据隔离原则。
- 训练集、验证集、测试集分三个目录或三个 Python 包。
- 在使用外部大模型 API 时，注意不要将敏感业务数据直接发送到外部，必须经过脱敏和授权。
- 如果是生产环境变更，一定要先在测试环境验证，保存变更前后结果对比。
尤其在用 Agent 操作真实数据库、发送邮件、处理工单时，要加一层沙箱或审批机制。评测脚本本身只能调用只读接口，除非明确是破坏性测试，否则必须使用模拟环境。
7.3 日志与可复现性
建议把每次评测的以下信息记录下来：
- 模型名称和版本。
- prompt 模板版本（建议用 hash 记录）。
- 训练样本集合的版本。
- 测试样本集合的版本。
- API 调用结果原文。
- 后处理脚本版本。
这些信息存到 JSON 或 YAML 文件里，方便后续复盘。
7.4 评估成本控制
持续评估非常消耗 API 调用。比如 20 个任务，每个任务 200 条测试样本，每阶段都要测一遍，调用次数会指数级增加。
控制成本的方法有：
- 先用小样本快速验证，确定没有 bug 后再全量评测。
- 相同任务选择更便宜的模型做基准。
- 缓存历史回复，避免重复调用。
- 对 prompt 模板做 diff，只重跑受影响的阶段。
7.5 安全边界
如果 Agent 要执行真实操作，必须强调最小权限原则。例如：
- 数据库连接使用只读账号。
- 文件操作限制在临时目录。
- API 调用增加配额限制。
- 高风险操作需要人工审批。
持续评测的目的不是为了把 Agent 放到生产环境里“裸奔”，而是为了在受控环境中测量能力和风险边界。
8. 下一步学习路线与总结
通过这篇文章，你应该已经理解了 ContinualSkillBench 的核心价值：它用持续学习的方式评估 LLM Agent，不是看单次能力，而是看能力随时间的演化。
我们实现了最简版本的三阶段评测流程，覆盖了任务构造、上下文记忆、准确率/遗忘率/迁移增益等关键概念。你可以在此基础上扩展：
- 加入真实的工具调用模拟。
- 加入长期记忆模块。
- 加入多个模型对比。
- 把测试集扩展到更多领域。
如果你正在做 Agent 产品，我建议先把“技能定义”和“评估指标”固定下来，再谈模型选型和 prompt 优化。因为如果没有一套持续评测框架，你很可能会被个别样例的惊艳表现误导，等到线上遇到真实任务时才发现问题。
我的建议是：不要停留在“跑通流程”这一步，试着把遗忘率、迁移增益、数据泄漏检测都纳入日常评测流程。这样你手里的 LLM Agent 才更接近“真正进化”的状态。
如果你在实现过程中遇到其他问题，欢迎在评论区交流。也建议把这篇文章收藏，后面搭建 Agent 评测体系时可以随时对照。
)
