商业网站接入聊天机器人时最常见的难点往往不是模型本身而是集成链路聊天窗口怎么嵌入业务页面、消息怎么从浏览器到服务端、服务端怎么返回回复、会话怎么定位到用户、部署在谁的环境里。Bolnee-Chat 这类自托管聊天机器人方案核心价值就是把这一整条链路放到自己的服务器上由自己控制代码、控制数据、控制部署位置而不是把客户对话和用户数据全部交给外部 SaaS。本文会从自托管聊天机器人的概念讲起然后带你走通一个最小可运行方案Node.js 服务端、前端嵌入脚本、业务页面接入、Docker 部署、验证和排错。学完之后你可以把这条链路迁移到自己的技术栈也可以继续扩展出大模型回复、人工接管、知识库和工单联动。1. 先理解自托管聊天机器人解决了什么问题1.1 自托管与 SaaS 聊天机器人服务的核心差异过去给官网加一个聊天机器人最常见的选择是第三方在线客服产品在页面上贴一段脚本然后到服务商后台配置机器人话术。这种方式上线快但存在几个现实问题。首先是数据归属。客户在聊天窗口里输入的每一条消息都会经过服务商的服务器。对于需要遵守个人信息保护要求、客户数据敏感的企业来说这个环节很难完全回避合规风险。其次是定制深度。第三方平台通常只能配置固定的开场白、多轮问答树、转人工条件一旦业务方想改消息路由逻辑、把聊天记录同步到自己的 CRM、或者对接内部大模型服务就会受平台功能限制。再次是长期成本。聊天机器人按消息量或坐席数计费当访问量增长后费用会以非线性方式上升。自托管聊天机器人则是把整套聊天服务打包成自己的后端模块前端通过一段可嵌入的脚本接入所有消息先到自己的服务端再由服务端决定回复方式。用一张表格可以更清楚看到差异对比维度SaaS 在线客服/聊天机器人自托管聊天机器人数据存储位置服务商机房自己的服务器或云账号可定制程度受平台功能限制代码完全可控部署成本按坐席或消息量付费服务器、带宽和运维成本数据合规依赖服务商协议自己控制存储和权限接入复杂度脚本粘贴即可需要搭建和运维故障恢复依赖服务商在线状态自己负责监控与恢复并不是说自托管一定更好。如果团队没有运维能力、业务周期很短SaaS 的成本和效率优势仍然明显。但如果客户数据敏感、需要深度定制、或者已经具备私有化部署条件自托管方案的价值会更大。1.2 Bolnee-Chat 这类方案在集成链路中的位置自托管聊天机器人不是单一功能而是一段完整的消息链路。前端页面通过嵌入脚本渲染聊天按钮和消息面板用户发送消息后脚本通过 WebSocket 或 HTTP 把消息送到自己的服务端服务端调用规则引擎、大模型接口或人工客服后台生成回复回复再沿链路返回页面同时写入会话存储。这段链路里Bolnee-Chat 作为自托管聊天机器人集成项目负责的是中间层消息接入、会话管理、回复分发、部署配置。它与底层底座模型解耦也就是说它本身不一定是大模型它可以是一个消息中台。这也是它适合嵌入商业网站的原因商业网站往往已经有客服系统、API 网关、用户中心聊天机器人不应该是一个孤岛而应该能接入这些已有组件。1.3 哪些项目适合自托管方案从实际选型角度以下几类场景更适合自托管聊天机器人第一客户数据敏感的业务。比如金融、医疗、教育、企业服务类网站客户在聊天窗口可能输入账号、合同号、健康信息等敏感内容自托管可以控制数据留存范围和访问权限。第二需要深度定制交互的业务。例如希望聊天窗口与页面内嵌表单联动、根据用户当前浏览商品自动发起引导、把聊天记录写入内部工单系统这些都需要改代码自托管更方便。第三已经使用私有云或本地化部署的企业。如果整个业务系统都不允许外部流量进入数据链路那么聊天服务也必须放在同一个内网环境SaaS 产品很难满足。反过来说如果只是想快速验证用户是否需要一个在线咨询入口不建议第一时间就上自托管。可以先用一个最小脚本模拟人工客服或固定问答验证需求后再切换为自托管方案。2. 环境准备先把最小服务端跑起来2.1 运行环境要求本文示例使用 Node.js 实现服务端。虽然 Bolnee-Chat 的实际实现不一定只有 Node.js 一种选择但用 Node.js 作为示例的好处是它对 WebSocket 支持天然、生态成熟、前端和后端可以共用 JavaScript 语法容易理解完整链路。学习环境建议如下组件学习环境建议生产环境建议Node.js18 或 20 LTS18 或 20 LTS包管理器npm使用npm ci锁定依赖容器Docker 24 以上与 CI/CD 保持一致会话存储内存或 SQLitePostgreSQL 或 Redis反向代理不需要Nginx 或 Caddy前置知识方面建议先了解 JavaScript 基础函数、异步回调、HTTP 请求和 WebSocket 的基本概念。如果这些还不太熟悉可以先跟着本文化整为零地跑通再在扩展阶段补齐知识。2.2 初始化项目并安装依赖先创建项目目录并初始化package.jsonmkdir bolnee-chat cd bolnee-chat npm init -y npm install express socket.io dotenv这里安装三个依赖express提供 HTTP 接口和静态文件服务。socket.io实现浏览器与服务端之间的 WebSocket 通信用于实时消息推送。dotenv从.env文件读取环境变量避免把密钥和端口直接写死在代码里。如果你的网络环境安装速度较慢可以只安装必选包并留意安装完成后出现的版本信息。不同大版本之间的 API 可能有差异落地前先确认实际安装的版本。2.3 编写一个最小服务端创建一个server.js先实现健康检查接口和一个简单的聊天回显接口。require(dotenv).config(); const express require(express); const http require(http); const { Server } require(socket.io); const crypto require(crypto); const app express(); const server http.createServer(app); const io new Server(server, { cors: { origin: process.env.ALLOWED_ORIGIN || http://localhost:8080, methods: [GET, POST] } }); app.use(express.json()); // 简单会话存储。生产环境请替换为数据库或 Redis。 const sessions new Map(); // 健康检查接口用于部署后确认服务在线。 app.get(/health, (req, res) { res.json({ status: ok, timestamp: new Date().toISOString() }); }); // 创建会话或追加消息的 HTTP 接口。 app.post(/api/chat, (req, res) { const { sessionId, message, user } req.body; if (!sessionId || !message) { return res.status(400).json({ error: sessionId and message are required }); } const reply 服务端已收到${message}; sessions.set(sessionId, { user: user || { name: anonymous }, lastMessage: message, reply, updatedAt: new Date().toISOString() }); res.json({ sessionId, reply }); }); // 查看指定会话的当前状态用于排错。 app.get(/api/session/:sessionId, (req, res) { const session sessions.get(req.params.sessionId); if (!session) { return res.status(404).json({ error: session not found }); } res.json(session); }); // WebSocket 连接处理。 io.on(connection, (socket) { socket.on(client:message, (payload) { const { sessionId, content } payload; if (!sessionId || !content) return; const reply 服务端收到${content}; sessions.set(sessionId, { lastMessage: content, reply, updatedAt: new Date().toISOString() }); socket.emit(server:reply, { sessionId, content: reply, timestamp: new Date().toISOString() }); }); }); const PORT process.env.PORT || 3000; server.listen(PORT, () { console.log(Bolnee-Chat server listening on port ${PORT}); });这段代码有几个关键点第一sessions使用内存 Map 保存只是为了演示会话逻辑。服务重启后数据会丢失生产环境必须换成 PostgreSQL、MySQL 或 Redis。第二io.on(connection)中的client:message和server:reply是自定义事件名。前端脚本必须使用相同的事件名才能连通。第三/api/chat使用 HTTP 接口处理一次性的会话创建WebSocket 用于实时双向通信。两者可以共存分工不同。2.4 启动并验证最小服务端启动服务node server.js看到Bolnee-Chat server listening on port 3000后在另一个终端验证接口curl http://localhost:3000/health预期返回{status:ok,timestamp:2025-01-01T08:00:00.000Z}再测试消息接口curl -X POST http://localhost:3000/api/chat \ -H Content-Type: application/json \ -d {sessionId:test001,message:你好,user:{name:张三}}预期返回一个包含sessionId和reply的 JSON说明服务端到这一步已经可用。注意这里的回复只是回显实际项目中会替换为业务机器人逻辑。3. 把聊天机器人接入业务网站3.1 前端嵌入组件的设计思路聊天机器人集成到业务页面通常不要求业务方改造整个前端框架而是提供一个可复用的嵌入脚本。业务页面只需要加一行script传入服务端地址和业务参数脚本会自动完成以下工作生成聊天按钮和消息面板的 DOM。动态加载socket.io客户端。创建会话 ID 并建立 WebSocket 连接。将输入框消息发送到服务端并把回复渲染到面板。设计嵌入脚本时要注意几个原则一是避免污染业务页面样式。脚本生成的所有元素都放在一个独立根节点内使用内联 style 或带前缀的 CSS 类名。二是配置参数通过>(function () { var script document.currentScript; var apiBase script.getAttribute(data-api-base) || http://localhost:3000; var sessionId wc_ Date.now() _ Math.random().toString(16).slice(2); var socket null; function loadScript(src, callback) { var s document.createElement(script); s.src src; s.onload callback; document.head.appendChild(s); } function createUI() { var root document.createElement(div); root.id bolnee-chat-root; root.style.cssText position:fixed;bottom:20px;right:20px;z-index:99999;; root.innerHTML div idbolnee-chat-panel styledisplay:none;width:320px;height:420px; border:1px solid #ddd;border-radius:8px;box-shadow:0 4px 12px rgba(0,0,0,0.15); background:#fff;overflow:hidden; div idbolnee-chat-messages styleheight:340px;padding:12px;overflow-y:auto;font-size:14px;/div div styleborder-top:1px solid #eee;padding:8px;display:flex; input idbolnee-chat-input styleflex:1;border:0;outline:none;padding:8px; placeholder请输入消息 / button idbolnee-chat-send styleborder:0;background:#1677ff;color:#fff;padding:8px 12px;border-radius:4px;发送/button /div /div button idbolnee-chat-toggle styleborder:0;background:#1677ff;color:#fff;padding:10px 14px;border-radius:20px;cursor:pointer;在线咨询/button; document.body.appendChild(root); var toggle document.getElementById(bolnee-chat-toggle); var panel document.getElementById(bolnee-chat-panel); var messages document.getElementById(bolnee-chat-messages); var input document.getElementById(bolnee-chat-input); var sendBtn document.getElementById(bolnee-chat-send); function appendMessage(text, from) { var div document.createElement(div); div.style.cssText margin:6px 0;text-align: (from user ? right : left); div.textContent text; messages.appendChild(div); messages.scrollTop messages.scrollHeight; } toggle.addEventListener(click, function () { panel.style.display panel.style.display none ? block : none; }); sendBtn.addEventListener(click, function () { var value input.value.trim(); if (!value || !socket) return; appendMessage(value, user); input.value ; socket.emit(client:message, { sessionId: sessionId, content: value }); }); return { appendMessage: appendMessage }; } function init() { var ui createUI(); loadScript(apiBase /socket.io/socket.io.js, function () { socket io(apiBase); socket.on(server:reply, function (data) { ui.appendMessage(data.content, bot); }); socket.on(disconnect, function () { ui.appendMessage(连接已断开请刷新页面重试。, bot); }); window.bolneeChat { sessionId: sessionId, send: function (message) { socket.emit(client:message, { sessionId: sessionId, content: message }); } }; }); } if (document.readyState loading) { document.addEventListener(DOMContentLoaded, init); } else { init(); } })();这段脚本的核心逻辑是document.currentScript获取当前脚本标签从而读取>!DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1.0 / title示例商城页面/title /head body h1示例商城/h1 p这是业务方自己的页面内容。/p script srchttp://localhost:3000/widget.js >npx serve .然后访问页面页面右下角会出现“在线咨询”按钮。点击按钮打开面板输入一条消息并发送应该看到服务端回复回显到消息区域。注意这里使用http://localhost:3000作为示例地址。生产环境页面如果用 HTTPS 访问聊天服务地址也必须使用 HTTPS否则浏览器会阻止混合内容。3.4 把会话关联到登录用户匿名会话只能标识一次页面访问无法把聊天记录关联到具体客户。实际业务中通常需要把登录用户的 ID 和昵称传给服务端。可以在 widget 初始化后通过暴露的window.bolneeChat对象与页面通信// 页面拿到登录用户信息后自行调用 window.bolneeChat.bindUser({ id: u001, name: 张三, email: zhangsanexample.com });widget 内部需要实现bindUser。在 init 的返回对象中增加方法并保存用户信息window.bolneeChat { sessionId: sessionId, user: null, bindUser: function (user) { this.user user; }, send: function (message) { socket.emit(client:message, { sessionId: sessionId, user: this.user, content: message }); } };服务端收到消息时从payload.user中读取用户信息并写入会话存储。这样客服后台就能根据用户 ID 汇总一位客户在不同时间、不同设备上的聊天记录。4. 关键配置与参数说明4.1 服务端环境变量创建.env.example文件作为团队内的配置模板# 服务监听端口 PORT3000 # 允许承载聊天窗口的业务页面域名 ALLOWED_ORIGINhttps://www.example.com # 会话令牌签名密钥生产环境务必替换 AUTH_SECRETplease-change-me # 会话持久化地址 DATABASE_URLsqlite:///data/chat.db常见的服务端参数说明如下配置项含义默认值错误设置的表现PORT服务监听端口3000端口冲突或访问地址不正确ALLOWED_ORIGIN允许加载聊天窗口的页面来源http://localhost:8080页面 WebSocket 连不上报 CORS 错误AUTH_SECRET用于签名会话令牌的密钥空会话信息可被伪造DATABASE_URL会话与消息持久化地址内存存储使用数据库时未配置服务重启后数据丢失LOG_LEVEL日志输出级别info排错时没有足够日志参数调大或调小的实际影响需要结合场景理解。例如ALLOWED_ORIGIN设为空或*会让任意第三方网站都能嵌入聊天窗口并消耗后端资源因此生产环境必须收敛为业务域名白名单。PORT是基础设施参数调整后要同步更新反向代理和防火墙规则。4.2 前端嵌入脚本参数前端脚本通过>FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --omitdev COPY . . ENV PORT3000 EXPOSE 3000 CMD [node, server.js]node:18-alpine适合作为 Node.js 服务的基础镜像体积小、启动快。npm ci --omitdev只安装生产依赖保证版本可复现。再创建docker-compose.yml便于本地和服务器启动version: 3.8 services: bolnee-chat: build: . container_name: bolnee-chat ports: - 3000:3000 environment: - PORT3000 - ALLOWED_ORIGINhttps://www.example.com - AUTH_SECRET${AUTH_SECRET} - DATABASE_URLsqlite:///app/data/chat.db - LOG_LEVELinfo volumes: - ./data:/app/data restart: unless-stopped启动命令docker compose up -d --build镜像更新时会重建容器宿主机上的./data目录通过 volume 挂载到容器内SQLite 数据库文件不会因为容器重建而丢失。4.4 安全相关配置聊天服务暴露在公网安全配置不能省略。首先CORS 必须配置业务域名白名单。Socket.IO的 CORS 配置在new Server(server, { cors: { origin: ... } })中指定。白名单之外的域名无法建立 WebSocket 连接。其次如果服务端后续会处理用户身份需要给会话令牌加上签名校验。签名密钥通过AUTH_SECRET注入不要在代码仓库和镜像中明文保存。生产环境建议使用平台的密钥管理服务或环境变量注入。再次对外提供消息接口时要做基础限流避免被脚本刷量。下面是在 Express 中加入简单限流的示例const rateLimit require(express-rate-limit); const chatLimiter rateLimit({ windowMs: 60 * 1000, max: 30, message: { error: 请求过于频繁请稍后再试 } }); app.post(/api/chat, chatLimiter, (req, res) { ... });这个示例限定了同一个 IP 在一分钟内最多调用 30 次消息接口。实际阈值要结合业务量调整过小会误伤真实用户过大会失去防护意义。5. 运行验证与结果检查5.1 用浏览器验证完整链路启动服务端和静态页面后按以下顺序验证打开业务页面确认右下角出现“在线咨询”按钮。点击按钮确认聊天面板正常打开无样式错乱。在输入框输入“你好”发送。消息面板先出现用户消息随后出现服务端回复。刷新页面重新打开聊天窗口确认仍能正常使用。常见的一个错误是只验证第一次发送成功没有刷新或换浏览器验证。自托管服务的状态往往与浏览器保持的长连接有关刷新后需要确认 socket 能重新建立连接。5.2 用命令行验证后端接口后端接口验证可以在浏览器之外独立完成curl -X POST http://localhost:3000/api/chat \ -H Content-Type: application/json \ -d {sessionId:test001,message:你好,user:{name:张三}}预期响应{sessionId:test001,reply:服务端已收到你好}再查会话状态curl http://localhost:3000/api/session/test001预期响应中包含lastMessage和reply字段。这个接口主要用于排错生产环境需要注意对会话查询接口做权限控制避免任意用户读取其他会话。5.3 查看服务端日志启动服务端的终端会输出启动信息。当浏览器发送消息时如果服务端代码没有打印日志可以临时在 socket 回调中加入日志socket.on(client:message, (payload) { console.log(received message:, JSON.stringify(payload)); ... });生产环境不要把完整的用户消息直接打印到 stdout避免敏感数据泄露。建议使用结构化日志记录消息长度、会话 ID、处理耗时等元信息必要时把消息内容写入带权限控制的日志系统。6. 常见问题排查6.1 五类高频问题自托管聊天机器人上线后遇到最多的问题集中在接入配置、跨域、协议、连接和资源占用五个方面。问题现象常见原因检查方式处理建议页面加载后没有聊天按钮script 路径错误、页面存在 JS 错误打开浏览器开发者工具查看 Console 和 Network确认 widget.js 能加载修复页面 JS 错误按钮出现但消息发不出去WebSocket 没有建立连接查看 Network 面板中的 WS 请求检查 ALLOWED_ORIGIN 和 api-base 地址生产页面是 HTTPS聊天服务是 HTTP浏览器阻止混合内容Console 提示 Mixed Content统一使用 HTTPS刷新后会话丢失会话只存在内存 Map 中调用 /api/session/:id 查询接入 Redis 或数据库持久化多个用户并发时偶发离线会话存储跨实例不同步查看多实例负载是否开启 sticky session使用共享 Redis 和 Socket.IO adapter6.2 排查链路按顺序检查当聊天功能异常时建议按下面的顺序排查避免跳到深水区。检查页面 Console。如果 widget.js 没有执行问题先在浏览器侧。检查 Network 面板。确认widget.js是否加载成功、socket.io.js是否加载成功。检查 WS 连接。确认 WebSocket 是否进入pending或直接失败。检查服务端日志。确认client:message是否被收到。检查回复链路。确认server:reply是否发出、前端是否监听同名事件。检查会话持久化。确认刷新后能否从数据库恢复会话。在 WebSocket 场景下事件名不一致是最隐蔽的错误。前端发送client:message后端必须监听同一事件名后端发送server:reply前端也必须监听同一事件名。排错时优先核对这两个事件名。6.3 日志关键字服务端日志出现以下关键字时对应问题如下日志关键字含义下一步received message后端收到前端消息检查回复是否发出CORS跨域策略拒绝检查 ALLOWED_ORIGINECONNREFUSED下游依赖连接失败检查数据库、Redis、模型服务EADDRINUSE端口被占用检查端口占用并调整GET /health 200健康检查正常整体链路基本正常7. 生产环境部署最佳实践7.1 学习环境与生产环境的差异本地跑通与生产发布之间隔着一系列不可省略的工程步骤。学习环境只需要代码能跑、页面能用生产环境要考虑连接安全、数据可靠、扩展和运维。项目学习环境生产环境页面协议HTTPHTTPS会话存储内存 MapRedis 或 PostgreSQL密钥明文或随机密钥管理服务注入日志console.log结构化日志系统部署npm startDocker 编排平台监控手动查看探活、指标、告警多实例单实例多实例 共享存储7.2 安全加固清单自托管聊天机器人直接暴露在公网上线前至少完成以下加固使用 HTTPS并在反向代理层统一终止 TLS。将ALLOWED_ORIGIN配置为业务域名白名单禁止使用*。通过环境变量注入AUTH_SECRET不要写入镜像和仓库。对/api/chat和 WebSocket 连接做限流。对用户输入做长度限制避免超大消息压垮服务。对回复内容做基础过滤和脱敏避免在页面上渲染危险内容。生产环境禁止开放未授权访问的会话查询接口。7.3 日志与监控至少记录以下指标WebSocket 连接数。消息发送频率。消息处理耗时。回复失败次数。会话持久化失败次数。健康检查探活结果。如果使用 Docker 部署可以为容器增加健康检查healthcheck: test: [CMD, node, -e, fetch(http://localhost:3000/health).then(r { if (!r.ok) process.exit(1) }).catch(() process.exit(1))] interval: 30s timeout: 5s retries: 3健康检查地址要落在服务内网不要通过公网地址检查。否则公网网络波动会导致误报 or 公网被攻击时掩盖真实问题。7.4 发布前检查清单把下面这份清单交给上线负责人可以减少大部分上线事故[ ] 页面与聊天服务均使用 HTTPS。[ ]ALLOWED_ORIGIN已填写正式业务域名。[ ]AUTH_SECRET已更改为随机强密钥。[ ] 会话存储已切换为 Redis 或数据库。[ ] 服务端日志已接入统一日志平台。[ ] 反向代理已配置 WebSocket 升级支持。[ ] 端口和防火墙规则已放行。[ ] 健康检查探活在监控平台正常展示。[ ] 多实例部署时已确认 Socket.IO shared adapter 或 sticky session。7.5 本地调试与生产调试的差异本地调试时可以直接看终端日志、修改代码热重启。生产环境通常没有终端权限更多要依赖日志和监控。建议从一开始就使用结构化日志至少包含time、level、event、sessionId字段。这样在搜索日志平台时可以通过sessionId精确串联一次完整对话。8. 扩展方向8.1 对接大模型并接入知识库当前示例的回复只是回显生产环境中通常需要把用户消息发给大模型服务。可以优先选择兼容 OpenAI 协议的推理服务因为这样可以保留下游切换空间先开发一个统一的回复接口由内部网关决定调用哪个模型。公开的大模型评估平台例如 LMArena可以作为初步筛选底座模型的参考但最终选型必须基于自己的业务测试集。要把行业术语、客服话术、隐私边界整理成评测集而不是直接拿公共榜单的结果做最终决定。知识库接入后聊天机器人优先在知识库中检索答案检索不到时再判断是否需要大模型生成或转人工。这一步会让自托管聊天机器人的价值更明显知识库数据、检索逻辑、脱敏规则都掌握在自己手里。8.2 人工接管自动回复不能覆盖所有场景。常见策略是设置一个转人工阈值用户连续问两次“转人工”、或者在回复中点击“转人工”按钮系统就把会话状态标记为人工。人工接管的技术实现需要一个坐席端页面坐席通过 WebSocket 监听分配给自己的会话。会话分配规则、坐席离线处理、排队提示都需要单独设计。建议在扩展这一功能之前先把会话状态机定义清楚新建、机器人接待、转人工中、人工接待、已结束、已归档。8.3 与企业系统集成聊天记录和线索不能停留在聊天服务内部。最常见的集成方式是利用 Webhook 把新消息、新会话、转人工事件推送给外部系统外部系统再决定后续动作。例如把聊天产生的用户意向写入 CRM、把售后请求自动创建为工单、把高价值客户消息同步给企业微信群机器人。如果企业已经使用 SAP Integration Suite 这类集成平台可以让聊天服务只负责暴露标准 REST 或 Webhook 接口再由集成平台统一编排到 ERP、CRM、工单等系统。这样聊天服务本身保持简单复杂的业务流程交给专业集成平台处理。8.4 下一步学习路径做完本文的最小示例后建议按以下顺序深化第一把内存 Map 替换为 Redis 或 PostgreSQL理解会话恢复和数据持久化的意义。第二为服务端补充单元测试和接口测试至少覆盖健康检查、消息接口和 WebSocket 事件。第三设计一个简单的多轮对话状态机让机器人能根据上下文记忆上一轮问题。第四加入限流、鉴权和日志中间件把服务从“能跑”提升到“能上线”。第五尝试接入一个大模型服务并用知识库做检索增强生成比较不同提示词策略的效果。自托管聊天机器人的学习价值不在于它比 SaaS 产品更省钱而在于它逼你理解消息链路中的每一个环节。你能解释问题出现在哪一层并且能修改它、监控它、优化它这是商业网站接入聊天功能时最核心的能力。
商业网站接入聊天机器人时最常见的难点往往不是模型本身而是集成链路聊天窗口怎么嵌入业务页面、消息怎么从浏览器到服务端、服务端怎么返回回复、会话怎么定位到用户、部署在谁的环境里。Bolnee-Chat 这类自托管聊天机器人方案核心价值就是把这一整条链路放到自己的服务器上由自己控制代码、控制数据、控制部署位置而不是把客户对话和用户数据全部交给外部 SaaS。本文会从自托管聊天机器人的概念讲起然后带你走通一个最小可运行方案Node.js 服务端、前端嵌入脚本、业务页面接入、Docker 部署、验证和排错。学完之后你可以把这条链路迁移到自己的技术栈也可以继续扩展出大模型回复、人工接管、知识库和工单联动。1. 先理解自托管聊天机器人解决了什么问题1.1 自托管与 SaaS 聊天机器人服务的核心差异过去给官网加一个聊天机器人最常见的选择是第三方在线客服产品在页面上贴一段脚本然后到服务商后台配置机器人话术。这种方式上线快但存在几个现实问题。首先是数据归属。客户在聊天窗口里输入的每一条消息都会经过服务商的服务器。对于需要遵守个人信息保护要求、客户数据敏感的企业来说这个环节很难完全回避合规风险。其次是定制深度。第三方平台通常只能配置固定的开场白、多轮问答树、转人工条件一旦业务方想改消息路由逻辑、把聊天记录同步到自己的 CRM、或者对接内部大模型服务就会受平台功能限制。再次是长期成本。聊天机器人按消息量或坐席数计费当访问量增长后费用会以非线性方式上升。自托管聊天机器人则是把整套聊天服务打包成自己的后端模块前端通过一段可嵌入的脚本接入所有消息先到自己的服务端再由服务端决定回复方式。用一张表格可以更清楚看到差异对比维度SaaS 在线客服/聊天机器人自托管聊天机器人数据存储位置服务商机房自己的服务器或云账号可定制程度受平台功能限制代码完全可控部署成本按坐席或消息量付费服务器、带宽和运维成本数据合规依赖服务商协议自己控制存储和权限接入复杂度脚本粘贴即可需要搭建和运维故障恢复依赖服务商在线状态自己负责监控与恢复并不是说自托管一定更好。如果团队没有运维能力、业务周期很短SaaS 的成本和效率优势仍然明显。但如果客户数据敏感、需要深度定制、或者已经具备私有化部署条件自托管方案的价值会更大。1.2 Bolnee-Chat 这类方案在集成链路中的位置自托管聊天机器人不是单一功能而是一段完整的消息链路。前端页面通过嵌入脚本渲染聊天按钮和消息面板用户发送消息后脚本通过 WebSocket 或 HTTP 把消息送到自己的服务端服务端调用规则引擎、大模型接口或人工客服后台生成回复回复再沿链路返回页面同时写入会话存储。这段链路里Bolnee-Chat 作为自托管聊天机器人集成项目负责的是中间层消息接入、会话管理、回复分发、部署配置。它与底层底座模型解耦也就是说它本身不一定是大模型它可以是一个消息中台。这也是它适合嵌入商业网站的原因商业网站往往已经有客服系统、API 网关、用户中心聊天机器人不应该是一个孤岛而应该能接入这些已有组件。1.3 哪些项目适合自托管方案从实际选型角度以下几类场景更适合自托管聊天机器人第一客户数据敏感的业务。比如金融、医疗、教育、企业服务类网站客户在聊天窗口可能输入账号、合同号、健康信息等敏感内容自托管可以控制数据留存范围和访问权限。第二需要深度定制交互的业务。例如希望聊天窗口与页面内嵌表单联动、根据用户当前浏览商品自动发起引导、把聊天记录写入内部工单系统这些都需要改代码自托管更方便。第三已经使用私有云或本地化部署的企业。如果整个业务系统都不允许外部流量进入数据链路那么聊天服务也必须放在同一个内网环境SaaS 产品很难满足。反过来说如果只是想快速验证用户是否需要一个在线咨询入口不建议第一时间就上自托管。可以先用一个最小脚本模拟人工客服或固定问答验证需求后再切换为自托管方案。2. 环境准备先把最小服务端跑起来2.1 运行环境要求本文示例使用 Node.js 实现服务端。虽然 Bolnee-Chat 的实际实现不一定只有 Node.js 一种选择但用 Node.js 作为示例的好处是它对 WebSocket 支持天然、生态成熟、前端和后端可以共用 JavaScript 语法容易理解完整链路。学习环境建议如下组件学习环境建议生产环境建议Node.js18 或 20 LTS18 或 20 LTS包管理器npm使用npm ci锁定依赖容器Docker 24 以上与 CI/CD 保持一致会话存储内存或 SQLitePostgreSQL 或 Redis反向代理不需要Nginx 或 Caddy前置知识方面建议先了解 JavaScript 基础函数、异步回调、HTTP 请求和 WebSocket 的基本概念。如果这些还不太熟悉可以先跟着本文化整为零地跑通再在扩展阶段补齐知识。2.2 初始化项目并安装依赖先创建项目目录并初始化package.jsonmkdir bolnee-chat cd bolnee-chat npm init -y npm install express socket.io dotenv这里安装三个依赖express提供 HTTP 接口和静态文件服务。socket.io实现浏览器与服务端之间的 WebSocket 通信用于实时消息推送。dotenv从.env文件读取环境变量避免把密钥和端口直接写死在代码里。如果你的网络环境安装速度较慢可以只安装必选包并留意安装完成后出现的版本信息。不同大版本之间的 API 可能有差异落地前先确认实际安装的版本。2.3 编写一个最小服务端创建一个server.js先实现健康检查接口和一个简单的聊天回显接口。require(dotenv).config(); const express require(express); const http require(http); const { Server } require(socket.io); const crypto require(crypto); const app express(); const server http.createServer(app); const io new Server(server, { cors: { origin: process.env.ALLOWED_ORIGIN || http://localhost:8080, methods: [GET, POST] } }); app.use(express.json()); // 简单会话存储。生产环境请替换为数据库或 Redis。 const sessions new Map(); // 健康检查接口用于部署后确认服务在线。 app.get(/health, (req, res) { res.json({ status: ok, timestamp: new Date().toISOString() }); }); // 创建会话或追加消息的 HTTP 接口。 app.post(/api/chat, (req, res) { const { sessionId, message, user } req.body; if (!sessionId || !message) { return res.status(400).json({ error: sessionId and message are required }); } const reply 服务端已收到${message}; sessions.set(sessionId, { user: user || { name: anonymous }, lastMessage: message, reply, updatedAt: new Date().toISOString() }); res.json({ sessionId, reply }); }); // 查看指定会话的当前状态用于排错。 app.get(/api/session/:sessionId, (req, res) { const session sessions.get(req.params.sessionId); if (!session) { return res.status(404).json({ error: session not found }); } res.json(session); }); // WebSocket 连接处理。 io.on(connection, (socket) { socket.on(client:message, (payload) { const { sessionId, content } payload; if (!sessionId || !content) return; const reply 服务端收到${content}; sessions.set(sessionId, { lastMessage: content, reply, updatedAt: new Date().toISOString() }); socket.emit(server:reply, { sessionId, content: reply, timestamp: new Date().toISOString() }); }); }); const PORT process.env.PORT || 3000; server.listen(PORT, () { console.log(Bolnee-Chat server listening on port ${PORT}); });这段代码有几个关键点第一sessions使用内存 Map 保存只是为了演示会话逻辑。服务重启后数据会丢失生产环境必须换成 PostgreSQL、MySQL 或 Redis。第二io.on(connection)中的client:message和server:reply是自定义事件名。前端脚本必须使用相同的事件名才能连通。第三/api/chat使用 HTTP 接口处理一次性的会话创建WebSocket 用于实时双向通信。两者可以共存分工不同。2.4 启动并验证最小服务端启动服务node server.js看到Bolnee-Chat server listening on port 3000后在另一个终端验证接口curl http://localhost:3000/health预期返回{status:ok,timestamp:2025-01-01T08:00:00.000Z}再测试消息接口curl -X POST http://localhost:3000/api/chat \ -H Content-Type: application/json \ -d {sessionId:test001,message:你好,user:{name:张三}}预期返回一个包含sessionId和reply的 JSON说明服务端到这一步已经可用。注意这里的回复只是回显实际项目中会替换为业务机器人逻辑。3. 把聊天机器人接入业务网站3.1 前端嵌入组件的设计思路聊天机器人集成到业务页面通常不要求业务方改造整个前端框架而是提供一个可复用的嵌入脚本。业务页面只需要加一行script传入服务端地址和业务参数脚本会自动完成以下工作生成聊天按钮和消息面板的 DOM。动态加载socket.io客户端。创建会话 ID 并建立 WebSocket 连接。将输入框消息发送到服务端并把回复渲染到面板。设计嵌入脚本时要注意几个原则一是避免污染业务页面样式。脚本生成的所有元素都放在一个独立根节点内使用内联 style 或带前缀的 CSS 类名。二是配置参数通过>(function () { var script document.currentScript; var apiBase script.getAttribute(data-api-base) || http://localhost:3000; var sessionId wc_ Date.now() _ Math.random().toString(16).slice(2); var socket null; function loadScript(src, callback) { var s document.createElement(script); s.src src; s.onload callback; document.head.appendChild(s); } function createUI() { var root document.createElement(div); root.id bolnee-chat-root; root.style.cssText position:fixed;bottom:20px;right:20px;z-index:99999;; root.innerHTML div idbolnee-chat-panel styledisplay:none;width:320px;height:420px; border:1px solid #ddd;border-radius:8px;box-shadow:0 4px 12px rgba(0,0,0,0.15); background:#fff;overflow:hidden; div idbolnee-chat-messages styleheight:340px;padding:12px;overflow-y:auto;font-size:14px;/div div styleborder-top:1px solid #eee;padding:8px;display:flex; input idbolnee-chat-input styleflex:1;border:0;outline:none;padding:8px; placeholder请输入消息 / button idbolnee-chat-send styleborder:0;background:#1677ff;color:#fff;padding:8px 12px;border-radius:4px;发送/button /div /div button idbolnee-chat-toggle styleborder:0;background:#1677ff;color:#fff;padding:10px 14px;border-radius:20px;cursor:pointer;在线咨询/button; document.body.appendChild(root); var toggle document.getElementById(bolnee-chat-toggle); var panel document.getElementById(bolnee-chat-panel); var messages document.getElementById(bolnee-chat-messages); var input document.getElementById(bolnee-chat-input); var sendBtn document.getElementById(bolnee-chat-send); function appendMessage(text, from) { var div document.createElement(div); div.style.cssText margin:6px 0;text-align: (from user ? right : left); div.textContent text; messages.appendChild(div); messages.scrollTop messages.scrollHeight; } toggle.addEventListener(click, function () { panel.style.display panel.style.display none ? block : none; }); sendBtn.addEventListener(click, function () { var value input.value.trim(); if (!value || !socket) return; appendMessage(value, user); input.value ; socket.emit(client:message, { sessionId: sessionId, content: value }); }); return { appendMessage: appendMessage }; } function init() { var ui createUI(); loadScript(apiBase /socket.io/socket.io.js, function () { socket io(apiBase); socket.on(server:reply, function (data) { ui.appendMessage(data.content, bot); }); socket.on(disconnect, function () { ui.appendMessage(连接已断开请刷新页面重试。, bot); }); window.bolneeChat { sessionId: sessionId, send: function (message) { socket.emit(client:message, { sessionId: sessionId, content: message }); } }; }); } if (document.readyState loading) { document.addEventListener(DOMContentLoaded, init); } else { init(); } })();这段脚本的核心逻辑是document.currentScript获取当前脚本标签从而读取>!DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1.0 / title示例商城页面/title /head body h1示例商城/h1 p这是业务方自己的页面内容。/p script srchttp://localhost:3000/widget.js >npx serve .然后访问页面页面右下角会出现“在线咨询”按钮。点击按钮打开面板输入一条消息并发送应该看到服务端回复回显到消息区域。注意这里使用http://localhost:3000作为示例地址。生产环境页面如果用 HTTPS 访问聊天服务地址也必须使用 HTTPS否则浏览器会阻止混合内容。3.4 把会话关联到登录用户匿名会话只能标识一次页面访问无法把聊天记录关联到具体客户。实际业务中通常需要把登录用户的 ID 和昵称传给服务端。可以在 widget 初始化后通过暴露的window.bolneeChat对象与页面通信// 页面拿到登录用户信息后自行调用 window.bolneeChat.bindUser({ id: u001, name: 张三, email: zhangsanexample.com });widget 内部需要实现bindUser。在 init 的返回对象中增加方法并保存用户信息window.bolneeChat { sessionId: sessionId, user: null, bindUser: function (user) { this.user user; }, send: function (message) { socket.emit(client:message, { sessionId: sessionId, user: this.user, content: message }); } };服务端收到消息时从payload.user中读取用户信息并写入会话存储。这样客服后台就能根据用户 ID 汇总一位客户在不同时间、不同设备上的聊天记录。4. 关键配置与参数说明4.1 服务端环境变量创建.env.example文件作为团队内的配置模板# 服务监听端口 PORT3000 # 允许承载聊天窗口的业务页面域名 ALLOWED_ORIGINhttps://www.example.com # 会话令牌签名密钥生产环境务必替换 AUTH_SECRETplease-change-me # 会话持久化地址 DATABASE_URLsqlite:///data/chat.db常见的服务端参数说明如下配置项含义默认值错误设置的表现PORT服务监听端口3000端口冲突或访问地址不正确ALLOWED_ORIGIN允许加载聊天窗口的页面来源http://localhost:8080页面 WebSocket 连不上报 CORS 错误AUTH_SECRET用于签名会话令牌的密钥空会话信息可被伪造DATABASE_URL会话与消息持久化地址内存存储使用数据库时未配置服务重启后数据丢失LOG_LEVEL日志输出级别info排错时没有足够日志参数调大或调小的实际影响需要结合场景理解。例如ALLOWED_ORIGIN设为空或*会让任意第三方网站都能嵌入聊天窗口并消耗后端资源因此生产环境必须收敛为业务域名白名单。PORT是基础设施参数调整后要同步更新反向代理和防火墙规则。4.2 前端嵌入脚本参数前端脚本通过>FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --omitdev COPY . . ENV PORT3000 EXPOSE 3000 CMD [node, server.js]node:18-alpine适合作为 Node.js 服务的基础镜像体积小、启动快。npm ci --omitdev只安装生产依赖保证版本可复现。再创建docker-compose.yml便于本地和服务器启动version: 3.8 services: bolnee-chat: build: . container_name: bolnee-chat ports: - 3000:3000 environment: - PORT3000 - ALLOWED_ORIGINhttps://www.example.com - AUTH_SECRET${AUTH_SECRET} - DATABASE_URLsqlite:///app/data/chat.db - LOG_LEVELinfo volumes: - ./data:/app/data restart: unless-stopped启动命令docker compose up -d --build镜像更新时会重建容器宿主机上的./data目录通过 volume 挂载到容器内SQLite 数据库文件不会因为容器重建而丢失。4.4 安全相关配置聊天服务暴露在公网安全配置不能省略。首先CORS 必须配置业务域名白名单。Socket.IO的 CORS 配置在new Server(server, { cors: { origin: ... } })中指定。白名单之外的域名无法建立 WebSocket 连接。其次如果服务端后续会处理用户身份需要给会话令牌加上签名校验。签名密钥通过AUTH_SECRET注入不要在代码仓库和镜像中明文保存。生产环境建议使用平台的密钥管理服务或环境变量注入。再次对外提供消息接口时要做基础限流避免被脚本刷量。下面是在 Express 中加入简单限流的示例const rateLimit require(express-rate-limit); const chatLimiter rateLimit({ windowMs: 60 * 1000, max: 30, message: { error: 请求过于频繁请稍后再试 } }); app.post(/api/chat, chatLimiter, (req, res) { ... });这个示例限定了同一个 IP 在一分钟内最多调用 30 次消息接口。实际阈值要结合业务量调整过小会误伤真实用户过大会失去防护意义。5. 运行验证与结果检查5.1 用浏览器验证完整链路启动服务端和静态页面后按以下顺序验证打开业务页面确认右下角出现“在线咨询”按钮。点击按钮确认聊天面板正常打开无样式错乱。在输入框输入“你好”发送。消息面板先出现用户消息随后出现服务端回复。刷新页面重新打开聊天窗口确认仍能正常使用。常见的一个错误是只验证第一次发送成功没有刷新或换浏览器验证。自托管服务的状态往往与浏览器保持的长连接有关刷新后需要确认 socket 能重新建立连接。5.2 用命令行验证后端接口后端接口验证可以在浏览器之外独立完成curl -X POST http://localhost:3000/api/chat \ -H Content-Type: application/json \ -d {sessionId:test001,message:你好,user:{name:张三}}预期响应{sessionId:test001,reply:服务端已收到你好}再查会话状态curl http://localhost:3000/api/session/test001预期响应中包含lastMessage和reply字段。这个接口主要用于排错生产环境需要注意对会话查询接口做权限控制避免任意用户读取其他会话。5.3 查看服务端日志启动服务端的终端会输出启动信息。当浏览器发送消息时如果服务端代码没有打印日志可以临时在 socket 回调中加入日志socket.on(client:message, (payload) { console.log(received message:, JSON.stringify(payload)); ... });生产环境不要把完整的用户消息直接打印到 stdout避免敏感数据泄露。建议使用结构化日志记录消息长度、会话 ID、处理耗时等元信息必要时把消息内容写入带权限控制的日志系统。6. 常见问题排查6.1 五类高频问题自托管聊天机器人上线后遇到最多的问题集中在接入配置、跨域、协议、连接和资源占用五个方面。问题现象常见原因检查方式处理建议页面加载后没有聊天按钮script 路径错误、页面存在 JS 错误打开浏览器开发者工具查看 Console 和 Network确认 widget.js 能加载修复页面 JS 错误按钮出现但消息发不出去WebSocket 没有建立连接查看 Network 面板中的 WS 请求检查 ALLOWED_ORIGIN 和 api-base 地址生产页面是 HTTPS聊天服务是 HTTP浏览器阻止混合内容Console 提示 Mixed Content统一使用 HTTPS刷新后会话丢失会话只存在内存 Map 中调用 /api/session/:id 查询接入 Redis 或数据库持久化多个用户并发时偶发离线会话存储跨实例不同步查看多实例负载是否开启 sticky session使用共享 Redis 和 Socket.IO adapter6.2 排查链路按顺序检查当聊天功能异常时建议按下面的顺序排查避免跳到深水区。检查页面 Console。如果 widget.js 没有执行问题先在浏览器侧。检查 Network 面板。确认widget.js是否加载成功、socket.io.js是否加载成功。检查 WS 连接。确认 WebSocket 是否进入pending或直接失败。检查服务端日志。确认client:message是否被收到。检查回复链路。确认server:reply是否发出、前端是否监听同名事件。检查会话持久化。确认刷新后能否从数据库恢复会话。在 WebSocket 场景下事件名不一致是最隐蔽的错误。前端发送client:message后端必须监听同一事件名后端发送server:reply前端也必须监听同一事件名。排错时优先核对这两个事件名。6.3 日志关键字服务端日志出现以下关键字时对应问题如下日志关键字含义下一步received message后端收到前端消息检查回复是否发出CORS跨域策略拒绝检查 ALLOWED_ORIGINECONNREFUSED下游依赖连接失败检查数据库、Redis、模型服务EADDRINUSE端口被占用检查端口占用并调整GET /health 200健康检查正常整体链路基本正常7. 生产环境部署最佳实践7.1 学习环境与生产环境的差异本地跑通与生产发布之间隔着一系列不可省略的工程步骤。学习环境只需要代码能跑、页面能用生产环境要考虑连接安全、数据可靠、扩展和运维。项目学习环境生产环境页面协议HTTPHTTPS会话存储内存 MapRedis 或 PostgreSQL密钥明文或随机密钥管理服务注入日志console.log结构化日志系统部署npm startDocker 编排平台监控手动查看探活、指标、告警多实例单实例多实例 共享存储7.2 安全加固清单自托管聊天机器人直接暴露在公网上线前至少完成以下加固使用 HTTPS并在反向代理层统一终止 TLS。将ALLOWED_ORIGIN配置为业务域名白名单禁止使用*。通过环境变量注入AUTH_SECRET不要写入镜像和仓库。对/api/chat和 WebSocket 连接做限流。对用户输入做长度限制避免超大消息压垮服务。对回复内容做基础过滤和脱敏避免在页面上渲染危险内容。生产环境禁止开放未授权访问的会话查询接口。7.3 日志与监控至少记录以下指标WebSocket 连接数。消息发送频率。消息处理耗时。回复失败次数。会话持久化失败次数。健康检查探活结果。如果使用 Docker 部署可以为容器增加健康检查healthcheck: test: [CMD, node, -e, fetch(http://localhost:3000/health).then(r { if (!r.ok) process.exit(1) }).catch(() process.exit(1))] interval: 30s timeout: 5s retries: 3健康检查地址要落在服务内网不要通过公网地址检查。否则公网网络波动会导致误报 or 公网被攻击时掩盖真实问题。7.4 发布前检查清单把下面这份清单交给上线负责人可以减少大部分上线事故[ ] 页面与聊天服务均使用 HTTPS。[ ]ALLOWED_ORIGIN已填写正式业务域名。[ ]AUTH_SECRET已更改为随机强密钥。[ ] 会话存储已切换为 Redis 或数据库。[ ] 服务端日志已接入统一日志平台。[ ] 反向代理已配置 WebSocket 升级支持。[ ] 端口和防火墙规则已放行。[ ] 健康检查探活在监控平台正常展示。[ ] 多实例部署时已确认 Socket.IO shared adapter 或 sticky session。7.5 本地调试与生产调试的差异本地调试时可以直接看终端日志、修改代码热重启。生产环境通常没有终端权限更多要依赖日志和监控。建议从一开始就使用结构化日志至少包含time、level、event、sessionId字段。这样在搜索日志平台时可以通过sessionId精确串联一次完整对话。8. 扩展方向8.1 对接大模型并接入知识库当前示例的回复只是回显生产环境中通常需要把用户消息发给大模型服务。可以优先选择兼容 OpenAI 协议的推理服务因为这样可以保留下游切换空间先开发一个统一的回复接口由内部网关决定调用哪个模型。公开的大模型评估平台例如 LMArena可以作为初步筛选底座模型的参考但最终选型必须基于自己的业务测试集。要把行业术语、客服话术、隐私边界整理成评测集而不是直接拿公共榜单的结果做最终决定。知识库接入后聊天机器人优先在知识库中检索答案检索不到时再判断是否需要大模型生成或转人工。这一步会让自托管聊天机器人的价值更明显知识库数据、检索逻辑、脱敏规则都掌握在自己手里。8.2 人工接管自动回复不能覆盖所有场景。常见策略是设置一个转人工阈值用户连续问两次“转人工”、或者在回复中点击“转人工”按钮系统就把会话状态标记为人工。人工接管的技术实现需要一个坐席端页面坐席通过 WebSocket 监听分配给自己的会话。会话分配规则、坐席离线处理、排队提示都需要单独设计。建议在扩展这一功能之前先把会话状态机定义清楚新建、机器人接待、转人工中、人工接待、已结束、已归档。8.3 与企业系统集成聊天记录和线索不能停留在聊天服务内部。最常见的集成方式是利用 Webhook 把新消息、新会话、转人工事件推送给外部系统外部系统再决定后续动作。例如把聊天产生的用户意向写入 CRM、把售后请求自动创建为工单、把高价值客户消息同步给企业微信群机器人。如果企业已经使用 SAP Integration Suite 这类集成平台可以让聊天服务只负责暴露标准 REST 或 Webhook 接口再由集成平台统一编排到 ERP、CRM、工单等系统。这样聊天服务本身保持简单复杂的业务流程交给专业集成平台处理。8.4 下一步学习路径做完本文的最小示例后建议按以下顺序深化第一把内存 Map 替换为 Redis 或 PostgreSQL理解会话恢复和数据持久化的意义。第二为服务端补充单元测试和接口测试至少覆盖健康检查、消息接口和 WebSocket 事件。第三设计一个简单的多轮对话状态机让机器人能根据上下文记忆上一轮问题。第四加入限流、鉴权和日志中间件把服务从“能跑”提升到“能上线”。第五尝试接入一个大模型服务并用知识库做检索增强生成比较不同提示词策略的效果。自托管聊天机器人的学习价值不在于它比 SaaS 产品更省钱而在于它逼你理解消息链路中的每一个环节。你能解释问题出现在哪一层并且能修改它、监控它、优化它这是商业网站接入聊天功能时最核心的能力。
