企业官网建设流程全解析

商业网站接入聊天机器人时，最常见的难点往往不是模型本身，而是集成链路：聊天窗口怎么嵌入业务页面、消息怎么从浏览器到服务端、服务端怎么返回回复、会话怎么定位到用户、部署在谁的环境里。Bolnee-Chat 这类自托管聊天机器人方案，核心价值就是把这一整条链路放到自己的服务器上，由自己控制代码、控制数据、控制部署位置，而不是把客户对话和用户数据全部交给外部 SaaS。本文会从自托管聊天机器人的概念讲起，然后带你走通一个最小可运行方案：Node.js 服务端、前端嵌入脚本、业务页面接入、Docker 部署、验证和排错。学完之后，你可以把这条链路迁移到自己的技术栈，也可以继续扩展出大模型回复、人工接管、知识库和工单联动。

1. 先理解自托管聊天机器人解决了什么问题

1.1 自托管与 SaaS 聊天机器人服务的核心差异

过去给官网加一个聊天机器人，最常见的选择是第三方在线客服产品：在页面上贴一段脚本，然后到服务商后台配置机器人话术。这种方式上线快，但存在几个现实问题。

首先是数据归属。客户在聊天窗口里输入的每一条消息，都会经过服务商的服务器。对于需要遵守个人信息保护要求、客户数据敏感的企业来说，这个环节很难完全回避合规风险。其次是定制深度。第三方平台通常只能配置固定的开场白、多轮问答树、转人工条件，一旦业务方想改消息路由逻辑、把聊天记录同步到自己的 CRM、或者对接内部大模型服务，就会受平台功能限制。再次是长期成本。聊天机器人按消息量或坐席数计费，当访问量增长后，费用会以非线性方式上升。

自托管聊天机器人则是把整套聊天服务打包成自己的后端模块，前端通过一段可嵌入的脚本接入，所有消息先到自己的服务端，再由服务端决定回复方式。用一张表格可以更清楚看到差异：

并不是说自托管一定更好。如果团队没有运维能力、业务周期很短，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 语法，容易理解完整链路。

学习环境建议如下：

前置知识方面，建议先了解 JavaScript 基础函数、异步回调、HTTP 请求和 WebSocket 的基本概念。如果这些还不太熟悉，可以先跟着本文化整为零地跑通，再在扩展阶段补齐知识。

2.2 初始化项目并安装依赖

先创建项目目录并初始化package.json：

mkdir 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 id="bolnee-chat-panel" style="display: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 id="bolnee-chat-messages" style="height:340px;padding:12px;overflow-y:auto;font-size:14px;"></div>' + ' <div style="border-top:1px solid #eee;padding:8px;display:flex;">' + ' <input id="bolnee-chat-input" style="flex:1;border:0;outline:none;padding:8px;" placeholder="请输入消息" />' + ' <button id="bolnee-chat-send" style="border:0;background:#1677ff;color:#fff;padding:8px 12px;border-radius:4px;">发送</button>' + ' </div>' + '</div>' + '<button id="bolnee-chat-toggle" style="border: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 lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>示例商城页面</title> </head> <body> <h1>示例商城</h1> <p>这是业务方自己的页面内容。</p> <script src="http://localhost:3000/widget.js" >npx serve .

  然后访问页面，页面右下角会出现“在线咨询”按钮。点击按钮打开面板，输入一条消息并发送，应该看到服务端回复回显到消息区域。

  注意：这里使用http://localhost:3000作为示例地址。生产环境页面如果用 HTTPS 访问，聊天服务地址也必须使用 HTTPS，否则浏览器会阻止混合内容。

  3.4 把会话关联到登录用户

  匿名会话只能标识一次页面访问，无法把聊天记录关联到具体客户。实际业务中通常需要把登录用户的 ID 和昵称传给服务端。

  可以在 widget 初始化后，通过暴露的window.bolneeChat对象与页面通信：

  // 页面拿到登录用户信息后，自行调用 window.bolneeChat.bindUser({ id: 'u001', name: '张三', email: 'zhangsan@example.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文件，作为团队内的配置模板：

  # 服务监听端口 PORT=3000 # 允许承载聊天窗口的业务页面域名 ALLOWED_ORIGIN=https://www.example.com # 会话令牌签名密钥，生产环境务必替换 AUTH_SECRET=please-change-me # 会话持久化地址 DATABASE_URL=sqlite:///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 --omit=dev COPY . . ENV PORT=3000 EXPOSE 3000 CMD ["node", "server.js"]

  node:18-alpine适合作为 Node.js 服务的基础镜像，体积小、启动快。npm ci --omit=dev只安装生产依赖，保证版本可复现。

  再创建docker-compose.yml，便于本地和服务器启动：

  version: "3.8" services: bolnee-chat: build: . container_name: bolnee-chat ports: - "3000:3000" environment: - PORT=3000 - ALLOWED_ORIGIN=https://www.example.com - AUTH_SECRET=${AUTH_SECRET} - DATABASE_URL=sqlite:///app/data/chat.db - LOG_LEVEL=info 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 用浏览器验证完整链路

  启动服务端和静态页面后，按以下顺序验证：

  1. 打开业务页面，确认右下角出现“在线咨询”按钮。
  2. 点击按钮，确认聊天面板正常打开，无样式错乱。
  3. 在输入框输入“你好”，发送。
  4. 消息面板先出现用户消息，随后出现服务端回复。
  5. 刷新页面，重新打开聊天窗口，确认仍能正常使用。

  常见的一个错误是只验证第一次发送成功，没有刷新或换浏览器验证。自托管服务的状态往往与浏览器保持的长连接有关，刷新后需要确认 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 adapter

  6.2 排查链路：按顺序检查

  当聊天功能异常时，建议按下面的顺序排查，避免跳到深水区。

  1. 检查页面 Console。如果 widget.js 没有执行，问题先在浏览器侧。
  2. 检查 Network 面板。确认widget.js是否加载成功、socket.io.js是否加载成功。
  3. 检查 WS 连接。确认 WebSocket 是否进入pending或直接失败。
  4. 检查服务端日志。确认client:message是否被收到。
  5. 检查回复链路。确认server:reply是否发出、前端是否监听同名事件。
  6. 检查会话持久化。确认刷新后能否从数据库恢复会话。

  在 WebSocket 场景下，事件名不一致是最隐蔽的错误。前端发送client:message，后端必须监听同一事件名；后端发送server:reply，前端也必须监听同一事件名。排错时优先核对这两个事件名。

  6.3 日志关键字

  服务端日志出现以下关键字时，对应问题如下：

  日志关键字	含义	下一步
  received message	后端收到前端消息	检查回复是否发出
  CORS	跨域策略拒绝	检查 ALLOWED_ORIGIN
  ECONNREFUSED	下游依赖连接失败	检查数据库、Redis、模型服务
  EADDRINUSE	端口被占用	检查端口占用并调整
  GET /health 200	健康检查正常	整体链路基本正常

  7. 生产环境部署最佳实践

  7.1 学习环境与生产环境的差异

  本地跑通与生产发布之间隔着一系列不可省略的工程步骤。学习环境只需要代码能跑、页面能用；生产环境要考虑连接安全、数据可靠、扩展和运维。

  项目	学习环境	生产环境
  页面协议	HTTP	HTTPS
  会话存储	内存 Map	Redis 或 PostgreSQL
  密钥	明文或随机	密钥管理服务注入
  日志	console.log	结构化日志系统
  部署	npm start	Docker + 编排平台
  监控	手动查看	探活、指标、告警
  多实例	单实例	多实例 + 共享存储

  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 产品更省钱，而在于它逼你理解消息链路中的每一个环节。你能解释问题出现在哪一层，并且能修改它、监控它、优化它，这是商业网站接入聊天功能时最核心的能力。