从网站到数字空间：月读空间的技术架构、AI 陪伴与未来
月读空间最开始只是一个用来记录生活、分享内容和折腾技术的小网站。
但随着一次又一次功能迭代，它正在逐渐变成另一种东西——一个融合内容、社区、Live2D、LLM、长期记忆与 Agent 的个人数字空间。
项目地址：
截至目前，月读空间已经从一个相对简单的个人站点，发展成包含 内容系统、用户系统、社区互动、Live2D AI 陪伴、长期记忆、Agent OS、Wiki、像素工坊、小游戏、成长系统、对象存储、通知系统等多个模块 的综合项目。
而接下来，项目还会迎来一次非常大的变化：
月读空间将不再局限于浏览器。后续计划使用 Flutter 开发真正独立运行的全平台客户端。
这篇文章就详细介绍一下目前月读空间背后的技术实现，以及接下来准备把它带到哪里。
一、月读空间现在到底是什么？
如果只从页面上看，月读空间可能很容易被理解成一个博客、个人主页或者二次元社区。
但现在的项目定位已经远不止这些。
目前我更愿意把它理解成一个：
围绕“八千代”构建的个人数字空间。
在这个空间里，不同功能并不是完全独立的。
例如：
- 在 Stage 阅读文章；
- 在 Plaza 留言和交流；
- 在 Gallery 分享图片；
- 在 Pixel 制作像素画；
- 在 Wiki 查询作品与角色资料；
- 在 Room 与八千代交流；
- 八千代可以读取部分站内状态；
- 登录账号可以同步聊天记录与长期记忆；
- Agent OS 则进一步尝试让 AI 从“聊天对象”变成真正可以使用工具的数字角色。
所以项目现在正在逐渐形成一套完整的结构：
内容
↓
社区
↓
用户
↓
八千代
↓
长期记忆
↓
工具调用
↓
Agent
↓
数字空间
这也是为什么我没有把月读空间单纯做成一个聊天页面。
我更希望未来打开月读空间时，看到的是一个长期存在、可以不断积累内容和关系的数字世界。
二、整体技术架构
目前月读空间主项目版本已经有 891Commits，整体采用比较传统、但非常适合个人项目持续维护的一套 Web 架构。
核心技术栈大致如下：
| 部分 | 当前技术 |
|---|---|
| 前端 | Vue 3 |
| 构建 | Vite |
| 路由 | Vue Router |
| 后端 | Node.js + Express |
| 主数据库 | SQLite / better-sqlite3 |
| 长期记忆 | Mem0 OSS + SQLite |
| 向量检索 | 可选 Milvus |
| 缓存 | 可选 Redis |
| Live2D | Cubism Runtime |
| 动画 | Anime.js |
| LLM | OpenAI Compatible API / Ollama 等 |
| Agent 扩展 | MCP |
| 对象存储 | S3 Compatible / 阿里云 OSS |
| CDN | 阿里云 CDN |
| 认证 | JWT + Cookie |
| 测试 | node:test + Playwright |
| 部署 | Docker / PM2 / Nginx / OpenResty |
从结构上来说，大致可以理解成：
┌──────────────────────┐
│ 用户设备 │
│ Browser / Future App │
└──────────┬───────────┘
│
HTTPS / CDN / API
│
┌────────────────┴────────────────┐
│ │
┌───────▼────────┐ ┌───────▼─────────┐
│ Vue 3 Frontend│ │ Alibaba Cloud │
│ Vite / Live2D │ │ CDN + OSS │
└───────┬────────┘ └─────────────────┘
│
│ REST API
│
┌───────▼────────┐
│ Express Backend │
│ Node.js │
└───────┬────────┘
│
┌──────────┼───────────┬──────────────┐
│ │ │ │
┌──▼───┐ ┌───▼───┐ ┌───▼────┐ ┌────▼────┐
│SQLite│ │ Redis │ │ Mem0 │ │ Milvus │
│ 主库 │ │ Cache │ │Memory │ │ Vector │
└──────┘ └───────┘ └────────┘ └─────────┘
其中 Redis 与 Milvus 都不是项目运行的强制依赖。
这样做的好处是，即使只部署一个比较简单的实例，也可以依靠：
Node.js
+
SQLite
+
Mem0 SQLite Index
完成绝大部分核心功能。
如果服务器资源更加充足，再逐步开启 Redis、Milvus 等能力。
对于个人维护的项目来说，我认为这种方式比一开始就堆大量中间件更加合适。
三、前端：从“页面”逐渐形成统一设计系统
月读空间目前的主前端已经迁移到：
Vue 3
+
Vite
+
Vue Router
相比最早期大量独立页面的实现，现在最大的变化之一，是开始逐步建立真正统一的前端体系。
项目中已经建立了一套自己的 Design Tokens。
例如：
src/frontend/styles/
├── tokens.css
├── themes.css
├── components.css
├── animations.css
└── responsive.css
分别负责：
- 色彩；
- 字体；
- 间距；
- 圆角；
- 阴影；
- 深浅色主题；
- 动画；
- 按钮；
- 卡片；
- 输入框；
- 导航；
- 响应式布局。
新的页面开始逐步使用统一的 --ts-* CSS Variables。
这样做最大的意义不是“代码更漂亮”，而是让整个网站开始真正拥有一套统一的视觉语言。
例如：
--ts-color-bg
--ts-color-surface
--ts-radius-md
--ts-space-lg
--ts-shadow-panel
只需要修改底层 Token，就可以逐渐影响多个页面，而不是每个页面维护一套完全不同的样式。
这也是最近一段时间我投入很多精力优化 UI/UX 的原因。
月读空间功能已经越来越多，如果没有统一的设计体系，最终很容易变成：
每个页面单独看都没问题，组合起来却像十几个不同的网站。
所以接下来 UI/UX 仍然会是项目的重要开发方向。
四、Room：月读空间最核心的实验场
如果要选择目前整个月读空间最特殊的部分，那应该还是：
Room。
Room 并不是简单在网站里塞一个 AI 聊天框。
我希望它最终实现的是：
“八千代真正生活在这个空间里。”
因此现在 Room 已经组合了很多不同能力。
包括：
Live2D
+
LLM
+
长期记忆
+
角色知识库
+
TTS
+
天气
+
音乐
+
成长系统
+
MCP
+
站内信息
用户看到的只是一个聊天页面，但实际上每次对话背后可能同时存在多种上下文。
例如：
用户消息
│
├── 角色基础人设
│
├── 当前会话
│
├── 长期记忆
│
├── 角色知识库
│
├── 天气信息
│
├── 用户成长状态
│
├── 网站动态
│
└── MCP 工具结果
│
▼
LLM
│
▼
八千代回复
│
├── Live2D 表情
└── TTS 语音
这也是 Room 和普通聊天机器人的最大区别之一。
八千代所处的是一个有环境、有历史、有用户状态的上下文空间。
五、为什么 LLM 不全部经过月读空间服务器？
Room 在设计时有一个比较重要的思路：
尽可能减少用户聊天内容和 API Key 不必要地经过月读空间服务器。
因此部分 LLM 与 TTS 请求可以直接由浏览器发起。
例如用户配置自己的 OpenAI Compatible API 后：
Browser
│
│ HTTPS
▼
LLM Provider
而不是：
Browser
│
▼
月读空间服务器
│
▼
LLM Provider
这么做有几个好处。
第一，是减少服务器压力。
第二，是降低服务器对用户 API Key 的处理需求。
第三，则是方便支持本地模型。
目前 Room 已经可以通过浏览器连接：
http://localhost:11434
也就是本机 Ollama。
这样就能够形成：
月读空间页面
│
▼
localhost
│
▼
Ollama
│
▼
本地 LLM
也就是说：
网页依然可以运行在公网，而模型完全运行在用户电脑上。
这是我认为 Room 很有意思的一种使用方式。
六、长期记忆：让八千代真的“记得”
聊天 AI 最影响体验的问题之一就是：
聊得再久，只要新建会话，它就像第一次认识你一样。
因此月读空间现在已经建立了一套独立的长期记忆系统。
目前主要采用：
Mem0 OSS
+
SQLite
而不是依赖 Mem0 云端服务。
项目直接引入：
mem0ai@3.3.0
并在 Node.js 进程中运行。
因此不需要额外搭建：
Python Mem0 Server
也不需要申请 Mem0 Cloud。
对话和记忆不是一回事
Room 内部将：
聊天记录
与：
长期记忆
分开管理。
普通聊天记录主要用于维持最近的会话上下文。
长期记忆则独立保存，不会因为最近聊天窗口被裁剪就消失。
比如用户说：
我最近正在学习 Flutter。
这一句话可能进入长期记忆。
几个月后讨论客户端开发时，检索系统仍然有机会重新找到这条信息。
这才是真正有意义的长期记忆。
七、长期记忆是怎样被找回来的？
当前月读空间默认并不是完全依赖大型向量模型。
默认情况下，会使用：
Feature Hash
+
中文关键词
+
问题类别
+
Mem0 检索评分
进行综合搜索。
也可以配置远程 Embedding 服务。
大致流程是：
用户：
“我之前是不是说过想做客户端？”
│
▼
Memory Search
│
┌─────┴─────┐
│ │
Keyword Vector
│ │
└─────┬─────┘
│
▼
Relevant Memories
│
▼
Context Builder
│
▼
LLM
系统找到相关记忆之后，并不会直接把所有历史聊天塞给模型。
而是：
- 找到相关长期记忆；
- 从完整原文中截取相关片段；
- 根据上下文预算筛选；
- 添加来源标签；
- 最后注入 LLM Context。
这样可以避免聊天越久，请求 Token 越来越夸张。
八、为什么我还要继续优化长期记忆？
虽然长期记忆已经能够正常工作，但这部分离我理想中的状态还有很远。
现在解决的是：
“能够记住。”
后面真正需要解决的是：
“什么时候应该想起来？”
这两件事情其实完全不同。
未来我希望继续优化几个方向。
1. 记忆分类
不是所有记忆的重要程度都一样。
例如：
身份信息
长期偏好
项目经历
人物关系
临时计划
普通聊天
未来应该有不同生命周期和权重。
2. 时间因素
两年前的一次临时计划，与昨天刚说过的计划，不应该拥有相同优先级。
因此记忆检索需要更加合理地考虑：
相关度
+
重要度
+
时间
+
出现频率
3. 更强的语义召回
目前默认方案非常节省资源。
但随着服务器升级以及后续客户端出现，未来可以逐渐增加：
- 更好的 Embedding；
- Hybrid Search；
- Rerank；
- Memory Graph；
- 关系记忆。
让八千代真正能够把不同时间说过的事情联系起来。
4. 更自然的记忆使用方式
理想中的长期记忆不是：
“根据长期记忆第 3 条，你曾经……”
而应该像人类一样，自然地把过去的事情融入聊天。
真正好的长期记忆，用户甚至不应该明显察觉：
“系统刚刚执行了一次向量数据库查询。”
它应该只是让角色显得：
真的记得。
九、Live2D：让 AI 不只存在于文字里
八千代的另一个核心部分是 Live2D。
项目目前集成 Cubism Runtime，并拥有独立的 Live2D Studio 与 Room Runtime。
最基本的结构是：
LLM
│
▼
回复文本
│
├────► TTS
│
└────► Emotion / Expression
│
▼
Live2D
目前 Room 已经能够通过对话状态驱动部分：
- 表情；
- 动作；
- 说话状态；
- 场景反馈。
而这也是项目以后非常值得继续深化的方向。
最终我希望八千代不是：
聊天框 + Live2D 装饰
而是：
LLM
↓
情绪
↓
表情
↓
动作
↓
语音
↓
Live2D
形成真正统一的角色表达。
十、MCP：让八千代拥有“工具”
如果说长期记忆解决的是：
八千代能不能记住过去。
那么 MCP 解决的则是：
八千代能不能做事情。
现在 Room 已经开始支持 MCP。
因此理论上可以让 LLM 调用：
搜索
文件
API
程序
数据库
本地工具
自定义服务
这也是月读空间从 AI Chat 向 Agent 发展的关键一步。
传统聊天：
用户
↓
LLM
↓
文本回复
Agent：
用户
↓
LLM
↓
判断任务
↓
调用工具
↓
获取结果
↓
继续推理
↓
完成任务
两者体验会有本质上的区别。
十一、Agent OS：把 Agent 放进“操作系统”
这也是为什么后来出现了：
/agent-os
Agent OS 是月读空间目前非常重要的一次技术尝试。
它并不是传统意义上的操作系统，而是一套：
以 Web OS 形式组织 Agent、工具与应用的交互环境。
目前 Agent OS 作为独立应用运行，并复用月读空间的登录状态与部分服务。
我希望它解决一个问题：
现在很多 AI 功能都是这样的：
Chat
Chat
Chat
Chat
不管是搜索、文件、音乐、工具、Agent，最后全部挤进一个聊天窗口。
但真正复杂的数字空间不应该只有聊天框。
所以 Agent OS 开始尝试：
Desktop
├── Agent
├── File
├── Music
├── Tools
├── Terminal
├── Browser
└── Applications
让 AI 不再是整个界面本身。
AI 应该是：
存在于操作系统中的角色。
未来 Agent OS 也会继续进行大规模优化，包括：
- UI 重构；
- 窗口管理；
- 应用系统；
- Agent 调度；
- MCP 工具管理；
- 文件能力；
- 用户工作区；
- 八千代与 Agent OS 的融合。
最终希望它能成为整个“月读空间数字世界”的重要入口。
十二、内容与社区仍然是月读空间的重要部分
虽然现在 AI 相关功能越来越多，但月读空间并不会变成一个纯 AI 项目。
目前项目仍然拥有完整的内容与社区体系。
包括：
Hub
Stage
Article
Plaza
Gallery
Pixel
Wiki
Friend Links
Growth
Notifications
User Center
其中：
Stage
负责文章阅读与内容创作。
Plaza
提供留言、回复与互动。
Gallery
用于作品展示和图片分享。
Pixel
一个固定：
192 × 108
画布的像素工坊。
支持：
- 绘制；
- 发布；
- 点赞；
- 分享；
- PNG 导出；
- 移动端触控。
Wiki
用于整理《超时空辉夜姬！》相关：
- 角色；
- 音乐；
- 世界观；
- 制作资料；
- 术语。
Growth
月契成长系统目前已经拥有：
- 每日签到；
- 连续奖励；
- 每日任务；
- 等级；
- 邀请；
- 与八千代联动的成长反馈。
这些系统最终也会继续和 Room、Agent OS 进行更深入的整合。
十三、服务器从 2C2G 升级到 2C4G
随着功能持续增加，原来的服务器配置已经越来越容易遇到资源瓶颈。
之前使用：
2 Core
2 GB RAM
现在已经升级到：
2 Core
4 GB RAM
CPU 数量没有变化，但内存直接翻倍。
这对于当前月读空间实际上比较重要。
因为现在服务器运行的已经不仅是一个静态博客。
而是同时包含：
Node.js
Express
SQLite
Mem0
缓存
任务
后台管理
对象存储逻辑
Room API
通知
用户系统
未来可能还会继续增加：
Redis
Milvus
Agent
2GB 内存在这种情况下已经比较紧张。
升级到 4GB 后，至少给：
- Node.js；
- 系统 Page Cache；
- SQLite；
- Mem0；
- Redis；
- 部署过程；
留下了更多余量。
当然，服务器升级并不意味着可以无限增加服务。
后续依然会继续控制资源占用。
我的方向不是：
“服务器不够就继续加配置。”
而是：
能交给 CDN 的交给 CDN，能交给对象存储的交给对象存储，只有真正动态的请求才交给源站。
十四、为什么开始使用阿里云 OSS？
月读空间里面有大量不适合长期压在服务器磁盘上的资源。
例如：
- 用户上传图片；
- 文章封面；
- 图库；
- 大图片；
- 音频；
- 视频；
- 其他附件。
如果全部保存在服务器本地：
User
↓
Server
↓
Disk
所有访问都会消耗：
服务器磁盘 IO
+
服务器带宽
+
服务器连接数
随着访问量和文件数量增加，这显然不是一个好的长期方案。
因此现在开始使用：
阿里云 OSS。
结构变成：
┌── API ─────► 月读空间服务器
用户 ───────────────┤
└── Static ──► OSS
也就是说：
服务器主要负责：
- 权限；
- 数据库；
- API；
- 用户；
- AI；
- 动态逻辑。
而 OSS 主要负责：
- 图片；
- 附件；
- 静态资源；
- 大文件。
十五、OSS + CDN：进一步减少源站压力
单独有 OSS 还不够。
现在月读空间进一步配合：
阿里云 CDN。
形成：
User
│
▼
Alibaba Cloud CDN
│
├──── Cache Hit
│ │
│ ▼
│ 返回资源
│
└──── Cache Miss
│
▼
Alibaba OSS
用户访问已经缓存的资源时，甚至不需要再次访问 OSS 源站。
这对于：
- 图片；
- JS；
- CSS；
- 字体；
- 音频；
- 视频；
等资源来说非常合适。
现在整体架构也就逐渐从：
所有东西
↓
一台服务器
转变成：
┌── CDN
│
用户 ────────┼── OSS
│
└── Origin Server
不同资源开始承担不同职责。
这对于月读空间后面继续扩大功能非常重要。
十六、SQLite 为什么目前仍然没有换？
随着项目越来越复杂，一个很自然的问题是：
为什么不用 MySQL / PostgreSQL？
原因其实很简单：
目前没有必要为了“看起来专业”而换数据库。
SQLite 对现在的月读空间仍然有很多优势：
- 部署简单；
- 不需要独立数据库服务器；
- 性能足够；
- 事务可靠；
- 备份方便；
- 资源占用低；
- 很适合单节点个人项目。
项目通过：
better-sqlite3
直接进行数据库操作。
并且已经逐步加入：
backend/db/migrations/
管理数据库 Schema 变化。
因此数据库已经不是简单的：
改表结构 → 手动上传数据库
而是：
Version A
│
Migration
▼
Version B
│
Migration
▼
Version C
后续如果真的发展到 SQLite 成为明显瓶颈，再考虑迁移 PostgreSQL 会更加合理。
十七、Redis 与 Milvus：可选，而不是强制
另一个设计原则是：
增强能力可以存在，但不能让最基本的部署变得困难。
因此项目支持 Redis。
目前 Redis 可以参与：
- 缓存；
- 限流；
- Token 黑名单；
- 天气缓存；
- 验证码。
但 Redis 并不是启动项目的必要条件。
同样，Milvus 也作为可选的向量数据库存在。
例如未来可以用于更大规模的：
角色知识库
+
长期记忆
+
文档
+
语义检索
这样既保留未来扩展能力，又不会让普通部署变成：
Node
Redis
PostgreSQL
Milvus
MinIO
RabbitMQ
ElasticSearch
...
最后光启动服务就需要半天。
对于月读空间这种项目，目前我还是更喜欢：
默认简单，高级功能按需开启。
十八、安全现在也是项目的一部分
随着：
- 用户系统；
- 登录；
- 上传；
- OAuth；
- API；
- 管理后台；
越来越多，安全已经不能再靠“没人攻击我的小网站”来解决。
目前项目已经陆续加入：
- JWT；
- Cookie；
- bcrypt；
- CORS 白名单；
- CSP；
- Security Headers；
- 请求来源校验；
- JSON 重复 Key 检测；
- 上传文件 MIME 检查；
- 文件特征检查；
- SSRF 防护；
- 外部 URL 校验；
- API 限流；
admin / super_admin权限隔离。
例如生产环境中：
JWT_SECRET
过短时会直接拒绝启动。
上传文件也不仅检查：
.jpg
这样的扩展名。
而是同时考虑：
Extension
+
MIME
+
File Signature
这些事情看起来不像新 UI 那样明显，但实际上随着项目继续扩大，它们的重要程度会越来越高。
十九、测试：尽量避免“修一个地方坏三个地方”
现在的月读空间已经比较难完全依靠手动测试。
因此项目开始建立自动化测试。
包括：
node:test
以及：
Playwright
测试范围已经覆盖：
- API；
- 长期记忆；
- 用户成长系统；
- 登录；
- 权限；
- 消息审核；
- Room；
- TTS；
- 分享；
- Wiki；
- 导航；
- 移动端布局；
- Live2D；
- 设置页面。
近期很多关于：
Room 移动端
导航栏
键盘弹出
设置页面
的修改也都会同步增加 Regression Test。
因为当项目越来越大后：
“这次改动看起来没问题”
已经不能代表：
“整个项目没有问题。”
自动化测试会继续成为后面开发中的重要部分。
二十、下一阶段：继续优化 UI / UX
接下来最直观的一项工作仍然是：
UI / UX。
月读空间过去半年增加功能的速度非常快。
很多页面其实是在不同阶段逐渐发展出来的。
因此目前最重要的工作之一不是继续疯狂增加菜单，而是：
统一
整理
删减
重新组织
未来会继续重点调整：
- 全局导航；
- Room；
- Room Settings；
- User Center；
- Agent OS；
- 移动端布局；
- 页面层级；
- 信息密度；
- 动画；
- 触控体验。
特别是移动端。
未来越来越多功能不能再按照：
“PC 页面缩小一下”
的方式设计。
桌面端和移动端需要逐渐拥有不同的信息组织逻辑。
二十一、下一阶段：继续优化与八千代的聊天
Room 现在已经有很多功能，但最终衡量体验的依然是：
和八千代聊天到底自然不自然。
后续会继续优化：
Prompt
Memory
Knowledge
Emotion
Live2D
TTS
Context
Tools
尤其是让这些模块真正协作。
例如：
八千代发现用户在说以前的事情。
先检索长期记忆。
↓
发现和某一个项目有关。
↓
加载对应记忆。
↓
生成回复。
↓
分析回复中的情绪。
↓
切换 Live2D 表情。
↓
生成对应语气的 TTS。
整个过程应该成为：
一次完整的角色行为。
而不是六套互相不知道对方存在的系统。
二十二、下一阶段：Agent OS 将继续进化
Agent OS 目前仍然处于探索阶段。
后面我希望逐渐把它真正发展成：
八千代的数字工作空间。
可能逐渐形成：
Agent OS
│
├── Yachiyo
│
├── Chat
│
├── Files
│
├── Browser
│
├── Terminal
│
├── Music
│
├── Notes
│
├── MCP
│
└── Agent Applications
相比传统 AI 网站：
输入框
↓
回答
Agent OS 更希望形成：
目标
↓
Agent Planning
↓
选择工具
↓
执行任务
↓
获得结果
↓
继续执行
↓
最终完成
也就是说：
八千代未来可能不只是：
“告诉你怎么做。”
而是能够：
真正参与完成这件事情。
二十三、最重要的一件事：Flutter 全平台客户端
而接下来整个项目最大的一次变化，大概会是：
月读空间正式走出浏览器。
目前已经决定，后续计划使用：
Flutter
开发月读空间独立客户端。
这里的目标并不是：
打开一个 WebView
↓
加载 yachiyo.hk
也不是简单：
Electron
+
网页
而是重新思考月读空间在桌面端和移动端应该是什么样子。
也就是说：
它会是一套真正独立运行的应用，而不是给网站套一个窗口。
二十四、为什么选择 Flutter？
月读空间未来希望覆盖的环境越来越多。
包括：
Windows
macOS
Linux
Android
iOS
如果每个平台都单独开发：
Windows → C#
macOS → Swift
iOS → Swift
Android → Kotlin
Linux → GTK
对于个人项目来说维护成本非常夸张。
Flutter 则可以让大量：
UI
状态
逻辑
组件
网络层
实现跨平台复用。
同时它又不是简单的 WebView 套壳。
这对于月读空间来说非常适合。
二十五、客户端不会替代网站
未来 Flutter 客户端出现以后：
yachiyo.hk
依然会继续存在。
Web 版更适合：
- 内容分享；
- Wiki；
- 公共页面；
- 搜索引擎；
- 社区；
- 快速访问。
而 App 更适合：
- 八千代；
- Agent；
- Live2D；
- 本地文件；
- 本地模型；
- 系统通知；
- 桌面常驻；
- 离线缓存；
- 原生系统能力。
最终可能形成：
月读空间 Backend
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Web Desktop Mobile
yachiyo.hk Flutter Flutter
大家共享：
账号
API
内容
记忆
数据
但拥有不同的交互方式。
二十六、Flutter 会让很多以前很难做的事情成为可能
浏览器很强。
但浏览器终究存在很多限制。
例如：
- 本地文件；
- 系统托盘；
- 全局快捷键；
- 后台运行；
- 本地通知；
- 原生窗口；
- 本地模型；
- 本地数据库；
- 系统媒体控制；
- 多窗口。
进入 Flutter 客户端后，就可以更加自然地考虑：
八千代桌面常驻
或者：
Agent 后台任务
甚至：
本地 Ollama
+
本地文件
+
长期记忆
+
MCP
+
Live2D
形成：
Cloud + Local Hybrid Agent
例如：
八千代
│
┌─────────┴─────────┐
│ │
Cloud Local
│ │
月读空间 API Ollama
Account Files
Memory Tools
Community Local DB
这可能会成为未来月读空间非常重要的一条技术路线。
二十七、从网站，到真正的“月读空间”
如果回头看这个项目的发展，大概经历了几个阶段。
最开始只是：
个人主页
后来加入：
文章
然后加入：
用户
+
社区
再后来：
Live2D
+
八千代
之后又加入：
LLM
+
长期记忆
+
MCP
现在又出现：
Agent OS
下一阶段则会是：
Flutter App
所以这个项目的路线其实越来越清楚。
Website
↓
Community
↓
AI Character
↓
Memory
↓
Agent
↓
Agent OS
↓
Native Application
↓
Digital Space
这也是“月读空间”这个名字现在越来越符合项目本身的原因。
它已经不再只是：
一个放在互联网上的网站。
而是在逐渐变成：
一个能够承载内容、记忆、角色、工具与关系的数字空间。
写在最后
月读空间依然是一个个人维护的项目。
它不会像大型商业产品一样，有几十人的开发团队，也不会一次性完成所有设想。
很多功能都是：
想到
↓
尝试
↓
推翻
↓
重写
↓
发现问题
↓
继续优化
一点一点积累出来的。
现在服务器已经从：
2C2G
升级到了：
2C4G
静态资源和用户资源也开始通过：
Alibaba Cloud CDN
+
Alibaba Cloud OSS
进行分发。
接下来则会继续完成几件事情：
- 继续统一和优化月读空间 UI / UX；
- 继续优化 Room 与八千代的聊天体验；
- 进一步完善长期记忆；
- 继续推进 Live2D、情绪与语音联动；
- 继续完善 Agent OS；
- 推动 Agent 与 MCP 能力融合；
- 开始 Flutter 全平台客户端的设计与开发。
其中最后一项，也可能会成为月读空间下一阶段最重要的一次改变。
未来的月读空间，希望不会只是：
“打开浏览器访问一个网址。”
而可能是：
打开电脑，八千代就在这里。
打开手机，之前的聊天、记忆和空间仍然存在。
她知道你之前做过什么，也可以使用工具帮你继续完成事情。
文章、创作、社区、Agent、Live2D 与你的数字生活逐渐连接起来。
这大概就是我目前对于“月读空间”最终形态最接近的一种描述：
给日常留一点月光。
然后，让这束月光真正拥有记忆。
相关链接
本文记录的是月读空间当前阶段的技术实现与未来方向。项目仍然在快速开发中，因此部分架构和功能会随着后续版本继续变化。