Swarm Skills：让一群 Agent 像一个组织一样工作
这篇论文不是那种让人看完立刻觉得“哇，模型指标又涨了”的论文。它的价值不在 benchmark。当 Agent 越来越多，真正稀缺的不是智能。而是秩序。没有秩序，多 Agent 就是几个模型互相聊天。有了秩序，多 Agent 才可能变成团队。而 Swarm Skills，就是试图把这种秩序变成一种可以复用、可以分发、可以进化的资产。从 Prompt Engineering，走向 Context E
过去我们一直在研究怎么让一个 Agent 更强；但接下来真正重要的问题，可能是怎么让一群 Agent 像一个组织一样工作。
AI Agent 的下一场竞争，可能不是谁更聪明，而是谁更会“组队”。Swarm Skills 讨论的核心，不是单个模型能力，而是多 Agent 团队的协作协议、复盘机制与可复用组织方法。
Contents
AI Agent 的下一场竞争，可能不是谁更聪明。 而是谁更会“组队”。
最近我看了一篇挺有意思的论文: http://arxiv.org/abs/2605.10052。
名字叫：
《Swarm Skills: A Portable, Self-Evolving Multi-Agent System Specification for Coordination Engineering》
翻译成人话大概是：
Swarm Skills：一种可移植、可自我进化的多智能体协作规范。
这个标题看起来有点学术，有点绕。
但它真正想讲的事情，其实非常直白：
过去我们一直在研究，怎么让一个 Agent 更强。 但接下来真正重要的问题是： 怎么让一群 Agent 像一个组织一样工作。
我觉得这篇论文最有价值的地方，不是它提出了一个多么复杂的新模型。
恰恰相反。
它提出的是一个更底层、更工程化，也更容易被忽略的问题：
多 Agent 系统最难的，不是“多开几个 Agent”。
而是：
这些 Agent 到底怎么分工、怎么交接、怎么互相审查、怎么判断完成、怎么沉淀经验。
这件事，以前大多藏在代码里。
现在，它想把这件事变成一个可以复用、可以分发、可以迭代的东西。
这就是 Swarm Skills。
01 以前我们以为 Agent 的核心是能力
过去这一年，大家聊 Agent，通常聊的是这些东西：
- 模型能力强不强
- 工具调用稳不稳
- 记忆能不能用
- RAG 查得准不准
- MCP 接得多不多
- Workflow 能不能拖出来
这些当然都重要。
但它们解决的大多是一个问题：
单个 Agent 怎么把一件事做好。
比如：
让它写代码。
让它查资料。
让它生成 PPT。
让它总结文档。
让它调用工具完成一个任务。
所以我们有了很多 Skills。
一个 Skill，通常就是一个能力包。
你可以理解成：
把某类任务的经验、规则、脚本、模板、参考资料，打包成一个 Agent 能读取和执行的技能。
这件事已经很有价值了。
因为它让 Agent 不再每次从零开始。
但论文指出了一个更进一步的问题：
当任务复杂到必须由多个 Agent 协作时，单个 Skill 就不够了。
因为复杂任务里，真正难的不是“会不会做某一步”。
而是：
谁先做？
谁后做？
谁审查？
谁拍板？
谁失败后重试？
谁负责汇总？
什么时候停止？
怎么判断这个团队表现得好不好？
这些东西，不是普通 Skill 能完整表达的。
这就是论文里所谓的：
Coordination Engineering，协作工程。
02 多 Agent 最大的问题，是协作经验不可复用
现在很多多 Agent Demo，看起来都很酷。
一个 Agent 当产品经理。
一个 Agent 当工程师。
一个 Agent 当测试。
一个 Agent 当 reviewer。
最后大家一起完成任务。
看上去很像一个 AI 公司。
但真落到工程里，你会发现一个很尴尬的问题：
这些协作方式通常是写死的。
角色 prompt 写死。
leader-worker 结构写死。
消息流转写死。
终止条件写死。
评估方式写死。
失败恢复也写死。
也就是说，一个多 Agent 系统跑得好，并不代表它的协作经验可以被别人拿走。
换一个框架，可能就没了。
换一个运行时，可能就崩了。
换一组工具，可能就要重写。
这就像一个公司有一套非常优秀的项目管理方法，但这套方法只存在于某个项目经理的脑子里。
他在的时候，团队很强。
他一走，全没了。
Swarm Skills 想解决的，就是这个问题。
它想把“多 Agent 怎么协作”这件事，从代码和隐性经验里抽出来。
变成一个类似 Skill 的包。
一个可以被读取、安装、分发、版本管理、自动优化的协作协议。
03 Swarm Skills 到底是什么？
简单说，Swarm Skill 不是给一个 Agent 用的技能。
而是给一群 Agent 用的协作说明书。
它里面可能会描述这些东西：
这个团队有哪些角色
每个角色负责什么
任务应该怎么拆
消息应该怎么传
什么时候进入下一阶段
什么时候需要人工介入
什么时候任务算完成
执行过程中有哪些边界
成功后如何总结经验
失败后如何修正流程所以它不是一个普通的 prompt。
也不是一个 workflow 图。
更不是简单的“专家角色设定”。
它更像一个：
可执行的组织协议。
如果说普通 Skill 是：
让一个 Agent 学会一种手艺。
那么 Swarm Skill 就是：
让一群 Agent 学会一种组织方式。
这个区别非常重要。
因为单个 Agent 的能力再强，也很难解决所有复杂问题。
复杂问题天然需要分工。
而只要有分工，就一定需要协作协议。
图 1从单个 Agent 的能力包，到多 Agent 的协作说明书：Swarm Skills 解决的是“组织方式”如何被复用。
04 这篇论文最重要的判断：Agent 时代需要“组织能力”
我觉得这篇论文真正有意思的地方在这里。
它其实是在说：
未来 AI 系统的竞争，不只是模型能力，也不是工具数量，而是组织能力。
这句话听起来有点抽象。
但你想一下就明白了。
现实世界里，一个公司强，不是因为每个人都是天才。
而是因为它有一套稳定的组织方式：
有人负责发现问题。
有人负责拆解问题。
有人负责执行。
有人负责质检。
有人负责交付。
有人负责复盘。
这套机制跑得越顺，公司就越强。
Agent 系统也是一样。
当任务越来越复杂，一个 Agent 再强，也会遇到边界。
它需要其他 Agent 协同。
但协同不是把几个模型连起来就行。
协同需要协议。
需要秩序。
需要角色。
需要交接。
需要边界。
需要复盘。
这就是 Swarm Skills 这篇论文想表达的核心观点：
**AI Agent 的下一步，不是从个人能力走向超级个体。 而是从单体智能走向组织智能。**
05 它和 openJiuwen 的关系，其实挺自然
这篇论文如果单独看，是一个规范设计。
但如果放到 openJiuwen 的背景里看，就会更清楚。
openJiuwen 公开组织下有几个关键仓库：
jiuwenSwarmagent-coreagent-studiodeepsearchagent-protocolagent-store
其中，GitHub 页面显示 agent-core 定位为提供 Agent 开发、运行、优化和演化相关 SDK 能力；agent-studio 则提供低代码/零代码开发、工作流编排，以及模型、知识库、插件等资源的统一管理；agent-protocol 则涉及 MCP 和 A2A 等 Agent 通信协议实现。。
这意味着什么？
意味着 openJiuwen 其实已经有了几个关键拼图：
agent-core：负责 Agent 怎么跑
agent-studio：负责工作流怎么编排
agent-protocol：负责 Agent 怎么通信
jiuwenSwarm：负责更贴近用户侧的 Agent 体验
agent-store：负责 Agent 资产生态而 Swarm Skills 刚好可以补上中间那一层：
多个 Agent 到底应该怎么协作所以它和 openJiuwen 的关系，不像是一个外部概念硬套进来。
更像是 openJiuwen 已经有了运行时、工作流、协议、工具生态之后，需要一个更上层的“协作资产标准”。
用一句话说：
openJiuwen 提供 Agent 的身体。 Swarm Skills 试图提供多 Agent 团队的组织方法。
放在 openJiuwen 体系里看，Swarm Skills 更像“协作资产层”：Core 负责执行，Studio 负责编排，jiuwenSwarm 负责协作运行，而 Swarm Skills 负责把协作经验沉淀下来。
06 这件事如果做成，价值会很大
我举几个很具体的例子。
假设你有一个“论文解读团队”。
它可以不是一个 prompt。
而是一个 Swarm Skill。
里面定义：
Researcher Agent：负责读论文和找背景
Engineer Agent：负责看代码仓库和实现可行性
Reviewer Agent：负责质疑论文贡献和实验
Writer Agent：负责转成公众号文章
Editor Agent：负责标题、结构和传播性这就不是“让一个 Agent 写文章”。
而是一个完整的内容生产组织。
再比如，一个“代码迁移团队”。
Architect Agent：判断迁移边界
Coder Agent：执行修改
Test Agent：补测试
Reviewer Agent：审查风险
Release Agent：生成变更说明这也不是普通代码助手。
这是一个可以复用的工程协作模式。
再比如，一个“客户问题处理团队”。
Triage Agent：判断问题类型
Knowledge Agent：检索内部知识库
Action Agent：调用工具处理
Risk Agent：检查合规风险
Reply Agent：生成回复你会发现，一旦 Swarm Skill 成立，很多东西就可以沉淀下来。
不是沉淀某个 prompt。
而是沉淀一个团队的工作方法。
这就是它的想象力。
07 但我也觉得，它最危险的地方在“自进化”
论文里还有一个非常激进的设定：
Swarm Skills 不只是可复用。
它还可以自我进化。
也就是说，系统可以从成功的执行轨迹里，总结出新的协作方式。
然后根据效果、使用情况、新鲜度等指标，去更新旧的 Swarm Skill。
这个想法很漂亮。
但也很危险。
因为你仔细想一下：
如果一个 Skill 会影响 Agent 未来怎么行动，那么自动修改 Skill，本质上就是在自动修改 Agent 的行为准则。
这不是小事。
如果轨迹本身有问题呢？
如果一次成功只是运气呢？
如果协作流程里引入了隐性风险呢？
如果某个 Agent 学会了绕开审查呢？
如果一个旧工具已经不安全，但因为历史表现好继续被保留呢？
所以我觉得，自进化一定不能一开始就完全自动化。
更合理的方式应该是：
先生成修改建议
再跑评测
再做人类确认
最后进入版本库尤其是涉及权限、数据访问、终止条件、人工介入条件这些高风险部分，必须有审查。
自进化不是不该做。
而是不能无脑做。
它应该像代码合并一样，有 diff、有测试、有 reviewer、有回滚。
08 我认为这篇论文最该被记住的一句话
如果只能记住一个点，我觉得是这个：
多 Agent 的核心，不是 Agent 数量，而是协作协议。
这句话很关键。
因为现在很多人做多 Agent，还是有一种很朴素的想法：
一个 Agent 不够，那就多来几个。
但这就像创业公司招人。
不是人越多，公司越强。
没有组织方式，人越多，沟通成本越高，混乱越多。
Agent 也一样。
你加 3 个 Agent，不一定更强。
可能只是多了 3 个不确定性来源。
真正重要的是：
它们之间有没有清晰分工。
有没有交接机制。
有没有审查机制。
有没有失败恢复。
有没有终止条件。
有没有沉淀经验的方式。
这才是多 Agent 系统能不能从 Demo 走向生产的关键。
09 所以，Swarm Skills 可能不是一个小功能
我一开始看这个概念，会觉得它只是 Skills 的一个扩展。
但看完之后，我更愿意把它理解成：
Agent 时代的组织工程规范。
RAG 解决知识怎么进来。
MCP 解决工具怎么接进来。
普通 Skills 解决单个 Agent 怎么学会一类任务。
而 Swarm Skills 想解决的是：
一群 Agent 怎么变成一个可复用、可演化的团队。
这件事如果做成，会改变很多 Agent 产品的形态。
未来我们使用 Agent，可能不再只是选择一个助手。
而是选择一种团队。
比如：
我需要一个研究团队
我需要一个投研团队
我需要一个代码审查团队
我需要一个增长分析团队
我需要一个内容生产团队
我需要一个应急响应团队这些团队不是临时 prompt 出来的。
而是有版本、有协议、有历史表现、有进化记录的 Swarm Skills。
这就很像从“雇一个人”，变成“调用一个组织”。
10 最后说人话
这篇论文不是那种让人看完立刻觉得“哇，模型指标又涨了”的论文。
它的价值不在 benchmark。
它的价值在于，它把一个工程上迟早会遇到的问题提前说出来了：
当 Agent 越来越多，真正稀缺的不是智能。 而是秩序。
没有秩序，多 Agent 就是几个模型互相聊天。
有了秩序，多 Agent 才可能变成团队。
而 Swarm Skills，就是试图把这种秩序变成一种可以复用、可以分发、可以进化的资产。
这可能是 Agent 时代一个很重要的转折：
从 Prompt Engineering，走向 Context Engineering。
再往后，可能就是：
Coordination Engineering。
也就是：
不只是会和 AI 对话。
不只是会给 AI 上下文。
而是会设计一群 AI 如何协作。
这件事，可能会变成未来几年最重要的工程能力之一。
多 Agent 的核心，不是 Agent 数量，而是协作协议。
Sources
小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用
更多推荐
5
0- 0
已为社区贡献1条内容
所有评论(0)