Symphony 能力编排

解决什么问题

一个企业智能体平台上，技能（skill）和智能体会越积越多：查库存的、算交期的、做排产的、写订单的，可能各有好几个版本。模型面对上百个候选能力时，既找不准，也不知道怎么组合。

openjiuwen.symphony 管的就是"能力资产"这一层：发现、指纹、检索、编排、评估、经验沉淀。

检索用树，编排用图

能力资产目录
  ↓ 扫描（只扫调用方显式传入的目录）
能力指纹：语义画像、输入输出、标签
  ├─ 检索树：按类别逐层展开 → 候选能力
  └─ 关系图：能力之间谁能把输出喂给谁 → 规划器 → 执行路线

• 能力指纹是两边共享的标准视图：这个能力干什么、要什么输入、产出什么。
• 关系图的每条边都有类型、置信度、判定方法和证据，比如"查库存"的输出能喂给"算交期"。
• 规划器有两种：FastOneShotPlanner 让模型在一个精简子图上一次给出计划；BidirectionalBeamPlanner 在图上做语义双向束搜索，生成多个候选计划再重排。

源码GraphEdgeagent-core/openjiuwen/symphony/orchestration/graph/models.py:130@fbe6a0d9 源码BidirectionalBeamPlanneragent-core/openjiuwen/symphony/orchestration/planning/beam.py:317@fbe6a0d9

拿贯穿案例来说：客户问交期，检索树先缩到"库存""产能""交期"几个分支，找出候选能力；关系图知道库存和产能的输出都能喂给交期计算，规划器据此排出"并行查库存和产能 → 算交期"的路线。

实施状态：先看清哪些已经能用

Symphony 的 README 同时写了最终设计和当前实现，学习和选型时要分清：

源码README 实施状态表agent-core/openjiuwen/symphony/README.md@fbe6a0d9

边界：它不替你做什么

Symphony 只处理调用方显式交给它的东西。能力的安装注册、模型账号、会话状态、权限控制、实际调用入口和界面展示，都由使用方负责，通过 Adapter 把运行时信息转换成 Symphony 能消费的普通对象。

这条边界对企业场景很重要：编排建议不等于执行授权。规划器给出的路线，真正执行时仍然要走智能体的工具调用，也就仍然会经过 Rail 关卡里那些检查。

小结

• 能力多了以后，先建指纹，再分别用树检索、用图编排。
• 关系图的边带置信度和证据，规划器在图上生成可解释的路线。
• 以 README 的实施状态表为准，检索和 Toolkit 还在迁入中。
• Symphony 只给建议，权限和执行留在你的系统里。