会 Python 但做不出大模型应用这问题我太熟了。上个月还有朋友跟我吐槽pandas、爬虫、FastAPI 都玩得转一打开大模型 API 文档却发现自己只会写一句帮我翻译然后对着 messages 参数发呆。会说 Python 只是入场券能不能做出应用取决于你有没有把三件事变成肌肉记忆——Prompt、RAG、Agent。这篇就把这三条线的原理、实战顺序、常见坑一次性讲透给那些代码会写、但一碰大模型就懵的 Python 开发者一条能直接照做的进阶路线。1. 会 Python 和能做大模型应用之间隔着一个应用层1.1 多数人的真实卡点不是语法是系统思维我见过太多人卡在同一个地方能写requests.get调接口能跑通一个 Hello World 对话但真要做点有用的东西就不知道从哪里拆。问题不在 Python 水平而在于你把大模型当成什么。如果你把大模型当成一个能聊天的 API那你的天花板就是聊天机器人。真正的应用开发是把模型嵌进一条完整的数据流和控制流里数据从哪来、怎么切分、怎么检索、怎么拼进上下文、模型输出后怎么校验、失败怎么处理、日志怎么留。这些环节里Python 只负责胶水真正的难点在于你懂不懂模型的脾气。这里有个很反直觉的点写传统代码时你追求确定性一分逻辑一分结果写大模型应用时模型是概率性的同样的 prompt 两次输出可能不一样。所以工程重心从写逻辑变成了写约束——用提示词约束行为、用检索约束知识、用循环约束动作。这就是 Prompt、RAG、Agent 分别干的事。1.2 为什么偏偏是这三样东西用一个比方来说Prompt 是教模型怎么说话RAG 是给模型喂资料Agent 是让模型动手干活。Prompt解决的是更会问——同一个模型你会提需求它就能给你高质量输出RAG解决的是更懂行——模型没学过你的业务数据你临时把相关资料塞进上下文里Agent解决的是更会做——模型不只会输出文字还能调用工具、执行动作、完成多步任务。这三条线是从易到难的。很多新手一上来就玩 Agent结果连基础对话的稳定性都没搞定最后跑出来一顿乱调工具还以为是模型不行。我后面给一个明确的顺序和路线按着走能省一半时间。2. 第一关Prompt 工程把聊天变成接口调用2.1 你写的是提示词不是聊天记录大多数人的第一个错误是把提示词当聊天记录写。比如messages [ {role: user, content: 帮我写一个Python函数计算两个日期之间的天数要处理闰年还要考虑边界情况最好用datetime库注释要中文} ]这种写法不是不能用但把所有需求塞进一句话里模型很容易顾此失彼。等到输出格式不固定、漏条件、风格不一致的时候你再回头调就麻烦了。合格的提示词应该像产品需求文档一样有结构。我习惯的模板是四段式角色 任务 约束 输出格式。角色告诉模型它是什么身份任务说清要做什么约束划出边界输出格式决定你怎么解析结果。system_prompt 你是一名资深Python工程师擅长编写健壮、可读性强的代码。 请根据用户需求编写Python函数并遵守以下约束 1. 必须使用Python标准库或用户明确指定的库 2. 必须处理边界情况空输入、None、极端值 3. 代码注释使用中文 4. 只输出代码本身不要额外解释 输出格式 - 先输出函数定义 - 然后输出三组测试用例及预期结果 把约束写进system而不是user是有原因的system 消息在模型内部权重更高、更稳定适合放规则user 消息适合放这一次的具体输入。你把规则放 user 里每次都要跟着业务数据一起发既浪费 token又容易被后续输入干扰。2.2 一套可直接抄的结构化提示词模板下面这个模板我用了大半年适合大多数输入-输出型任务[角色] 你是{领域}专家擅长{能力}。 [任务] 根据输入完成{具体目标}。 [输入] {这里放业务数据} [约束] 1. {硬性规则} 2. {禁止事项} 3. {边界条件} [输出格式] {JSON / Markdown表格 / 纯文本} [示例] {给1-2个高质量样例}这里的示例很关键。对模型来说一个具体例子胜过十句抽象规则。比如你想让模型输出 JSON与其写必须输出合法的JSON不如给它一段真实输出样例。这叫 few-shot效果比 description 稳定得多。参数上也别忽略做结构化抽取时temperature调到 0.2 以下减少随机性做创意写作时可以高一点。max_tokens别舍不得给很多输出被截断不是模型问题是你的上限设太小。2.3 实测中常见的反馈信号闪退、被拦截、输出不稳定写 prompt 的过程中你会遇到各种奇奇怪怪的报错我先把最常见的几个列出来省得你以为是模型坏了。prompt 闪退——这个我排查过好几次最后发现多数不是模型问题而是客户端或前端交互层的问题。比如超长输入导致浏览器卡死、SDK 版本不兼容、网络断连。遇到闪退先看后端日志有没有收到请求收到请求就是客户端问题没收到才是 SDK 或网络问题。invalid prompt: your prompt was flagged as potentially violating our usage policy——这是内容安全策略拦截了你的提示词。常见触发场景是提示词里包含暴力、色情、非法活动相关字眼或者是在做越狱式指令。解决办法不是绕过而是先检查自己是不是碰了红线然后把内容改写成合规表述。开发阶段如果频繁被拦说明你的数据源本身要清洗。输出不稳定——同一段 prompt 跑两次结果不一样这是常态。处理办法是先固定 temperature 和 seedOpenAI 支持 seed 参数再检查你的 prompt 是否包含歧义。比如总结这篇文章就比提取文章中的三个关键结论输出为JSON数组更容易飘。3. 第二关RAG 知识库让模型用上你才知道的事3.1 RAG 解决什么问题和微调怎么分工大模型的训练数据有时间截止也没有你公司的内部资料。你问它我们平台的新用户注册流程是什么它只能编。传统方案是微调但现在更主流、成本更低的做法是 RAGRetrieval-Augmented Generation检索增强生成。RAG 的核心思路就一句话不要背答案要带着资料答卷。每次请求时先从你的知识库里检索出相关片段拼进上下文里再让模型基于这些片段回答。这样知识可以实时更新不用重新训练模型。和微调的分工也很清楚微调适合改变模型的风格和能力比如让它更会写某种文案RAG 适合补充事实和知识比如回答业务问题。两者不冲突可以叠加用但新手阶段把 RAG 玩明白性价比高得多。3.2 零基础可复现的最小 RAG 流水线我给你一套能跑通的骨架用 Ollama 跑本地模型不用申请云端 API 也能实验ollama pull qwen2.5 ollama pull nomic-embed-text然后装上几个库pip install chromadb sentence-transformers ollama最小流程是五步加载文档 → 切分 → 向量化 → 检索 → 生成。核心代码看这篇够用了逻辑比框架重要import ollama import chromadb from chromadb.utils import embedding_functions # 1. 切分把长文切成块 def chunk_text(text, size400, overlap80): chunks [] for i in range(0, len(text), size - overlap): chunks.append(text[i:i size]) return chunks docs chunk_text(open(help.md, encodingutf-8).read()) # 2. 向量化 存入向量库 client chromadb.PersistentClient(path./rag_db) col client.get_or_create_collection( help_docs, embedding_functionembedding_functions.OllamaEmbeddingFunction( urlhttp://localhost:11434/api/embeddings, model_namenomic-embed-text, ), ) # 3. 检索 question 用户如何重置密码 q_vec col.query(query_texts[question], n_results3) context \n\n.join(doc for doc in q_vec[documents][0]) # 4. 生成 prompt f基于以下资料回答问题如果资料中没有相关信息直接说不知道。 资料 {context} 问题{question} resp ollama.chat(modelqwen2.5, messages[ {role: user, content: prompt} ]) print(resp[message][content])这段代码没有用 LangChain原因是我希望你先理解每一步在干什么。市面上零散教程很多但很多是一行代码装好但出了问题完全不知道哪里断了。3.3 chunk、embedding、hit rate三个必须懂的参数RAG 的效果好不好第一个拦路虎是chunk 切分。切太大检索到的片段里噪音多切太小语义不完整。一般建议 300-800 token重叠 50-100。具体最优值跟你文档类型相关手册类文档 500 左右起步。第二个是embedding 模型。要保证查询和文档用的是同一个 embedding 模型这是新手最常犯的错——用 OpenAI 的 embedding 存库又用本地的 embedding 查询维度都对不上报错都算轻的最怕不报错但相似度全乱。第三个是hit rate召回率。它衡量的是相关文档出现在前 k 条检索结果里的比例。比如测试集里有 100 个问题每个问题有 1 个标准答案文档系统把正确答案召回进了 top-5如果有 80 个问题做到了那 hit rate5 就是 0.8。这个指标是 RAG 的基石如果你 hit rate 都上不去后面 prompt 写得再好也是白搭。我用 30-50 条来自造一个带标准答案的评测集每次改完 chunk 策略就跑一遍比凭感觉调参靠谱得多。3.4 RAG 的瓶颈与常见坑召回质量上不去怎么办RAG 系统跑通了只是开始真正难受的是检索质量上不去。常见的三连坑相似度不等于相关性向量相似度高的片段可能是同主题废话不含关键信息。解法是引入 rerank重排模型先粗召回 20 条再用重排模型精排选 3 条。开源可以看 bge-rerankerAPI 可以用 Cohere Rerank单一向量检索不够专有名词、产品名用词向量效果很差因为字面没匹配上。解法是混合检索BM25 关键词检索 向量检索取交集再合并排序问题本身问得不好密码怎么重置和我忘了密码怎么办语义相近但表述不同。解法是加一步 query 改写先用小模型把用户问题改写成更适合检索的多个候选问题再分别检索。还有个大坑是embedding 模型和主模型不匹配。有的人本地跑 Ollama 加载一个小模型做生成又用一个很强的 embedding 做检索结果生成模型反而理解不了高质量的上下文。生成模型和检索模型的能力差距别拉太大。另外提醒一句所谓RAG 知识库工程上不等于丢一堆 PDF 进去就完事。文档本身要去重、要清洗格式、要按类型设计不同的 chunk 策略。我见过那些效果稳定的 RAG 系统一半时间花在数据治理上另一半才在调检索。4. 第三关Agent从回答问题到完成任务4.1 Agent 的本质一个带工具的循环RAG 再强本质还是一问一答。Agent 不一样它是让模型自己决定要不要查资料、要不要调工具、下一步做什么。最经典的模式是 ReAct思考Thought→ 行动Action→ 观察Observation循环往复直到完成任务。最小 Agent 其实不复杂。核心逻辑长这样def run_agent(question, tools, max_steps5): messages [{role: user, content: question}] for step in range(max_steps): resp llm.call(messages, toolstools) action parse_action(resp) # 解析模型输出的工具调用 if action is None: # 模型认为任务完成 return resp.content result execute_tool(action) # 执行工具 messages.append({ role: tool, content: result, tool_call_id: action.id, }) return 任务超时就这么个循环。模型每次生成的不是答案而是下一步动作。你的工具可以是查数据库、查天气 API、执行 Python 代码、发邮件。每个工具定义里要有清晰的描述和参数 schema模型靠这个才知道什么时候该调谁。4.2 手写最小 Agent还是直接用框架我的建议先用框架快速跑通再手写一遍内部逻辑。理由很现实框架帮你处理了工具协议、对话历史、错误重试这些脏活你先用框架建立感性认识再手写你才知道框架替你做掉了什么。Agent 框架现在很卷选型就看你的技术栈和场景框架适合场景特点LangChain通用原型生态最大概念多容易踩坑LangGraph复杂状态流以图的方式定义流程可控性强适合生产LlamaIndex文档密集型在 RAG 基础上扩展 Agent 能力自然AgentScope多智能体协作国内团队维护多 Agent 编排方便顺带说一句如果你是做企业级 Java 后端会看到很多Spring AI 国产大模型的教程那是另一套技术栈了。同一个模型、同样的 RAG 思路换个语言生态换套 SDK 而已原理完全通用。别被工具名吓住。吴恩达在 DeepLearning.AI 上有一个很短的 Agent 教程里面把 Translation、Planning、Tool Use 几个模式讲得很清楚作为入门资源很合适。核心不是看代码是理解 Agent 的每种模式解决什么问题。4.3 Agentic RAG把检索变成 Agent 的工具Agent 和 RAG 不是二选一现在的热点是Agentic RAG。普通 RAG 的流程是死的接到问题 → 检索 → 拼上下文 → 回答。Agentic RAG 则把是否检索、检索什么、要不要再检索一次这些决策权交给模型。举个例子用户问对比一下我们两款产品的退款政策差异。普通 RAG 会一次性检索两个产品的文档片段可能有一半是不相干的Agentic RAG 会让模型先决定我需要分别检索 A 产品的退款政策和B 产品的退款政策分两次检索再综合回答。更复杂的场景里模型还能判断这个问题需要查实时库存数据于是去调库存工具而不只是翻文档。实现上并不神秘就是在 Agent 的工具列表里加一个search_knowledge_base(query)工具。难度在于给模型足够的工具描述让它知道什么时候该查、什么时候不该查否则模型会乱调甚至每个问题都跑一遍检索白白增加延迟。4.4 Agent 开发最常见的失控场景与修复Agent 看起来爽做起来全是坑。我把高频问题列一下死循环模型反复调用同一个工具永远不收敛。解法设最大步数这是底线再就是工具返回信息要给足让模型知道这次结果已经拿到了别再查了工具参数乱传模型把参数类型传错、JSON 格式崩掉。解法工具 schema 写严格运行时做校验失败信息回传给模型让它自行修正上下文爆炸每轮对话都塞进完整历史Agent 跑几轮 token 就爆了。解法历史做摘要或者只保留最近 N 轮 工具结果摘要沙盒环境异常写代码类 Agent 靠沙箱跑 Python偶尔会遇到更新 Agent 沙盒之类导致任务中断的提示。这种属于基建问题解法是任务要设计成可幂等重试别让沙盒状态成为单点。还有个很实用的经验Agent 不是参数越大越好。小模型在简单场景下足够还便宜快。你对 Agent 的要求应该是在约束下完成任务而不是像人一样思考约束和流程设计比模型能力更值钱。5. 进阶路线按什么顺序学、学到什么程度再往下走5.1 顺序的逻辑先稳定输入再扩大知识最后放权为什么必须按 Prompt → RAG → Agent 的顺序因为每一层都在给上一层添乱。Prompt 是地基它让你掌握模型的稳定性。地基没打好就做 RAG你根本分不清回答得不好是检索问题还是提示词问题RAG 是知识层它让模型有依据地说话。知识层没做扎实就玩 Agent模型就会被错误信息带偏做出错误决策。这个顺序我见过太多人跳最后全回来补课。5.2 一份可对照的 20 小时实战路线下面是按小时拆的路线每个阶段标清了退出标准别贪快阶段时长做什么退出标准Prompt 基础3h用 API 跑 20 个不同任务写结构化 prompt调 temperature、max_tokens能稳定输出指定 JSON 格式Prompt 进阶2h做 few-shot、角色约束、对抗简单的不稳定输出同一任务连续 10 次输出可用RAG 最小系统5h用 Ollama Chroma 跑通完整流水线自己准备 20 篇文档系统能回答 80% 自建问题RAG 调优4h自建 30 条评测集调 chunk、试 rerank、加混合检索hit rate 提升 20% 以上Agent 基础3h用框架做一个能查天气算数的小 Agent再手写一遍循环能解释 ReAct 每一步在干什么Agentic RAG3h把检索变成 Agent 的工具做一个多步决策应用模型能在 3 步内完成复合问题这个路线不是把每个框架都学一遍而是让你把每件事的为什么搞懂。框架更新太快原理十年不过时。5.3 完成一个能写进简历的端到端项目光看教程没用最后一定要落地一个完整项目。我的建议是做一个基于本地知识库的智能问答助手但别停在能回答这个层次加上三件事就不一样支持多格式文档PDF/Markdown/Word上传和自动清洗带引用来源回答后面列出依据文档片段方便校验加一个简单的评测页面展示 hit rate 和人工打分的通过率。这个项目覆盖了 Prompt、RAG、前后端、评测几个维度面试或写简历时比我调过大模型 API有说服力得多。做完这个再往上走就是研究怎么上生产限流、缓存、审计日志、多租户隔离那是另一个阶段了。6. 实战中的高频坑与经验补充6.1 环境与工具链细节本地模型还是云端 API很多人在环境配置上浪费了最多时间。我建议的路径是先本地、后云端。本地用 Ollama 拉模型免费且不受网络限制适合学习和调试做完了再切到云端 API享受更好的模型能力。环境上几个老生常谈但年年有人栽的坑Python 版本和依赖冲突。建议每个项目建独立虚拟环境别把 LangChain、Chroma、SentenceTransformer 装进全局环境否则 Pandas 版本冲突够你折腾两天。Linux 下安装 Python 我踩过编译坑现在一律建议用 pyenv 或 apt 装现成包别自己从源码编译。embedding 模型下载也是个坎。HuggingFace 在国内访问不稳定是常态建议用镜像站配置环境变量或者直接用 Ollama 拉 nomic-embed-text 这类本地模型省心很多。6.2 成本、延迟与可观测性上线前必须算的账个人玩和上线之间有道鸿沟主要就是这三件事成本一个 RAG 请求的成本 检索 (embedding) 上下文 (大模型输入 token) 输出。上下文越大越贵所以检索结果别贪多3-4 个 chunk 足够。长文档场景可以用摘要替代全文进上下文延迟RAG 多一次向量检索Agent 可能循环多次。用户能接受的是 2-3 秒Agent 超过 5 秒体验就很差。解法是并行工具调用、缓存高频问题、流式输出可观测性传统开发看日志看异常大模型应用要看每一轮的输入输出、tools 调用、token 消耗。我习惯给每条请求打 trace_id把 prompt、检索命中的 chunk、最终输出全记下来排错时极其有用。这些虽然不性感但上线后救过我的命。很多项目死不是死在模型效果是死在你不知道该看哪里。6.3 一点个人体会这是搭积木不是写魔法最后说点实在的。我见过很多 Python 开发者焦虑会不会被大模型淘汰其实恰恰相反会 Python 的人在 AI 应用时代是最大的受益者——因为整个工具链都是 Python 写的。你缺的不是编程能力而是怎么把模型当成一个组件来设计系统的经验。这条进阶路线不算轻松但每一步都有明确的产出物走完你就不再是会调 API 的人而是能设计应用的人。我自己的感受是这三个能力其实是一层一层叠上去的Prompt 让我和模型沟通顺畅RAG 让我敢说业务Agent 让我敢说这件事我能自动搞定。等你把三样串起来回头再看最开始那个只会写给我一个翻译的自己就知道差距不在代码量而在思维模型。现在就打开你的编辑器从写好第一段结构化 prompt 开始。