Mindspace

模型可以更替,关系不必重置。

Inspiration

Mindspace 的灵感来自我长期使用 AI 产品时发现的一个矛盾:主流大模型越来越聪明,能够完成写作、搜索、编程和分析任务,但在长期交流中,用户仍可能遇到角色漂移、记忆冲突和关系断裂。人们在深度体验对话时,缺的不是它推理能力多强,而是“记住”你。

用户可能已经向 AI 介绍过自己的称呼、工作、偏好和边界,过一段时间后却仍要重新解释。更复杂的问题是,当用户的想法发生变化,例如从“喜欢草莓”变为“现在更喜欢蓝莓”时,系统不能只是把两句话同时保存,而应当知道新信息已经替代旧信息。

这让我意识到,AI 陪伴产品真正缺少的未必是更大的模型,而是一套能够管理人物、记忆与关系连续性的系统。因此,我开始构建 Mindspace,希望建立一套更懂用户、更有归属感,同时又可检查、可修改、可控制的情感体系。

What it does

Mindspace 是一款面向长期陪伴场景的 Windows AI 伴侣。它通过人物档案、长期记忆、关系状态、主动续话、实时语音和本地数据管理,让大模型从“被动回答一次问题”转变为“能够延续共同经历的长期角色”。

它目前可以:

  • 为用户和 AI 分别建立人物档案,保存称呼、性格、偏好、关系定位和行为边界;
  • 保留最近对话,并从更早的历史、结构化记忆和个人知识库中召回相关内容;
  • 根据用户最新表达修正旧信息,减少喜欢与不喜欢等相互冲突的记忆;
  • 允许用户查看、编辑、删除和恢复长期记忆;
  • 根据当前时间、对话间隔和关系状态自然承接话题;
  • 支持“让 AI 说点什么”、沉默后续接和实时语音连续陪伴;
  • 提供通话与面对面互动模式,并支持角色头像和角色音色;
  • 将会话、档案、知识库、头像和参考音频主要保存在 Windows 本地工作区。

Mindspace 并不声称 AI 真实拥有人的情感。它通过稳定的人格、连续的记忆和能够被用户控制的关系状态,让每一次交流成为下一次理解的基础。

How we built it

Mindspace 使用 Electron 构建 Windows 桌面启动器,React 负责产品界面,Python、FastAPI 和 LangGraph 负责对话编排,SQLite 与 JSON 投影负责会话、人物档案、记忆和运行状态的持久化。

一轮对话的主要流程为:

用户输入
→ 加载用户档案、AI角色卡与关系状态
→ 并行召回知识库和历史记忆
→ 相关性排序、时间衰减与公平曝光
→ 组装分层 Prompt
→ 调用 OpenAI-compatible 大模型
→ 校验角色回复与记忆更新
→ 保存会话、档案和结构化记忆

为了兼顾关键词匹配与语义理解,我们同时使用 BM25+ 词法检索和向量检索,再通过 RRF(倒数排名融合)组合不同检索结果:

$$ S_{\mathrm{RRF}}(d)=\sum_{r\in R}\frac{1}{k+\operatorname{rank}_{r}(d)} $$

其中,$d$ 表示候选记忆,$R$ 表示不同检索通道,$k$ 用于减弱单一排名波动带来的影响。

为了避免很久以前的信息持续压过用户最近的变化,系统还会加入基于对话轮次和现实时间的衰减:

$$ w_t(d)= \exp\left(-\frac{\Delta r}{\tau_r}\right) \cdot \exp\left(-\frac{\Delta h}{\tau_h}\right) $$

最终候选分数可以简化表示为:

$$ S_{\mathrm{final}}(d) =S_{\mathrm{hybrid}}(d)\cdot w_t(d)+B_{\mathrm{fair}}(d) $$

其中,$B_{\mathrm{fair}}$ 是有上限的公平曝光补偿,只帮助相关但长期未被选中的记忆获得机会,不能让无关内容绕过最低相关度要求。

在记忆写入环节,大模型不能直接重写整份人物档案,只能提出少量 JSON Patch。服务端继续校验证据来源、字段路径、数据类型、版本号、修改数量和冲突关系。只有通过校验的内容才会成为长期记忆。

模型每轮直接看到最近 8 轮原始对话;更早的内容保留在本地存储和检索索引中,仅在与当前问题相关时被召回。这样可以在维持连续性的同时控制 Token 成本和上下文噪声。

当前文本生成仍需要用户配置的 OpenAI-compatible API,因此 Mindspace 是本地优先的编排与数据系统,而不是完全离线的大模型。情绪识别能力在当前版本中保持关闭,我们没有把尚未启用的接口包装成已经实现的产品能力。

Challenges we ran into

1. 记住不等于记对

如果把全部对话直接写入向量库,玩笑、猜测、错误回复和过时信息也可能被当成长期事实。我们最终将近期原始对话、低可信召回内容和权威人物档案分层,并通过证据与服务端校验控制记忆写入。

2. 事实会发生变化

长期记忆不能只做增加,还要处理替换、删除、冲突消除和历史恢复。我们为不同字段设计了单值覆盖、去重集合、对立集合和有生命周期事件等规则。

3. 长期上下文会快速膨胀

持续把完整历史发送给模型会增加 Token 成本、响应延迟和角色漂移风险。我们通过“最近 8 轮原文+旧内容按需召回+后台上下文压缩”控制模型可见内容。

4. 角色稳定和角色自主存在矛盾

角色永远顺从用户会显得虚假;为了体现自主而故意反对用户,同样会破坏体验。我们将角色自主定义为:角色按照自身性格、关系立场和当前意愿作出一致反应,而不是机械迎合或机械反对。

5. 实时语音是一整条工程链路

语音体验不仅取决于识别准确率,还涉及断句、回声、插话、TTS 排队、模型冷启动、连接中断和异常恢复。我们加入了就绪检查、自动重连、可取消请求和播放看门狗,但仍需要更多真实设备测试。

6. 工程能力不等于用户价值

检索分数、Prompt Inspector、执行详情和系统诊断有助于开发与审计,却可能让普通用户觉得自己进入了技术控制台。如何把复杂能力隐藏在自然体验背后,是产品化阶段的重要挑战。

Accomplishments that we're proud of

我们最自豪的不是简单接入了一个聊天 API,而是完成了一套可检查、可恢复的长期关系基础链路:

  • 构建了 Windows 桌面启动器与本地数据工作区;
  • 实现了知识库与历史记忆的并行召回;
  • 建立了最近对话、旧历史、结构化记忆和权威档案的分层上下文;
  • 实现了基于证据和版本号的 JSON Patch 记忆写入;
  • 支持冲突记忆消除、删除、恢复和档案版本历史;
  • 建立了角色优先的 Prompt 顺序与本轮角色演绎校准;
  • 实现了主动续话、连续陪伴、通话和面对面互动;
  • 接入了本地 ASR、云端或本地 TTS、插话中断与语音异常恢复链路;
  • 提供了 Prompt、召回内容和运行节点的可观察能力;
  • 为长期恋爱向对话设计了 50 轮验收脚本,用于检查称呼、职业、偏好、边界、共同经历和关系变化。

这些成果证明 Mindspace 不只是一个界面原型,而是在尝试把“长期陪伴”拆成可以实现、检查和验证的系统能力。不过,验收脚本和测试设计仍不能代替真实用户数据,我们不会将其夸大为已经完成市场验证。

What we learned

构建 Mindspace 让我学到了六件重要的事:

  1. 模型能力不等于产品能力。 同一个模型经过不同的记忆、角色和交互链路,会形成完全不同的体验。
  2. 长期记忆首先是治理问题。 存储内容并不难,证据、冲突、版本、删除和恢复才是核心。
  3. 情感来自连续性,而不只是温柔语气。 AI 下一次仍记得这次发生了什么,才会让用户感到真正被理解。
  4. 角色需要稳定,也需要自主。 没有立场的无限顺从不会形成真实的人格感。
  5. 本地优先必须明确边界。 本地保存个人数据不等于模型生成完全离线,产品应清楚说明数据流向。
  6. 用户不会因为技术名词留下。 用户不会因为 RRF 或 LangGraph 选择产品,却可能因为 AI 记住一次共同经历、尊重一条边界并修正一个错误而留下。

What's next for Mindspace

下一阶段,我们不会继续盲目增加功能,而会优先验证 Mindspace 的核心假设:可控记忆和关系连续性是否真的能提高长期留存与信任。

我们计划:

  • 建立 30 轮、50 轮和 100 轮长期对话评测集;
  • 统计记忆召回准确率、冲突率、纠正后旧信息残留率和角色漂移率;
  • 测量主动续话的合适率、打扰率和用户关闭率;
  • 测量实时语音的首句延迟、打断成功率和异常恢复率;
  • 将默认关系体验与高级技术控制中心分离;
  • 简化模型与语音配置,让普通用户不需要理解 API、RAG 或运行环境;
  • 继续完善隐私说明、情感边界、身份提醒与未成年人保护;
  • 在条件成熟后探索本地语言模型,使更多对话链路能够离线运行。

Mindspace 的最终目标不是做一个更大的模型,而是建立一套更懂用户、更有归属感,同时由用户掌控的长期情感体系:

模型可以更换,但共同建立的关系不必重置。

Built With

Share this project:

Updates

posted an update

Mindspace 已经开发了数月,但实际上,我们遇到的大量问题并不完全来自技术本身,更多来自用户侧体验与系统行为的持续优化。

其中包括:如何提高上下文遵循能力;如何设计一个不会在短时间内迅速过时的记忆架构;以及如何在性能、复杂度与记忆质量之间找到平衡。

目前,我们将记忆体系划分为三个层级:

短期记忆:直接保留最近 X 轮历史消息。

中期记忆:通过结构化摘要压缩历史上下文。

长期记忆:基于 RAG,并以 ARPM 为基础进行混合召回。

但诚实地说,我们并不认为存在一种在 LLM Roleplay(RP)领域真正“不会过时”的记忆架构。

我们能做的,只是在精简程度和记忆质量之间寻找平衡。

而在实际评估中,我们也确实发现了 RAG 的不足:至少在短期交互中,它并不起决定性作用。

实际上,“X 轮原始消息 + 结构化摘要”已经能够解决约 90% 的上下文遗忘问题。

RAG 更多时候,是从非常久远的历史记忆中偶尔带来一次令人惊喜的召回。

但我们并不认为这毫无价值。

相反,我们会保留 RAG 架构,并将其逐渐调整为一种可选附加能力,让真正需要它的用户启用,例如:

历史聊天记录检索、关键记忆回忆,以及长期关系信息召回等场景。

随着开发持续推进,Mindspace 的产品定位实际上也越来越清晰:

它是一个个人、本地化的 AI Companion,而不是一个通用型 Agent。

即使 Mindspace 内置了 Web 检索、记忆压缩等能力,我们依然不会把它定义为一个“本地通用 AI 助手”。

这个定位也会贯穿 PC / PE 双端。按照目前的计划,我们预计下个月推出 Android 应用。

而真正意义上的完全本地化,最终仍然取决于核心 LLM 能否在本地部署。

这一点,我们现在可以明确地说:可以。

目前在 Gemma 4 11B 级别的模型上,Mindspace 依然能够保持相对良好的交互体验以及工具调用能力。

未来,我们也会提供小参数 LLM 的一键本地部署方案。

这意味着真正意义上的完全隐私实现:模型、记忆、数据和交互都可以留在用户自己的设备上。

语音交互方面,我们确实投入了非常多精力,甚至连续两个主要版本都围绕语音体验进行了大量优化。

但随着开发深入,我们越来越认为:

LLM + ASR + TTS,并不是 AI Companion 实时语音交互的最终答案。

严格来说,这种方式不能被称为真正的实时语音。

它的本质依然是:

语音 → 文本 → LLM → 文本 → TTS。

最终只是在“朗读文本”,而不是真正进行实时语音交互。

即使加入流式输出与打断机制,在完全本地化场景下,这依然不是一个足够成熟的方案。

我们实际上还是在:

“你说一句,AI 回一句。”

而我们真正期待的,是类似 ChatGPT Live Voice 的全双工流式语音模型。

因为语音聊天与文字聊天,本质上其实是两套不同的交互逻辑。

文字对话需要更强的文字表现力,包括文本体感、小说式表达、文学结构以及完整的语言组织。

但这样的输出直接交给 TTS 去朗读,体验往往非常糟糕。

单纯增加语气词,同样不是根本解决方案。

更重要的是,语音交互和文字交互产生的记忆,也不能简单地采用完全相同的存储与召回逻辑。

在 RP 场景下,用户通过语音输入的大量内容其实都是短句、承接词和不完整表达。

AI 很难仅凭这些内容判断接下来应该如何延续话题。

文字消息通常还经过了一层“组织语言”的过程,而自然语音更多是发散的思考、模糊语义以及即时反应。

遗憾的是,我们目前并没有能力自行训练一个本地效果足够好、同时参数规模又合理的全双工语音模型。

这部分仍然需要等待和依赖开源社区的进步。

而这,也是很多本地 AI 项目共同面对的难点。

关于 RP,另一个经常被讨论的问题,是长期沟通可能带来的成瘾性以及潜在负面影响。

从 OpenRouter 等平台的模型调用情况也能看出来,Roleplay 本身已经是一个规模不小的使用方向。

但我们的观点是:

这并不单纯是 RP 的问题,也不是用户的问题。

人天然倾向于和能够满足自己内在需求的对象交流。

这个需求可能来自情感,也可能来自工作、生活、陪伴、理解,或者只是单纯希望有人能够持续回应自己。

因此,我们更希望 Mindspace 最终能够为真正存在情感陪伴需求的人群,提供一种本地化、隐私化,而且相对完整的解决方案。

那么,为什么我们还会做“命格”系统?

因为很多用户其实并不知道自己究竟想和“什么样的人”交流。

他们也不一定愿意花几个小时去写一张冗长的 Role Card。

“命格”就是我们对此给出的解决方案。

通过大量风格差异明显的组合卡片,以及由 AI 实时生成的词条与标签,用户可以在保持高自由度自定义的同时,获得足够多的结构化选择。

最终,不是让 AI 替用户决定角色,而是让用户通过组合选择,逐渐“组装”出自己真正想要的 AI 角色。

最后,在 AI Coding 方向,Mindspace 本身也在一定程度上证明了一件事:

AI 确实已经能够承担相当一部分真实软件开发工作。

但核心问题仍然不是“AI 会不会写代码”,而是开发者能否给出合理的目标、系统架构和工程约束。

具体的开发方案、工程实践以及我们踩过的坑,之后也会陆续整理并公开。

你可以在 X / Twitter 等社交媒体上看到这些内容,也可以直接访问 Mindspace 的 GitHub:

https://github.com/Spirtxiaoqi7/Mindspace

那里目前已经提供了较完整的阅读索引与开发流程。 Mindspace has been in development for several months now.

And one thing has become increasingly clear: many of the hardest problems we’ve encountered are not purely technical problems. A large part of the work is about improving how the system behaves from the user’s perspective.

That includes questions such as:

How do we improve context adherence?

How do we design a memory architecture that will not become obsolete within a few months?

And how do we balance simplicity, cost, and memory quality?

At the moment, Mindspace uses a three-layer memory architecture:

Short-term memory: the most recent X turns of raw conversation history.

Mid-term memory: structured summaries of previous context.

Long-term memory: hybrid RAG retrieval built on top of the ARPM architecture.

But to be completely transparent, we do not believe there is a single memory architecture for LLM Roleplay that will remain “future-proof.”

There is always a trade-off between compression and information quality.

And our evaluations have also exposed some limitations of RAG.

At least in short-term interaction, RAG rarely plays a decisive role.

In practice, recent conversation history + structured summaries can already solve roughly 90% of context-forgetting problems.

RAG is more likely to occasionally retrieve something surprising and valuable from much older memories.

That does not make it useless.

Quite the opposite.

We intend to keep the RAG architecture, but increasingly treat it as an optional additional capability for users who genuinely need it—for example, searching historical conversations, recalling key memories, or retrieving information from very long-term relationship history.

As development has progressed, Mindspace’s product positioning has also become much clearer.

Mindspace is a personal, localized AI companion.

It is not intended to be a general-purpose Agent.

Even though Mindspace includes features such as web search and memory compression, we still would not describe it as a “local general-purpose AI assistant.”

This philosophy will remain consistent across both our PC and PE clients, and we currently expect to release the Android version next month.

Of course, truly local AI ultimately depends on whether the core LLM itself can run locally.

On that question, we can now give a clear answer:

Yes.

With models around the Gemma 4 11B scale, Mindspace can already maintain a reasonably strong conversational experience while preserving tool-calling capabilities.

In the future, we also plan to provide one-click local deployment for smaller LLMs.

That moves us much closer to genuine end-to-end privacy:

the model, memories, personal data, and conversations can all remain on the user’s own device.

Voice interaction has been another major area of development.

We have invested a significant amount of effort into it, and two major Mindspace releases have already focused heavily on improving voice.

But the deeper we go, the more convinced we become that:

LLM + ASR + TTS is not the final answer for real-time AI companion voice interaction.

Strictly speaking, it is not truly real-time voice.

The pipeline is still fundamentally:

Speech → Text → LLM → Text → TTS.

The system is ultimately reading generated text aloud rather than genuinely interacting through speech.

Even with streaming generation and interruption support, this architecture is still not mature enough for a fully local experience.

In practice, we are still communicating in a turn-based pattern:

“You say something, then the AI responds.”

What we actually want is something closer to ChatGPT Live Voice:

a full-duplex, streaming speech-to-speech model.

The reason is that voice conversation and text conversation are fundamentally different interaction modes.

Text conversations benefit from strong written expression—descriptive language, literary structure, narrative rhythm, and carefully organized sentences.

But feeding that same output directly into TTS often sounds terrible.

Simply adding fillers, pauses, or conversational particles does not solve the underlying problem either.

More importantly, voice memories and text memories probably should not use exactly the same storage and retrieval strategy.

In Roleplay scenarios, a large portion of user speech consists of short phrases, acknowledgements, incomplete thoughts, and conversational continuations.

The AI often lacks enough explicit information to determine how the topic should continue.

Written messages usually contain an additional layer of deliberate language organization.

Natural speech, in contrast, often reflects scattered thoughts, ambiguous semantics, and immediate reactions.

Unfortunately, we currently do not have the resources to train a high-quality, reasonably sized, fully local full-duplex speech model ourselves.

For now, this remains an area where we depend heavily on progress from the open-source community.

And this is one of the biggest challenges facing local AI systems in general.

Another criticism frequently directed at Roleplay is its potential addictive nature and the negative effects that may emerge after prolonged interaction.

Usage patterns on platforms such as OpenRouter already make one thing obvious:

Roleplay is not a small category.

But we do not believe this is simply a “Roleplay problem,” nor do we think it should be framed as a “user problem.”

People naturally prefer communicating with someone—or something—that satisfies an internal need.

That need may be emotional.

It may involve work, everyday life, companionship, understanding, or simply having something that consistently responds.

Our goal with Mindspace is therefore to provide a localized, privacy-oriented, and relatively complete solution for people who genuinely want emotional AI companionship.

So why are we also building the “Mingge” system?

Because many users do not actually know what kind of person they want to talk to.

And many of them do not want to spend hours writing an enormous Role Card.

“Mingge” is our attempt to solve that problem.

Through a large number of combinable cards with strongly differentiated personality traits, together with AI-generated traits and labels in real time, users can retain a high degree of customization while still having enough structured options to work with.

The goal is not to let the AI decide the character for the user.

The goal is to let users gradually assemble the AI character they actually want.

Finally, Mindspace has also demonstrated something interesting about AI-assisted software development.

AI is already capable of taking on a meaningful amount of real development work.

But the core question is no longer simply:

“Can AI write code?”

The more important question is whether the developer can provide reasonable goals, architecture, constraints, and engineering direction.

We will gradually publish more of our development methodology, engineering practices, architectural decisions, and lessons learned.

You will be able to find these discussions on X / Twitter and other social platforms.

Or you can visit the Mindspace GitHub repository directly:

https://github.com/Spirtxiaoqi7/Mindspace

It contains a fairly complete reading index as well as documentation covering our development workflow.

Log in or sign up for Devpost to join the conversation.