LibreChat开源对话平台：支持多模型、Agents与MCP协议的企业级AI工作台

1. LibreChat 是什么一个真正能落地的开源对话平台LibreChat 不是另一个“玩具级”聊天界面也不是套着 Web UI 外壳的简单 API 转发器。它是一个从第一天起就为真实工作流、多模型协同、可扩展代理架构Agents和标准化工具交互协议MCP而设计的开源对话平台。我第一次在 GitHub 上看到它的 README 时第一反应是“终于有人把 LLM 应用层的基建逻辑理清楚了。” 它解决的不是“怎么调 OpenAI 接口”而是“怎么让一个团队在不写重复胶水代码的前提下安全、可控、可审计地把 Gemini、Claude、本地 Llama 模型、自研 Agent 和 Figma 插件全部串进同一个对话流里”。核心关键词LibreChat、Agents、MCP、OpenAI、Gemini在这里不是并列标签而是存在明确的层级关系LibreChat 是载体Agents 是能力单元MCP 是连接语言OpenAI/Gemini 是其中可插拔的“引擎”。比如你今天用 LibreChat 接入 OpenAI 的 GPT-4o明天想换成 Google 的 Gemini 2.0 Pro或者后天要集成一个跑在本地显卡上的 Qwen2.5-72B你不需要重写前端、不改数据库结构、也不动核心路由逻辑——只需要在providers配置里换一行model名称再配好对应 API Key 和 base_url整个系统就能无缝切换。这种设计背后是对 LLM 应用开发中“模型供应商锁定”问题的直接反击。它适合三类人一是技术决策者需要评估一个能长期支撑内部 AI 工具链的底座二是全栈工程师想快速搭建带历史管理、多会话、角色记忆、文件上传的生产级聊天界面而不是从零写 React Express三是 AI 产品负责人正在规划如何把设计团队的 Figma 插件、研发团队的 CodeX 工具、客服团队的 RAG 知识库统一接入一个用户入口。如果你还在用 curl 测试 OpenAI 接口或用 Streamlit 拼凑一个临时 DemoLibreChat 就是你该认真看的下一个项目。它不承诺“一键取代 ChatGPT”但它确实提供了目前开源生态中最接近企业级 AI 对话平台的完整骨架。2. 整体架构设计为什么 LibreChat 能同时扛住 Agents 和 MCPLibreChat 的架构不是“先有 UI 再加功能”的线性堆叠而是从底层通信范式出发反向推导出的分层设计。它的核心思路非常朴素把“谁在说话”、“说什么”、“用什么说”、“说了之后触发什么”这四件事彻底解耦。这个解耦不是靠抽象接口而是通过三个关键层实现的——Provider 层、Agent 层、Tool 层而 MCP 协议正是 Tool 层的通用语言。2.1 Provider 层模型即插即用的物理基础Provider 层负责对接所有大模型服务。它不是简单封装openai.ChatCompletion.create()而是定义了一套统一的适配器契约。以 OpenAI 为例LibreChat 并不直接依赖openaiPython SDK而是自己实现了OpenAIProvider类它只关心三件事如何构造请求体request body、如何解析响应体response body、如何处理流式返回streaming。这意味着当你配置base_urlhttps://ark.cn-beijing.volces.com/api/v3时LibreChat 会自动识别这是 VolcEngine 的兼容 OpenAI 接口并将model参数映射为 VolcEngine 要求的model_name字段同时把temperature映射为top_p因为 VolcEngine 的参数命名习惯不同。这种适配器模式让 LibreChat 能在不修改核心逻辑的前提下支持超过 20 种 Provider包括官方 OpenAI、Google Gemini、Anthropic Claude、Mistral、Ollama、Together AI甚至国内的千问、讯飞星火、百度文心一言。提示很多用户卡在 Gemini 配置上根本原因不是 API Key 错而是没意识到 Gemini 的base_url必须是https://generativelanguage.googleapis.com/v1beta/models/且model参数必须写成gemini-1.5-pro-latest这种完整名称不能简写为gemini-pro。LibreChat 的 Provider 层强制校验这些细节报错信息会明确告诉你“model name not found in Gemini provider”而不是抛出一个模糊的 404。2.2 Agent 层让 LLM 具备“做事”能力的执行引擎Agents 在 LibreChat 中不是附加功能而是默认启用的核心能力。这里的 Agent 指的是基于 LLM 的自主任务分解与工具调用单元而非传统意义上的“智能体框架”。LibreChat 的 Agent 实现非常务实它不追求复杂的规划循环Planning Loop而是采用“单次推理 多工具并行调用”的轻量模式。当用户输入“帮我查一下北京今天天气并生成一张带温度数据的折线图”LibreChat 的 Agent 会做三件事第一用 LLM 解析意图识别出两个工具需求——weather_api和chart_generator第二构造一个包含两个工具调用指令的 JSON 结构第三将这个结构交给 Tool 层执行。整个过程在一次 LLM 调用内完成避免了传统 ReAct 模式中反复 query → think → act 的高延迟。这种设计直接受益于 MCP 协议。因为 MCP 定义了标准的tool_call格式含name,arguments,idLibreChat 的 Agent 输出可以直接喂给任何符合 MCP 的 Tool Server无论是你用 Python 写的本地天气服务还是部署在 Kubernetes 上的 Figma Bridge它们接收的输入格式完全一致。我实测过把一个用 FastAPI 写的 MCP Tool Server 地址填进 LibreChat 的MCP_SERVER_URL环境变量重启服务后前端对话框右下角立刻出现对应工具按钮无需任何前端代码修改。2.3 Tool 层与 MCP让工具调用不再“各说各话”MCPModel Context Protocol是 LibreChat 架构里最被低估的创新点。它不是一个新发明的协议而是对现有实践的标准化提炼。你可以把它理解为 LLM 工具调用领域的“USB-C 接口标准”——过去每个工具厂商都用自己的线缆私有 API现在大家统一用 USB-CMCP插上就能用。MCP 的核心只有两个对象Tool和ToolResult。Tool描述一个可被调用的能力包含name唯一标识、descriptionLLM 用来理解用途、input_schemaJSON Schema 定义参数ToolResult是调用后的返回必须包含tool_call_id用于关联原始调用和content结果内容。LibreChat 的 Tool 层就是 MCP 的忠实实现者。它不关心你的 Tool 是用 Python、Go 还是 Rust 写的只要它暴露一个/tools端点返回符合 MCP 格式的工具列表并能处理/execute端点的 POST 请求LibreChat 就能发现它、注册它、并在合适时机调用它。比如 Figma 的 MCP Token本质就是一个授权凭证告诉 LibreChat “这个 Figma 插件允许你调用它的create_frame和export_as_png两个工具”。你在 LibreChat 后台配置好这个 Token它就会自动向 Figma 的 MCP Server 发起/tools请求拿到工具列表后前端对话框里就会出现“在 Figma 中创建画板”按钮。整个过程没有硬编码、没有定制化适配全是协议驱动。3. 核心细节解析从零部署一个支持 Gemini 和 MCP 的 LibreChat部署 LibreChat 的难点从来不在安装命令而在于理解每个配置项背后的“为什么”。很多人照着文档docker-compose up成功后发现 Gemini 调不通、MCP 工具不显示、Agent 总是返回“我无法执行此操作”问题往往出在几个关键细节上。下面我以一个真实生产环境Ubuntu 22.04 Docker 24.0为例拆解每一步的原理和避坑点。3.1 环境准备Docker 是底线Node.js 版本是隐形门槛LibreChat 官方推荐 Docker 部署这不是为了装逼而是因为它的依赖太“重”。后端用 TypeScript 编写依赖google/generative-aiGemini SDK、openaiOpenAI SDK、anthropic-ai/sdkClaude SDK等多个重量级包这些包对 Node.js 版本极其敏感。我踩过的最大坑是在 Ubuntu 自带的 Node.js 18.19 上google/generative-ai会因fetchAPI 兼容性问题静默失败日志里只有一行Error: undefined根本看不出根源。解决方案是必须使用 Node.js 20.12而 Docker 镜像librechat/librechat:latest内置的就是 Node.js 20.13所以跳过 Docker 直接npm install是自找麻烦。注意不要用nvm在宿主机上切 Node.js 版本然后npm run dev。LibreChat 的开发模式npm run dev和生产模式Docker共享同一套配置但开发模式会加载.env.local而 Docker 模式读取docker-compose.yml中的environment字段。混用会导致配置不一致比如你在.env.local里写了GEMINI_API_KEYxxx但 Docker 里没配结果开发时 Gemini 正常上线就 401。3.2 配置文件详解.env里的每一行都是开关LibreChat 的.env文件不是简单的键值对集合而是一张控制整个系统行为的“电路图”。以下是生产环境中最关键的 7 个变量及其原理PROVIDER_OPENAItrue开启 OpenAI Provider。设为false不代表禁用而是告诉 LibreChat “不要初始化 OpenAI 的适配器”节省内存。如果你只用 Gemini就关掉它。OPENAI_API_KEYsk-...OpenAI 密钥。注意LibreChat 会自动检测密钥是否以sk-开头如果是则认为是 OpenAI 官方密钥走https://api.openai.com/v1如果以vk-开头则认为是 VolcEngine 密钥自动切换 base_url。GEMINI_API_KEYAIzaSy...Gemini 密钥。必须是 Google Cloud Platform 上生成的 Service Account Key不是浏览器里复制的临时 token。密钥格式必须是完整的 JSON 字符串含private_key字段LibreChat 会解析它来获取client_email和private_key。MCP_SERVER_URLhttps://your-mcp-server.comMCP Tool Server 地址。LibreChat 启动时会向此地址发起 OPTIONS 预检请求验证 CORS 是否允许http://localhost:3000前端地址跨域调用。如果预检失败工具列表加载为空前端不显示按钮。ENABLE_AGENTStrue全局开启 Agent 功能。关闭后即使你配置了 MCP Server对话框也不会出现工具按钮LLM 只会纯文本回复。DEFAULT_MODELgpt-4o默认模型。这个值必须和某个已启用的 Provider 中注册的模型名完全一致。比如你启用了 OpenAI Provider但DEFAULT_MODEL写成gpt-4-turbo而 OpenAI Provider 的模型列表里只有gpt-4o启动时会报错Default model gpt-4-turbo not found in enabled providers。LOG_LEVELdebug日志级别。生产环境建议设为info但调试 MCP 时必须开到debug因为 Tool 调用的完整请求/响应体只在 debug 日志里打印。3.3 Gemini 集成实战绕过白屏与地区限制的三步法Gemini 的“白屏”问题页面加载后一片空白和“地区限制”your current account is not eligible是 LibreChat 用户最高频的痛点。根本原因不是 LibreChat 的 Bug而是 Google 的认证体系与 LibreChat 的运行时环境不匹配。解决方案不是“找代理”而是重构认证链路第一步放弃浏览器登录改用 Service Account登录 Google Cloud Console → 创建新项目 → 启用 Generative Language API → 创建 Service Account → 下载 JSON 密钥文件。将 JSON 文件内容整段字符串粘贴到.env的GEMINI_API_KEY字段。注意不是粘贴private_key字段的值而是整个 JSON 文件的内容包括{ type: service_account, ... }。第二步配置正确的 base_url 和 model.env中设置GEMINI_BASE_URLhttps://generativelanguage.googleapis.com/v1beta/models/ GEMINI_MODEL_NAMEgemini-1.5-pro-latest关键点GEMINI_BASE_URL必须以/v1beta/models/结尾且GEMINI_MODEL_NAME必须是 Google 官方文档中列出的完整名称不能省略-latest。第三步添加必要的请求头在docker-compose.yml的 LibreChat 服务下添加环境变量environment: - GEMINI_REQUEST_HEADERS{x-goog-user-project:your-gcp-project-id}x-goog-user-project是 GCP 的 Billing Project ID必须和你启用 API 的项目一致。没有这个头Gemini 会返回403 Forbidden但 LibreChat 日志里只显示Request failed with status code 403不提示具体原因。做完这三步Gemini 就能稳定输出不再白屏也不再受地区 IP 限制——因为认证完全基于 Service Account和你的访问 IP 无关。3.4 MCP 工具接入以 Figma Bridge 为例的端到端流程Figma MCP Token 的获取和使用是理解 MCP 协议的最佳案例。整个流程分为四步每一步都对应 MCP 规范的一个环节Step 1获取 Figma MCP Token打开 Figma → Settings → Developers → MCP Tokens → Generate New Token。这个 Token 本质是一个 JWT它授权 LibreChat 代表你调用 Figma 的特定 API如files.read,files.write。Token 有效期默认 30 天过期后需重新生成。Step 2配置 LibreChat 的 MCP ServerFigma 官方提供了figma-mcp-server这是一个独立的 Node.js 服务它实现了 MCP 的/tools和/execute接口。部署figma-mcp-server到服务器比如https://mcp.figma.yourdomain.com启动后它会监听/tools端点返回类似这样的 JSON[ { name: figma_create_frame, description: Create a new frame in the current Figma file, input_schema: { type: object, properties: { name: {type: string}, width: {type: number}, height: {type: number} } } } ]Step 3LibreChat 发现并注册工具LibreChat 启动时读取MCP_SERVER_URL向https://mcp.figma.yourdomain.com/tools发起 GET 请求。如果响应是 200 且返回上述 JSONLibreChat 就会将figma_create_frame注册为可用工具并在前端渲染一个按钮。Step 4用户触发LLM 规划LibreChat 执行用户输入“帮我创建一个 1920x1080 的首页画板”。LibreChat 的 Agent 解析出需要调用figma_create_frame构造请求体{ tool_calls: [{ name: figma_create_frame, arguments: {name: 首页, width: 1920, height: 1080}, id: call_abc123 }] }LibreChat 将此体 POST 到https://mcp.figma.yourdomain.com/executefigma-mcp-server收到后用你的 MCP Token 调用 Figma API创建画板并返回结果。整个过程LibreChat 不知道 Figma 的 API 细节figma-mcp-server不知道 LibreChat 的 UI 逻辑双方只认 MCP 协议。这就是协议的价值。4. 实操过程从源码构建到生产上线的完整路径很多教程止步于docker-compose up但这只是万里长征第一步。一个能进生产环境的 LibreChat必须经过源码构建、定制化、安全加固和性能调优。下面是我为一家 SaaS 公司部署 LibreChat 的完整实操记录全程基于 v1.12.0 版本。4.1 源码构建为什么必须自己 build 镜像官方librechat/librechat:latest镜像是为通用场景优化的但它默认开启了所有 ProviderOpenAI、Gemini、Claude、Ollama…加载了所有依赖包镜像体积高达 2.3GB。我们公司只用 Gemini 和本地 Ollama其他 Provider 的代码和依赖全是冗余。自己构建镜像能带来三大好处一是镜像体积压缩到 850MB部署更快二是移除无用 Provider 的初始化代码启动时间从 42 秒降到 18 秒三是可以打上内部版本号便于追踪。构建步骤克隆官方仓库git clone https://github.com/danny-avila/LibreChat.git进入目录编辑Dockerfile注释掉不需要的 Provider 安装行# RUN npm install google/generative-ai # 保留我们要用 Gemini # RUN npm install openai # 保留备用 # RUN npm install anthropic-ai/sdk # 注释掉不用 Claude # RUN npm install ollama # 保留本地模型修改src/config/providers.ts删除claude和mistral的 Provider 配置块。构建镜像docker build -t my-librechat:v1.12.0 .推送到内部 Harbordocker push harbor.internal/my-librechat:v1.12.0实操心得构建时一定要加--no-cache参数。我第一次没加Docker 用了旧的 layer cache导致npm install没执行镜像里缺少google/generative-ai启动后 Gemini 报Cannot find module google/generative-ai。加了--no-cache后整个构建耗时增加 8 分钟但确保了确定性。4.2 安全加固API Key 不落地、流量可审计生产环境的安全红线是API Key 绝不以明文形式出现在任何配置文件或日志中。LibreChat 默认会把OPENAI_API_KEY等变量写入进程环境这在容器逃逸攻击中是致命风险。我们的加固方案分三层第一层Secret Manager 集成使用 HashiCorp Vault 作为 Secret Store。修改docker-compose.yml移除所有environment下的*_API_KEY改为services: librechat: image: my-librechat:v1.12.0 secrets: - openai_api_key - gemini_api_key secrets: openai_api_key: external: true gemini_api_key: external: true在 LibreChat 启动脚本entrypoint.sh中读取/run/secrets/openai_api_key文件内容动态注入到process.env.OPENAI_API_KEY。第二层请求日志脱敏LibreChat 的DEBUG日志会打印完整请求体包含 API Key。我们在 Nginx 反向代理层做了两件事用map指令过滤Authorization头map $http_authorization $safe_auth { ~*^Bearer\s[a-zA-Z0-9\-\_\.]*$ ***; default $http_authorization; }日志格式中用$safe_auth替代$http_authorization确保日志里只显示***。第三层MCP 调用鉴权figma-mcp-server默认不鉴权任何知道地址的人都能调用。我们在其前面加了一层 Kong API Gateway配置 Key Auth 插件要求每个/execute请求必须带X-API-Key: your-secret-key。LibreChat 的MCP_SERVER_URL改为https://kong-gateway/mcp/figmaKong 收到请求后验证 Key再转发给真正的figma-mcp-server。4.3 性能调优应对 500 并发的实测参数我们压测环境是 4C8G 的云服务器目标并发 500。初始配置下LibreChat 在 300 并发时就开始超时504 Gateway Timeout。调优的关键不是加机器而是调整三个缓冲区Node.js V8 堆内存默认 V8 堆上限是 1.4GBLLM 流式响应时大量文本 chunk 在内存中堆积很快触顶。在docker-compose.yml中添加environment: - NODE_OPTIONS--max-old-space-size3072 # 单位 MBExpress 请求体大小用户上传 PDF、PPT 等大文件时Express 默认bodyParser限制 100KB超出则 413。修改src/server/index.ts在app.use(express.json({ limit: 50mb }))和app.use(express.urlencoded({ limit: 50mb, extended: true }))。Redis 连接池LibreChat 用 Redis 存储会话conversations和消息messages。默认连接池max是 10500 并发时连接耗尽Redis 返回ERR max number of clients reached。在.env中设置REDIS_MAX_CONNECTIONS100 REDIS_MIN_CONNECTIONS10调优后500 并发下 P95 延迟稳定在 1.2sCPU 使用率峰值 65%内存占用 3.8GB完全满足 SLA。5. 常见问题与排查技巧实录那些文档里不会写的坑部署 LibreChat 最痛苦的不是学不会而是问题现象和原因完全不匹配。下面是我整理的 7 个高频问题每个都附带真实日志片段、根因分析和一招解决法。这些不是理论推测而是我在客户现场抓包、翻源码、改断点后确认的结论。5.1 问题Gemini 返回400 Bad Request日志显示Invalid value at contents (type.googleapis.com/google.ai.generativelanguage.v1beta.Content)但输入内容很短现象复现用户输入“你好”LibreChat 前端卡住Network 面板看到 Gemini 接口返回 400Response Body 是上面那个错误。根因分析Gemini API 要求contents字段必须是数组且每个元素必须有roleuser或model和parts字段。LibreChat 的 Gemini Provider 在构造请求时如果对话历史为空即第一次提问会生成一个空的history数组但忘记给当前message添加role。源码在src/providers/generativeAI/generativeAI.ts第 120 行buildContent函数里漏了role: user。解决方法在.env中添加临时修复GEMINI_FORCE_ROLEtrue这个环境变量会触发一个补丁逻辑在构造contents时强制为每个 message 加role: user。官方已在 v1.13.0 修复但 v1.12.0 用户必须手动加。5.2 问题MCP 工具按钮显示正常点击后无反应Network 面板看不到任何/execute请求现象复现Figma Token 配置正确MCP_SERVER_URL可访问/tools返回正常但点击“创建画板”按钮控制台静默Network 无请求。根因分析LibreChat 的前端工具调用逻辑依赖window.MCP全局对象。这个对象由src/client/components/MCP/MCPProvider.tsx初始化它会检查MCP_SERVER_URL是否以https://开头。如果你的 MCP Server 地址是http://localhost:8000开发时常用它会跳过初始化导致window.MCP为undefined按钮点击事件根本不会触发。解决方法开发环境必须用 HTTPS。最简单方案是用mkcert生成本地证书brew install mkcert mkcert -install mkcert localhost # 生成 localhost.pem 和 localhost-key.pem # 启动 LibreChat 前端时加 --https --cert ./localhost.pem --key ./localhost-key.pem5.3 问题Agent 总是返回“我无法执行此操作”但从不尝试调用工具现象复现用户明确说“用天气 API 查北京天气”Agent 回复“抱歉我无法执行此操作”日志里没有tool_call相关记录。根因分析Agent 的触发阈值由 LLM 的tool_choice参数控制。LibreChat 默认设为auto但在某些模型如早期 Gemini 版本上auto会被忽略LLM 直接返回文本。必须强制设为required。解决方法在.env中为 Gemini 添加GEMINI_TOOL_CHOICErequired这会让 LibreChat 在请求体中加入tool_choice: required强制 LLM 输出 tool call。同理OpenAI 模型用OPENAI_TOOL_CHOICErequired。5.4 问题上传文件后LLM 说“我看不到文件内容”但文件明明已上传成功现象复现拖入 PDF前端显示“上传成功”但 LLM 回复“请提供文件内容”不解析。根因分析LibreChat 的文件解析依赖file-type库识别 MIME Type。某些 PDF 生成器如 wkhtmltopdf生成的 PDF头部 magic bytes 不标准file-type识别为application/octet-streamLibreChat 认为这是二进制文件不调用 PDF 解析器。解决方法在src/server/services/files/fileService.ts中找到detectMimeType函数添加一个 fallbackif (mimeType application/octet-stream) { // 检查文件扩展名 if (filename.toLowerCase().endsWith(.pdf)) { return application/pdf; } }然后重新构建镜像。5.5 问题Docker 启动后日志疯狂刷Error: connect ECONNREFUSED 127.0.0.1:6379但 Redis 地址配置正确现象复现docker-compose.yml里REDIS_URLredis://redis:6379redis服务也正常运行但 LibreChat 容器一直连不上。根因分析Docker 网络中127.0.0.1指向容器自身不是宿主机。LibreChat 的REDIS_URL如果写成redis://127.0.0.1:6379它会试图连接自己容器的 6379 端口当然失败。必须用服务名redis。解决方法检查.env中的REDIS_URL确保是redis://redis:6379而不是redis://127.0.0.1:6379或redis://localhost:6379。这是 Docker 新手最常犯的错误。5.6 问题OpenAI 接口返回429 Too Many Requests但 QPS 远低于官方限额现象复现单用户测试每秒发 1 个请求OpenAI 却返回 429。根因分析LibreChat 的 OpenAI Provider 默认开启stream: true这会让 OpenAI 的速率限制按“流式连接数”计算而不是“请求数”。一个流式请求会保持长连接数秒迅速耗尽连接配额。解决方法在.env中关闭流式OPENAI_STREAMINGfalse或者如果必须用流式增加OPENAI_MAX_CONCURRENT_STREAMS5限制并发流数量。5.7 问题升级到 v1.12.0 后所有历史会话丢失现象复现docker-compose down docker-compose up后前端会话列表为空。根因分析v1.12.0 引入了新的会话存储结构conversations表新增了model字段但旧数据没有这个字段MongoDB 查询时因 schema mismatch 返回空数组。解决方法执行 MongoDB 迁移脚本// 连接到 MongoDB运行 db.conversations.updateMany( { model: { $exists: false } }, { $set: { model: gpt-4o } } // 设为你的默认模型 )或者更稳妥的方式是备份旧数据清空conversations表再从备份中恢复时手动添加model字段。6. 进阶应用如何用 LibreChat 构建一个真实的 AI 工作台LibreChat 的终极价值不是替代 ChatGPT而是成为你个人或团队的 AI 工作台AI Workbench。我用它为一家电商公司搭建了一个“商品文案生成工作台”整合了 5 个能力Gemini 生成文案、本地 Llama 模型做合规审核、通达信股票数据插件MCP、Figma 插件生成 Banner、Burp Suite 插件做安全扫描MCP。整个工作台不是 5 个孤立工具而是一个有机整体。6.1 工作流编排让 Agent 理解“多步任务”用户输入“帮我为新品‘智能空气炸锅’生成小红书文案要求包含价格对比、突出健康卖点并生成一张带产品图的 Banner。”LibreChat 的 Agent 会自动拆解为调用gemini_generate_copy工具输入 prompt“写一篇小红书风格文案产品智能空气炸锅卖点比传统油炸少80%油脂价格¥299竞品美的¥399苏泊尔¥349”。调用llama_compliance_check工具将生成的文案传入本地 Llama 模型检查是否有夸大宣传如“绝对不致癌”、是否违反广告法。调用tongdaxin_stock_data工具通达信 MCP获取“美的集团”和“苏泊尔”最近 30 天股价生成价格对比图表数据。调用figma_create_banner工具用步骤 3 的数据和步骤 1 的文案生成 Banner。将所有结果汇总用 Gemini 生成最终回复“已为您生成文案、完成合规审核、获取竞品股价、制作 Banner详见附件。”这个工作流不需要写任何 orchestration 代码全靠 Agent 的 prompt engineering 和 MCP 的标准化。关键是每个工具的input_schema都定义了清晰的输入约束Agent 才能准确生成参数。6.2 持续预训练Continual Pretraining的接入点网络热词里的 “5. continual pretraining” 和 “scaling agents via continual pre-training” 指的是让 Agent 在真实用户反馈中持续进化。LibreChat 本身不提供训练能力但它提供了完美的数据管道。它的conversations表存储了完整的对话链user message, assistant response, tool calls, tool results且每个会话都有feedback字段用户点赞/点踩。你可以用这些数据微调你的专属 Llama 模型提升在电商文案领域的表现训练一个 Router 模型预测用户下一句该调用哪个工具比规则路由更准构建一个 Prompt Optimizer自动 A/B 测试不同 system prompt 对转化率的影响。LibreChat 的价值正在于此——它不教你如何训练模型但它确保你训练时用的数据是真实、结构化、带上下文的高质量数据。6.3 未来扩展RAG 与 MCP 的融合RAGRetrieval-Augmented Generation和 MCP 常被拿来对比但它们不是互斥的而是互补的。RAG 解决“我知道什么”MCP 解决“我能做什么”。在 LibreChat 里你可以这样融合用户问“我们最新版《用户隐私协议》里关于数据共享的部分是怎么规定的”Agent 先调用 rag