★ FEATURED ARTICLE 这两年我接触了不少从其他技术栈转过来做AI应用开发的朋友大家最普遍的一个困惑是资料看了几百篇教程也跟了不少可真到自己动手做一个带点智能的应用时却不知道从哪儿下手。LLM、RAG、Agent、记忆系统、向量数据库这些词每个单独拿出来都有人讲但它们在真实项目里到底怎么分工、怎么衔接很少能有一篇文章讲透。这篇文章我想把AI开发这条路上的7个核心领域摊开揉碎说一遍——从大模型的基础认知与Prompt编写到RAG检索增强生成再到Agent智能体的规划与工具调用、记忆系统的设计实现最后落到开发框架选型和一条适合小白的实战路线。目标只有一个让你读完脑子里能有一张完整的地图知道每个环节解决什么问题、什么时候该上什么技术而不是看到一个教程就盲目抄一个。1. 先看懂AI开发的能力地图7大核心领域各自解决什么问题很多人对AI开发的认知是调一下大模型的接口传个prompt拿到结果就完事了。这种思路在做一个Demo时确实成立可一旦要做成一个真正的产品你会发现事情远没有这么简单。举个最直观的例子你让大模型回答我们公司最新的报销流程是什么它大概率会一脸茫然甚至编造一套流程。因为它的知识停留在训练数据截止那天而且从不认识你公司。1.1 一个比喻大模型像个会聊天但不会干活的新员工我特别喜欢用这个比喻来解释AI应用的技术栈大模型本质上是一个知识面很广、但有点健忘、也不太会用工具的新员工。他读过很多很多书聊起天来头头是道但你没告诉他的内部信息他真的不知道却又不好意思说不知道于是就开始顺着你的话编。你让他帮忙订个会议室、统计一份数据他嘴上答应但手里没工具、也不知道该按什么步骤执行。更麻烦的是他每次见到你都像第一次见面完全不记得你上周提过什么需求。后面这四层技术本质上就是在给这位新员工补能力RAG是给他外挂一个公司知识库让他遇到不确定的问题先查资料再回答而不是瞎编。Agent是给他配上双手和工具让他能调用各种接口去执行具体任务而不是只动嘴。记忆系统是治他的健忘症让他在多次对话里记住你是谁、你关心什么、任务进展到哪一步。Prompt工程则是给他一本工作手册把说话和干活的规矩写得清清楚楚。1.2 七块拼图与它们之间的关系基于这个比喻我把完整的AI应用开发拆成7个局部这也是本文不断提到的7大核心领域。它们不是并列的技术名词而是一个有依赖关系的分层结构核心领域解决的痛点你能得到的产出1. LLM基础与API调用不了解模型能力边界调用都不会第一个跑通的对话程序2. Prompt工程输出不稳定、格式不可控一套可复用的提示词模板3. RAG检索增强生成知识截止、私有知识缺失、幻觉严重能基于文档库回答问题的系统4. Agent智能体模型只会聊天不会干活能自主调用工具完成任务的应用5. 记忆系统模型没有跨会话记忆、上下文受限记得用户与业务状态的智能应用6. 开发框架与工具链集成多组件时效率低、重复造轮子一套稳妥的工程脚手架7. 部署与评估上线后效果不可控、问题不直观可监控、可度量、可迭代的线上服务1.3 为什么按这个顺序学习最省力很多初学者的误区是一上来就追Agent甚至直接啃某个开源大项目的源码结果被各种抽象概念砸晕。我的建议是按依赖顺序来先把1和2做扎实理解你正在跟一个什么样的模型打交道再叠加3和4让应用从能说变成会做然后补上5和7这两个工程化能力让应用真正可商用。第6点其实是贯穿全程的我会在教程后面单独展开因为框架选错了前期有多爽后期就有多痛。2. 第一层地基LLM基础认知与Prompt工程的配方打法2.1 理解大模型的三个弱点你才知道后面技术为什么存在动手写代码之前我强烈建议你先花一天时间搞清楚大模型的工作原理。它不是一个数据库也不是搜索引擎它的本质是一个给定前文、预测下一个词的概率模型。这个底层机制决定了它有三个天然弱点第一知识有截止日期。模型只记得训练数据里出现过的东西训练完之后的世界它一无所知。你以为它在给你讲今天的新闻其实它在根据历史规律合理推测这跟编造只有一线之隔。第二幻觉是原生的。因为它本质是概率生成遇到不知道的事情它不会诚实地说不知道而是会生成一段听起来非常自信、逻辑自洽的内容。越是不懂越敢说。第三上下文窗口有限。模型能记住的上下文长度是有限制的几千到几万token不等。你不可能把一本书都塞进一次请求里更不可能让它记住上个星期的对话。理解这三点之后你会瞬间明白后续章节里的每个技术选择为什么要做RAG因为要补知识、治幻觉。为什么要做记忆系统因为上下文窗口装不下所有历史。为什么要做Agent循环因为一次调用只能做一件事复杂任务需要多次规划执行。2.2 Prompt不是说话是配方角色、任务、约束、示例缺一不可很多人把Prompt理解成跟模型好好说话这是最大的误区。Prompt的核心是配方——它是一份结构化的控制指令而不是一段聊天文本。我在实战中总结了一个四段式配方【角色】你是一位具备X领域经验的专业人士。 【背景】用户正在做某件事当前遇到了某类问题。 【任务】针对以下输入完成某个具体产出。 【约束】 - 输出必须包含哪些字段 - 不允许出现什么内容 - 如果信息不足应该怎么处理举个例子我要让模型帮忙做代码审查你是一位资深的前端开发者擅长分析React应用中的状态管理问题。 背景用户的项目在不该重新渲染的地方出现了频繁重渲染导致页面卡顿。 任务分析下面的组件代码找出可能导致重渲染的写法并给出修改建议。 约束 1. 先给出结论再给修改后的代码最后用100字以内解释原因。 2. 只关注性能问题不要修改业务逻辑。 3. 如果代码中没有明显问题明确说明未发现明显问题不要为了找问题而找问题。 组件代码 【待粘贴的代码】这个Prompt为什么有效因为它把模型知道的和我需要的之间的边界画清楚。特别是第三条约定了查不出问题就说查不出直接压制了幻觉的源头。2.3 Prompt调优里的4个坑我每个都踩过坑一指令堆叠导致模型选择困难。我早期写Prompt喜欢把几十条要求全塞进去结果模型反而忽略关键约束输出一些四不像。后来我把约束精简到5条以内并且把最重要的约束放到靠前的位置效果立刻提升。大模型对长Prompt里的细节本身就是选择性注意。坑二只写输出JSON但不给结构。解析永远是Prompt工程里最疼的问题。你告诉模型输出JSON它可能给你一个带注释的JSON、一个markdown包裹的JSON甚至一个漏了括号的JSON。后来我学会了在Prompt里直接给出JSON Schema或示例模板让模型照着填值解析成功率从60%直接跳到95%以上。坑三temperature设置永远用默认值。如果你的场景是数据抽取、格式转换temperature设为0.2以下会大幅降低随机性如果是头脑风暴类的创意生成调高到0.8以上才有惊喜。不少初学者不知道这个旋钮是干嘛的白白被随机性折磨。坑四没有输出校验环节。这里是工程思维和Demo思维的分水岭。线上应用必须在拿到模型输出之后加一层校验字段缺失就重新生成或走降级逻辑而不是拿着脏数据继续往下走。我记得有次线上问答应用把模型的幻觉输出直接存进了业务数据库排查了好几天才发现是输出校验缺失。3. RAG检索增强生成让模型学会先查资料再回答3.1 RAG要解决的核心问题与整体链路RAG这个名字听起来高大上拆开就是Retrieval-Augmented Generation检索增强生成。它做的事情用大白话讲在模型回答之前先从你自己的知识库里检索出相关的资料片段再把这些资料连同问题一起交给模型让它依据资料作答。这个技术之所以成为AI应用开发的标配是因为它同时解决了三个问题知识截止日期、私有领域知识缺失、以及幻觉。模型不用再猜测答案它会像开卷考试一样先把参考资料摆在眼前照着抄。RAG的整体链路是一个完整的数据管线跑通它你才算真正入了门文档加载 → 文本切分chunking → 向量化embedding → 存入向量库 → 用户提问时向量化问题 → 召回retrieval → 重排rerank可选 → 拼接Prompt交给LLM生成答案这八个环节里任何一个出了问题最终回答质量都会打折扣。而大多数人的RAG效果不好原因往往不在模型而在前面的数据环节。3.2 文档切分与向量化决定RAG效果的地基环节切分方式直接影响召回质量。我见过太多人直接把整本PDF丢进去切每500个token硬切一刀结果一句话被拦腰截断丢失语义。更合理的做法是按文档结构切先按标题分块每个标题下的内容作为一个语义完整的段落段落太长再按固定长度切并设置overlap重叠区域。overlap的作用是让相邻块之间保留上下文衔接避免一句话因为换块而失忆。关于chunk_size我给你一组经验值通用业务文档选300到600个token技术文档可以适当扩大如果文档里都是短段落200个token就够。不要迷信某个固定数值用你的真实数据跑一遍看看召回结果的命中情况再调。向量化模型的选择也很关键。不同embedding模型对中文的支持差异很大有的在中英混合场景表现非常差。建议用至少两个模型在你的业务数据上做一个召回对比不要只看网上谁火就选谁。向量模型输出的维度也影响存储成本768维和1536维的存储开销差一倍小项目够用就行别盲目上大模型。3.3 召回到生成之间的调优经验参数、重排与问题排查链路跑通之后就到了最磨人的调优阶段。我最常调的几个参数列成表格给你参考参数作用我的经验值chunk_size检索单元大小200-600 tokenchunk_overlap块间上下文重叠10%-20%top_k召回数量3-8 条temperature生成随机性0.1-0.3重排开关是否对召回结果精排数据量大时必须开一个值得单独提醒的参数是top_k。有些人以为召回越多越好一下子把top_k调到20结果Prompt被大量无关片段塞满模型反而抓不住重点回答质量直线下降。我先用top_k5做基线再逐步增减找到效果拐点。如果RAG效果不理想问题排查要按照数据 → 召回 → 生成的顺序拆解而不是一上来就怀疑模型看召回结果里有没有包含问题的关键段落。如果没有那是切分或向量化的问题去检查chunk大小、embedding模型和文档本身的格式。如果召回了但生成答案没用上那是Prompt组装的问题。很多框架默认的RAG模板要自己改你得明确要求模型只能依据提供的资料回答资料中没有的内容不要编造。如果上下文里有干扰信息那就考虑加重排或者动态调整召回阈值。记住一个排查原则召回决定上限生成决定下限。召回阶段就漏了后面再怎么调Prompt都是徒劳。4. Agent智能体从回答问题到主动完成任务4.1 Agent的本质模型从对话者变成执行者如果说RAG是让模型会查资料那么Agent就是让模型会干活。两者的思维模式完全不同在普通的对话场景里模型是一个回答者你说一句它答一句在Agent场景里模型变成了一个决策者和执行者你给它一个目标它自己拆解步骤、选择工具、执行动作、观察结果并在必要时调整计划直到完成任务或到达最大步数。Agent的核心组件就三个大模型作为大脑、工具集作为手脚、循环控制作为躯干。模型负责下一步该做什么工具负责把事儿做出来循环负责检查结果并决定是否继续。理解了这个结构你就知道为什么Agent的代码量其实不大难的是设计好它的思考边界和工具边界。工具不是越多越好你用到的场景大概就那几类查数据库的、调外部API的、算数据的、发消息的、控制浏览器的。每个工具都要有清晰的描述因为模型是靠描述来决定什么时候该调它的。4.2 用ReAct循环实现一个最小AgentReAct是目前最简单的Agent范式思路是让模型在每一步输出我想了什么Thought→ 我决定调用什么工具Action→ 我期待得到什么结果Action Input然后由程序去执行这个工具把观察结果Observation还给模型如此循环直到模型输出Finish。这里给你一个最小可运行的伪代码结构def run_agent(goal, tools, max_steps10): messages [{role: system, content: 你是任务规划与执行助手只能使用给定的工具完成任务。每次按格式输出Thought/Action/Action Input。}] for step in range(max_steps): response llm.chat(messages) messages.append({role: assistant, content: response}) action parse_action(response) # 解析Action字段 if action.type finish: return action.answer if action.type not in tools: messages.append({role: system, content: f工具{action.type}不存在请重新选择}) continue tool_result tools[action.type](action.args) messages.append({role: tool, content: tool_result}) return 任务未在最大步数内完成跑通这个最小Agent的关键在于行动输出格式必须极其严格。模型很擅长在Action里自由发挥用了各种不同的格式导致parse_action直接摔跟头。我的做法是在系统Prompt里给出一个标准输出模板并且每一轮都把上一个工具的结果原样放回上下文让模型的下一步决策有据可依。同时务必加上max_steps限制不然模型会在某些任务里无限循环白白消耗你的API预算。4.3 Agent失控的4个常见原因与工程防护Agent开发者的主要工作不是写代码而是防止模型胡来。我在项目里踩过的坑归纳下来就四种一是死循环。模型反复调用同一个工具得到相同结果然后再调用一次。防护办法是设置最大步数以及对重复动作做去重检测发现连续N次相同的调用就强制终止。二是动作格式漂移。前面几轮还规规矩矩按格式输出几轮之后就开始加注释、换措辞、甚至用markdown包裹动作。我的经验是不要在上下文里放太多无关历史每轮执行完把刚刚这一步的结果摘要放进去减少模型的发散空间。三是工具权限失控。给Agent的工具越多安全隐患越大。有一次我给Agent接了一个执行任意代码的工具它直接循环执行了几十次耗时的计算。现在我对每个工具都做白名单和参数校验能读不能写的绝不放开写权限能用只读查询的绝不给执行权限。最小权限原则在Agent场景里尤其重要。四是目标理解偏差。用户说的目标跟模型理解的目标经常不是一回事。比如帮我整理这份数据模型可能直接开始删数据而不是统计汇总。防护办法是在任务启动前加一个目标确认环节让模型先复述一遍它对任务的理解用户确认后再真正开跑。5. 记忆系统让AI应用从失忆到记事儿5.1 为什么需要单独的记忆系统设计你做过那种用户每次打开都得重新介绍自己的应用吗我做过效果非常糟糕。大模型的上下文窗口天然有限它天生是健忘的要想让应用有连续对话能力、个性化体验必须专门设计一套记忆机制。记忆系统要解决的问题有三类第一类是会话内的短期记忆比如用户刚刚说了什么这些内容要一直保留在上下文里第二类是跨会话的长期记忆比如用户一个月前说过的偏好、历史偏好、业务状态第三类是任务状态比如一个多步骤流程走到哪一步了中间产出的临时数据放在哪。没有记忆系统的AI应用就像一个每次见面都假装不认识你的客服用户用两次就烦了。有了记忆系统应用才可能从能用升级到好用。5.2 短期、长期、工作记忆的工程实现方案短期记忆是最简单的直接把对话历史作为消息数组传给模型。但要注意上下文窗口有限不可能无限累积所以通常的做法是只保留最近N轮对话更早的内容做摘要压缩。你可以用模型把前面的对话生成一个对话小结在下一轮放进system message里这样既保留关键信息又省token。长期记忆的通用方案是向量数据库 结构化数据库组合把用户说过的重要事实、历史操作、偏好摘要存成两类数据——结构化的字段比如用户ID、创建时间、偏好标签放关系型数据库叙事性的内容比如上次讨论过某项目的技术选型向量化之后放进向量数据库。等到新对话开始时系统用当前问题去检索相关的历史记忆把命中结果注入Prompt。工作记忆管理的是当前任务的状态最简单的实现是一个JSON文档或一张任务状态表记录任务ID、当前阶段、已完成步骤、下一步动作、已完成的结果。Agent每执行一步更新一次状态表任务中断后重新拉起可以从状态表恢复进度。5.3 记忆的写入、召回与更新一个轻量级设计给你一个可以直接抄作业的轻量级记忆模块设计思路class MemoryService: def __init__(self, sqlite_path, vector_store): self.db sqlite_path # 结构化信息 self.vectors vector_store # 语义记忆 def save_interaction(self, user_id, query, response, important_facts): # 1. 把important_facts存入SQLite作为带标签的结构化记忆 # 2. 把queryresponse写入向量库作为可检索的语义记忆 # 3. 触发一次记忆摘要更新合并旧的摘要与本次新内容 def recall(self, user_id, query, top_k5): # 1. 先从SQLite取出用户标签/画像 # 2. 再从向量库召回语义相似的历史交互 # 3. 合并两组结果按时间衰减权重返回给上层这里有一个时间衰减权重的细节值得展开长期记忆不能平等对待。三个月前的偏好可能早变了但用户当前项目使用的技术栈这类短期事实反而更准确。我的做法是在召回时对记忆打一个时间衰减系数近7天的记忆权重给1.030天前降到0.590天前降到0.2再用这个权重参与排序。这样既保留长期画像又不会被过期信息误导。5.4 记忆场景里容易被忽视的3个问题记忆系统做出来不难做对很难。三个问题我建议你提前想清楚不然后面早晚返工。一是隐私合规。你存了用户多少历史对话就必须承担起保护这些数据的责任。用户在设置里关闭记忆功能时你真能把他所有记忆痕迹删干净吗设计阶段就要把删除逻辑做进去而不是事后补救。二是记忆污染。模型提取重要事实的过程可能出错它可能把用户随口说的一句话当成事实存下来然后在下一次对话里用它作为推理依据错误就被放大了。我的应对方案是记忆写入前加一个置信度门槛只有模型判断为明确提出且对后续对话有影响的内容才入长期记忆。三是记忆检索失败不能影响主流程。如果召回记忆的服务超时或者返回空结果应用应该优雅降级到普通对话模式而不是直接抛错。做个简单的try-except让用户感知不到技术故障只把他当成第一次对话的正常人。6. 开发框架、向量数据库与环境准备少走弯路的关键选型6.1 先写原生代码再上框架理解永远比工具重要聊到工具链之前我想先说一个反常识的建议学习阶段不管框架多方便都先写一遍不依赖框架的原生代码。我见过太多框架熟练工会用LangChain的链式调用却不知道一个RAG请求真正经历了哪些环节出了问题只能网上搜搜索不到就彻底卡住。用原生API把第三节里那个RAG链路完整写一遍把Agent循环自己实现一遍你会发现框架只是个封装底层逻辑一点都不神秘。这不是说框架不好而是说理解要在抽象之前。框架帮你省掉的重复劳动建立在你已经理解它帮你做了什么事的前提下。否则你省掉的不是麻烦是理解。6.2 主流框架与向量数据库怎么选开发框架我用自己的经验给你一个客观的评价框架/工具定位适用场景注意事项LangChain这类编排框架全链路组件编排项目里组件多、集成复杂版本更新频繁抽象层多排错成本高LlamaIndex这类数据索引框架文档索引与RAG知识库密集、召回场景多索引优化方便Agent能力不如通用编排框架原生代码 必要库自由可控学习原理、做精细定制代码量大但最透明Chroma/FAISS轻量向量存储Demo、中小规模简单易用数据量大要换分布式方案Milvus这类分布式向量库生产级向量存储大规模、高并发部署运维成本高初创期别急着上我的项目选型原则很简单Demo期怎么做最简怎么做上线前再根据真实瓶颈做取舍。不要因为某个框架未来能扩展到百万数据量就在第一天选它你的第一个版本可能连一千条文档都没有。过早引入重型基础设施只会拖慢迭代速度。6.3 环境准备虚拟环境、依赖管理与密钥管理很多教程跳过了环境配置直接到代码结果新手第一步就摔跤。这里给你一份足够稳的准备流程# 1. 创建并激活虚拟环境 python -m venv venv source venv/bin/activate # 2. 安装核心依赖按需增减版本号 pip install openai python-dotenv pip install langchain chromadb tiktoken # 3. 用.env管理密钥绝不要写进代码 echo OPENAI_API_KEYsk-xxx .env在密钥管理上我说个血的教训有一次我把API密钥直接写进了共享的代码仓库不到两小时就被扫描程序捞走了当天账单直接爆掉。现在我的所有密钥都放环境变量或密钥管理服务里代码仓库里只放.env.example模板并且把.env加进.gitignore。这类事一次都赌不起新手尤其要养成习惯。7. 小白7天入门路线与避坑清单7.1 7天路线图每天学什么、交付什么如果你完全没有经验又想快速建立完整的动手能力我建议你按下面这份路线走。每一天的产出都是一个能跑的东西而不是看完了某个文档。天数学习主题当日交付物Day 1LLM API调用与基础认知用代码完成一次真实的模型调用拿到回复Day 2Prompt工程针对一个具体场景写出一套四段式Prompt并验证稳定性Day 3RAG最小实现加载3个文档跑通检索生成问答Day 4向量化与检索调优调整chunk方式对比检索结果并记录差异Day 5Agent最小实现让模型能调用两个工具完成查询天气并整理成日报Day 6记忆系统实现跨对话记住用户名字与偏好的DemoDay 7综合项目做一个带记忆的、可回答私有知识的、能调用工具的助手到了第7天你其实已经把7大核心领域的核心串起来了。这个综合项目不用大但一定要完整。7.2 我给新手的10条避坑建议别在没跑通Demo前纠结最优架构。架构是为可维护性服务的你的第一版还没有维护负担。别把大模型当数据库用。事实查询交给RAG或传统存储模型只负责理解和生成。别忽略输出校验。模型输出是概率性正确必须有程序层面的兜底。别把密钥写进代码。一次泄露就可能被薅掉大量API额度。一定要设计日志。模型输入输出、耗时、成本、召回结果全都要留痕不然线上问题无从查起。别盲目追逐最新版本。框架大版本升级经常破坏API能用稳定的就别当小白鼠。密切关注上下文长度与成本。同样功能不同Prompt方案token消耗能差好几倍。先保证召回质量再调生成效果。RAG系统里召回是根生成是叶。做好输入输出的Schema校验。非结构化数据是系统地雷。给自己定义一个最小可用标准别憋大招。7天学不会完美但完全足够学完能跑通。7.3 从跑通Demo到做成产品评估、监控与成本很多人的项目止步在Demo是因为没有往下走产品化的那几步。第一个要解决的是效果评估。RAG系统不能只靠感觉回答得还行要建立一批测试问题集给每个问题标注标准答案自动记录模型的回答、召回结果、准确率和漏检率。我一般准备50到100条线上真实问题作为评测集每次改参数都重新跑一遍用自己的评测数据判断改动方向而不是拍脑袋。第二个是监控。上线之后至少要看三件事API调用的成功率与延迟、用户真实Query里的Bad Case、每天的token消耗成本。我见过不少团队模型表现时好时坏却毫无察觉等用户投诉了才去翻日志非常被动。第三个是成本控制。大模型API的账单是按token算的而在Agent和RAG场景里每次任务动辄消耗几万token。如果不做缓存、不做上下文压缩、不限制Agent最大步数一个看起来很简单的功能也能烧出让你肉疼的费用。建议从第一天就养成记录token的习惯。我在做综合项目的阶段最大的体会是把上面这些无聊的工程问题处理好反而比追求更花哨的模型能力提升更快。因为产品体验的短板往往不在模型的聪明程度而在工程链路的可靠性。最后再分享一个实际项目里被验证过的小技巧把项目中的Prompt模板、参数配置、知识库版本全部纳入版本管理。模型效果和Prompt文本强相关你改了Prompt却说不清改了什么回滚和排查都会变成灾难。哪怕只是加了一个换行符也记录下来。AI开发很多时候不是一次写好而是持续调对而调对的前提是每一次改动都留痕。这条习惯越早养成越受益。
阅读完成 · 觉得有帮助？
