第一个企业 Agent 项目上线时，把知识库直接做进应用里，通常是正确的选择。
要接的数据不多，场景也很清楚：找几份文档，做解析、切分和索引，再把检索结果交给 Agent。团队能迅速验证业务价值，工程边界也足够紧凑。问题不是从第一个 Agent 开始的。
问题出现在第二个、第三个场景陆续出现之后：面向员工的制度问答、面向客户的产品顾问、面向交付团队的项目助手，开始都需要“懂公司知识”。每个项目都可以很快接上一套知识库；但很快就会发现，大家重复建设的是同一段基础能力。
重复的从来不只是一份文档
最直观的重复是数据源接入。相同的产品资料、制度和项目文档，被不同系统各自上传、解析和同步。随后是更难看见的重复：
- 每个团队各自决定文档怎么清洗、怎么切分；
- 每个团队各自维护向量索引和全文检索；
- 每个团队各自处理部门、客户或项目之间的访问权限；
- 每个团队各自排查“为什么这次没有检索到”的问题；
- 每个团队各自处理文档更新、重试和历史版本。
一开始，这些都像是业务实现的一部分。可当 Agent 变多，问题会从“重复写了一些代码”变成“企业里出现了多套不一致的知识事实”。
同一份制度更新后，一个 Agent 已经看到新版，另一个仍引用旧版；某个检索结果无法说明来自哪份文档、哪个版本；权限规则散落在多个应用中，排障时也很难说清问题在数据、检索还是 Agent 本身。
应该共享的是知识处理能力
我后来把这件事换了一个角度理解：企业要共享的不是某个 Agent 已经导入的文档，而是文档变成可用知识的过程。
这层能力至少应当统一处理：
- 文档导入、版本与资产归档；
- 面向不同工作区的权限和隔离；
- 分块、向量检索与全文检索；
- 每次检索返回的来源锚点和证据；
- 更新、失败重试与可观察的状态。
上层 Agent 则继续专注自己真正不同的部分：理解任务、调用工具、组织流程、提示词和最终回答。它们消费知识能力，而不是各自重新拥有一套知识处理流水线。
这不是说所有东西都要拆成平台。只有一个场景时，应用内聚依然是更快的选择。真正的临界点是：当多个团队、多个项目或多个客户开始反复建设同一种知识接入与检索能力时，它已经是基础组件，而不再只是某个 Agent 的内部细节。
琅嬛放在这个边界上
琅嬛不负责 Agent 编排，也不生成最终答案。它把文档处理为可检索、可追溯的知识，再通过 REST 和 MCP 提供给不同的上层应用。
具体来说，它把工作区隔离、文档版本、混合检索和来源锚点放在同一条知识处理链中。这样，多个 Agent 可以使用同一套事实基础；出现召回问题时，也能回到具体文档和位置，而不是只面对一段不可解释的上下文。
项目的能力边界和架构可以在 琅嬛仓库 与 架构文档 中核对。
如果你的团队正在从一个 Agent 走向多个 Agent，值得先问一个问题：下一套知识库，真的还应该从头建在下一个应用里吗？