[Feature] 知识库升级为 Context Infra 层：支持多知识后端 + 分层记忆 + 治理

[Joe0720]

你在解决什么问题？（必填）

当前 LLM Wiki 作为结构化知识引擎运行良好，但在企业多 Agent 协同场景中存在以下问题：

1. 知识孤岛：无法对接企业已有的百炼知识库、FastGPT、RAGFlow 等外部知识平台
2. 上下文断裂：Agent 跨会话无法恢复知识，缺少分层加载策略，浪费 Token 窗口
3. 缺少治理能力：无权限控制、版本溯源、冲突消解，无法满足企业生产部署要求

参考 Codified Context Infrastructure 和业界 Context Infra 三层架构（Protocol → Delivery → Governance），建议将知识库从"知识检索模块"升级为 Agent 平台的 Context Infra 层。

你期望它怎么工作？（必填）

1. Protocol Layer — 可插拔知识协议

引入 KnowledgeProvider 统一接口，暴露 MCP / REST API：

KnowledgeProvider
  ├── LLM Wiki（内置，结构化页面）
  ├── PGVector / Qdrant / Milvus（向量数据库）
  ├── 阿里云百炼知识库 API
  ├── FastGPT Dataset API
  └── RAGFlow API

Agent 调用 find_relevant_context(task) 即可获取上下文，新增知识源只需实现 Provider 适配器。

2. Delivery Layer — 分层记忆交付

Level	Content	Loading Strategy
Hot	核心规范/行为准则	每次会话必加载，≤660 行
Warm	领域 SOP/技术方案	Trigger Table 按任务类型路由加载
Cold	大规模文档库	语义检索按需召回

检索聚合流程：多 Provider 并行 → 去重 → 分数归一化 → Reranker（如 gte-rerank-v2）→ 安全过滤 → 注入 system prompt

3. Governance Layer — 企业级治理

• RBAC 权限控制：不同用户/Agent 只能看到授权范围内的知识
• 版本溯源：知识变更可追溯（who/when/what）
• 可信度标注 + 冲突消解：多源冲突时按优先级裁决
• 审计日志：全链路记录上下文消费轨迹

4. Multi-Agent Context Sharing

引入 Context Broker 作为共享上下文枢纽，多 Agent 基于 Shared Memory Graph 协作，避免各自维护 context 导致数据孤岛。

Implementation Roadmap

Phase	Scope	Notes
Phase 1	PGVector 接入 + Hot/Cold 分离 + Reranker	v1.6.0 已支持 PG 适配层，改造成本最低
Phase 2	多源对接（百炼/FastGPT）+ MCP Context API + Warm Memory	百炼/FastGpt优先
Phase 3	Governance + 多 Agent 共享 + Context 压缩	企业生产部署必需

你试过的替代方案？（选填）

No response