多 Agent 设计理念
为什么一个"全能 AI"不如一队"专家 AI"——LobeChat 的设计哲学
你已经在用多 Agent 了
打开 LobeChat，你可以创建一个"代码专家"、一个"写作助手"、一个"翻译官"，每个都有不同的系统提示词和个性。这不只是换了个名字——背后是完全独立的Agent配置。
一个 Agent 负责所有事情，提示词会越来越长、越来越复杂，AI 的注意力被分散。专业化的 Agent 可以有更精炼的提示词，更聚焦的行为，更高的输出质量。
LobeChat 的三个核心概念
一个 AI 角色实例，有自己的名字、头像、系统提示词、工具权限。是 LobeChat 的基本单位。
你和某个 Agent 的一段对话历史。每个 Session 对应一个 Agent，保存完整的消息记录。
赋予 Agent 调用外部工具的能力：搜索网络、计算代码、调用 API。让 AI 从"对话者"变成"执行者"。
和 LobeHub 生态系统的联系
LobeChat 不只是一个聊天工具，它连接着 LobeHub 生态：
Agent 市场
数千个社区制作的专业 Agent，一键安装到你的 LobeChat
插件市场
各种工具插件，让 Agent 能搜索、计算、访问外部 API
桌面应用
基于 Electron 的跨平台桌面版，支持本地 LLM 访问
知识点检测
你既需要 AI 帮你写代码，又需要它帮你写营销文案。最佳做法是什么？
插件系统架构
AI 如何从"只能聊天"变成"能做事"——Function Calling 的工作原理
插件让 AI 走出对话框
没有插件的 AI 就像一位知识渊博但只能纸上谈兵的顾问——他知道怎么做股票分析，但无法真正查询今天的股价。插件系统让 AI 可以"打电话"给外部世界。
这个机制在 OpenAI 那里叫 Function Calling，在 Anthropic 那里叫 Tool Use，本质是一样的：AI 说"我需要调用这个工具"，系统执行并把结果告诉 AI。
一个插件调用的完整过程
LobeChat 插件的数据结构
{
"identifier": "weather",
"meta": {
"title": "实时天气",
"description": "查询天气数据"
},
"api": [{
"name": "getCurrentWeather",
"parameters": {
"city": { "type": "string" }
}
}]
}
这是一个插件的描述文件（JSON 格式）
插件的唯一标识符：weather
展示给用户的元数据
在插件市场显示的名称
插件功能描述
这个插件提供的 API 函数列表
函数名：getCurrentWeather（获取当前天气）
这个函数需要一个参数
city 参数，类型是字符串（城市名称）
知识点检测
当你问 LobeChat："帮我搜索今天 AI 领域的新闻"，AI 是如何获取这些信息的？
模型提供商抽象
LobeChat 如何支持 30+ 种 AI 模型——用一套统一接口抹平差异
USB 接口的启示
为什么你的键盘、鼠标、U盘都能插同一个 USB 接口？因为 USB 定义了一套标准协议，所有设备只要符合这个协议就能工作，无论里面的实现多不一样。
LobeChat 用同样的思路解决多模型问题：定义一套统一的"模型接口"，不管后面是 OpenAI、Claude 还是本地的 Ollama，前端代码都用同样的方式调用。
提供商抽象层的工作方式
代码里的提供商结构
export const anthropicProvider = {
id: 'anthropic',
name: 'Anthropic',
models: [
{ id: 'claude-sonnet-4-5',
contextWindowTokens: 200000 },
],
chatCompletion: async (payload) => {
return createAnthropic(payload)
}
}
导出 Anthropic 提供商的配置对象
在系统内部的唯一 ID，用于路由判断
展示给用户的名称
这个提供商支持的模型列表
模型 ID 和它支持的最大上下文 token 数（20万！）
（更多模型...）
核心方法：接收统一格式的请求，发给 Anthropic API
调用 Anthropic 专用的创建函数，处理格式差异
知识点检测
LobeChat 刚发布了一个新版本，支持了某家新 AI 公司的模型。从代码架构角度，这需要修改哪里？
会话记忆与持久化
消息如何被保存、如何跨设备同步——以及"记忆"到底存在哪里
AI 其实每次都是"失忆"的
一个令人惊讶的事实：AI 模型本身没有记忆。每次对话，LobeChat 都要把完整的历史消息作为上下文发给 AI。AI "记得"你说过什么，是因为你说过的话一直在消息列表里。
每个 AI 模型都有一个上下文窗口，就像一张办公桌——桌面越大，能同时看到的材料越多，但总有上限。当对话历史超出窗口，最早的消息会被移出，AI 就"不记得"了。
本地存储 vs 云端同步
本地模式（默认）
数据存在浏览器的 IndexedDB。无需服务器，完全离线可用。缺点：换设备数据不同步，清除浏览器数据会丢失记录。
云端同步模式
配置 Clerk 或自托管 NextAuth 后，登录账号，数据存储在后端数据库。多设备实时同步，消息不会丢失。
WebRTC P2P 同步
无需服务器的设备间直接同步方案。LobeChat 内置基于 CRDT 的点对点同步，保证多设备数据一致性。
消息是如何存储的
interface ChatMessage {
id: string
role: 'user' | 'assistant' | 'system'
content: string
sessionId: string
createdAt: number
parentId?: string
tools?: ToolCall[]
}
每条聊天消息的数据结构定义
消息的唯一 ID（一串随机字符）
消息发送者角色：用户/AI助手/系统提示
消息的实际文字内容
这条消息属于哪个会话
发送时间（Unix 时间戳，毫秒）
父消息 ID：实现消息树形分支结构（? 表示可选）
如果这条消息调用了工具，工具调用记录存这里
知识点检测
你和一个 LobeChat Agent 聊了 50 条消息，第 51 条你问"你刚才说的第 3 条建议是什么"，AI 怎么知道这个答案？
自托管部署指南
在自己的服务器上运行 LobeChat——完全掌控数据和配置
为什么要自托管？
数据隐私
企业对话数据不经过第三方服务器，所有数据存在自己的基础设施里
深度定制
修改界面、添加定制插件、接入内部系统，cloud 版本不支持的都可以自己实现
成本控制
按量付费的云服务在高用量下成本高昂。自托管只需为服务器费用付费
LobeChat 的两种部署模式
只需 Next.js 服务器，数据存在用户浏览器。快速部署，适合个人使用。缺点：无法多设备同步，无用户管理。
需要 PostgreSQL + MinIO + Clerk（或 NextAuth）。支持多用户、跨设备同步、权限管理。适合团队和企业部署。
关键环境变量配置
OPENAI_API_KEY
OpenAI API 密钥，填了才能用 GPT 系列模型
ANTHROPIC_API_KEY
Anthropic API 密钥，用于 Claude 系列模型
DATABASE_URL
PostgreSQL 连接字符串，完整模式必须配置
S3_PUBLIC_DOMAIN
MinIO 或 S3 域名，用于文件上传和知识库存储
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
Clerk 认证服务的公钥，用于用户登录