论文: Swarm Skills: A Portable, Self-Evolving Multi-Agent System Specification for Coordination Engineering
作者: Xinyu Zhang, Zhicheng Dou, Deyu Li, Jianjun Tao, Shuo Cheng, Ruifeng Shi, Fangchao Liu, Enrui Hu, Yangkai Ding, Hongbo Wang, Qi Ye, Xuefeng Jin, Zhangchun Zhao (中国人民大学高瓴人工智能学院 & openJiuwen团队)
发布日期: 2026-05-11
你有没有想过一个很奇怪的事——
单智能体的技能（Skill）已经可以像App一样打包、分发、安装了。Claude的SKILL.md就是一个标准化的技能包，写好一次，到处能用。但多智能体呢？你在CrewAI里写的团队模板，AutoGen里配的GroupChat，MetaGPT里定义的SOP——跑完就没了。换一个框架？完全不能用。
这就像每个团队做完项目就把流程文档全删了，下次再来类似任务，又要从零开始摸索"谁干什么、怎么配合"。不是浪费，是巨大的浪费。
Swarm Skills这篇论文就是要解决这个问题。
先搞清楚：Swarm Skill到底是什么？
名字里带"Skill"，但它不是一个Skill，而是一组Skill的编排方案。
打个比方：
- 普通Skill = 一个人的岗位说明书（你会什么、用什么工具、怎么干活）
- Swarm Skill = 一整个部门的组织架构图（有哪些岗位、谁先干谁后干、怎么配合、预算多少）
它们虽然都叫"Skill"，都放在skills/目录下，都用SKILL.md做入口，但层次完全不同。普通Skill描述的是一个Agent能做什么，Swarm Skill描述的是一群Agent怎么合作。
再直白一点——一个Swarm Skill本质上就是一家虚拟公司：
- SKILL.md = 公司简介 + 组织架构（有哪些部门）
- roles/ = 每个岗位的JD（岗位职责、需要什么能力、用什么工具）
- workflow.md = 业务流程（哪个部门先干、谁交付给谁、哪些可以并行）
- bind.md = 公司制度（预算上限、deadline、质量标准）
- evolutions.json = 公司的经验积累（上次项目踩了什么坑、下次怎么改进）
一个被忽视的空缺
论文把AI工程的演进分成四个阶段——Prompt Engineering、Context Engineering、Harness Engineering、Coordination Engineering。前三个都围着单智能体转，到了Coordination Engineering才真正面对"多智能体怎么协作"这件事。
但最关键的瓶颈不是"怎么让多个Agent跑起来"——CrewAI、AutoGen、MetaGPT已经做了——而是协作经验沉淀：成功的协作模式能不能被记录、复用、持续改进？
论文做了一个很有说服力的调研：在现有的Anthropic Skills社区里，大量高下载量的Skill其实是在用单智能体格式"假装"多智能体。比如一个叫c-level-advisor的Skill里面塞了9个角色，ra-qm-team定义了13个专家人格。用户想表达"团队协作"的需求，但标准只支持单智能体，只能凑合。
这说明什么？需求早就有了，只是没人给一个正经的标准。
"描述格式，不是运行时"——最关键的设计决策
Swarm Skills最核心的一句话就是：它是一个描述格式，不是一个运行时。
传统框架把协作逻辑写死在Python代码或私有配置文件里。CrewAI的模板AutoGen读不懂，MetaGPT的SOP也不能搬到CrewAI——它们各自定义了自己的"执行图"，彼此互不兼容。
Swarm Skills完全反过来——它只规定**"谁来做、做什么、有什么约束"，完全不碰"怎么做"**。消息怎么传递？任务队列怎么管理？进程怎么隔离？那是宿主Agent（Host Agent）运行时的事。
换个说法：Swarm Skill是一份作战方案，Host Agent是指挥官。作战方案写了"你需要5个人、A负责侦察、B负责火力、C负责后勤、A先出动然后BC跟上"，但具体怎么调兵遣将、用什么通讯设备，是指挥官自己的事。任何指挥官拿到这份方案都能排兵布阵，不需要适配器。
那具体怎么用？跑一遍流程
整个使用流程是这样的：
- Host Agent收到一个任务，比如"帮我规划一次旅行"
- Leader扫描所有Swarm Skill的简介——只看frontmatter里的description字段，省token
- Leader选中合适的Swarm Skill，比如travel-planning-swarm
- 按需读取详细内容——用
read_file逐层加载SKILL.md正文、roles/、workflow.md、bind.md - 创建队友——Leader根据roles/里的定义，用Host Agent原生的子Agent工具（比如Task）实例化各个角色
- 按workflow协作——队友们按workflow.md描述的方式配合完成任务
- 执行完后，系统自动扫描轨迹——发现摩擦就生成Evolution Record追加到evolutions.json
注意第5步——Swarm Skill自己不会"运行"，它只是告诉Host Agent该怎么组织团队。队友的创建、消息的传递，全靠Host Agent的原生能力。Swarm Skill只提供"剧本"，不提供"舞台"。
五个组件，一个目录
一个Swarm Skill长这样：
swarm-skill/
├── SKILL.md # 入口：frontmatter元数据 + 自然语言概述
├── roles/ # 角色定义（每个角色一个.md文件）
├── workflow.md # 工作流描述（自然语言或Mermaid语法）
├── bind.md # 执行边界（最大轮次、token预算、质量门控）
└── evolutions.json # 进化记录（运行时自动生成和更新）
跟传统多智能体框架比一下就很清楚了：
| CrewAI / AutoGen | Swarm Skills | |
|---|---|---|
| 协作逻辑 | 写死在Python代码里 | 写在Markdown文件里 |
| 跨框架 | ❌ 不行 | ✅ 任何能读懂Markdown的Agent都能用 |
| 可进化 | ❌ 跑完就没了 | ✅ 自动记录改进，越用越好 |
| 降级处理 | 换框架直接报错 | 不支持多Agent就降级成单Agent顺序执行 |
SKILL.md是入口，frontmatter里声明kind: swarm-skill告诉框架"这是多智能体技能"，roles[]列出角色配置。有意思的是，这些新字段利用了Anthropic Skills标准的additionalProperties: true机制——不支持多智能体的框架会自动忽略它们，把Swarm Skill当普通Skill用。不崩溃，只是降级成单智能体顺序执行。优雅降级，而不是报错退出。
roles/目录里每个角色一个.md，Leader用read_file加载后创建队友。workflow.md用自然语言或Mermaid语法描述任务依赖。bind.md设定约束——防止团队跑飞。
而evolutions.json——这是最有趣的部分。
只追加，不修改——像Git一样的进化记录
每次执行完一个Swarm Skill，系统会自动扫描执行轨迹，寻找"摩擦"：循环依赖、冗余通信、角色职责耦合……发现后生成一条Evolution Record追加到evolutions.json：
{
"id": "evo_20260430_001",
"context": "Budget Reviewer在数值审计和创意写作之间反复切换，效率低下",
"change_directive": {
"target_files": ["roles/copywriter.md", "workflow.md"],
"action": "SPLIT_ROLE",
"content": "拆分出独立的Copywriting Expert，与预算审查并行执行"
},
"metrics": {
"effectiveness_score": 0.5,
"utilization_rate": 0.0,
"freshness_decay": 1.0
}
}
只追加，不修改基础文件。 SKILL.md、roles/、workflow.md保持原样，进化记录是叠加在上面的。这就像Git——每次改进是一条commit，基础代码是干净的，出问题随时revert。
而且因为evolutions.json是Swarm Skill的一部分，所以进化经验是跟着资产走的。你把一个Swarm Skill从Agent A传给Agent B，B自动继承A积累的所有协作经验。这在以前是不可能的——你用CrewAI跑出来的经验，AutoGen一点都沾不到。
用"虚拟公司"来说就是：你把一家公司卖给新老板，公司制度、项目经验、踩过的坑全部打包带走，新老板不用从零开始。
怎么进化？三个阶段循环
格式定义了"进化记录放哪"，但怎么产生和评估这些记录？配套的自我进化算法分三个阶段：
CREATE（从零到有）：当Host Agent执行任务时动态创建了多个子智能体，算法监控到"协作信号"（≥2个角色 + 跨Agent依赖），就把执行轨迹蒸馏成一个新的Swarm Skill。比如"分析框架A vs B"被抽象成"N-way Component Comparison"这个通用模式。新Skill存到暂存区，Leader选了才正式采纳——自然淘汰机制。
USE（按需加载）：Leader只看所有Skill的description（省token），选中后才用read_file逐层加载详情。历史进化记录也会被注入，让团队自动受益于过去的改进。
PATCH（摩擦驱动）：任务完成后扫描轨迹，找两类信号——隐式摩擦（循环依赖、冗余通信）和显式改进（用户反馈、Agent反思）。找到就自动追加Evolution Record。
还是用公司的类比：CREATE相当于"新业务线跑通了，沉淀成标准流程"；USE相当于"下次接类似项目，直接翻手册"；PATCH相当于"项目复盘发现问题，记到改进清单里"。
但进化不能乱来——三维评分和治理动作
Evolution Record会越积越多，不能什么都留着。系统用三维加权评分评估每条记录：
- E (Effectiveness)：补丁的实际效果。用贝叶斯平滑（Beta(1,1)先验）稳定早期评估，不会因为一两次异常结果就大起大落
- U (Utilization)：采纳率。如果Leader总是忽略某条进化指令，说明它没用，U就衰减
- F (Freshness)：时间衰减，指数半衰期（如90天）。过时的优化不该永远占着上下文窗口
低分记录自然沉底，最终被忽略。
当记录积累到一定量（≥10条），触发三大治理动作：
- SIMPLIFY：LLM驱动的修剪——低分删、重叠合、措辞磨。相当于公司定期"清理旧制度"
- REBUILD：解决"首次运行锁定"——如果初始工作流就很差，打再多补丁也不如推倒重来。REBUILD把补丁合并到基础文件，生成干净的版本，清空evolutions.json。相当于"公司架构重组"
- ROLLBACK：REBUILD搞砸了？回滚到之前归档的版本。相当于"重组失败，恢复原状"
这套机制让进化不是"野蛮生长"，而是有质量管控的持续改进。
看看实际效果：一个旅行规划的例子
论文用了一个travel-planning-swarm来演示整个系统怎么跑。
任务：五一从杭州去东北，一家三口（含1岁宝宝），预算2万。5个专家角色：交通、住宿、景点、计划整合、预算审查。
执行中出了个有趣的冲突——交通专家选了便宜的晚班航班，景点专家安排了第一天下午的行程，时间对不上。两个Agent自主协商，考虑到1岁宝宝的舒适度，决定改上午航班，保住下午行程，预算也没超。
任务完成后，算法发现"预算审查者"同时干财务审计和社交媒体文案写作，职责耦合。自动生成Evolution Record建议拆分。确认后REBUILD，团队从5人变6人，文案和审查并行——越用越强。
这就像一家真公司——项目做多了发现"财务和文案让一个人干"效率太低，自然就拆成两个岗。Swarm Skills把这个过程自动化了。
零适配器部署的秘密
Swarm Skills声称"Zero-Adapter Deployment"——不需要翻译层就能跨框架用。怎么做到的？
答案是渐进式披露（Progressive Disclosure）。整个协作协议用自然语言和Markdown写，唯一有结构的是SKILL.md的frontmatter。Host Agent不需要解析什么专有执行图，它只需要读懂自然语言的工作流描述，然后用原生的read_file和子智能体创建工具来执行。
对Claude Code来说，部署就是把目录复制到skills/文件夹，完事。对不支持多智能体的框架，会优雅降级成单智能体顺序执行——不会崩溃，只是效果差一些。
我的看法
真正厉害的地方：问题定义精准——"协作经验沉淀"这个痛点以前没人系统提过。设计哲学也对——"描述格式而非运行时"让它天然可移植，如果自己定义执行引擎，就又变成另一个CrewAI了。进化机制的工程化程度很高，贝叶斯平滑、时间衰减、SIMPLIFY/REBUILD/ROLLBACK这套组合拳不是拍脑袋想出来的。
我的疑虑：自然语言工作流的鲁棒性是个问题——不同模型对同一段workflow.md的理解可能差别很大，这比代码定义的执行图脆弱。论文也承认缺乏大规模跨框架定量测试，目前只有JiuwenSwarm一个参考实现。"首次运行锁定"也不太好解决——初始工作流很差的话，PATCH可能只是给烂楼刷漆。
实践启发：不管你用什么框架做多智能体，现在就该把协作协议和运行时解耦——别把逻辑写死在代码里。evolutions.json"只追加不修改"的模式很值得借鉴，任何需要持续改进的系统都能用。三维评分的思路也通用——不是所有"改进"都是真改进，量化评估比拍脑袋靠谱。
Swarm Skills提出了一个简洁但野心勃勃的想法：多智能体的协作方式，应该像单智能体的技能一样，可以打包、分享、安装、进化。 当AI从"一个人干活"走向"一个团队干活"，协作经验能不能沉淀和复用，决定了团队是每次从零开始，还是越用越强。
它给出的答案很有说服力——让协作协议本身成为可进化的生命体。
🤖 以上是小歪对这篇论文的研读笔记，欢迎交流讨论～
