从“看数据”到“做决策”：CRM 智能助手的工程设计

为什么 CRM 需要智能助手

传统 CRM 已经积累了大量客户、销售、商品和行为数据，但“数据存在”不等于“数据可用”。业务人员常遇到两类问题：

看到了指标，却不知道下一步应该做什么；
已经有明确动作，却不知道该从哪个页面、哪个维度找到支撑数据。

因此，智能助手的目标不是替代 CRM 页面，而是缩短从业务意图到数据行动的路径。用户用自然语言描述想做的事，系统识别意图、选择数据工具、验证权限并返回可继续操作的卡片。

自然语言 Action
      |
      v
意图识别与参数抽取
      |
      v
权限校验 -> 工具/API 调用 -> 结构化结果
      |
      v
文字解释 + 业务卡片 + 下一步操作

先从 Action 反推数据

如果先把所有数据维度堆进模型，再期待模型自己发现价值，结果通常是上下文越来越长、答案越来越泛。

更稳妥的设计顺序是：

列出高频业务动作，例如查看销售榜、定位潜力客户、分析商品趋势；
为每个动作定义最小必要数据与权限范围；
把稳定查询封装成明确的工具，而不是让模型任意生成 SQL；
用真实问题构建评测集，持续补齐无法命中的数据路径。

例如，“找出最近 7 天销售增长最快的商品”可以被拆成：

{
  "intent": "query_sales_growth",
  "time_range": "last_7_days",
  "dimension": "item",
  "sort": "growth_rate_desc",
  "limit": 20
}

模型负责把非结构化表达转成受约束的参数，后端负责权限、参数验证和实际执行。

总体架构

Web / App
   |
   | 创建任务、查询状态
   v
Assistant API
   |-- Auth Context：当前用户与租户
   |-- Intent Router：意图与工具路由
   |-- Schema Validator：结构化参数校验
   |-- Policy Guard：字段级、行级权限
   |-- Agent Runtime：工作流与模型调用
   `-- Result Renderer：文本、表格、卡片
            |
            +--> CRM Query API
            +--> Search / RAG
            +--> Analytics Service

模型不直接持有数据库凭证，也不能通过 Prompt 指定“替我查询另一个用户”。所有数据范围都必须从服务端认证上下文派生。

为什么采用异步任务

一次助手请求可能包含模型推理、知识检索和多个业务接口调用，耗时不稳定。如果让普通 HTTP 请求一直阻塞，会占用应用进程，也更难处理超时和重试。

可以采用“创建任务 + 状态查询”的模式：

POST /assistant/tasks
Content-Type: application/json
 
{"message":"查看最近一周增长最快的商品"}

{
  "task_id": "task_xxx",
  "status": "queued"
}

前端通过短轮询获取阶段结果；需要更自然的输出体验时，再由独立的 SSE 网关推送增量事件。

短任务：普通 HTTP
长任务：创建任务 -> 队列 -> Worker -> 持久化结果
交互展示：轮询或 SSE 读取任务事件

轮询接口应支持退避、最大等待时间和终态缓存，避免所有客户端固定高频请求。

数据卡片协议

纯文本很难承载排行、趋势和客户列表。助手应返回稳定的内容协议，让前端按类型渲染：

{
  "type": "ranking_card",
  "version": 1,
  "title": "近 7 天增长商品",
  "data": {
    "items": [],
    "metric": "growth_rate"
  },
  "actions": [
    {"type": "open_page", "target": "sales-ranking"}
  ]
}

协议需要版本号、失败兜底和允许列表。模型只能选择已注册的卡片类型，不能下发任意组件代码。

会话与消息模型

会话用于组织历史，消息用于保存用户输入、助手结果和任务状态。一个简化的数据模型如下：

create table assistant_session (
  id bigint primary key,
  owner_id bigint not null,
  title varchar(100) not null,
  status smallint not null default 0,
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now()
);
 
create table assistant_message (
  id uuid primary key,
  session_id bigint not null references assistant_session(id),
  task_id uuid,
  role varchar(20) not null,
  content_json jsonb not null,
  status varchar(20) not null,
  model_version varchar(50),
  created_at timestamptz not null default now()
);

不要把前端传入的 owner_id 当成权限依据。查询条件必须使用服务端解析出的登录身份，并对 session_id + owner_id 做联合校验。

参数映射与 RAG

自然语言里的品牌、类目和商品名称经常存在简称、错别字和歧义。参数映射可以分成三层：

精确映射：ID、标准名称与别名表；
搜索召回：关键词、拼音、模糊匹配；
语义召回：Embedding / RAG 返回候选项。

模型只负责从候选集中选择或发起澄清，不应在没有证据时凭空生成业务 ID。

{
  "raw_text": "某品牌儿童鞋",
  "candidates": [
    {"id": "brand_a", "name": "示例品牌", "score": 0.91}
  ],
  "needs_confirmation": false
}

安全边界

CRM 数据通常包含敏感业务信息，智能助手至少需要以下控制：

身份、租户和数据范围由服务端注入，不能由 Prompt 覆盖；
工具使用允许列表，每个工具声明输入 Schema、权限和超时；
对模型输出做结构化校验，非法字段直接拒绝；
查询结果按字段脱敏，避免把手机号、地址等信息送入模型；
对 Prompt Injection 做隔离，知识库文本不能获得工具控制权；
保留工具调用、数据范围、模型版本和结果摘要的审计日志；
高风险写操作必须二次确认，默认只开放只读工具。

如何评估助手是否真的可用

不能只看回答“像不像”。至少需要一组固定 Case 评估：

维度	说明
意图命中率	是否路由到正确工具
参数准确率	时间、维度、过滤条件是否正确
权限正确率	是否严格限制在当前用户可见范围
数据一致性	与原 CRM 页面或基准 SQL 是否一致
任务成功率	超时、重试和兜底是否有效
用户行动率	用户是否继续打开页面、导出或跟进

把失败 Case 按“意图缺失、参数映射失败、数据源缺失、权限拒绝、工具异常”分类，才能知道下一步该补工作流还是补数据。

分阶段落地

第一阶段：跑通确定性路径

选择 2 到 3 个高频榜单或分析场景；
建立只读工具与统一卡片协议；
完成任务创建、轮询和会话历史；
用内部测试集验证数据一致性。

第二阶段：补参数映射与反馈

建立品牌、类目、商品的检索与消歧；
引入 RAG 作为候选召回，而不是最终事实源；
记录用户的追问、纠正与未命中问题。

第三阶段：Agent 化

把稳定工作流注册为可编排工具；
为复杂分析引入多步骤计划与中间结果；
建立离线评测、灰度发布和模型版本回滚能力。

总结

CRM 智能助手的关键不是聊天界面，而是把自然语言安全地转换为可执行的数据路径。Action 定义需求，工具封装确定性，模型负责理解与编排，权限系统守住边界，卡片协议把结果变成下一步操作。

当这些基础设施完善后，助手才不只是“回答问题”，而是在业务系统中缩短决策链路。