🚀 背景描述

当前 openJiuwen 已经围绕智能体能力形成了 Agent 应用（jiuwenswarm）、能力分发、能力检索、能力编排和质量评估等环节。这里的“能力”，指智能体的能力执行单元，可对应 skill、生态agent、业务自研 Agent 或其他可被 Agent 调用的能力形态。
从现有实现看，能力指纹、能力检索、能力编排和能力排序已经逐步成为多条业务链路都会依赖的公共逻辑。继续以分散方式演进，会导致公共能力难以复用、接口契约不稳定、产物格式不统一，也会让指纹、检索、编排和排序逻辑在多个使用方之间重复建设。

如果相关能力继续分散维护，会带来以下设计问题：

• 公共能力需要同时服务 Agent 应用、能力分发服务和业务 Agent 场景。如果沉在 jiuwenswarm 内，会受到单一 Agent 应用的部署形态限制，难以被多用户或业务侧场景复用。
• 能力指纹（含评估）、检索、排序和编排如果被单一 Agent 应用约束，容易混入会话、权限、UI、工具注册等应用运行逻辑，导致公共能力边界不清晰。
• 相关能力分散在 Agent 应用、能力分发服务和业务集成代码中，会导致能力指纹、检索、排序、评估口径不一致，形成重复实现；同时也不利于依赖按需裁剪，例如只使用质量评估时仍可能被迫安装检索、编排或经验沉淀相关依赖。

设计思路

将 Jiuwen Symphony 能力指纹（含评估）、检索、编排等能力进行收敛，打造边界清晰、支持独立发布、可供多方复用的公共组件。
Jiuwen Symphony 核心代码迁移至 agent-core 代码仓，存放路径：agent-core/openjiuwen/symphony；jiuwenswarm 代码仓仅保留对该组件的依赖调用以及UI 相关代码。

涉及到的对外API

与其他模块的相关性描述

建设完成后，jiuwen-symphony 作为 jiuwenswarm 依赖的能力检索与编排组件。
在 jiuwenswarm 场景中，jiuwen-symphony 的价值不在于给 Agent 增加一个新的能力入口，而在于把大量能力单元组织成可被 Agent 有效使用的中间层。jiuwenswarm 负责承接用户任务和执行链路，jiuwen-symphony 负责回答“当前任务应该看哪些能力、这些能力如何组合、组合结果是否可靠”。这样可以避免 jiuwenswarm 直接维护一套不断膨胀的能力列表，也避免能力已安装但无法被有效检索、调起和组合。

jiuwenswarm 应保留：

• Agent 应用启动、gateway、agent server、extension 注册和 UI 展示。
• 与 Agent 应用环境相关的账号、权限、配置读取和运行时状态。
• 将 Symphony toolkit 接入 Agent 调用体系的 Adapter。
• Agent 应用内部能力 ID 与 capability_id 的映射逻辑。

jiuwen-symphony 应承接：

• 能力单元清单、指纹结果、分类和 IO 语义归一化。
• 能力检索、候选排序、能力关系图构建和在线计划。
• 能力指纹（含评估）、经验沉淀和质量结果产出。
• 与具体 Agent 应用无关的公开 API、产物格式和构建流程。

测试设计与测试计划

建设完成后，jiuwenswarm 使用 Adapter 接入 openjiuwen.symphony，Agent 应用链路中的检索、图读取和计划生成行为保持可用。

其他信息

关联的jiuwenswarm issue: https://gitcode.com/openJiuwen/jiuwenswarm/issues/2460

感谢您的贡献 🎉!