如果你准备从零开始学 AI 大模型应用开发最关心的通常不是理论而是三件事跑通一个真实可用的 RAG 知识库、写出能调用工具的 Agent、搞懂 MCP 怎么接。这份学习路线围绕这三件事展开目标是用十天时间完成从调用大模型 API 到做一个完整智能助手。和网上零散教程不同这份路线不堆概念而是按“基础调用 - RAG 检索增强 - Agent 智能体 - MCP 工具接入”的顺序推进。每天都有明确的交付物全部跟完后你会有一套自己的 RAGAgentMCP 可运行项目。整个过程不要求你有 AI 基础但需要会一点 Python 语法至少看得懂 import 和函数调用。学习之前先明确这是一条应用开发路线不是模型训练路线。重点是把现有大模型能力接进业务系统解决私域知识检索、多步任务拆解和外部工具联动三个问题。硬件方面弹性很大——如果只调云厂商 API普通笔记本就够如果想本地部署模型再考虑 GPU 显存。文中会单独给出环境准备清单。1. 学习路线核心能力速览模块说明学习目标独立完成 RAG 知识库、Agent 智能体、MCP 工具集成前置要求基础 Python 语法了解 HTTP 请求会安装依赖技术栈Python、OpenAI 兼容 API、LangChain、Chroma、FastAPI、MCP SDK硬件要求API 模式普通笔记本即可本地模型模式按模型显存要求准备 GPU是否支持本地部署支持路线中会区分 API 调用与本地推理两种情况是否涉及模型训练不涉及只做应用开发与业务集成是否提供 API 示例提供包含同步、流式输出、SSE 渲染、批量任务适合场景知识库问答、智能客服、自动化工作流、企业内部工具增强最终产出一个可对话、可检索、可调用外部工具的 AI 应用项目这张表基本回答了“这东西值不值得学”的问题。如果你是做后端、前端、测试、产品或刚入行的算法同学这条路线都能在短时间内补齐工程侧最常用的三块拼图。如果你已经有深度学习理论基础可以直接跳到 RAG 部分。2. 十天学习路线总览天数主题当天交付物第 1 天大模型基础认知与 API 调用用代码跑通一次大模型对话第 2 天提示词工程与请求参数能针对不同场景写出可用 Prompt第 3 天流式输出与交互逻辑实现类似 ChatGPT 逐字回复效果第 4 天RAG 原理与文档加载完成文档切割与向量化第 5 天向量库与检索优化能问答自己上传的 PDF/文本第 6 天Agentic RAG 与多轮检索让知识库会提问、会多轮查证第 7 天Agent 智能体基础让模型可以调用自定义工具第 8 天Agent 框架与编排完成一个多步骤任务自动执行第 9 天MCP 协议与服务端配置通过 MCP 接入浏览器/文件/数据库第 10 天接口封装与批量任务部署把整套能力封装成 API 服务这个节奏是按每天 2 到 3 小时有效学习时间设计的。如果你是全职投入可以压缩到 6 天如果每天只有 1 小时建议拉到两周。核心不是“十天”这个数字而是每个阶段必须留下能跑的代码否则学完就忘。3. 大模型 API 接入与流式输出3.1 环境准备无论你最后要不要本地部署第一步都是把 Python 环境准备好。这里推荐使用 conda 或 venv 创建独立环境避免和系统 Python 冲突。conda create -n llm-learn python3.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_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1) ) response client.chat.completions.create( modelgpt-4o-mini, # 按实际可用模型调整 messages[{role: user, content: 你好请用一句话介绍大模型}] ) print(response.choices[0].message.content)这里model参数要改成你实际可用的模型名。如果调用失败优先检查api_key是否正确、base_url是否可达、模型名是否匹配。这一步跑通之后后面所有项目都基于同一个请求结构。3.3 流式输出让回复实时渲染很多 AI 应用体验好是因为回答不是等全部生成完再显示而是像打字机一样逐字输出。实现方式就是让 HTTP 请求以 SSEServer-Sent Events方式接收数据流。from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(LLM_BASE_URL) ) stream client.chat.completions.create( modelyour-model, messages[{role: user, content: 讲一个关于RAG的技术小故事}], streamTrue, ) for chunk in stream: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)在后端你需要把大模型返回的数据流透传给前端在前端用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大模型训练数据有截止日期而且不包含企业内部文档、个人笔记、最新产品说明书。如果直接问模型“公司报销制度是什么”它大概率答不准。RAGRetrieval-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, encodingutf-8) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split_documents(docs) embeddings OpenAIEmbeddings(modeltext-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(modelyour-model) qa RetrievalQA.from_chain_type( llmllm, retrievervectorstore.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, k4) return \n.join([d.page_content for d in docs]) agent create_tool_calling_agent(llm, [search_kb], prompt) executor AgentExecutor(agentagent, tools[search_kb]) result executor.invoke({input: 我们公司团建费用人均上限是多少如果没有请再查活动经费。})在实际项目里Agentic RAG 比固定链路的 RAG 更适合复杂问题。但代价是模型多轮推理耗时更长、token 消耗更多。建议优先用普通 RAG 跑通再升级为 Agentic RAG。5. Agent 智能体开发让模型自主调用工具5.1 什么是 AgentAgent 的本质是“大模型 工具 循环”。大模型负责理解目标、拆解步骤、决定调用什么工具工具负责执行具体动作比如搜索、计算、发邮件、写文件。每一步执行后模型观察工具返回结果再决定下一步。与固定 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(modelyour-model) tools [summarize] agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools) 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 是什么MCPModel 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( commandpython, 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_workers3) as pool: results list(pool.map(process_one, items))批量任务最怕“一个失败全部重跑”。建议用一张数据表记录任务状态每一步写日志。失败时先重试 2 次仍失败则进入死信队列人工排查。批量并发数要根据接口限流和本地资源动态调整不是越大越好。8. 环境准备与硬件门槛8.1 API 模式与本地部署模式怎么选如果你学习目标是“尽快跑通业务逻辑”直接使用在线大模型 API 是最快路径。普通笔记本、一台云服务器就能完成不需要关注显存。缺点是每次调用都有费用数据要发送到第三方服务敏感数据需要法律和合规评估。如果你希望数据不出内网可以选择本地部署或私有化部署。这时才需要关心 GPU 显存、推理框架和模型量化。常见做法是先选一个开源模型的中等版本再用 GGUF/AWQ 等量化方式降低显存需求。具体占多少显存取决于模型参数规模、量化位宽和上下文长度没有统一数字必须按实际测试为准。8.2 通用环境检查清单检查项说明Python 版本建议 3.10 及以上CUDA 驱动仅本地 GPU 推理需要运行nvidia-smi查看内存API 模式 8GB 以上本地 64B 模型需要更大内存磁盘本地模型动辄 10GB 以上预留足够空间网络需要能正常访问所使用的模型 API 或镜像源端口启动 API 服务前确认端口没有被占用运行nvidia-smi可以看到显卡驱动和显存使用情况。如果你没有 NVIDIA GPU也可以用 CPU 运行小模型只是速度慢很多适合功能验证不适合生产。9. 常见问题与排查方法问题现象可能原因排查方式解决方案调用 API 报 401API Key 错误或已过期检查.env配置重新生成 Key并确认没有多余空格调用 API 报 404base_url 或模型名错误打印请求 URL对照服务商文档换成正确的 endpoint 和模型名请求超时网络波动或模型响应慢看服务端日志延长 timeout增加超时时间开启流式输出流式输出不逐字后端未透传 SSE用 curl 测试接口是否返回text/event-stream后端使用 StreamingResponse 返回RAG 答非所问切块不合理或检索 k 值太小打印检索出的文档片段调整 chunk_size、overlap、k 值Agent 不停调用工具工具描述模糊或模型选错工具打印 Agent 中间步骤精简工具列表优化工具描述MCP 连接失败启动命令错误或端口冲突看 MCP Server 日志检查命令路径、参数和环境变量批量任务卡住并发太高被限流查看接口返回状态码降低并发加入重试和超时显存不足模型太大或上下文过长运行nvidia-smi观察占用缩小模型、开启量化、降低 batch size排查问题的基本功是先看日志。不管是 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 应用项目。剩下的问题只有一个——现在开始写第一行代码。
