Fusion Capabilities

当前 Fusion 不是自己发明一套孤立能力系统，而是通过 adapter 和 binding 接入平台已有能力，并把这些能力折叠成 definition-driven runtime 可消费的输入。

当前能力面

RAG

RAG binding 允许某个 definition run 直接复用平台已有 knowledge / retrieval 能力。

当前重点不只是“能不能检索”，而是：

• 是否启用
• 绑定到哪个 agent
• top_k
• score_threshold

这些值会在 governance context 中被落成事实快照。

MCP

MCP binding 允许 definition run 接入 Agent 级 server mount 与工具策略。

当前会关心：

• agent_id
• allowed_tool_names
• mounted_server_ids
• 是否启用 MCP

因此 Fusion 不是另起一套工具调用系统，而是复用现有 MCP 治理面。

模型调用

definition runtime 会把模型视为能力之一，而不是默认隐式存在的黑盒。

这使得 prompt 构建、模型调用和输出归一化可以明确出现在图里，而不是散在各个业务节点。

文件与工件处理

当 run 输入包含文件、图片或其他 artifact 时，runtime 会先准备工件，再把它们交给后续节点消费。

这类能力决定 Fusion 不只适合纯文本任务。

继承规则

• capability_bindings.rag.agent_id 未显式指定时，可继承绑定 Agent
• capability_bindings.mcp.agent_id 未显式指定时，也可继承绑定 Agent
• 显式声明的 binding 优先于继承路径

这意味着 definition 可以只写“我要用 RAG / MCP”，再由 linked agent 提供具体治理资产。

能力解析不是直接读 JSON

运行时不会把 binding JSON 原样塞进节点，而是会经过 adapter / governance 解析。

典型路径是：

1. 读取 definition version 的 capability_bindings
2. 结合 linked agent 与默认值做 resolve
3. 产出治理快照
4. 再由 runtime graph 消费

所以排查“binding 配了但没效果”时，要看 resolve 后的结果，而不是只看原始 JSON。

为什么重要

这决定了 Fusion 可以共享平台既有治理资产，而不是复制一套独立配置系统。

更具体地说，它带来 3 个结果：

1. RAG / MCP 的权限、挂载和默认策略可以继续沿用
2. definition version 仍然保持可复现，不会因为外部配置漂移而完全失真
3. 平台新增一种能力时，可以通过新增 binding adapter 进入 Fusion，而不是重写整套 runtime

代码入口

路径	作用
ai_service/fusion/infrastructure/adapters/rag_binding.py	RAG binding 解析
ai_service/fusion/infrastructure/adapters/mcp_binding.py	MCP binding 解析
ai_service/fusion/infrastructure/adapters/governance.py	binding 到治理快照的折叠
ai_service/fusion/infrastructure/runtime/graph.py	能力在运行时图中的消费顺序

什么时候该新增一种 capability

只有当该能力满足下面两个条件时，才值得进 Fusion binding 体系：

• 它是跨 definition 可复用的正式运行能力
• 它需要进入治理、版本化和 run 级可追溯链路

否则更适合作为内部节点实现细节，而不是公开 capability。