最近在技术社区里被问到最多的问题就是AI工程到底怎么学大家搜出来的路线往往是“先学Python再啃PyTorch然后从Transformer原理开始”这套路径不能说错但它更像算法研究员的成长路线。真正做AI工程的人日常打交道的是RAG流水线、Agent工具调用、评估集设计、上下文截断、接口延迟和token账单这些内容在传统机器学习教程里几乎找不到系统化的整理。我花了大半年时间把从零进入AI工程的经验沉淀成了自己的项目取了个名字就叫ai-engineering-from-scratch这篇博文就是把项目背后的路线、选型和踩坑一并拆开来讲。这篇文章适合两类人一类是想从后端、前端转过来的软件工程师另一类是被“算法”两个字劝退、但对AI应用开发有强烈兴趣的同学。我不会聊模型训练细节也不会推损失函数公式重点是工程化思维、可复现的实操步骤以及怎么把一个带RAG和工具调用的系统真正跑起来。1. AI工程不是“算法岗换皮”它在解决完全不同的问题1.1 和传统机器学习工程的区别在哪很多想入行的人问我的第一句话是“做AI工程是不是得先把机器学习基础打好”这个问题的前提就已经错了。传统机器学习工程的工作链路是收集数据、做特征工程、选模型、训练、调参、评估指标、部署上线最后交付的“成果”是一个推理模型。而AI工程的工作链路是基于现成的强大模型GPT、Claude、Qwen、GLM这些把它当作一个智力组件去搭建一套能够完成实际任务的系统最后交付的是一个“系统”。这个区别带来的是完全不同的思维方式。做ML工程时你担心的是模型AUC不够高、特征泄漏、过拟合做AI工程时你担心的是提示词在什么情况下会崩、检索回来的资料是否准确、工具调用失败了怎么办、这个功能跑一次要烧多少token。换句话说ML工程是在“造一个更聪明的脑袋”AI工程是在“给现有的聪明脑袋配上手脚、资料库和验收流程”。我用一个比较接地气的类比传统软件开发是写死流程像给员工发一份非常详细的标准作业手册每一步都写得明明白白AI工程更像是给员工一个模糊的目标他需要自己判断该查哪些资料、该调用哪些工具、该怎样组织回答而你作为开发者的任务是确保他手里的资料足够准确、工具足够顺手、干坏了有兜底方案。这个类比在做Agent设计时尤其重要。1.2 AI工程师真正要会的东西我把AI工程涉及的能力拆成了一张清单方便你对照自己目前缺什么模型接口调用与参数控制HTTP调用、SDK使用、temperature/max_tokens/top_p的含义结构化输出JSON模式、函数调用Function/Tool Calling、输出校验提示词工程系统提示词设计、少样本示例、上下文管理检索增强RAG文档解析、文本分块、向量化、召回排序、相关性判断Agent循环ReAct模式、工具注册、多轮状态管理、失败重试评估体系评估集构建、自动断言、模型评分、回归测试可观测性与成本控制日志、追踪、token计量、缓存与限流。这里面有哪一条需要你推公式都没有。它更像后端工程和产品逻辑的结合体。听到“不用深入研究反向传播”的时候很多人松了一口气但我也要说实话不推公式不代表不需要理解基本概念。你需要知道向量是什么、相似度怎么算、上下文窗口意味着什么这些在后续使用embedding和设计提示词时都会直接碰到。理解到什么程度会用、会调试就够不需要能从零推导。2. 从零开始的第一阶段把心智模型从“训练模型”切换到“设计系统”2.1 先建立一个正确的系统心智模型动手写代码之前我先建议你做一个思维转换。我记得自己刚开始学的时候总把“调用一次大模型”当成“完成一个功能”后来发现这个理解会处处碰壁。单次调用不是系统单次调用只是系统里的一个齿轮。真正的AI工程系统至少要包含五个环节输入解析把用户的原始需求转化成能被模型理解的结构化指令上下文构建决定哪些资料、哪种背景信息应该被塞进这一次调用推理决策模型基于上下文产出回答或决定调用工具执行动作如果模型决定调用工具系统去执行真实的API操作查库、查订单、发消息结果校验对模型输出做格式检查、内容验证不合格就触发重试或降级。这五个环节串起来才叫一个AI应用。学AI工程最重要的不是记住某个框架的API而是把这五个环节的每个衔接点想明白什么情况下会断断了之后怎么接上。很多人上来就学LangChain结果连“为什么一个Chain需要那么多步骤”“为什么Retriever的返回要重新加工”都搞不清楚出了问题只能到处问。2.2 前置知识到底需要多少数学我可以直接给结论不需要高深数学。需要掌握的是三个基本概念每一个都是工程直觉层面就能理解的向量与相似度embedding把文本变成一串数字检索本质上是算“哪两串数字长得最像”你会用余弦相似度即可概率与置信度模型输出的是概率分布所以同一个问题在不同次调用可能得到不同答案这决定了你必须设计重试机制统计思维评估系统好坏不是看一两个用例而是要准备一组有代表性的问题综合计算通过率。至于线性代数的严格推导、概率论的完备体系这些可以等以后真的需要时再补。我更建议你把时间花在Python基础、HTTP与JSON接口调用这些“工程日常”上。说实话我见过太多人在数学上原地打转迟迟不敢动手调接口结果浪费了整整一个月。2.3 动手前先亲手调通一次API理论说再多都不如亲手调通一次接口来得实在。注册一个大模型平台的API用Python发起第一次对话请求把返回的JSON结构打印出来看一遍。这一步的目的有三个第一破除“模型很神秘”的心理障碍第二亲眼看到请求参数和返回结构后面做结构化输出才有直观载体第三体会token是怎么计算的——同一个接口返回内容变长账单数字也在变这是你建立成本意识的第一步。我强烈建议在这个阶段就把temperature、max_tokens、top_p这三个参数各玩一遍。把temperature调到0和调到1.5分别生成同一道题的回答对比结果的稳定性和创造性你就能直观理解“可控性”和“多样性”之间的张力。这一课比读十篇参数文档都管用。3. 四阶段学习路线图从结构化输出到一个能交付的Agent系统3.1 阶段一输出可控是地基很多人学AI应用开发第一个项目就做聊天机器人这是我觉得最不推荐的方式。聊天机器人看起来简单但它的评估太难了——怎么算答得好怎么算答得差对话长了之后上下文怎么管理这些全是复杂问题。从工程训练的角度我建议第一个目标小而明确把用户的自然语言输入转成一个结构化的JSON输出。举个例子写一个函数输入“帮我订一张周五下午去杭州的火车票”输出{ intent: book_train, params: { destination: 杭州, time: 周五下午 } }这个功能很小但你要处理至少三个问题怎么让模型稳定输出合法JSON、怎么处理模型偶尔输出无关文字的情况、怎么校验和兜底。这三个问题一旦解决你就掌握了AI工程里最常用的一环——结构化输出后续所有Agent和工具调用都建立在这一能力上。我自己的体会是模型返回“看起来合法、但字段值完全不对”的JSON比返回乱码更危险。比如它把“杭州”解析成“hangzhou”字段对但值错了程序不会报错结果却是错的。所以从第一个项目开始就必须引入校验层这个习惯会一直伴随你。3.2 阶段二RAG让你的系统“有资料可用”第二个阶段做检索增强生成。为什么需要RAG因为模型训练完知识就冻结在某个时间点了而且它的训练语料不一定包含你的业务数据。RAG的思路很直白先在外部建立知识库用户提问时把相关的资料片段检索出来连同问题一起交给模型让它“看着资料回答”。最经典的入门项目是把一个公司员工手册或者任意一份Markdown文档做成一个能回答问题的助手。看起来简单实际做起来全是细节分块策略整篇塞进上下文不可能切小了又会把完整语义切断我试过200字、500字、1000字几种块大小对同一个文档回答质量差别很大需要测重叠设计相邻块之间重叠几十个字能减少切断句子造成的召回遗漏Embedding选型不同embedding模型对中文的支持差异很大需要拿你的真实文档跑一圈对比相关度阈值低于多少分的检索结果不应该送给模型这是防止幻觉的第一步参考答案比对同一个问题直接问模型和“带资料回答”质量差距肉眼可见这个对比做一次就能理解RAG的价值。这一步做完你的系统开始有“知识”了不再是一个纯凭记忆答题的模型。3.3 阶段三工具调用和Agent循环让系统“会做事”第三阶段是很多AI工程学习者觉得“突然上了一个台阶”的地方让你的系统不是光会说话而是能动手操作外部系统。这本质上就是Function Calling也叫Tool Use。我推荐的入门项目是做一个能查天气和能搜索新闻的小助手。天气数据接一个公共接口新闻搜索也接一个公共接口然后把这两个能力“声明”给模型模型在需要的时候会以结构化参数的形式发起调用请求你的代码接收到请求后执行真实API操作把结果回传给模型模型再根据结果组织最终回答。这个过程中最关键的是理解“Agent循环”模型先判断“我现在需不需要工具”——如果需要它不直接回答用户而是输出一个工具调用指令——你的代码执行工具——把结果塞回给模型再看一轮——直到模型认为信息足够才给用户最终答复。这个循环听起来简单实际工程中有无数细节最多允许循环几次、工具调用出错怎么重试、工具返回的结果太长怎么压缩、多工具时优先调用哪个。3.4 阶段四评估、观测、成本决定你能否走得更远前三阶段做完你已经能做出一个“能跑”的AI系统了。但离“能交付”还很远。第四阶段是很多自学的人最容易漏掉的评估体系和可观测性。“能跑”和“能交付”之间隔着一套评估基础设施。我建议你现在就动手做三件事沉淀一个评估集至少准备30到50条覆盖典型场景的问题标注标准答案或评分要点写一个自动化回归脚本每次修改提示词或检索逻辑后批量跑一遍评估集统计通过率建立trace日志记录每次请求的完整链路——输入了什么、检索到了什么、模型怎么决策的、调用工具花了多久、花了多少token、最终答了什么。这三件事做完你的开发节奏会完全改变。你不再依赖“感觉回答变好了”而是依赖数据。我自己在带项目时经常说AI工程的重点不是让模型“看起来聪明”而是让你的改动结果可以被测量、被比较、被回滚。没有评估体系的AI项目做得越久越容易变成一团乱麻。4. 工具链选型为什么我先劝你别碰重量级框架4.1 模型服务怎么选先跑通云端API再谈私有化第一选择永远是各大厂商的云端API。理由很简单零部署成本按量付费你需要把精力放在应用逻辑而不是运维模型上。至于选哪家说实话各家能力各有长短但我建议初学者锁定一到两家主流的把API调通了再横向对比。什么时候需要考虑开源模型两种情况一是数据敏感业务数据不能出域二是调用量巨大云端价格撑不住。这时候才去考虑Qwen、GLM这类开源模型的自部署。我见过不少初学者一开始就折腾本地部署显卡、驱动、推理框架一整套下来人先累瘫了一半应用逻辑还没开始写。这个顺序是错的。4.2 编排框架先手写循环再引入LangGraph这是我最想强调的一点。现在市面上主流的编排框架有LangChain、LlamaIndex等功能强大组件丰富点几下就能把RAG串出来。但我强烈建议你在学习期不要用至少不要一上来就用。原因有三个第一框架把太多细节封装成了黑盒出了问题你根本不知道断在哪一环第二框架本身的抽象概念Chain、Runnable、Callbacks也是一套需要学习的内容叠加在AI工程之上等于一次学两套东西第三市面上绝大多数的报错到最后排查时你会发现自己手写十行代码就能解决的问题框架里绕了半圈。我自己带人的路径是用原生SDK手写一次Agent循环把请求、判断、工具调用、结果回填全部显式写出来。等你完全理解了每一步在干什么再去看LangGraph这一类工具你会发现自己几分钟就能看懂它的设计逻辑而且能用得比直接上手更稳。4.3 向量存储怎么选三个字看规模。我个人把选择分成四档用一个表格说清楚方案适合场景部署方式是否需要中间件Chroma学习项目、原型验证、数据量小嵌入式否FAISS百万级以下、单机够用嵌入式/独立否Qdrant需要高并发、过滤筛选丰富的生产环境Docker/独立服务是Milvus千万级以上、大规模检索集群独立集群是我的建议非常明确第一个项目用Chroma就够数据量大了再迁移到Qdrant。原因是Chroma的开箱即用体验极好几行代码就能跑起来让你专心理解检索逻辑本身。过早引入分布式向量库等于在还没学会开车时先研究发动机原理。4.4 观测与调试工具越早接越好很多做AI应用的人没有日志习惯这是要付出代价的。普通程序的bug可以稳定复现AI应用的bug往往“这次好、那次坏”没有日志你根本无从定位。我现在最低限度的要求是每个请求必须记录模型名称、输入内容、输出内容、token数、延迟、检索命中文档ID、工具调用过程。出错时能完整回溯。开源工具里我比较常用的是Langfuse或者阿里云的链路追踪核心无非是把关键节点埋点。如果你不想引入额外服务用最简单的结构化日志打印到文件也能解决问题。重要是“有”而不是“工具多高级”。这句话在我自己踩了无数次坑之后体会很深没有日志的AI项目出了问题就像在黑屋子里找一只黑猫。5. 端到端实战拆解一个带RAG和工具调用的客服助手5.1 项目背景与功能定义纸上谈兵这么多我们直接跑一个完整的小项目。场景是给一个小型电商公司做客服助手需要处理两类用户请求。第一类是“知识库问答”比如退换货政策、发货时间这类高频问题靠RAG查企业手册第二类是“订单查询”用户给出订单号查物流状态这个必须调真实订单系统接口。这个项目规模不大但它完整覆盖了AI工程的两条主要链路检索增强和工具调用非常适合照着做一遍。5.2 整体流程设计运行逻辑是这样的用户发来一句话系统先让模型判断意图。如果用户问的是政策类问题模型触发search_knowledge_base工具我们执行知识库检索把结果带回模型生成回答如果用户问的是订单状态模型触发get_order_status工具我们调订单接口拿真实数据再组织回答如果用户一次问了两件事模型也会分别触发工具。为了让步骤清晰我画一下请求流转的要点用户输入进入对话循环模型判断直接回答本地话术还是需调用工具如需调用工具模型返回结构化工具调用指令代码解析指令并执行对应函数把函数返回结果附加到对话上下文回到第2步模型认为信息足够输出最终回答循环结束。我在实际项目中把最大循环次数设为5超过就返回“暂时无法处理请转人工”宁可让用户转人工也不无限烧token。5.3 核心代码实现这里给出一段可以照跑的Python核心逻辑用OpenAI兼容接口演示模型不锁定import json from openai import OpenAI client OpenAI() def get_order_status(order_id: str) - str: # 真实项目里这里是HTTP请求订单中心这里做一个mock返回 return f订单{order_id}当前状态已发货预计2天内送达。 def search_knowledge_base(query: str) - str: # 真实项目里这里会走向量检索这里用关键词匹配mock if 退货 in query or 退款 in query: return 我们支持7天无理由退货前提是商品未经使用且包装完好。 if 发货 in query: return 现货商品一般在48小时内发货定制类商品需要5-7个工作日。 return 知识库中没有找到直接相关的答案请转人工处理。 TOOLS [ { type: function, function: { name: get_order_status, description: 根据订单号查询订单当前物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单编号} }, required: [order_id] } } }, { type: function, function: { name: search_knowledge_base, description: 从企业知识库中检索售后服务相关问题的标准答案, parameters: { type: object, properties: { query: {type: string, description: 用户原始问题或检索关键词} }, required: [query] } } } ] def run_agent(user_input: str) - str: messages [ {role: system, content: 你是电商客服助手回答简洁专业涉及订单信息必须调用工具获取真实状态。}, {role: user, content: user_input} ] for _ in range(5): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, ) msg resp.choices[0].message if msg.tool_calls: # 把模型产出的tool_calls追加到上下文 messages.append(msg) for tc in msg.tool_calls: args json.loads(tc.function.arguments) if tc.function.name get_order_status: result get_order_status(args[order_id]) elif tc.function.name search_knowledge_base: result search_knowledge_base(args[query]) else: result 未知工具 # 把工具执行结果以tool角色回传 messages.append({ role: tool, tool_call_id: tc.id, content: result, }) else: return msg.content return 抱歉我暂时无法完成这个请求已为你转接人工客服。 # 测试用例 if __name__ __main__: print(run_agent(帮我查一下订单20240617-8899的物流状态)) print(run_agent(我想退货请问怎么操作))这段代码有三个关键细节值得你反复看一是tool_calls信息要追加到messages里不追加模型就丢了“它自己刚才想调用工具”这个上下文二是工具执行结果必须以role等于tool回传并且tool_call_id要和模型给出的一致三是循环次数的硬上限这是成本控制和避免死循环的第一道防线。5.4 评估集与回归测试代码能跑起来之后不要急着交付。我建议建一个分类评估集至少20条问题分布如下类型数量示例纯知识库问答8条“退换货运费谁承担”纯订单查询6条“订单20240618-1234发货了吗”混合型问题6条“我的订单晚到了能赔偿吗”每次改动代码后批量跑一遍评估集人工判断或写脚本自动评分。这一步在你日后的复杂系统里会变成一个自动化流水线它决定了你改任何一行代码时有没有安全感。我自己在这个项目里的实测结果是手写循环比直接套框架的通过率高7个百分点原因不是模型变聪明了而是我能精确控制上下文拼接和重试策略。6. 落地时最容易翻车的四个工程坑6.1 上下文塞爆与截断的取舍我见过最多的灾难点是开发者为了“让模型答得更好”把整本手册、全部历史对话一股脑塞进提示词然后很快遇到上下文窗口爆掉。解决方法看起来是“截断”但粗暴截断会让模型丢失关键信息。正确的做法是分层递进先用检索把资料范围缩小只把命中的片段放进去命中片段仍然过长时就做摘要压缩而不是头部截断历史对话只保留最近几轮更早的信息做摘要缓存。这个“资料只是引用不是全文”的思路是RAG的核心精神。我有一次把用户手册一个章节全文塞进去回答质量反而下降了因为无关文字干扰了模型对重点的注意力。6.2 工具调用时JSON解析的防御式处理模型返回的tool_calls参数经过JSON序列化但解析时不能假设它永远合法。实测中会出现参数名拼错、值类型错误、多出无关字段等情况。我的处理方式是解析外层函数名用官方SDK字段参数解析则包一层try-except失败后不回传错误给用户而是重新请求模型一次让模型修正参数。还有一个隐藏很深的坑模型返回一个工具名但参数里缺了必填字段。你的代码访问args[order_id]会抛KeyError然后整个Agent崩溃。处理办法是写一个字段校验函数缺什么补提示词让模型补充而不是直接相信模型输出。凡是模型输出的东西都要当成“来自外部用户输入”一样做严格校验这是我在AI工程里学到的第一课。6.3 Agent死循环与费用失控Agent循环不加限制的后果比想象中严重得多。最坏的情况是模型反复要求调用同一个工具工具每次返回相似结果它又觉得信息不足继续调用一轮循环几十次账单蹭蹭上涨用户还等不到答复。三道防线缺一不可硬性循环次数上限实战中我一般设3到5轮同工具连续调用次数检测超过两次就强制转人工单次请求的token总预算用max_tokens和调用监控双保险。我在生产环境里还加了费用告警每天超过预设金额直接切断接口宁可功能不可用也不能失控。这个说得可能有些严重但在企业场景里成本失控是真实的安全生产事件。6.4 “自测感觉良好”的评估陷阱最后一个坑不是技术问题而是心态问题。很多开发者自己设计了测试问题跑几次觉得回答都挺好就上线了。结果真实用户一问答得乱七八糟。原因是自测问题往往和你的提示词措辞高度一致而真实用户的表达千奇百怪包括错别字、口语化、指代不明。我的建议是评估集除了自己写还要分两个来源——第一让身边不参与开发的人按真实语气提问题第二上线后收集真实用户问题进入评估集。把评估集改造成一个“会生长的活集子”每次用户反馈不好的案例都沉淀进去。系统不是越做越聪明是越做越“稳”原因是它见过的坏例子越来越多回归测试能拦住大部分劣化。踩过足够多的坑之后我自己的体会亲手把从零到交付的流程完整走过一遍之后我最大的感受是AI工程真正考验人的地方不在于某一次调用写得多漂亮而在于你能不能把一个充满不确定性的系统设计得有边界、有兜底、可观测。它和传统后端的区别就像带实习生和写死脚本的区别——你得相信“实习生”有判断力同时永远假设它会犯错。如果只给一条建议我会说拿一个真实的小任务哪怕只是把你自己的知识库做成问答也要把它当作一个长期维护的产品来做而不是一次性的脚本。先跑通最小系统再逐步补上检索优化、评估、日志和成本控制。卡住的时候把报错信息原样复制去搜索你大概率不是第一个遇到这个问题的人。AI工程没有想象中那么陡峭的入门门槛但它确实需要耐心——每一步都搞懂为什么比赶进度重要得多。
