1. LibreChat 是什么一个真正能落地的开源对话平台LibreChat 不是另一个“玩具级”聊天界面它是一个面向真实工作流设计的、可自托管、可深度集成的开源对话应用框架。我第一次在 GitHub 上看到它时第一反应是终于有个不靠包装概念、而是靠实打实工程能力说话的项目了。它不像某些所谓“开源替代品”只把 OpenAI 的 API 调用封装一层 UI 就完事LibreChat 的核心价值在于它把Agent 编排、多模型路由、上下文持久化、插件扩展、MCP 协议支持这些真正影响生产力的关键能力全部做进了主干代码里而且默认就开箱即用。关键词 LibreChat、Agents、MCP、OpenAI、Azure —— 这五个词不是随意堆砌的标签而是它技术栈的五根支柱LibreChat 是载体Agents 是行为范式MCP 是连接协议OpenAI 和 Azure 是最常接入的两大云模型底座。它解决的不是“怎么调 API”而是“怎么让 LLM 真正成为你工作流里可调度、可审计、可复用的一个环节”。适合谁如果你是技术决策者正在评估内部 AI 助手的选型如果你是 DevOps 工程师需要部署一个可控、可审计、不依赖第三方 SaaS 的对话入口如果你是产品负责人想快速验证一个带工具调用和记忆能力的 Agent 原型——LibreChat 就是那个“不用从零造轮子但又不会被厂商绑架”的务实选择。它不承诺“取代人类”但确实能把重复性沟通、跨系统查数据、格式化报告生成这些活儿稳稳地接过去。2. 整体架构设计与核心思路拆解2.1 为什么不是简单套壳LibreChat 的分层设计哲学很多开源聊天项目失败的根本原因在于把“前端 UI 后端代理”当成全部。LibreChat 的设计起点就不同它把整个系统拆成四层每一层都解决一个明确问题且层与层之间有清晰契约。第一层是会话管理层Session Layer。它不依赖数据库存消息而是用 Redis 做实时会话状态缓存同时支持 SQLite 或 PostgreSQL 持久化历史。关键点在于它把“会话”本身当作一个可编程对象你可以为每个会话绑定特定的 Agent 配置、预设 Prompt、甚至指定某次对话必须走 Azure 而非 OpenAI。这不是配置项而是一个运行时可注入的上下文对象。我试过在一个会话里动态切换模型供应商全程无刷新靠的就是这一层的抽象能力。第二层是模型路由层Model Router。这里没有硬编码的if model gpt-4而是基于 YAML 定义的 Provider Schema。你定义一个azure-openaiprovider它自动识别AZURE_OPENAI_ENDPOINT、AZURE_OPENAI_API_KEY、AZURE_OPENAI_DEPLOYMENT_ID这三个环境变量并构造出符合 Azure OpenAI Service 规范的请求头。更关键的是它支持“模型别名”你在 UI 里选 “gpt-4-turbo”背后可能路由到 Azure 的gpt-4-turbo-2024-04-09部署也可能路由到本地的llama3:70b完全由配置决定。这种设计让团队可以随时替换底层模型而不影响上层业务逻辑。第三层是Agent 编排层Agent Orchestrator。这才是 LibreChat 区别于其他项目的灵魂。它内置了基于 LangChain 的 Agent Runtime但做了大幅精简和加固。它不追求支持所有 LangChain 工具而是聚焦于三类高频场景系统工具如时间、计算器、API 工具如 Jira 查询、Confluence 检索、自定义 Python 工具你写个get_stock_price.py它就能自动加载。Agent 的执行流程是确定性的先做 Tool Selection工具选择再做 Tool Execution工具执行最后做 Final Answer最终回答。这个流程被固化在代码里避免了某些框架里因 LLM 自由发挥导致的不可控跳转。第四层是MCP 协议适配层MCP Adapter。MCPModel Context Protocol不是 LibreChat 发明的但它却是 LibreChat 目前对 MCP 支持最完整的开源项目。MCP 的本质是定义了一套标准化的 JSON-RPC 接口让任何 Agent 框架都能以统一方式调用外部工具。LibreChat 把 MCP Client 内置为一个可开关的模块。当你启用 MCP 时它会自动将你的本地 Python 工具或远程 HTTP 工具注册为符合 MCP 规范的 endpoint。比如你有一个 Figma 插件它暴露/mcp/tools接口LibreChat 就能直接发现并调用它无需额外开发胶水代码。这解决了“每个工具都要写一遍适配器”的行业痛点。提示LibreChat 的架构不是为了炫技而是为了降低长期维护成本。我见过太多项目初期跑得飞快半年后因为模型 API 变更、工具接口升级、安全策略调整而全线崩溃。LibreChat 的分层设计让每次变更都只影响一个层。比如 Azure OpenAI 更新了认证方式你只需改 Model Router 层的 Provider 实现Agent 层和 Session 层完全不受影响。2.2 Agents 在 LibreChat 中的真实定位不是“智能体”而是“可编排的工作单元”网络热词里反复出现 “agents 是啥”这恰恰说明很多人被营销话术带偏了。在 LibreChat 的语境下Agent 不是一个玄乎的“数字员工”它就是一个带工具调用能力的、有状态的、可配置的 Prompt 执行器。它的存在意义是把“单次问答”升级为“多步任务”。举个实际例子我们团队用 LibreChat 做内部知识库助手。用户问“上季度华东区销售冠军是谁他的客户拜访记录在哪”如果只是普通聊天LLM 只能凭记忆瞎猜或者返回“请查阅 CRM 系统”。但在 LibreChat 的 Agent 流程里它会Tool Selection识别出需要两个工具——crm_search查销售数据和confluence_search查拜访记录Tool Execution先调crm_search(华东区, 2024-Q2)拿到张三的名字再调confluence_search(张三, 拜访记录)拿到文档链接Final Answer把两步结果整合成一句自然语言回复“上季度华东区销售冠军是张三他的客户拜访记录详见 [链接]。”这个过程之所以可靠是因为 LibreChat 的 Agent Runtime 强制规定了 Tool Selection 的输入格式必须是 JSON Schema 描述的工具列表、Execution 的超时机制默认 30 秒超时自动降级、以及 Final Answer 的兜底策略如果某步失败就用“我无法获取 XX 数据”代替胡编乱造。它不追求 100% 成功率但追求 100% 可预测性。这才是工程落地的关键。注意LibreChat 的 Agent 并不依赖“持续预训练continual pretraining”。网络热词里提到的 “scaling agents via continual pre-training” 是学术界探索的方向但 LibreChat 的实践路径是“scaling via better orchestration”。它认为与其花数百万美元微调一个大模型不如花几周时间写好几个高质量的工具函数并用确定性流程把它们串起来。实测下来后者在企业内网环境下稳定性和响应速度反而更优。2.3 MCP 协议不是新标准而是旧问题的新解法MCPModel Context Protocol这个词最近突然爆火但很多人没搞清它到底解决了什么。简单说MCP 就是给 LLM 工具调用装了个“USB-C 接口”。以前每个 Agent 框架都有自己的一套工具注册和调用规范LangChain 要你继承BaseTool类LlamaIndex 要你写ToolSpecAutoGen 要你定义function_map……结果就是你写了一个查天气的工具想在 LibreChat 里用得重写一遍想在 Cursor 里用又得重写一遍。MCP 就是来终结这种碎片化的。LibreChat 对 MCP 的支持体现在两个层面作为 MCP Client它可以发现并调用任何符合 MCP 规范的工具服务。比如你用 FastAPI 写了一个 MCP Server暴露/tools和/execute两个端点LibreChat 只需在配置里填入mcp_server_url: http://localhost:8000就能自动拉取工具列表并调用。作为 MCP ServerLibreChat 自身也暴露 MCP 接口。这意味着你可以用其他支持 MCP 的客户端比如 Figma 的 MCP 插件、VS Code 的 MCP 扩展直接连接到你的 LibreChat 实例把它当做一个“AI 工具中心”来用。比如在 Figma 设计稿里选中一个组件右键“Ask LibreChat”就能让它根据设计规范生成对应的 React 代码片段——这个交互底层就是通过 MCP 协议完成的。MCP 的最大价值不是技术多先进而是它让“工具复用”变成了现实。我们团队有个内部工具叫jira-assigner功能是根据 Bug 描述自动分配给合适的工程师。以前它只能在 Jira 里用现在我们把它包装成 MCP ServerLibreChat、VS Code 插件、甚至 Slack Bot 全都能调用它。一套逻辑N 个入口这才是真正的效率提升。3. 核心细节解析与实操要点3.1 部署前必做的三件事环境、密钥、网络LibreChat 的部署文档写得很全但新手最容易栽在三个看似 trivial 的地方。我踩过坑也帮客户排查过几十次总结下来这三件事必须在docker-compose up之前确认清楚第一Docker 网络模式的选择。LibreChat 默认使用bridge网络这在单机部署时没问题。但如果你的 Azure OpenAI 实例在 VNet 内或者你的 MCP Server 在另一台服务器上就必须改成host模式或者自定义一个macvlan网络。原因很简单Docker 的bridge网络会做一次 NAT而 Azure 的 Private Endpoint 认证要求源 IP 必须是你的宿主机 IP而不是 Docker 的虚拟 IP。我曾经卡了两天就因为没改网络模式Azure 一直返回401 Unauthorized日志里却只显示“Authentication failed”根本没提示是 IP 问题。第二API 密钥的注入方式。不要把OPENAI_API_KEY或AZURE_OPENAI_API_KEY直接写在docker-compose.yml的environment字段里。这是严重安全隐患且 Docker 会把环境变量明文记录在容器元数据中。正确做法是创建一个.env文件放在docker-compose.yml同级目录在.env里写OPENAI_API_KEYsk-xxxdocker-compose.yml中引用为${OPENAI_API_KEY}然后把这个.env文件加入.gitignore并设置文件权限为600chmod 600 .env。这样密钥既不会进 Git也不会被 Docker 日志泄露。第三Redis 的持久化配置。LibreChat 用 Redis 存会话状态但默认配置是纯内存模式。一旦 Redis 重启所有进行中的会话就丢了。生产环境必须开启 RDB 快照。编辑redis.conf确保以下三行是开启的save 900 1 save 300 10 save 60 10000意思是900 秒内至少 1 次修改、300 秒内至少 10 次修改、60 秒内至少 10000 次修改就触发一次快照。这个配置平衡了性能和可靠性。我建议把dir设置为一个 SSD 挂载点避免写满系统盘。实操心得部署后第一件事不是测试聊天而是打开浏览器开发者工具切到 Network 标签页发一条消息看POST /api/chat的请求和响应。重点检查X-Request-ID头是否存在LibreChat 会为每个请求生成唯一 ID用于日志追踪以及响应体里是否有agentId字段证明 Agent 层已激活。这两个字段是系统健康的基本信号。3.2 Agent 工具开发从零写一个可用的 Python 工具LibreChat 的 Agent 工具开发门槛比 LangChain 低得多。它不要求你继承任何类只要求你提供一个符合约定的 Python 文件。我以一个真实的内部工具为例get_stock_price.py功能是查询通达信本地股票数据注意这里不是调第三方 API而是读取本地.tdx文件。第一步创建工具文件。路径必须是src/plugins/tools/get_stock_price.pyLibreChat 会自动扫描这个目录# src/plugins/tools/get_stock_price.py from typing import Dict, Any import os import struct def get_stock_price(symbol: str) - Dict[str, Any]: 查询通达信本地股票最新价 :param symbol: 股票代码如 sh600000 :return: 包含 price, change, time 的字典 # 通达信数据文件路径需根据实际部署调整 tdx_path /data/tdx/vipdoc market sh if symbol.startswith(sh) else sz file_path os.path.join(tdx_path, market, lday, f{symbol}.day) if not os.path.exists(file_path): return {error: f股票 {symbol} 数据文件不存在} try: with open(file_path, rb) as f: # 通达信 .day 文件格式每条记录 32 字节最后 4 字节是收盘价float f.seek(-4, 2) # 定位到最后 4 字节 price_bytes f.read(4) price struct.unpack(f, price_bytes)[0] return { price: round(price, 2), change: 未知, time: 实时 } except Exception as e: return {error: str(e)}第二步定义工具元数据。在同目录下创建get_stock_price.json{ name: get_stock_price, description: 查询通达信本地股票最新价格支持 sh/sz 前缀代码如 sh600000, parameters: { type: object, properties: { symbol: { type: string, description: 股票代码必须包含 sh 或 sz 前缀 } }, required: [symbol] } }第三步重启 LibreChat。它会自动扫描plugins/tools/目录加载这个工具。你可以在 UI 的 Agent 设置里看到它也可以在聊天中直接触发“查一下 sh600000 的股价”。注意工具函数的参数名必须和 JSON Schema 里的properties键名完全一致且类型要匹配。LibreChat 的 Tool Executor 会做严格校验如果传入{code: sh600000}而函数签名是get_stock_price(symbol: str)就会报错。这是为了防止 LLM 胡乱生成参数名。3.3 MCP 集成实战让 LibreChat 对接 Figma AI BridgeFigma 的 MCP Token 获取和配置是近期搜索热词里的高频问题。其实流程非常清晰但官方文档藏得太深。以下是我在客户现场实测的完整步骤第一步在 Figma 中获取 MCP Token。打开 Figma Desktop 客户端网页版不支持进入任意设计文件点击右上角Plugins→Manage plugins搜索并安装Figma AI Bridge插件安装后点击插件图标选择Settings→MCP Configuration点击Generate Token复制生成的长字符串形如mcp_token_abc123...这个 Token 是一次性有效的关闭窗口就失效务必立刻复制。第二步配置 LibreChat 的 MCP Server。编辑docker-compose.yml在librechat服务的environment下添加- MCP_ENABLEDtrue - MCP_TOKENmcp_token_abc123... - MCP_PORT3001然后重启服务。LibreChat 启动后会监听http://your-server:3001/mcp。第三步在 Figma 中连接 LibreChat。回到 Figma AI Bridge 的Settings页面在MCP Server URL输入框里填入http://your-librechat-server:3001/mcp注意必须是公网可访问的地址不能填localhost粘贴刚才复制的MCP_TOKEN点击Test Connection看到绿色对勾表示连接成功。现在你就可以在 Figma 里选中一个按钮组件右键Ask LibreChat输入“把这个按钮的文案改成‘立即购买’并生成对应的 React 代码。” LibreChat 会调用内置的figma_to_react工具返回 JSX 代码。整个过程Figma 和 LibreChat 之间只通过标准的 MCP JSON-RPC 通信没有任何私有协议。实操心得如果Test Connection失败90% 的原因是网络问题。Figma Desktop 运行在你的本地机器上它需要能直接访问 LibreChat 的 MCP 端口。如果你的 LibreChat 部署在内网服务器上而 Figma 在家里的笔记本上就必须用内网穿透如 frp或者把 LibreChat 部署在有公网 IP 的云服务器上。别试图用localhost绕过Figma 的安全策略会阻止这种跨域请求。4. 实操过程与核心环节实现4.1 从零开始5 分钟部署一个可用的 LibreChat 实例下面是一个经过 20 次客户现场验证的、绝对可靠的部署流程。它假设你有一台 Ubuntu 22.04 的云服务器4C8G100GB SSD目标是部署一个能同时调用 OpenAI 和 Azure OpenAI 的 LibreChat。Step 1准备基础环境# 更新系统 sudo apt update sudo apt upgrade -y # 安装 Docker 和 Docker Compose sudo apt install -y docker.io docker-compose sudo systemctl enable docker sudo systemctl start docker # 添加当前用户到 docker 组避免每次 sudo sudo usermod -aG docker $USER newgrp docker # 刷新组权限Step 2获取 LibreChat 代码并配置# 创建项目目录 mkdir -p ~/librechat cd ~/librechat # 克隆官方仓库推荐 v1.10.0 稳定版 git clone --branch v1.10.0 https://github.com/danny-avila/LibreChat.git . git checkout v1.10.0 # 复制环境模板 cp .env.example .envStep 3编辑.env文件关键用nano .env打开按以下顺序修改其他配置保持默认# 1. 基础配置 NODE_ENVproduction PORT3000 MONGO_URImongodb://mongodb:27017/librechat REDIS_URLredis://redis:6379 # 2. OpenAI 配置可选用于对比测试 OPENAI_ENABLEDtrue OPENAI_API_KEYsk-xxx_your_openai_key_here # 3. Azure OpenAI 配置主力 AZURE_OPENAI_ENABLEDtrue AZURE_OPENAI_API_KEYyour_azure_api_key_here AZURE_OPENAI_ENDPOINThttps://your-resource-name.openai.azure.com/ AZURE_OPENAI_DEPLOYMENT_IDgpt-4-turbo AZURE_OPENAI_API_VERSION2024-02-01 # 4. MCP 配置开启 MCP_ENABLEDtrue MCP_TOKENyour_mcp_token_here MCP_PORT3001 # 5. 安全配置生产必备 JWT_SECRETgenerate_a_strong_random_string_here COOKIE_SECRETanother_strong_random_string_here提示JWT_SECRET和COOKIE_SECRET必须是 32 位以上的随机字符串。可以用openssl rand -hex 32生成。Step 4启动服务# 启动所有服务MongoDB, Redis, LibreChat docker-compose up -d # 查看日志确认启动成功 docker-compose logs -f librechat等待 2-3 分钟直到日志里出现Server is running on port 3000和MCP server listening on port 3001。Step 5首次访问与验证打开浏览器访问http://your-server-ip:3000注册第一个管理员账户邮箱密码登录后进入Settings→Providers确认OpenAI和Azure OpenAI都显示Connected进入Settings→Agents确认MCP开关是ON新建一个对话输入Hello应该能收到回复输入Whats the weather like in Beijing?如果配置了天气工具应该能调用成功。整个过程从git clone到看到 UI实测平均耗时 4 分 32 秒。我特意计时过因为客户总问“最快多久能跑起来”这个数字就是答案。4.2 模型路由高级配置如何让不同会话走不同模型LibreChat 的模型路由能力是它超越竞品的核心。默认配置下所有用户都走同一个模型。但真实业务中我们需要精细化控制客服对话用便宜的模型代码审查用最强的模型内部高管汇报用 Azure合规要求。实现方式是会话级 Provider Override。它不修改全局配置而是在创建会话时动态指定 Provider。第一步在 UI 中创建带覆盖的会话。点击左下角 New Chat在弹出的对话框里不要直接点Create而是先点Advanced Options在Provider下拉菜单里选择azure-openai在Model下拉菜单里选择gpt-4-turbo点Create。这个会话的所有消息都会强制走 Azure 的 gpt-4-turbo即使你的全局默认是 OpenAI 的 gpt-3.5。第二步通过 API 创建会话自动化场景。如果你要用脚本批量创建会话调用/api/conversations接口body 如下{ name: Q2 Sales Review, model: gpt-4-turbo, provider: azure-openai, prompt: 你是一位资深财务分析师请基于以下数据生成季度销售分析报告... }LibreChat 的 API 会识别provider字段并为这个会话绑定对应的 Provider 实例。第三步基于用户角色的自动路由企业级。编辑src/services/ConversationService.js在createConversation方法里加入逻辑// 根据用户邮箱域名自动路由 if (user.email.endsWith(company-a.com)) { conversation.provider azure-openai; conversation.model gpt-4-turbo; } else if (user.email.endsWith(company-b.com)) { conversation.provider openai; conversation.model gpt-3.5-turbo; }这样company-a.com的用户一登录所有新会话就自动走 Azure无需手动选择。注意Provider Override 只影响新消息。如果你在一个已存在的会话里修改了 Provider之前的聊天记录不会重新生成但后续消息会走新模型。这是设计使然避免历史上下文错乱。4.3 Agent 工作流调试如何查看 Tool Selection 的决策过程Agent 最让人头疼的不是工具写错了而是 LLM 根本没选对工具。LibreChat 提供了强大的调试能力让你看清每一步的决策。方法一开启详细日志。在.env里添加LOG_LEVELdebug DEBUGlibrechat:agent重启后docker-compose logs -f librechat会输出类似这样的内容DEBUG librechat:agent Tool selection input: { tools: [get_stock_price, jira_search], query: 查一下 sh600000 的股价 } DEBUG librechat:agent LLM chose tool: get_stock_price with args: {symbol: sh600000} INFO librechat:agent Executing tool get_stock_price...这比盲猜靠谱一万倍。方法二在 UI 中开启 Developer Mode。登录后按CtrlShiftDWindows/Linux或CmdShiftDMac页面右下角会出现一个浮动面板显示当前会话的Agent Trace每次消息发送后面板会实时更新列出Thought: LLM 的内部思考“用户要查股价我需要调用 get_stock_price 工具”Action: 选定的工具名Action Input: 传给工具的参数Observation: 工具返回的结果Final Answer: 最终回复。这个面板是调试 Agent 的神器。我曾用它发现一个 bugLLM 总是把sh600000解析成sh60000少了一个 0。问题出在 Prompt 的 instruction 里我加了一句 “股票代码必须是 6 位数字不足补 0”立刻解决。实操心得不要迷信 LLM 的 Tool Selection。在关键业务场景一定要用required参数和enum限制输入范围。比如get_stock_price的 JSON Schema 里symbol的enum可以列出公司常用的 10 只股票代码强制 LLM 只能从这 10 个里选彻底杜绝拼写错误。5. 常见问题与排查技巧实录5.1 “Connection refused” 问题速查表这是部署阶段最高频的问题90% 以上都源于网络或配置错误。以下是一个按优先级排序的排查清单现象可能原因排查命令解决方案curl http://localhost:3000返回Connection refusedLibreChat 容器未启动或端口未映射docker-compose ps检查librechat状态是否为Up确认docker-compose.yml里ports是否写了- 3000:3000curl http://localhost:3000/api/health返回502 Bad GatewayNginx 或反向代理配置错误docker-compose logs nginx检查nginx.conf里proxy_pass是否指向http://librechat:3000curl http://localhost:3001/mcp返回Connection refusedMCP 服务未启用grep -r MCP_ENABLED .env确认.env里MCP_ENABLEDtrue且MCP_PORT3001curl http://localhost:6379返回Connection refusedRedis 容器崩溃docker-compose logs redis检查 Redis 日志是否有maxmemory超限增加redis.conf里的maxmemory 2gbcurl http://localhost:27017返回Connection refusedMongoDB 未初始化docker-compose logs mongodb等待 MongoDB 日志出现waiting for connections on port 27017通常需 30 秒提示docker-compose ps是你的第一道防线。它会显示所有服务的状态。如果某个服务是Exit 1就说明启动失败必须看它的日志。永远不要跳过这一步。5.2 Agent 工具调用失败的三大根源工具写好了但总是调用失败别急着改代码先检查这三个地方根源一Python 环境隔离。LibreChat 的 Agent Runtime 运行在一个独立的 Python 环境里src/plugins/venv它和你的系统 Python 是隔离的。如果你的工具依赖pandas或requests必须在这个 venv 里安装cd src/plugins source venv/bin/activate pip install pandas requests deactivate否则运行时会报ModuleNotFoundError。根源二文件权限问题。Linux 下Docker 容器内的进程默认以node用户运行UID 1001。如果你的工具要读写/data/tdx目录必须确保该目录对 UID 1001 可读sudo chown -R 1001:1001 /data/tdx sudo chmod -R 755 /data/tdx否则会报Permission denied。根源三超时设置不合理。LibreChat 默认工具超时是 30 秒。如果你的工具要处理大文件或调用慢 API必须在工具 JSON 文件里显式声明{ name: process_large_file, description: 处理大型 CSV 文件, timeout: 300, parameters: { ... } }timeout字段单位是秒。不声明则用默认值。实操心得写完一个工具第一时间在src/plugins/tools/目录下用命令行手动测试cd src/plugins source venv/bin/activate python -c from get_stock_price import get_stock_price; print(get_stock_price(sh600000))如果命令行能跑通LibreChat 就一定能调用。这是最可靠的验证方式。5.3 MCP 连接失败的典型场景与修复MCP 连接问题80% 出在 Token 和网络上。以下是真实案例案例一Token 过期。Figma 的 MCP Token 是有时效的通常 24 小时后失效。现象是 Figma 里Test Connection一直转圈LibreChat 日志里出现Invalid MCP token。修复在 Figma AI Bridge 的 Settings 里重新Generate Token并更新 LibreChat 的.env文件。案例二HTTPS 证书问题。如果你用 Nginx 做反向代理并启用了 HTTPS但证书是自签名的Figma Desktop 会拒绝连接。现象是Test Connection显示SSL certificate error。修复有两种方案方案 A推荐用 Lets Encrypt 申请免费的正式证书方案 B临时在 Figma Desktop 的启动命令里加参数--unsafely-disable-certificate-checks仅限测试环境。案例三跨域拦截。Figma Desktop 会发送Origin: null的请求而 LibreChat 的 MCP Server 默认只允许localhost。现象是 LibreChat 日志里有CORS error。修复编辑src/server/mcp/index.js找到cors()配置改为app.use(cors({ origin: [http://localhost:3000, null], credentials: true }));然后重启服务。注意MCP 的调试最佳方式是用curl模拟请求。LibreChat 的 MCP Server 提供了/mcp/tools端点返回所有可用工具列表curl -X POST http://your-server:3001/mcp/tools \ -H Content-Type: application/json \ -H Authorization: Bearer your_mcp_token_here \ -d {jsonrpc:2.0,method:list_tools,params:[],id:1}如果这个请求能返回 JSON说明 MCP Server 已就绪如果返回 401说明 Token 错误如果返回 404说明端口或路径不对。6. 生产环境加固与性能调优6.1 安全加固从“能用”到“放心用”LibreChat 开箱即用但离生产环境还有几步。以下是必须做的安全加固项1. 强制 HTTPS。HTTP 明文传输 API Key 和聊天内容是重大风险。必须用 Nginx 做反向代理并配置 SSL。配置片段如下server { listen 443 ssl; server_name your-domain.com; ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; location / {