MemoFlow · AI 模块开发笔记

AI 模块目标

我希望 AI 在 MemoFlow 里不只是一个聊天窗口，而是可以围绕目标、任务和知识库提供实际帮助。用户提出“准备考试”这样的意图，AI 能追问细节、整理 Key Result、拆解 Task；遇到资料时，也可以结合已有笔记生成或补充知识草稿。

Desktop 与 Web 都需要一个容易唤起的入口，同时允许用户根据自己的渠道配置模型。

V1.0.0

先做基础对话和模型接入。聊天窗口要支持流式回复、会话记录与模型选择；再提供一个可以配置 API 地址和密钥的入口。

最初考虑 OpenAI-compatible 格式，是因为不少模型服务都提供类似接口，可以减少接入工作。但接口路径相似，不代表所有 Provider 的工具调用、结构化输出、流式事件和上下文参数完全一致。配置时要把“能连通”和“具备哪种能力”分开看。

知识问答先按用户已有知识库进行检索，再把相关内容交给模型。检索材料是参考信息，不应让任意网页或笔记内容修改系统的工具权限。

v1.1.0

现在尝试把聊天变成真正可操作的业务功能。

以创建 Goal 为例，用户只给一句自然语言，AI 需要先确认目标、时间和指标，再整理 Goal、KR、Task 草稿。知识补充也是一样：先找已有内容，避免重复写入，再给用户看拟新增的 Markdown。

这版决定把流程拆成理解意图 → 澄清 → 生成草稿 → 用户确认 → 调用业务服务。AI 生成格式正确的字段，不等于 Goal 或 Task 已经创建成功；真实的校验和写入必须交给对应业务模块。

V2.0.0

对话能覆盖多个业务后，单个请求函数已经不够用了。现在需要一个支持多步骤、暂停、恢复和重试的 Agent / Workflow 运行时。

决定使用 TypeScript + Mastra 作为主要 Assistant 和工作流实现。它负责对话状态、工具调用与 durable workflow；典型流程包括 Goal 创建、Task 创建和 Knowledge Capture。

不准备让 AI Runtime 成为第二套业务后端。工作流可以保存草稿、修订和执行记录，但不能私自拥有 Goal、Task 或 Repository 的持久化真值。真正 Apply 时，通过各 Owner 的 Application / Command Port 处理，使用稳定的操作身份避免重试生成重复对象。

v2.1.0

模型与工具能力也需要更清楚的边界。Provider 定义、用户连接、密钥和模型能力证据分开管理：前端可以展示“这个连接有什么模型”，但不能把明文密钥塞进会话、日志或 AI 上下文。

Desktop 可以使用本地 Agent/BYOA 渠道；Web 的业务 AI 路径走 Mastra。两端可以共享产品权限语义，但不能假装所有 Agent 都支持相同的流式协议和工具模式。

工具也按风险区别对待：查询今日任务、知识检索等只读操作可以自动执行；修改持久配置、创建重要业务对象等动作需要相应的审批。模型输出或检索到的内容，不允许临时扩大这套授权规则。

V3.0.0

现在要处理一个实际的交互问题：AI 生成的 Goal 草稿，应该在哪里编辑和确认？

如果 AI 模块再实现一套独立的 Goal / Task 表单，就会出现两份校验规则、两套保存入口和不同的未保存提醒。用户正常创建 Goal 与通过 AI 创建 Goal，看到的界面也会不一致。

这版采用 Owner Native Surface Orchestration。Mastra 继续保存内部草稿和恢复状态；Chat 负责澄清、进度、取消与异常恢复；真正需要用户编辑时，打开 Goal、Task 或 Knowledge 所属的原生业务界面。

AI 通过有类型的业务意图协调界面，不通过模拟点击 DOM 来冒充用户操作。用户在原生表单中保存时，依然执行 Owner 原有的校验、权限和持久化规则。

v3.1.0

继续完善 AI 的上下文和知识来源。Context Assembler 需要在有限 token 预算下选择当前时间、用户授权的业务信息和相关知识；引用的文档使用稳定的 KnowledgeDocumentId，路径改变后也不能丢失来源身份。

同时记录必要的模型用量、失败类型和调用耗时，方便比较不同 Provider 的质量与成本；这些执行记录只是观测数据，不替代业务对象和持久会话。