CyberSelf：实验室专属赛博师兄计划（5）——CampusLab维度知识库搭建

CyberSelf：实验室专属赛博师兄计划（5）——Campus&Lab维度知识库搭建

背景与动机

在高校科研环境中，信息的获取往往依赖于非正式渠道——群聊记录、口耳相传、散落在各处的通知文件。这种信息分布方式导致了显著的知识摩擦：同样的问题被反复提问，新成员的入组成本居高不下，隐性知识难以沉淀。

本项目的目标是将这些碎片化的隐性知识系统化，构建一套可被 AI Agent 直接调用的结构化知识库，服务于中国民航大学 ISECCA 实验室的日常运转。

整体架构设计

知识库采用MOC（Map of Content）路由架构，核心思路是将"知识定位"与"知识存储"分离。每个维度下设一个顶层索引文件（_*.MOC.md），负责描述该维度的覆盖范围和子模块路径，Agent 在处理用户问题时先通过 MOC 定位领域，再进入对应子目录检索具体答案。

knowledge_base/ ├── MOC.md # 全局入口，维度路由 ├── campus/ │ ├── _campus.MOC.md # campus 维度索引 │ ├── facilities/ │ ├── graduation/ │ └── procedures/ └── lab/ ├── _lab.MOC.md # lab 维度索引 ├── management/ ├── reimburse/ └── service/

这种两级路由结构（全局 MOC → 维度 MOC → 子模块）使得知识库在规模扩展时仍能保持检索效率，避免了单一大文档带来的上下文污染问题。

每个子模块内部遵循统一的文件约定：faq.md承载问答对，独立的.md文件承载需要详细展开的参考文档。这种分层存储策略兼顾了 Agent 的快速检索需求与人工维护的可读性。

campus 维度：校园公共信息层

campus 维度覆盖学校层面的公共信息，当前包含三个子模块。

facilities 模块目前仅聚焦图书馆资源。
graduation 模块建模了硕士毕业的约束条件集合。

procedures 模块覆盖行政流程，目前包含就业三方协议的签订/解约流程和保密审批表的盖章流程。行政流程类知识的特点是步骤强依赖、顺序敏感，FAQ 格式能够有效支持 Agent 进行流程引导式问答。

lab 维度：实验室运营信息层

lab 维度面向实验室内部，信息粒度更细、时效性要求更高。

management 模块覆盖实验室的物理空间信息、人员职责分配、计算资源访问方式，以及学术诚信与信息安全规范。后者包含了对 AI 工具使用的明确约束，体现了实验室在 AIGC 时代的合规管理意识。

reimburse 模块是该维度中信息密度最高的部分。模块对可报销类别进行了完整枚举，并为每个类别定义了所需凭证的具体格式要求。此外，模块还内嵌了学校的标准开票信息，使 Agent 能够在报销咨询场景中提供端到端的完整指引。

service 模块维护实验室的基础服务信息：网络接入凭证、后勤联系方式、算力资源清单及申请路径。这类信息变更频率较低，但对新成员的入组体验影响显著。

设计模式总结

纵观两个维度的构建，可以提炼出以下几个核心设计决策：

分层路由而非全文检索。MOC 索引机制将问题分类与答案检索解耦，降低了 Agent 在大规模知识库中的检索噪声。

FAQ 与参考文档分离。高频问答存入faq.md，需要详细展开的内容（如图书馆详情、学位标准）独立成文，保持了文件粒度的合理性。

信息精确化优先。知识库中大量记录了具体数值、账号、联系方式等精确信息，而非模糊描述。这是面向 Agent 调用的知识库与面向人类阅读的文档之间最本质的区别。

维度正交性。campus 与 lab 两个维度在信息覆盖上保持正交，避免了冗余存储和一致性维护的负担。

后续规划

research 维度目前处于规划阶段，预计覆盖科研工具链、论文写作规范、期刊投稿流程等内容，将进一步完善知识库对实验室全生命周期场景的覆盖。随着维度数量增加，全局 MOC 的路由逻辑和各维度索引的维护机制也将是下一阶段需要重点关注的工程问题。

知识库已经呈现雏形，后续就进入模型部署和实践操作环节啦，非常期待他回复的第一句话。当然在这个过程中还是要持续维护知识库内容，有什么好的建议欢迎交流~