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.