随着 AI 融入企业办公，档案系统正在转变为企业知识底座。我们团队陆续推出了 JitWord 协同 AI 文档、JitKnow AI 知识库、Pxcharts 超级表格等 AI 产品，而面向企业电子档案场景的答案，就是 JitArchives。
这篇文章从产品、技术与落地实战角度，拆解 JitArchives 智能电子档案管理系统，分析传统电子档案痛点、整体技术架构、核心能力、业务价值、适用场景与落地边界，帮技术负责人、档案管理人员看懂新一代智能档案系统的设计思路与实践路径。
一、背景：档案电子化了，却没有"智能化"
在数字化转型浪潮下，绝大多数企事业单位已经完成档案电子化的第一步：把纸质档案扫描、文件上传，搭建电子档案管理平台。
但很多企业普遍会遇到一个困境：档案实现了电子化，却没有实现"智能化"。海量合同、项目资料、制度文件全部存入系统，但查找资料依旧依靠关键词检索，档案之间相互孤立，文件躺在服务器硬盘中成为"沉睡资产"。
传统电子档案系统存在几个现实问题：
- 档案查找只能依靠档号、文件名精确检索，无法直接对附件正文做语义问答；
- 档案与档案之间没有自动关联，想找一份合同对应的验收资料、审批文件，需要人工跨目录翻找；
- 借阅审批、归档流程依靠人工流转，操作追溯依靠手工台账；AI 能力大多停留在噱头层面，容易产生幻觉，无法绑定真实档案证据；
- 不少系统权限只做前端按钮隐藏，后端缺少强校验，存在数据泄露风险。
这套智能电子档案管理系统，定位面向企业组织的新一代电子档案平台：
它不只完成档案存储、著录、归档、借阅的基础业务闭环，更把档案 Agent 智能助理、档案知识图谱深度融入档案全生命周期管理，在传统档案业务底座之上，用轻量化技术方案解决档案检索难、关联发现难、证据溯源难的行业痛点，实现档案"存得稳、管得住、找得到、读得懂、可追溯"。
同时为了实现将传统文档数字化，它集成了 JitWord 协同文档 SDK，能实现线上多人编辑和共享 Word 文档。这个能力在电子档案协同场景里是比较少见的。
今天从业务痛点、产品定位、技术架构、核心模块实现、落地价值、适用场景、能力边界多个维度完整解析这套系统。
二、传统电子档案系统的四大核心痛点
很多单位上线档案系统之后，实际使用率并不高，根源不在于不会操作，而是产品设计依然停留在"电子化库房"思维，没有站在档案利用的角度做设计。
痛点 1：检索能力薄弱，只支持元数据检索 传统系统检索字段局限于档案标题、档号、分类名称。如果用户只记得文档里某一段内容、不记得文件名和档号，就很难定位目标档案。PDF、Word 附件内部的文字内容无法参与检索，大量有价值的正文信息被隔绝在检索体系之外。
痛点 2：档案信息孤岛，缺少关联挖掘能力 合同、项目立项书、验收报告、付款凭证分散为多条独立档案记录，系统不会自动发现档案之间的业务联系。工作人员做审计、项目复盘时，需要人工记忆、手动搜索多份相关档案，效率低还容易遗漏关键材料。
痛点 3：AI 能力"重演示、轻可信"，幻觉风险难以管控 市面上不少档案系统引入大模型，但直接让模型自由生成回答，缺少证据约束。AI 输出无法溯源到原始档案，经常出现编造内容的幻觉。对于档案这种强凭证、强合规的业务场景，直接使用会带来合规风险。
痛点 4：权限管控浮于表面，审计追溯能力不足 部分系统仅在前端隐藏操作按钮，后端接口没有二次校验，存在越权访问、直接拼接文件地址下载附件的安全漏洞；关键操作缺少完整审计日志，档案修改、附件下载、借阅审批行为无法完整追溯。
JitArchives 的整体产品设计正是针对以上痛点展开：完整覆盖档案创建、著录、分类管理、附件上传、归档、借阅审批、操作审计等全流程业务，同时新增档案 Agent 智能助理、档案知识图谱两大 AI 能力，并坚持"证据优先、后端强校验、AI 只读不篡改业务数据"的设计原则，平衡智能化与档案业务的合规底线。
三、产品定位与整体业务能力
系统面向企业、事业单位的内部电子档案集中管理场景，把档案基础业务、全文内容检索、Agent 智能问答、知识图谱关联分析整合到一套 Web 平台中，预设五类业务角色：管理员、审核员、著录员、借阅者、访客，后端完成权限校验。
核心业务能力清单
-
档案资源全生命周期管理：档案新建著录、多级树形分类、档号自动生成，区分草稿与已归档状态，归档后档案进入只读保护；
- 电子附件受控管理：支持 PDF、DOCX、TXT、图片等格式上传，单文件最大 100MB；附件下载必须经过后端权限校验，禁止通过文件路径直接访问；
-
借阅审批全流程：借阅者线上提交申请，审核员处理审批，记录借阅授权、归还全流程；
-
操作审计日志：登录、档案编辑、附件上下载、归档、借阅审批全部记录审计，支持按时间、操作人、业务对象筛选；
-
数据大盘统计：展示档案总量、归档/草稿占比、新增趋势、分类分布、借阅待办；
-
档案 Agent 智能助理：基于自然语言提问检索档案与附件正文，回答全部绑定原始档案证据来源，证据不足时明确告知，禁止 AI 编造内容；
- 档案知识图谱：以节点-连线可视化展示分类、档案、附件、正文知识块之间的关系，自动挖掘结构关系与文本相似关联，支持和 Agent 双向联动。
典型适用业务场景：合同采购档案（采购合同、报价单、验收材料全套关联）、项目档案（立项、实施、交付、验收全流程）、行政制度档案（通知、管理制度、会议纪要）、财务与人事类电子档案管理（内部查阅、审计调阅）。
四、整体技术架构：前后端分离，轻量化不依赖重型中间件
系统采用 Vue3+TypeScript 前端 + NestJS 后端 + SQLite 数据库的前后端分离 Web 架构。
一个很有特点的设计是：系统没有引入独立向量数据库、独立图数据库，依靠 SQLite 内置 FTS5 全文检索、BM25 排序算法完成文本检索；
知识图谱的相似度计算基于 CJK Bigram + TF-IDF 余弦算法在应用层完成，降低部署复杂度，支持 Windows 本地部署、局域网私有化部署，大幅降低中小企业部署运维门槛。
分层技术架构
- 前端展示层：Vue3+Pinia+Vue Router，实现全部业务页面，前端仅做 UI 展示与按钮状态控制，所有权限判断、业务规则全部由服务端执行。前端隐藏按钮不等于权限控制，这是系统安全设计的核心原则。
- 接口接入层：NestJS Controller + Guard 守卫，处理 HTTP 请求，完成登录身份识别、参数校验、第一层权限拦截。
- 业务服务层：拆分用户认证、档案管理、分类、附件、借阅、审计、Agent、知识图谱独立 Service 模块，业务逻辑集中在此层，处理事务、业务状态校验、工具调用编排。
- 数据访问层：基于 SQLite，管理业务数据表、FTS5 全文索引、知识图谱节点与关系数据表；开启 WAL 预写日志，保障并发读写与事务一致性。
- 文件与索引层：本地目录存储电子附件；完成附件正文解析切块，构建全文检索索引；维护知识图谱派生索引。索引属于派生数据，可基于原始档案数据全量重建。
- 外部模型服务层：对接兼容 Chat Completions 协议的大模型 API（DeepSeek、Kimi、通义千问等）。模型只接收受控的只读检索结果，没有直接访问数据库、文件存储的权限。
重要设计原则：业务源数据与派生索引分离。 全文索引、知识图谱都属于派生数据，如果索引损坏，可以直接基于原始档案、附件重新构建，不会破坏真实业务档案数据。
关键安全设计理念
- 密码使用 scrypt 哈希存储，不保存明文密码；登录态采用 HttpOnly Cookie，浏览器脚本无法读取会话凭证；
- 附件下载接口每次都校验用户对档案的访问权限，禁止路径穿越漏洞，不能依靠构造 URL 直接下载文件；
- Agent 智能助理全部采用只读工具集合，AI 不能修改、新增、删除任何档案业务数据，只能查询有权限看到的内容；
- 所有检索（包括 Agent、知识图谱读取数据）全部携带当前用户权限过滤条件，不会越权返回用户无权查看的档案；
- 关键业务变更和审计记录放在同一个数据库事务内，保证操作和日志记录一致性。
五、两大 AI 核心模块技术实现：档案 Agent 与知识图谱
市面上很多档案系统的 AI 只是简单把文档片段塞进 Prompt 交给大模型，缺少完整的工具调用、权限过滤、证据核验链路，很容易出现幻觉。这套系统针对档案凭证类业务，设计了一套证据驱动的 AI 工作流。
5.1 档案 Agent 智能助理：证据优先的问答链路
Agent 完整处理链路分为 7 个步骤：用户自然语言提问 → 需求理解与检索规划 → 权限约束下执行检索工具 → 证据整理与评估 → 引用核验 → 基于证据生成回答 → 返回带来源引用的结果。
- 问题理解与检索规划：大模型解析用户问题，识别业务对象、时间范围、查询目标，生成结构化检索计划。系统对计划做白名单校验，禁止模型直接生成 SQL 语句；
- 受控只读工具调度：工具注册表限定可调用能力，包括档案元数据查询、分类查询、附件正文片段读取、全文检索，全部只读。工具执行时自动带入当前登录用户的访问权限；
- 证据评估：系统评估检索到的材料是否足够回答问题，如果证据不足，不会强迫模型编造答案；
- 引用核验：校验 AI 回答引用的档案、附件定位是否真实存在，引用失效就降级提示证据不足；
- 结果输出：返回回答同时附带来源档案、附件摘录定位；无可靠证据直接告知未找到相关资料。
Agent 不是替代人工审批，只做检索、信息整理辅助。档案归档、借阅审批等关键业务操作依旧需要拥有权限的人工完成。
5.2 档案知识图谱：不依赖向量库的关联挖掘实现
档案知识图谱把分类、档案、附件、正文片段抽象成节点，把业务归属、包含关系、文本相似抽象为关系边。图谱数据全部是派生索引，不能替代原始档案作为业务凭证。
- 节点类型：分类节点、档案节点、附件节点、正文知识块（Chunk）节点；
- 真实结构关系：分类包含档案、档案包含附件、附件包含正文片段，来自真实业务数据，100% 可信；
- 文本相似关系：基于 CJK Bigram 二元分词、TF-IDF、余弦相似度计算得到正文内容相似关联。这里要重点注意：正文相似不等于真实业务关联，仅作为线索，需人工对照原始档案确认业务事实。
更新机制支持全量重建、单档案增量刷新；档案、附件删除时自动清理对应图谱节点与关系。图谱还可与 Agent 联动：用户在图谱选中某一档案节点，可直接把上下文带入 Agent 继续提问，实现"看图→提问→查阅原文"的闭环。
技术亮点：整套图谱相似度计算不需要 Embedding 向量模型，不需要部署向量数据库，普通 PC、服务器即可运行，降低私有化部署硬件依赖。
六、业务落地价值：解决档案"存、管、查、用"四大难题
价值 1：降低档案日常管理成本 系统标准化档案创建、著录、分类、归档、借阅归还流程。著录员专注录入、审核员处理审批、管理员负责权限，职责边界清晰。归档完成后档案自动只读保护，避免误修改；数据大盘快速统计档案规模与待办审批。
价值 2：提升档案查找利用效率 传统模式下只记得文档片段很难定位档案；现在可以直接用自然语言描述需求，Agent 自动检索档案元数据 + 附件全文。例如"帮我查找本年度设备采购相关的全部合同"，不需要记住档号和文件名即可召回，并附带原文证据来源。知识图谱帮助使用者从一份档案向外辐射，快速发现一批潜在相关资料。
价值 3：构建完整安全与审计能力 服务端多层权限校验，严格控制档案查看、附件下载权限；所有关键业务行为留存审计日志，可回溯"谁、什么时间、做了什么操作"；归档档案只读、附件访问强授权。
价值 4：轻量化私有化部署 基于 SQLite 实现核心存储与检索，支持 Windows 本地部署、局域网内网部署，数据全部保存在内部环境，不需要上公有云 SaaS，兼顾数据安全与运维成本。
七、落地实施的适用场景
适合落地的组织：
- 中小型企事业单位，需要私有化电子档案管理、预算有限、不想维护复杂中间件；
- 拥有大量合同、项目、行政、财务电子文档，经常需要调阅附件正文；
- 档案团队人手有限，希望借助 AI 提升检索效率，同时严格控制 AI 幻觉风险；
- 需要完整操作审计日志，对内审、外审有合规追溯需求；
- 内网局域网环境部署，不希望档案数据上传公网 SaaS 平台。
八、客观看待能力边界，避免预期偏差
任何软件都存在能力边界，正确理解边界，才能合理规划落地路径：
- 全文检索基于 FTS5/BM25 词法检索，不使用 Embedding 向量检索；知识图谱相似度为 TF-IDF 余弦计算，不是大模型 Embedding。优势是部署简单，缺点是深度语义泛化能力弱于向量检索；
- Agent 智能问答依赖附件能提取出可复制文本，图片扫描 PDF 无法解析正文，不能参与正文问答；
- 知识图谱中文本相似关系仅为线索，不等同业务事实，业务判断依旧需要人核对原始档案；
- 当前档案级权限是角色 + 访问级别模式，暂不支持完全自定义的档案 ACL 细粒度授权；
- Dockerfile 配置文件存在，但需要使用者完成环境验证，开箱即用的容器生产环境需自行验收；
- HTTPS、CORS 安全头、密钥保护属于部署侧配置，软件本身提供能力，需要运维人员在部署阶段配置完成。
九、写在最后：新一代档案系统，不是把纸质文件搬上网
回顾电子档案系统发展历程：第一代是纸质档案电子化扫描存储，解决"存下来"；第二代实现元数据检索、线上借阅审批，解决"管起来"；而新一代智能档案系统，目标是解决"用起来"。
很多单位投入资金建设档案系统，最后档案存满硬盘却很少被查阅，本质就是只完成存储、没有解决利用的问题。但档案业务又具备极强的合规、凭证属性，不能无限制放任大模型自由发挥，不能为了智能化牺牲可信、可追溯的底线。
这套系统给出的是一套平衡方案：传统档案业务底座保证合规管理；全文检索挖掘附件内容价值；Agent 坚持证据驱动，回答全部溯源原始档案；知识图谱提供关联线索但区分"真实业务关系"与"文本相似线索"；同时用轻量化技术架构，降低私有化部署门槛。
AI 不是用来替代档案工作人员，而是把人员从反复翻找档案、手工整理关联资料这类重复劳动中释放出来，把精力放在档案鉴定、业务判断、资料审核这些更有价值的工作上。
对于正在选型电子档案系统的团队，选型时不仅要看演示界面是否炫酷，更要重点考察：权限是否全部后端校验、AI 回答是否可以溯源原始材料、索引是否可以基于源数据重建、系统能力边界是否清晰——这些才是决定系统能否长期稳定运行的关键要素。如果你也在做档案数字化、AI + 档案相关方向，或对这套证据驱动方案有想交流的实现细节，欢迎一起探讨。
