从零开始学大模型应用开发：RAG、Agent与MCP十天实战路线

如果你准备从零开始学 AI 大模型应用开发，最关心的通常不是理论，而是三件事：跑通一个真实可用的 RAG 知识库、写出能调用工具的 Agent、搞懂 MCP 怎么接。这份学习路线围绕这三件事展开，目标是用十天时间完成从调用大模型 API 到做一个完整智能助手。

和网上零散教程不同，这份路线不堆概念，而是按“基础调用 -> RAG 检索增强 -> Agent 智能体 -> MCP 工具接入”的顺序推进。每天都有明确的交付物，全部跟完后你会有一套自己的 RAG+Agent+MCP 可运行项目。整个过程不要求你有 AI 基础，但需要会一点 Python 语法，至少看得懂 import 和函数调用。

学习之前先明确：这是一条应用开发路线，不是模型训练路线。重点是把现有大模型能力接进业务系统，解决私域知识检索、多步任务拆解和外部工具联动三个问题。硬件方面弹性很大——如果只调云厂商 API，普通笔记本就够；如果想本地部署模型，再考虑 GPU 显存。文中会单独给出环境准备清单。

1. 学习路线核心能力速览

这张表基本回答了“这东西值不值得学”的问题。如果你是做后端、前端、测试、产品，或刚入行的算法同学，这条路线都能在短时间内补齐工程侧最常用的三块拼图。如果你已经有深度学习理论基础，可以直接跳到 RAG 部分。

2. 十天学习路线总览

这个节奏是按每天 2 到 3 小时有效学习时间设计的。如果你是全职投入，可以压缩到 6 天；如果每天只有 1 小时，建议拉到两周。核心不是“十天”这个数字，而是每个阶段必须留下能跑的代码，否则学完就忘。

3. 大模型 API 接入与流式输出

3.1 环境准备

无论你最后要不要本地部署，第一步都是把 Python 环境准备好。这里推荐使用 conda 或 venv 创建独立环境，避免和系统 Python 冲突。

conda create -n llm-learn python=3.10 -y conda activate llm-learn pip install requests openai python-dotenv chromadb langchain fastapi uvicorn

如果你所在网络环境访问官方 OpenAI 不稳定，可以改用国内可访问的兼容接口服务。绝大多数开源模型的在线服务都提供了 OpenAI 兼容的 endpoint，你只需要替换base_url和api_key。注意不要把 key 写死在代码里，用.env文件管理。

3.2 第一次对话：用 OpenAI SDK 调用

先跑通最基础的对话接口，确认环境、网络和密钥都没有问题。

import os from openai import OpenAI client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("LLM_BASE_URL", "https://api.openai.com/v1") ) response = client.chat.completions.create( model="gpt-4o-mini", # 按实际可用模型调整 messages=[{"role": "user", "content": "你好，请用一句话介绍大模型"}] ) print(response.choices[0].message.content)

这里model参数要改成你实际可用的模型名。如果调用失败，优先检查api_key是否正确、base_url是否可达、模型名是否匹配。这一步跑通之后，后面所有项目都基于同一个请求结构。

3.3 流式输出：让回复实时渲染

很多 AI 应用体验好，是因为回答不是等全部生成完再显示，而是像打字机一样逐字输出。实现方式就是让 HTTP 请求以 SSE（Server-Sent Events）方式接收数据流。

from openai import OpenAI client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("LLM_BASE_URL") ) stream = client.chat.completions.create( model="your-model", messages=[{"role": "user", "content": "讲一个关于RAG的技术小故事"}], stream=True, ) for chunk in stream: delta = chunk.choices[0].delta.content if delta: print(delta, end="", flush=True)

在后端，你需要把大模型返回的数据流透传给前端；在前端，用fetch读取ReadableStream，或直接用EventSource/postMessage方式渲染。如果要支持“停止生成”，前端要配合AbortController中断请求，后端则需要监听连接断开并取消上游生成任务。

const controller = new AbortController(); fetch('/api/chat', { method: 'POST', signal: controller.signal, body: JSON.stringify({ message: '你好' }) }).then(...); // 点击“停止”按钮时： controller.abort();

这里的核心逻辑是：大模型生成是一个流，不是一次返回。理解了“流”的概念，后面做 Agent、做批量任务都会轻松很多。

4. RAG 知识库实战：让模型“知道”你的私有资料

4.1 为什么需要 RAG

大模型训练数据有截止日期，而且不包含企业内部文档、个人笔记、最新产品说明书。如果直接问模型“公司报销制度是什么”，它大概率答不准。RAG（Retrieval-Augmented Generation，检索增强生成）的思路是：先把文档切碎并向量化，用户提问时先检索相关片段，再把片段和问题一起交给大模型生成答案。

RAG 能替代一部分模型微调。绝大多数知识库问答场景，用 RAG 就能解决，成本低、更新快、可追溯。它比微调更适合私域数据频繁变化的场景。

4.2 文档加载：切割与向量化

假设你手头有一份guide.txt，第一步是加载文档，然后按固定长度做切块。切块大小会直接影响检索质量，一般 300 到 800 个字符比较常用，重叠 50 到 100 字符。

from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import Chroma loader = TextLoader("docs/guide.txt", encoding="utf-8") docs = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50 ) chunks = splitter.split_documents(docs) embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = Chroma.from_documents(chunks, embeddings)

如果你不想用在线 Embedding 接口，也可以用本地模型做向量化，比如常见的开源 Embedding 模型。区别是本地推理不依赖网络，但需要占用一定的 CPU/内存或显存。向量检索这一步，Chroma 会默认持久化到本地目录，重启后仍可复用。

4.3 检索增强生成：把上下文塞进 Prompt

完成向量化之后，就能实现最核心的问答逻辑：用户输入问题 → 向量检索 TopK 相关片段 → 拼接 Prompt → 调用大模型 → 返回答案。

from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="your-model") qa = RetrievalQA.from_chain_type( llm=llm, retriever=vectorstore.as_retriever(search_kwargs={"k": 4}) ) result = qa.invoke("报销制度里提到发票类型是什么？") print(result["result"])

这个流程看起来简单，但坑主要集中在两个地方。第一是切块不合理：一个完整知识点被切散，导致检索不到。第二是检索质量差：召回的内容和问题无关，模型只能瞎猜。解决方法是不断调整chunk_size、chunk_overlap、k值，同时用一批验证问题统计检索命中率（Hit Rate）。

4.4 从 RAG 到 Agentic RAG

普通 RAG 只做一次“检索-生成”，如果知识库里没有相关信息，它不会主动换个关键词再查。Agentic RAG 则不同：检索器变成一个工具，大模型扮演 Agent，可以根据初步检索结果判断“信息够不够”，不够就改写关键词再查一次，甚至去查多个数据源。

from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.tools import tool @tool def search_kb(query: str) -> str: """从知识库检索与query相关的片段。""" docs = vectorstore.similarity_search(query, k=4) return "\n".join([d.page_content for d in docs]) agent = create_tool_calling_agent(llm, [search_kb], prompt) executor = AgentExecutor(agent=agent, tools=[search_kb]) result = executor.invoke({"input": "我们公司团建费用人均上限是多少？如果没有，请再查'活动经费'。"})

在实际项目里，Agentic RAG 比固定链路的 RAG 更适合复杂问题。但代价是模型多轮推理，耗时更长、token 消耗更多。建议优先用普通 RAG 跑通，再升级为 Agentic RAG。

5. Agent 智能体开发：让模型自主调用工具

5.1 什么是 Agent

Agent 的本质是“大模型 + 工具 + 循环”。大模型负责理解目标、拆解步骤、决定调用什么工具；工具负责执行具体动作，比如搜索、计算、发邮件、写文件。每一步执行后，模型观察工具返回结果，再决定下一步。

与固定 Prompt 不同，Agent 不需要你提前写好每一步操作。你可以告诉它“帮我整理今日待办，并写入本地文件”，它会自己决定先读待办、再写文件。这个能力来自模型在训练中习得的“推理-行动-观察”循环。

5.2 用 LangChain 创建一个能调用工具 Agent

下面这段示例展示一个最简 Agent：给模型一个summarize工具，让它根据 URL 返回摘要。实际你可以在summarize函数里写爬虫、调第三方 API 或读数据库。

from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.tools import tool @tool def summarize(url: str) -> str: """抓取网页正文并返回摘要。""" # 这里替换成你的抓取逻辑 return "示例摘要：这是一个测试地址。" llm = ChatOpenAI(model="your-model") tools = [summarize] agent = create_tool_calling_agent(llm, tools, prompt) executor = AgentExecutor(agent=agent, tools=tools) result = executor.invoke({"input": "帮我总结这个页面 https://example.com"}) print(result["output"])

@tool装饰器会把函数的 docstring 发给模型，模型凭这个描述决定何时调用该工具。所以工具名称、参数注释、返回说明要写清楚。不是随便定义一个函数就能被正确调用。

5.3 Agent 开发的常见问题

Agent 项目跑起来容易，稳定很难。你遇到最多的报错可能是 “Agent execution terminated due to error.” 这类信息，常见原因有三种：模型调用了不存在的工具名，工具返回格式不合法，或推理循环超过最大步数。

排查时先打印中间步骤：

for step in executor.iter({"input": "帮我总结这个页面 https://example.com"}): print(step)

这个循环会输出 Agent 的思考、动作和观察结果，能快速定位是哪一步卡住。另外，给模型准备的工具数量不是越多越好，工具多了决策准确率反而下降。建议先保留 3 到 5 个高价值工具。

6. MCP 协议：把外部工具统一接入大模型

6.1 MCP 是什么

MCP（Model Context Protocol，模型上下文协议）是一种开放协议，解决的是“大模型如何标准化的访问外部工具和数据源”的问题。以前每个 Agent 都要单独写插件；有了 MCP，工具提供方只需实现一个 MCP Server，任何支持 MCP 的客户端都能自动发现并调用这些工具。

从本质上看，MCP 是软件协议，属于应用层协议，类似 HTTP、WebSocket 之于网络通信。它的目标是建立大模型与外部工具之间的通用“USB-C”接口。

6.2 MCP Server 怎么配

一个常见的 MCP Server 配置会声明命令、参数和环境变量。下面是一个示例，不是某个特定服务的真实配置：

{ "mcpServers": { "fetch-tool": { "command": "python", "args": ["-m", "mcp_server_fetch"], "env": { "API_BASE_URL": "https://your-service.example.com" } } } }

不同客户端支持不同的 MCP 配置方式。有些桌面端工具直接在界面里启用“MCP 连接”，填入服务名和启动命令；有些开发框架需要在代码中注册。

from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client server_params = StdioServerParameters( command="python", args=["-m", "mcp_server_fetch"], env={"API_BASE_URL": "https://your-service.example.com"} ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: tools = await session.list_tools() for tool in tools: print(tool.name)

这段代码会连接本地启动的 MCP Server，并列出它提供的工具列表。如果你是工具提供方，只需要实现一个符合 MCP 规范的 Server，把函数暴露成 tool，你的工具就能被 MCP 客户端使用。

6.3 MCP 常见的接入场景

MCP 已经覆盖了大量常用工具，比如浏览器自动化、数据库查询、文件读写、设计工具、安全测试工具等。注意：任何 MCP Server 都拥有你授予的大模型权限，在配置时遵循最小授权原则，不要把数据库 root 账号或云平台的全局密钥放进配置。

如果你在开发中需要 MCP 客户端连接远程服务，一定要确认连接地址、鉴权方式和证书是可信的，避免把 token 泄露给未知服务。不要在生产环境直接使用示例里的 token 占位符，更不要把任何长期有效的密钥提交到公开仓库。

7. 从教程到落地：封装 API 与批量任务

7.1 用 FastAPI 封装 AI 交互逻辑

学习完前六章，你已经知道如何调用大模型、查询知识库、执行 Agent。最后一步是把这些逻辑封装成 HTTP 接口，供前端或其他系统调用。下面是一个最小实现：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class ChatRequest(BaseModel): message: str stream: bool = False @app.post("/chat") async def chat(req: ChatRequest): # 这里接入你的 RAG 或 Agent 逻辑 return {"reply": f"你说了：{req.message}"}

真实项目中，接口里应该组合“知识库检索 + 大模型生成 + 日志埋点”。还要考虑接口鉴权、限流、超时控制。尤其当流式输出时，FastAPI 需要返回StreamingResponse，而不是普通 JSON。

7.2 批量任务与失败重试

如果你的场景是离线处理一批文档或内容，不要用同步接口一个个排队。建议把任务放到队列里，用消费端批量处理，并记录每个任务的状态。

import concurrent.futures def process_one(item): # 替换成你的 RAG / Agent 调用逻辑 return item items = ["doc1.pdf", "doc2.pdf", "doc3.pdf"] with concurrent.futures.ThreadPoolExecutor(max_workers=3) as pool: results = list(pool.map(process_one, items))

批量任务最怕“一个失败全部重跑”。建议用一张数据表记录任务状态，每一步写日志。失败时先重试 2 次，仍失败则进入死信队列，人工排查。批量并发数要根据接口限流和本地资源动态调整，不是越大越好。

8. 环境准备与硬件门槛

8.1 API 模式与本地部署模式怎么选

如果你学习目标是“尽快跑通业务逻辑”，直接使用在线大模型 API 是最快路径。普通笔记本、一台云服务器就能完成，不需要关注显存。缺点是每次调用都有费用，数据要发送到第三方服务，敏感数据需要法律和合规评估。

如果你希望数据不出内网，可以选择本地部署或私有化部署。这时才需要关心 GPU 显存、推理框架和模型量化。常见做法是先选一个开源模型的中等版本，再用 GGUF/AWQ 等量化方式降低显存需求。具体占多少显存取决于模型参数规模、量化位宽和上下文长度，没有统一数字，必须按实际测试为准。

8.2 通用环境检查清单

运行nvidia-smi可以看到显卡驱动和显存使用情况。如果你没有 NVIDIA GPU，也可以用 CPU 运行小模型，只是速度慢很多，适合功能验证，不适合生产。

9. 常见问题与排查方法

排查问题的基本功是先看日志。不管是 API 客户端、Agent 框架还是 MCP Server，都会输出详细日志。不要在没有日志的情况下盲猜。

10. 最佳实践与合规使用

10.1 工程化建议

第一，先小参数测试再全量运行。第一次跑 RAG 用 1 个文档、几十条文本；第一次跑 Agent 用 1 个工具、单轮任务。确认稳定后再逐步加规模。

第二，模型文件、输入素材、输出结果分目录管理。建议项目结构类似：

project/ ├── data/ # 原始知识库文档 ├── vector_store/ # 向量库持久化文件 ├── logs/ # 运行日志 ├── output/ # 生成结果 └── app.py # API 入口

第三，所有外部服务调用都要有超时、重试和熔断。不要让一个第三方接口挂掉导致整个服务不可用。

10.2 合规与隐私边界

使用 RAG 处理内部文档时，先确认文档是否可以直接进入模型厂商的 API。涉及商业秘密或个人隐私的数据，优先考虑私有化部署或脱敏处理。

使用 Agent 调用外部工具时，只授予最小权限。例如“读取当日待办”的工具就不要带写权限。涉及浏览器自动化、网络请求时，只访问你拥有合法访问权的站点，禁止利用工具绕过登录、扫描未授权地址或抓取受限内容。

涉及他人肖像、声音、作品或版权素材时，必须获得明确授权。生成、编辑或克隆相关能力只能用于合法授权的测试与作业，不得用于传播、冒充或误导他人。

10.3 模型版本与依赖锁定

项目跑通后，建议把requirements.txt或pyproject.toml里的版本锁定，否则依赖升级可能导致接口变动、代码报错。尤其是 LangChain 这类快速迭代的框架，今天能跑的代码，三个月后可能因为 API 变更跑不起来。锁定版本是省心绕坑的重要一步。

11. 总结与下一步

这套路线最值得尝试的点，是让你在短时间内亲手拼出“大模型 + 私域知识 + 外部工具”的完整链路。第一优先验证的是最简单的 API 调用和流式输出，这决定了你后续所有功能是否能跑通。最容易踩的坑包括：模型名填错、切块不合理、工具描述太含糊、MCP 配置里混入了不该出现的密钥。

十天结束后，你至少拥有一个本地可运行的 RAG 知识库、一个能调用工具的 Agent、一套 MCP 客户端接入示例。下一步可以往三个方向扩展：一是把 RAG 的检索效果做到极致，加入重排、混合检索和评估集；二是让 Agent 接入更多真实业务工具，比如工单系统、代码仓库；三是用 MCP 统一管理这些工具，形成企业内部的 AI 工具生态。

这份学习路线建议收藏备用。今天跑通一个 API 调用，明天搭好一个知识库，一个月后你就能独立完成一个 AI 应用项目。剩下的问题只有一个——现在开始写第一行代码。