你的Agent跑通了50个任务。每次成功之后，你把经验写成一份Skill.md，存进技能库。日积月累，库里有30份技能。你很满意。
然后来了一个新任务。Agent检索了一圈——没有完全匹配的技能。于是它从零开始，像从来没学过任何东西一样，重新探索。
这就是平铺技能库的毛病。你存了30份经验，份份孤立。谁跟谁都没关系。“找苹果→洗苹果→放桌上"和"找土豆→洗土豆→热土豆→放桌上”，明明共享了"找"“洗”"放"三个动作，但在平铺库里，它们是两份独立的文档。Agent看不见它们之间的关联。
中科院自动化所和上海AI实验室联合发了一篇论文，叫SKILLPYRAMID。它做的事就是把这个平铺的技能库，变成一座能自己长高的金字塔。
一、平铺技能库的三个死穴
在SKILLPYRAMID之前，Agent技能管理的基本模式是：写一份Skill.md → 存档 → 遇到新任务 → 检索 → 找到就复用，找不到就自己探索 → 探索成功后再写一份新的Skill.md。循环。
这种方式有三个问题，而且越往后越严重：
第一，经验没法跨任务迁移。找苹果→洗→放"和"找土豆→洗→热→放，人一眼就能看出它们共享了定位目标→拿起→清洗这个底层能力。但在平铺库里，这个共享能力没有被显式提取出来。来一个找番茄→洗→切片→放的新任务，Agent检索不到匹配的技能，只能从零开始。尽管它明明已经学会了"找"和"洗"和"放"。
第二，技能越存越多，冗余越来越重。每学一个新任务多一份技能。30个任务30份独立文档。这些文档里大量步骤描述互相重复 —— 只是换了不同的物体名称。冗余不只是浪费 Token，更烦的是让检索变慢、让 Agent 在相似技能之间犹豫。
第三，技能库不会自己进化。你今天写的技能是基于今天的模型、今天的工具、今天的环境。三个月后模型升级了、API改了、任务的边界变了，你的30份技能没有人去更新。它们从资产慢慢变成负债 —— Agent 检索到一份半过期的技能，照着做反而走弯路。
图1 扁平技能库与SKILLPYRAMID对比
二、SKILLPYRAMID 的核心设计：把技能库建成一座金字塔
SKILLPYRAMID的灵感很朴素：技能之间天然有层级关系。底层是可复用的原子动作，中层是组合模式，高层是抽象的任务框架。把这些层级关系显式挖出来，技能库就能从"一堆文件"变成"一个能自己长高的结构"。
具体来说，框架由两个核心Agent和一个自演化机制组成。
图2 SKILLPYRAMID框架概览
2.1 Relation Analyzer：谁跟谁有关系，什么关系
Relation Analyzer的任务是扫描现有技能库，找出哪些技能之间可以建立复用关系。它用了一个从粗到细的两阶段策略来避免全库扫描的噪音和成本：
粗分组：先只看每份技能的名称和简短描述。把功能相近、任务范围相似、有潜在复用可能的技能分到一组。找苹果→洗→放和找土豆→洗→热→放在这一步就会被分到同一组。
细分析：对每个粗分组，打开每份技能的完整内容，深入分析到底存在什么关系。这一步输出的是结构化的关系构建任务—— 指定了哪些技能跟哪些技能有什么关系、关系类型是什么、有什么证据。
2.2 Relation Builder：把关系变成金字塔的砖和梁
Relation Builder接收Analyzer的分析结果，实际执行两种构建操作：
向下原子提取（Downward Atomic Extraction）。从一组技能中提取它们共享的最小可复用能力。比如找苹果→洗苹果→放桌上和找土豆→洗土豆→热土豆→放桌上，共享的底层能力是三个原子技能：“定位并获取目标物体”“清洗目标物体”“放置目标物体”。提取出来的原子技能放在金字塔的更低一层 —— 它们是更细粒度、更不绑定具体任务的构件。同时，原来的技能会被重写，在关键步骤显式引用原子技能：[reuse skill: acquire-object \| when: need to locate and pick up target \| provides: agent has target in hand]。
向上抽象归纳（Upward Abstract Induction）。从一组技能中提取它们共享的高层解题模式。比如找→拿→处理→放这个模式，在清洁任务、烹饪任务、整理任务中反复出现。抽象技能不写具体的动作步骤（“拿起苹果”），而是写结构化的任务框架（“阶段一：获取目标物体。阶段二：对目标施加状态转换。阶段三：验证转换结果。阶段四：放置到指定位置”）。抽象技能放在金字塔的更高一层——它们提供的是可泛化的解题结构，不是僵化的执行步骤。
金字塔建成后，原始技能被改写——它们显式声明了对原子技能和抽象技能的依赖关系。技能不再是一份份孤立的文档，而是一张有层级、有引用、有方向的图。
2.3 任务驱动的Skill Creator：不检索，而是组合
金字塔建好之后，遇到新任务就不是检索→找到匹配→复用的逻辑了。
Skill Creator分两步工作：首先，框架构建（Framework Construction），先用抽象技能勾勒出任务的高层解题结构、子目标、决策点和成功标准；其次，细节实例化（Detail Instantiation），再用原子技能填充每一步的具体操作、输入检查、输出验证。
新生成的技能不是凭空编的。它的每一层都显式引用了金字塔中的已有技能。这解决了一个关键问题：新技能不需要从零开始写，而是从现有的能力中组合出来。找番茄→洗→切片→放这个任务，框架来自抽象技能获取→处理→验证→放置，细节来自原子技能"获取"“清洗”“放置”，只有"切片"是需要新增的部分。
2.4 自演化：用完不扔，把新技能长回金字塔
每次任务执行结束后，新生成的技能不是用完就丢。Self-Evolution机制把它作为一个新节点长回金字塔中，不需要重建整个结构，Relation Analyzer只检索跟新技能相关的已有技能，Relation Builder只构建新技能与它们的关联。增量更新。
这就让技能库从"静态文件夹"变成了"活的演化系统"。每一次任务都在扩展这个系统的边界。而金字塔的层级结构天然防止了冗余膨胀——新技能出现时，Builder会检查它是否能被已有原子技能或抽象技能覆盖，如果能，就不重复构建。
三、实验：ALFWorld、WebShop、ScienceWorld上的表现
实验在三个交互式Agent Benchmark上跑，四个主干模型（DeepSeek-V3.2、GPT-4.1、Gemini 2.5 Pro、Qwen3-235B），对比ReAct、Reflexion、ExpeL和ReAct+Skills（用同样的初始技能库，但平铺不建金字塔）。
全面领先，优势在未见任务上尤其明显
平均奖励从53.4（ReAct）拉到了73.7。比ReAct+Skills的 65.8 高出 7.9 分。这不是"有技能比没技能好"，这是"同样的技能，有金字塔结构比平铺好"。
最打动我的是未见任务上的表现。ReAct+Skills在ALFWorld未见任务上已经是 80.6 了（比 ReAct 的 69.4 高出一大截），说明初始技能库本身质量不错。但SKILLPYRAMID把它拉到了84.8，在Qwen3-235B上甚至到了91.0。同样的技能库，只是把它组织成了金字塔，未见任务成功率从 68.6 跳到 91.0。
效率提升同样显著
平均交互步数从20.2（ReAct）降到了14.6。在ALFWorld上尤其明显：DeepSeek-V3.2 从 15.6 步砍到 10.7 步（已见任务），从 14.7 步砍到 10.6 步（未见任务）。Agent不是变快了，是走的路变短了。金字塔里的原子技能和抽象技能让 Agent 不需要每次都重新探索那些已经学会的基础操作，它直接跳到了真正需要决策的部分。
消融实验：每一层都在出力
去掉原子技能，ALFWorld奖励从 81.4 掉到 78.6。去掉抽象技能，ScienceWorld从 76.3 掉到 71.1，降幅更大。原子技能在操作密集型的任务上贡献更大，抽象技能在需要多步组合的任务上贡献更大。两个缺一不可。
最惨的是去掉金字塔、让Skill Creator从头生成技能：ALFWorld 从 81.4 直接崩到 64.3，比平铺技能库的 75.7 还差。没有金字塔做知识锚点，LLM凭空生成的技能注入的噪音比提供的帮助还多。
冻结金字塔不更新也掉了——从 81.4 到 76.4。技能系统需要自演化。静态的技能库，再好的结构也只是在延缓腐烂。
四、SKILLPYRAMID & SkillDAG，两种路线，同一个答案：技能的结构比技能本身更重要
SKILLPYRAMID做了一件在这个领域里非常稀缺的事：它没有发明新的技能生成方法，而是回答了"技能有了之后该怎么办"。
这恰好是当前Agent技能生态最薄弱的一环。大家都在卷怎么生成技能 —— 零样本、轨迹蒸馏、终身演化、归纳-演绎。但很少有人想过：技能库本身应该是什么结构？技能之间的关系应该怎么管理？
有意思的是，SKILLPYRAMID不是唯一在思考这个问题的工作。之前聊过的SkillDAG[1]（复旦/NUS/A*STAR）解决的是同一个大问题：技能库从"能用"到"好用"，中间缺的不是更多技能，是技能之间的结构。但两个工作走了完全不同的路线。
| 维度 | SKILLPYRAMID | SkillDAG |
|---|---|---|
| 核心思路 | 改技能内容，重建技能本体 | 不改内容，改关系，建技能关系图 |
| 做什么 | 向下原子提取 + 向上抽象归纳，把技能拆成层级金字塔 | 用五类有向边把技能之间的关系显式建出来 |
| 结构形态 | 严格层级金字塔（L_0 ~ L_K） | DAG 有向无环图 |
| 建结构方式 | 自底向上：从具体技能中提取原子和抽象层 | 自顶向下：先建节点，边在执行中逐步发现 |
| Agent 怎么用 | 框架构建（抽象层）→ 细节实例化（原子层），两步组合 | 随时查图、展开邻居、发现新关系、当场写回 |
| 演化方式 | 新技能增量插入金字塔，Builder检查去冗余 | propose-edge → edit-edge 在线提交，三条结构性约束防污染 |
| 适用场景 | 技能从零开始：内部项目、封闭场景、需从头搭建体系 | 技能已经一堆了：开放场景、社区技能库、已积大量历史技能 |
| 互补 | 解决"技能该怎么写" | 解决"技能该怎么选" |
两个工作指向同一个结论：技能不是独立的。把它们当独立的检索单元，就是主动放弃了技能之间最有价值的那层信息。平铺技能库，存 30 份就到了天花板。金字塔里，每份新技能都在加固结构。关系图里，每条新边都在让下次检索更准。
如果你在维护Agent的技能库，这两篇论文加起来给了四个马上能用的启示：
- •别满足于"检索→匹配"，让你的Agent学会"组合"。
- •别让技能之间互不相识，显式构建复用和依赖关系。
- •别只用相似度做检索，让Agent看到技能之间的关系。
- •别让技能库原地不动，每次任务都是一次进化机会。
五、最后说两句
SKILLPYRAMID做的最重要的事，不是建塔或自演化。是它问了一个别人没问的问题。
所有人都在问"怎么生成更好的技能"。SKILLPYRAMID问的是"技能有了之后，应该放在什么样的结构里"。一旦你意识到技能之间的关系是核心资产——不是附属品——你看技能库的方式就彻底变了。
技能不是文件。技能是节点。技能库不该是文件夹，该是一座能自己长高的金字塔。
当然，SKILLPYRAMID还有明显局限。
- •第一次建金字塔需要全库扫描，Analyzer-Builder管道遍历整个技能库，论文没探索更轻量的构建策略。
- •依赖强主干模型，Analyzer和Builder都需要能理解技能语义、识别复用关系的大模型，弱模型下金字塔质量怎么退化还没人知道。
- •只在文本交互环境上验证（ALFWorld、ScienceWorld、WebShop 全是文本场景），多模态和具身环境碰都没碰。
- •金字塔目前只有"向下原子提取"和"向上抽象归纳"两种复用关系，时序依赖、因果关联这些更复杂的组合推理还没有被建模。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
