第 2.16.1 节：先把项目需求和资料治理边界定清楚
进入实现之前，先围绕“先把项目需求和资料治理边界定清楚”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出需求与资料治理的适用场景、不适用场景、前置条件和进入工程实现的判断标准。
本章要解决什么问题
第 2 卷前面的章节已经把工程能力逐个拆开：RAG（检索增强生成）的边界、文档解析、资料治理、分块、Embedding（嵌入向量）、索引、重排、向量数据库、MCP（模型上下文协议）、Tool Calling（工具调用）、LangGraph（智能体状态图框架）、多智能体、前端工作台、部署、可观测性、安全、发布质量和商业验收。
但真实项目不会按章节发生。客户不会说“请帮我做第 2.3 章到第 2.15 章的组合实现”。客户通常只会说：
我们资料很多，客服每天重复回答问题。能不能做一个企业知识库 Agent（智能体），能回答问题、查订单、建工单、必要时转人工？
这句话背后不是一个聊天框，而是一整套制作路线。你要先访谈需求，再判断资料是否可用；先做资料治理，再做解析、分块和索引；先决定哪些问题走 RAG，再决定哪些问题走工具调用；先把高风险动作变成草稿和审批，再考虑自动化；先定义验收问题集，再谈上线。
本章要解决的问题是：如何把第 2 卷所有工程能力整合成一个“综合知识库 Agent”的制作方法和验收总图。
请注意，本章不是可复制代码交付，也不提供可复制完整代码。它是制作路线、系统边界、字段契约、模块拆分、失败兜底和验收标准。读完本章后，你应该能把“企业客服知识库与工单 Agent 工作台”作为面试主项目讲 3 分钟，也能接受面试官围绕资料、检索、工具、权限、部署和商业验收连续追问。
学习目标
读完本章后，你应该能够：
- 用一张总图讲清企业知识库 Agent 从需求访谈到上线验收的完整流程。
- 说明综合知识库 Agent 和普通 FAQ（常见问题）、普通聊天机器人、单纯 RAG 系统的区别。
- 把需求访谈、资料治理、文档解析、分块、Embedding（嵌入向量）、索引、重排和回答引用串成一条知识链路。
- 把 RAG、工具调用、MCP、LangGraph（智能体状态图框架）和多智能体放到同一套客服工作台流程中。
- 设计前端工作台需要展示的会话、引用、工具计划、审批状态、转人工、质检和日志信息。
- 设计综合请求字段契约，覆盖
project_id（项目编号）、tenant_id（租户编号）、session_id（会话编号）、query_intent（查询意图）、retrieval_context（检索上下文）、tool_plan（工具计划）、workflow_state（工作流状态）、approval_status（审批状态）、answer_draft（回答草稿）、citation_refs（引用来源）、quality_score（质量评分）、handoff_required（是否转人工）、release_version（发布版本）和trace_id（追踪编号）。 - 说明权限、状态、日志、可观测性、安全和发布质量如何一起决定系统能不能上线。
- 准备商业验收问题集、工程检查清单和面试回答。
贯穿业务场景
本章继续使用统一贯穿项目：企业客服知识库与工单 Agent 工作台。
这套工作台服务一家中型企业。企业有外部客户、一线客服、售后运营、产品负责人、质检负责人、IT（信息技术）管理员和客服主管。企业资料包括产品说明书、售后政策、FAQ（常见问题）、客服话术、培训手册、历史工单总结和内部升级规则。企业系统包括订单系统、物流系统、工单系统、CRM（客户关系管理系统）和统一登录。
用户可能提出的问题很混杂：
| 用户问题 | 系统应该怎么处理 | 需要组合哪些能力 |
|---|---|---|
| “A 产品保修多久？” | 检索已发布产品资料和售后政策，生成带引用回答 | 资料治理、分块、Embedding（嵌入向量）、索引、重排、RAG、引用。 |
| “我的订单为什么没发货？” | 先识别为订单状态问题，再调用订单或物流工具 | 查询意图识别、工具调用、MCP、权限、日志。 |
| “帮我申请退款。” | 查询订单条件，生成工单草稿，进入人工确认或审批 | Tool Calling、LangGraph（智能体状态图框架）、审批、工单、转人工。 |
| “你们内部投诉升级规则是什么？” | 根据用户身份判断是否可见，不可见则拒答或转人工 | 租户、角色权限、资料权限、Guardrail（护栏）、审计日志。 |
| “资料里没写，但你猜我能不能赔偿？” | 不猜测，不生成公司承诺，建议人工处理 | 拒答规则、风险识别、转人工、质检复盘。 |
| “这次回答依据是哪份资料？” | 展示引用来源、版本和片段摘要 | 引用契约、前端引用面板、Trace ID（追踪编号）。 |
| “上周为什么这个问题答错了？” | 根据日志追踪检索、引用、工具、模型和审批记录 | 可观测性、日志、质量评分、发布版本。 |
这就是综合知识库 Agent 的难点：它不是一条模型调用链，而是多条链路的协作。知识问题要走 RAG，业务事实要走工具，复杂流程要用 LangGraph（智能体状态图框架）管理状态，高风险动作要审批，多角色协作要支持转人工，线上质量要靠日志、监控和发布门禁。
新手为什么会卡住
很多新手不是不会单个技术，而是不会把技术组合成可验收的系统。
| 卡点 | 表现 | 根因 | 正确处理 |
|---|---|---|---|
| 把综合项目做成聊天框 | 页面只有输入框和回答，不能上传资料、看引用、转人工或查日志 | 只理解模型交互，不理解客服工作台 | 先画业务流程和工作台状态，再决定模型放在哪里。 |
| 把 RAG 当成总入口 | 订单、退款、投诉、审批都塞进知识库问答 | 没分清资料问题和业务动作 | 先做查询意图识别，再分流到 RAG、工具或人工。 |
| 资料一上传就索引 | 旧版、草稿、内部资料和无负责人资料混在一起 | 缺少资料治理 | 资料必须有负责人、版本、状态、权限和发布流程。 |
| 工具调用缺少权限 | Agent 能随便查订单或建工单 | 把工具当接口，不把工具当业务动作 | 工具要有权限、审批、幂等、日志和失败兜底。 |
| LangGraph（智能体状态图框架）用成流程图装饰 | 只画节点，不定义状态、停止条件和失败转移 | 没理解工作流状态 | 每个节点要有输入、输出、状态变化、失败路径和人工接管。 |
| 多智能体越做越乱 | 检索智能体、工单智能体、质检智能体互相推责 | 没有主控和交接契约 | 使用 Supervisor（监督者）或明确调度规则，所有交接都记录原因。 |
| 前端看不见关键证据 | 客服只看到回答，看不到引用、工具计划和审批状态 | 前端不是工作台，只是 Demo（演示）页 | 前端要展示证据、状态、风险、下一步动作和人工操作入口。 |
| 验收只看几次聊天效果 | 客户主观觉得“不够聪明” | 没有验收问题集和质量口径 | 用场景样例、引用准确率、拒答正确率、工具成功率和日志可追溯验收。 |
综合项目最重要的能力不是“多接几个组件”，而是让每个组件有边界、有状态、有证据、有失败处理。