AI 应用开发全景图：从模型到 Agent，完整技术链路深度解析

核心观点：AI 应用开发不是堆砌技术名词，而是构建一条从模型选择到 Agent 智能体的完整价值交付链路。一、引言：为什么你需要这张"全景图"很多 AI 学习者都有这样的困惑：“学了很多 AI 名词，还是做不出项目；会调用模型接口，还是搭不起业务闭环；做了几个 Demo，还写不进简历。”问题的根源不在于你不够努力，而在于缺乏系统结构感。今天看 Prompt 技巧，明天看 RAG 教程，后天刷 LangChain 示例，再过两天试一个 Agent Demo——这种碎片化学习让你永远在表面徘徊。本文将给你一张完整的 AI 应用开发地图。读完它，你会知道：每个技术环节在整体架构中的位置和作用什么时候该用什么技术，不该用什么如何把这些技术组装成一个真正的产品二、整体架构：五层技术栈AI 应用开发可以分解为五个核心层次：┌─────────────────────────────────────────────────────────────┐ │ Agent（智能体）层 │ │ 推理、规划、工具使用、记忆、反思 │ ├─────────────────────────────────────────────────────────────┤ │ 应用框架层 │ │ LangChain、LlamaIndex、自定义编排 │ ├─────────────────────────────────────────────────────────────┤ │ RAG（检索增强）层 │ │ 向量检索、文档处理、知识图谱 │ ├─────────────────────────────────────────────────────────────┤ │ 模型层 │ │ 基座模型、微调模型、专家混合 │ ├─────────────────────────────────────────────────────────────┤ │ 基础设施层 │ │ 部署、推理优化、监控、向量数据库 │ └─────────────────────────────────────────────────────────────┘核心原则：每一层都建立在下层之上，但上层的选择会反推下层的选型。三、第一层：模型选择——不是越大越好3.1 基线模型选择应用场景推荐模型参数量特点通用对话GPT-4、Claude 3、LLaMA 370B+能力强，成本高垂直领域Qwen、Baichuan、ChatGLM7B-14B性价比高，可微调端侧部署Qwen2-0.5B、Phi-3-mini1B极致轻量，离线可用代码生成CodeLlama、DeepSeek-Coder7B-34B专精代码3.2 模型选型的三把尺子第一把尺子：任务复杂度简单任务（分类、提取）：小模型 + 提示工程足够中等任务（对话、摘要）：中等模型 + 少量微调复杂任务（推理、多跳问答）：大模型 + RAG + Agent第二把尺子：延迟要求实时响应（500ms）：选小模型 + 量化 + 推理优化可接受延迟（1-3s）：中等模型可满足离线/异步：可以用大模型第三把尺子：成本约束成本公式 = API调用成本 + 推理算力成本 + 维护成本 典型对比（100万Token/月）： - GPT-4 API：约 $15-30 - LLaMA-8B 本地推理：约 $5-10（需GPU） - Qwen-1.8B 本地推理：约 $0.5-1（CPU即可）3.3 实践建议不要盲目追求大模型。很多场景下，一个经过精心提示工程的小模型，效果往往超过"裸用"的大模型。典型案例：任务大模型方案优化方案效果情感分类GPT-4 直接判断Qwen-7B + 5-shot prompt成本降低 90%，准确率相当意图识别GPT-4 APIChatGLM-6B 微调延迟从 3s 降到 300ms实体抽取Claude API本地 7B 模型 + 正则校验成本降低 95%四、第二层：提示工程——让你的模型更聪明4.1 提示工程的核心原理本质：提示工程是一种"编程"方式，通过设计输入来控制模型输出。传统编程：代码 → 编译器 → 输出 提示工程：自然语言 → LLM → 输出4.2 提示工程的五个层次层次一：零样本提示（Zero-shot）输入："把以下评论分类为正面或负面：服务很差" 输出："负面"层次二：少样本提示（Few-shot）输入：""" 例子1：产品很好用 - 正面 例子2：有点失望 - 负面 待分类：超出预期 - ？ """ 输出："正面"层次三：思维链提示（Chain-of-Thought）输入：""" 问题：小明有5个苹果，小红给了他3个，他又吃了2个，还剩多少个？ 让我们一步步思考： """ 输出："..."层次四：ReAct 提示（Reason + Act）输入：""" 问题：今天北京天气如何？ 思考：我需要先查询北京天气 行动：调用天气API 观察：API返回晴天，25度 结论：今天北京晴天，气温25度 """层次五：自我反思（Self-Reflection）输入：""" 生成回答后，检查以下问题： 1. 事实性：是否有幻觉？ 2. 完整性：是否回答了所有问题？ 3. 安全性：是否有害内容？ """4.3 提示工程实战技巧技巧一：结构化输出# 不好的提示"帮我总结这篇文章"# 好的提示"""请按以下JSON格式总结文章： { "title": "文章标题", "summary": "不超过100字的摘要", "key_points": ["要点1", "要点2", "要点3"], "sentiment": "positive|neutral|negative" } """技巧二：分隔符隔离prompt=""" 请根据以下上下文回答问题。 ========上下文======== {context} ================== ========问题======== {question} ================== 请先引用相关原文，再给出回答。 """技巧三：角色设定prompt=""" 你是一位资深技术架构师，有10年以上的系统设计经验。 你的风格是：深入浅出、注重实战、强调可行性。 请分析以下场景，给出架构建议： {scenario} """4.4 提示工程的局限上下文限制：模型有 token 上限（通常 4K-128K）一致性不稳定：相同提示不同调用可能有不同结果无法精确控制：模型可能"过度发挥"或"理解偏差"这就是为什么需要下一层：RAG。五、第三层：RAG（检索增强生成）——解决知识截止和幻觉5.1 为什么要 RAG？大模型的两大痛点：问题表现RAG 解决方案知识截止训练数据不包含最新信息实时检索最新文档幻觉一本正经地胡说八道基于真实文档生成5.2 RAG 完整流程用户输入 → 编码 → 向量数据库检索 → 上下文拼接 → LLM 生成 → 输出 ↓ [文档1, 文档2, ..., 文档n]5.3 RAG 的核心组件组件一：文档加载器fromlangchain.document_loadersimportPyPDFLoader,TextLoader,WebLoader# PDF 文档loader=PyPDFLoader("report.pdf")docs=loader.load()# 网页loader=WebLoader("https://example.com/article")docs=loader.load()组件二：文本分块fromlangchain.text_splitterimportRecursiveCharacterTextSplitter splitter=RecursiveCharacterTextSplitter(chunk_size=500,# 块大小chunk_overlap=50,# 重叠区域，保证连续性separators=["\n\n","\n","。",""]# 按优先级分割)chunks=splitter.split_documents(docs)组件三：向量化嵌入fromlangchain.embeddingsimportHuggingFaceEmbeddings# 选择嵌入模型embeddings=HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5"# 中文效果好的模型)# 向量化vectors=embeddings.embed_documents