ARTICLE · 1106246
WeKnora 架构全景:从文档问答到企业知识平台
一个售后团队决定把散落的产品手册、退款规定和处理记录放到一起，让同事直接向 AI 提问。
最初的愿望很简单：少翻文档，快一点找到答案。真正开始使用后，问题却接连出现。
扫描版 PDF 能不能读懂？新规定上传后何时可以查到？不同团队能否只看自己的资料？如果需要比较政策、整理反馈、生成报告，系统还能继续做吗？
这些问题，逐渐把一个聊天窗口变成了一套知识平台。
腾讯开源的 WeKnora 提供了一个值得观察的样板：它把文档处理、检索问答、任务执行和知识整理放在同一套系统里。
本系列从架构、RAG、Agent、Wiki 和协作机制五个角度展开。第一篇先建立全景：各部分负责什么，为什么这样分工，以及一份资料如何走到用户面前。
先看它提供的三种能力
面对一批资料，人们通常有三种不同需要。
知道问题的人，希望迅速找到依据；接到任务的人，希望有人协助查阅、比较和产出；刚进入一个领域的人，则需要一份能帮助自己理解背景的知识地图。
WeKnora 用三种能力回应这些需要：
三者共享知识库，但工作方式不同。
RAG 有预先安排的问答步骤，Agent 可以根据中间结果调整行动，Wiki 则是可以被阅读、检索和修订的内容。
后面几篇会分别展开；现在先记住，系统需要同时支持“查资料”“做事情”和“积累知识”。
系统全景：用户看见的界面之外，还有哪些部分
从外部看，WeKnora 有网页界面，也可以通过接口和消息渠道接入其他工作场景。
从内部看，业务主应用居中协调，周围连接着解析、模型、存储和任务处理等能力。
下面是一张经过简化的系统地图。连线表示主要协作关系，不代表每次请求都会经过全部组件。
网页主要负责接收操作、展示内容和反馈进度。Go 编写的业务主应用负责判断“谁能做什么”“这件事应该怎样进行”，以及“结果应该交给谁”。文档解析部分包含 Python 服务，用来承接多种格式的内容提取。模型和检索、存储组件则提供各自的专业能力。
其中，“保存数据”还需要进一步区分。原始文件要保留，用户与知识库的关系要记录，适合检索的内容也要建立索引。它们承担不同职责，即使某种部署把部分数据放进同一个数据库，也不能把这些职责混为一谈。
长文档解析和批量知识维护可能耗时较长，任务执行机制负责安排这些工作。在配置了队列的部署中，它们可以交给后台处理；轻量部署则采用相应的本地替代方式。可选的图检索、外部工具和执行环境，也按需要接入。
这张图最重要的信息是：聊天界面只是入口，业务主应用负责把多种专业能力组织成一项完整服务。
五个设计思路，贯穿整套系统
组件一多，真正的难题就是管理变化。模型会换，文件类型会增加，部署规模会变化，前端也可能从网页延伸到其他渠道。WeKnora 的几个设计选择，都与这些变化有关。
先约定能力，再连接具体实现
业务流程需要的是“保存文件”“查找相关内容”“调用模型”等能力。至于文件存在本地还是对象存储、检索由哪一种引擎完成，可以交给对应组件。
这些约定在软件中称为接口。它们让更换某个外部服务时，修改尽量集中在连接处。代价是系统需要维护更多适配工作，而且不同产品的能力差异仍然存在。支持替换，不等于任何组合都有相同效果。
在启动时把组件组装起来
文档处理需要解析和存储，问答需要模型和检索，知识维护又需要任务执行。WeKnora 在启动时集中连接这些依赖，相当于先确认各项工作由谁承接，再开始接收请求。
核心依赖出现问题时，可以尽早暴露；部分可选能力则允许记录错误后继续启动。这种区别很实际：某个扩展没有配置好，不一定要让整个系统都无法使用，但必需的基础能力不能缺席。
按部署条件选择实现
一个人试用，与一个团队多人使用，需要的基础设施不同。WeKnora 根据配置选择组件：有共享服务时利用共享状态和任务队列，没有时为部分能力提供本地替代。
因此，业务层可以沿用相近的工作方式，而部署者不必在第一次体验时就准备最完整的环境。需要付出的维护成本，是同时照顾不同运行条件下的行为和限制。
把流程推进和进度通知分开
“接下来该做什么”和“告诉用户刚才发生了什么”是两件事。
问答内部需要按顺序完成检索、整理和生成；页面则需要知道检索何时开始、回答何时产生新内容。WeKnora 为它们采用不同机制，让流程组织和对外通知各自演进。
这样，新增一种进度展示方式时，不必重新安排整个问答流程。反过来，调整检索步骤，也不必让业务逻辑依赖某个具体聊天界面。
在变化频繁的位置保留扩展空间
模型、检索引擎、对象存储、数据源和消息渠道，都是企业环境中容易出现差异的地方。WeKnora 在这些位置提供适配入口，接入企业已有资源。
这个选择增加了配置和验证工作，却也降低了采用新平台时“一切重来”的阻力。评估时，应重点看自己准备使用的组合能否正常运行，而不是只看支持列表有多长。
业务主应用内部，怎样分工
外部组件说明了系统由什么组成，内部职责则决定一次操作怎样被处理。
以知识库相关业务为例，可以把职责理解为四组。下面是职责关系示意，具体业务会按需要调用数据访问或基础能力。
请求处理层把用户操作转换成系统能理解的请求；业务层决定怎样完成；数据访问层负责记录和查询；基础能力层提供解析、分块、网页获取等支撑。
拿“上传一份退款规定”来说，接收文件、判断能否写入知识库、安排内容处理、保存处理结果，都有各自的责任位置。权限也会在入口和具体资源访问处受到检查，不能只凭用户已经登录就放行所有操作。
分层的价值，在于让问题和变化有明确落点。文件内容读错了，应重点检查解析环节；用户看到了不该看的资料，应检查访问范围；页面迟迟没有更新，则要沿状态记录和通知链路查找原因。
它也有成本：一项操作会跨越多个组件，理解和排查需要沿着流程走。架构设计因此还要配合日志、进度和错误反馈，才能让分工真正可维护。
沿着一次上传、一次提问走一遍
全景图说明位置，实际流程说明这些位置如何协作。
上传时，系统把文件变成可用资料。接收文件后，先检查身份、知识库权限与文件信息，再安排解析。提取出的内容被切成适合检索的片段，相关记录进入存储，并建立检索索引。如果知识库启用了 Wiki，还会触发主题知识页的生成与维护。
所以，“上传成功”“解析完成”“能够检索”“Wiki 更新完成”是不同阶段。用户已经看见文件名，并不代表所有后续处理都结束了。
提问时，系统把资料变成回答依据。常规知识问答先结合历史理解问题，再寻找相关内容，整理证据并交给模型生成回答。过程事件和回答内容通过流式通道送回页面，让用户逐步看到进展。
如果进入 Agent 执行路径，系统还会根据所选资料和允许使用的工具，准备任务环境，由模型决定下一步行动。它可以检索资料，也可以读取 Wiki，具备相应工具时还可以继续处理文件或生成产物。
两条使用路径共享基础资源，但各自采用适合任务的推进方式。这也是后续理解 RAG 与 Agent 差别的起点。
从个人试用到团队使用，哪些条件会变化
WeKnora 提供轻量运行方式，也支持依赖更多共享服务的部署。两者的差别，主要体现在任务协调和状态保存上。
轻量方式适合较快验证资料和模型的实际效果。用户增加后，需要重新检查任务吞吐、资源共享、访问控制和运维条件，不能仅靠增加应用副本解决所有问题。
这种设计提供了一条连续的采用路径：先获得有效体验，再补齐团队运行所需的条件。
读懂架构之后，再看每项能力
WeKnora 的架构把几个经常被低估的问题放到了台前：文档需要持续处理，模型需要被组织调用，知识需要维护，用户需要知道过程发生了什么。
对于使用者，这些问题决定系统是否适合进入日常工作；对于建设者，它们决定一个演示能否长期运行。接口、分层和组件装配的意义，最终都会落到这些具体体验上。
接下来的 RAG 篇，将沿着一条退款规定，观察文件内容如何变成可核查的回答依据；Agent 篇讨论任务如何被推进；Wiki 篇讨论知识如何被整理和更新；最后再把三者放回同一个使用过程。