WeKnora 源码架构分析：对齐 IMA 前必须看清的现有基础

这篇文章只基于本地源码和文档判断 WeKnora 的现状，源码根目录为 /Users/colin/code/WeKnora。它的目的不是重复 README，而是为后续“靠拢 IMA PC 端工作台”建立准确地基。此前如果简单写成“WeKnora 没有记忆、没有任务、没有浮窗”，会误导实施路线。更准确的判断是：WeKnora 已经有不少底层能力，但这些能力还没有被组织成 IMA 式 PC 端 Copilot 工作台。

一、总体架构基础

WeKnora 是 Go 后端、Vue 3 前端、Python docreader、MCP Server、微信小程序、Chrome 扩展和多种部署脚本组成的知识管理框架。README_CN.md 明确把产品定位为“RAG、Agent 推理与自动 Wiki 一体化的知识框架”，并列出 RAG 快速问答、ReAct Agent、Wiki 模式、多源数据接入、网站嵌入 Widget、主流模型厂商集成、Langfuse 可观测性、多租户 RBAC 和私有化部署等能力。

从目录结构看，后端核心在 internal，前端核心在 frontend/src，文档解析在 docreader，MCP 独立能力在 mcp-server，数据库迁移在 migrations/versioned。这说明 WeKnora 不是一个简单聊天 Demo，而是一个已经具备企业级边界、权限、凭证、异步任务和多端入口的系统。

二、知识库与文档处理能力

WeKnora 的知识库能力已经覆盖 IMA 对标路线中最重要的“资料入库”基础。README_CN.md 写到它支持 PDF、Word、Txt、Markdown、HTML、EPUB、MHTML、图片、CSV、Excel、PPT、JSON 等格式，并支持文件夹导入、URL 导入、多标签管理、在线录入、批量重新解析和按批次解析配置。

本地文档 /Users/colin/code/WeKnora/docs/数据源导入开发文档.md 进一步说明数据源导入模块采用连接器注册表、数据源服务、Cron 调度和 asynq 任务队列。一个数据源绑定到一个知识库，可以接入飞书、Notion、语雀、RSS 等外部平台，并记录同步日志、同步状态、增量游标、冲突策略和删除同步策略。这个基础对齐 IMA 的知识库广场之前已经足够扎实，因为 WeKnora 现在缺的不是“导入文件”，而是“导入后的知识资产分发和能力绑定”。

检索层面，README_CN.md 列出 BM25 稀疏召回、Dense 稠密召回、GraphRAG、父子分块、pgvector HNSW、多向量数据库和端到端测试。源码中 internal/application/service/knowledgebase_search.go、knowledgebase_search_fusion.go、knowledgebase_search_fanout.go 与 retriever 目录支撑了这些能力。对标 IMA 时，应当复用这些检索管道，而不是另起一套“任务模式专用检索”。

三、AgentQA 与 ReAct 能力

WeKnora 的 Agent 入口在 /Users/colin/code/WeKnora/internal/application/service/session_agent_qa.go。AgentQA 会解析自定义 Agent 配置，解析知识库范围、模型、rerank 模型、历史上下文、MCP 服务、Skills、图片与附件，随后通过 agentService.CreateAgentEngine 创建执行引擎，并调用 engine.Execute 流式返回结果。

这条链路已经包含若干 IMA 需要的基础：它有多轮历史加载，有知识库与具体文件范围，有 Web Search 开关，有 MCP 和 Skills 的运行时注入，有图片和附件内容注入，也有事件总线向前端推送 Agent 思考、工具调用、工具结果、引用和最终答案。它的问题不是“不能调用工具”，而是还缺一个更高层的任务编排层。当前 ReAct 循环关注“回答这一次问题”，而 IMA 的任务模式关注“围绕一个目标规划、执行、确认、产出和保存一组文件”。

四、MCP 与 Skills 基础

WeKnora 在 MCP 和 Skills 上与 IMA 的差距较小。docs/MCP功能使用说明.md 描述了前端 设置 -> MCP 服务 的集中管理入口，支持 SSE、HTTP Streamable 和 Stdio，支持认证配置、超时、重试、连接测试和工具清单展示。frontend/src/views/settings/McpSettings.vue 和 frontend/src/views/settings/components/McpServiceDialog.vue 负责管理界面，后端 internal/application/service/mcp_service.go 与相关 repository 负责持久化、测试和调用。

Skills 方面，docs/agent-skills.md 明确采用 Progressive Disclosure，分为元数据、完整指令和附加资源三级加载。types.AgentConfig 中已经有 SkillsEnabled、SkillDirs 和 AllowedSkills 字段，运行时也支持 PinnedSkillNames。这与 IMA 公开强调的“Skills 是领域知识，MCP 是外部工具”非常接近。真正的差距在产品层：IMA 有 Skill 广场和能力发布路径，而 WeKnora 目前更像租户内可配置能力，还没有形成“可发现、可版本化、可复制安装、可评价”的能力生态。

五、IM、Widget 与多端入口

WeKnora 的多端入口比一般开源知识库项目更完整。docs/IM集成开发文档.md 显示它支持企业微信、飞书、Slack、Telegram、钉钉、Mattermost 等 IM 渠道，并可以把渠道绑定到 Agent。源码中的 internal/im/service.go 处理 IM 消息、流式回复、引用回复、文件消息入库、限流、去重和用户会话映射。

网站嵌入 Widget 是另一个重要入口。README_CN.md 提到 v0.6.3 引入嵌入 Widget 与发布集成中心，支持安全模式 Token 交换、限流和会话来源筛选。前端存在 frontend/src/embed-main.ts、frontend/src/views/embed/EmbedChatView.vue、frontend/src/composables/useEmbedBridge.ts 等文件，说明 WeKnora 已经有“把 Agent 发布到外部站点”的能力。这对齐 IMA 时很有价值，因为 Copilot 浮窗不应该只局限于 WeKnora 管理后台，也可以逐步扩展为网站内嵌助手。

六、前端工作台现状

WeKnora 前端是 Vue 3 + TDesign + Pinia + Vue Router。frontend/src/router/index.ts 显示主要路由包括知识库列表、知识库详情、Agent 列表、设置、创建聊天、聊天详情、组织列表和嵌入页。frontend/src/App.vue 是全局根组件，负责认证回调、邀请轮询、租户切换提示、全局通知、手动知识录入宿主和上传确认宿主。

这说明全局 Copilot 浮窗最自然的挂载点是 App.vue 或 platform 布局，而不是某个聊天页内部。当前聊天体验主要集中在 /platform/chat/:chatid 和 /platform/creatChat，知识库详情页、Wiki 浏览页、设置页和文档预览页并没有统一的“在当前页面旁边问 Copilot”的入口。对标 IMA PC 端时，前端要做的关键变化是：把对话能力从“一个页面”升级为“全局助手层”，并让各路由暴露可被采集的上下文。

七、记忆系统的真实现状

这是最需要纠偏的地方。WeKnora 并非完全没有记忆。源码中存在 /Users/colin/code/WeKnora/internal/application/service/memory/service.go，它会把一次对话整理成 Episode，调用 LLM 抽取 summary、entities 和 relationships，再通过 MemoryRepository.SaveEpisode 保存。/Users/colin/code/WeKnora/internal/application/repository/memory/neo4j/repository.go 使用 Neo4j 保存 Episode、Entity 和 RELATED_TO 关系，并能按关键词检索相关 Episode。/Users/colin/code/WeKnora/internal/application/service/chat_pipeline/memory.go 是聊天管线里的 MemoryPlugin，它会在 MEMORY_RETRIEVAL 阶段取回相关记忆并追加到用户上下文，在 MEMORY_STORAGE 阶段监听最终答案并异步写入 Episode。

前端和接口层也已经存在记忆开关。internal/handler/session/types.go 的 CreateKnowledgeQARequest 有 EnableMemory *bool，internal/handler/session/qa.go 会按请求覆盖、用户偏好和默认值解析 enable_memory。internal/types/user.go 中的 UserPreferences.EnableMemory 对应“开启记忆功能”偏好，internal/handler/auth.go 提供 PUT /auth/me/preferences 更新当前用户偏好。

因此正确结论应该是：WeKnora 已有“会话记忆图谱雏形”和“用户级记忆开关”，但它还不是 IMA 式 Copilot 四层记忆系统。它缺少用户可见的 Soul 设定、User 档案、长期记忆管理、Agent 经验总结、记忆编辑、记忆删除、记忆置信度、记忆来源追溯和多租户治理。后续实施应当复用现有 Episode、Entity、Relationship 与 MemoryPlugin，而不是推倒重来。

八、任务与产物管理现状

WeKnora 已经有异步任务队列基础，例如数据源同步、文档解析、Wiki 入库和移动/复制进度。migrations/versioned/000041_task_queue_and_wiki_indexes.up.sql 引入了任务队列和 Wiki 索引相关迁移，internal/application/repository/task_queue.go 也说明系统存在任务持久化能力。文档解析还有 knowledge_processing_spans 和 pending subtasks，用于展示解析追踪和取消。

不过，这些任务主要是系统后台任务，不是用户可见的“研究任务”或“创作任务”。IMA 的任务模式要求用户可以看到计划、步骤、来源、草稿、确认点和最终产物。WeKnora 需要新增面向用户的 agent_tasks、agent_task_steps、agent_artifacts 这一类实体，把现有队列能力上移为产品能力，而不是只把耗时操作放到后台执行。

九、WeKnora 的优势边界

对标 IMA 时，WeKnora 不应该丢掉自己的优势。IMA 是闭源产品，强调腾讯生态、多端客户端和平台化分发。WeKnora 的优势是开源、私有化、多租户 RBAC、模型和向量库可替换、MCP 与 Skills 可控、IM 渠道丰富、数据源同步开放、Widget 可自部署。更理想的路线不是做一个“开源 IMA 外观”，而是做一个“具备 IMA PC 端连续体验的私有化知识工作台”。

这意味着实施时要把能力拆成可渐进落地的层次。第一层是全局 Copilot 与页面上下文，这能直接改善 PC 端体验。第二层是记忆产品化，让用户知道系统记住了什么并能控制。第三层是任务模式与多格式产物，把 WeKnora 从问答工具推进到知识工作流。第四层才是知识广场、Skill 广场和生态分发。

十、本篇结论

WeKnora 已经拥有对齐 IMA 的许多底层模块：知识库、检索、Agent、MCP、Skills、IM、Widget、数据源同步、RBAC、记忆雏形和异步任务基础。差距集中在 PC 端产品组织方式上：缺全局 Copilot，缺页面上下文注入，缺 IMA 式可见记忆层，缺用户任务模式，缺产物管理，缺能力广场。

后续实施文档会基于这个判断展开。所有方案都应优先复用现有源码结构：在 App.vue 挂载浮窗，在 session_agent_qa.go 追加上下文入口，在现有 MemoryService 上做分层记忆，在现有 MCP 和 Skills 基础上接任务模式，在现有文件和知识入库管道上保存任务产物。