先说一个我见过无数次的场景：你学了几个月Python，for循环、列表推导式、requests爬虫都玩得挺溜，也能照着文档调通OpenAI的API。有人问你"能不能帮我做一个大模型应用"，你打开编辑器，盯着空白的main.py，半天打不出几行代码。这种状态太典型了——问题从来不是你不会Python，而是你只学会了"调用模型"，没学会"设计应用"。

我经常跟朋友打一个比方：Python像一本驾照，大模型应用是开车上路。有驾照的人很多，但到了复杂路口、需要变道、处理突发状况时，很多人还是不会开。Prompt、RAG、Agent这三样东西，就是大模型应用领域的三项"上路技能"：Prompt是你会不会跟司机沟通，RAG是你会不会用导航，Agent是你敢不敢把车交给系统去完成一段复杂行程。

这篇文章不聊空理论，我直接把这三条路拆开讲：每条路解决什么问题、有哪些坑、需要掌握哪些实操要点，最后给一条完整的学习路线。适合所有"会Python但做不出应用"的人。你看完不需要背概念，按着路线走就行。

1. 先别急着写代码，想清楚"会Python"和"能做AI应用"之间差了什么

我见过太多人一上来就抱着LangChain的文档啃，啃了两周连一个能用的问答机器人都没做出来。为什么？因为在你开始调库之前，脑子里少了一张"应用全景图"。

1.1 Python只是入场券，不是核心竞争力

会Python语法和能做大模型应用之间，隔着至少四层能力：

• 模型调用层：你知道如何用API、如何处理返回结果、如何管理Token、如何处理超时和限流。
• 上下文设计层：你知道怎么把用户需求翻译成模型能高效理解的"输入"。
• 数据工程层：你知道怎么把外部数据变成模型可以检索、可以信任的"知识"。
• 流程编排层：你知道怎么让模型在多个步骤之间做决策、调工具、处理失败。

很多人卡住，是因为他们只接触过第一层。调通一个chat.completions.create()就觉得自己会了，实际上后面三层才是决定应用好坏的关键。

这四层能力对应的正好是三个关键词：Prompt、RAG、Agent。它们不是三个孤立的技术名词，而是从"单次对话"到"数据增强"再到"自主行动"的三级跳。

1.2 大模型应用开发是一个系统工程

我常说，做一个"能跑"的大模型应用很简单，几十行代码就行；但做一个"稳定可用"的应用，需要考虑的事情翻好几倍。

举个实际例子。你写一个客服机器人，表面上是"用户提问——模型回答"，但真正落地时你会发现要处理这些事：

• 用户的问题太模糊，要不要先追问澄清？
• 回答需要引用内部知识库，知识库里没有相关内容时怎么办？
• 模型出现幻觉、一本正经胡说八道时怎么兜底？
• 输出的格式是否需要下游系统能够解析？
• 用户连续提问时，上下文要不要做裁剪？

这些问题没有一个是Python语法层面的，全是工程层面的。这也是为什么很多写代码很溜的人，第一次做AI应用会碰壁：他会写代码，但还没建立"把人、模型、数据、流程串起来"的思维。

1.3 一个普遍存在的心智误区

我还发现一个特别普遍的误区：很多人以为"学完Python → 学会调用大模型API → 就能做出应用"，其实中间的链条长得多。

真实的学习路径应该是：

学会Python基础 → 理解大模型的工作方式 → 学会设计输入（Prompt） → 学会让模型连接外部数据（RAG） → 学会让模型调用工具和自主决策（Agent） → 学会评估和迭代 → 做出可用的产品

如果你跳过中间任何一环，最终都会在某个项目里卡住。这篇文章给出的路线，就是帮你把中间这些环节补上。

2. 第一关：Prompt工程，学完就能立刻提升对话质量

我遇到很多人对Prompt工程有个误解，以为就是"把话说得更好听一点"。真不是。Prompt工程是一门关于"如何与大模型高效沟通"的工程学科，它的核心是把模糊需求转变成模型容易服从的精确指令。

2.1 为什么你抄的提示词总是不好用

网上流传的万能提示词模板一大把，什么"你是一个资深专家，请帮我……"之类的，你会发现照抄以后效果也就那样。原因很简单：提示词不是咒语，而是一份"接口协议"。

模型不会因为你夸它是"资深专家"就真的变强，它只会按照你给出的"角色、任务、约束、输入、输出格式"这套结构化信息去生成内容。如果提示词里只有"你是一个资深专家，帮我写一个方案"，模型根本不知道：

• 方案要给谁看？
• 要求多少字？
• 什么语气风格？
• 必须包含哪些部分？
• 有哪些绝对不能写的东西？

所以你会发现效果飘忽不定。提示词真正的价值，是把你的需求定义得足够完整，让模型没有多少自由发挥的空间。

2.2 一套可复用的系统提示词模板

我自己写提示词的时候，长期用一套固定结构，它能覆盖大部分对话类应用的场景。分享给你们：

角色：你是[某领域的专业助手]，你的用户是[某类人群]。 任务：你的核心任务是[一句话描述你要完成什么]。 约束： 1. 只能基于给定的资料回答，资料中没有的内容，直接说"资料中未提及"。 2. 回答必须使用简体中文，控制在200字以内。 3. 不得提供任何违反法律法规的建议。 4. 如果用户的问题不明确，先追问一个澄清问题。 输入：用户会向你提交以下内容——[输入内容格式说明]。 输出格式：你的回答请遵循以下结构： 1. 直接结论 2. 理由或依据 3. 可执行的后续建议

如果你用了这套结构还是觉得模型不听话，问题通常出在"约束"不够具体。你要学会把"回答得专业一些"改成"必须引用数据，没有数据就说明数据不存在"；把"别太啰嗦"改成"回答控制在150字到200字之间"。

2.3 上下文工程：比提示词更值得花时间

很多人只在"系统提示词"里下功夫，忽略了另一个同等重要的部分——上下文。

举个例子。你让模型帮你写一封英文邮件，只写"帮我用英文写一封委婉的催款邮件"，它写出来的东西可能很空。但如果你在输入里塞进"对方是合作了两年的老客户，上个月刚续约，我们是乙方，应收账款已经逾期15天，金额是3.8万美元，希望在一周内到账"——模型写出来就是另一封能让对方看得进去的邮件。

这就是上下文工程的价值：模型的能力上限是固定的，但你能通过高质量上下文，把它的质量下限抬高。

上下文工程里有几个高频技巧，建议直接上手练：

• 少样本示例：给模型2-3个标准问答对，让它模仿格式，这比写一百字规则都有用。
• 思维链：需要解决多步推理问题时，在提示词里加一句"请一步一步思考，先列出步骤再回答"，能明显减少逻辑跳跃。
• 强制结构化输出：在提示词中明确要求回答一个JSON，并给出字段说明。很多模型本身就支持JSON模式，别浪费。
• 温度与控制参数：客服场景把temperature调到0.1-0.3，输出稳定；头脑风暴场景调到0.7-0.9，更有发散性。

这些技巧不依赖任何框架，你只要会调API就够。

2.4 无效提示词的三个常见特征

根据我踩过的坑，一份没效果的提示词基本有以下特征：

第一，太泛。什么"帮我分析一下这份报告"——报告呢？分析维度呢？给谁看呢？全都没有。你要把提示词当成给一个聪明但很懒的新员工下指令，指令不够具体，他就随便干干。

第二，没有示例。人类学习需要范例，模型也是。你想要什么格式，直接给一个或两个示例，比你说十句"要简洁、要专业"都管用。

第三，缺少输出约束。不告诉模型"只能输出JSON"或"每条回答不超过50字"，模型就会自然状态地自由发挥。自由发挥在B端产品里通常意味着灾难。

Prompt工程这关，我的建议是：不要追求什么"万能模板"，而是建立一套你自己的结构化写作习惯，然后针对具体场景反复调优。

3. 第二关：RAG，把企业内部文档变成"模型知识"

如果你会了Prompt工程，能做一个不错的对话机器人了，很快就会撞上下一堵墙：模型不知道你的业务数据。

你问它"我们公司上个月客户投诉最多的三个问题是什么"，它会一本正经地编一个答案。这时候就需要RAG（Retrieval-Augmented Generation，检索增强生成）上场。

3.1 RAG的本质：给模型配一本"随时翻阅的参考书"

RAG说白了就一句话：在让模型回答之前，先从外部资料库里检索出最相关的片段，把这些片段和用户问题一起拼给模型。

为什么要这么做？因为大模型的训练数据是滞后的，而且根本不包含你公司的私有文档。如果你想让模型成为一个"懂内部业务"的助手，只有两条路：更新训练数据（微调），或者检索相关资料（RAG）。

前者的成本高、周期长、每次更新数据都要重训；后者成本低、见效快、知识库更新只需要重新索引一遍。RAG解决的核心问题不是让模型记住，而是让模型在需要时查得到。

它的适用场景非常广：企业内部知识库问答、产品说明书问答、客服工单辅助、文档摘要、法律法规助手。只要手头有PDF、Word、Excel、网页、数据库这类数据源，RAG都能派上用场。

3.2 一条完整的RAG流水线长什么样

RAG的第一步，先把整条流水线在脑子里搭出来，不然你写代码时很容易漏掉环节：

文档加载 → 文本切分 → 向量化 → 索引存储 → 用户提问 → 检索 → 重排 → 拼装上下文 → 模型生成

这里面的每一步都有讲究，我逐个说。

文档加载：先把PDF、Word、Markdown、HTML各种乱七八糟的格式统一转成纯文本。注意PDF里的表格可能变成乱码，扫描件需要OCR，这些都要预处理。

文本切分：这是新手最容易忽略但影响最大的一步。很多人把所有文档内容一股脑塞给模型，结果上下文爆掉；或者切得太碎，一个问题相关的上下文散落在好几个片段里，检索时找不到。我常用的参数是：每个片段（chunk）控制在300-500个token左右，相邻片段之间重叠50-100个token。这样既能保留上下文语义，又不会让片段太臃肿。

向量化：把每个文本片段通过Embedding模型转换成一个向量（一串几百维的浮点数）。这里有两种选择：用闭源API（如OpenAI的Embedding接口），也可以本地部署开源模型（如BGE系列）。闭源方便，但数据出域你不放心；本地部署更安全，但需要自己搭服务。企业内部用敏感文档，我会优先推荐本地Embedding。

索引存储：把向量和对应的原文存进一个向量数据库。轻量方案有Chroma、FAISS，适合学习和小项目；生产环境可以考虑Milvus、Qdrant这类分布式方案。小项目没必要一上来就上重型数据库。

检索与重排：用户提问后，先把它向量化，然后到数据库里召回最相似的Top-K个片段。但底层的向量检索有时召回不精准，所以一个越来越常见的方法是加入一个rerank（重排）步骤，先用BM25和向量检索各召回一批候选，再用一个专门的排序模型把它们综合排序。这个方法能显著提升RAG的准确度。

3.3 检索之后，拼上下文也有讲究

检索到相关资料以后，不是简简单单把一堆文本丢给模型就完事了。你要在提示词里把"引用"的关系讲清楚。

我给一个最常见的上下文拼装框架：

根据以下资料回答问题。 资料1：…… 资料2：…… 用户问题：…… 要求：如果资料中没有直接答案，请回答"资料中未提及，请补充相关资料"，且不要编造。

这里有一个细节：你要明确要求模型区分"资料说"和"我说"。否则模型会把资料信息和自身世界观混合，生出一大堆似是而非的答案。很多人的RAG应用"看起来像那么回事，但一深问就露馅"，根源就在提示词里缺少"只依据资料，不自行发挥"这个约束。

3.4 RAG常见的失败模式和优化方案

我随便说几个实际项目中踩过的坑，你看完能少走很多弯路。

第一个坑：召回垃圾。你检索出来的Top-K片段跟用户问题无关，回答自然就偏。解决思路：调低相似度阈值、增加重排、改进切分方式。我见过很多效果不佳的项目，最后查出是切分太粗暴——一个长段落被硬切成两半，语义断了。

第二个坑：答案太"拼凑"。模型把多个片段的内容强行整合在一起，读起来很别扭。解决办法是提示词里加一句"只能基于单一连续片段回答，不要跨片段拼接"，同时缩小chunk大小。

第三个坑：文档更新不及时。知识库里的文档改了，但索引没重建，模型还在用旧资料回答。这是个工程问题，需要在文档更新流程里加一道"触发重新索引"的钩子。

第四个坑：盲目上框架。很多人一听说RAG就装LangChain，结果库是调通了，但内部发生了什么完全没概念。我的建议是：入门阶段亲手写一遍完整的RAG流程，用Embedding API + 向量数据库 + 几十行代码自己串一遍。之后你再用框架，就会知道自己到底在调什么参数。

RAG这一关，你至少要亲手跑通一个"本地知识库问答"的完整项目。不用做得多复杂，能对一个PDF文档做到"提问-检索-回答-引用来源"就算过关。

4. 第三关：Agent，让模型从"回答问题"变成"动手干活"

如果说Prompt是让模型"说得好"，RAG是让模型"知道得多"，那么Agent就是让模型"干得了活"。

4.1 Agent带来的能力跃迁到底在哪

我随便举几个场景，你会发现光靠一个对话模型是搞不定的：

• "帮我查一下今天上海到北京的航班，挑一个价格合适、时间不早不晚的帮我订了。"——模型需要查航班、对比价格、调订票接口、确认订单。
• "分析这份销售数据，发现问题后自动给我生成一封给产品团队的邮件。"——模型需要读取文件、跑分析、写邮件，也许还要先问你要不要调整数据口径。

这背后有一个核心能力模型本身不具备：调用外部工具的能力。Agent的本质就是给模型加装一个"能使用工具的循环"：模型先思考接下来该做什么，决定调用哪个工具，拿到工具结果后再继续思考，直到任务完成。

学Agent之前，你要先理解一个底层概念——Function Calling（函数调用）。这是大模型API提供的结构化工具选择能力。你在API请求里声明一批工具，模型会根据用户需求决定调用哪个，并产出一段符合工具参数要求的JSON。你拿到这个JSON之后自己去执行函数，再把结果回传给模型。

4.2 从零实现一个带工具调用的最小Agent

别急着装Agent框架，我给你一个手写的最小流程，这个流程可以写进你任何一个Python项目里。

假设你要做一个"能算数学、能查时间"的小助手。代码骨架大致就是这么个循环：

def run_agent(user_input): messages = [{"role": "user", "content": user_input}] for _ in range(5): # 最大循环轮次，防止死循环 response = call_llm(messages, tools=[TIMESTAMP_TOOL, CALCULATOR_TOOL]) if not response.get("tool_calls"): return response["content"] # 模型不再调用工具，输出最终答案 # 否则：把模型要求的工具调用结果追加到 messages，继续循环 for tool_call in response["tool_calls"]: result = execute_tool(tool_call) messages.append({"role": "tool", "content": result})

注意看这段代码的关键点：

• 每一轮模型都可能决定"要不要调用工具"。
• 如果调用了，你不急着给用户答复，而是先执行工具，把结果作为消息回传。
• 循环要设上限，我写5轮，防止模型陷入无休止的工具调用。
• 最终模型输出一个不再带tool_calls的回复，才算完成任务。

你把这个循环跑通之后，再去理解LangChain的Agent模块，你会发现所谓框架不过是帮你封装了这个循环加一堆现成工具。

4.3 ReAct模式真的有用吗

学Agent一定会遇到一个词：ReAct。它把模型的思考过程拆成"Reason（思考）和 Act（行动）"两步，你在很多开源Agent里都会看到类似下面的输出格式：

Thought: 用户想查今天的天气，我需要调用天气API。 Action: call_weather_api Action Input: {"city": "上海市"}

实际上，现代大模型的Function Calling机制已经天然具备了这个能力，不一定非要显式地把Thought、Action写在提示词里。你只需要理解它背后的思路：模型不再是"一次性输出最终答案"，而是每走一步都审视"我现在掌握的信息够不够，不够就调用工具"。

我个人的经验是：对于工具数量很少、流程固定的场景，你不需要完整的ReAct，只需要Function Calling循环就够；对于需要复杂推理、多步骤决策的场景，把思维的中间步骤暴露出来确实能提升成功率。理性判断，不要盲目套用。

4.4 Agent落地最容易翻车的四个工程问题

Agent做demo很容易，让模型调一个计算器5分钟就行。但真正要落地，你得提前考虑这几个问题：

第一个是状态管理。Agent在多个步骤之间需要记住"已经做到了哪里、用户的需求是什么、哪些结论已经被确认过"。很多人做Agent，跑两步就忘了之前的上下文，结果反复重复工作。你要设计一个合理的消息列表管理策略，该裁剪的裁剪，该保留的保留。

第二个是失败重试机制。工具调用不是每次都成功的。你的工具可能超时、可能传参错误、可能API返回异常。任何一步失败，你都要决定：是重试、还是告诉模型换一种方案、还是终止并给用户一个明确的错误提示？没有这个机制，Agent就是一颗定时炸弹。

第三个是防"鬼打墙"。模型可能在同一个工具调用上反复打转，或者陷入完全无关的思考循环。设最大迭代次数只是底线，更好的方式是定期检查"模型最近几轮的动作是否重复且无进展"，如果是，就主动终止并通知用户。

第四个是权限与安全控制。这可能是最容易被忽略的。当你给Agent开放工具权限时，要有"最小权限"意识：能只读就不要给写权限，能局部操作就不要给全局操作。关于这一点我多说一句：生产中给Agent接数据库、接支付接口这些场景，一定要有独立的权限校验层，不能直接把它当成一个"调Python函数"的黑盒。

4.5 Agent框架的本质，别被它唬住

现在市面上的Agent框架很多，LangChain、AutoGen、MetaGPT、CrewAI……我见过不少新手被这些框架吓住，觉得不学会它们就做不了Agent。

说句大实话：这些框架的本质就是帮你封装了"模型调用循环 + 工具注册 + 记忆管理 + 多Agent通信"，方便是方便的，但代价是你对底层失控。

我自己做项目的顺序是：先手写最小循环，确认整套逻辑通了；再根据项目复杂度决定要不要引入框架。小项目、工具少，手写更可控；多Agent协作、复杂任务规划，才考虑框架。

这个顺序避免了一个经典问题：你用框架三分钟搭出来一个demo，但一旦要调试、加功能、改逻辑，你完全不知道该改哪里。

5. 一条能落地的实战进阶路线

前面三关我都讲完了，这一章给你一条实际推进的计划。如果你不知道从哪天开始、怎么做，可以直接照这个路线走。

5.1 阶段自测：请你老实告诉我你现在卡在哪里

做之前先花十分钟做个自测。对着下面几个问题，你能回答到第几个，就从第几个开始：

1. 你会用Python调大模型的API，能处理参数和返回结果吗？
2. 你能为"单轮对话"和"多轮对话"分别设计一套系统提示词吗？
3. 你做过一个完整的RAG项目，能让模型基于本地文档回答问题吗？
4. 你写过Function Calling循环，让模型调用过外部工具吗？
5. 你做过一个需要多步骤决策、多个工具配合的Agent吗？

我的建议是：哪怕你已经知道第4、第5题的概念，但没亲手写过代码，都不要跳过前面的步骤。我从这批经验里总结出一个很痛的教训——理论看过一百遍，不如亲手踩一个坑。

5.2 用三个项目驱动，而不是啃厚书

学习大模型应用开发，最有效的路子是项目驱动。我给你设计三个递进的项目。

项目一：个人对话助手（练Prompt）

做一个能帮你写邮件、写周报、做翻译的对话工具。重点不是功能多，而是你要反复迭代提示词，直到输出稳定。验收标准：随便给它一个"写周报"的需求，它输出的格式每次都一致；你要求它改成简短版，它就只输出简短版。

项目二：本地知识库问答（练RAG）

拿一批真实的PDF（比如公司制度、产品手册、课程资料），做一个聊天界面。验收标准：对资料里的细节提问能答对，并能标出引用来源；对资料里没有的东西，它明确说"未找到"，而不是瞎编。

项目三：带工具的目标任务Agent（练Agent）

做一个能完成一个真实任务的小Agent。我建议从一个简单的场景开始，例如"让它根据用户要求，搜索知识库里的相关内容，然后通过一个表单接口把结果提交给某个系统"。别一上来就做什么全自动股票分析，先做一个能稳定完成单一任务的。验收标准：同一个任务连续跑十次，成功率达到八次以上。

5.3 时间怎么排、里程碑怎么定

如果是在职学习，每天能挤出1-2小时，我建议这样安排：

• 第1-2周：只做Prompt工程，项目一完成。中间穿插学习模型的参数（温度、Top-p、Max tokens）和上下文窗口概念。
• 第3-4周：做项目二，RAG。第一遍你可能会花大量时间调切分和检索参数，这很正常。把每一步的输入输出都打日志，方便排查。
• 第5-8周：做项目三，Agent。先手写Function Calling循环，再引入一个框架对比感受。如果你觉得多Agent协作很酷，这个阶段也可以看一点多Agent的资料。

不用给自己太大压力，从"能跑"到"稳定"本来就是量变到质变的过程，成年人学习最重要的不是计划多完美，是每天都能推进一点点。

5.4 部署和迭代：不要让项目永远躺在笔记本里

很多人的项目做完就扔在Jupyter Notebook里，我强烈建议至少走一次"部署-使用-迭代"的闭环。

用一个轻量界面把项目包起来，我推荐Gradio或Streamlit，二选一即可。它能让你在浏览器里操作，也能生成一个临时链接给朋友用。此外，建一个"测试集"，固定20-30个问题和对应的最优回答，每次改完代码就跑一遍测试集对比效果。这比每次都临时想问题靠谱得多。

然后再往前一步，你会涉及这些生产级话题：日志系统、错误监控、Token成本统计、评估指标（准确率、召回率）、用户反馈收集。不用一步到位，但你要知道应用有这些"生长方向"。

6. 常见问题与排查技巧实录

最后分享一些我在实际项目里反复遇到的问题，以及对应的排查思路，希望对你有参考价值。

6.1 "文档明明传进去了，它还是胡说"

这几乎是RAG项目里出现频率最高的问题。先说结论：文档"传进去"了不代表"检索得到"。

排查顺序是这样的：先单独跑一次检索，看看召回的片段相不相关。如果不相关，检查切分是不是太大或太小、Embedding模型本身的能力、检索用的Top-K是不是太小。如果检索相关，但还是胡说，问题出在生成阶段——检查提示词里有没有"只能根据资料回答"的约束。

我见过一个很颠覆认知的案例：某项目把所有文档塞进一个chunk里，模型上下文放不下，被系统截断成两段，第二段全是乱码——模型拿到乱码资料后自由发挥，效果自然惨不忍睹。所以遇到"胡编乱造"，先从资料切分查起。

6.2 "改了很多次提示词，效果还是不稳"

提示词效果不稳定，第一个检查点不是提示词本身，而是输入波动。用户的提问五花八门，你如果只在系统提示词里写了"回答用户问题"，那任何措辞变化都会影响输出。

解决方案是把"回答的边界"收紧：给出固定输出模板、给出几个少样本示例、强制JSON输出、在关键字段上做校验。如果这些全做了还不行，就看是不是温度参数太高。客服场景温度超过0.3，基本就开始飘了。

还有一个容易被忽略的细节：多轮对话里的历史记录也在污染模型。你会发现单轮测试效果很好，一旦变成多轮对话，模型被用户之前某个跑题的提问带偏。这种问题需要你定期裁剪或总结历史上下文，只保留跟当前问题相关的部分。

6.3 "Agent跑到一半就卡死，没反应了"

我排查这类问题有个固定的顺序：先看日志，Agent停在哪个环节？是工具调用的结果没回传、模型迟迟没有输出、还是你设置的循环次数太少导致提前退出？

如果是工具结果没回传，大概率是你把格式塞错了，messages里少了一条"role": "tool"的消息。如果是循环次数太少，把5改成10试试；如果它在反复调用同一个工具且参数完全一样，判为"无进展"直接终止，这是这类系统的一个基本兜底策略，提前规划好。

6.4 API报错速查表

我自己在实践中整理了一张简单的排查表，遇到报错先对照看看：

6.5 新手最容易踩的五个坑集合

最后再送你一份个人总结的避坑清单，都是踩出来的经验，说不定能帮你省下一个月的挣扎时间。

第一，不要迷信大模型能力。模型再强，你给的上下文垃圾，它输出就垃圾。大模型是放大器，不是无中生有的神仙。

第二，不要一上来就学框架。LangChain、LlamaIndex、AutoGen都很优秀，但不是你的第一步。你至少手工做一遍API调用、RAG、Function Calling循环，才能读懂框架的抽象。

第三，不要忽视评估。你改了一版提示词，凭感觉觉得"好像好一点"，这不算数。建一个固定的测试集，用统一的评分标准比较两版输出，才算一次真正的优化。

第四，不要一次性把任务设置得太复杂。新手做Agent，老想着做一个全能管家。我给你一个建议：先做只调一个工具的"最小Agent"，跑通了再逐步加工具。复杂度是滚雪球上来的，一次到位不现实。

第五，不要忘掉成本和延迟。生产环境的大模型应用，你要记账：每轮对话消耗多少Token、平均耗时多少毫秒。很多项目死于"面试时demo很酷，上线后账单爆炸"。

我个人做了几年大模型应用，最大的体会是：这个领域变化太快，今天的主流框架明天可能就被替代，但**"会设计上下文、会管理数据、会编排流程、会评估效果"这四件事永远不会过时**。你现在花时间把Prompt、RAG、Agent这三条路走通，不是学几个工具，而是在建立一套属于你自己的"应用思维"。

最后再送你一个我自己的习惯：做一个新功能时，先写一个最简单的手工实现证明可行性，再考虑要不要引入更重的工具。这套方法论帮我避开过不少"看着很厉害但根本跑不动"的方案。你可以从今天随手一个小项目开始，写完第一个RAG问答，做完第一个带工具的Agent，你再看这个领域，视角会完全不一样。