◂ OpsMate Docs 架构总览 论文解读 检索与证据 MAF 实现 部署 历史报告
AZ OPSMATE · 技术文档集

OpsMate 技术文档架构 · 理论 · 实现 · 部署

基于 dev 分支 993471ff 真实代码统计编写。当前系统与微软研究院开源的 PIKE-RAG 已无共用代码——保留的是论文思想，重写的是全部工程实现。

679
累计提交 · 5 个月
1349
C# 源文件
36
后端模块
57
Agent 与 Skill 定义
目录

从哪里开始读

四份文档各有侧重。若只读一份，读架构总览；若要理解技术选型背后的原因，补上论文解读。

01 · 推荐入口
架构总览 ▸
项目五个月的三次范式转换、与研究院原版的关系、双后端双前端结构、自研 PIKE-RAG 的三条实现路径、模型与外部依赖现状。不了解本项目的人应从这里开始。
02 · 理论基础
PIKE-RAG 论文解读 ▸
arXiv:2501.11551 的通用解读：三大工业挑战、四类问题分级、多层异构知识图、知识原子化与任务分解。含本项目未采纳部分的说明。
03 · 技术核心
检索与证据链路 ▸
全系统技术含量最高的部分。双路召回 + RRF、两段式排序、权限前置、引用可溯源四处硬化，以及「答不出来是合法结果」这条核心原则。
04 · 工程实现
MAF 在项目中的实现 ▸
为何只用 Agent 不用 Workflow、一主九从的委派结构、十六章一章一 Skill、Agent 加工具的能力组合，以及 MAF 依赖深度评估——结论是薄封装而非锁定。
05 · 运维交付
部署方式 ▸
Compose / Nomad / Helm 三套编排、七服务拓扑与启动顺序、配置要点与已知陷阱、结构化数据的 Parquet 落地形态。
附 · 历史存档
早期项目分析报告 ▸
较早阶段的项目分析，含交付数据与贡献者统计。部分技术描述已过时（如本地模型、Workflow 绑定），仅作历史参考。
阅读提示
三处易误判
① Pike.* 命名指向论文方法论，非开源依赖 ② 仓库内 vllm 与 GPU 部署脚本属历史遗留，生产已用 Foundry ③ Workflow 仅用于知识入库，Agent 侧完全不用。
速查

关键事实

代码仓库
github.com/mayong43111/PIKE-RAG · 分支 dev · 快照 993471ff
技术栈
C# / .NET 模块化单体 · React + TypeScript + Vite 前端 · Python 已清零（仅剩 2 个工具脚本）
Agent 框架
Microsoft.Agents.AI 1.10.0 · 只用 Agent 编排，不用 Workflow
对话模型
gpt-5.4 · 云端 Foundry 托管 · 经 AI 网关池化代理
内网服务
仅 Document Intelligence 文档识别容器 · 临床文档不出网
检索
Milvus 混合检索 · dense(COSINE) 与 sparse(BM25) 双路经 RRF(k=60) 融合 · 默认 embedding bge-m3 · rerank 阈值 0.3
MAF 依赖深度
本体仅 3 个项目引用；Workflows 包已显式删除；官方五种编排模式全部弃用。脱离成本约数百行
重写脉络
2026-04-20 起手为「增量共存」，05-29 Python 全删。仓库内无任何 .NET 选型决策文档
业务范围
OpsMate-Ask 问答（GKB / CKB）· OpsMate-MVR 监查报告 · OpsMate-HGR 遗传资源申请（未签约）
本文档基于 github.com/mayong43111/PIKE-RAG dev 分支 993471ff 的真实代码统计生成 · 2026-07-29