企业官网建设流程全解析

看到“ContinualSkillBench: Can LLM Agents Truly Evolve Their Capabilities?”这个题目时，我第一反应不是去找论文地址，而是想到一个很典型的工程场景：你花了一周时间，把某个 LLM Agent 的任务成功率从 50% 调到 85%，感觉很满意。第二周产品提了新需求，你加入一个新工具，结果 Agent 在旧任务上的表现立刻掉回 60%。你开始怀疑是提示词污染，还是模型上下文太长，还是工具调用顺序出了问题。但你很难证明它到底“退化”在哪一步。

这个场景，恰好是 ContinualSkillBench 这类题目真正想回答的问题：LLM Agent 能不能在持续接触任务的过程中，真正积累能力，而不是每次都在同一个水平线上反复横跳。

这篇文章不打算只复述一个基准的名字。我会从“Agent 能力进化到底意味着什么”出发，拆开这个题目背后真正的评测难点，再落到我们自己开发和使用 Agent 时能用上的判断标准、排查思路和工程建议。

1. 从单次成功率到持续演进，Agent 评测正在换问题

1.1 为什么“这次答得不错”不等于“能力变强了”

大多数人对 LLM Agent 的能力判断，来自单次任务的完成质量。输入一个问题，Agent 调工具、组织答案、输出结果，看起来对，那就认为它能力可以。这种判断方式很自然，但它混淆了两个完全不同的概念：单次执行的准确率，和系统能力的持续增长。

单次执行反映的是“在给定上下文和工具下，模型能不能处理当前请求”。它依赖提示词、示例、工具描述、上下文窗口里的历史信息，甚至模型当时的随机性。而能力进化意味着：Agent 在处理完一个任务后，留下来的东西不仅仅是一条日志，而是一种可复用的、能够迁移到未来任务中的技能。

举个例子。一个 Agent 第一次被要求把 Markdown 表格转成 CSV，它靠提示词里的示例勉强完成了。第二次再遇到类似转换，它不应该再从零开始学一遍，更不能因为上下文里没写示例就失败。真正的“能力变强”，是它对这类任务已经有了一种稳定的处理模式——要么固化成了工具脚本，要么形成了技能描述，要么至少学会了主动询问表格结构。

ContinualSkillBench 这个项目名里，最值得注意的词不是 Skill，而是 Continual。它把评测对象从“单任务能力”变成了“持续学习能力”，这完全是两个评估维度。

1.2 传统基准测的是“记忆”，不是“进化”

现在很多 Agent 基准，本质上测的是回忆能力，或者说是信息检索和指令遵循能力。给一个任务，看 Agent 能不能正确完成。任务之间通常彼此独立，没有依赖关系，前一题的结果不会影响后一题，Agent 也不需要从一个任务的经验中学习出通用方法。

这种评测有一个隐藏假设：所有任务都是静态的，Agent 的世界不会变化。但真实世界里，任务永远在变：业务规则会更新，工具接口会升级，用户提问方式会变化，数据分布会漂移。静态基准测不出 Agent 在这种环境下的稳定性，更测不出它能不能把旧经验迁移到新任务上。

所以在实践中，越来越多的人发现：一个 Agent 在 benchmark 上分数不低，但放进真实业务里用几周就越来越不靠谱。原因之一就是，它没有持续学习能力，也没有遗忘控制机制。我们看到的“变强”，经常只是外部给它堆了更多提示词和更多上下文，而不是它自己积累了能力。

如果一个基准真的叫 ContinualSkillBench，那么它的核心问题就不该是“Agent 能完成多难的任务”，而应该是：当 Agent 按顺序接触一系列任务后，它的技能库有没有变大，它在新任务上的表现有没有因为旧经验而变好，它在学新技能时有没有丢掉旧技能。

这是一个完全不同的评测逻辑，也更能反映一个 Agent 能不能在真实产品里长期存活。

2. 拆解“能力进化”：一个 Agent 要具备哪三种行为

2.1 经验固化：把一次性解法沉淀成通用技能

“进化”的第一步，是 Agent 能从一次具体任务中提取出可复用的东西。这一步在人类学习里很常见：你做过一次 PPT，下次再做就熟练了。但 LLM Agent 默认没有这个机制。

Agent 的每次调用，如果没有额外的记忆层、技能库或者外部存储，它面对新请求时，和第一次面对请求时没有本质区别。它所谓“变强”，只发生在单次对话内部：上下文里多了历史消息，它知道刚刚做过什么。但对话一结束，这个上下文就消失了。

所以如果一个 Agent 真的想持续演进，它至少需要做到：每次完成一个任务后，把这次解决过程中最有效的步骤、工具组合、判断规则记录成结构化信息。这种结构化的东西，可以是文档、脚本、配置文件，也可以是让它自己能检索的技能描述。

现实里，很多团队已经在这个方向做了半自动化的尝试。比如让 Agent 把一次有效的工具调用序列保存下来，下次遇到相似任务时先检索这个序列，再决定要不要复用。这种做法的本质，就是“经验固化”。

ContinualSkillBench 如果真的评估持续能力，它就应该设置一种场景：Agent 在任务 A 里成功解决了一个问题，任务 B 和它相似但不完全相同，看 Agent 会不会主动提取并迁移 A 的经验。如果 Agent 每次都表现得好像第一次见，那不管正确率多高，都不算有演进能力。

2.2 迁移复用：新任务可以调用旧技能

经验固化之后，下一步是迁移。所谓迁移，不是让 Agent 把旧回答原样抄过来，而是让它判断：旧任务里的哪个技能适用于当前新任务，哪些部分需要调整。

这其实是很多 Agent 框架最难做好的地方。因为模型天然擅长“基于上下文生成”，不擅长“主动去外部技能库检索”。你可以在系统提示词里写“请检索技能库”，但如果 Agent 没有真正形成结构化的调用习惯，这个指令不会稳定生效。

更好的做法，是让技能调用变成一种工具调用。把“查询技能库”“记录新技能”“更新旧技能”都设计成 Agent 可以主动调用的工具，而不是依赖它在自由文本里自动想起来。这样做的好处是：技能的使用和沉淀，都有了明确的触发条件和日志记录。

评估 Agent 是否真的在“进化”，关键指标之一就是它的迁移效率。同一个 Skill，如果 Agent 第一次需要 10 步才能完成，第二次在相似任务里只需要 6 步，第三次只要 4 步，那说明它真的有在积累。如果每次都是 10 步，说明它只是在重复执行，并没有形成能力。

2.3 遗忘控制：学会新技能不能丢掉旧技能

持续学习里有个经典问题叫灾难性遗忘。放在 AGI 语境下，这是常识；放在 Agent 里，很多人反而忽略了。

Agent 最常见的一种遗忘，不是模型权重被覆盖，而是上下文管理失控。比如为了支持新任务，团队往系统提示词里加了大量新规则和工具说明，结果把旧规则挤出了有效注意力范围；或者 Agent 的技能库越来越大，检索时总是命中最近加入的技能，旧技能被淹没。

另一种遗忘发生在工具层面。当 Agent 学会用新工具实现某个功能后，它可能不再优先调用旧工具，但旧工具在某些边界场景下仍然更可靠。如果没有明确的路由规则，Agent 可能会固定选新工具，导致旧场景质量下降。

所以真正的“技能保持”，不只是不丢失，还包括在正确场景里仍然选择正确的方法。ContinualSkillBench 如果要评测这一点，应该设计一种反向指标：Agent 在学会任务序列后半部分的新技能后，再回头测试前半部分的旧任务，看能力是否保持稳定。能做到这一点的 Agent，才算是真的在累积能力，而不是在翻滚记忆。

3. 从名字看 ContinualSkillBench 最可能评测什么

3.1 任务序列的设计方式

从“Continual”这个词来看，这个基准应该会采用“任务序列”而非“任务集合”。这跟传统评测有个很明显的差异：任务之间是有顺序、有依赖和有遗忘风险的。

我判断它的评测流程很可能是这样的：

1. 准备一系列彼此关联但难度递增的任务，覆盖若干个技能簇。
2. Agent 按顺序接触任务：先完成早期任务，再进入后期任务。
3. 中间可能会插入新的工具、新的约束或新的使用场景，模拟真实系统不断变化的状态。
4. 最后，不只评估 Agent 在最后一个任务上的表现，还要重新测试它在早期任务上的表现。

这种设计的意图，就是模拟真实产品生命周期：系统永远在加功能、改规则、换数据，但你不能因为加了新功能，就弄坏旧功能。

任务序列的难度设计也会很重要。任务不能只靠模型已有的常识完成，不然测不出“习得”过程。更合理的设计是：任务里包含一些需要 Agent 从历史交互中才能总结出来的规则，或者需要它通过工具调用才能发现的知识。这样，Agent 只能靠持续积累才能做得更好，而不是靠大模型预训练时已经知道的知识来“作弊”。

3.2 指标不只是准确率

评估一个持续学习系统，不能只盯着一个最终分数。传统的准确率指标是静态快照，而持续能力需要观察多个维度。

如果这是一个合格的持续技能基准，我预期它至少会追踪以下几类指标：

• 滚动准确率：每个阶段任务刚学完时的表现，反映的是“学习能力”。
• 反向迁移：学完后续任务后，回到旧任务上的表现。这个值如果下降，说明有遗忘。
• 正向迁移：接触早期任务的经验，是否让学习新任务的成本下降。这个值如果提升，说明技能有复用。
• 学习曲线效率：同一个技能簇内，Agent 完成新任务所需步骤、失败次数、重试比率是否随经验增加而下降。

这些指标合起来，才能回答标题里的问题：Agent 是不是真的在进化，还是仅仅在靠更大的上下文强撑。

顺便说一句，这也是为什么评价这类基准时要格外小心。如果它只看最终任务的准确率，那就很容易被提示词堆砌和长上下文掩盖问题。真正能说明持续能力提升的，是那些跨任务、跨时间的指标，而不是单点分数。

3.3 评估难点：怎么区分记忆复用和真正理解

我觉得这个基准最终面对的难点，不在于构造任务，而在于“归因”。

当一个 Agent 在后期任务里表现变好了，我们怎么知道它变好是因为学到了可迁移的技能，还是因为它只是把早期任务的答案记下来了？这两种情况，都给最终分数，但含义完全不同。前者是泛化，后者是记忆。

解决这个问题，通常需要设置一些“换皮任务”：表面形式变了，底层逻辑和早期任务相似。比如早期任务是处理 Markdown 表格，后期任务变成处理 JSON 数组；如果 Agent 只会记住格式，那它换皮后就扑街；如果它真理解了“把结构化数据转换成另一种结构化数据”的通用逻辑，它就能继续工作。

反过来，也要设置一些“相似但不可复用”的任务，防止 Agent 过度迁移。比如早期任务里某个规则只适用于特定业务域，后期任务看起来相似但规则相反。这时候 Agent 如果分不清边界，就会把旧规则错误地套到新任务上。这种错误，恰恰是 Agent 系统在真实业务里最多的问题——不是不会，而是乱套。

所以，持续技能评测的重点不是“难度”，而是“区分度”：能区分短期记忆、机械复用、真正理解和错误迁移。我们不能只看它成功了多少次，还要看它为什么会失败，以及它是怎么切换策略的。

4. 这类基准对 LLM 应用的落地价值

4.1 用来验证应用能否长期迭代

对很多团队来说，Agent 项目最危险的一刻，不是上线第一天，而是迭代三个月之后。功能越来越多，技能库越来越杂，系统提示词从 500 字膨胀到 5000 字，最后没有人能解释为什么某个旧功能忽然变差了。

ContinualSkillBench 这类持续评测的价值，正是给“长期迭代”踩一脚刹车。你可以用它来构建一套观察指标：把核心业务流程拆成若干任务序列，每次迭代后都跑一遍，追踪旧任务的表现有没有下降。这样发现问题就不再靠用户投诉，而是靠回归测试。

这其实和软件开发里的 CI/CD 回归测试逻辑一样。你改一行代码，不能只检查新功能，还要跑一遍旧用例。LLM Agent 应用更应该这样，因为它比传统代码更不稳定，更需要用评测来约束每一次改动。

但注意，这类基准的评估口径，通常是为研究场景设计的。放到自己的项目里，不要原封不动照搬，你需要先把自己的业务任务整理成“技能簇”，再定义“旧技能不退化”的阈值。这样才能让基准从论文工具变成工程工具。

4.2 Agent 框架里如何实现持续技能累积

如果你想让自己的 Agent 真正具备“技能累积”能力，不管外部基准叫什么，工程上最核心的一件事就是：把技能当作一等公民，而不是提示词的一部分。

我比较推荐的做法，是把技能拆成几个可管理的部分：

• 技能描述：说明这个技能解决什么问题、适用边界、调用条件。
• 技能流程：保存成可运行的模板、脚本或工具定义。
• 技能示例：保留一到两个代表性的成功和失败案例。
• 技能元信息：记录创建时间、调用次数、最近使用时间、成功率等。

然后让 Agent 通过工具主动管理技能库：遇到新任务时，先搜索技能库；完成后，判断是否有新技能需要记录；过程中，更新已有技能的使用统计。这样做最大的好处，是每一步都有日志，可以追踪 Agent 是在“成长”还是“重复”。

在实现时，可以用向量数据库存技能描述，用常规代码库存流程模板，再通过 Agent 的工具调用把它们串起来。技能搜索的召回质量很重要，因为它直接影响 Agent 是选择复用旧技能，还是宁可直接裸跑。

4.3 别等基准公布再补能力，先把日志和记录做起来

研究基准的正式结果我们还不清楚，但你可以立刻开始做一件事：给你的 Agent 加上技能使用日志。

现在的 Agent 框架，记录了太多对话消息，却太少记录工具级行为。你想要回答“Agent 有没有进化”，必须先能回答“Agent 上一次遇到相似任务时是怎么处理的”“它这次和上一次有什么不同”。

所以建议先建立这样的日志字段：

• 任务标识：一个任务属于哪个技能簇。
• 工具调用序列：完成任务的完整路径。
• 结果状态：成功、失败、部分成功、人工修正。
• 耗时和成本：调用次数、token 消耗、运行时长。
• 技能库命中情况：这次任务有没有检索到旧技能，有没有写回新技能。

有了这些日志，你才能在每周复盘时发现趋势：是不是某些工具组合越来越稳定？是不是技能库检索命中率在下降？是不是某类任务的失败路径一直没变？这些观察，比任何单一分数都更能说明 Agent 是否在进化。

5. 面向实践的排查链路与建议

5.1 如果我发现 Agent 后续任务越做越差，先按这个顺序查

这个问题很容易被误判成“模型变笨了”。实际上，模型权重没变，变的是 Agent 的外围状态。我从工程经验看，通常按以下顺序排查：

1. 先看输入历史：是不是上下文里积累了太多旧的工具输出，导致模型注意力被噪声稀释。最常见，先查。
2. 再看技能库检索：是不是新增技能后，检索排序把旧技能挤掉了，或者旧技能被误判为不相关。
3. 再看提示词结构：系统提示词是否被新规则平均化，旧规则还在，但优先级和明确性被削弱。
4. 再看工具定义：新工具和旧工具的名字、描述是否相似，模型可能误选新工具，导致旧场景行为变化。
5. 最后看评测任务本身：任务集合是否被污染，比如旧任务的期望答案已经不符合当前业务规则。

这个顺序的核心思想是：先隔离“模型本身的问题”，再检查“Agent 周边设施的问题”。大部分情况下，问题出在上下文和工具管理，而不是模型推理能力。

5.2 用一个小型“技能追踪”清单来评估自己的 Agent

你不一定非要跑完整的 ContinualSkillBench，但可以做一个简化版，用来评估自己的 Agent 是否具备持续能力。

建议准备 8 到 12 个任务，分成 3 个技能簇：

• 第一阶段：只让 Agent 完成 A 簇任务。
• 第二阶段：加入 B 簇任务，同时抽测 A 簇任务。
• 第三阶段：加入 C 簇任务，同时抽测 A、B 簇任务。

每个阶段记录四项数据：当前任务成功率、旧任务回归率、平均工具调用步数、人工修正次数。

判断标准很简单：

• 如果 B、C 加入后，A 的成功率明显下降，说明存在遗忘问题。
• 如果同一技能簇内，第二次出现类似任务时步数更少、成功率更高，说明经验固化有效。
• 如果新任务失败模式和旧任务高度相似，说明技能库没有形成有效抽象。

这个简易评测不严谨，但足够帮你在功能迭代时发现退化趋势，比“凭感觉觉得还行”可靠得多。

5.3 真正的进化可能发生在上下文之外

有一种情况需要注意。很多 Agent 在单次对话里表现得非常聪明：它会自我纠正、会回顾前面步骤、会主动调整策略。这很容易让人误以为它具备持续学习能力。但实际上，这只是模型在大上下文窗口里的短期推理能力。

真正的“持续技能”，必须发生在上下文之外。它一定要有一个外部化过程：把经验写进某个可检索的结构里，在下一个任务开始时能重新读取。没有这个外部化过程，再长的上下文也只是临时的，不会形成累积。

所以，在评估 Agent 的进化能力时，可以做一个“冷启动测试”：结束当前会话，清空上下文，只保留技能库记忆，然后让 Agent 处理一个和上个会话相似的新任务。如果它还能稳定触发相关技能，说明技能沉淀真的发生了。如果它表现得像失忆了一样，那说明它只是吃到了上下文红利，不是真正的进化。

这个测试虽然简单，却非常能说明问题。它在某种意义上也回应了标题：一个只能靠长上下文扮聪明的 Agent，和真正能把经验固化为技能的 Agent，相差的不是准确率，而是架构设计。

5.4 落地这类能力时的资源与边界判断

实现持续技能管理不是免费的，它有明显的资源成本和维护成本。

技能库的构建和清理需要投入人力。技能描述写得太具体，复用范围窄；写得太抽象，Agent 容易乱套。你需要像维护代码库一样维护技能库：定期删除失效技能，合并重复技能，标注哪些技能因为业务规则变化已经废弃。

检索成本也会随技能库变大而上升。技能多了以后，如果检索不做聚类和过滤，Agent 每次任务都要在无关候选上浪费时间，甚至被噪声干扰。常见做法是按技能簇索引，或者先做粗粒度路由，再在簇内做细粒度匹配。

最后还要控制 Agent 对技能库的“写权限”。不是每一次成功执行都值得变成永生技能。你要设置写入门槛：只有连续多次成功，或者经过人工确认，才能进入长期技能库。否则技能库很快就会变成垃圾堆，反倒是更大的负担。

所以，如果你问我这个基准能不能直接帮我们把 Agent 做得更好，我的回答是：它可以帮我们建立正确的观察维度，但真正让 Agent 进化起来的，仍然是工程上的技能管理设计。基准给出的是测量尺子，进化靠的是我们为 Agent 搭的那套积累机制。

ContinualSkillBench 这类题目最大的价值，是提醒我们停止用“单次成功”来安慰自己。Agent 能不能真正进化，取决于我们有没有为它设计一套从经验到技能的转化通道，以及一套能识别退化的评估方式。先把技能记录和回归测试做起来，比等待某个基准发布更有实际意义。