In-Context Learning 能力的真实边界：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——从一份长而复杂的上下文文档中学习解决问题所需的知识。

graph LR
    subgraph icl["传统 In-Context Learning"]
        E1["示例 1: 输入 -> 输出"]
        E2["示例 2: 输入 -> 输出"]
        E3["示例 3: 输入 -> 输出"]
        Q["新输入 -> ?"]
    end

    subgraph cl["Context Learning (本文)"]
        DOC["50 页技术规范<br/>复杂业务规则<br/>多步骤程序"]
        TASK["基于文档的<br/>推理/执行任务"]
    end

    icl --> |"LLM 擅长"| OK["准确率高"]
    cl --> |"LLM 挣扎"| HARD["准确率低<br/>遗漏规则<br/>步骤出错"]

    style icl fill:#d3f9d8,stroke:#2f9e44
    style cl fill:#ffe3e3,stroke:#c92a2a
    style OK fill:#d3f9d8,stroke:#2f9e44
    style HARD fill:#ffe3e3,stroke:#c92a2a

区别在于：few-shot ICL 的”上下文”是几个结构化的示例对，模式清晰可推断；而 context learning 的”上下文”是一份非结构化的长文档，规则隐含在叙述中，需要多步推理才能应用。

这是一个现实场景中的核心痛点。企业级 RAG 系统面对的典型挑战就是：检索到了相关文档，但 LLM 无法正确地从文档中提取并应用复杂规则。它可能漏掉某个条件、搞混操作顺序、或者”发挥”出文档中不存在的规则。

Ctx2Skill 的核心方案：推理时的技能增强

Ctx2Skill 的核心思路是一个中间步骤：不直接让 LLM 从原始上下文回答问题，而是先从上下文中提取”技能”（skills），再用这些技能指导 LLM 推理。

“技能”在这里的定义是：从上下文中提炼出的自然语言规则和程序描述。比如，面对一份复杂的退款政策文档，技能可能是：

• “如果购买日期超过 30 天且产品未开封，适用政策 A”
• “计算退款金额时，先扣除运费，再按比例折算”
• “连续退款超过 3 次的客户，需要人工审核”

这些技能将隐含在长文档中的规则显式化、可操作化。

但技能提取面临两个挑战：

1. 标注成本：为长而复杂的文档手动标注技能成本极高
2. 缺乏反馈：没有外部 oracle 告诉你提取的技能是否正确和完整

Ctx2Skill 的解决方案是一个多 Agent 自博弈循环——不需要人工标注或外部反馈，系统通过自我对弈发现技能。

多 Agent 自博弈：自演化的技能发现

graph TB
    subgraph loop["自博弈循环"]
        CH["Challenger<br/>生成探测任务 + 评分标准"]
        RE["Reasoner<br/>用当前技能集尝试解决"]
        JU["Judge<br/>提供二元反馈 (对/错)"]
    end

    subgraph evolve["技能演化"]
        PR["Proposer<br/>分析失败案例"]
        GN["Generator<br/>合成新技能/更新旧技能"]
    end

    subgraph safety["对抗崩塌防护"]
        CR["Cross-time Replay<br/>跨历史版本回测<br/>选择最佳平衡点"]
    end

    CH --> |"任务"| RE
    RE --> |"答案"| JU
    JU --> |"失败"| PR
    PR --> |"改进方向"| GN
    GN --> |"更新技能集"| CH
    GN --> |"更新技能集"| RE

    CR --> |"防止过拟合"| RE
    CR --> |"防止极端化"| CH

    style loop fill:#e5dbff,stroke:#5f3dc4
    style evolve fill:#ffe8cc,stroke:#d9480f
    style safety fill:#d3f9d8,stroke:#2f9e44

自博弈循环包含三个 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 机制来防止这种退化：

1. 保留不同时间点的”代表性案例”
2. 用这些代表性案例回测所有历史版本的技能集
3. 选择在代表性案例上表现最均衡（而非最极端）的技能集作为 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 系统在生产中面临的核心挑战——不是找不到相关文档，而是找到了之后无法正确推理。

对工程实践的启示

graph LR
    subgraph traditional["传统 RAG 流程"]
        direction LR
        TR1["检索文档"] --> TR2["拼接上下文"] --> TR3["生成回答"]
    end

    subgraph enhanced["Ctx2Skill 增强流程"]
        direction LR
        ER1["检索文档"] --> ER2["技能提取<br/>(自动/预计算)"] --> ER3["技能指导推理"] --> ER4["生成回答"]
    end

    traditional --> |"复杂规则场景<br/>准确率不足"| FAIL["遗漏条件<br/>步骤出错"]
    enhanced --> |"显式规则化"| OK["规则完整覆盖<br/>可审计"]

    style traditional fill:#ffe3e3,stroke:#c92a2a
    style enhanced fill:#d3f9d8,stroke:#2f9e44
    style FAIL fill:#ffe3e3,stroke:#c92a2a
    style OK fill:#d3f9d8,stroke:#2f9e44

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 的自动方式，还是通过人工整理的结构化提示。

---

参考链接

• From Context to Skills: Can Language Models Learn from Context Skillfully?
• CL-bench: A Benchmark for Context Learning
• Language Models are Few-Shot Learners (GPT-3)