AI 应用核心技术栈全景指南
Prompt Engineering → RAG → 爬虫/文档处理 → MCP 智能查数
一份给实习工程师的概念串联手册
写在前面：为什么这些概念容易混淆？
你在实习中同时接触了 提示词工程 、RAG 、爬虫/文档处理 、MCP 智能查数 四个方向，发现它们之间边界模糊、经常交叉------这很正常。因为在大模型应用的完整链路中，它们分别处于不同层级，但又在实际项目中紧密配合。
本文档的目标：用一条清晰的逻辑线，把这四个技术点串成一张完整的地图，让你知道每个东西是什么、不是什么、在链路中扮演什么角色、以及它们如何在你的 ESG 项目中配合。
第一章：Prompt Engineering（提示词工程）------ 一切的基础层
1.1 定义
Prompt Engineering 是设计和优化输入给大模型的文本指令的技术，目的是让模型输出更准确、更可控、更符合预期。
它不改变模型的参数，只改变你怎么问问题。
1.2 核心技巧（来自 promptingguide.ai）
| 技巧 | 作用 | 示例 |
|---|---|---|
| Zero-shot | 直接提问，不给例子 | "总结这段文字" |
| Few-shot | 给 2-3 个例子让模型学习格式 | "问：A 公司处罚 → 答：query_punishment..." |
| Chain-of-Thought (CoT) | 让模型"一步步想" | "请先分析用户意图，再决定调用哪个工具" |
| Role Prompting | 给模型设定角色 | "你是一位 ESG 数据分析专家" |
| Output Formatting | 强制输出 JSON/XML | "请严格按以下 JSON 格式输出..." |
1.3 关键认知
Prompt Engineering 解决的是"模型怎么理解指令"的问题，不涉及任何外部数据。
它就像你跟一个聪明人说话的方式------措辞不同，结果天差地别。但不管你怎么措辞，这个聪明人脑子里装的知识是固定的（训练数据的截止时间点）。
所以 Prompt Engineering 的局限：模型不知道训练数据之后发生的事，也不知道你们公司的内部数据。
这就引出了下一个层级：RAG。
第二章：RAG（Retrieval-Augmented Generation）------ 知识层
2.1 定义
RAG（检索增强生成）是一种让大模型在回答问题时，先从外部知识库中检索相关文本，再把检索到的内容作为上下文注入 Prompt，最后生成回答的技术架构。
它解决的核心问题：模型知识过时 + 模型不知道企业内部私有数据。
2.2 RAG 的完整工作流
┌─────────────────────────────────────────────────────────────┐
│ 阶段 1：Indexing（索引构建，离线进行） │
│ │
│ 企业文档/PDF/网页 → 文本清洗 → 切分 Chunk │
│ ↓ │
│ Embedding 模型（如 text-embedding-3）→ 向量 │
│ ↓ │
│ 存入向量数据库（如 pgvector / Milvus / Chroma） │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 2：Retrieval + Generation（在线查询） │
│ │
│ 用户提问："公司环保政策有什么要求？" │
│ ↓ │
│ 问题 Embedding → 向量相似度检索 → Top-K 相关文本块 │
│ ↓ │
│ 把检索到的文本块塞进 Prompt（作为上下文） │
│ ↓ │
│ 大模型基于"原始问题 + 检索到的文本"生成回答 │
└─────────────────────────────────────────────────────────────┘2.3 RAG 的核心特征
| 特征 | 说明 |
|---|---|
| 数据类型 | 非结构化文本（PDF、Word、网页、邮件） |
| 检索方式 | 语义相似度（向量距离），不是精确匹配 |
| 结果形态 | 文本块（chunk），可能不精确 |
| 数据时效 | 依赖索引刷新频率（T+1 或定时） |
| 动作能力 | 只读，不能修改数据库或执行操作 |
| 最佳场景 | "公司制度是什么？"、"这份合同有什么条款？" |
2.4 RAG 不是什么
- ❌ 不是搜索引擎：搜索引擎返回链接列表，RAG 返回的是被塞进 Prompt 的文本块
- ❌ 不是数据库查询：RAG 查的是"语义相近"，不是"字段等于某值"
- ❌ 不能执行动作：RAG 只能给模型补充知识，不能让模型去"查数据库"或"发邮件"
2.5 一句话总结
RAG = 给模型装一个"外置记忆"，让它能引用你们公司的文档来回答知识性问题。
第三章：爬虫与文档处理 ------ 数据准备层
3.1 爬虫在链路中的位置
爬虫本身不是 RAG，也不是 MCP ，它是数据采集手段------位于整条链路的最上游，负责把互联网上的原始数据抓下来，供下游使用。
互联网数据
↓
【爬虫】抓取原始 HTML / API 响应
↓
【文档处理】清洗 → 提取结构化字段 / 切分文本 Chunk
↓
┌─────────────────┬─────────────────┐
│ │ │
▼ ▼ ▼
结构化数据 非结构化文本 混合数据
（入 PG 库） （入向量库做 RAG） （两者都做）
↓ ↓
MCP 查询 RAG 语义检索3.2 爬虫 → 结构化数据（你的 ESG 场景）
监管网站 / 12315 平台 / 环保披露网站
↓
爬虫抓取 HTML / JSON API
↓
解析提取结构化字段：
- company_name
- punish_date
- illegal_fact
- format_money
↓
存入 PostgreSQL（结构化数据库）
↓
通过 MCP 智能查数接口被 AI 调用特点：
- 数据是结构化的（字段明确）
- 查询方式是精确匹配 （
company_name = '茅台'） - 被 MCP 工具调用，不是 RAG
3.3 爬虫 → 非结构化文本（RAG 场景）
上市公司 PDF 年报 / ESG 报告 / 政策文件
↓
爬虫/下载器获取文件
↓
文档处理（OCR / 解析 / 去页眉页脚）
↓
切分 Chunk（每段 500-1000 字）
↓
Embedding → 向量数据库
↓
RAG 语义检索特点：
- 数据是非结构化的（大段文字）
- 查询方式是语义相似度（"环保违规"和"环境处罚"可能召回同一段）
- 走 RAG 链路，不走 MCP
3.4 一句话总结
爬虫和文档处理是"数据原料生产线"，它们本身不属于 RAG 或 MCP，但它们的产出决定了下游走 RAG（非结构化文本）还是 MCP（结构化数据）。
第四章：MCP 智能查数 ------ 行动层/结构化数据层
4.1 定义
MCP（Model Context Protocol）是一种标准化协议，让 AI Agent 能够发现、调用外部工具（如数据库查询、API 调用），并获取结构化结果。
你的 ESG 智能查数 MCP 属于其中的 Data Source MCP------本质上是**"AI 能调用的数据库网关"**。
4.2 MCP 的工作方式
用户："查一下茅台去年的环保处罚"
↓
Hermes（Agent）理解意图
↓
Hermes 决定调用 Tool：query_punishment
↓
Hermes 构造入参（查询条件，不是数据本身）：
{
"company_name": "茅台", ← 过滤条件
"year": 2024, ← 过滤条件
"category": "环保", ← 过滤条件
"limit": 20 ← 数量限制
}
↓
MCP Server 收到入参 → 执行 SQL / 调 API
↓
MCP Server 返回结构化 JSON（出参，这才是 ESG 数据）
↓
Hermes 把 JSON 润色成自然语言回复用户4.3 MCP 的核心特征
| 特征 | 说明 |
|---|---|
| 数据类型 | 结构化数据（数据库记录、API 响应） |
| 查询方式 | 精确条件匹配 （=、BETWEEN、IN） |
| 结果形态 | 结构化 JSON / 表格 |
| 数据时效 | 实时（每次查询直接命中数据源） |
| 动作能力 | 可读可写（查数据库、调 API、甚至执行操作） |
| 最佳场景 | "XX 公司有多少条处罚？"、"查一下排污许可" |
4.4 MCP 与 Function Calling 的关系
| 对比 | Function Calling | MCP |
|---|---|---|
| 本质 | 应用内技术机制 | 行业标准协议 |
| 工具定义 | 写在应用代码里 | 独立 Server 暴露 |
| 可移植性 | 锁定在当前应用 | 跨 Agent 复用 |
| 适用场景 | 2-3 个工具的 Demo | 企业级多工具平台 |
关系：Function Calling 是"怎么让模型调用函数"，MCP 是"怎么让这套调用机制标准化、可复用"。
4.5 一句话总结
MCP 智能查数 = 给 AI 装了一个"数据库驱动"，让 AI 能用自然语言意图去精准查询结构化数据，返回的是实时、精确的记录，不是模糊的文本块。
第五章：四者关系全景图
5.1 层级关系
┌─────────────────────────────────────────────────────────────┐
│ 第 4 层：应用交互层 │
│ 用户提问 → Agent（Hermes）理解意图 → 选择技术路径 │
└─────────────────────────────────────────────────────────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 知识性问题 │ │ 数据查询问题 │ │ 执行类问题 │
│ "制度是什么" │ │ "处罚有多少" │ │ "生成报告" │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ RAG 链路 │ │ MCP 链路 │ │ MCP 工具调用 │
│ 向量语义检索 │ │ 结构化查询 │ │ 执行操作 │
└──────────────┘ └──────────────┘ └──────────────┘
▲ ▲
│ │
┌──────┴───────┐ ┌──────┴───────┐
│ 文档处理 │ │ 爬虫/采集 │
│ 切分/Embedding│ │ 结构化入库 │
└──────────────┘ └──────────────┘
▲ ▲
└─────────────────┘
│
┌──────┴───────┐
│ 原始数据源 │
│ 网页/PDF/API │
└──────────────┘5.2 对比矩阵
| 维度 | Prompt Engineering | RAG | 爬虫/文档处理 | MCP 智能查数 |
|---|---|---|---|---|
| 解决的问题 | 模型怎么理解指令 | 模型知识不够/过时 | 数据从哪来 | 模型怎么查实时结构化数据 |
| 处理的数据 | 纯文本指令 | 非结构化文本块 | 原始网页/文件 | 结构化数据库记录 |
| 核心动作 | 写更好的 Prompt | 向量相似度检索 | 采集 + 清洗 | 精确条件查询 |
| 结果确定性 | 中（依赖模型理解） | 低（语义召回可能不准） | --- | 高（SQL 精确匹配） |
| 数据时效 | 静态（模型训练截止点） | 依赖索引刷新 | 采集时最新 | 实时 |
| 能否执行动作 | ❌ | ❌ | ❌ | ✅（查库/调 API） |
| 在链路中的位置 | 贯穿全程 | 知识检索层 | 数据准备层 | 行动/数据层 |
5.3 关键区分口诀
- Prompt Engineering：怎么问（技巧层）
- RAG：查文档（语义模糊，给模型补充知识）
- 爬虫/文档处理：准备料（数据原料生产线）
- MCP 智能查数：查数据库（精确实时，给模型提供数据）
最核心的一条分界线：
- RAG 查的是"意思相近的文本" → 非结构化、语义检索、可能不准
- MCP 查的是"符合条件的记录" → 结构化、精确匹配、实时准确
第六章：在你的实习项目中如何配合
以你们公司的 ESG 系统为例，四个技术的配合方式：
6.1 数据流全景
【数据采集层】
爬虫定时抓取：
- 监管处罚网站 → 解析结构化字段 → 存入 PG (credit_china)
- 环保披露网站 → 解析结构化字段 → 存入 PG (disclosure)
- 上市公司 PDF 报告 → 文本提取 → 切 Chunk → 存入向量库
【数据存储层】
├─ PostgreSQL：结构化表（处罚、抽检、环保、子公司...）
└─ 向量数据库：非结构化文本（报告、政策、文档）
【服务层】
├─ MCP Server：暴露 19 个 Tools，查结构化 PG 数据
└─ RAG 检索服务：查向量库，做语义问答
【应用层】
Hermes Agent（MCP Client）
↓
用户问"茅台去年环保处罚" → Hermes 调 MCP Tool → 返回 JSON
用户问"ESG 报告里环保部分怎么写" → Hermes 调 RAG → 返回文本块6.2 实际对话中的路由逻辑
用户输入
↓
Hermes 意图识别（Prompt Engineering + Few-shot 示例）
↓
┌────────────────────────────────────────┐
│ 问题类型判断： │
│ │
│ "查数据/有多少/什么时候" → MCP 路径 │
│ "怎么理解/制度是什么/如何写" → RAG 路径 │
│ "生成报告/发邮件/更新状态" → MCP 动作 │
└────────────────────────────────────────┘
↓
选择对应技术栈执行 → 返回结果 → Prompt Engineering 润色输出6.3 你的日常工作对应关系
| 你的工作 | 属于哪个技术点 | 在链路中的角色 |
|---|---|---|
| 写 Prompt 让 Hermes 正确理解用户意图 | Prompt Engineering | 控制 Agent 行为 |
| 配置 Few-shot 示例教模型选 Tool | Prompt Engineering | 提升 Tool 选择准确率 |
| 维护向量数据库里的 ESG 报告 | RAG | 知识检索基础设施 |
| 写爬虫抓监管网站数据 | 爬虫 | 数据采集 |
| 把爬下来的数据解析成结构化字段入库 | 文档处理/ETL | 数据结构化 |
| 维护 MCP Server 的 19 个 Tools | MCP | 结构化数据查询网关 |
| 优化 query_punishment 的 SQL 和参数 | MCP | 提升查询精准度 |
第七章：选型决策树
当你面对一个新需求时，按以下逻辑判断该用哪套技术：
用户问题/需求
↓
Q1: 需要外部数据才能回答吗？
├─ 否 → 纯 Prompt Engineering 即可
└─ 是 → 继续
↓
Q2: 数据是结构化（表/字段）还是非结构化（文档/文本）？
├─ 非结构化 → 走 RAG（向量语义检索）
└─ 结构化 → 继续
↓
Q3: 需要精确匹配（查某家公司某年数据）还是语义理解（找相关政策）？
├─ 语义理解 → 考虑把结构化数据文本化后走 RAG
└─ 精确匹配 → 走 MCP（结构化查询）
↓
Q4: 需要执行动作（写数据/调 API）还是只读查询？
├─ 只读查询 → MCP Tool 返回数据
└─ 执行动作 → MCP Tool 执行操作（如生成报告、发通知）典型场景对照表
| 场景 | 推荐技术 | 原因 |
|---|---|---|
| "公司考勤制度是什么？" | RAG | 查文档，语义匹配即可 |
| "茅台 2024 年有多少条处罚？" | MCP | 精确查结构化数据库 |
| "帮我写一段 ESG 报告里的环保章节" | RAG + MCP | RAG 找模板，MCP 查数据，两者结合 |
| "对比 A 和 B 公司的环保风险" | MCP × 2 | 分别查两家数据，Agent 做对比分析 |
| "这个处罚依据的是哪条法规？" | RAG | 查法规文档，语义检索 |
第八章：常见误区澄清
❌ 误区 1："爬虫抓下来的数据就是 RAG"
正解 ：爬虫只是数据采集。抓下来的数据如果结构化入库 → 走 MCP ；如果文本化向量化 → 走 RAG。爬虫本身不属于任何一层。
❌ 误区 2："MCP 查询也是检索，所以也是 RAG"
正解 ：RAG 的 R 是 Retrieval（语义检索） ，MCP 查数是 Structured Query（结构化查询）。一个是"找意思相近的文本"，一个是"找符合条件的记录"。技术路径完全不同。
❌ 误区 3："Prompt Engineering 就是写几个例子"
正解：Few-shot 只是 Prompt Engineering 的一种技巧。完整的 Prompt Engineering 还包括：角色设定、输出格式约束、Chain-of-Thought、ReAct 模式、Self-consistency 等。它是贯穿所有 AI 应用的底层能力。
❌ 误区 4："有了 MCP 就不需要 RAG 了"
正解：两者互补。MCP 解决"实时结构化数据查询"，RAG 解决"文档知识语义检索"。一个完整的 ESG 助手需要同时回答"XX 公司处罚数量"（MCP）和"ESG 报告怎么写"（RAG）。
❌ 误区 5："RAG 可以替代数据库查询"
正解 ：RAG 查向量库是模糊匹配，适合"找相关政策"，不适合"查茅台 2024 年处罚金额总和"。后者必须走结构化查询（MCP/SQL）。
附录：术语速查表
| 术语 | 一句话解释 |
|---|---|
| Prompt Engineering | 优化给大模型的指令，让它输出更准确 |
| RAG | 先从外部知识库检索相关文本，再让模型生成回答 |
| Embedding | 把文本转成高维向量，用于语义相似度计算 |
| Vector DB | 存储向量并支持相似度检索的数据库 |
| Chunk | 把长文档切分成小段，每段单独做 Embedding |
| MCP | 标准化协议，让 AI Agent 能发现和调用外部工具 |
| Tool / Function | AI 可调用的外部能力（如查数据库、调 API） |
| Function Calling | 模型输出结构化参数请求调用函数的能力 |
| Agent | 能自主规划、调用工具、完成多步骤任务的 AI 系统 |
| ReAct | 一种 Agent 模式：Reason（思考）→ Act（行动）→ Observation |
| Few-shot | 在 Prompt 里给几个例子，让模型学习格式/风格 |
| CoT | Chain-of-Thought，让模型一步步推理 |
参考资源
- Prompt Engineering Guide --- promptingguide.ai（你正在看的）
- RAG 基础论文 --- Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", 2020
- MCP 官方文档 --- modelcontextprotocol.io
- MCP vs RAG 架构对比 --- Kanerika Blog
- Context Engineering: RAG, Memory & MCP --- FutureAGI
- MCP vs Function Calling --- OpenClaw AI
- MCP vs RAG vs Function Calling 分层对比 --- Mikaeels Blog
最后的话 ：这四个技术不是互相替代的关系，而是分层协作的关系。Prompt Engineering 是贯穿全程的底层能力，爬虫/文档处理是数据原料生产线，RAG 和 MCP 是两条并行的数据消费路径------一个查文档知识，一个查结构化数据。在你的 ESG 项目中，它们共同构成了完整的 AI 数据链路。