- 基础
- RAG
- 编排
- 运营
功能展示： AI智能客服实战能干什么
| 你刚看到的 | 背后的机制 | 哪一章造出来 |
|---|---|---|
| 回答带引用编号，逐句可溯源 | RAG 检索 + 证据引用 | 第 3、4 章 |
| 两个工具自己串成链 | Function Calling + ReAct 循环 | 第 2、5 章 |
| 只说「它」也知道是哪一单 | 指代消解 | 第 6 章 |
| 退款先查政策再下结论 | 确定性退款子流程 | 第 5、6 章 |
| 答不上来说不知道、转人工 | 置信度闸门 + 兜底 | 第 4、5 章 |
| 弹订单列表等你点选 | LangGraph 中断与恢复 | 第 5、6 章 |
| 点踩的问题下次能答上 | 数据飞轮 | 第 9 章 |
用户：我上周买的那个蓝色耳机，想退，怎么弄？
机器人：（指代消解 → 知道是哪个订单）
（Function Calling → 调 query_order 查订单）
（ReAct 循环 → 再调 check_policy 查政策）
（确定性退款子流程 → 判断是否符合）
（RAG + 证据引用 → 回答带引用编号¹）
「根据《退货政策》第 3 条¹，您这副蓝色耳机签收 5 天，可以退。」
用户：它什么时候能到？
机器人：（指代消解 → 「它」= 蓝色耳机订单）
「预计明天送达。」
用户：我要退。
机器人：（LangGraph 中断与恢复 → 弹订单列表）
「请选择要退的订单：① 蓝色耳机 ② 充电线 ③ 耳机套」
用户：你们 CEO 是谁？
机器人：（置信度闸门 + 兜底）
「这个我不确定，帮您转人工。」
用户：（点踩）
机器人：（数据飞轮 → 进知识库，下次答对）大模型到底是个啥，它又缺了什么
缺：
- 无上下文
- 会编造
- 只会一问一答
Agent 是怎么让大模型动手干活的
| # | 代码 / 实现（第 1 列） | 概念 / 解释（第 2 列） | 对应章节（第 3 列） |
|---|---|---|---|
| 1 | client.chat.completions.create 发请求 |
LangChain 的 ChatOpenAI |
第 1 章 |
| 2 | history 列表存聊天记录 |
上下文裁剪、摘要与预算 | 第 1 章、第 7 章 |
| 3 | 手写工具清单和 query_order |
@tool 装饰器自动生成清单 |
第 2 章 |
| 4 | run_agent 里那个循环 |
LangGraph 搭的主力 Agent | 第 5 章 |
| 5 | run_workflow 里写死的步骤 |
LangGraph 的节点和分支 | 第 5 章、第 6 章 |
| 6 | try 兜住工具报错、步数上限 |
工具系统的超时、重试和审计 | 第 8 章 |
用户：我上周买的那个蓝色耳机，想退，怎么弄？
│
▼ #1 ChatOpenAI 接入 → 理解意图
▼ #3 @tool 生成的 query_order → 查订单
▼ #4 LangGraph 主力 Agent → ReAct 循环驱动
▼ #5 LangGraph 节点/分支 → 走「退款子流程」
▼ #6 超时/重试/审计 → 全程兜底
▼ #2 上下文裁剪 → 多轮对话不爆 token理论学习：LLM 接入与 Prompt 工程
prompt
- system
- user
- assistant
openai协议
prompt工程化 - 培训手册->System Prompt
- 话术库->PromptTemplate
- 工单表单->with_structured_output
- System Prompt
- 头一层是角色设定，定身份和语气；第二层圈定业务范围；更重要的是第三层行为约束。模型天性爰把话说圆说满，用户问「退款多久到账」，它顺口一句「 24 小时内一定到账」，这承诺一出口就是一张客诉单。哪些话不能说、说到什么分寸，这类红线须白纸黑字写进 system ，别指望模型自己懂。
- 不能裁剪
- PromptTemplate
- 人设立任了，再看日常话术。客服话术天然带变量真人团队的话术库就是汶么写的：亲，您的订单{订单号}已从{仓库}发出，预计{日期}送达
- with_structured_output
- json格式，不符合重试
- 流式输出
- 轮询
- WebSocket
- 最终选择SSE
- 多轮对话
- 传历史
- 裁剪
- 按轮
- 按token
实战演练：动手实现对话模块
- 功能需求
- 技术栈
- 本章不做
- 验收标准
- 工作要求
理论学习：Function Calling 与工具定义
- 工具说明书
- 三个字段各管一块： name 是工具的名字， description 告诉模型这工具是干什么的、什么时候用parameters 用 JSON Schema 描述参数长什么样。 JSON Schema 你可以理解成参数的「格式合同」类型，每个参数自己的 description 说明取值含义， required 圈出必填顶type ÄE
理论学习：RAG 原理与知识库构建
- 知识库
- 人工整理
- 客服历史对话
- 为什么分批喂
- 一是幻觉变多。上下文又长又杂，模型会分心，把不同会话的内容串味，硬凑出一条压根没出现过的问答对，这个现象有个说法叫「上下文焦虑」，材料越堆越多，模型越读越不专心。
- 另一点是准确率往下掉，这跟一个叫「Lost in the Middle」的现象有关系：喂给模型的材料排成一条长，开头结尾模型看得认真，塞在中间那部分反倒容易被一带而过，该抽的问答对没抽出来。再加上原始对话本身噪音就大，寒暄、跑题、答非所问都掺在里头，喂得越多，信噪比只会越差。
- 切分
- 切分错，文档会乱答
- 按照markdown层级感知去切
- 相似度语义切分
- Embedding
- 电商客服数据不能泄露需要开源的
理论学习：混合检索与 RRF 融合
- BM25
- Milvus
- 字面
- 语义
- 粗排精排
- 长文档中间薄弱
- 生成后核对（这里没做）
第 6 章：意图识别与对话管理
- Query改写扩写
- 意图看数据演变类目
- 对话状态追踪
- 模型升级降级
- 意图多的时候两级分类，检索式意图识别
理论学习：上下文选择与分层管理
- 历史
- 滑动窗口
- 语义检索
- 主题重要度
- 早期对话
- 截断
- 压缩
- 分层压缩
- 上下文窗口开销
理论学习：工具系统与 MCP 接入
- 写权限要限制
- 工具调不准这类问题，Anthropic 推出的「Skill」机制能大大提高工具调用准确率。它的官方示例仓库地址是https://github.com/anthropics/skills，从写文档、做设计到跑测试，各种任务的现成 Skill 都在里头。