第 2.16.2 节：把 RAG、工具调用和 MCP 串成综合项目链路
RAG、工具调用和 MCP 只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够按顺序说明 RAG、工具调用和 MCP 的触发、处理、复核、记录和兜底步骤。
核心概念四层解释法
本章把关键概念按“四层解释法”串起来：人话解释、项目位置、工程动作、面试说法。
综合知识库 Agent（智能体）
人话解释：综合知识库 Agent（智能体）不是只会聊天的机器人，而是能围绕企业资料、业务工具、人工协作和质量复盘完成客服辅助工作的系统。
项目位置：在客服工作台里，它位于用户入口、知识库、业务系统、工单系统和人工客服之间。它负责判断问题类型，组织检索、工具、审批和转人工。
工程动作：你要设计需求边界、资料链路、检索链路、工具链路、工作流状态、前端呈现、权限安全、日志监控、发布验收和商业交付。
面试说法：我做的不是单纯聊天 Demo（演示），而是一个客服知识库与工单 Agent 工作台。它能把资料问答、工具查询、工单草稿、人工审批、引用追踪和质检复盘连成闭环。
RAG（检索增强生成）
人话解释：RAG（检索增强生成）是在回答前先从企业资料中找依据，再让模型基于依据回答。
项目位置：它处理客服工作台里的政策、产品、话术、流程和培训资料问题，不处理实时订单状态和写入动作。
工程动作：你要设计资料清单、解析、分块、Embedding（嵌入向量）、索引、权限过滤、重排、引用、拒答和反馈。
面试说法：RAG 在项目里是“企业资料依据层”，解决依据、引用、更新和权限，不是万能问答。
Tool Calling（工具调用）
人话解释：工具调用是让 Agent 在需要时请求业务系统执行查询或动作。
项目位置：订单查询、物流查询、工单创建、客户资料查询和投诉升级都属于工具链路。
工程动作：你要定义工具清单、输入输出、权限、审批、失败处理、幂等、审计和前端工具卡片。
面试说法：工具调用不只是调接口，还要管理业务风险。只读查询、写入动作和高风险动作要分级处理。
MCP（模型上下文协议）
人话解释：MCP（模型上下文协议）可以理解成把工具、资源和上下文用更统一的方式暴露给模型或 Agent 使用。
项目位置：当客服工作台要复用订单、工单、知识库、CRM（客户关系管理系统）等能力时，MCP 可以作为工具生态和上下文接入层。
工程动作：你要决定哪些能力适合做成 MCP Server（模型上下文协议服务端），哪些客户端可以调用，权限如何下发，日志如何统一。
面试说法：MCP 适合把工具生态标准化，但它不能替代权限、安全和业务审批。
LangGraph（智能体状态图框架）
人话解释：LangGraph（智能体状态图框架）用于把多步骤 Agent 流程做成有状态、有分支、有回退的工作流。
项目位置：客服工作台里，一个问题可能经历识别意图、检索资料、调用工具、生成草稿、等待审批、转人工和质检复盘，这种流程适合用状态图表达。
工程动作：你要定义节点、边、状态字段、停止条件、错误转移、人工接管和重试策略。
面试说法：我会用 LangGraph（智能体状态图框架）表达工作流，而不是让模型在一个 Prompt（提示词）里自由决定所有步骤。
多智能体
人话解释：多智能体不是越多越好，而是把职责不同的处理角色分开，例如资料检索、工具执行、质检复盘和主管调度。
项目位置：客服工作台可以有 Router（路由）智能体、Knowledge（知识）智能体、Tool（工具）智能体、Ticket（工单）智能体和 QA（质检）智能体，但必须有主控规则。
工程动作：你要定义每个智能体能做什么、不能做什么、交接字段是什么、冲突时谁决定、失败时谁兜底。
面试说法：我不会为了炫技堆多智能体，而会在职责真正不同、需要独立验收和日志时才拆。
Guardrail（护栏）与 Trace ID（追踪编号）
人话解释：Guardrail（护栏） 是防止系统越权、编造、泄露或执行高风险动作的规则；Trace ID（追踪编号） 是让每次请求能被追踪复盘的编号。
项目位置：客服工作台所有回答、检索、工具、审批和转人工都要有护栏和追踪编号。
工程动作：你要设计输入检查、权限过滤、敏感信息处理、拒答、审批、日志、告警和问题复盘。
面试说法：生产级 Agent 必须能解释自己为什么这样回答、调用了什么、引用了什么、谁批准了什么。
本章在客服工作台中的位置
如果把“企业客服知识库与工单 Agent 工作台”拆成 10 层，本章就是把这些层连成总图。
| 层级 | 作用 | 本章如何整合 |
|---|---|---|
| 需求访谈层 | 确认目标、角色、资料、系统和验收 | 决定项目范围和商业验收方式。 |
| 资料治理层 | 管理资料来源、负责人、版本、权限和状态 | 决定哪些资料能进入正式回答。 |
| 文档解析层 | 抽取正文、表格、图片说明和元数据 | 决定资料能否被可靠分块和引用。 |
| 检索索引层 | 分块、Embedding（嵌入向量）、索引、重排 | 决定能否找到正确依据。 |
| 问题分流层 | 判断走普通回答、RAG、工具或人工 | 防止把所有问题塞给同一条链路。 |
| 工作流编排层 | 管理多步骤状态、分支、重试和人工接管 | 用 LangGraph（智能体状态图框架）表达复杂流程。 |
| 工具生态层 | 查询订单、物流、工单、CRM（客户关系管理系统） | 用 Tool Calling（工具调用）或 MCP 接入。 |
| 多智能体协作层 | 分配检索、工具、工单、质检等职责 | 只在职责清晰时拆分。 |
| 前端工作台层 | 展示会话、引用、工具卡片、审批和日志 | 让客服能看懂并接管。 |
| 运行治理层 | 部署、监控、成本、限流、安全、发布质量 | 决定系统能否进入生产。 |
本章是第 2 卷工程实战篇的收束章。它不再深入单个技术细节，而是训练你用“总负责人”的视角组织项目。
系统流程图
下面这张图是综合知识库 Agent 的推荐总流程。它把需求、资料、检索、工具、工作流、前端、日志和验收放到一张图里。
读图重点：先读上组的需求、资料、解析、索引与发布，再读下组的意图分流；RAG 与工具路径都受依据、权限和审批约束，质检结果最终回到资料治理。
读这张图时要抓 5 个关键点：
- 资料发布在用户提问之前。没有治理过的资料不应该进入正式索引。
- 用户提问后先做身份和意图识别。不同租户、角色和会话决定可见资料和可用工具。
- RAG 只处理资料依据问题。订单、工单和写入动作要走工具或人工。
- 回答不是最终动作，可能只是
answer_draft（回答草稿），高风险场景要经过审批。 - 日志和质检会反向推动资料修正、索引重建和发布质量提升。
模块拆分
综合知识库 Agent 可以拆成 12 个模块。拆模块的目的不是让系统复杂，而是让每个模块能独立验收。
| 模块 | 负责什么 | 关键产物 | 验收方式 |
|---|---|---|---|
| 需求访谈模块 | 收集业务目标、角色、资料、接口、风险和验收口径 | 访谈纪要、范围表、验收样例草案 | 客户或项目负责人确认。 |
| 资料治理模块 | 资料清单、负责人、版本、状态、权限、发布 | 资料台账、状态流转、权限规则 | 未发布资料不能进入正式回答。 |
| 文档解析模块 | 解析 PDF（便携式文档格式）、Word（文字文档）、网页、表格和历史工单 | 标准化文本、章节结构、元数据 | 抽样资料可追溯到原文。 |
| 分块索引模块 | 分块、Embedding（嵌入向量）、索引、重建、失效 | 知识片段、索引状态、质量标记 | 检索命中能定位到资料版本和片段。 |
| 查询理解模块 | 识别租户、角色、会话、意图和风险 | query_intent（查询意图）、路由结果 | 典型问题能正确分流。 |
| RAG 模块 | 检索、重排、引用、拒答、回答草稿 | retrieval_context（检索上下文）、citation_refs（引用来源） | 答案引用正确，无依据时拒答。 |
| 工具计划模块 | 生成工具计划、检查权限、决定是否执行或审批 | tool_plan（工具计划）、工具卡片 | 工具调用可审计，高风险不自动执行。 |
| 工作流编排模块 | 管理节点、状态、分支、重试、人工接管 | workflow_state（工作流状态） | 每个流程都有停止条件和失败路径。 |
| 多智能体协作模块 | 分配知识、工具、工单、质检等职责 | 智能体职责表、交接记录 | 交接原因清楚，不互相推责。 |
| 前端工作台模块 | 会话、引用、工具计划、审批、转人工、质检 | 客服操作界面 | 客服能看懂并完成核心任务。 |
| 可观测性模块 | Trace ID（追踪编号）、耗时、成本、错误、质量评分 | 日志、看板、告警 | 问题能复盘到具体环节。 |
| 发布验收模块 | 发布检查、验收问题集、回滚、培训、维护 | 发布报告、验收记录、交接说明 | 通过约定场景后再上线。 |
面试时不要只背模块名称。你要能说明每个模块解决什么风险。例如资料治理解决“资料不可信”，工具计划解决“自动动作风险”，可观测性解决“出错不可追踪”。