我最初接触AI工程时有个很深的误解以为只要会调模型接口、会写提示词就算入了门。等真正从零把一个AI功能做到生产可用才发现完全不是这么回事——调接口只占整个工作量的很小一部分更多的时间花在了数据清洗、效果评测、Agent编排、部署观测、兜底降级这些事情上。换句话说AI工程不是调用模型而是围绕一个概率系统搭建完整的工程闭环。这篇文章就是来梳理这条从零开始的路径。它会覆盖大模型的基础概念、Prompt系统设计、Agent实战、评测与测试、部署运维还有我实际踩过的坑。适合两类人一是写传统业务代码、想系统转AI方向的后端或全栈开发者二是已经在用大模型做应用、但总感觉跑通Demo容易、上线很难的技术负责人。下面这些内容不追求面面俱到每个环节只讲真正关键的、能直接落地的部分。1. 先想明白AI工程和传统软件开发到底差在哪1.1 概率系统带来的工程范式转移传统软件工程的核心是确定性。你写一个if user.age 18无论调用多少次结果都一样逻辑可以被单测完整覆盖。但AI系统的核心是概率同一个Prompt模型每次的回答可能不一样甚至同一个输入在不同时间调用结果也有波动。这个差异不是细节层面的而是系统设计层面的。我举个例子。假设你要做一个用户意图识别功能用来判断用户输入是想查余额还是想转账。传统做法是关键词规则或正则匹配用工程手段把规则写死逻辑透明、可测试。AI做法是让大模型判断意图准确率可能到了95%但剩下5%的误判怎么兜底模型返回的JSON格式偶尔不合规怎么处理用户恶意输入绕过系统指令怎么办这些才是AI工程真正要解决的问题。所以AI工程的第一课不是学Prompt、不是学LangChain而是接受一个现实你构建的是一个概率系统必须用工程手段把不确定性控制在一定范围内。1.2 从零开始的正确姿势先建立三块地基我见过不少半途而废的案例共性问题是地基没打牢就急着追热点。所谓地基我总结为三块编程基本功至少熟练掌握一门语言Python、TypeScript都行能独立写接口、处理并发、做异常处理。AI工程本质还是工程语言基础不牢后面写编排逻辑、写测评脚本都会很痛苦。对API和异步模型的理解大模型接口是网络服务有延迟、有限流、有超时你得习惯异步处理、流式响应、重试退避这些机制。很多从纯算法背景转过来的朋友在这里最容易翻车——他们习惯本地函数调用不习惯远程函数的高延迟和不可靠。成本意识Token不是免费的。一个复杂的Agent任务可能一次调用就要消耗几万Token折合人民币几毛到几块钱。没有成本模型功能上线之日就是烧钱开始之时。这三块地基不打牢后面所有环节都会返工。1.3 如何判断自己是否适合走这条路判断标准不是会不会写Prompt而是看你有没有排查问题的意愿。AI工程里模型输出出错只是表象根因可能是数据没处理好、Prompt有歧义、上下文被污染、参数配置不对、召回结果太差……定位问题的链路比传统开发长得多。如果你愿意面对这种不确定性带来的排查复杂度那这条路适合你。2. 构建AI工程能力的四个基础模块2.1 大模型基础理论六个必须吃透的核心概念不一定要读论文但这六个概念必须真正理解。我用大白话拆一遍Token模型处理文本的最小单位可以理解为字的积木块。英文一个词通常1-2个Token中文一个字大概1-2个Token。计费、上下文长度都基于Token。知道这个概念你就明白为什么把整个文档塞给模型这么贵。上下文窗口模型一次能看到的最大Token数可以类比为桌面大小。桌面越大能同时摊开的资料越多但成本也越高。超出的部分会被截断或遗忘这是RAG检索增强生成存在的原因之一。温度Temperature控制输出随机性的参数。温度越低输出越确定适合分类、抽取这类任务温度越高输出越多样适合创意写作。工程上建议结构化任务用0.1-0.3创意任务用0.7-0.9。系统提示System Prompt对话开始前给模型设定的长期指令设定角色、行为边界、输出规范。相当于给新员工发的一份岗位说明书。函数调用Function Calling让模型输出结构化意图比如用户想查余额参数是账户ID由程序解析后执行真实操作。这是Agent能操作外部世界的根基。流式输出Streaming模型边生成边返回内容不用等全部生成完毕。对用户体感影响巨大——等3秒出全文和第一秒就看到第一个字体验完全不一样。2.2 Prompt工程从写提示词到设计提示系统很多人以为Prompt就是用自然语言提要求但工程化的Prompt是一套有结构的文本协议。我自己在团队里推的写法是五段式角色定义你是XX系统的客服助手负责解答退款问题语气专业但不机械。 任务描述根据用户问题从给定FAQ中检索最相关条目并生成回答。 约束条件只基于FAQ内容回答如果FAQ没有相关内容明确告知暂未收录不得编造政策。 输出格式先输出命中的FAQ编号列表再输出最终回答。 少样本示例提供2-3组用户问题→正确回答的样例。这套模板看起来简单但真正执行到位有几个容易被忽略的细节。第一角色定义要写什么不能做禁区往往比职责更重要模型没有禁区意识就会自由发挥。第二少样本示例要选困难样本选模型容易犯错的类型而不是随便找几个顺手的。第三输出格式里要明确不允许输出什么比如不要使用Markdown表格、不要输出思考过程格式崩坏是工程上最常见的低级事故。我见过一个常见的反面做法Prompt写得像一篇小作文把各种要求全部堆进去结果模型记不住重点输出质量反而下降。本质原因是Prompt越复杂越容易让模型迷失在指令里。Prompt设计的核心是压缩——用最少的指令覆盖最多的场景。2.3 工具链选型2025年做AI工程需要什么工具箱从零开始逐层构建我把工具链分成四层层级作用常用选择我的建议开发框架编排Prompt、管理链式调用LangChain、LlamaIndex、自研小团队先用LangChain起步但核心业务逻辑尽早自研模型网关统一管理多模型Key、负载均衡OpenRouter、One-API、自建网关有预算就自建后续换模型、做灰度都方便向量数据库存储和检索知识切片Milvus、pgvector、Chroma数据量小于百万条pgvector够用数据量大再上Milvus观测评估追踪调用链路、评测输出质量LangSmith、Promptfoo、自建日志初期用开源方案后期必须沉淀自建评测集选型有个原则能不加依赖就不加依赖。LangChain这类框架能加速原型验证但也带来了抽象层过多、排错困难的问题。我见过不少项目用了LangChain之后出问题完全不知道是框架的锅还是自己的锅。建议用框架跑通Demo上线前重写核心链路。2.4 评测意识没有评测就没有AI工程这是我觉得整条学习路径中最容易被跳过、但最关键的一环。做AI应用跟做传统功能最大的差别在于传统功能逻辑对就是对、错就是错AI功能没有绝对的对错只有好不好。那好不好怎么衡量靠评测。评测体系的搭建分三步构建测试集整理100-500条真实用户输入覆盖常见场景、边界场景、恶意输入。这些数据从哪来初期可以靠人工构造上线后要持续从线上日志里捞。定义评测指标分类任务看准确率、召回率生成任务看相关性、忠实度、格式合规率。生成任务的指标可以用大模型来评分让GPT-4当裁判也可以规则检查客观点。建立回归机制每次修改Prompt、调整模型参数、更换模型版本都要在测试集上跑一遍对比指标变化。这一步相当于传统开发的单元测试。我见过太多团队花两周调Prompt把线上效果调好了一个点结果下一个需求改动把之前的效果打回原形这就是没有回归机制的结果。评测集就是AI工程的测试用例多早开始建都不嫌早。3. 从Prompt到Agent智能体工程的关键跃迁3.1 Agent的核心机制推理、行动、观察的循环如果说Prompt是教模型怎么说Agent就是教模型怎么做。Agent和普通对话的本质区别是它通过循环调用获得解决问题的能力。这个模式在学术上叫ReActReason Act工程实现可以简化为一个循环系统把任务和可用工具清单交给模型。模型推理出下一步计划输出一个结构化意图比如调用search_inventory函数参数是产品名称。程序解析意图执行真实函数把结果返回给模型。模型观察结果决定是继续调用还是输出最终回答。循环直到任务结束或达到最大轮数。这个循环听起来简单但它是Agent系统的灵魂也对应了工程界最近常说的Loop Engineering——核心工作不再只是写单个Prompt而是设计循环的节奏、退出条件、异常分支。我把循环比作放风筝模型是风筝可以自由飞但线循环控制逻辑必须握在工程手里什么时候收线、什么时候放线由程序决定而不是让模型自己决定。3.2 多Agent协作从单个Agent到Agent团队任务复杂度上来之后单个Agent往往顾此失彼。比如一个客服Agent既要理解用户意图、又要查订单系统、又要写回复、又要处理售后工单一个Prompt塞这么多职责效果一定差。这时候就需要拆分。我在实践里验证过三种协作模式编排模式一个主Agent负责任务分发把任务拆给多个子Agent汇总结果。适合任务边界清晰、子任务互相独立的场景。管线模式任务按固定流程依次经过多个Agent每个Agent只负责一个环节比如先提取信息、再生成回复、最后质检。适合流水线性质的业务。会诊模式多个Agent分别从不同角度分析同一问题最后由裁决Agent综合结果。适合复杂决策场景但成本较高、延迟较长。多Agent系统在工程上的难点不是怎么让它们对话而是状态管理。每个Agent跑到哪一步了上下文传到了谁那里怎么避免A Agent的错误被B Agent放大我的建议是能用单Agent解决的场景绝不上多Agent多Agent是复杂度放大器不是万灵丹。3.3 Agent落地最容易翻车的三个地方我亲自踩过、也看别人反复踩的坑集中在以下三个死循环Agent在一个错误分支里反复执行同一个工具调用浪费Token还不出结果。解决方法是硬性设置最大轮数一般3-5轮足够、单次任务Token上限、连续相同操作判定。上下文爆炸每轮工具调用结果都被追加进上下文几轮之后上下文就超限了模型开始忘记最初的任务。解决方法是做上下文裁剪只保留关键中间结果比如工具调用的最终返回值而不是完整的JSON原始响应。工具误用模型选择了错误的工具或者传了错误的参数。解决方法是工具描述写清楚什么情况用/什么情况不用并做参数校验——程序要在执行工具前校验参数格式不要完全信任模型的输出。这三点说穿了都是确定性兜底的问题Agent的大脑是概率的但它的骨架必须是确定的。4. 工程化落地从Demo到生产要闯的几道关4.1 知识与数据接入RAG的完整链路大部分商业AI应用不能只靠大模型的通用知识必须接入私有业务数据。RAG是目前最主流方案它的完整链路是解析 → 切片 → 向量化 → 检索 → 重排 → 生成。若干实操细节值得强调。解析阶段最容易被低估。PDF、Word、网页等不同格式要针对性处理扫描件还要OCR。我曾经遇到一个项目解析后的文本乱码率高达20%直接导致检索质量崩盘最后定位到是编码问题换了解析库才解决。切片阶段的核心矛盾是粒度切大了检索结果不够精准切小了上下文碎片化模型理解困难。我的经验是按语义段落切片每片控制在500-800字且切片之间保留少量重叠overlap大约50字左右避免跨越段落边界时信息丢失。检索阶段不能只靠向量相似度。纯向量检索对关键词精确匹配不敏感iPhone 15和苹果15向量可能不匹配所以生产环境更建议用混合检索向量检索 关键词检索BM25再用一个重排模型Rerank把两路结果合并排序。这三个词可能对新手有点陌生但它们是RAG效果提升最立竿见影的三个杠杆。4.2 AI测试开发给不确定的系统做质量保障AI测试和传统测试最大的区别是不能只测对不对还要测好不好。我在这块积累了一套组合拳第一层是规则化断言。模型输出是文本但工程上可以约束它输出结构化字段通过Prompt函数调用然后对结构化字段做规则校验。比如如果结果是JSON就必须包含status字段且status取值只能是success或failed这条断言可以用代码实现准确率100%。这类规则能被抽象的一定要抽出来它构成测试的硬底线。第二层是模型化评测。涉及语义质量的指标回答是否相关、是否忠实于资料、语气是否合理规则很难判断就引入一个评测模型打分。做法是定义好评分标准1-5分附具体评分细则把用户问题和待评回答一起发给GPT-4或Claude这类强模型让它按标准打分。这里有个人尽皆知但不好听的秘密让模型当裁判裁判本身也会有偏差所以每个评测样本要跑多次取均值并且定期人工抽检裁判质量。第三层是回归测试。每次改动Prompt或模型参数都要跑一遍完整测试集对比各指标变化。这个习惯建立起来之后团队对Prompt调整的恐惧感会明显下降——因为改得好不好有数字说话不用靠感觉。这套体系也被业界叫做Harness Engineering——给AI模型装一套安全带约束它的输出边界、检测它的异常行为、衡量它的运行质量。4.3 部署与观测模型上线后的持续管理模型推理服务上线只是开始比部署更关键的是三个配套能力缓存与限流相同或相似的请求可以考虑结果缓存能省很多成本限流是做生产系统的基本功模型接口的限流策略要提前设计好否则突发流量来了就是雪崩或超支。完整链路日志每一次请求从用户输入、检索结果、Prompt全文、模型输出到最终返回结果全部落日志。这是排查线上问题的基础设施。没有这套日志线上出问题你只能靠猜而AI系统的猜成本极高。质量监控线上效果会随着模型版本迭代、用户输入分布变化而漂移。定期从线上日志抽样做评测跟踪准确率、Token成本、延迟等指标的变化趋势设定告警阈值。这是很多人忽略的持续运营环节。5. 从0到1踩过的坑与避坑路线图5.1 我亲历的三个教训讲点实际踩坑的经历。第一个坑是不建评测就上线。早期做一个知识问答产品团队花了大量精力优化Prompt上线后用户反馈有些问题答非所问。一查才发现我们自己在测试集上看着效果不错是因为测试集就几十条数据还都是我们手写的友好问题。真实用户提问的表述五花八门甚至带着错别字和口语化的指代测试集完全没有覆盖。后来我们花了三周从后台日志捞数据建测试集效果才开始稳定。这个坑本质上就是用直觉代替评测的代价。第二个坑是一股脑上Agent。之前做一个报表分析功能我们想当然用了多Agent架构一个负责理解问题、一个负责查数据、一个负责做图表。结果每次调用要5-8秒Token成本高得吓人而且三个Agent之间互相误解经常出现答非所问。最后砍掉两个Agent把任务合并成单Agent 函数调用的模式延迟降到1.5秒成本降了70%效果反而更好。这个案例告诉我能简单就不要复杂Agent架构是最后的选择而不是第一的选择。第三个坑是忽视JSON解析鲁棒性。模型输出偶发JSON格式错误工程上一定要做容错处理和自动重试机制。具体策略是设置最大重试次数比如2次每次重试时在Prompt里附带上次输出格式错误请严格按照指定格式输出通常第二次就能恢复正常。5.2 一份12周从零到能落地的参考路线如果让我给新人规划一条可执行的路径大概是这样的节奏第1-2周掌握基础概念动手调通大模型API理解Token、上下文、温度这几个核心参数。目标跑通一个最简单的输入→输出程序。第3-4周系统练习Prompt工程掌握五段式结构、少样本示例、约束条件设计。目标能针对一个具体任务写出稳定可用的Prompt。第5-6周实现一个带RAG的知识问答应用跑通解析、切片、向量化、检索、生成全链路。目标理解数据接入的完整流程。第7-8周上手Agent开发用Function Calling做一个能调用外部工具查天气、查数据库的Agent。目标理解ReAct循环和工具协议设计。第9-10周搭建评测体系构建测试集、定义指标、实现回归测试。目标能量化评估任何一次Prompt或模型改动。第11-12周把应用部署上线完善日志、监控、限流、容错。目标完成从Demo到生产环境的闭环。按这条路线走下来基本能建立完整的AI工程能力地图。不是每条路都必须按这个顺序但评测这一环建议别跳它决定了你后面的所有优化是在盲调还是科学调参。想清楚这个逻辑就比大多数还在追新模型、抄新Prompt模板的人领先一大截了。