In-Context Learning 能力的真实边界：LLM 从上下文「学会」技能了吗？
Ctx2Skill 提出自演化的多 Agent 自博弈框架，从上下文中自动发现、提炼和选择技能——无需人工标注或外部反馈。核心问题：LLM 真的能从上下文中学习技能，还是只是模式匹配？
“In-context learning” 这个词在 2022 年之后几乎变成了 LLM 的核心卖点之一。GPT-3 论文中展示的 few-shot 能力——给模型几个示例，它就能执行新任务——让很多人相信 LLM 能够”从上下文中学习”。但这个叙事有一个被低估的裂缝：当上下文不是简单的输入-输出示例对，而是一份 50 页的技术规范或一套复杂的业务规则时，LLM 真的能从中”学会”如何执行吗？
Ctx2Skill（arXiv:2604.27660）直面了这个问题。它的核心发现是：单纯把长上下文塞给 LLM 不够——需要一个显式的”技能提取”过程，把上下文中隐含的规则和程序转化为可操作的自然语言技能描述。更有趣的是，这个技能提取过程本身不需要人工标注，可以通过多 Agent 自博弈（self-play）自动完成。
问题定义：Context Learning 不等于 In-Context Learning
先厘清一个概念混淆。业界常说的 “in-context learning”（ICL）通常指 few-shot prompting：给模型几个示例，模型推断出模式并应用到新输入。但 Ctx2Skill 讨论的是一个更难的问题：context learning——从一份长而复杂的上下文文档中学习解决问题所需的知识。
区别在于：few-shot ICL 的”上下文”是几个结构化的示例对，模式清晰可推断；而 context learning 的”上下文”是一份非结构化的长文档，规则隐含在叙述中，需要多步推理才能应用。
这是一个现实场景中的核心痛点。企业级 RAG 系统面对的典型挑战就是：检索到了相关文档，但 LLM 无法正确地从文档中提取并应用复杂规则。它可能漏掉某个条件、搞混操作顺序、或者”发挥”出文档中不存在的规则。
Ctx2Skill 的核心方案：推理时的技能增强
Ctx2Skill 的核心思路是一个中间步骤：不直接让 LLM 从原始上下文回答问题，而是先从上下文中提取”技能”（skills），再用这些技能指导 LLM 推理。
“技能”在这里的定义是：从上下文中提炼出的自然语言规则和程序描述。比如，面对一份复杂的退款政策文档，技能可能是：
- “如果购买日期超过 30 天且产品未开封，适用政策 A”
- “计算退款金额时，先扣除运费，再按比例折算”
- “连续退款超过 3 次的客户，需要人工审核”
这些技能将隐含在长文档中的规则显式化、可操作化。
但技能提取面临两个挑战：
- 标注成本：为长而复杂的文档手动标注技能成本极高
- 缺乏反馈：没有外部 oracle 告诉你提取的技能是否正确和完整
Ctx2Skill 的解决方案是一个多 Agent 自博弈循环——不需要人工标注或外部反馈，系统通过自我对弈发现技能。
多 Agent 自博弈：自演化的技能发现
自博弈循环包含三个 Agent：
Challenger：生成探测任务和评分标准。它的目标是发现当前技能集的盲区——如果 Reasoner 能轻松通过所有任务，说明 Challenger 不够”难”。
Reasoner：用当前技能集指导推理，尝试解决 Challenger 生成的任务。它的目标是应用技能正确完成任务。
Judge：提供二元反馈——Reasoner 的答案对还是错。不提供详细的错误分析（那是其他 Agent 的事）。
当 Reasoner 失败时，两个辅助 Agent 介入：
Proposer：分析失败案例，定位问题——是技能缺失？还是现有技能描述不够精确？还是技能之间有冲突？
Generator：基于 Proposer 的分析，合成新技能或更新现有技能。
关键设计：Challenger 和 Reasoner 双方都通过积累的技能演化。Challenger 那边的技能让它学会如何出更有区分度的题目；Reasoner 那边的技能让它学会如何更好地解决问题。这不是简单的”出题-解题”循环，而是双方共同演化。
Cross-time Replay：防止对抗崩塌
自博弈系统有一个已知的失效模式：对抗崩塌（adversarial collapse）。Challenger 为了让 Reasoner 失败，开始出越来越极端的题目；Reasoner 为了通过极端题目，开始积累过度特化的技能。最终双方都偏离了原始任务的分布——技能变得精确但脆弱，无法泛化到正常任务。
Ctx2Skill 引入 Cross-time Replay 机制来防止这种退化：
- 保留不同时间点的”代表性案例”
- 用这些代表性案例回测所有历史版本的技能集
- 选择在代表性案例上表现最均衡（而非最极端）的技能集作为 Reasoner 的最终输出
这类似于强化学习中的 population-based training 或 early stopping——不选择训练最久的模型，而选择泛化能力最好的模型。
评估结果：通用能力增强而非特定任务优化
论文在 CL-bench 的 4 个 context learning 任务上评估 Ctx2Skill，结果在不同骨干模型（backbone models）上一致提升了解题率。
几个值得注意的特性：
技能是可迁移的。Ctx2Skill 生成的技能不绑定特定 LLM——提取出来的技能可以插入（plug in）到任何语言模型，改善其 context learning 能力。这意味着技能是一种独立于模型的知识表征。
自动发现 vs 人工标注。没有人工介入的情况下，系统通过自博弈发现了有效的技能集。这证明了技能发现可以自动化，但也引出一个问题：自动发现的技能和人类专家提取的技能有多大差异？论文没有深入比较这一点。
长上下文是关键难度来源。任务涉及的上下文是”long, technically dense contexts”。这正是当前 RAG 系统在生产中面临的核心挑战——不是找不到相关文档，而是找到了之后无法正确推理。
对工程实践的启示
RAG 系统的中间层价值。当前主流 RAG 流程是”检索 → 拼接上下文 → 生成回答”。Ctx2Skill 提示了一个可能的改进方向：在检索和生成之间插入一个”技能提取”步骤。不是直接把原始文档塞给 LLM，而是先从文档中提取可操作的规则，再用规则指导推理。这对规则密集型任务（合规检查、政策执行、技术规范遵循）可能有显著价值。
自博弈作为评估生成器。Ctx2Skill 的自博弈循环本质上是一个自动评估生成器——它不断产出新的测试用例来暴露系统的弱点。这个思路可以借鉴到任何 LLM 系统的质量保证中：用一个 Agent 不断生成边界案例，用另一个 Agent 评判系统的表现，通过失败案例驱动系统改进。
技能集 = 可审计的中间表征。与黑盒的 ICL 不同，提取出的技能集是可读的自然语言，可以被人类审计和修改。这对需要可解释性的场景（金融、医疗、法务）有重要价值——你可以检查 LLM “学到了” 哪些规则，修正错误的规则，补充遗漏的规则。
局限和开放问题
技能粒度的选择。论文没有深入讨论技能的粒度——是一条规则一个技能，还是一组相关规则一个技能？粒度太细会增加检索负担，太粗会丧失精确性。在工程实践中，最优粒度可能取决于具体领域。
动态上下文的适应。Ctx2Skill 假设上下文是相对静态的——一份文档的技能提取一次就够了。但如果上下文持续变化（比如频繁更新的政策文档），技能集需要增量更新还是完全重建？
和长上下文窗口的关系。随着 LLM 的上下文窗口扩展到 100K+，“长上下文推理”是否仍然需要显式的技能提取？还是说足够大的窗口加上足够强的模型就能直接做 context learning？Ctx2Skill 的隐含论点是”不够”——即使窗口足够长，显式技能仍然有价值。但这个论点需要在更强的模型（如 Claude 4、GPT-5）上重新验证。
Ctx2Skill 的核心贡献不只是一个具体的框架，而是明确了一个观点：ICL 的”学习”不是自动发生的。把上下文塞给 LLM 不等于 LLM 学会了上下文中的知识。在简单模式（few-shot 示例对）下，推断是隐式的、够用的；但在复杂场景（长文档、多步规则、领域特定程序）下，需要一个显式的知识提取和组织步骤。
这对构建 RAG 系统的工程师意味着：如果你的场景涉及复杂规则的应用而不只是信息检索，“检索+生成”的两步流程可能不够。考虑在中间加一个”技能提取/规则提取”的步骤——无论是通过 Ctx2Skill 的自动方式，还是通过人工整理的结构化提示。
参考链接