双非转行AI Agent开发：7天掌握LangGraph、RAG与私有化部署

经常有读者问我双非院校背景没有名校光环也没有大厂实习经历现在想转行做 AI Agent 开发到底能不能入局我的答案很明确可以。大模型时代和传统互联网最大的区别在于它把很多能力门槛拉平了。以前做 NLP 需要发论文、刷榜单、调 BERT现在更多是工程化地组织和编排大模型能力。我见过不少双非背景的同学靠 LangGraph、RAG、私有化部署这一整套技能栈一样把简历写得很有竞争力。这篇文章不是要给你画一个“7 天速成大神”的饼而是想给你一条相对踏实、可执行的学习路径。我会从背景概念讲起把 LangGraph 的核心用法、RAG 知识库的完整流程、私有化部署和调优对齐这些关键环节全部串起来并且给出可以直接复制的代码和配置。无论你是刚接触 AI Agent 的零基础新手还是已经写过一些 LangChain 脚本但想往工程化方向走的开发者这篇文章都值得收藏。1. AI Agent、LangGraph、RAG、私有化部署、对齐到底是什么在动手写代码之前我建议先用 20 分钟把概念理清楚。很多人“学了三个月还是不会”不是因为不努力而是因为一直在背 API脑子里没有一个完整的全局图。1.1 AI Agent 不是 ChatBotChatBot 是一次性的问答你问一句模型答一句。AI Agent 则是一个能“自己决定下一步做什么”的程序。它通常包含 LLM、规划能力、工具调用能力和记忆能力。举一个最简单的例子你让它“帮我统计日志里最近一小时 5xx 错误的数量”Agent 会自己决定先调日志接口、再写一段统计逻辑、最后把结果整理成报告。这里面每一步都是模型在推理和选择而不是开发者提前写死的 if-else。AI Agent 的完整架构一般包含这几层层作用典型组件模型层提供推理能力大模型 API、本地模型记忆层保存短期/长期上下文LangGraph 的 checkpointer、向量库工具层连接外部系统搜索、数据库、ES、HTTP API规划层决定下一步动作ReAct、Plan-and-Execute、LangGraph 的图结构接口层暴露给用户FastAPI、WebSocket、命令行很多初学者上来就学 LangChain 的 chain其实 chain 是线性固定的而 Agent 的核心是“动态选择”。这也是 LangGraph 出现的原因它把 Agent 流程建模成一张图节点之间允许有条件跳转、循环和并行。1.2 LangGraph 与 LangChain 的区别LangGraph 是 LangChain 团队推出的一个专注于构建有状态、可编排的 Agent 应用的框架。LangChain 更强调“链”Chain是一条线串起来的固定流程LangGraph 则基于图Graph节点可以互相跳转还支持循环、分支、子图。用大白话说LangChain 是流水线LangGraph 是带红绿灯和回环的道路网。实际项目中两者并不是二选一。LangGraph 底层仍然依赖 LangChain 的模型封装、Prompt 模板和工具定义。你可以理解成LangChain 提供零部件LangGraph 负责把这些零部件拼成可控制的流程。1.3 为什么 RAG 是 Agent 落地的关键大模型的知识截止日期和隐私边界是硬伤。RAG检索增强生成就是让模型在回答之前先从外部知识库里检索相关内容再把这些内容作为上下文一起送给模型。这样至少有三个好处回答得更准确减少幻觉。可以引用出处方便人工核对。不需要重新训练模型业务知识更新成本低。Agent 嵌套 RAG 的形态叫 Agentic RAGAgent 自己判断什么时候需要检索、检索到什么程度、用哪个知识库。这种模式比“固定步骤的 RAG”灵活得多也是当前企业落地的主流形态。1.4 私有化部署和“对齐”解决什么问题调用云端大模型 API 很方便但很多企业内部数据不能出内网所以需要私有化部署。私有化部署通常有三种选型思路直接用开源模型跑推理、用模型量化工具压缩体积、用推理框架做服务化封装。“对齐”这个词听起来很学术通俗理解就是“让模型输出的风格、价值观和事实边界符合你的业务要求”。对齐有两层一是训练阶段的对齐比如 RLHF、DPO二是工程阶段的对齐比如 Prompt 约束、输出校验、敏感词过滤。对于普通团队来说工程阶段的对齐成本更低也是 7 天学习路线里最值得先掌握的部分。2. 7 天学习路线双非背景如何规划“7 天从小白到大神”这句话确实有标题党成分但如果你把范围定义成“7 天掌握 Agent 开发的核心工程链路”其实是可行的。我见过很多转行成功的案例他们共同的特点是不纠结理论先跑通最小案例再逐步扩展。下面给出的是一个偏工程向的学习路线。2.1 第 1 天大模型 API 与 Prompt 基础目标是能调通一次大模型接口并理解 Prompt 的基本结构。你可以选择任意一家大模型服务商的 API也可以用本地模型。重点不是 API 本身而是把 system、user、assistant 三层消息结构理解清楚。from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) response client.chat.completions.create( modelqwen2.5-7b, messages[ {role: system, content: 你是一个智能客服助手回答必须简洁。}, {role: user, content: 如何申请发票}, ], ) print(response.choices[0].message.content)这里我故意不写死云端地址是为了演示一个关键点只要接口兼容 OpenAI 格式你后面把 base_url 换成任意本地推理服务的地址代码都不需要大改。这就是工程上的“可替换性”。2.2 第 2 天到第 3 天LangGraph 节点、边与状态第二天建议先不看复杂的 Agent 概念只做一件事用 LangGraph 构建一个固定流程比如“接收用户输入 - 调用 LLM - 处理结果 - 返回”。第三天再升级为“有条件跳转”的图比如当用户输入包含“新增”一词时走工具调用分支否则走普通问答分支。2.3 第 4 天到第 5 天RAG 知识库RAG 是整个技能栈里性价比最高的部分文档加载、文本切块、向量化、检索、重排、引用溯源。至少要把 FAISS 或 Chroma 跑通一个。不要一开始就追 Milvus、Elasticsearch先用轻量级方案理解原理。2.4 第 6 天私有化部署这一天目标是能在本地把一个小模型跑起来并用 FastAPI 暴露成接口。对新手来说推荐路径是 llama.cpp 或 Ollama。如果你没有 GPU用 CPU 跑一个 1.5B 到 3B 的小模型做演示也完全够用。2.5 第 7 天调优与对齐把前面的模块串起来做一个完整的“本地知识库问答 Agent”再加上引用溯源、输出过滤和日志监控。这一天更接近真实项目的收尾阶段重点不是加新功能而是打磨稳定性和可观测性。3. 环境准备与版本说明为了避免你卡在环境问题上我先给出一份保守的环境清单。由于 AI 框架迭代很快本文不写死某个具体版本号而是给出“以 2025 年常见稳定版本为准”的建议。请务必根据你的实际环境调整。依赖说明操作系统Windows 10/11、Ubuntu 20.04/22.04、macOS 均可Python3.10 或 3.11建议用 pyenv 或 conda 管理LangChain / LangGraph以官方最新稳定版为准向量库FAISS、Chroma 任选其一本地推理llama.cpp、Ollama 二选一IDEVS Code 或 PyCharm建议打开 Python 虚拟环境安装核心依赖的命令如下建议在虚拟环境中执行python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install --upgrade pip pip install langgraph langchain langchain-openai langchain-community pip install faiss-cpu chromadb sentence-transformers fastapi uvicorn这段命令会安装大部分基础依赖。如果你的网络环境下载比较慢可以配置 pip 国内镜像但不要让依赖安装成为你学习的拦路虎。项目的目录结构建议如下agent-tutorial/ ├── main.py # FastAPI 入口 ├── agent/ │ ├── graph.py # LangGraph 图定义 │ ├── tools.py # 工具函数 │ └── prompts.py # Prompt 模板 ├── rag/ │ ├── loader.py # 文档加载 │ ├── splitter.py # 文本切块 │ ├── vectorstore.py # 向量库封装 │ └── retriever.py # 检索逻辑 ├── deploy/ │ └── model_server.py # 模型服务 └── data/ └── docs/ # 知识库原始文档这个结构不是官方标准但很符合中小型 Agent 项目的组织习惯把模型代理、图编排、RAG、部署分开后面调参会非常省事。4. LangGraph 实战从固定链到可控图LangGraph 是这 7 天学习路线里的核心框架所以单独拿出一章来写。我们先从状态图StateGraph的基本概念开始。4.1 StateGraph 的核心概念在 LangGraph 里你定义的数据结构叫做 State所有节点函数都接收 state 并返回更新后的部分 state。节点是真正执行逻辑的地方边则是连接节点并控制流方向。from typing import TypedDict, Annotated from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): user_input: str final_answer: strState 不要只用基础的 Python 字典建议定义 TypedDict。这样在节点函数里编辑器就能自动提示字段名降低低级拼写错误。4.2 构建第一个最小图下面这个图包含两个节点一个负责“读取用户输入”另一个负责“拼接输出”。它虽然简单但已经包含了 LangGraph 的全部核心要素状态、节点、边、起点和终点。def handle_input(state: AgentState) - AgentState: return {final_answer: f收到你的消息{state[user_input]}} def build_graph(): builder StateGraph(AgentState) builder.add_node(handle_input, handle_input) builder.add_edge(START, handle_input) builder.add_edge(handle_input, END) return builder.compile() app build_graph() result app.invoke({user_input: 你好LangGraph}) print(result[final_answer])运行结果收到你的消息你好LangGraph这个例子的意义在于让你理解LangGraph 不是黑魔法它就是一张由节点和边组成的有向图。compile()执行后的对象可以像函数一样被调用也可以部署成服务。4.3 条件路由与分支控制真实场景中Agent 不可能总是走同一条路径。比如用户输入“查一下今天的天气”Agent 应该走工具调用分支用户输入“讲个笑话”走普通问答分支就可以。条件路由就是用来解决这个问题的。from typing import Literal def route_user_input(state: AgentState) - Literal[tool_node, chat_node]: keywords [查询, 统计, 搜索, 天气] for kw in keywords: if kw in state[user_input]: return tool_node return chat_node def tool_node(state: AgentState) - AgentState: # 这里模拟工具调用实际可换成 ES、天气 API 等 return {final_answer: f[工具调用] 正在查询{state[user_input]}} def chat_node(state: AgentState) - AgentState: return {final_answer: f[普通问答] {state[user_input]}} def build_route_graph(): builder StateGraph(AgentState) builder.add_node(tool_node, tool_node) builder.add_node(chat_node, chat_node) builder.add_conditional_edges( START, route_user_input, {tool_node: tool_node, chat_node: chat_node}, ) builder.add_edge(tool_node, END) builder.add_edge(chat_node, END) return builder.compile() app build_route_graph() print(app.invoke({user_input: 帮我统计一下 nginx 错误日志})) print(app.invoke({user_input: 你好呀}))这里要特别注意add_conditional_edges的三个参数第一个是起始节点第二个是路由函数第三个是路由结果到节点名的映射。路由函数一定要写成返回字符串不要在里面写业务逻辑只做判别。4.4 循环、子图与并行分支条件路由解决的是“下一步走哪条路”循环解决的是“要不要重复某个步骤”。在很多 ReAct 风格的 Agent 里模型需要反复调用工具直到信息足够才输出最终答案。这个“反复”就是循环。LangGraph 实现循环的方式很简单把一个节点的下一个边指回当前节点或前置节点。比如builder.add_edge(tool_node, route_user_input)这样工具节点就会回到路由节点由路由节点判断是继续调用工具还是结束。为了防止死循环建议在 State 里记录调用的轮数并在路由函数里加一个最大轮数限制。子图的主要作用是复用。如果你有多个 Agent且它们共享同一个“日志查询子流程”可以把这个子流程单独定义成一张子图再在主图里作为节点引入。并行分支可以用send()或者把多个节点挂在一个节点之后LangGraph 在多个节点同时可进入时会自动并行调度。实际项目中并行分支很适合“多个知识库并行检索”这类场景。4.5 长期记忆与持久化Agent 的无状态版本在演示时没问题但真实场景中用户需要多轮对话Agent 也需要记住上一次的状态。LangGraph 的做法是引入 checkpointer把每一步的状态保存到内存、数据库或 Redis 中。from langgraph.checkpoint.memory import MemorySaver memory MemorySaver() app builder.compile(checkpointermemory) config {configurable: {thread_id: user-123}} result1 app.invoke({user_input: 我叫小明}, config) result2 app.invoke({user_input: 我叫什么名字}, config) print(result2[final_answer])thread_id在这里相当于会话 ID。不同用户用不同的 thread_id状态互不干扰。生产环境中建议把 MemorySaver 换成基于 Redis 或 Postgres 的持久化方案否则服务重启后记忆就丢了。5. RAG 知识库实战从文档到引用溯源RAG 是 Agent 落地时最常搭配的能力。这一章带你把 RAG 全链路跑通。5.1 RAG 完整流程一个标准的 RAG 流程可以分为两个阶段准备阶段离线加载文档PDF、Markdown、Word、HTML 等。切块把长文档切成小块。向量化用 Embedding 模型把文本转成向量。入库写入向量数据库。查询阶段在线把用户问题向量化。在向量库中检索 TopK 相似文本块。把检索结果拼入 Prompt。交给大模型生成答案。下面是一张文本流程图方便你对照文档 - 加载 - 切块 - 向量化 - 向量库 ^ 用户问题 - 向量化 - 检索 TopK - 拼入 Prompt - LLM - 答案5.2 文档加载与解析文档加载最容易被低估。实际项目中PDF 可能是扫描件Word 里可能带表格HTML 里有大量噪声。建议先做一层清洗再进入切块流程。from langchain_community.document_loaders import DirectoryLoader, TextLoader loader DirectoryLoader( data/docs, glob**/*.md, loader_clsTextLoader, loader_kwargs{encoding: utf-8}, ) docs loader.load() print(f加载文档数{len(docs)})5.3 切块策略切块大小直接决定检索质量。切太大检索出来噪音多切太小语义可能不完整。常用策略是按分隔符切并设置 overlap 来保留上下文。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , , ], ) chunks splitter.split_documents(docs) print(f切块数量{len(chunks)})chunk_size 不要盲目选固定值。如果文档是 FAQ 一类的短文本512 可能太大如果文档是长方案128 又可能太碎。建议先抽样看几块切分结果再确定参数。5.4 向量化与检索向量化的关键是选对 Embedding 模型。中文场景优先考虑中文语义理解较好的模型单纯用英文模型跑中文效果会差很多。本地轻量演示可以使用 sentence-transformers 支持的模型。from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, encode_kwargs{normalize_embeddings: True}, ) vectorstore FAISS.from_documents(chunks, embeddings) retriever vectorstore.as_retriever( search_typesimilarity, search_kwargs{k: 4}, )检索之后可以把结果拼接成上下文再送去生成。from langchain.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI llm ChatOpenAI( modelqwen2.5-7b, base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) prompt ChatPromptTemplate.from_messages([ (system, 你是一个知识库问答助手。只根据下面的上下文回答如果上下文没有相关信息请直接说明不知道。\n\n{context}), (human, {question}), ]) def answer(question: str): docs retriever.invoke(question) context \n\n.join([d.page_content for d in docs]) messages prompt.format_messages(contextcontext, questionquestion) response llm.invoke(messages) return response.content5.5 引用溯源与 Groundedness企业场景对 RAG 的核心要求不是“答得好”而是“答得有依据”。引用溯源就是在回答里带上知识块来源和原文片段。实现方式不复杂检索时把每个 doc 的 metadata 一起带过去生成时让模型在答案里标注来源编号。docs retriever.invoke(question) source_texts [] for i, d in enumerate(docs): source_texts.append(f[{i1}]{d.page_content}\n来源{d.metadata.get(source, 未知)}) context \n\n.join(source_texts)Groundedness 则是对“模型输出是否忠于上下文”的检测。常用做法是再跑一次 LLM让它判断回答中的每个关键结论是否都能在上下文中找到支持。这一步在生产环境可以作为独立评估模块也可以在 Agent 图里作为校验节点。6. 私有化部署把 Agent 放到内网跑起来为什么单独写私有化部署因为很多企业项目天然要求数据不出内网。你用 LangGraph、RAG 搭好业务逻辑之后最终还是需要一个本地推理服务来当模型的“发动机”。6.1 私有化部署的选型思路对于初学阶段最稳妥的路线是先在 llama.cpp 或 Ollama 上跑通一个小模型再用 OpenAI 兼容协议把它暴露给上层代码。这样上层 LangGraph 代码不需要关心你用的是云端模型还是本地模型。如果你的服务器有 NVIDIA GPU且显存在 16GB 左右可以考虑 7B 到 14B 参数量的量化模型。如果是纯 CPU 环境优先选 3B 以下的小模型重点体验流程而不是追求效果。6.2 llama.cpp 部署示例llama.cpp 的核心优势是量化推理能把大模型压缩到普通机器可接受的体积。假设你已经下载好了 GGUF 格式的模型文件启动一个兼容 OpenAI 的本地服务./llama-server \ -m ./models/qwen2.5-7b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8000 \ -c 8192参数说明-m模型文件路径。--host 0.0.0.0允许局域网访问注意控制网络安全。--port 8000服务端口。-c 8192上下文长度影响同时可输入的文本量。启动后再验证一下curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen2.5-7b, messages: [{role: user, content: 你好}]}注意私有化部署会暴露网络端口务必在防火墙层面控制访问范围不建议直接暴露到公网。如果必须对外提供服务建议在前面加一层带鉴权的网关。6.3 FastAPI 封装 Agent 服务模型服务是底层业务 Agent 一般用 FastAPI 再包一层方便给前端或其他系统调用。下面的代码把前面的 LangGraph 应用封装成一个 POST 接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleAgent Service) class QueryRequest(BaseModel): message: str user_id: str default class QueryResponse(BaseModel): answer: str app.post(/agent, response_modelQueryResponse) async def agent_endpoint(req: QueryRequest): config {configurable: {thread_id: req.user_id}} result agent_app.invoke({user_input: req.message}, config) return QueryResponse(answerresult[final_answer])启动服务uvicorn main:app --host 0.0.0.0 --port 9000这时你就有了一个“可控、可扩展、可替换模型”的 Agent 服务。上层调用方只需要发 HTTP 请求不需要关心底层是 LangGraph 还是别的框架。6.4 部署注意事项私有化部署最容易踩的坑有三个。第一个是模型显存估算不准确建议先用量化模型压测再看显存占用。第二个是上下文长度设置过长导致推理变慢需要结合实际业务调整。第三个是服务进程缺少监控模型服务一旦崩溃上层 Agent 全部不可用。至少要做进程守护和健康检查接口。7. 调优与对齐让 Agent 更稳、更可信7 天路线的最后一天我们聚焦两个目标让效果更好、让输出更安全。7.1 Prompt 调优Prompt 调优是最便宜、收益最高的手段。这里有一个核心技巧把“角色、任务、约束、输入、输出格式”写清楚不要只说“你是一个助手”。SYSTEM_PROMPT 你是企业知识库问答助手。 任务 1. 只依据提供的上下文回答用户问题。 2. 如果上下文没有答案必须回答“根据当前资料无法确认”。 3. 回答中引用上下文时使用[数字]标记来源。 输出格式 简洁的中文分点回答每条结论后标明来源编号。 实际调优时建议准备 20 到 50 个典型问题作为评测集每次改 Prompt 都跑一遍对比回答质量。不要凭感觉觉得“这次回答好像变好了”。7.2 向量检索调优RAG 效果不好时先别急着换大模型优先检查检索。可以从三个方向调提高 TopK 数量观察上下文里是否出现相关信息。切换 Embedding 模型中文场景多试几款。加入重排Rerank环节用 rerank 模型对召回结果做二次排序。重排的代码思路如下# 核心思路把检索结果交给 rerank 模型打分再取 TopN from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) pairs [(question, doc.page_content) for doc in docs] scores reranker.predict(pairs) ordered_docs [doc for _, doc in sorted(zip(scores, docs), keylambda x: x[0], reverseTrue)]7.3 模型对齐的工程化落地对齐在学术界有非常复杂的定义但工程化落地时我建议先做“输出边界控制”。具体来说在 system prompt 中明确“不要回答政治、医疗、财务建议等敏感内容”。在模型输出后加一层关键词过滤或分类器过滤。对 Agent 的工具调用权限做最小化授权禁止非必要的系统操作。如果你的目标是让模型更贴合某个垂直领域的回答风格且有一定数据可以进一步了解 DPO、LoRA 微调等手段。但这不是 7 天内能完成的建议作为第二个学习阶段的内容。7.4 评估体系调优的前提是能度量没有评估体系调优就是盲人摸象。建议从三个维度搭建简单评估维度说明评估方式准确率回答是否正确人工标注或 LLM 打分groundedness回答是否有依据检查每个结论是否能在上下文中找到拒答率不知道时是否正确拒答统计“不知道”类回答比例搭建评估集时覆盖正常问题、边界问题、敏感问题和多轮追问四类。每次调整必须跑完整评估集再上生产。8. 常见问题与排查清单学习过程中一定会遇到报错。下面这张表列了最常见的问题和排查思路建议收藏。问题现象常见原因解决思路LangGraph 节点间数据丢失State 字段没定义或返回了错误 key检查 TypedDict 字段确认节点返回的字典 key 必须存在条件路由不生效路由函数返回值和边映射不匹配检查add_conditional_edges的第三个参数 dict循环导致无限调用缺少最大轮数限制在 State 中记录轮数路由函数里加限制RAG 回答质量差切块参数不合理或检索 TopK 过少调整 chunk_size/overlap提升 TopK增加重排本地模型启动很慢CPU 推理或模型过大使用更小的量化模型减少上下文长度服务端口被占用本地已有进程占用端口更换端口或检查lsof -i :端口FastAPI 调用卡住模型推理阻塞了请求线程结合上模型服务使用异步接口或加队列引用溯源不准确metadata 丢失或拼接错误检查文档加载后的 metadata 是否保留 source 字段排查通用思路先看日志再看配置最后看代码。很多问题不是代码逻辑错了而是依赖版本不匹配。遇到奇怪报错时可以先把所有核心库升级到官方最新稳定版再重新运行。9. 最佳实践与工程建议如果你已经能跑通一个完整的 Agent RAG 项目下面这些工程建议会帮你从“能跑”走向“能上线”。9.1 配置与密钥管理不要把模型地址、API Key 写在代码里。建议用环境变量或者.env文件管理。import os from dotenv import load_dotenv load_dotenv() MODEL_BASE_URL os.getenv(MODEL_BASE_URL, http://localhost:8000/v1)这份配置在不同环境测试、预发、生产之间要能灵活切换。9.2 可观测性Agent 的决策链路比普通接口长很多日志尤其重要。至少记录以下信息用户请求和最终回答。每个节点消耗的时间。工具调用的入参和出参。检索到的文档 ID 和相关性得分。建议日志用 JSON 格式输出这样后续接入日志平台成本很低。不要只打印print。9.3 测试策略Agent 的测试不要只测接口通不通还要测“决策链路对不对”。常见的做法是单元测试测试每个节点函数、路由函数。集成测试用固定输入跑完整图断言中间 state 和最终输出。回归测试每次修改 Prompt 或图结构后跑一遍评测集。9.4 安全边界Agent 一旦能调用工具就相当于把一部分系统操作权交给了模型。务必做到工具权限最小化避免 Agent 直接操作生产数据库。在执行删除、更新类操作前必须有人工确认环节。调用外部 API 时校验返回值设置超时。私有化部署的服务端口要鉴权使用 API Key 或网关鉴权。9.5 性能优化优先级如果 Agent 响应很慢按下面的优先级排查模型推理是不是太慢考虑换更小模型或量化。检索是不是太慢向量库索引方式是否合理。是否为每轮请求重复初始化大对象比如 Embedding 模型应该全局复用。图结构是否有不必要的串行节点能并行的尽量并行。不要一上来就上微服务。单体应用把内聚模块拆好已经能覆盖绝大多数场景。10. 下一步该怎么走如果这篇文章的学习路线你都走完了恭喜你已经超过了相当一部分“只调 API”的开发者。下一步可以按自己的方向继续深入。如果你对框架底层感兴趣可以手写一个简化版 ReAct Agent深入理解工具调用和循环推理的实现。如果你对部署感兴趣可以学习 Kubernetes 下的大模型服务弹性伸缩。如果对效果优化感兴趣可以研究微调和 DPO但一定要先有充足的数据和评估集。双非背景从来不是核心障碍真正拉开差距的是“能不能把一条链路完整做出来”。我始终建议新人别贪多先把一个最小 Agent 跑通再加 RAG再加部署再谈对齐。这条路我已经见过很多人走通你也可以。