最近有朋友问我说现在谈AI应用开发动不动就是 Agent、RAG、LLM 三个词捆在一起到底是什么意思是不是要把三个系统都从零写一遍才算懂如果是个刚入门的程序员该怎么理解这套“三核驱动架构”的演进这个问题其实问得很好。我自己的理解是LLM 是大脑RAG 是外接的知识库和记忆Agent 是调度中心。三者不是为了拼概念凑在一起的而是层层递进、互相补齐短板。早期我刚开始做AI应用时也以为只要把模型接上就完事了后来踩过不少坑才发现真正能落地的应用基本都会走到 Agent LLM RAG 这个组合上。这篇文章我把演进过程、核心模块、最小可跑通的方案和常见问题一次讲透适合那些想从“调API”进阶到“搭应用架构”的朋友。1. 为什么是“三核驱动”而不是“模型为王”很多刚接触这一行的开发者会有个惯性思维选个聪明的大模型问题就解决了。实际上模型只解决“下一步该输出什么token”的问题不解决“信息从哪来”“动作怎么做”“连续任务怎么拆解”这类工程问题。现在的 AI 应用本质上是一个把模型、知识和行动串起来的系统中枢。1.1 单独用LLM就像让实习生直接上产线我习惯把大语言模型比作名校毕业但没有任何行业经验的实习生知识量巨大、理解力强、表达流利但一问到2023年之后的事它就犯难再问到企业内部某个流程文档它更是完全没见过。这里涉及一个核心概念——预训练的知识截止点。模型在训练阶段见过大量公开语料之后的实时数据和私有数据它根本没接触过。很多刚入行的朋友第一次做知识库问答时问模型“我们公司的报销流程是什么”得到的答案是一段很像那么回事的、但完全编造的流程说明这就是典型的幻觉问题。另一方LLM 本身也不擅长多轮、长链条的决策。比如“帮我查一下订单状态如果延误超过一天就申请退款再发一封邮件通知用户”这样一个简单的三步任务如果只靠一次 Prompt 输出模型经常会漏步骤或者顺序搞错。它并不是逻辑能力差而是缺少“分步执行”和“检查中间结果”的机制。1.2 RAG解决的是一件事让模型“知道它不知道的”RAG 全称是检索增强生成核心思路一句话在模型回答之前先去外部资料库查一圈把相关的片段拿回来塞进上下文里再让模型基于这些片段作答。这就像实习生上岗前公司没指望他脑子里自带流程而是塞了一本非常厚的操作手册让他每次回答前先把对应章节翻出来照着讲。优点是回答有据可依来源可控而且不需要重新训练模型就能让模型掌握新知识。在实际项目中RAG 约等于把“存储”和“推理”分开文档切片、向量化、索引、检索、重排最后把命中的内容作为上下文交给LLM。这套链路每个环节都有坑比如切块粒度太大导致上下文超长切太碎导致语义断裂召回不够精准导致模型只能基于残缺信息硬编。很多“好像回答得不太对”的问题根子其实不在模型而在检索质量。1.3 Agent真正带来的是从“会说话”到“会干活”Agent智能体的核心不在于“更聪明的对话”而在于“把任务拆解出来后去执行”。它会把用户的一句话变成行动计划决定什么时候调用搜索、什么时候查数据库、什么时候写文件再根据每一步的结果动态调整下一轮行为。如果说 RAG 是给模型递资料Agent 就是给模型发了一套工具还给了它一张任务清单。典型结构包括任务规划器、工具注册中心、执行器、短期工作记忆。任务规划器负责将“帮我处理退款”拆成“查订单”“判断状态”“执行退款”“通知用户”工具注册中心维护了一张“有哪些能力可用”的清单执行器则按照规划逐个调用工具每一步都拿到真实返回值。把 Agent、LLM、RAG 三个概念放到一起看其实就形成了一个闭环Agent 从上游任务里提炼出决策路径LLM 负责每个决策点上的语义理解和生成RAG 在需要知识时把最相关的资料送到模型眼前三者各司其职这就是现在主流AI应用的基本运转逻辑。2. 架构演进四阶段每一步都是被真实需求逼出来的技术演进从不靠概念驱动靠的是实际需求倒逼。我这个理解纯属个人总结但基本符合当下大家普遍认可的路线单模型裸奔 → 接RAG → 上Agent → 三核融合。2.1 第一阶段语言模型单打独斗刚开始接触AI应用开发时大部分人的第一个Demo都是类似的把用户问题拼到 Prompt 里请求模型返回回答。有的模型当时已经很强但你只要问两类问题它就会露馅一类是“今天/上周”这种时效性问题。模型的知识是快照式的它无法凭空知道最新事件又为了让回答显得完整就会自己编一段看起来很权威的内容。这就是幻觉的直接原因。另一类是私有领域知识。比如把内部规章制度文档做成一个问答系统模型压根没见过这些文档你问什么它都只能按常识答结果在业务上基本不可用。这个阶段的架构非常简单但问题也非常明显没有记忆、没有知识来源、没有工具调用遇到需要“事后更新”的知识场景全部失灵。2.2 第二阶段加上RAG这个“外挂知识库”RAG 出现后模板变成了用户问题 → 向量检索 → 相关片段 → 拼接Prompt → 模型生成。这一步解决了“信息怎么进模型”的问题。我当时第一次做知识库问答时用了某个开源向量数据库加载了一批产品文档每个段落切成若干个块转成向量存储回答时先把问题转向量再检索top-k然后拼进Prompt。效果相比裸奔模型是质的飞跃引用真实文档后回答不再天马行空。但新的问题又来了用户未必只想“问知识”还需要“办事”。比如客服场景里用户问“我的退款到底什么时候到账”这不仅需要查知识文档还需要真正查库里这张订单的状态然后给出针对性答复。RAG 本身是不具备调用外部接口能力的它只能把“你知道什么”做得更好但没办法触及“你能做什么”。这一步是Agent进入架构的契机。2.3 第三阶段Agent让模型长出“手脚”Agent 让模型从“回答问题”上升到“完成任务”。当时我做过一个内部工单处理助手用户描述问题后Agent 判断要不要调用工单查询接口、要不要自动创建工单、要不要把结果写入进度表每一步通过调用预先注册好的函数实现而不是靠LLM直接编答案。这个阶段有个非常明显的感受模型的推理能力终于被用在“决策链路”上了而不是只用来“写句子”。但意外情况也很多——当Agent需要回答一个涉及具体业务术语的问题时因为它缺少领域知识经常给出错误的拆解方向。比如把“退款状态”误判成“订单类型”这种概念性的偏差。所以单纯 Agent 能干活但方向感会跑偏。它需要一个知识源在每步推理时不断校准RAG 的价值第二次体现出来给决策提供上下文依据。2.4 第四阶段三个核心协同的现代形态到了现在这个阶段比较主流的架构就是把两者串起来用户输入进入 AgentAgent 的规划模块明确当前步骤需要什么信息如果发现该步骤包含业务实体或领域术语就会触发 RAG 去检索相应资料检索结果连同当前任务状态一起交给 LLM由 LLM 生成下一步行动工具执行的真实返回值再返回给 Agent循环往复直到任务完成。我画过一张简化的流程图来表达这个过程接收用户请求判断是否需要外部知识、是否需要调用工具。若需要知识支撑先查询向量库召回相关片段并重排。将“背景知识 历史对话摘要 用户目标”组装成当前步骤的Prompt。模型输出结构化决策比如JSON格式解析出工具名和参数。执行工具拿到真实数据判断是否还需要补充知识若需要再回第2步。直到满足结束条件生成最终回复。这个形态已经不是一个单纯的“问答系统”了更像一个可以感知资料、执行操作、自我校验的智能服务工作流。3. 三核各自的内功模型、检索、编排的核心选型逻辑理解了架构之后下一步就是动手选型和落地。很多新手一上来就卡在“选什么模型”“向量库用什么”“Agent框架怎么写”这里我按三个核心模块分别拆解。3.1 模型选型不是越大越好是越合适越好LLM 是三核里最被关注的但也是最好决策的。选型主要看四个点上下文窗口决定了你能塞多少知识片段和工具返回结果。想省事就选长上下文但成本会随窗口非线性上升不是越长越好。工具调用能力是否支持标准的工具调用格式能否稳定输出结构化参数这是Agent能否跑通的关键。指令遵循与结构化输出你是否能让模型稳定输出符合你定义的JSON或函数签名直接决定你的解析层容错复杂度。成本与响应速度线上业务场景每秒并发一高模型推理耗时和价格就是生死线。很多实际场景选择“主力模型轻量分流”的策略小模型过滤简单问题大模型处理复杂推理。我一般会给团队建议如果你做企业内部工具而不是面向全球用户的通用助手一个中杯尺寸的开源模型部署在私有环境往往比调用商用API更可控但如果你只是做Demo验证商用API的快上手优势就很明显。没有唯一正确的答案只有合适不合适。3.2 检索链路切块、向量化和召回重排的细节RAG 这部分是最容易出现“看似能用实际一测就崩”的环节。我把它拆成数据准备、入库、检索三个阶段。数据准备阶段的切块很多人直接按固定token数切结果常常把一个完整表格从中间切断或把一个业务流程的第三步单独隔开检索时语义碎了一地。我常用的做法是优先按文档结构切分比如标题、段落、列表项、表格行。对于一个章节如果超过阈值再二次切分并保留上下文描述。这样能最大程度保证每个片段都是自洽的信息单元。向量化阶段要看嵌入模型质量。不要只看榜单分数要做一次实际召回测试准备几个典型用户问题查几个真正的相似片段肉眼判断有没有召回真正有用的内容。这块是纯工程手感多测几次就明白了。检索阶段最容易被忽视的是重排。向量召回只能保证“语义相似”但不保证“对当前问题最有用”。很多系统召回top-20直接把全部塞给模型上下文被无关内容撑爆回答质量反而下降。更合理的流程是先用快而便宜的向量召回和关键词召回拿到候选集再用一个精排模型对候选进行相关性打分最后只保留top-3或top-5进Prompt。3.3 Agent编排规划、工具注册、记忆管理的实现方式Agent 的开发框架很多但核心概念基本一致。我自己的实现习惯是三个部分第一部分是任务规划。最粗浅的做法是让模型直接输出 JSON 格式的步骤数组复杂一点的做法是把一个大任务拆成阶段性子任务每个任务都带状态。新手最容易犯的错是让Agent一次性生成所有步骤然后按步骤盲走。真实场景中后续步骤往往依赖前面工具返回的实际结果所以更好的方式是“边执行边规划”每完成一步把结果总结后重新评估下一步。第二部分是工具注册。每个工具的元信息要包含工具名、功能描述、参数Schema、返回结构。模型的工具选择能力完全依赖这些描述的清晰程度。描述写得像废话模型就会选择错误的工具或者干脆不停问你。这里值得多花时间打磨。第三部分是记忆管理。短期工作记忆保存当前任务的关键信息比如订单号、用户ID、中间结果长期记忆则可以沉淀用户偏好或历史处理模式。很多项目上来就做长期记忆其实短期工作记忆才是保证任务不跑偏的基石先扎实做好短时记忆再谈更高级的记忆机制。4. 最小三核架构实操做一个能服务的知识库Agent理论讲再多不如跑一个最小可运行的Demo。下面这套是我在本地做验证时常用的方案简化过但完整具备“知识推理行动”三要素。4.1 整体项目结构与选型说明我建议的技术栈组合是一个具备工具调用能力的开源对话模型一个轻量级向量数据库一个支持函数调用的 Agent 编排框架。项目目录结构大概长这样mini_agent/ ├── config.yaml ├── data/ │ ├── policies/ # 业务知识文档 │ └── processed_chunks/ # 切分后的片段 ├── src/ │ ├── indexer.py # 文档切分、向量化、入库 │ ├── retriever.py # 召回重排 │ ├── tools.py # 工具定义 │ ├── agent.py # Agent编排主逻辑 │ └── main.py # 交互入口 ├── requirements.txt └── run.sh这几个模块的职责单一indexer 建索引retriever 提供知识tools 提供可执行操作agent 负责决策调度。数据层和逻辑层分离后后续替换任何一个组件都方便。选型时有一个我后来才意识到的心得向量数据库不要选最大最重的选一个文件型、部署零成本的轻量方案就够了。数据量到了百万级再迁移不迟前期Quick Proto最重要。4.2 索引构建把业务文档转换成可检索的知识底座我用一个模拟场景来说明某公司的客服知识库里面有“退款政策”“发货时效说明”“保价规则”三份文档。我要做个客服助手能回答这些规则也能查询模拟订单。第一步是切块。我按 Markdown 的二级标题分块每块最大约800字符超过则按句子再切但保留所在章节的标题作为上下文前缀。# src/indexer.py import os from typing import List def split_markdown_by_sections(text: str) - List[str]: chunks [] current_section 通用 current_buffer [] for line in text.splitlines(): if line.startswith(## ): if current_buffer: chunks.append(current_section \n \n.join(current_buffer)) current_section line.strip(# ) current_buffer [] else: current_buffer.append(line) if current_buffer: chunks.append(current_section \n \n.join(current_buffer)) return chunks第二步是向量化直接调某个通用的嵌入模型接口把上面拿到的chunk变成向量。入库时除了向量还要保存文本内容、来源文件名、章节标题等元信息便于之后溯源。# src/indexer.py 续 def build_index(doc_dir: str, embedder, vector_store) - None: for fname in os.listdir(doc_dir): text open(os.path.join(doc_dir, fname), encodingutf-8).read() for chunk in split_markdown_by_sections(text): vector embedder.embed_query(chunk) vector_store.add_item( vectorvector, payload{ text: chunk, source: fname, } )这里要注意一个实践细节嵌入模型的选择要和你真实场景的数据类型对齐。如果文档里有大量中英混排的表格用纯中文优化的嵌入模型效果往往比通用模型好很多。4.3 工具定义让Agent拥有查询与操作能力接下来定义两个模拟工具一个是查询订单状态的函数一个是计算退款金额的函数。为了让Agent能稳定调用我把每个工具都包装成带Schema的注册结构。# src/tools.py import json def get_order_status(order_id: str) - dict: # 模拟真实订单系统 fake_table { A1001: {status: shipped, days: 3}, A1002: {status: delivered, days: 1}, A1003: {status: delayed, days: 5}, } return fake_table.get(order_id, {status: not_found, days: 0}) def calculate_refund(order_id: str, reason: str) - dict: status get_order_status(order_id) if reason delay and status[days] 2: refund 20.0 else: refund 0.0 return {order_id: order_id, refund_amount: refund} TOOL_SCHEMAS [ { name: get_order_status, description: 根据订单号查询订单当前状态和物流天数, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } }, { name: calculate_refund, description: 根据订单号和原因计算退款金额, parameters: { type: object, properties: { order_id: {type: string}, reason: {type: string} }, required: [order_id, reason] } } ] TOOL_FUNCS { get_order_status: get_order_status, calculate_refund: calculate_refund, }工具描述要写清楚“它是什么、适合在什么时候调用、参数含义”。模型在规划时真的会逐字读这些描述一个描述模糊的工具可能永远不被调用。4.4 跑通全链路从一句话到一次完整服务流转主流程我的写法是用户输入→召回相关知识→Agent规划→循环调用工具→汇总回复。这里先走一遍模拟场景。# src/agent.py def run_once(user_query: str, memory: dict) - str: # 1. RAG召回 knowledge retriever.retrieve(user_query, top_k3) system build_system_prompt(knowledge, TOOL_SCHEMAS) messages [ {role: system, content: system}, {role: user, content: user_query}, ] # 2. Agent循环 for step in range(MAX_STEPS): resp llm.chat(messages, toolsTOOL_SCHEMAS) if resp.has_tool_call: tool_name resp.tool_name args json.loads(resp.tool_args) result TOOL_FUNCS[tool_name](**args) messages.append(resp.message) messages.append({ role: tool, tool_call_id: resp.tool_call_id, content: json.dumps(result, ensure_asciiFalse) }) memory[last_tool_result] result continue # 3. 没有工具调用时说明Agent认为可以最终回答 return resp.content return 任务步骤较多请尝试拆分子任务后重试。测试一下输入“我的订单A1002已经超过两天了还没收到我能退款吗”。第一步Retriever 召回“发货时效说明”和“退款政策”相关片段。第二步Agent 规划后先调用 get_order_status 查询订单返回 delivered、1天说明其实已签收于是重新评估发现用户说的“超过两天”不成立最终回答“该订单状态显示已签收尚未超过退款政策中约定的延迟条件因此不满足退款条件”。全程没有让模型硬编答案而是基于真实工具返回结果做结论这就是三核协同的意义。5. 落地过程中的高频问题与排查手册这部分是领导价值所在。跑通Demo只是第一步真正让系统在业务场景稳定工作一定会遇到各种边界问题。以下是我在实际项目中反复见过的问题整理成一套高频排查要点。5.1 答非所问召回环节怎么排查现象用户问“退款需要什么条件”系统回复了一段关于售后的泛泛规则看起来相关但完全没击中要害。这类问题八成出在 RAG 召回阶段。我排查顺序是先看切片质量相关条款是否被切散是否被错误归入其他章节。再看召回结果把用户问题转成向量后在向量库里查top-5肉眼看每个结果是否相关。最后看重排策略top-5里高分段是否有正确片段重排模型有没有把最优片段压到后面。如果召回结果本身不相关那就是前期数据清洗和切分策略问题如果召回相关但最终回答跑偏则可能是Prompt里知识片段太多模型注意力被无关内容干扰。5.2 Agent转圈死循环和工具调用失败的应对现象Agent 不停调用同一个工具参数还略有变化或者某次工具返回异常Agent 也不汇报而是反复尝试其他工具最后超时。我的处理办法设置最大轮次限制比如6次工具调用后强制结束并提示“请简化你的操作方案”。每个工具加上错误返回结构工具内部异常时返回一个带错误码的dict而不是抛异常让Agent能“看到”失败原因并调整。在Prompt里强制要求同一个工具最多调用两次两次后必须更换策略或转为人工介入。这里有个细节工具返回内容也要设计“人话”。如果返回的是一个嵌套很深的JSON模型读起来费劲也容易误判。比较好的做法是把关键信息提炼成简单文本或扁平JSON再交给模型。5.3 成本失控如何把单次对话的花费用在刀刃上现象功能很好但一聊起来上下文越堆越长每轮请求的token数不断膨胀费用成倍增长。原因多半是历史对话和工具返回结果一直在累加。对策有三个层次轻量层简单问候、功能导航类问题由一个小模型处理不进复杂链路。压缩层每次工具调用后对返回结果做摘要只保留关键结论进上下文而不是保留原始JSON。截断层历史对话超过阈值时用“近期目标最新结果”替代完整历史短期内只需保住当前任务的连续性。很多成本问题不是选的模型太贵而是上下文管理太粗糙。5.4 一套自查清单出问题先查这五件事现象排查方向常见根因回答内容泛泛RAG是否真正命中知识切片粒度不合理、嵌入模型不匹配回答包含错误数据是否调用了正确工具工具描述不清、参数Schema有问题Agent 反复调用工具规划逻辑缺乏约束缺少轮次限制和重复调用检查上下文超长历史与工具结果膨胀缺少摘要压缩和截断策略模型答非所问Prompt中上下文过载召回片段太多重点信息淹没这张表我一直贴在项目看板上线上反馈处理不过来时先按表里的方向定位比每次从头捋代码快很多。最后再分享一个小技巧如果只给一条建议先别急着把 Agent 做得复杂。我见过很多项目一开始就上了全套“多智能体协作长期记忆”结果连最基础的知识问答准确性都没过关。更稳妥的打法是先把 RAG 调到足够稳再给 Agent 加一个工具让它在真实链路里跑两星期看日志、看错误率再逐步扩展。这样每一步都是可回退的不会一上来就被一堆不确定性淹没。架构演进到这个阶段三核联动已经不是“要不要用”的问题而是“怎么组织好”的问题。对小白程序员来说理解好这三个角色的分工比看懂某一段新框架代码重要得多。