很多团队搭知识库的第一次演示都很顺：上传几份文档，切块、向量化、接上模型，问答就能跑。真正卡住的是第二周——第二个部门要进来，第三个角色要限制检索范围，某个智能体还要调用外部工单系统。这时问题不再是“能不能答”，而是“谁能在哪个租户里、通过哪个工具、看到哪部分知识”。Yuxi 这类项目值得关注的地方，也正在这里：从公开介绍看，它把 RAG、知识图谱、多智能体、Skills、MCP、沙盒、多租户与权限管理放进了一个可自托管的工作台。本文不从功能清单出发，而是按多租户与权限边界做一份落地前检查。
先判断：你需要知识库，还是知识智能体工作台
只做文档问答的团队，用轻量 RAG 往往更快：一个向量库、一套切块与召回策略、一个模型接口，先把答案质量和引用做好。Yuxi 的定位更接近“知识智能体工作台”：除了检索，它还涉及 Agent 编排、知识图谱、外部工具调用和沙盒执行。能力越多，权限面越大，落地前要检查的对象也越多。
| 你现在的信号 | 更建议的起点 |
|---|---|
| 单一团队、文档量有限、只问不改 | 轻量 RAG，先验证召回与引用 |
| 多部门共用，但暂不调用外部系统 | 多租户 RAG，先做租户与知识库隔离 |
| 需要多步任务、工具调用、代码执行 | 知识智能体工作台，补沙盒与工具权限 |
| 问题大量涉及实体关系、多跳推理 | 在 RAG 稳定后评估知识图谱 |
| 要求私有化、数据不出内网 | 自托管部署，先核验许可证与运维成本 |
这张表不是选型结论，而是检查顺序。Yuxi 是否适合，取决于你的权限边界是否已经清楚，而不是它功能数量是否足够。
检查一：模型接入与推理链路是否可控
公开资料显示，Yuxi 借 LangGraph 完成 Agent 编排。这意味着模型调用不是孤立的一问一答，而是和检索节点、工具节点、子智能体节点串在同一条链路里。落地前要确认的不是“能不能填 API Key”，而是模型接入后，权限与成本能否被管住。
检查项可以包括：
- 是否支持你现有的模型网关或 OpenAI 兼容端点；本地模型与外部模型能否按租户分别配置。
- 模型密钥存放在哪里，是否能按租户隔离，普通知识库编辑是否看不到密钥。
- 是否能把 token 消耗、调用次数归集到租户或应用，而不是只看到一个全局账单。
- 检索节点、工具节点和最终回答节点是否都带租户上下文；子智能体是否继承父级权限，还是拥有更大的默认权限。
- 回答附引用时，引用片段是否经过权限过滤。否则“引用”可能绕过检索权限，把无权文档的片段带出来。
如果模型接入层没有租户维度的限流和计量，多租户就容易变成“共用一把钥匙”。这类问题在上线前不显眼，账单和越权事故出现时才难补。
检查二：租户与角色边界是否贯穿到检索层
多租户不是登录页加一个组织字段。真正的边界要落到资源对象上：知识库、文档、切片、向量集合、图谱节点与边、会话历史、工具凭据、沙盒产物，都要能回答“属于哪个租户、谁能读、谁能写、谁可授权”。
下面是一张评审时用的权限矩阵示例，不是 Yuxi 的默认配置，而是落地时至少要问清的粒度：
| 资源对象 | 要问的问题 | 常见失败信号 |
|---|---|---|
| 知识库 | 能否跨租户共享？共享是只读还是可检索？ | 共享后检索结果混入其他租户文档 |
| 文档与切片 | 删除文档后，向量与图谱是否同步清理？ | 文档删了，旧切片仍被召回 |
| 向量集合 | 是否按租户或知识库分集合，还是只靠元数据过滤？ | 过滤条件写错就全量召回 |
| 知识图谱 | 节点与边是否继承文档权限？ | 图谱路径暴露无权实体关系 |
| 会话历史 | 租户管理员能否导出、普通用户能否删除？ | 会话跨租户可见或无法审计 |
| 工具凭据 | 凭据是按租户注入，还是全局共享？ | 一个租户的工具调用消耗另一个租户额度 |
角色划分也建议先做最小矩阵：平台管理员、租户管理员、知识库编辑、普通问答用户、工具调用审批人。重点检查权限继承和最小权限，而不是角色名称是否齐全。比如知识库编辑能否给自己授权一个高权限 MCP 工具？子智能体能否绕过审批直接调用写操作？这些问题要在试点租户里实际验证。
检查三：MCP、Skills 与沙盒带来哪些安全边界
MCP 让智能体连接外部系统，Skills 把可复用能力封装起来，子智能体负责分工，沙盒用来执行代码或隔离工具运行。它们组合起来很有用，但也把风险从“答错一句话”扩大到“调错一个接口”。
落地前建议逐项检查：
- 工具白名单：MCP 服务是否按租户、按知识库授权；默认是拒绝还是允许。只读工具与写工具是否分开审批。
- 凭据注入：工具凭据是否按租户注入，是否能在日志、提示词和回答中被带出。沙盒内能否读到宿主机环境变量。
- 沙盒边界：网络出口是否受限，文件系统是否只挂载必要目录，CPU、内存、执行时长是否有配额。沙盒不是万能隔离，仍要看底层运行时和逃逸风险。
- 高风险动作审批：发邮件、改工单、执行 SQL、调用支付类接口，是否要求人工确认或二次授权。
- 审计与回放：谁在哪个租户、用哪个智能体、调用了哪个工具、输入输出是什么，能否追溯。回答附引用和推理过程有据可循，不等于审计日志完整。
- 提示注入防护：外部文档和工具返回内容是否会被当作指令执行；MCP 返回的文本是否经过隔离。
一个实用做法是先用只读 MCP 工具跑通，再逐步开放写操作。沙盒先限制网络和文件系统，再观察真实任务需要什么。不要一开始就把“能调用一切”当作能力证明。
检查四：知识图谱是不是必需
公开介绍提到 Yuxi 以 Milvus / Neo4j 为基础搭建知识图谱。图谱适合实体关系密集、需要多跳推理、需要解释路径的场景，比如设备故障链、供应链关系、售后件与车型的关联。但它不是 RAG 的默认升级项。
可以用下面的判断表做取舍：
| 你的问题形态 | 轻量 RAG 是否够用 | 引入图谱的理由 |
|---|---|---|
| 文档段落问答、政策查询 | 通常够用 | 图谱收益有限，先优化切块与召回 |
| 多实体关联、跨文档关系 | 可能不够 | 需要实体抽取与关系路径 |
| 需要解释“为什么关联” | 引用片段较难表达 | 图谱路径可辅助解释 |
| 实体更新频繁、关系易变 | 维护成本高 | 要评估抽取质量与更新机制 |
| 权限粒度到文档 | 较直接 | 要检查节点与边是否继承权限 |
如果决定引入图谱，至少要检查实体抽取质量、图谱更新与版本、节点与边的权限继承，以及 Neo4j 的备份和运维成本。对多数团队来说，先用 RAG 验证答案质量和用户需求，再决定是否上图谱，风险更低。
检查五：部署、许可证与运维底线
从公开信息看，Yuxi 支持 Docker 部署，定位偏向自托管。落地前要核验许可证与依赖许可：项目对外标注为 MIT 许可证，但具体以仓库 LICENSE 文件、第三方依赖许可和发布页为准。涉及版本、镜像标签、接口兼容性和星标等时效数据，发布前应联网核验，不宜把旧截图当结论。
运维上至少要确认：Milvus、Neo4j 与关系型数据如何备份恢复；升级时向量与图谱是否需要重建；租户删除后数据如何清理；日志、指标和告警是否覆盖检索、模型调用、工具调用与沙盒执行。自托管意味着数据控制权更大，也意味着这些责任在你这边。
哪些团队更适合先用轻量 RAG 验证
如果文档量不大、用户集中在少数团队、没有外部工具调用、也不要求多租户隔离，轻量 RAG 更容易在两周内验证价值。此时引入知识图谱、MCP 和沙盒，只会增加配置面和排错成本。
相反，如果你已经出现这些信号，Yuxi 这类工作台值得进入试点：多个部门共用知识但必须隔离；智能体需要调用工单、CRM 或内部 API；需要对工具调用做审批和审计；有私有化部署要求；问题开始涉及实体关系和多跳推理。试点时建议按“单租户单知识库 → 双租户隔离 → 角色矩阵 → 只读 MCP → 受限沙盒 → 审计回放”的顺序推进，每一步都留下验证记录。
功能多不是采用理由，权限边界清楚才是。先画出你的租户、角色、知识资源和工具调用关系，再决定要不要知识图谱、要不要开放写操作。Yuxi 提供了一个可自托管的知识智能体工作台选项，但最终能否落地，取决于你是否愿意把多租户与权限管理当成第一等需求来检查。
评论列表 (1条)：
加载更多评论 Loading...