文章目录
-
-
- 前言
- [1. 整体架构：大模型只负责语义判断](#1. 整体架构：大模型只负责语义判断)
-
- [1.1 数据接入](#1.1 数据接入)
- [1.2 确定性预处理](#1.2 确定性预处理)
- [1.3 模型分析](#1.3 模型分析)
- [1.4 业务交付](#1.4 业务交付)
- [2. 关键实现一：先把碎消息拼成完整会话](#2. 关键实现一：先把碎消息拼成完整会话)
- [3. 关键实现二：隐私处理必须做在模型前面](#3. 关键实现二：隐私处理必须做在模型前面)
- [4. 关键实现三：让模型输出程序能验收的结果](#4. 关键实现三：让模型输出程序能验收的结果)
- [5. 业务交付：直接写进日常用的工具里](#5. 业务交付：直接写进日常用的工具里)
- [6. 失败原则：宁可停摆，也不凑数](#6. 失败原则：宁可停摆，也不凑数)
- [7. 业务到底怎么用这三样东西](#7. 业务到底怎么用这三样东西)
- [8. 可复用的Agent交付检查清单](#8. 可复用的Agent交付检查清单)
-
P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。
前言
做过客服数据分析的朋友，大概率都踩过同一个坑：第三方客服系统导出来的Excel，一行就一条消息。同一次用户咨询，拆得七零八落散在十几行里，你想捋明白一个完整问题，得像玩拼图一样自己凑。
我们最近落地了一个客服数据分析Agent，不是那种生成完本地报告就完事的花架子，是直接扎进客服工作流程里的实用工具。最终产出就是钉钉里的三样东西：一份用户原声洞察周报、一张问题聚类明细表、一张原声样本池。
整条链路跑通不难，但里面有几个工程细节，真的很容易被忽略。今天就给大家拆解拆解。
1. 整体架构：大模型只负责语义判断
别一提到Agent就觉得全是大模型在发光发热，真要落地干活，大模型只能干它最擅长的事------处理不确定的语义判断。剩下那些能写死规则、能重复校验的脏活累活，全得靠程序来。
整套Agent拆成了四个部分，分工明明白白，谁也别抢谁的活。
1.1 数据接入
就是负责读Excel或者CSV文件，识别不同文件里的字段名，先检查最核心的会话标识和消息内容能不能对上。
这一步就像入场检票，票不对，直接不让进，半点儿商量的余地都没有。
1.2 确定性预处理
过滤掉无效记录，分清哪条是用户发的、哪条是客服回的，把能识别的敏感信息先替换掉，最后按时间和会话ID，把散着的消息拼成完整的会话。
说白了就是干脏活累活的后勤部门，把数据收拾得干干净净再往下传。
1.3 模型分析
大模型拿到预处理好的完整会话，只干一件事：判断用户的核心诉求、问题主题、情绪、优先级，然后按固定结构返回结果。
多的它也不用干，干多了反而容易出幺蛾子。
1.4 业务交付
把模型返回的结构化结果，转成钉钉表格能认的二维数组，写进两张表格里，再生成周报，把表格链接嵌进去。
相当于最后打包发货，直接送到业务人员办公桌上。
整个流程大概是这么个逻辑：
上传客服咨询Excel/CSV
字段识别与必填校验
→ 不通过：停止处理并报告缺失字段
→ 通过：确定性数据清洗
敏感信息规则脱敏
按conversation_id聚合为完整会话
隐私残留检查
→ 存在高风险隐私残留：阻断对应会话
→ 通过：会话级大模型结构化分析
问题聚类与样本抽取
生成两张二维表格数据
写入问题聚类明细表钉钉表格
写入原声样本池钉钉表格
生成用户痛点周报正文
写入用户痛点周报钉钉文档
周报中写入两张钉钉表格链接2. 关键实现一：先把碎消息拼成完整会话
很多人做客服分析，图省事就直接逐行喂给模型，这纯属自欺欺人。
你想啊，一行就孤零零一句话，模型只看到用户甩了一句"这不行"，它哪知道前面客服是怎么回复的？哪知道用户是因为啥炸毛？就像你看春晚小品只截中间一句台词，你根本不知道前面铺垫了啥包袱，还得以为演员现场忘词了。
所以我们把会话ID和消息内容定为必要字段，缺一个都直接停流程，绝不拿残缺数据凑数交差。
这段预处理的逻辑，用代码说大概是这样：
rows = read_excel_or_csv(input_file)
mapped_rows = map_field_aliases(rows)
require_fields(mapped_rows, ["conversation_id", "message_text"])
clean_rows = filter_invalid_messages(mapped_rows)
redacted_rows = redact_by_rules(clean_rows)
sorted_rows = sort_by_conversation_and_time(redacted_rows)
conversations = group_by_conversation_id(sorted_rows)实际跑起来，细节还挺多：
不同文件同一个意思可能叫不同字段名，得先做别名映射；空消息、系统消息、没会话ID的记录，直接过滤掉；发送方角色没写的，得通过前缀或者内容自己识别；同一会话里的消息，得先按时间排好序再拼起来。
等都拼完了，模型看到的才是一次完整的对话，而不是一堆支离破碎的单句。
3. 关键实现二：隐私处理必须做在模型前面
这里有个死规矩，半点儿不能破：没脱敏的原始对话，绝对不能直接进大模型。
别指望模型自己判断什么该看什么不该看，就像你别指望快递员自动忽略你快递单上的手机号。该遮的，你得自己提前遮好。
所以预处理脚本不会把整份Excel直接丢给模型，它会先把分析需要的字段提出来，用关键词加正则，把手机号、身份证号这些能稳定识别的敏感信息全替换掉。
这个顺序千万不能乱，乱了就容易出风险：
原始Excel → 必要字段筛选 → 确定性规则脱敏 → 会话聚合 → 模型分析隐私处理是模型输入前的工程步骤，不是模型的职责。把风险掐死在源头，比啥都强。
4. 关键实现三：让模型输出程序能验收的结果
要是模型每次都回一大段自然语言总结，后续程序直接罢工------总不能让代码再去读一遍小作文，自己提取信息吧？那不等于绕了一圈又回去了，脱裤子放屁多此一举。
所以我们要求，每个完整会话，必须返回一条固定结构的结果。长这样：
{
"conversation_id": "123456",
"problem_topic": "某类业务问题",
"core_user_need": "用户希望确认原因和后续处理时间",
"emotion": "negative",
"priority": "high",
"manual_category_mismatch": false,
"suggested_department": "建议跟进部门",
"suggested_action": "建议的后续动作",
"need_follow_up": true,
"confidence": 0.86
}字段名、枚举值必须稳如老狗，业务侧才能接着往下走：校验字段完不完整，把内部枚举翻译成大白话，把相近的问题归堆统计，最后组装成钉钉表格要的格式。
要是模型返回的结构不对，程序直接拦下来，绝不让错误内容混到最终产物里。
等所有会话都分析完，Agent再把相近的问题合并成业务能看懂的主题。重复出现的、差评集中的、人工分类明显错的，都会优先拎出来。每个主题还会抽几条脱敏后的原声样本，方便业务人员核对模型说得对不对。
5. 业务交付：直接写进日常用的工具里
这项目还有第二个死规矩：最终结果只能写进钉钉文档和钉钉表格，不能搞成md、csv、xlsx文件让人家自己下载。
别觉得这只是输出格式不一样，这直接决定了项目有没有真的交付。
你想啊，业务人员天天上班就钉在钉钉里，你给人发个附件，还得下载、打开、说不定还要转格式，麻烦得要死。放心，大概率看都不会多看一眼，最后就躺在文件夹里吃灰。
所以我们是直接把数据组装成二维数组，第一行是固定的中文表头，后面全是业务数据，直接写进钉钉表格里。
写完还不算完，还得检查一下表格的A1单元格：问题聚类明细表的A1必须是"问题主题"，原声样本池的A1必须是"会话ID"。要是A1出现个本地路径或者文件名，那就是写崩了，得清空重写。
两张表格都校验通过了，再生成周报正文，把表格链接嵌到对应的章节里。
整个交互流程大概是这样：
用户上传客服咨询Excel/CSV
→ Agent执行字段校验、清洗、脱敏、会话聚合
→ 返回脱敏会话、统计和审计结果
→ 隐私残留检查，返回可分析/阻断结果
→ 大模型会话级分析、问题聚类、样本抽取
→ 返回结构化分析结果
→ 写入问题聚类二维表格数据，返回钉钉表格链接
→ 写入原声样本池二维表格数据，返回钉钉表格链接
→ 写入周报正文和两个表格链接，返回钉钉文档链接
→ 最终返回1个钉钉文档+2个钉钉表格6. 失败原则：宁可停摆，也不凑数
做工程的，得有这个底线：遇到问题就停下来报原因，别硬着头皮跑，最后输出一堆四不像的东西，反而给业务添乱。
我们这套流程，遇到下面这些情况，直接停止并报告原因，绝不凑合：
没收到上传的文件；文件解析不开；会话标识或者消息内容对不上；清洗完有效会话数是0；模型返回的结构通不过校验；钉钉授权或者写入工具用不了。
停了之后，只说清楚为啥断了、需要补啥信息，绝不说"要不我先给你个本地文件凑合用"。
就像外卖漏了餐，你得告诉用户缺了啥、什么时候补，而不是随便塞点咸菜凑数送过去，那不是解决问题，是找投诉。
7. 业务到底怎么用这三样东西
也挺简单的，客服同学先看周报，快速扫一眼这周高频问题是啥、不满意的地方集中在哪。
想再细一点，就去聚类明细表，看具体的问题分布和优先级。
要是想核对用户到底是怎么说的，就去原声样本池，看脱敏后的完整会话。
Agent干的活，说白了就是把散在成千上万条消息里的问题，捞出来、理清楚、分好类，再给点处理建议。但到底要不要改产品、调规则、优化客服话术，还是得业务团队自己拍板。
这个边界得拎清：Agent是帮业务提效的工具，不是来抢业务决策权的。
8. 可复用的Agent交付检查清单
这次实践最值钱的，不是某段写得天花乱坠的prompt，是从原始数据到业务产物的完整交付链路。
要是你也在做客服记录、工单或者用户反馈的分析Agent，可以照着下面这几条自查，能少踩很多坑：
- 有没有明确必要字段，缺失的时候直接停流程？
- 原始消息有没有按会话ID聚合，而不是逐行分析？
- 是不是只给模型提供分析必需、且经过处理的字段？
- 模型输出有没有用固定结构、必填字段和枚举值？
- 程序会不会拒绝结构不合格的模型结果？
- 聚类结果能不能回溯到脱敏后的具体会话？
- 最终产物是不是直接进了业务日常用的工具？
- 写入完成后有没有稳定的验收规则？
- 输入、模型、业务工具出异常的时候，有没有明确的停止条件？
其实做客服数据分析Agent，难点真的不在选什么模型、写什么prompt。
难的是原始数据怎么接、碎消息怎么拼成完整会话、敏感信息怎么提前处理、模型输出怎么让程序能校验、最后结果怎么送到业务真正天天用的工具里。
这些环节都能稳定跑通、稳定验收了，这个Agent才算真的从演示demo，变成了能干活的交付物。
P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了