Starting 2.0 of LobeHub(LobeChat): A System Reconstruction and Reflection

[arvinxx]

English | 简体中文

Over the past period, LobeChat has received widespread attention and support from the community, which has greatly encouraged us. However, at the same time, we are fully aware that as the user base grows and application scenarios become more complex, the architectural bottlenecks and product positioning limitations of LobeChat 1.0 are increasingly apparent. The performance issues repeatedly mentioned in community feedback, along with our own reflections on the future form of AI interaction, all point to the same conclusion: a simple version iteration is no longer sufficient to meet the challenges; what we need is a complete system reconstruction and directional upgrade.

Therefore, the development of LobeChat 2.0 has officially begun, and the product core will also undergo a redefinition.

Evolution of the Core Concept: From "Chat" to "Hub"

The first step is a brand-level upgrade: our product name will be upgraded from "LobeChat" to "LobeHub".

We believe that the next generation of AI applications will no longer be limited to "conversations" between a user and a single AI, but will evolve into a "hub" connecting users, diverse agents, vast knowledge, and external services. The term "LobeHub" more accurately captures our vision for the future: an open, modular, and scalable AI ecosystem platform.

Fundamental Architectural Transformation: Server-Centric

The architectural evolution of LobeChat was not achieved overnight but went through a clear iterative process that progressively approached the core of the problem:

• Era 0.x: Purely client-side form. The initial version was an application running entirely in the browser, which provided users with a very low deployment barrier. However, its limitations were also obvious: all data and state were tied to a single browser, making persistence and cross-device synchronization impossible.
• Era 1.x: Exploration and Compromise of a Hybrid Architecture. To address the issue of data persistence, we introduced a server-side version while retaining the pure browser version, and developed a desktop client in Q2 this year. This hybrid model, with browser, server, and desktop coexisting, met the needs of different users but also caused fragmentation in product experience and complexity in the technical architecture. It was more of a "compromise" than a final solution.

This hybrid model’s inherent contradictions became evident when supporting more complex AI application scenarios. This raises a fundamental question: how can a program that only runs when the user opens the browser execute a DeepResearch task that may take tens of minutes? And how can it perform scheduled tasks that run automatically in the background?

The answer is clearly no. This is precisely why version 2.0 is determined to restructure with the Server as the core. Many AI capabilities are essentially asynchronous and long-cycle. What users need is a reliable backend that can independently and continuously execute tasks after receiving instructions, while the frontend interface merely serves as a window to issue commands and receive results.

Therefore, we believe that an asynchronous architecture is the true path to efficient human-AI collaboration. Unifying the state, memory, knowledge base, and task execution of all Agents on the server side will evolve LobeChat from a temporary chat tool into a truly reliable AI work platform.

Addressing User Pain Points: A Complete Overhaul of Performance and Experience

We have not only heard the community feedback about app lag and slow response times but have also conducted an in-depth analysis of its technical root causes. The crux lies in the RSC architecture introduced during the 0.x phase.

I must honestly say that we chose RSC initially because it was widely regarded by the Next.js and React communities as the future direction, and as technology explorers, we embraced this new feature at the earliest opportunity. This was driven by a proactive pursuit of cutting-edge technology and a hope to leverage the latest solutions to benefit our product.

However, after nearly two years of deep practical experience, we have reached a firm conclusion that may run counter to this trend but is grounded in the reality of our product: For an application like LobeChat, which involves high-frequency, real-time interactions, RSC may not be the right answer.

RSC can theoretically reduce the initial JavaScript bundle size and help with SEO. However, in high-frequency interactive application scenarios like LobeChat, its drawbacks become very prominent. The essence of the RSC architecture is to render components on the server and then stream the results to the client. This means that even lightweight, high-frequency user interactions such as switching conversations may trigger a round-trip network request to the server. For conversational applications that demand instant response and smooth experience, this network latency embedded in the architecture is an unavoidable performance bottleneck. Every click is accompanied by subtle but real "micro-lags," which accumulate and seriously affect the product's interactive experience.

Therefore, in version 2.0, we decided to fully return to SPA. This choice was made based on long-term practice and a deep reflection on the relationship between technology and product.

Core Functional Pillars of LobeChat 2.0

On a brand-new concept and architecture, we will build a series of truly future-oriented features that embody collaborative value:

• Agent Runtime: A new runtime designed for Agents, whose core is to empower Agents with strong tool-calling capabilities. This means Agents will no longer be limited to text generation but will be able to call external APIs, access databases, execute code, and thus interact with the real world. This is the foundation for Agents to evolve from "chat companions" to "problem solvers."
• AI Team: Based on the powerful Agent Runtime, you will be able to create teams composed of multiple specialized Agents (such as "copywriting expert," "data analyst," "code reviewer"), allowing them to collaborate by dividing tasks and communicating internally to accomplish complex tasks that a single Agent cannot handle.
• Knowledge Base 2.0: We will significantly upgrade the capabilities of the knowledge base, with the core goal of breaking down the barriers between LobeHub and users' existing knowledge systems. To this end, we will gradually support integration with more mainstream third-party data sources, such as Notion, Google Drive, Feishu Docs, Yuque, and others. This enables Agents to build upon your existing workflows and knowledge accumulation, providing assistance that is more contextual and valuable.
• Personal Memory and Agent Memory: We will restructure the memory system and clearly divide it into two levels: personal memory will focus more on dynamically capturing individual user preferences by analyzing daily conversations and operational habits to automatically form a profile of your preferences. Agent memory, on the other hand, will concentrate on its own professional domain. As the Agent’s versions iterate and improve, its domain knowledge will be continuously accumulated and enhanced, enabling it to perform more professionally in specific tasks.
• Service-oriented Agent Marketplace: We will launch a brand-new Agent marketplace. The term "service-oriented" means that any developer can publish their own created Agents with specific capabilities and run them on LobeHub’s server side. This is not a private deployment but a public capability platform open to all users. Our goal is to build a thriving Agent ecosystem where innovative Agents can be discovered and used by more people.
• Desktop Official Release: After half a year of in-depth community testing and feedback, the desktop application will be officially released in version 2.0. We have continuously refined it based on extensive user feedback, and the official version will bring better stability, performance, and a more complete localized experience.
• Mobile App: The LobeChat mobile app has now entered public testing and will also be officially released in version 2.0. This marks the completion of LobeHub’s experience across all major platforms, ensuring that your AI assistant and knowledge system can seamlessly connect anytime, anywhere.

Future Outlook: Thoughts on Workspace, API, and Commercialization Models

2.0 is a brand new starting point. Moving forward, our roadmap will focus on further expanding the ecosystem:

• Workspace (Team Space): Designed for team collaboration, providing shared Agents and knowledge systems to truly integrate the power of AI into organizational workflows.
• API Support: LobeHub will offer a complete API interface, which is not only a technical opening but also an opening of the ecosystem. Enterprises and developers can seamlessly integrate their own businesses with LobeHub, creating unlimited possibilities.
• About Commercialization: We deeply understand that the vitality of the open-source community comes from openness and sharing. Therefore, all core features will remain permanently open source. At the same time, for the sustainable development of the project, we have decided to officially start exploring commercialization under the self-hosted mode in version 2.0. Workspace and API will be the first value-added features we explore, mainly targeting teams/enterprise users with more advanced needs. We believe a healthy business model is the foundation for the long-term prosperity of open-source projects, not an opposing force. We look forward to hearing feedback from the community to help us jointly explore a healthy path of coexistence between open source and business.

Conclusion: The Next Era Is More Than Just "Chat"

The core goal of LobeHub 2.0 is to build a unified platform connecting users, agents, knowledge, and services. We firmly believe that the next era of AI is not only about "chatting" but also about efficient and intelligent "collaboration."

We are advancing this work on the next branch and welcome you to join us: 👉 GitHub Development Branch

Whether you are trying out the new version, participating in design discussions, or directly submitting code, each of your contributions is powering the construction of the next-generation AI platform. Looking forward to working with you.

[arvinxx]

English | 简体中文

在过去的一段时间里，LobeChat 得到了社区的广泛关注与支持，这让我们备受鼓舞。但同时，我们也清醒地认识到，随着用户体量的增长和应用场景的复杂化，LobeChat 1.0 的架构瓶颈与产品定位局限性正日益凸显。社区反馈中被反复提及的性能问题，以及我们自身对 AI 交互未来形态的思考，都指向了同一个结论：一次简单的版本迭代已不足以应对挑战，我们需要的是一场彻底的体系重构与方向升级。

因此，LobeChat 2.0 的开发正式启动，同时也将对产品内核进行一次重新定义。

核心理念的演进：从「Chat」到「Hub」

首先要进行的是品牌层面的升级：我们的产品名将从 「LobeChat」 升级为 「LobeHub」。

我们认为，下一代 AI 应用的形态，将不再局限于人与单个 AI 的“对话”，而是演变为一个连接用户、多元化 Agent、海量知识与外部服务的“枢纽”。「LobeHub」一词将能更精准地描绘了我们对未来的构想：一个开放、模块化、可扩展的 AI 生态平台，一个人与 Agent 的协同中枢。

架构的根本性变革：以 Server 为核心

LobeChat 的架构演进并非一蹴而就，而是经历了一个清晰的、不断趋近问题本质的迭代过程：

• 0.x 时代：纯粹的客户端形态。 最初的版本是一个完全运行在浏览器中的应用，这为用户带来了极低的部署门槛。但其局限也显而易见：所有数据和状态都与单个浏览器绑定，无法实现持久化与跨设备同步。
• 1.x 时代：混合架构的探索与妥协。 为了解决数据持久化的问题，我们引入了服务端版本，同时保留了纯浏览器版本，并于今年 Q2 开发了桌面端。这种浏览器、服务端、桌面端并存的混合模式，虽然满足了不同用户的需求，但也造成了产品体验的割裂与技术架构的复杂化。它更像是一种“妥协”而非终极方案。

这种混合模式在支撑更复杂的 AI 应用场景时，其内在的矛盾便暴露无遗。这引出了一个根本性的问题：一个只能在用户打开浏览器时运行的程序，如何执行一个可能耗时数十分钟的深度研究任务（DeepResearch）？又如何实现一个定时的、在后台自动执行的任务？

答案显然是否定的。这正是 2.0 决心以 Server 为核心 进行重构的根本原因。AI 的许多能力，本质上是异步的、长周期的。用户需要的是一个可靠的后端，在接收指令后能够独立、持续地执行任务，而前端界面仅仅是下达指令和接收结果的窗口。

因此，我们认为，异步架构才是通往人与 AI 高效协作的正道。 将所有 Agent 的状态、记忆、知识库以及任务执行都统一到服务端执行，将使得 LobeHub 从一个临时对话工具进化为一个真正可靠的 AI 工作平台。

直面用户痛点：性能与体验的彻底革新

社区中关于应用卡顿、响应迟缓的反馈，我们不仅听到了，也对其技术根源进行了深入的分析——其症结在于 0.x 时期就引入的 RSC 架构。

我得坦诚地说，当初选择 RSC 是因为它被 Next.js 与 React 社区普遍视为未来的方向，而我们作为技术探索者，第一时间拥抱了这个新特性。这背后是对技术前沿的积极跟进，也是希望通过最新的解决方案为产品带来优势。

然而，在长达近 2 年的深度实践后，我们得出了一个可能与这个趋势相悖，但却基于我们产品现实的结论：对于 LobeChat 这样高频、即时交互的应用，RSC 可能并非正确的答案。

RSC 在理论上能够减少初始加载的 JavaScript 体积，并有助于 SEO。但在 LobeChat 这样的高频交互应用场景中，它的弊端则非常突出。RSC 架构的本质，是通过服务端渲染组件，再将结果流式传输到客户端。这意味着即便是像切换会话这样的高频次、轻量级的用户交互，都可能触发一次到服务器的往返网络请求。对于追求即时响应与流畅体验的对话式应用而言，这种内嵌在架构中的网络延迟，是无法根除的性能瓶颈。每次点击都伴随着难以察觉却真实存在的“微卡顿”，这累积起来严重影响了产品的交互体验。

因此，在 2.0 中，我们决定将全面回归到 SPA。这是我们基于长期实践，对技术与产品关系的深度反思后做出的选择。

LobeChat 2.0 的核心功能支柱

在全新的理念与架构之上，我们将构建一系列真正面向未来、体现协同价值的功能：

• Agent Runtime：一个为 Agent 设计的全新运行时，其核心是赋予 Agent 强大的工具调用能力。这意味着 Agent 将不再局限于文本生成，而是能够调用外部 API、访问数据库、执行代码，从而与真实世界进行交互，是 Agent 从“聊天伴侣”进化为“问题解决者”的基础。
• AI 团队 (AI Team)：基于强大的 Agent Runtime，你将可以创建由多个专用 Agent（如“文案专家”、“数据分析师”、“代码审查员”）组成的团队，让它们能够分工协作，通过内部沟通和任务流转来完成单一 Agent 无法胜任的复杂任务。
• 知识库 2.0：我们将对知识库进行一次重要的能力升级，其核心目标是打破 LobeHub 与用户现有知识体系之间的壁垒。为此，我们将逐步支持接入更多主流的第三方数据源，例如 Notion、Google Drive、飞书文档、语雀等。这使得 Agent 能立足于你已有的工作流与知识沉淀，提供更具上下文和价值的辅助。
• 个人记忆与 Agent 记忆：我们将开发独有的记忆系统，并将其清晰地划分为两个层面：个人记忆将更侧重于对用户个体偏好的动态捕捉，它通过对日常对话与操作习惯的分析，自动形成关于你的偏好画像。而 Agent 记忆则专注于其自身的专业领域，随着 Agent 的版本迭代与优化，其领域知识会得到不断沉淀与增强，使其在特定任务上表现得更加专业。
• 服务化的 Agent 市场：我们将推出全新的 Agent 市场。这里的「服务化」是指，任何开发者都可以发布自己创建的、具备特定能力的 Agent，并在 LobeHub 的服务端上运行，这将会是一个面向所有用户的公开能力平台。我们的目标是构建一个繁荣的 Agent 生态，让创新性的 Agent 能够被更多人发现和使用。
• 桌面端正式版：在经历了社区长达半年的深度测试与反馈后，桌面端应用将在 2.0 中正式发布。我们根据大量的用户反馈进行了持续打磨，正式版将带来更佳的稳定性、性能与更完善的本地化体验。
• 移动端 App：LobeChat 移动端目前已进入公开测试阶段，同样将在 2.0 中发布正式版本。这标志着 LobeHub 在所有主流平台上的体验闭环，确保你的 AI 助手与知识体系能够随时随地无缝衔接。

远景展望：Workspace、API 与商业化模式的思考

2.0 是一个全新的起点。在此之后，我们的路线图将聚焦于生态的进一步扩展：

• Workspace (团队空间)：面向团队协同，提供共享的 Agent 与知识体系，让 AI 的力量真正融入组织的工作流。
• API 支持：LobeHub 将提供完整的 API 接口，这不仅是技术的开放，更是生态的开放。企业与开发者可以将自身业务与 LobeHub 无缝集成，创造无限可能。
• 关于商业化：我们深知开源社区的活力源于开放与共享。因此，所有核心功能将永久保持开源。同时，为了项目的可持续发展，我们决定在 2.0 版本中，正式开启在自部署模式下的商业化探索。Workspace 与 API 将作为我们探索的首批增值功能，主要面向有更高级需求的团队/企业用户。我们认为，健康的商业模式是开源项目长期繁荣的基石，而非对立面。我们非常期待听到社区对此的反馈，帮助我们共同探索一条开源与商业共生的健康路径。

结语：下一个时代，不止于“聊天”

LobeHub 2.0 的核心目标，是构建一个连接用户、Agent、知识与服务的统一平台。我们坚信，AI 的下一个时代，价值不止在于「聊天」，更在于高效、智能的「协作」。

我们正在 next 分支上推进这项工作，欢迎你的加入：👉 GitHub 开发分支

无论你是试用新版、参与设计讨论，还是直接提交代码，你的每一次贡献都是在为构建下一代 AI 平台注入力量。期待与你同行。

[htdohk]

赞，异步完成确实是个非常合理的方向，没准等到3.0就可以是个OS了😂

[arvinxx]

OS 感觉有点远，做好 Hub 😆

[Coooolfan]

精彩，期待。

[AAEE86]

作为个人用户，用过很多同类应用，除了 lobechat 都无法满足我的需求，但是 lobechat 的性能问题一直困扰着我，期待基于 SPA 的重构

[bamboo512]

支持，LobeChat 的 UI 一直都很出色，我也一直在向朋友推荐 LobeChat。但他们都说太卡了，我自己也觉得使用流畅度远不如其他（比如 gemini.google.com），我用的还是 M4 芯片，网页性能应当是十分出色的，Speedometer 跑分也非常高。性能问题是我身边很多人不使用的主要原因。
btw，基于 SPA 的重构，会采用 TanStack 吗？

[ChenLuoi]

我自己部署和使用的ai服务中，lobechat从产品形态上是我最喜欢的，支持在线同步，更新迭代也足够快。
但是一直值得诟病的就是性能低下，rsc导致的使用体感上的卡顿，客户端相比cherry studio几乎翻倍的内存占用。MCP市场做的好有什么用呢？我宁愿在浏览器中打开，根本不会去使用一个光启动就要占用1G内存的应用。
这段时间我更多地会去cherry studio，即使它消息同步起来非常麻烦。
能够去重新梳理，做2.0，让我重新对lobechat有了期待。

另外，2.0的发布计划是怎么样的？什么时候能否释放呢？我看到release中已经有了不少next的构建了，目前是否建议试用2.0版本呢？如果试用的话，怎么识别哪些版本是可用的呢？

[arvinxx]

感谢鞭策。

计划月底左右发布 2.0 ，next 中的版本不建议日常使用。如果要提前测试，欢迎加入 Discord 频道。关于哪些版本可用的问题会在 Discord 及时同步。

[wzxjohn]

@arvinxx 想要提前测试的话，目前有部署文档么？

[arvinxx]

@arvinxx 想要提前测试的话，目前有部署文档么？

以前的lobe-chat-database 换成lobehub即可

[xWTF]

@arvinxx 想要提前测试的话，目前有部署文档么？

以前的lobe-chat-database 换成lobehub即可

建议把 2.0 的 docker repo 更名提示放到 README 的 Version Information 下方，以及简单提下 database 可以直接切换到 lobehub/lobehub 镜像

最近发布了 gpt 5.1 以及 gemini 3 系列模型，没有一直关注 GitHub 开发动态的话，会比较容易错过这两个点导致找不到最新版

[martin666888]

我想问一下，现在Windows桌面端2.0版本的lobechat是不是很多功能都还不太完善呢？我自己在使用任何模型调用mcp插件，例如context7或者exa，第一次永远无法响应

模型开始调用插件后会自己卡住，我要手动填重新回答才有可能正确返回。
还有一个最大的问题，就是不能把lobechat放在其他页面下面，必须要显示在桌面顶层，看着它，才能正常去调用插件或返回模型答案，否则就是阻塞的，这点体验很不好，因为我在等待模型回答的过程中肯定希望再看看别的地方，但每次我切到其他应用再回来，发现它还是停留在最开始回答的阶段，甚至连工具调用都还是卡着的阶段。

[arvinxx]

可能是 bug ，最近在改工具调用的整个流程，我晚点看下

[satlxq]

Expecting a new start~

[cloverzrg]

我的 1 核 E5-26xx v4 的 VPS 迫不及待了，现在用起来卡卡的，内存 400MB，CPU 动不动就 70%

[CXwudi]

我就想知道1.x什么时候把gpt-5.1加进去，我现在用不了5.1的内置联网搜索

[arvinxx]

1.x 不迭代了，要用 gpt-5.1 的话直接先用 2.0-next 吧

[CXwudi]

2.0-next 什么时候上database，有个大概timeline吗

[arvinxx]

2.0 默认就是 database

[CXwudi]

啊好吧，我把文章里的0.x和1.x看成了整个2.0的开发周期了，我的问题😅，等我下班了立即试试2.0

[yziqi]

请问升级到2.x，自部署的话需要重新部署吗？还是像1.x的时候，直接更新docker就行了，配置什么的都保持不变。

[0xff26b9a8]

想问一下如果现在想从1.x的最后一个版本升级到2.0-next测试的话，有什么需要注意的吗，切换镜像就能无缝升级上来吗？

[CXwudi]

@yziqi @0xff26b9a8 在docker compose文件里直接把lobechat换成新的lobehub镜像就行

[0xff26b9a8]

好的，感谢

[m0eak]

docker镜像没有更新v2.0.0吗

[zzwtsy]

改成这个镜像了：https://hub.docker.com/r/lobehub/lobehub

[oreporan]

Hey 👋
Looking forward to 2.0

Quick question -
Will 2.0 still be based on nextjs? from the post here it seems you're discontinuing Serverside components, but looking at the branch I still see next all over the code
I'd like to prepare by knowing the architectural changes for self-hosting and deploying

Thanks!

[ONLY-yours]

based on nextjs

but the front pages will change to spa

self-deployment method for docker remains the same.

[oreporan]

Can you explain please the purpose of nextjs in this case? is it just because of the routing system? or just because thats the given codebase?

[cloverzrg]

从日志上看，貌似 2.0 也是把语言的渲染放在了 node 端？