IMA 与 WeKnora 成熟度对比：以 PC 端知识工作台为中心

IMA 是多端产品，但它最值得 WeKnora 学习的是 PC 端知识工作台。移动端能补足录音、阅读、轻量提问和随手保存，但真正高频、复杂、可持续的知识生产发生在 Mac 与 Windows 桌面端：用户导入文件、整理知识库、阅读长文、打开多个资料、执行任务模式、生成报告或 PPT、配置 MCP、调试 Skill，并把产物沉淀回知识库。WeKnora 目前也有 Web UI、桌面端、Chrome 扩展、微信小程序、IM 和 Widget，但这些入口还没有形成 IMA 那种“一个 Copilot 贯穿当前工作”的体验。

本文把对比分成三层：第一层是 PC 端工作台体验，第二层是后端能力和数据模型，第三层是生态分发与企业治理。这样比较能避免两种误判：一种是只看功能清单，觉得 WeKnora 已经“差不多都有”；另一种是只看 IMA 的 Copilot 浮窗，忽略 WeKnora 已经具备的开源、私有化、MCP、Skills、多租户和数据源优势。

一、总体成熟度矩阵

二、PC 端 Copilot：最大差距不是聊天能力，而是“就地工作”

IMA 的 PC 端价值不只是“多一个聊天窗口”，而是用户在当前工作对象旁边使用 AI。用户打开知识库文档时，问题里的“这篇文档”有明确对象；用户查看知识库广场时，“这个知识库适不适合加入”也有明确对象；用户在任务模式里查看中间结果时，“继续扩展第二部分”指的是任务中的某个 artifact，而不是普通聊天上下文。

WeKnora 当前的对话能力集中在 /platform/chat/:chatid 和 /platform/creatChat。知识库详情页、文档预览组件、Wiki 页面、设置页、Agent 编辑器和集成页都有自己的业务状态，但这些状态没有统一进入 Agent 请求。session_agent_qa.go 已经支持 QuotedContext、附件内容、图片描述、知识库范围和 MCP/Skill 选择，这说明后端入口可扩展；真正缺的是前端统一采集和传输当前页面上下文。

靠拢 IMA 的 PC 端 Copilot 应该具备四个行为。第一，浮窗跨路由存在，不因为从知识库切到 Wiki 或设置页就丢失。第二，浮窗知道当前页面类型、资源 ID、资源标题、选中文本、可见摘要和权限范围。第三，用户可以把当前上下文固定到会话中，例如“接下来都围绕这份合同问”。第四，浮窗可以把结果保存回知识库、任务产物或笔记，而不是只显示一段回答。

三、记忆系统：WeKnora 有雏形，但缺少 IMA 式产品化

IMA 公开资料把 Copilot 记忆描述为用户可以持续调教的能力。无论内部实现是否完全等同于四个数据库表，它给用户传达的体验是清晰的：助手知道自己是谁，知道用户是谁，记得跨会话的重要事情，也会从任务中总结经验。

WeKnora 已有非常关键的起点。internal/application/service/memory/service.go 会把对话抽取为 summary、entities 和 relationships；internal/application/repository/memory/neo4j/repository.go 会保存 Episode、Entity、MENTIONS 和 RELATED_TO；internal/application/service/chat_pipeline/memory.go 会在检索阶段把相关 Episode 注入 UserContent，在回答完成后写入新 Episode；internal/handler/session/qa.go 会根据请求和用户偏好解析 enable_memory。这些都说明 WeKnora 已经在做“对话记忆”，只是它还没有成为用户可理解、可编辑、可治理的 Copilot 记忆。

成熟度差距主要体现在五点。第一，现有记忆没有 Soul 层，Agent 的人设、称呼、工作方式主要还是配置或 prompt，而不是 Copilot 个人设定。第二，现有记忆没有 User Profile 层，用户身份、行业、偏好、常用格式没有结构化展示。第三，现有 Episode 召回比较粗，更多依赖实体关键词，而不是面向项目、任务、偏好、决策的长期记忆。第四，任务经验还没有闭环，Agent 执行失败或成功后不会沉淀“下次类似任务怎么做”。第五，用户没有管理面板，无法查看“系统记住了什么”、删除错误记忆、修改称呼或关闭某类记忆。

四、任务模式：IMA 是产品级任务，WeKnora 目前是 Agent 级推理

IMA 2.0 任务模式的核心是让用户输入一个目标，而不是输入一个问题。公开报道提到任务模式可以自动拆解步骤、搜索资料、生成报告和播客等产物。这种形态和普通 ReAct 最大区别在于：任务有计划、有状态、有中间产物、有确认节点、有最终文件，并且任务可以被回看和恢复。

WeKnora 的 ReAct Agent 已经可以多步调用知识库检索、网络搜索、MCP 工具和 Skills，事件总线也能展示工具调用过程。但这仍然是“一个回答”的执行过程。用户无法在 UI 中看到一个稳定任务对象，无法暂停后恢复，无法确认计划，无法把步骤结果保存为多个文件，也无法在任务完成后继续围绕某个 artifact 修改。

靠拢 IMA 时，WeKnora 不应把任务模式做成“更长的 Agent 回答”。它需要新增任务实体，并把 Agent 每一步输出映射为任务计划、执行步骤、引用、草稿和产物。任务模式既要复用 AgentQA、MCP、Skills 和知识库检索，也要绕开聊天消息的单字符串限制，把中间结果写入 agent_task_steps 和 agent_artifacts。

五、内容生成：从聊天文本升级为可管理产物

IMA 的内容生成能力对 PC 端很重要，因为 PC 端用户不满足于“看一段回答”，而是要拿到可交付的文件。报告需要 Markdown、Word 或 PDF；PPT 需要 PPTX；播客需要音频和脚本；思维导图需要可交互浏览或导出图片；AI 解读需要把文档摘要、脑图、播客、测验和问答串成一个学习包。

WeKnora 当前有 Wiki 生成和 Markdown 渲染基础，也有文件服务、对象存储、知识库入库和附件处理能力。因此内容生成可以用 artifact 层增量实现。第一阶段不需要追求 IMA 的所有形态，而是先建立统一产物模型：每个产物有类型、标题、正文、文件路径、来源引用、生成任务、状态和权限。只要这个模型稳定，报告、PPT、播客和思维导图都能作为不同 renderer 挂上去。

六、知识生态：IMA 做公共广场，WeKnora 应先做私有市场

IMA 的知识库广场、知识号和 Skill 广场是平台型能力，它们适合腾讯这样的大规模分发平台。WeKnora 如果直接复制公共广场，可能会和私有化、企业部署、多租户隔离的优势冲突。更合理的路线是先做“私有知识市场”和“租户内能力市场”：组织内部可以发布知识库模板、Agent 模板、Skill 包、MCP 配置、任务模板和内容生成模板，管理员可以审核、上架、下架和授权。

这条路线与 WeKnora 现有共享空间、Agent Share、KB Share、RBAC 和审计日志更契合。等私有市场稳定后，再考虑社区公共仓库、导入导出包、精选 Skill 和公共模板。这样既靠近 IMA 的生态逻辑，又不会牺牲 WeKnora 的企业部署边界。

七、移动端与外围入口的定位

用户特别提醒 IMA 是多端产品，这一点必须纳入对比。但在实现优先级上，移动端不应抢 PC 端主线。移动端应承担三个角色：第一，录音纪要和现场采集，例如会议录音、照片、网页链接、临时想法；第二，轻量阅读和追问，例如在通勤时阅读任务报告或继续问某个知识库；第三，通知和审批，例如任务需要用户确认计划、MCP 授权或审核产物时推送到移动端。

WeKnora 已有微信小程序、IM 和 Widget，可以先通过这些入口承接移动端补充场景，而不是马上开发完整移动 App。换句话说，PC 端负责“生产”，移动端负责“采集、消费和确认”。这与 IMA 的多端形态一致，也更符合 WeKnora 当前资源和源码基础。

八、对标策略总结

WeKnora 靠拢 IMA 的优先级应该是：先做 PC 端全局 Copilot，再做可见分层记忆，然后做任务模式和产物模型，接着把 MCP 与 Skills 纳入任务模板，最后做私有知识与能力市场。移动端能力通过小程序、IM 和 Widget 渐进补齐，不把它作为第一阶段主战场。

如果只补“报告生成”或“PPT 导出”，WeKnora 会得到几个新工具，但不会变成 IMA 式工作台。如果只补“浮窗按钮”，用户仍然会因为没有上下文、记忆和任务而回到普通聊天体验。真正的路线应该把 PC 端 Copilot、页面上下文、分层记忆、任务状态和产物管理作为一个闭环实施。