智能客服的难点从来不在"能聊天"，而在聊天之后的事——认证谁在说话、什么时候该把对话交给真人、问题怎么变成可追踪的工单、RAG 检索出来的答案到底靠不靠谱。贝壳 AI 客服系统 v1.4.0 把这些"后半程"的工程问题逐个补齐，让 Agent 不只是一个会回答问题的对话框，而是一套能跑完完整服务流程的系统。
认证会话：从散装 Token 到统一管控
上一版的后台认证逻辑分散在不同模块里，Token 有效期各管各的，管理员登录态的续期和失效行为不一致。v1.4.0 重构了整个认证会话层：
- 统一管理员 Token 有效期配置，不再需要在多个配置文件里分别设置过期时间。
- 移除了旧版中冗余的会话存储路径，认证状态集中管理。
这意味着如果你在运维多租户或多角色场景，只需要改一处配置就能控制所有管理端登录态的生命周期，不用再担心某个模块的 Token 悄悄过期而另一个还活着。
人工转接与工单工作台：Agent 的"退出机制"
纯 AI 客服最大的隐患是：遇到它处理不了的问题，用户卡在那里。v1.4.0 加了两条"退出通道"。
人工转接——当 Agent 判断当前问题超出 Skill 覆盖范围，或用户主动要求真人介入，系统把完整对话上下文一并推给人工坐席，而不是让坐席从零开始问一遍。
工单工作台——不是所有问题都能在对话里当场解决。转接后如果仍需跟进，对话内容可以直接生成工单，进入工作台流转。工单状态、处理人、优先级都在工作台里可视可操作。
这两件事看似简单，但做不好就是客服系统最常见的"断点"：AI 答不上来没人接，接了人又没记录，记录了又没人跟进。v1.4.0 把这条链路串起来了。
RAG 回答可靠性：给检索结果加一道质检
RAG 是 AI 客服里用得最广的技术，也是最容易出幻觉的环节。检索到了一段文档，模型就照着说，但那段文档可能已经过时、可能和用户问题只是字面相似而语义不同。
v1.4.0 对 RAG 回答链路做了可靠性升级，核心思路是在"检索→生成"之间加入校验：
- 对检索召回的文档片段做相关性评分过滤，低分片段不进入生成环节。
- 生成回答时附带来源引用，让答案可追溯。
这样用户看到的不再是"AI 说了一句话"，而是"AI 引用了哪份文档说了这句话"，可信度从模型自信变成了证据支撑。
Widget SDK 体验升级：嵌入更顺，交互更稳
贝壳 AI 客服提供 Widget SDK 供第三方业务系统嵌入客服窗口。v1.4.0 改了几个实际影响接入体验的点：
- 消息渲染性能优化，长对话不再卡顿。
- 会话恢复逻辑修正，用户刷新页面后能续上之前的对话而不是开新窗口。
对于在 App 或 Web 里嵌入客服组件的团队来说，这些改动直接减少了"用户聊到一半丢了上下文"的投诉。
实践：用 MCP + Skill 搭一个最小客服 Agent
贝壳 AI 客服系统的核心架构是 Agent → Skill → MCP：Agent 是对话引擎，Skill 封装业务动作，MCP 连接外部系统能力。下面用一个最小示例演示如何定义一个 Skill 并通过 MCP 调用外部数据。
假设你要让客服 Agent 能查询房源信息，步骤如下：
1. 定义 MCP Server（提供房源查询能力）
# house_query_mcp_server.py
from mcp.server import Server
from mcp.types import Tool, TextContent
server = Server("house-query")
@server.list_tools()
async def list_tools():
return [
Tool(
name="query_house_by_id",
description="根据房源 ID 查询房源详情",
inputSchema={
"type": "object",
"properties": {
"house_id": {"type": "string", "description": "房源 ID"}
},
"required": ["house_id"]
}
)
]
@server.call_tool()
async def call_tool(name, arguments):
if name == "query_house_by_id":
house_id = arguments["house_id"]
# 实际场景中这里调用内部房源 API
mock_result = {
"house_id": house_id,
"title": "朝阳区两居室",
"price": "6800元/月",
"status": "可租"
}
return [TextContent(type="text", text=str(mock_result))]
# 启动 MCP Server（stdio 模式）
async def main():
from mcp.server.stdio import stdio_server
async with stdio_server() as (read_stream, write_stream):
await server.run(read_stream, write_stream)
if __name__ == "__main__":
import asyncio
asyncio.run(main())
2. 在系统中注册 Skill（绑定 MCP 能力到业务场景）
# skill_config.yaml — 房源查询 Skill 定义
skill:
name: house_query
description: "帮助用户查询房源信息，包括价格、状态等"
trigger:
keywords: ["房源", "房子", "租房", "查询房源"]
intent: house_inquiry
mcp_servers:
- name: house-query
transport: stdio
command: "python"
args: ["house_query_mcp_server.py"]
response_template: "为您查询到房源信息：{{title}}，租金 {{price}}，当前状态 {{status}}。"
fallback:
action: transfer_to_human
reason: "房源数据异常或用户需要线下看房"
3. 运行效果
用户说"我想查一下房源 BJ-10023"，Agent 匹配到 house_inquiry intent → 触发 house_query Skill → 通过 MCP 调用 query_house_by_id → 拿到结果后按模板回复。如果 MCP 返回异常或用户追问"能不能实地看"，Skill 的 fallback 把对话转给人工坐席。
上面是最小可跑的骨架。实际部署时，MCP Server 的
mock_result需替换为真实内部 API 调用，Skill 配置需放入贝壳 AI 客服系统的后台管理界面中注册，而非直接写 YAML 文件。具体注册方式参见项目文档。
接入前的几件要事
如果你在评估是否引入这套系统，建议先确认以下几点：
- 你的客服场景是否有明确的"AI 能处理 / AI 处理不了"边界？ 如果边界模糊，人工转接的触发条件需要仔细设计，否则要么转得太频繁增加坐席负担，要么转得太晚用户已经流失。
- RAG 数据源的更新频率如何？ 可靠性升级依赖引用溯源，但如果底层知识库本身更新不及时，引用也只能证明"AI 看了旧文档"，不能证明"AI 说的是当前事实"。定期清理和标注知识库是前提。
- Widget SDK 的嵌入环境是否支持长连接？ 会话恢复依赖 WebSocket 或类似机制，如果你的 Web 端有严格的连接超时策略，需要和 SDK 的心跳逻辑对齐。
贝壳 AI 客服系统 v1.4.0 的改动不是功能堆叠，而是把智能客服从"能对话"推向"能闭环"。认证统一管、转接有通道、工单可追踪、RAG 有质检、嵌入更稳定——每一项都是让 Agent 在真实业务里跑得更远的基础设施。