# 贯穿案例：一个知识客服如何工作

> 用同一个教学场景串起用户、知识、RAG、Agent、人工处理、评价和五类岗位。

适合阅读：希望把零散术语串成整体的读者  
更新：2026-09-05

## 先定义一个有限的服务范围

教学场景：一个课程服务提供方希望回答课程安排、资料位置和已公布的服务规则。它可以查询公开通知和授权知识，但不自动作出退款决定，也不向无权限的人展示其他学员的信息。这个场景用于解释产品链路，不是某家公司已上线系统的案例或实测结果。

用户输入可能含糊，例如“我上次的资料在哪里”。系统需要判断“上次”对应什么；缺少身份或课程信息时，先澄清比编造链接更有价值。

## 从提问到处理完成

系统先判断问题属于知识查询还是需要操作。知识查询走检索并附来源；涉及个人进度的请求需要适当身份与数据访问；需要修改记录的任务应按业务规则确认；无法回答的问题转给人工，并保留必要上下文。

| 环节 | 具体工作 | 知识连接 |
| --- | --- | --- |
| 识别与澄清 | 弄清课程、时间与问题 | 意图、对话状态、信息充分性 |
| 查找材料 | 定位有效通知与规则 | RAG、检索、版本 |
| 组织回答 | 解释并附对应依据 | 上下文、引用、事实评价 |
| 查询或执行 | 调用授权接口，确认结果 | 工具调用、参数、动作边界 |
| 人工处理 | 传递问题与已查到的材料 | 异常流程、反馈闭环 |

## 用具体失败说明协作

如果引用旧通知，运营需要检查知识更新；如果新通知已经在库但没检索到，算法和开发需要检查检索；如果接口返回失败而页面说成功，开发与产品需要检查状态表达；如果人工仍需从头问一遍，产品可以检查交接信息是否足够。

这些问题不一定需要训练新模型。改文档、改流程、改工具说明和改检索都可能影响结果。先定位环节，再决定处理方式，能避免用技术名称替代问题分析。

## 这个系统应该怎样被评价

知识问答看答案是否被当前材料支持；操作任务看动作是否在允许范围内完成；人工交接看上下文是否有效传递。还需考虑用户等待时间和单次服务成本。回答更长、模型更大或节点更多，都不能单独证明服务更好。

一个实习岗位可能只负责这条链路的一段。读 JD 时，把“维护知识库”“设计评测集”“开发 Agent”放回这里，就更容易理解具体日常，而不是把它们都理解成从零搭建整个系统。

## 参考资料与出处

- [Knowledge](https://docs.dify.ai/en/cloud/use-dify/knowledge/readme)（Dify）

- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)（Anthropic）

- [Agent 评测漫谈](https://tech.meituan.com/2026/08/07/Agent-Evaluation.html)（美团技术团队）

## 关联阅读

- [RAG：从资料到有依据的回答](https://cv.shujinxing777.com/career/handbook/rag)

- [Agent、工作流与工具调用](https://cv.shujinxing777.com/career/handbook/agents)

- [评测：让“效果好”有明确含义](https://cv.shujinxing777.com/career/handbook/evaluation)

- [AI 产品：从用户问题到产品机制](https://cv.shujinxing777.com/career/handbook/product)

- [AI 运营：用户、数据与质量](https://cv.shujinxing777.com/career/handbook/operations)