---
title: "openJiuwen 开源 Jiuwen Symphony — 海量技能的精准发现与稳定协同（技能编排与分发系统）"
source_url: "https://mp.weixin.qq.com/s/l7219b4sFVsrxzMFZwiv-Q"
mp: "CSDN"
pub_date: "2026-06-17"
ingested: "2026-06-17"
sha256: "04f86c8f03d32f26fd0950fe9e0dd17cdbe25fda1ee3f0fa54b80bfae717f2e6"
type: source
tags: ["openjiuwen", "jiuwenswarm", "symphony", "skill-orchestration", "skill-retrieval", "skill-tree", "skill-graph", "agent-tools", "scale-challenge", "动态能力分发"]
---

# openJiuwen 开源 Jiuwen Symphony — 海量技能的精准发现与稳定协同

## 核心问题：技能从 5 到 50，"断崖式下滑"

当一个 Agent 能调用的 Skill 从 5 个膨胀到 50 个，会发生什么？

答案是：任务执行效果出现"断崖式下滑"——技能越多，Agent 反而越选不准。

**两个绕不开的核心难题：**

- **选不准**：技能太多，上下文窗口装不下所有技能说明书，必然出现信息过载、上下文过长的问题。若改用语义检索查找相似技能，由于检索与任务执行相互独立，仍无法解决多意图、隐式意图这类需要推理的选择问题。
- **用不好**：技能选对了，还需要精准编排。技能广场上的技能标准不统一，上一个技能的产出能否喂给下一个、谁先谁后、谁依赖谁，这些关系若每次让模型临场发挥，常常出现执行失败、流程中断等稳定性问题。

## 双核心架构：检索用树，编排用图

Jiuwen Symphony 由两个核心组件构成：**技能检索**与**技能编排**。

- 前者负责从海量技能里选对结果，解决选不准的问题；
- 后者负责把合适的技能按依赖串成可执行轨迹，解决用不好的问题。

### 技能检索：让 LLM 自己"递归作曲"，实现层次化的技能树检索

将用户本地或技能广场中的 skill 预先组织成一棵层次化技能树，原本平铺的技能列表就变成了可逐层浏览的技能目录。

检索时，LLM 不必一次性读完全部技能，而是在树上**按任务需求逐步导航**：先判断主能力分支，再顺着输入格式、输出目标、验证要求等线索展开相关节点，直到定位候选技能。

这种方式既保留了 LLM 对复杂语义任务的判断力，又降低了无关技能对上下文和注意力的干扰。

更进一步，这套检索机制并没有被设计成执行前的一次性预处理，而是被整合为一组面向 Agent 的专用工具：

- 递归能力树构建
- 分支探索
- 轻量预览
- 候选技能读取

**这意味着，技能选择被真正融入了 Agent loop，而非检索与执行相互独立**。Agent 在理解任务、尝试求解、发现信息不足或判断需要专门能力时，可以随时动态调用检索工具，按需查看技能目录、读取候选技能说明，再决定下一步执行路径。

**三个直接收益：**

1. 检索行为贴近当前推理上下文，选择更符合真实任务状态；
2. 技能调用可以随着任务推进动态调整，而不是一开始"拍脑袋选完"；
3. 避免全量注入 skills 带来的上下文膨胀，让大规模技能库仍然保持可用性。

Jiuwen Symphony 不是在做一个的技能在线搜索器，而是在为 Agent 提供一种**面向执行过程的动态能力分发机制**。

**SkillsBench 实测数据（Top-5 选择）**：

| 方案 | 召回率 | 成功率 | 平均最大上下文 |
|------|--------|--------|---------------|
| 关闭检索 | 低 | 低 | ~82k tokens |
| Embedding 检索 | 中 | 中 | 中 |
| **Symphony 技能检索** | **0.741** | **0.615** | **~21.5k tokens** |

Symphony 在 Top-5 选择上取得最佳效果，且把平均最大上下文从约 82k tokens 降到约 21.5k tokens（**降幅 ~74%**）。

### 技能编排：把技能关系谱成依赖图，用图编排出执行轨迹

如果说技能检索解决的是"选谁上场"，那么技能编排要回答的就是"怎么让它们配合起来"——围绕任务目标，对技能的输入输出、衔接关系和调用顺序做结构化编排。

**编排系统先离线给技能提取能力指纹，形成统一表征**。指纹覆盖技能的基础信息、输入输出产物和能力质量评估。再借助动态词表，把命名不一的同义字段（如 body、content、正文）归一到规范词上。这样，技能不再是一个个孤立的调用对象，而是变成**可比较、可计算、可关联的能力 schema**。

Jiuwen Symphony 基于能力指纹构建技能关系图，并作为结构化资产沉淀下来。图里的节点是技能，边可以表示为技能 A 的输出能否成为技能 B 的输入。如此一来，**在 Agent 执行任务时关系图谱可以被反复读取、复用和演进**。

**运行时编排流程**：编排不是简单地从列表里挑一个工具，而是先依据用户目标、已有输入和候选技能锁定一组种子技能，再沿着总谱里的可衔接关系做**双向搜索**：向后扩展"下一步做什么"，遇到缺失输入就反向回溯"谁能补上"，从而拼出真正接得上的技能组合。

**三个直接收益：**

1. **组合可靠**：不再只凭"看起来相关"，而是建立在输入输出能否真正衔接之上，中间缺失的步骤还能被自动补齐；
2. **协同可解释**：每个技能为何被选中、上一步产物如何进入下一步、当前缺什么输入，都能从执行轨迹里清晰追溯；
3. **失败可局部修复**：某个技能执行失败时，可沿图结构定位，围绕该节点就近替换或修补，而不必整条链路推倒重跑。

至此，技能的选择与组合不再依赖每次临场发挥，而是被升级为一种"基于图谱的系统化组织"——这也是 Symphony 区别于一般工具调用机制的核心点。

## 三个实战场景

三种用法可独立、可接力：候选不确定就单独检索，依赖复杂就单独编排，复杂开放任务则先检索后编排。

启用方式：在 JiuwenSwarm 页面"配置信息-其他配置"里，打开"**技能交响乐**"开关。

### 场景一：视频处理（仅使用技能检索）

当用户安装的技能从几十个增长到数千甚至更多之后，真正困难的地方不再是"有没有技能"，而是 Agent 能不能在合适的时候找到正确技能，并把它们组合进当前任务。

Agent 会先理解任务所需的多类能力，并通过技能目录进行逐步检索。先探索"视频/音频处理"这类主能力分支，再根据任务目标继续查看"文本整理""报告生成"等辅助分支。

**最终覆盖的技能集**：

- 视频读取与处理
- 音频转写
- 口头禅检测
- 停顿分析
- 关键片段整理
- 报告生成
- 备选/兜底处理

### 场景二：办公写作（仅使用技能编排）

任务：将英文博客截图翻译后整理成公众号文案，并发送到指定邮箱。

**没有技能编排时**：Agent 可能先调用图片翻译技能，但输出仍然是翻译后的图片，无法交给后续写作技能继续改写，系统可能转去读取博客网页或重新猜测原文来源。

**有技能编排后**：系统会先围绕任务目标检查每个技能的输入输出关系，发现"公众号文案撰写需要可编辑文本，而不是图片；邮件发送需要正文内容和收件人，而不是截图文件"。

**因此规划出可衔接的稳定路径**：

1. 图片翻译
2. 文字识别（图片 → 可编辑文本）
3. 文案撰写
4. 邮件发送

只有当前一步的输出能够满足下一步的输入要求时，这条连接才会被保留下来。这样多个原本独立的技能才能被组织成一条稳定的工作流，避免任务在中途变成图片、网页、文本之间的反复猜测。

### 场景三：出行规划（先检索后编排）

两个核心组件联动的典型用例：候选不确定先检索，依赖复杂再编排。

## 结语与战略判断

今天，越来越多团队在构建 Agent 时都会遇到同一个现实问题：模型能力在增强，但**系统能力没有同步增长**：

- 模型可以理解复杂需求，却常常无法稳定调用外部能力；
- 工具越来越多，却难以被高质量地检索和复用；
- 流程越来越复杂，却缺乏统一的技能组织方式。

openJiuwen 的探索提供了一个很值得关注的方向：**把 skill 当作需要被管理、检索、调度、编排的"系统资产"，而不只是提示词里附带的一段工具说明**。

它的价值不止于"提升一次任务成功率"，更在于为 Agent 的工程化扩展提供了一种可持续路径：

- 当技能库继续扩大时，系统仍能保持可检索性
- 当任务链条继续拉长时，系统仍能保持可组织性
- 当执行环境不断变化时，系统仍能保持动态适配能力

**当 Agent 进入真正的大规模技能时代，如何让能力被准确发现、被高效调度、被稳定协同，也许会成为比模型参数更重要的竞争力。**

## 项目地址

- JiuwenSwarm（AtomGit）：https://atomgit.com/openJiuwen/jiuwenswarm
- JiuwenSwarm（GitHub）：https://github.com/openJiuwen-ai/jiuwenswarm

Jiuwen Symphony 相关代码开源在 JiuwenSwarm 里。华为云 AgentArts 也已经将 openJiuwen 引入到商业化平台能力中。