1. 从调用API到构建Agent我的大模型应用开发学习路径2023年初我跟大多数人一样第一次接触大模型是从网页对话框开始的。输入问题等它吐出一段回答觉得挺神奇但也就仅此而已。真正让我决定深入下去的转折点是尝试用API搭了一个自动整理会议纪要的小工具——把一段会议录音转写文本丢进去让它输出结构化的待办事项和决议记录。那个小工具跑通的瞬间我意识到大模型应用开发的核心不是“跟模型聊天”而是把LLM当作一个可编程的推理引擎嵌入到业务流程里。这篇文章想聊的就是这条学习路径从最基础的API调用到RAG知识库再到Agent智能体开发中间踩过哪些坑、哪些概念一开始容易混淆、哪些工具选型走了弯路。如果你也是刚入门的开发者或者正在从传统后端/前端往AI应用方向转希望这些经验能帮你少花点时间在无效摸索上。先明确几个基础概念因为后面所有内容都建立在这些概念之上。LLMLarge Language Model大语言模型是底层模型本身比如DeepSeek、Qwen、GPT系列、Claude系列它们提供的是文本理解和生成能力。Agent是在LLM之上加了一层“自主决策工具调用”的逻辑让模型能根据任务目标自己决定下一步做什么。RAGRetrieval-Augmented Generation检索增强生成是一种让模型能“查资料再回答”的技术方案解决的是模型知识过时和幻觉问题。LangChain是目前最主流的LLM应用开发框架之一它把提示词管理、工具调用、记忆管理、检索链路这些东西做了抽象封装。这几个概念的关系可以这样理解LLM是发动机RAG是给发动机加了一套外部供油系统Agent是自动驾驶系统LangChain是造车的流水线工具。你不需要一上来就全部搞懂但心里要有个大致的地图。2. 基础阶段LLM API调用与提示词工程2.1 为什么从API调用开始而不是直接学框架我见过不少人一上来就啃LangChain文档结果被各种Chain、AgentExecutor、Runnable的概念绕晕最后连一个最简单的问答都跑不通。我的建议很明确先用最原始的方式调用一次LLM API理解请求和响应的本质。所谓API调用本质上就是发一个HTTP请求把提示词prompt传过去服务器返回模型生成的文本。以OpenAI兼容接口为例一个最基础的调用长这样from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.example.com/v1 # 兼容接口地址 ) response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个专业的会议纪要助手。}, {role: user, content: 请把以下内容整理成待办事项...} ], temperature0.3 ) print(response.choices[0].message.content)这段代码虽然简单但它包含了几个关键概念system prompt系统提示词定义模型角色和行为边界、user prompt用户输入、temperature控制输出随机性0表示最确定1表示最发散。理解这三个东西比背LangChain的API重要得多。2.2 提示词工程的核心不是“写咒语”网上有很多所谓的“提示词模板”看起来像在念咒。但实际做项目时我发现真正有效的提示词设计遵循几个朴素原则角色定义要具体不要说“你是一个助手”而要说“你是一个有10年经验的财务分析师擅长从报表中提取异常项”。输出格式要明确如果需要JSON就在提示词里给出JSON schema示例并加上“只输出JSON不要输出其他内容”。边界条件要写清楚比如“如果用户问题涉及超出你知识范围的内容直接回答‘我无法确认’”。少用否定句说“不要编造数据”不如说“所有数据必须来自用户提供的文本如果文本中没有相关信息回答‘未提及’”。我踩过的一个典型坑是早期做合同信息抽取时提示词里写了“不要遗漏任何条款”结果模型把整个合同原文都抄了一遍。后来改成“提取以下字段甲方名称、乙方名称、合同金额、签署日期。每个字段如果原文中没有填null”输出立刻稳定了。2.3 密钥安全一个容易被忽视但极其重要的问题热搜词里有一条“使用llm时如何防止密钥等鉴权信息泄露”这个问题值得单独说。我见过太多项目把API Key硬编码在前端代码里或者提交到公开仓库。一旦泄露轻则被刷爆额度重则产生高额账单。基本的安全实践包括永远不要把API Key放在客户端所有LLM调用必须经过你自己的后端服务转发。使用环境变量或密钥管理服务本地开发用.env文件并加入.gitignore生产环境用云厂商的密钥管理服务。设置额度上限和告警大多数API提供商都支持设置月度预算上限务必开启。定期轮换密钥尤其是团队协作场景人员变动后立即更换。提示如果你在GitHub上不小心提交了密钥第一时间去API提供商后台吊销该密钥然后再清理仓库历史。不要只删文件就完事历史提交里依然能查到。3. RAG知识库让模型回答它没学过的东西3.1 RAG解决的核心问题LLM有两个硬伤一是训练数据有截止日期二是它不知道你公司内部的文档。RAG的思路很直接在模型回答问题之前先从你的知识库里检索相关片段把片段作为上下文一起发给模型。这样模型就能基于你提供的资料来回答而不是靠它自己的记忆。一个完整的RAG链路包含四个环节文档加载与切分把PDF、Word、网页等格式的文档转成纯文本再切成合适大小的片段chunk。向量化与存储用embedding模型把每个片段转成向量存入向量数据库。检索用户提问时把问题也转成向量在数据库中找最相似的片段。生成把检索到的片段和用户问题一起组装成提示词发给LLM生成回答。3.2 文档切分最容易被低估的环节很多人做RAG效果不好第一反应是换embedding模型或换向量数据库但实际上切分策略往往才是瓶颈。我做过一个内部技术文档的RAG项目最初按固定500字符切分结果检索出来的片段经常从句子中间断开模型理解起来很吃力。后来调整了策略按语义边界切分优先在段落、标题、代码块边界处切分而不是硬按字符数。设置重叠区域相邻片段之间保留10%-20%的重叠内容避免关键信息被切断。控制片段大小中文场景下300-800字是一个比较合理的范围。太短信息不足太长检索精度下降。保留元数据每个片段要带上来源文档名、章节标题、页码等信息方便后续引用和溯源。LangChain提供了RecursiveCharacterTextSplitter可以按优先级依次尝试用不同分隔符切分基本能满足大部分场景。但如果你处理的是结构化很强的文档比如法律合同、技术规范建议自己写切分逻辑按条款编号或章节结构来切。3.3 向量数据库选型不要过度设计向量数据库的选择上我的建议是从简到繁。个人项目或中小规模知识库几万条片段以内直接用Chroma或FAISS就够了本地跑零运维成本。团队协作或生产环境可以考虑Milvus、Qdrant、Weaviate这些支持分布式部署的方案。方案适用场景优势注意事项Chroma个人项目、原型验证轻量、Python原生、零配置大规模数据性能下降明显FAISS本地高性能检索Facebook出品、检索速度快不支持增删改需全量重建Milvus生产环境、大规模分布式、支持多种索引部署运维复杂度较高Qdrant中小规模生产Rust编写、性能好、API友好生态相对年轻pgvector已有PostgreSQL无需额外组件、事务支持超大规模性能不如专用方案我自己的习惯是原型阶段用Chroma验证效果后再根据数据量和并发需求决定是否迁移。3.4 检索策略从朴素检索到混合检索最基础的检索是向量相似度检索但实际用下来纯向量检索有几个问题对关键词精确匹配不敏感对数字和专有名词容易出错。比如用户问“RX6750GRE能跑什么模型”向量检索可能返回一堆泛泛的显卡对比内容而不是针对这个具体型号的信息。改进方案是混合检索把向量检索和关键词检索BM25的结果融合取长补短。LangChain的EnsembleRetriever就支持这种模式。另外还可以加一层重排序rerank用一个专门的rerank模型对初步检索结果做精排通常能显著提升Top-3的命中率。还有一个进阶玩法是Agentic RAG让Agent自己决定要不要检索、检索什么、检索几次。比如用户问一个简单的事实性问题Agent可以直接回答问一个需要多步推理的问题Agent可以先检索再推理再检索。这种模式比固定链路灵活得多但实现复杂度也更高。4. Agent开发从“问答”到“做事”4.1 Agent和LLM的本质区别LLM是被动的你给它输入它给你输出。Agent是主动的你给它一个目标它自己规划步骤、调用工具、检查结果、调整策略。举个例子你说“帮我查一下明天北京的天气如果下雨就提醒我带伞”LLM只能告诉你“我无法查询实时天气”而Agent会调用天气API、判断结果、再决定是否输出提醒。Agent的核心组件包括规划能力把复杂任务拆解成可执行的步骤。工具调用通过function calling或tool use机制调用外部API、数据库、代码执行器等。记忆管理记住对话历史和中间结果避免重复劳动。反思与纠错检查自己的输出是否合理发现问题后重新尝试。4.2 LangChain Agent的入门与避坑LangChain的Agent模块经历了多次迭代从早期的AgentExecutor到现在的LangGraphAPI变化很大。新手最容易困惑的是LangChain和LangGraph到底什么关系简单说LangChain是基础框架提供了LLM调用、提示词模板、工具定义、检索器等组件。LangGraph是在LangChain之上构建的状态机框架专门用于编排复杂的Agent流程。如果你只是做一个简单的“提问-检索-回答”链路LangChain的Chain就够了。如果你需要多轮工具调用、条件分支、循环重试LangGraph会更合适。一个最基础的LangChain Agent示例from langchain.agents import create_openai_tools_agent, AgentExecutor from langchain_openai import ChatOpenAI from langchain.tools import tool tool def query_database(sql: str) - str: 执行SQL查询并返回结果 # 实际项目中这里连接你的数据库 return 查询结果... tool def send_email(to: str, subject: str, body: str) - str: 发送邮件 return f邮件已发送至{to} llm ChatOpenAI(modelgpt-4, temperature0) tools [query_database, send_email] agent create_openai_tools_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) result executor.invoke({input: 查询上个月销售额然后发邮件给老板})这段代码看起来简单但实际跑起来会遇到不少问题。我踩过的坑包括工具描述写得太模糊导致Agent选错工具、工具返回结果太长导致上下文溢出、Agent陷入循环反复调用同一个工具。这些问题后面会专门讲排查方法。4.3 工具设计的几个关键原则Agent的能力上限很大程度上取决于你给它什么工具。工具设计有几个原则工具描述要像API文档一样清晰说明这个工具做什么、什么时候用、参数是什么格式。Agent是根据描述来决定调用的描述模糊它就会乱调。工具粒度要适中太细会导致Agent需要调用很多次才能完成一个任务太粗则灵活性不足。比如“查询订单”和“修改订单状态”应该分开但“查询订单”不需要再拆成“按ID查”和“按用户查”。工具要能处理错误不要假设输入永远正确工具内部要做好参数校验和异常处理返回有意义的错误信息这样Agent才能根据错误调整策略。控制返回结果长度如果工具返回大量数据要做截断或摘要否则会撑爆上下文窗口。4.4 记忆管理短期记忆与长期记忆Agent需要记住对话历史才能进行多轮交互。LangChain提供了多种记忆方案ConversationBufferMemory简单粗暴地保存所有对话历史适合短对话。ConversationSummaryMemory用LLM对历史对话做摘要节省token但可能丢失细节。ConversationBufferWindowMemory只保留最近N轮对话简单有效。实际项目中我通常组合使用短期用BufferWindow保留最近几轮长期用向量数据库存储关键信息需要时检索出来。这样既能控制上下文长度又不会丢失重要信息。5. 常见问题与排查技巧实录5.1 LLM返回JSON格式不稳定怎么办这是热搜词里提到的问题也是我遇到频率最高的问题之一。模型有时候返回纯JSON有时候在JSON外面包一层json有时候加一段解释文字。解决方案分几个层次提示词层面明确要求“只输出JSON不要有任何其他文字”并给出完整的JSON schema示例。API层面如果模型支持开启JSON mode或structured output功能。代码层面写一个健壮的解析函数先尝试直接解析失败后尝试提取JSON子串再失败则用正则匹配。Java生态里可以用Jackson的ObjectMapper配合自定义反序列化逻辑Python里可以用json.loads配合异常处理。import json import re def parse_llm_json(text: str) - dict: # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 尝试提取代码块中的JSON match re.search(r(?:json)?\s*([\s\S]*?), text) if match: try: return json.loads(match.group(1)) except json.JSONDecodeError: pass # 尝试提取第一个完整的JSON对象 match re.search(r\{[\s\S]*\}, text) if match: try: return json.loads(match.group(0)) except json.JSONDecodeError: pass raise ValueError(f无法从LLM输出中解析JSON: {text[:200]})5.2 Agent陷入循环或选错工具Agent循环调用同一个工具通常是因为工具返回的结果没有让Agent满意它以为再调一次会不一样。排查思路检查工具返回结果是否包含足够的信息让Agent判断下一步。在提示词里加入“如果工具返回结果为空或错误不要重复调用尝试其他方案”。设置最大迭代次数超过后强制停止并返回当前结果。Agent选错工具通常是工具描述不够清晰。我习惯在工具描述里加上“使用场景”和“不适用场景”比如“当用户询问订单状态时使用此工具不要用于查询用户信息”。5.3 RAG检索结果不相关检索不相关的原因可能出在切分、embedding、检索策略任何一个环节。排查顺序先看切分后的片段是否语义完整有没有从中间断开的。手动拿几个典型问题去检索看Top-5结果是否相关。如果向量检索效果差尝试加入BM25混合检索。如果还是不行考虑换embedding模型或者加入rerank层。5.4 本地部署大模型的硬件门槛热搜词里有人问“RX6750GRE训练大模型”和“AI大模型本地部署配置”。这里要区分推理和训练推理对硬件要求低得多训练则需要大显存GPU。任务类型最低显存推荐配置可运行模型示例推理量化6-8GB12-16GB7B量化模型推理FP1614-16GB24GB7B-13B模型微调LoRA16-24GB24-48GB7B-13B模型全量微调80GB多卡A100/H1007B以上模型RX6750GRE 12GB显存可以跑7B量化模型的推理但训练基本不现实。如果只是想本地体验用Ollama或llama.cpp跑量化模型是最省心的方案。5.5 常见问题速查表问题现象可能原因排查方向LLM输出截断max_tokens设置过小增大max_tokens或让模型分段输出检索结果不相关切分粒度不当/embedding模型不匹配调整切分策略、换embedding模型Agent不调用工具工具描述不清晰/提示词缺少引导优化工具描述、在system prompt中强调工具使用响应速度慢模型太大/检索链路太长换小模型、加缓存、并行化检索密钥泄露风险硬编码/前端暴露后端转发、环境变量、密钥轮换上下文溢出历史对话太长/工具返回太长加摘要、截断、滑动窗口6. 学习路线与工具选型建议6.1 一条可落地的学习路线如果你现在从零开始我建议按这个顺序推进第一阶段1-2周搞定API调用和提示词工程。用一个简单的场景练手比如做一个自动回复邮件的小工具。重点理解system prompt、temperature、max_tokens这些参数的实际影响。第二阶段2-3周入门RAG。用LangChain加Chroma搭一个本地知识库问答文档就用你自己的技术笔记或产品手册。重点掌握文档切分、embedding、检索这三个环节。第三阶段3-4周Agent开发。从简单的工具调用开始做一个能查数据库、能发邮件的Agent。然后逐步加入多轮对话、错误处理、记忆管理。第四阶段持续深入某个方向。可以是Agentic RAG、多Agent协作、模型微调、或者特定行业的应用落地。这个阶段没有标准答案取决于你的实际需求。6.2 工具选型不要追新够用就好LLM应用开发领域工具迭代极快今天出的框架明天可能就过时了。我的建议是LLM调用LangChain或直接使用官方SDK。LangChain的优势是抽象统一切换模型方便劣势是版本更新快API不稳定。如果项目简单直接用官方SDK更可控。RAG框架LangChain、LlamaIndex、Dify。LangChain最灵活LlamaIndex对检索场景优化更好Dify适合快速搭建原型。Agent框架LangGraph、AutoGen、CrewAI。LangGraph适合复杂流程编排AutoGen适合多Agent对话CrewAI适合角色分工明确的场景。向量数据库Chroma原型、Qdrant/Milvus生产。本地部署Ollama最简单、llama.cpp最轻量、vLLM高性能推理。6.3 关于LangChain和LangGraph的选择这是热搜词里反复出现的问题。我的判断标准很简单如果你的流程可以用一个有向无环图表示用LangChain的Chain就够了。如果需要循环、条件分支、动态决策用LangGraph。举个例子一个“用户提问-检索-生成回答”的RAG链路用LangChain的RetrievalQA就能搞定。但如果你要做“用户提问-Agent判断是否需要检索-如果需要则检索-判断检索结果是否充分-不充分则换关键词再检索-充分则生成回答”这种带循环和条件判断的流程LangGraph会更合适。6.4 我个人的一些经验体会做了这么多项目最大的感受是大模型应用开发的核心竞争力不在模型本身而在工程能力。模型能力是公共的但如何设计提示词、如何切分文档、如何编排Agent流程、如何处理异常情况这些才是区分项目质量的关键。另一个体会是不要追求一步到位。我见过太多人想直接做一个“全能Agent”结果连基础的RAG都没跑通。正确的做法是从小场景切入先跑通一个最小闭环再逐步叠加能力。最后保持动手。这个领域变化太快看再多文章不如自己跑一遍代码。遇到问题先查文档再搜社区最后自己调试。很多时候一个报错信息就能让你学到比十篇文章更多的东西。后续如果要做扩展可以考虑的方向包括多模态RAG支持图片和表格检索、Agent协作多个Agent分工完成复杂任务、模型微调用领域数据提升特定任务表现、以及性能优化缓存、并行、流式输出。这些方向每一个都值得单独写一篇但前提是你已经把基础链路跑通了。 从LLM API到Agent智能体：大模型应用开发学习路径与实战避坑指南
1. 从调用API到构建Agent我的大模型应用开发学习路径2023年初我跟大多数人一样第一次接触大模型是从网页对话框开始的。输入问题等它吐出一段回答觉得挺神奇但也就仅此而已。真正让我决定深入下去的转折点是尝试用API搭了一个自动整理会议纪要的小工具——把一段会议录音转写文本丢进去让它输出结构化的待办事项和决议记录。那个小工具跑通的瞬间我意识到大模型应用开发的核心不是“跟模型聊天”而是把LLM当作一个可编程的推理引擎嵌入到业务流程里。这篇文章想聊的就是这条学习路径从最基础的API调用到RAG知识库再到Agent智能体开发中间踩过哪些坑、哪些概念一开始容易混淆、哪些工具选型走了弯路。如果你也是刚入门的开发者或者正在从传统后端/前端往AI应用方向转希望这些经验能帮你少花点时间在无效摸索上。先明确几个基础概念因为后面所有内容都建立在这些概念之上。LLMLarge Language Model大语言模型是底层模型本身比如DeepSeek、Qwen、GPT系列、Claude系列它们提供的是文本理解和生成能力。Agent是在LLM之上加了一层“自主决策工具调用”的逻辑让模型能根据任务目标自己决定下一步做什么。RAGRetrieval-Augmented Generation检索增强生成是一种让模型能“查资料再回答”的技术方案解决的是模型知识过时和幻觉问题。LangChain是目前最主流的LLM应用开发框架之一它把提示词管理、工具调用、记忆管理、检索链路这些东西做了抽象封装。这几个概念的关系可以这样理解LLM是发动机RAG是给发动机加了一套外部供油系统Agent是自动驾驶系统LangChain是造车的流水线工具。你不需要一上来就全部搞懂但心里要有个大致的地图。2. 基础阶段LLM API调用与提示词工程2.1 为什么从API调用开始而不是直接学框架我见过不少人一上来就啃LangChain文档结果被各种Chain、AgentExecutor、Runnable的概念绕晕最后连一个最简单的问答都跑不通。我的建议很明确先用最原始的方式调用一次LLM API理解请求和响应的本质。所谓API调用本质上就是发一个HTTP请求把提示词prompt传过去服务器返回模型生成的文本。以OpenAI兼容接口为例一个最基础的调用长这样from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.example.com/v1 # 兼容接口地址 ) response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个专业的会议纪要助手。}, {role: user, content: 请把以下内容整理成待办事项...} ], temperature0.3 ) print(response.choices[0].message.content)这段代码虽然简单但它包含了几个关键概念system prompt系统提示词定义模型角色和行为边界、user prompt用户输入、temperature控制输出随机性0表示最确定1表示最发散。理解这三个东西比背LangChain的API重要得多。2.2 提示词工程的核心不是“写咒语”网上有很多所谓的“提示词模板”看起来像在念咒。但实际做项目时我发现真正有效的提示词设计遵循几个朴素原则角色定义要具体不要说“你是一个助手”而要说“你是一个有10年经验的财务分析师擅长从报表中提取异常项”。输出格式要明确如果需要JSON就在提示词里给出JSON schema示例并加上“只输出JSON不要输出其他内容”。边界条件要写清楚比如“如果用户问题涉及超出你知识范围的内容直接回答‘我无法确认’”。少用否定句说“不要编造数据”不如说“所有数据必须来自用户提供的文本如果文本中没有相关信息回答‘未提及’”。我踩过的一个典型坑是早期做合同信息抽取时提示词里写了“不要遗漏任何条款”结果模型把整个合同原文都抄了一遍。后来改成“提取以下字段甲方名称、乙方名称、合同金额、签署日期。每个字段如果原文中没有填null”输出立刻稳定了。2.3 密钥安全一个容易被忽视但极其重要的问题热搜词里有一条“使用llm时如何防止密钥等鉴权信息泄露”这个问题值得单独说。我见过太多项目把API Key硬编码在前端代码里或者提交到公开仓库。一旦泄露轻则被刷爆额度重则产生高额账单。基本的安全实践包括永远不要把API Key放在客户端所有LLM调用必须经过你自己的后端服务转发。使用环境变量或密钥管理服务本地开发用.env文件并加入.gitignore生产环境用云厂商的密钥管理服务。设置额度上限和告警大多数API提供商都支持设置月度预算上限务必开启。定期轮换密钥尤其是团队协作场景人员变动后立即更换。提示如果你在GitHub上不小心提交了密钥第一时间去API提供商后台吊销该密钥然后再清理仓库历史。不要只删文件就完事历史提交里依然能查到。3. RAG知识库让模型回答它没学过的东西3.1 RAG解决的核心问题LLM有两个硬伤一是训练数据有截止日期二是它不知道你公司内部的文档。RAG的思路很直接在模型回答问题之前先从你的知识库里检索相关片段把片段作为上下文一起发给模型。这样模型就能基于你提供的资料来回答而不是靠它自己的记忆。一个完整的RAG链路包含四个环节文档加载与切分把PDF、Word、网页等格式的文档转成纯文本再切成合适大小的片段chunk。向量化与存储用embedding模型把每个片段转成向量存入向量数据库。检索用户提问时把问题也转成向量在数据库中找最相似的片段。生成把检索到的片段和用户问题一起组装成提示词发给LLM生成回答。3.2 文档切分最容易被低估的环节很多人做RAG效果不好第一反应是换embedding模型或换向量数据库但实际上切分策略往往才是瓶颈。我做过一个内部技术文档的RAG项目最初按固定500字符切分结果检索出来的片段经常从句子中间断开模型理解起来很吃力。后来调整了策略按语义边界切分优先在段落、标题、代码块边界处切分而不是硬按字符数。设置重叠区域相邻片段之间保留10%-20%的重叠内容避免关键信息被切断。控制片段大小中文场景下300-800字是一个比较合理的范围。太短信息不足太长检索精度下降。保留元数据每个片段要带上来源文档名、章节标题、页码等信息方便后续引用和溯源。LangChain提供了RecursiveCharacterTextSplitter可以按优先级依次尝试用不同分隔符切分基本能满足大部分场景。但如果你处理的是结构化很强的文档比如法律合同、技术规范建议自己写切分逻辑按条款编号或章节结构来切。3.3 向量数据库选型不要过度设计向量数据库的选择上我的建议是从简到繁。个人项目或中小规模知识库几万条片段以内直接用Chroma或FAISS就够了本地跑零运维成本。团队协作或生产环境可以考虑Milvus、Qdrant、Weaviate这些支持分布式部署的方案。方案适用场景优势注意事项Chroma个人项目、原型验证轻量、Python原生、零配置大规模数据性能下降明显FAISS本地高性能检索Facebook出品、检索速度快不支持增删改需全量重建Milvus生产环境、大规模分布式、支持多种索引部署运维复杂度较高Qdrant中小规模生产Rust编写、性能好、API友好生态相对年轻pgvector已有PostgreSQL无需额外组件、事务支持超大规模性能不如专用方案我自己的习惯是原型阶段用Chroma验证效果后再根据数据量和并发需求决定是否迁移。3.4 检索策略从朴素检索到混合检索最基础的检索是向量相似度检索但实际用下来纯向量检索有几个问题对关键词精确匹配不敏感对数字和专有名词容易出错。比如用户问“RX6750GRE能跑什么模型”向量检索可能返回一堆泛泛的显卡对比内容而不是针对这个具体型号的信息。改进方案是混合检索把向量检索和关键词检索BM25的结果融合取长补短。LangChain的EnsembleRetriever就支持这种模式。另外还可以加一层重排序rerank用一个专门的rerank模型对初步检索结果做精排通常能显著提升Top-3的命中率。还有一个进阶玩法是Agentic RAG让Agent自己决定要不要检索、检索什么、检索几次。比如用户问一个简单的事实性问题Agent可以直接回答问一个需要多步推理的问题Agent可以先检索再推理再检索。这种模式比固定链路灵活得多但实现复杂度也更高。4. Agent开发从“问答”到“做事”4.1 Agent和LLM的本质区别LLM是被动的你给它输入它给你输出。Agent是主动的你给它一个目标它自己规划步骤、调用工具、检查结果、调整策略。举个例子你说“帮我查一下明天北京的天气如果下雨就提醒我带伞”LLM只能告诉你“我无法查询实时天气”而Agent会调用天气API、判断结果、再决定是否输出提醒。Agent的核心组件包括规划能力把复杂任务拆解成可执行的步骤。工具调用通过function calling或tool use机制调用外部API、数据库、代码执行器等。记忆管理记住对话历史和中间结果避免重复劳动。反思与纠错检查自己的输出是否合理发现问题后重新尝试。4.2 LangChain Agent的入门与避坑LangChain的Agent模块经历了多次迭代从早期的AgentExecutor到现在的LangGraphAPI变化很大。新手最容易困惑的是LangChain和LangGraph到底什么关系简单说LangChain是基础框架提供了LLM调用、提示词模板、工具定义、检索器等组件。LangGraph是在LangChain之上构建的状态机框架专门用于编排复杂的Agent流程。如果你只是做一个简单的“提问-检索-回答”链路LangChain的Chain就够了。如果你需要多轮工具调用、条件分支、循环重试LangGraph会更合适。一个最基础的LangChain Agent示例from langchain.agents import create_openai_tools_agent, AgentExecutor from langchain_openai import ChatOpenAI from langchain.tools import tool tool def query_database(sql: str) - str: 执行SQL查询并返回结果 # 实际项目中这里连接你的数据库 return 查询结果... tool def send_email(to: str, subject: str, body: str) - str: 发送邮件 return f邮件已发送至{to} llm ChatOpenAI(modelgpt-4, temperature0) tools [query_database, send_email] agent create_openai_tools_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) result executor.invoke({input: 查询上个月销售额然后发邮件给老板})这段代码看起来简单但实际跑起来会遇到不少问题。我踩过的坑包括工具描述写得太模糊导致Agent选错工具、工具返回结果太长导致上下文溢出、Agent陷入循环反复调用同一个工具。这些问题后面会专门讲排查方法。4.3 工具设计的几个关键原则Agent的能力上限很大程度上取决于你给它什么工具。工具设计有几个原则工具描述要像API文档一样清晰说明这个工具做什么、什么时候用、参数是什么格式。Agent是根据描述来决定调用的描述模糊它就会乱调。工具粒度要适中太细会导致Agent需要调用很多次才能完成一个任务太粗则灵活性不足。比如“查询订单”和“修改订单状态”应该分开但“查询订单”不需要再拆成“按ID查”和“按用户查”。工具要能处理错误不要假设输入永远正确工具内部要做好参数校验和异常处理返回有意义的错误信息这样Agent才能根据错误调整策略。控制返回结果长度如果工具返回大量数据要做截断或摘要否则会撑爆上下文窗口。4.4 记忆管理短期记忆与长期记忆Agent需要记住对话历史才能进行多轮交互。LangChain提供了多种记忆方案ConversationBufferMemory简单粗暴地保存所有对话历史适合短对话。ConversationSummaryMemory用LLM对历史对话做摘要节省token但可能丢失细节。ConversationBufferWindowMemory只保留最近N轮对话简单有效。实际项目中我通常组合使用短期用BufferWindow保留最近几轮长期用向量数据库存储关键信息需要时检索出来。这样既能控制上下文长度又不会丢失重要信息。5. 常见问题与排查技巧实录5.1 LLM返回JSON格式不稳定怎么办这是热搜词里提到的问题也是我遇到频率最高的问题之一。模型有时候返回纯JSON有时候在JSON外面包一层json有时候加一段解释文字。解决方案分几个层次提示词层面明确要求“只输出JSON不要有任何其他文字”并给出完整的JSON schema示例。API层面如果模型支持开启JSON mode或structured output功能。代码层面写一个健壮的解析函数先尝试直接解析失败后尝试提取JSON子串再失败则用正则匹配。Java生态里可以用Jackson的ObjectMapper配合自定义反序列化逻辑Python里可以用json.loads配合异常处理。import json import re def parse_llm_json(text: str) - dict: # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 尝试提取代码块中的JSON match re.search(r(?:json)?\s*([\s\S]*?), text) if match: try: return json.loads(match.group(1)) except json.JSONDecodeError: pass # 尝试提取第一个完整的JSON对象 match re.search(r\{[\s\S]*\}, text) if match: try: return json.loads(match.group(0)) except json.JSONDecodeError: pass raise ValueError(f无法从LLM输出中解析JSON: {text[:200]})5.2 Agent陷入循环或选错工具Agent循环调用同一个工具通常是因为工具返回的结果没有让Agent满意它以为再调一次会不一样。排查思路检查工具返回结果是否包含足够的信息让Agent判断下一步。在提示词里加入“如果工具返回结果为空或错误不要重复调用尝试其他方案”。设置最大迭代次数超过后强制停止并返回当前结果。Agent选错工具通常是工具描述不够清晰。我习惯在工具描述里加上“使用场景”和“不适用场景”比如“当用户询问订单状态时使用此工具不要用于查询用户信息”。5.3 RAG检索结果不相关检索不相关的原因可能出在切分、embedding、检索策略任何一个环节。排查顺序先看切分后的片段是否语义完整有没有从中间断开的。手动拿几个典型问题去检索看Top-5结果是否相关。如果向量检索效果差尝试加入BM25混合检索。如果还是不行考虑换embedding模型或者加入rerank层。5.4 本地部署大模型的硬件门槛热搜词里有人问“RX6750GRE训练大模型”和“AI大模型本地部署配置”。这里要区分推理和训练推理对硬件要求低得多训练则需要大显存GPU。任务类型最低显存推荐配置可运行模型示例推理量化6-8GB12-16GB7B量化模型推理FP1614-16GB24GB7B-13B模型微调LoRA16-24GB24-48GB7B-13B模型全量微调80GB多卡A100/H1007B以上模型RX6750GRE 12GB显存可以跑7B量化模型的推理但训练基本不现实。如果只是想本地体验用Ollama或llama.cpp跑量化模型是最省心的方案。5.5 常见问题速查表问题现象可能原因排查方向LLM输出截断max_tokens设置过小增大max_tokens或让模型分段输出检索结果不相关切分粒度不当/embedding模型不匹配调整切分策略、换embedding模型Agent不调用工具工具描述不清晰/提示词缺少引导优化工具描述、在system prompt中强调工具使用响应速度慢模型太大/检索链路太长换小模型、加缓存、并行化检索密钥泄露风险硬编码/前端暴露后端转发、环境变量、密钥轮换上下文溢出历史对话太长/工具返回太长加摘要、截断、滑动窗口6. 学习路线与工具选型建议6.1 一条可落地的学习路线如果你现在从零开始我建议按这个顺序推进第一阶段1-2周搞定API调用和提示词工程。用一个简单的场景练手比如做一个自动回复邮件的小工具。重点理解system prompt、temperature、max_tokens这些参数的实际影响。第二阶段2-3周入门RAG。用LangChain加Chroma搭一个本地知识库问答文档就用你自己的技术笔记或产品手册。重点掌握文档切分、embedding、检索这三个环节。第三阶段3-4周Agent开发。从简单的工具调用开始做一个能查数据库、能发邮件的Agent。然后逐步加入多轮对话、错误处理、记忆管理。第四阶段持续深入某个方向。可以是Agentic RAG、多Agent协作、模型微调、或者特定行业的应用落地。这个阶段没有标准答案取决于你的实际需求。6.2 工具选型不要追新够用就好LLM应用开发领域工具迭代极快今天出的框架明天可能就过时了。我的建议是LLM调用LangChain或直接使用官方SDK。LangChain的优势是抽象统一切换模型方便劣势是版本更新快API不稳定。如果项目简单直接用官方SDK更可控。RAG框架LangChain、LlamaIndex、Dify。LangChain最灵活LlamaIndex对检索场景优化更好Dify适合快速搭建原型。Agent框架LangGraph、AutoGen、CrewAI。LangGraph适合复杂流程编排AutoGen适合多Agent对话CrewAI适合角色分工明确的场景。向量数据库Chroma原型、Qdrant/Milvus生产。本地部署Ollama最简单、llama.cpp最轻量、vLLM高性能推理。6.3 关于LangChain和LangGraph的选择这是热搜词里反复出现的问题。我的判断标准很简单如果你的流程可以用一个有向无环图表示用LangChain的Chain就够了。如果需要循环、条件分支、动态决策用LangGraph。举个例子一个“用户提问-检索-生成回答”的RAG链路用LangChain的RetrievalQA就能搞定。但如果你要做“用户提问-Agent判断是否需要检索-如果需要则检索-判断检索结果是否充分-不充分则换关键词再检索-充分则生成回答”这种带循环和条件判断的流程LangGraph会更合适。6.4 我个人的一些经验体会做了这么多项目最大的感受是大模型应用开发的核心竞争力不在模型本身而在工程能力。模型能力是公共的但如何设计提示词、如何切分文档、如何编排Agent流程、如何处理异常情况这些才是区分项目质量的关键。另一个体会是不要追求一步到位。我见过太多人想直接做一个“全能Agent”结果连基础的RAG都没跑通。正确的做法是从小场景切入先跑通一个最小闭环再逐步叠加能力。最后保持动手。这个领域变化太快看再多文章不如自己跑一遍代码。遇到问题先查文档再搜社区最后自己调试。很多时候一个报错信息就能让你学到比十篇文章更多的东西。后续如果要做扩展可以考虑的方向包括多模态RAG支持图片和表格检索、Agent协作多个Agent分工完成复杂任务、模型微调用领域数据提升特定任务表现、以及性能优化缓存、并行、流式输出。这些方向每一个都值得单独写一篇但前提是你已经把基础链路跑通了。