Company Brain：用知识图谱+AI Agent打造企业智能知识助手

企业每天沉淀海量员工档案、项目文档、培训记录与内部政策，但这些信息通常散落在表格、数据库和不同部门系统中，找一条信息往往比想象中更费劲。一个名为 Company Brain 的开源项目尝试用「知识图谱 + 专家 Agent + 大模型」的组合，把组织知识变成可以对话查询的助手。它的架构选择和暴露出的安全短板，对想落地企业 AI 助手的团队都有参考价值。

企业知识检索的五个典型痛点

项目作者在背景部分列出了组织信息管理的常见问题：知识分散在多个文件和系统、人工检索记录耗时、传统表格难以表达员工与项目/管理者/培训记录之间的关系、员工不清楚该去哪个系统找答案、多系统切换打断工作流。这些问题指向同一个结论——企业缺的不是数据，而是把数据「连起来」并支持自然语言访问的统一入口。

这一判断与业界对 RAG（检索增强生成）落地的共识一致：单纯堆文档检索容易答非所问，而结构化关系能显著提升答案的准确性与可解释性。

RAG（检索增强生成） 是一种将外部知识检索与大型语言模型生成能力结合的技术范式。其核心流程是：用户提问后，系统先从知识库中检索出与问题相关的文档片段或结构化记录，再将这些内容作为上下文一并送入 LLM，让模型基于这些「证据」而非仅凭训练时的参数记忆来作答。相比直接让模型「自由发挥」，RAG 能显著降低幻觉、提升答案的时效性和可追溯性。业界落地时逐渐发现，单纯依靠向量相似度检索非结构化文档存在局限——当问题涉及实体间关系（如「谁向谁汇报」「某员工参与过哪些项目」）时，结构化知识图谱往往比文本切片更能精准命中。因此「图谱 + RAG」的混合检索成为企业知识助手的重要演进方向。

架构拆解：从 CSV 到对话答案的六步链路

Company Brain 的工作流可以分为六个环节：

1. 数据导入：支持 CSV 格式的员工信息、敬业度调研、招聘记录、培训数据和项目数据。
2. 知识图谱构建：后端把记录写入 FalkorDB，建立员工与管理者、项目、培训记录、调研之间的节点和边，将孤立记录变成可探索的关系网络。
3. 问题路由：用户提问后，系统根据关键词匹配把问题分派给 People & Teams、Projects、Issues & Telecom、Documents、Decisions 等专家 Agent，匹配不上则交给 Generalist 处理。
4. 证据检索：从知识图谱中拉取相关记录，作为回答的数据基础，而不是只依赖模型的参数知识。
5. 答案生成：通过 OpenRouter 调用 LLM，基于检索到的证据生成自然语言回答。
6. 前端呈现：React + TypeScript 构建的仪表盘，包含对话界面、图表、知识浏览器、员工与项目页面、搜索、报告与洞察视图，并支持语音搜索、命令面板、明暗主题和聊天历史。

技术栈方面，后端使用 Python + FastAPI 提供 REST 接口，FalkorDB 存储图谱，Supabase 可选存储对话历史，Streamlit 提供另一套聊天与 CSV 导入界面，Vite 负责前端构建。整体是一个典型的「图谱检索 + Agent 路由 + LLM 生成」三段式架构。

FalkorDB 是一个开源的图数据库，基于稀疏矩阵和线性代数技术实现图查询，兼容 Redis 协议与 openCypher 查询语言（Neo4j 生态常用的图查询语法）。它把数据建模为节点（Node）和边（Edge），节点可带属性，边表示实体间的关系，非常适合表达「员工—管理者」「员工—项目」「员工—培训记录」这类高度互联的数据。相比关系型数据库需要通过多表 JOIN 才能还原关系，图数据库可以用一次遍历直接回答「某员工的上级的下属参与的所有项目」这类多跳查询。在本项目中，FalkorDB 承担了把散落的 CSV 记录转成可遍历关系网络的角色，是「证据检索」环节的数据底座。

相比传统检索，差异在哪里

传统信息系统要求用户导航菜单、套用筛选器、猜测关键词。Company Brain 的差异化在于三点叠加：知识图谱负责组织关系，专家 Agent 负责把问题导向正确的知识域，LLM 负责把检索结果转成易懂的回答。

更关键的是证据可追溯：后端会在回答中附带图谱记录的来源与证据信息，让用户知道答案从哪里来。这一点对企业场景尤为重要——HR 或项目数据的回答如果无法溯源，很难被真正信任。

当前局限：关键词路由与默认开放的数据权限

项目文档罕见地坦率列出了短板，其中两条值得重点关注：

一是路由仍是关键词匹配。 当用户换一种说法提问时，匹配可能失败，作者建议未来引入语义路由来更准确识别意图。

二是默认配置的安全风险。 文档明确指出，当前可选的 Supabase 聊天历史策略允许匿名读写，在真实企业数据上线前必须收紧；同时应补充身份认证、基于角色的权限与访问控制。企业知识涉及员工档案等敏感信息，这一条是落地前的硬性前置条件。

其他待改进方向包括：用测试问题集评估答案的准确性、相关性与证据一致性；通过定时导入保持数据新鲜；引入 embedding 语义检索应对措辞差异；以及增强分析能力以发现缺失信息与使用趋势。作者强调这些是未来方向而非已实现的功能。

关键词路由与语义路由的区别值得展开。关键词路由依赖问题中是否出现预设词表里的词汇来判定意图，实现简单、可解释、无需额外模型调用，但对同义改写、口语化表达和跨领域混合问题很脆弱——用户说「我们组最近谁在带新人」可能匹配不到「培训」词表。语义路由则把用户问题编码为向量，与各专家 Agent 的职责描述向量做相似度比较，或直接用 LLM 做意图分类，从而按「意思」而非「字面」分派。代价是引入 embedding 模型或额外的 LLM 调用，增加延迟与成本，也需要维护各 Agent 的描述语料。从关键词路由过渡到语义路由，通常还会保留关键词作为兜底规则，形成混合路由策略。

RBAC（基于角色的访问控制） 是企业权限模型的常见范式：系统先定义角色（如 HR、项目经理、普通员工），再为角色授予对特定资源的操作权限，用户通过被分配角色间接获得权限。相比给每个用户单独配置权限（ACL），RBAC 更易管理和审计。在企业知识助手场景中，RBAC 决定了「谁能通过对话看到哪些图谱节点和字段」——例如普通员工不应查询到他人薪资或绩效记录。落地时通常还需结合身份认证（如 SSO/OAuth）与字段级过滤，确保检索环节在生成答案前就完成权限裁剪，而不是生成后再遮挡。

适用场景与落地建议

按照项目支持的数据类别，HR 可以用它查询员工信息、培训记录和敬业度调研；项目管理团队可以梳理人员与项目的对应关系；招聘与培训数据也能通过对话方式探索。但效果高度依赖图谱中数据的质量、完整度与可访问性。

对打算借鉴这套方案的团队，可以给出三条实践建议：先从小范围、低敏感度的数据域跑通链路，再逐步扩展 Agent 覆盖的知识域；把证据溯源作为验收指标而非附加功能；在接入真实组织数据前完成权限模型设计，不要沿用开发阶段的默认策略。

Company Brain 的价值不在于它已经是一个成熟的企业产品，而在于它把「图谱组织关系 + Agent 分域路由 + 证据驱动生成」这套组合用一套可运行的开源实现展示了出来，并诚实地标注了从演示到生产之间的距离。