干AI工程实践这几年我最大的感受是从零开始搭一个能用的AI项目难点根本不在模型而在Prompt工程、AI Agent、模型部署这一连串工程环节。很多人拿到一个大模型API就直接写业务代码结果demo能跑、上线就崩一问原因往往是输入输出没约束、上下文管不住、部署环境没有压测。这篇文章我想把从零开始做AI工程的完整路径拆开讲适合刚接触AI工程的新手也适合被项目折腾到怀疑人生的产品同学。我会把思路、参数、配置和踩过的坑都放进来争取你看完能照着这一套思路去落地自己的AI应用。1. 从零开始AI工程的整体蓝图与设计思路1.1 先拆需求你不是在训练模型而是在做工程很多新手被“AI”这个词吓住一上来就研究模型架构、损失函数想着是不是要微调一个专属模型。但真实项目里模型已经高度商品化你需要解决的是怎么把模型能力稳定地接进业务流程。我早期做第一个AI工程时犯过很典型的错误需求是“做一个智能客服”我直接去微调模型结果数据不够、效果玄学、上线还慢。后来我把需求拆成“FAQ检索单轮问答多轮对话”三个子问题分别用RAG、Prompt工程和会话管理解决事情立刻简单了。拆需求的本质是明确三个问题。第一输入输出是什么用户传进来的是文本还是表单系统吐出去的是回答、结构化JSON还是一个具体的操作指令。第二评价标准是什么用正确率、用户满意度、还是端到端延迟来衡量没有这个标准你永远说不清项目有没有成功。第三约束是什么数据能不能出域、并发量多大、预算多少、可用性要求几个9。把这些写清楚AI工程的边界就出来了。另一个常见误区是恨不得第一天就做出一个能自动规划任务的Agent。我不建议这么干。Agent是复杂度放大器它适合在“单轮能力已经稳定”之后再加。从零开始做AI工程正确顺序永远是先跑通一条最简单的主链路再加上检索、工具调用、记忆和循环控制。每加一层都要问自己这层到底解决了哪个可量化的痛点如果答不上来就别加。1.2 架构分层数据、模型、Agent、应用、交付从零搭AI项目我会习惯性把系统分成五层每一层都有独立的技术选型和验收标准。这个分层不是教科书理论而是方便排查问题一旦出了bug你至少能快速定位是模型层的问题、数据层的问题还是应用层的问题。分层核心职责关键技术点常见角色数据层数据采集、清洗、切片、向量化文档解析、Embedding、向量库数据处理工程师模型层选择基座模型提供推理服务API调用或私有化部署推理加速算法/运维工程师Agent层把LLM与工具、记忆、执行循环编排起来Prompt工程、Tool Calling、HarnessAI应用工程师应用层面向用户的产品逻辑、前端和接口会话管理、权限控制、业务后端后端/前端工程师交付层发布、监控、评估、迭代日志、指标、评测集、灰度发布SRE/测试工程师分层还有一个好处每一层都可以独立替换。今天用A模型效果不好换B模型时不需要动整个应用向量库从Chroma切到pgvectorAgent层也不该受影响。这也是AI工程和传统软件开发最大的不同——模型和工具迭代太快架构一定要松散耦合否则每次升级都等于重写一遍。我实际搭建时会先画一张简单的系统流程图把用户请求经过哪些层、每层依赖什么、超时时间是多少标出来。这张图不需要很细致但必须有。它决定了你后面是花三天调Prompt还是花三周重构架构。很多人做AI工程做到一半就跑偏就是因为从没想清楚每个模块的边界。2. 核心环节一Prompt工程AI工程的地基2.1 Prompt不是玄学是结构化输入标准我见过太多人写Prompt全靠“感觉”今天加一句“请你认真回答”明天又改成“你是专家”效果飘忽不定。真正的Prompt工程本质是把业务规则翻译成语言模型能稳定执行的输入标准。它和传统软件里的接口文档非常像——字段越清晰模型越不容易钻空子。举一个我做情感分析的例子。最初的Prompt是“请分析这句话的情感。”你能得到一百种格式的回答有的带解释有的只给词有的甚至反问。后来我改成你是一个情感分析引擎。 任务判断用户评论的情感倾向。 规则 1. 只输出一个词积极、消极或中性。 2. 不要输出任何解释或标点。 3. 如果内容包含讽刺按字面意思无法判断输出“中性”。 用户评论{评论内容}效果立刻稳定。不是因为模型变聪明了而是因为我把输出空间压缩到了固定集合并且明确禁止了干扰行为。好的Prompt不一定花哨但一定让模型知道“你要我做什么、按什么格式做、不要做什么”。Prompt工程里还有个很重要的杠杆少样本示例。模型在上下文里见过两到三个高质量输入输出对之后理解成本会大幅降低。比如让模型抽取病历实体我会在Prompt里粘上两条真实样例标注出正确结果再把新样本放进去。这比反复强调“请准确抽取”有效得多。少样本不是越多越好我用下来3到5个就够了太多会挤占上下文还会让模型模仿样本中的噪声。2.2 三段式模板与参数取舍我日常写Prompt基本套一个模板三段式角色定义、任务描述、输出约束。角色定义给模型一个工作框架任务描述说清楚目标和输入变量输出约束锁死格式和边界。如果还需要就再加一段示例区。这套模板几乎能覆盖大多数业务场景而且方便复用。你是{角色}。 你的任务是{一句话说清楚目标}。 输入是{变量} 请按以下约束输出 - 输出格式{JSON / Markdown / 纯文本} - 不要做{禁止事项} - 如果信息不足请回答{兜底话术} 示例 问题{示例问题} 答案{示例答案} 现在请处理{真实输入}除了Prompt内容生成参数也在Prompt工程范围之内。两个最关键的参数是temperature和top_p。我做信息抽取、分类、JSON输出这类确定性任务temperature设0.1到0.2让模型尽可能保守。做文案生成、头脑风暴这类创意任务temperature设0.7到0.9输出会更有变化。top_p我一般保持默认0.9如果发现回答太发散就调到0.7以下。max_tokens千万别省否则回答会被截断而且很多模型截断后不会提示只会强行停在中间。这些参数不是调得越大越好。有一个很常见的坑为了“看起来有创造性”把temperature拉到1.5结果输出开始胡言乱语连语法都不稳定。模型本质上是个概率采样系统温度过高会让低概率的糟糕词被放出来。工程里追求的是稳定可控不是偶尔惊艳。2.3 上下文管理与Token成本计算模型有上下文窗口但上下文不是免费的。窗口越大延迟越高、显存压力越大、单次调用成本越高。从零开始做AI工程第一课就是学会算Token预算。Token的估算没有绝对精确的公式但你按经验可以做到心里有数中文环境下1个汉字大约占0.6到1个Token英文环境下大概4个字符约等于1个Token。所以我做容量规划时会先估算一条完整请求的Token组成通常包括系统提示词、用户问题、检索回来的资料、历史的对话轮次、工具返回结果以及预留的输出Token。假设我们的模型窗口是8K我会给系统提示词留1000检索内容最多3000用户问题加历史3000输出1000这样刚好不爆。上下文管理常见的三个策略是截断、摘要和RAG。截断只适合保存最近几轮对话简单但会丢信息摘要是让模型把早期对话压缩成一小段适合长对话场景RAG是外部检索只把和当前问题相关的资料塞进上下文适合知识问答。三者可以混合用。我做一个客服Agent时就是把历史对话用另一个轻量模型做摘要然后跟检索片段一起拼进主Prompt既控制了成本又保留了关键信息。还要养成一个习惯每次调用后都打印响应里的usage字段。只看对话内容很容易忽略实际消耗尤其当传入的检索结果很大时成本会悄无声息地翻倍。我见过有人单次请求塞了一两万字知识库一次调用吃掉两三千Token导致账单一周涨了十倍。上下文管理不是可选项是AI工程的基本功。3. 核心环节二AI Agent与Harness Engineering3.1 Agent是什么LLM 工具 记忆 执行从零开始做AI工程绕不开AI Agent。简单说Agent就是让模型不仅能“说话”还能“做事”查数据库、调接口、控制软件、发起动作。一个Agent的最小组成我概括为四部分LLM大脑、工具集、记忆、执行循环。LLM负责理解和决策工具集负责连接外部世界记忆负责保存中间状态执行循环负责让整个过程在限定步骤内跑完。用生活化类比来理解LLM是公司里的老板工具是老板手下的员工记忆是老板的记事本执行循环是项目管理流程。老板不直接干活但他决定调用哪个员工、按什么顺序调用、最终产出什么。一个合格的Agent工程不是把老板的话原样转发给员工而是给整套工作流程定义清晰的接口、状态和失败处理。我早期写的Agent非常简陋一个while循环里反复调用模型直到模型说“结束”。听起来可行实际上模型经常在一个循环里打转不断调用同一种工具却从不收敛。这让我意识到Agent不是“模型能调函数”就完事了它必须有严格的执行约束。比如一次任务的步骤上限、每一步的超时时间、工具调用的白名单、以及从异常中恢复的兜底逻辑。这些约束就是接下来要说的Harness Engineering的雏形。3.2 Harness Engineering给Agent穿上工程背带Harness Engineering是我非常看重的一层也常常被新手忽略。我理解它指的是为了让Agent稳定、安全、可观测在模型外部加上一套控制、校验和追踪机制。你可以把它想象成登山背带它不负责替你爬山但能保证你在爬的过程中不会失手坠落。具体到实现Harness至少包括几个部分任务分解器把一个大目标拆成可执行的子步骤工具注册中心统一管理Agent能调用哪些工具、每个工具的入参和权限状态管理记录当前步骤、前一步输出、剩余预算可观测性把每一步的输入输出、Token消耗、报错信息完整落日志。我做过一个踩坑案例给Agent注册了搜索、数据库查询、计算器三个工具但模型经常把参数传错比如把搜索关键词传到数据库SQL里导致执行直接报错。后来我加了一个参数校验层在工具真正执行前先做格式和枚举校验不合格的调用直接返回错误信息告诉模型重新生成。这一层加上之后工具误调用率降了差不多四成。Harness不是花架子它解决的就是这类真实工程问题。另一个Harness重点是大循环的边界。Agent任务不能无限制跑下去我会强制设置最大步骤数、最大Token消耗和总超时时间超限就强制终止并返回当前已获得的最优结果。这有点像一个预算控制机制很可能用户问一句“帮我整理报告”Agent跑了二十步只为了找一个引文这是不可接受的。该止损就止损工程里稳定比“聪明”更重要。3.3 工具调用与安全边界工具调用是Agent能力的放大器也是风险集中区。让模型调用外部工具之前必须把工具描述写得足够清晰否则模型无法正确选择参数。绝大多数模型平台都支持Function Calling你可以给每个工具定义一个JSON Schema包含名称、描述、参数类型、枚举值、是否必填。参数描述越具体模型越不容易出错。{ name: query_document, description: 在内部知识库中检索与问题相关的文档片段。, parameters: { type: object, properties: { keywords: { type: string, description: 用于检索的关键词或自然语言问题 }, top_k: { type: integer, description: 返回的文档片段数量默认5最大10 } }, required: [keywords] } }我在接入工具时会坚守几个原则。第一最小权限模型只能看到当前任务需要的工具不需要的全部从工具列表里拿掉避免它产生幻觉去调用无关能力。第二服务端校验模型给出的工具参数必须经过服务端二次校验绝不直接透传到数据库或第三方接口。第三危险动作额外确认删除、发送消息、支付、修改线上配置这类操作必须触发人工确认流程。别指望模型有“常识”它只会按概率推断最合适的下一步而概率最高的动作不一定安全。还有一点容易被忽略工具返回结果也要做大小限制和格式清洗。外部接口可能返回几十KB的脏数据直接塞进上下文会浪费Token还可能盖过关键信息。我会在Harness里做一层裁剪、提取摘要、结构化只把最有用的字段返回给模型。这样Agent既快又省还更容易做出正确决策。4. 核心环节三模型部署与AI工程实践4.1 选型API调用还是私有化部署模型部署是AI工程从原型走向生产的关键一环。面对一个具体的业务需求首先要回答用现成的模型API还是自己部署开源模型。两条路线各有优劣不能盲目跟风。维度API调用私有化部署接入速度快几行代码搞定慢需要准备GPU、模型和环境初始成本低按量付费高需要服务器和运维投入长期成本随请求量线性增长固定投入高并发时更划算数据隐私数据需要经过第三方服务数据全在自家环境可控性受限模型不可替换自由可换模型、调推理参数运维复杂度低高需要监控和版本管理我的建议是冷启动阶段优先用API把业务逻辑和Prompt工程跑通验证产品价值等到请求量稳定了、数据隐私要求变高了再评估私有化部署。不要为了“自主可控”一上来就招运维买GPU结果模型效果没验证完成本先烧没了。私有化部署也别急着微调。现在开源模型的能力已经很强绝大多数场景只需要把Prompt和RAG做好。微调只适用于两件事一是特殊输出格式怎么也约束不住二是领域知识必须融进生成过程。其他情况下微调的性价比都很低因为每次基座模型更新你的数据又得重新适配。4.2 部署一个可用的推理服务部署私有化模型我近一年用得最顺的工具是vLLM。它支持OpenAI兼容接口也就是说你的业务代码可以完全复用原来的客户端只改一个base_url就行。下面是一个最基础的启动命令我用7B模型举例pip install vllm python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --port 8000几个参数值得说明。--gpu-memory-utilization控制显存使用比例默认会预留一部分给KV cache但如果你只有一张8G显存卡跑7B模型就很紧张建议先调小--max-model-len到4096或者开启量化。--max-model-len是允许的最大上下文长度不是越大越好显存固定时调太大容易启动时就直接OOM。启动之后可以用一行命令验证服务是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好}]}业务侧用OpenAI的Python库就能接上from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: user, content: 用一句话介绍你自己} ], temperature0.2, ) print(resp.choices[0].message.content)如果你需要在推理服务之上再包一个业务接口我一般用FastAPI做一层BFFBackend For Frontend在里面做鉴权、限流、Prompt组装、日志记录和兜底返回。推理服务保持干净只负责和模型对话业务逻辑全部放在外层。这样模型升级不影响后端后端迭代也不干扰模型服务。4.3 性能调优与监控部署完之后最常被问到的问题是为什么这么慢AI推理服务和传统Web服务不一样它的性能瓶颈通常在显存带宽和KV cache而不只是CPU。我要关注的指标有两类首Token延迟TTFT和生成吞吐Tokens/s。首Token延迟影响用户感知生成吞吐影响并发承载力。调优手段我按优先级排第一用vLLM这类支持Continuous Batching的框架它能把多个请求拼在一个batch里推理吞吐提升非常明显。第二控制上下文长度上下文越长KV cache越大单请求耗时越多。第三量化模型比如从FP16降到INT8显存占用减少推理速度往往也能提升代价是效果可能有轻微下降。第四打开Prefix Caching如果多轮对话有大量相同的系统提示词缓存前缀可以大幅减少重复计算。监控这块别漏掉。至少记录请求量、成功率、平均延迟、p95延迟、Token消耗量和显存利用率。我会在应用层每次调用后用日志记录usage.prompt_tokens和usage.completion_tokens再配合服务器监控这样一旦响应变慢或者成本飙升能快速定位是哪一层出了问题。没有监控的AI服务就像一个不带仪表的飞机起飞容易降落全凭运气。5. 从零到一落地一个AI应用的全流程5.1 定义一个真实场景文档问答Agent前四章把技术点拆开了这一章我串起来做一个完整案例基于内部技术文档的问答Agent。这是AI工程里很典型的需求既涉及RAG又涉及Agent还涉及部署和评估。需求最初描述是“给新员工做一个助手问技术问题能直接给出答案。”这句话非常模糊。我开始前先把它补全用户输入的是一个自然语言问题系统输出的是一个参考答案和对应文档的引用链接整套流程必须在3秒内返回答案必须严格基于内部文档禁止编造如果检索结果不足以回答系统必须直接说“资料库中没有相关内容”不能硬答。这些约束一明确方案基本就定了。架构上我分为离线索引和在线推理两段。离线阶段把技术文档清洗、切片、向量化后存进向量库。在线阶段用户问题先向量化再从向量库召回TopK片段组装成Prompt交给模型生成回答。在这个基础上再加一个Agent外壳让模型可以调用一个“查询文档”工具如果第一轮召回不理想它可以选择改写关键词再查一次。注意这里Agent是辅助不是主流程所以它失控的风险有限。5.2 端到端搭建第一步是文档清洗。HTML、PDF、Word要转成纯文本删除页眉页脚、目录和乱码。我通常按固定长度切块比如512到1024个Token切块时加10%到15%的重叠避免一句话被腰斩到下一个块里。切片太小则语义不全太大会稀释核心信息带着重叠是一个折中的工程做法。第二步是向量化。我选一个轻量的Embedding模型把所有文本块编码成向量存入向量数据库。工具可以选择Milvus、pgvector或者Chroma小规模验证期用Chroma最省事。索引建好后要把每个向量和它的原文、来源文档ID、页码关联起来这样后续能返回引用。第三步是检索和生成。查询进来后我先把问题向量化从库里召回TopK个相关块通常K取5。然后用一个组装Prompt把召回内容包进去你是技术文档问答助手。 请基于以下资料回答用户问题。 资料 {检索到的文档片段} 注意 1. 如果资料中没有相关信息请直接回复“资料库中暂无相关信息”。 2. 引用来源时用[文档ID-序号]标注。 3. 回答控制在200字以内。 用户问题{用户问题}第四步是封装成Agent。我给Agent注册了query_document工具它自动执行上面的检索但如果首轮结果不理想模型可以根据已有信息改写查询词再次检索。我把整个流程放入Harness设置最大迭代3次超时10秒所有调用记录日志。最后部署直接用前面介绍过的vLLM加FastAPIEmbedding模型单独拿一个轻量服务向量库和业务库分开部署。5.3 成本与评估上线之前必须做评估。我建了一个50到100条的测试集覆盖常见问题、冷门问题和故意刁难的问题。每条问题都标注了理想答案或至少标注了答案来源。然后跑一轮离线评测记录三个指标准确率、拒答率、引用准确率。准确率是回答内容是否合规且正确拒答率是遇到未知问题时是否老实说不知道引用准确率是给出的文档引用是不是真的支撑了回答。这三个指标能暴露大部分问题。比如引用准确率低说明检索召回相关度不够需要调切片或换Embedding模型。成本方面我按Token估算。假设平均每次请求读入1200Token输出400Token国内按0.2元每万Token估算单次成本大约0.03元。如果每天10000次请求日成本约300元月成本接近9000元。这个数字能帮团队做容量预估也能反推缓存策略如果用户问题大量重复我可以把高频问答的答案直接缓存跳过模型生成成本和延迟都会明显下降。部署上线后我还会持续做回归每周拿同一份测试集跑一遍比较新Prompt或新模型的效果。AI系统最大的特点是不确定性今天通过的case明天换版本可能就失败。评测集就是AI工程的“自动化测试”没有它你根本不敢改任何参数。6. 常见问题与排查技巧实录6.1 模型输出不稳定这是最高频的问题。现象是同样输入今天返回JSON明天多了一句解释后天直接截断。我一般按三步排查先检查Prompt里是否明确规定了输出格式并给出了示例再检查temperature是否过高抽取任务应该控制在0.2以下最后检查输出后是否有校验逻辑。模型生成是概率性的你不能只“希望”它输出合法JSON必须用代码做二次校验不合法就自动重试或返回兜底话术。我在实践里的一个经验是把输出约束写到工具的返回格式里比如要求模型以Function Calling的方式返回结构化结果或者用JSON Mode。这样模型输出的合法性会高很多。当初我做一个实体抽取项目纯Prompt要求JSON时通过率只有六成切到Function Calling之后通过率稳定在95%以上。所以尽量把格式要求交给框架去约束不要全靠Prompt里的“请务必”。6.2 Agent循环卡死Agent最常见的故障是陷入死循环模型不停地调用工具不输出最终答案。我第一次遇到时任务日志刷了几百行全是同一条搜索请求看着都头大。原因往往是工具被过度鼓励Prompt里写着“你可以多次搜索”但没有告诉它什么时候该停。后来我给Harness加了三个硬约束最大迭代次数设为5到10次、全局超时设为30秒、每一步之间必须比较前一步结果如果工具返回没有带来新信息就强制结束。排查这类问题我靠的是完整的trace日志。每执行一步就记录这轮的模型推理、工具名、入参、返回摘要和Token消耗。出现死循环时回放日志很快就能看到是哪一步开始重复的然后针对性调整Prompt或工具描述。不要试图在模型里“教育”它别死循环用工程手段锁定边界才是正解。6.3 部署内存爆炸私有化部署最常见的事故是OOM。有一次我给一个8G显存的环境部署模型把--max-model-len设成32768结果进程一启动就崩溃日志提示CUDA out of memory。检查后发现模型本身参数占了不少显存KV cache又是动态分配的窗口设太大直接挤爆了。解决办法是把窗口降到4096或8192同时调低--gpu-memory-utilization预留更多空间给缓存。另一个隐藏炸弹是日志文件。业务侧如果把每次推理的完整输入输出都打进日志几天就能占满磁盘。我会把日志轮转打开或者只记录截断后的摘要。内存爆炸还有一个多进程陷阱。如果用FastAPI默认的多worker模式每个worker都会加载一份模型显存翻倍。推理服务最好单worker用Batch机制扛并发。实在需要水平扩展就多加几台机器做负载均衡而不是在一台机器上硬堆进程。6.4 上下文丢失做RAG问答时用户经常反馈“明明资料里有它却说不知道”。这种上下文丢失的坑一般有几种。第一检索TopK太小真正的答案排在第六位没被召回。第二切片太碎关键信息被切散了语义不完整。第三召回的内容和问题表面相似但实际无关模型不敢用。排查时我先看日志确认系统到底召回了哪些片段。如果是TopK问题我调大到8或10如果是语义不匹配我会在Embedding前对文档做摘要或者加一个重排序模型把真正相关的片段提到前面。另一种“丢失”是Prompt里的资料太长模型只关注了开头内容。我会在组装Prompt时把相关度高的片段放在最靠前的位置并在Prompt里明确写“优先参考第一条资料”。这些细节看着小但对生成稳定性影响很大。上下文管理做到最后拼的还是对细节的把控。最后分享一个我个人积累多年的体会从零开始做AI工程真正难的不是某个算法而是把不确定性一点一点变成确定性。你现在每给系统加一条校验、加一层超时、加一段日志都是在给自己的项目上保险。不要迷信某个框架能一次性解决所有问题先把最简单的主链路跑通再针对真正出现的故障去迭代。希望你少踩几个坑早日做出自己满意的AI应用。