这篇是对论文 Parametric Skills 的学习笔记。它和上一篇 Program-as-Weights 学习笔记 放在一起看，会出现一条非常清楚的技术主线：
过去：把能力写成 prompt / 文档 / skill，然后在运行时塞进上下文
现在：把能力编译成 LoRA / 参数模块，然后在运行时加载到模型里如果说 PAW 是“函数即权重”，那 Parametric Skills 更像是“技能即权重”。
它不是把一个具体模糊函数编译成小模型程序，而是把 Agent 的技能文档、过程经验、验证方法和失败模式压进 LoRA adapter。运行时，模型不需要在长上下文里读一大段 SKILL.md，再努力记住里面的关键步骤；它直接加载这个 skill adapter，让能力在参数空间里生效。
这句话听起来和 PAW 非常像。我的判断是：它们不是同一篇论文换个名字，但确实属于同一个范式迁移：从 text-space capability 到 parameter-space capability。
1. 先说什么是 skill
在 Agent 系统里，skill 通常不是一个普通函数，也不是一个工具 API。它更像一份“做事说明书”。
一个 coding agent 的 skill 可能长这样：
技能名称：修复 flaky test
什么时候使用：测试偶发失败、CI 不稳定、日志里有 timeout / race condition
步骤：
1. 先复现失败
2. 区分真实逻辑错误和环境抖动
3. 找共享状态、时间依赖、并发顺序、随机种子
4. 修改后必须重复跑测试
常见反模式：
不要直接增加 sleep
不要跳过测试
验证方式：
运行目标测试多次它描述的不是一个确定性操作，而是一套可复用的方法论：什么时候触发、怎么调查、怎么避免误修、怎么验收。
今天很多 Agent 框架会把 skill 当成文本上下文注入模型：
system prompt
+ developer instructions
+ task
+ retrieved skill documents
+ repo context
+ command outputs
→ model decides next action这很自然，因为 LLM 本来就会读文本。但问题也在这里：读到 skill，不等于真的会用 skill。
2. 文本 skill 的瓶颈：模型要在上下文里“找说明书、读说明书、照做”
文本 skill 的执行链路其实很重：
检索到相关 skill
→ 塞进上下文
→ 模型在长上下文里定位关键句
→ 理解触发条件和操作步骤
→ 在多轮任务里持续遵守
→ 遇到冲突信息时仍然不漂移这里每一步都会出问题。
第一，skill 会占上下文窗口。一个复杂 Agent 任务里，本来已经有代码片段、错误日志、用户要求、工具返回、历史决策，再塞几份长 skill 文档，注意力会被稀释。
第二，模型可能看见了但没用。尤其是小模型或长上下文任务，关键 instruction 很容易被淹没。它知道 skill 文档存在，但下一步行动仍然按自己的旧习惯走。
第三，skill evolution 和模型学习是脱节的。你可以不断改 SKILL.md，但模型权重并没有变。它每次还是临时阅读一份外部说明书，而不是把这份经验真正内化为行为倾向。
第四，多 skill 组合很难。一个真实 SWE 任务可能同时需要：
定位 bug
理解 API migration
修改配置
写回归测试
处理性能边界把多份 skill 文档全部塞进上下文，不但费 token，还会产生相互干扰。
Parametric Skills 正是针对这些问题来的。
3. 一句话理解 Parametric Skills
论文的核心链路是：
textual skill
→ hypernetwork
→ LoRA adapter
→ skill-conditioned LLM也就是：
一份技能文档
→ 一个参数生成器读进去
→ 生成一份 LoRA
→ 基座模型加载 LoRA 后执行任务这和普通 in-context skill 的差异很大。
In-context skill：
模型每次运行时读 skill 文档
Parametric skill：
hypernetwork 先把 skill 文档编译成 adapter
模型运行时加载 adapter，不再消耗上下文窗口如果用软件工程类比：
文本 skill = Markdown 说明书
parametric skill = 编译后的插件
base model = 宿主程序
hypernetwork = skill 编译器所以它不是简单地“压缩 prompt”。它想做的是：把技能的内容和使用方法一起压进参数空间，让模型不只是看到技能，而是更像装上技能。
4. 它和 PAW 到底是不是一回事？
先给结论：不是完全一回事，但思想同构。
两者都在做这件事：
文本态能力描述
→ 编译/参数化
→ LoRA 或 PEFT 工件
→ 推理时加载
→ 减少运行时 prompt 依赖但它们面向的对象不同。
| 维度 | Program-as-Weights | Parametric Skills |
|---|---|---|
| 编译对象 | 自然语言 fuzzy function spec | 文本 skill / Agent 过程经验 |
| 输出工件 | pseudo-program + per-function LoRA | per-skill LoRA adapter |
| 运行主体 | frozen lightweight interpreter | Qwen3-8B backbone |
| 目标 | 把模糊函数变成本地可执行小程序 | 把技能文档内化成可加载行为模块 |
| 典型输入输出 | input -> label / structured output | task context -> agent solution / patch / diagnosis |
| 重点收益 | 本地、便宜、可复用函数 | 长上下文鲁棒性、技能利用、多 skill 合并、自进化 |
PAW 的感觉更像：
urgent_filter = compile("判断邮件是否需要立即处理")
urgent_filter("Need signature by EOD")Parametric Skills 的感觉更像：
compile_skill("如何做 API migration")
compile_skill("如何修复 flaky test")
load_adapters([api_migration, flaky_test])
让 agent 解决一个复杂 repo 任务所以可以把二者放进同一张地图：
函数层：Program-as-Weights
技能层：Parametric Skills
经验层：self-evolving / continual parametric skill它们共同指向一个方向：LLM 应用不会永远把所有知识都塞进上下文窗口。很多可复用能力会逐渐从文本提示迁移到参数模块。
5. 系统结构：hypernetwork 是 skill 编译器
Parametric Skills 采用 hypernetwork-driven text-to-LoRA。
Hypernetwork 的意思是：一个网络负责生成另一个网络的权重。这里它接收 skill 文档，输出 LoRA 参数。
简化成伪代码：
skill_text = read("SKILL.md")
skill_embedding = text_encoder(skill_text)
lora_weights = hypernetwork(skill_embedding)
model_with_skill = base_model + lora_weights
answer = model_with_skill(task)论文里强调一个关键点：一旦 hypernetwork 训练好，生成新 skill adapter 只需要一次 forward。
这意味着部署时不需要：
不需要为每个 skill 收集专门训练数据
不需要对 base model 做梯度更新
不需要每次调用都把 skill 文档塞进上下文这点和 PAW 很像。PAW 里 compiler 读函数规格，生成 program adapter；这里 hypernetwork 读 skill 文档，生成 skill adapter。
6. 训练数据：不是只拿 Markdown 压缩，而是围绕 skill 构造执行轨迹
这篇论文的重点之一，是它不只训练 hypernetwork “复述 skill 文档”。它还要训练模型“会用 skill”。
论文的数据构造分几步。
6.1 收集 skill 文档
Skill 来源有两类。
第一类是公开技能文档和开发者生态里的文本资源，比如 skill repository、npm、GitHub 等。
第二类更有意思：从成功的 agent 执行轨迹里提炼 skill。也就是一个 agent 真的解决了某个任务，论文再把这个过程总结成可复用方法：
原始轨迹
→ 提取定位步骤、修改策略、验证信号
→ 生成候选 skill
→ 过滤低质量、不通用、不够可操作的样本最终论文保留了 45.8K 个高质量、可复用 skill，覆盖 13 个领域，包括 software、AI & LLM、security 等。
这个设计很关键。因为真正有价值的 skill 往往不是“写一段漂亮说明”，而是来自闭环任务经验：
哪里出错
怎么定位
尝试了什么
为什么这样改
怎么验证
哪些坑不要踩这比普通 prompt library 更接近工程经验库。
6.2 构造单轮 skill-use 样本
有了 skill 文档后，论文为每个 skill 构造单轮使用样本。
这类样本大概分两类：
短 QA 风格：
文件路径、代码片段、错误日志、配置片段
训练模型识别 skill 何时触发，以及如何做一个小范围动作
真实 agentic 场景：
repo 级请求、更长上下文、多约束、干扰信息
训练模型在嘈杂输入里稳定执行核心 skill这一步是在训练“技能激活”和“技能应用”。
6.3 构造多轮 skill-exploitation 轨迹
真实 Agent 任务通常不是一问一答，而是多轮交互：
用户先给一个错误现象
模型查看文件
用户补充日志
模型修改代码
测试失败
模型重新定位
最后验证通过论文用 OpenCode sandbox 生成真实 agent session，把任务信息、约束、证据逐步暴露出来。模型需要在多轮里保持 skill 相关上下文和过程一致性。
这一步很重要，因为它把 Parametric Skills 和普通 text-to-LoRA 拉开了：它训练的不只是“skill 文档内容压缩”，而是“在真实任务轨迹中利用 skill 的行为方法”。
7. 训练目标：先学会压缩技能，再学会使用技能
论文把训练分成两个主要阶段。
7.1 Skill-reconstruction pretraining
第一阶段让 hypernetwork 学会把 skill 文档编码进 LoRA。
它用了三类自监督目标：
- 完整重构：给完整 skill 文档，生成 adapter，让模型重构整个文档。
- 前缀补全：只给 skill 的前半部分或某个 section 前缀，让模型补出完整内容。
- section-level component completion：随机挖掉某个功能 section，让模型根据其他 section 和缺失 section 名称补出来。
第三个目标很有意思。它逼 hypernetwork 学到 skill 内部结构：
触发条件
执行步骤
失败处理
验证检查
反模式之间的关系，而不是把 skill 当成一坨文本压缩。
7.2 Skill-exploitation fine-tuning
第二阶段才是真正让模型“会用技能”。
每个训练样本是：
textual skill + supervised skill exploitation trajectory训练目标从“重构 skill 文档”变成“生成能诱导正确行为的 adapter”。
这个阶段覆盖：
规划
上下文检查
工具使用
代码修改
验证
多轮证据整合所以这篇论文最值得注意的地方是：它不是把 SKILL.md 做无损压缩，而是把“如何利用 skill 完成任务”的方法学压进 adapter。
8. 多 skill 合并：从上下文拼接变成参数合成
真实任务经常要用多个技能。
文本方案通常是：
把多个 SKILL.md 都塞进 context
让模型自己读、自己权衡、自己组合Parametric Skills 的方案是：
skill A -> LoRA A
skill B -> LoRA B
skill C -> LoRA C
推理前合并 adapter论文用的是 update-space rank-concat merge。直觉上，不是直接把 LoRA 的 A/B 因子粗暴相加，而是在 LoRA 有效更新空间里组合，并对每个 adapter 的更新范数做校准，避免某个高范数 adapter 因为尺度太大而压过其他 skill。
可以把它理解成：
不是把多份说明书丢给模型读
而是把多个插件按权重装到模型上实验上，在 529 个需要多 skill 的 SWE 任务里，rank-concat merge 的 LLM judge 平均分是 60.12，高于 single parametric skill 的 58.27，也明显高于 base model 的 12.44。
这个结果说明：参数空间的 skill composition 至少有初步可行性。
9. 自进化：文本里改 skill，参数里验证 skill
论文还提出了一个 self-evolving parametric skill loop。
流程大概是：
任务进来
→ skill generator 生成初始文本 skill
→ hypernetwork 编译成 LoRA
→ model 加载 LoRA 解题
→ verifier 判断是否通过
→ 如果失败，把反馈写回文本 skill
→ 重新编译成 LoRA
→ 重复直到通过或达到轮数上限这里的关键设计是：skill 的编辑仍然发生在 text space，skill 的验证和执行发生在 parameter space。
为什么不直接在参数空间改 LoRA？因为文本更容易被人和 LLM 修改：
补充边界条件
增加验证步骤
修正反模式
删掉误导性策略但最终是否有效，要看编译成 adapter 后模型能不能更好地完成任务。
论文在 HumanEval 上做了一个测试：初始生成的 base parametric skill 只有 123/164 正确，低于 no-skill 的 133/164；但经过 self-evolution 后提升到 139/164，也就是 84.76% pass rate。
这个结果很有启发：初始 skill 质量不一定可靠，但“文本修 skill + 参数执行 skill”的循环可以把它往可用方向推。
10. 持续学习：把成功经验合并成 global parametric skill
更进一步，论文提出 online continual accumulation。
每完成一个任务，如果 verifier 接受结果，就把这次成功轨迹总结成 skill，再编译成 parametric skill，然后并入一个 global LoRA。
简化流程：
task_i 成功
→ 总结 task_i 的经验成文本 skill
→ 编译成 task_i LoRA
→ 范数归一化
→ 以 EMA 合并进 global LoRA推理下一个任务时，模型同时使用：
当前任务的 task-specific skill
+ 累积经验的 global skill论文在 HumanEval 子集上报告：
Base model：9 / 31，29.03%
Independent self-evolution：12 / 31，38.71%
Online continual merge：16 / 31，51.61%这还只是初步实验，但方向很重要。它把“Agent 从经验里成长”这件事，具体落到了一个可操作的参数空间记忆上。
今天很多 Agent 的所谓学习，其实是：
把经验写进日志
把总结存进向量库
下次检索出来塞进 promptParametric Skills 想进一步走到：
把成功经验变成 adapter
把 adapter 合并成 global skill
让模型的行为本身产生增量变化这就是它比普通 skill retrieval 更激进的地方。
11. 实验结果怎么读
论文主实验使用 Qwen3-8B 作为 backbone，hypernetwork 采用 SHINE 架构，并从 SHINE checkpoint 初始化。
评估是六类复杂 SWE 任务：
Feature / Patch
Robustness Fix
Refactor / API Migration
Performance / Data
Diagnosis / Search
Configuration / Integration对比三类 baseline：
No-Skill：不给 skill
In-Context：把文本 skill 放进上下文
SHINE：用 SHINE 生成 parametric skill平均结果是：
No-Skill judge：50.21
SHINE judge：48.48
In-Context judge：57.65
ParametricSkills judge：64.09也就是说，文本 skill 确实有帮助：In-Context 比 No-Skill 高 7.44 分。但 ParametricSkills 又比 In-Context 高 6.44 分。
这个结果对应了论文的核心主张：
skill 不只是要被看到
skill 还要被模型稳定地执行把 skill 放进上下文能提供信息；把 skill 编译成 adapter，可能更像改变模型执行任务的行为倾向。
不过这里也要保守读。主指标之一是 LLM judge score，虽然论文同时报告了 F1 和 BERT Score，但 SWE 任务的真实工程质量仍然很难完全靠这些指标刻画。这个结果足以说明方向有潜力，但还不是“生产级 Agent 技能系统已经解决”的证据。
12. 和 PAW 放在一起看：从 prompt 工程到参数工程
上一篇 PAW 让我形成一个判断：未来 LLM 应用不会只有两种东西：
传统代码
大模型 prompt中间会出现越来越多“可加载的神经工件”：
函数 adapter
技能 adapter
记忆 adapter
风格 adapter
领域 adapterPAW 和 Parametric Skills 正好给了两个落点。
12.1 PAW：把模糊函数变成 adapter
PAW 解决的是高频 fuzzy function：
输入一条日志，输出是否报警
输入一个 query 和候选结果，输出相关性
输入一个坏 JSON，输出修复版本它的目标是让这类函数像普通软件函数一样：
便宜
本地
可版本化
可重复调用12.2 Parametric Skills：把做事方法变成 adapter
Parametric Skills 解决的是 Agent 的技能利用问题：
如何做 repo 级 bugfix
如何做 API migration
如何做配置集成
如何处理性能和数据问题它的目标是让模型不只是临时阅读一份技能文档，而是在行为层面更稳定地利用这份技能。
12.3 它们共同反对“所有东西都塞上下文”
现在很多 LLM 应用的默认做法是：
有知识？塞 prompt。
有规则？塞 prompt。
有经验？塞 prompt。
有工具说明？塞 prompt。
有 skill？塞 prompt。这在早期很方便，但不是长期工程形态。上下文窗口会变长，但注意力、成本、稳定性和可控性不会自动解决。
PAW 和 Parametric Skills 的共同判断是：
可复用能力不应该每次都以文本形式被重新解释。
一部分能力应该被编译、缓存、加载和组合。这就是从 prompt engineering 到 parameter engineering 的变化。
13. 工程上怎么想：哪些 skill 适合参数化？
不是所有 skill 都应该变成 LoRA。
我会用四个条件判断：
13.1 高频使用
如果一个 skill 很少被用，参数化意义不大。直接文本注入就够了。
适合参数化的是：
每天大量触发
不同任务反复复用
成本和上下文占用明显的技能。
13.2 行为复杂但边界可验证
比如：
修复 flaky test
做 API migration
分析错误日志并定位代码
根据项目规范生成 patch这些不是一条规则能写完，但有明确验收方式：测试通过、编译通过、diff 合理、lint 通过。
如果一个 skill 的结果不可验证，参数化后反而更危险，因为你更难解释它为什么这么做。
13.3 文本 skill 太长或容易被忽略
如果 skill 只有三句话，没必要参数化。
但如果 skill 包含：
触发条件
多步流程
常见失败模式
验证 checklist
工具调用顺序
环境约束并且经常在长上下文里被模型漏掉，那参数化就有价值。
13.4 可以接受 adapter 版本管理
参数化 skill 不再是纯文本。它会产生一个权重工件：
flaky-test-skill-v1.lora
api-migration-skill-v3.lora
repo-diagnosis-global-skill.lora这意味着工程系统要处理：
版本
回滚
A/B test
安全扫描
失效样本
adapter 组合如果团队没有这些管理能力，先用文本 skill 更实际。
14. 局限和风险
Parametric Skills 很有意思，但同样不能过度解读。
14.1 它依赖 skill 数据质量
论文自己也说，skill library 和 fine-tuning trajectories 还能继续 scale。参数化不是魔法。如果输入 skill 本身质量差、过于任务特化、含有错误经验，生成的 adapter 也会继承这些问题。
这和人类学习很像：把错误经验内化，比临时看错说明书更危险。
14.2 它目前依赖 SHINE checkpoint
论文限制里明确提到，当前 ParametricSkills 依赖预训练的 SHINE checkpoint。也就是说，这还不是一个从零开始完全独立验证的成熟系统。后续需要看更大规模 hypernetwork、更不同 backbone、更不同任务域上的复现。
14.3 参数化 skill 更难审计
文本 skill 可以直接 review：
这句 instruction 是否危险？
这个步骤是否错误？
这个验证方式是否充分？LoRA adapter 则不直观。你可以测试它，但很难像读 Markdown 一样理解它。
所以实际工程里，parametric skill 最好保留源文本和生成记录：
source skill text
adapter hash
compiler/hypernetwork version
training/evolution trace
eval report
known failure cases否则后期排查会很痛苦。
14.4 多 skill 合并可能有干扰
论文展示了 rank-concat merge 的初步效果，但真实场景里 skill 之间可能冲突：
一个 skill 要保守修改
另一个 skill 要大范围重构
一个 skill 要优先性能
另一个 skill 要优先可读性参数空间合并不等于语义无冲突。未来需要更强的 adapter routing、conflict detection 和任务级选择机制。
14.5 持续学习有分布漂移问题
论文也指出，长期迭代的 distribution shift 还没有解决。Global LoRA 如果不断吸收经验，可能会学到偏见、过拟合某类任务，或者把偶然成功的坏策略固化进去。
所以 online continual merge 必须有强验证和回滚机制。不能因为一个任务通过，就无脑写进长期参数记忆。
15. 我对这篇论文的判断
这篇论文最重要的价值，不是证明“参数化 skill 已经可以替代所有 SKILL.md”，而是把 Agent 技能系统从文本工程推进到了参数工程。
我会这样定级：
研究方向：很重要
和 PAW 的关系：高度同构，不是同一任务
实验验证：比概念 demo 强，但仍偏早期
工程成熟度：还需要工具链
最值得关注：多 skill 合并和经验累积
最大风险：不可解释、难审计、长期漂移如果站在 AI Infra 视角，我觉得可以把它和 PAW 合并成一个更大的趋势：
可复用认知能力正在从上下文窗口迁移到参数模块。过去我们把能力写进 prompt：
请遵守这个规则
请按照这个流程
请参考这个经验未来一部分能力会变成：
load_adapter("json-repair")
load_adapter("flaky-test-debugging")
load_adapter("api-migration")
load_adapter("company-code-style")这不代表 prompt 会消失。Prompt 仍然适合一次性任务、低频技能、需要人类可读控制的场景。但对于高频、复杂、可验证、可复用的能力，参数化会越来越有吸引力。
16. 最后一句话
Parametric Skills 和 Program-as-Weights 讲的是同一个大方向的两个侧面：
PAW：把函数从 prompt 里拿出来，编译成权重程序。
Parametric Skills：把技能从上下文里拿出来，编译成权重插件。它们共同说明一件事：下一阶段的 LLM 工程，不只是写更好的 prompt，而是要学会管理、组合、验证和演化这些可加载的神经能力模块。