AI工程实践指南：从提示词到Agent的完整落地路径

经常有人问我AI工程现在到底是不是换个皮的前端开发说实话这个问题我过去一年被问了几十次。亲手做过几个从零起步的AI项目之后我的答案已经变得非常明确——AI工程是独立的手艺它的核心不是写代码而是围绕大模型构建一套可信、可控、可迭代的系统。这篇文章不聊空洞的概念我直接把从零开始做AI工程的全过程摊开讲从提示词设计、Agent编排、模型选型到评估体系每一步该做什么、为什么这么做、哪些地方容易翻车都给你说清楚。无论你是刚转行的开发者还是已经在写代码但没真正做过AI项目的工程师这份实践路径应该能帮你少走很长一段弯路。1. 先搞清楚AI工程到底在解决什么问题1.1 从能跑通到能上线的鸿沟很多人第一次接触大模型都是被几行代码就能调用ChatGPT这种体验吸引的。写一个demo确实不难装个SDK填上API Key调用一次completion一个聊天机器人就活了。但如果你把这个demo直接扔到生产环境大概率第一天就被打爆。我见过太多团队在demo阶段兴奋得不行一上生产就集体翻车。原因其实不复杂demo只需要回答模型能不能给出合理输出而生产环境要回答的问题多得多——输入变了怎么办输出格式不稳定怎么办用户并发上来之后延迟和成本怎么控模型升级之后行为漂移了怎么发现这些问题没有一个属于调用模型这个动作本身它们全部落在模型之外。而这恰恰就是AI工程存在的理由。AI工程不是魔法它本质上做的是三件事第一把不可控的模型输出变得可控第二把单次的模型调用变成一个有状态、可复用的系统第三让整个系统在持续迭代中不倒退。想清楚这三件事你就明白了为什么AI工程会从普通后端开发里长成一门独立的技术方向。1.2 我理解的AI工程核心能力清单如果你问我一个合格的AI工程师和普通后端工程师最大的区别在哪我的答案是普通后端面对的是确定性的代码逻辑AI工程师面对的是概率性的模型输出咱们所有的工作都是在跟这种概率性较劲。具体来说我认为AI工程的核心能力可以拆成下面五块提示词协议设计不是写咒语而是设计一套稳定的、结构化的输入输出协议让模型稳定执行任务。模型评估体系没有评估就没有工程。你需要一套离线评测集和线上指标才能知道每次改动到底是变好了还是变坏了。Agent编排能力把一次问答升级为多步骤任务让模型学会拆解问题、调用工具、处理中间结果。部署与成本优化延迟、并发、token消耗、模型版本管理每一块都是钱也都是用户体验。鲁棒性与容错模型会出错系统必须能兜底。重试、降级、熔断、输出校验一个都不能少。这五块能力跟传统的软件开发相比多了对不确定性的管理少了对确定性逻辑的依赖。从零开始学AI工程本质上就是把这五块逐一补齐的过程。2. 提示词工程把需求翻译成模型能执行的协议2.1 提示词不是咒语是一条结构化指令我经常遇到一种误解觉得提示词工程就是学一些神奇的魔法词汇比如在提示词里加上请一步一步思考就能提升效果。这类技巧确实有点用但如果把提示词工程等同于背咒语那你大概率做不出稳定可用的系统。我更愿意把提示词理解为一份写给模型的任务说明书。模型本质上是一个没有常识边界的超级实习生它能力很强但你交给它的任务如果没有边界、没有格式要求、没有示例它就会自由发挥。自由发挥在demo里是惊喜在生产环境里就是灾难。举个例子我接手过一个项目需要让模型从用户反馈里提取结构化的问题分类。最初的提示词就一句请分析以下用户反馈判断问题类型。结果模型输出的格式五花八门——有时候返回中文标签有时候返回英文有时候还附带一段分析文字。后来我把提示词改成明确的协议SYSTEM_PROMPT 你是一个用户反馈分类器。你的任务是对用户反馈进行问题类型识别。 必须遵守以下规则 1. 只能输出JSON不要输出任何其他文字。 2. JSON结构固定为{category: 分类名, confidence: 0到1之间的浮点数, reason: 一句话理由} 3. 分类只能是以下枚举值之一[bug, feature_request, usage_question, billing, other] 4. 如果无法判断category输出otherconfidence可以偏低。 5. confidence低于0.4时reason必须说明信息不足。 示例输入登录页面一直转圈进不去 示例输出{category: bug, confidence: 0.9, reason: 登录功能出现异常属于程序缺陷} 这套提示词看起来啰嗦但它把模型的行为空间压缩到了一个可控范围内输出格式锁死为JSON分类枚举锁死为五个值置信度给了明确定义。上线之后解析逻辑只需要一个json.loads加一个枚举校验不需要再去处理各种奇怪的边缘格式。这就是提示词工程和写咒语的本质区别——你设计的不只是给模型看的话更是给下游代码看的数据契约。2.2 设计一套可复用的提示词模板提示词工程做到后面你会发现最值钱的东西不是某一条神级提示词而是一套可以复用的模板体系。我在项目里通常会维护一个模板层把所有提示词统一管理而不是散落在业务代码里到处拼接字符串。# prompt_templates.py from dataclasses import dataclass dataclass class PromptTemplate: system: str user: str temperature: float 0.3 max_tokens: int 512 CLASSIFY_TEMPLATE PromptTemplate( systemSYSTEM_PROMPT, user用户反馈{feedback}\n请输出JSON分类结果。, ) EXTRACT_TEMPLATE PromptTemplate( system..., user..., temperature0.1, )为什么要这么做三个理由。第一提示词的改动是全项目最高频的改动之一集中管理方便做diff和回滚第二模板参数化之后同样的结构可以套用在不同业务场景里比如把分类枚举换成别的枚举一套模板瞬间复用第三模板和代码分离之后方便配合后面的评估体系做批量测试——这个我后面会细讲。2.3 实测中的提示词调优经验提示词不是一次写对的它跟代码一样需要调试。分享一下我调优时最常用的几个手段先把规则写死再谈自由度。新场景的提示词先用最严格的约束固定格式、固定枚举、禁止多余输出跑通之后根据实际效果逐步放宽。放宽一步测一步不要一开始就给模型太大自由。用少量示例锚定输出格式。一个复杂的JSON结构光靠文字描述模型还是可能搞错嵌套关系。给两个正例加一个反例效果立竿见影。温度参数不是越高越有创造性。做结构化抽取任务我一般直接设成0或0.1只有做创意文案、头脑风暴这类任务才会调到0.7以上。很多人忽略这个参数导致抽取结果忽好忽坏其实很多时候根本不是模型问题是温度没调对。输出校验一定要跟上。提示词写得再严谨模型偶尔也会给你来个不合法JSON。所以下游必须有校验和重试逻辑——解析失败就带着错误信息重试一次大部分情况下第二次就正常了。3. 从单次调用走向AI Agent工程化的分水岭3.1 Agent的基本骨架规划、工具、记忆聊完提示词再往上一层就是AI Agent。判断一个AI项目是否真正进入工程化阶段就看它是在做单次问答还是多步骤任务。Agent这个词这两年被炒得很热但拆开来看核心骨架其实就是三块规划Planning、工具Tools和记忆Memory。规划指的是模型把一个大任务拆成多个子步骤工具是Agent调用外部能力搜索、数据库、代码执行器、API的接口记忆是跨步骤保存的上下文状态让Agent记得自己做到哪一步了、已经拿到什么结果了。打个比方单次问答像你去前台问路前台告诉你答案就结束了Agent像你请了一个助理帮你办手续——助理需要先了解你在办什么然后自己决定先去哪个窗口、需要复印什么材料、材料不够的时候怎么处理。这个自己决定下一步做什么的能力是Agent和普通对话机器人的本质区别。3.2 我用Python实现的最小Agent框架网上各种Agent框架很多比如LangChain、LlamaIndex功能确实强。但如果你是从零开始学我强烈建议你先别急着上框架而是自己用几十行代码实现一个最小可用的Agent循环。别看它简陋自己写一遍你会彻底理解Agent到底是怎么工作的。下面是我在项目里写过的一个极简思路只展示核心循环逻辑import json from typing import Callable TOOLS { search: search_web, # 工具搜索 calc: calculate, # 工具计算 query_db: query_database, # 工具查数据库 } def run_agent(task: str, max_steps: int 5): messages [{role: user, content: task}] step 0 while step max_steps: response call_model(messages, toolsTOOLS) tool_call response.get(tool_calls) # 模型决定调用工具 if tool_call: tool_name tool_call[name] tool_args json.loads(tool_call[arguments]) result TOOLS[tool_name](**tool_args) messages.append({role: tool, content: str(result)}) else: # 模型认为可以给出最终答案 return response[content] step 1 return 达到最大步骤限制任务未完成。这段代码的核心就一个循环模型思考 → 决定调工具 → 系统执行工具 → 把结果喂回模型 → 模型继续思考。看起来简单但所有Agent框架的底层都是这个循环。你先把这个循环吃透再去学框架里的复杂编排、并行调度、人机协作这些高级特性基础就非常扎实了。3.3 多步骤任务中的状态管理与错误恢复自己做了一遍Agent循环之后你会发现真正难的不是让模型想下一步干吗而是两个工程问题状态怎么保存错了怎么恢复。先说状态。Agent每一步的中间结果都依赖前一步的输出如果某个环节超时或者进程重启整个任务可能就废了。所以我在实际项目中的做法是每隔几步就把messages完整地持久化到数据库或Redis里并且记录当前步骤数、已经调用的工具、各步骤的结果。这样即使中间崩了也能从最近一个检查点恢复而不是从头再来。再说错误恢复。Agent执行过程中工具调用失败是常态——搜索没结果、数据库超时、参数解析失败。我的兜底策略是三层第一层单个工具调用失败就带着错误信息返回给模型让它决定换个参数重试还是换个工具第二层同一工具连续失败两次直接提示模型跳过该步骤改用其他方案第三层如果整体步骤数超过上限就放弃自动执行转交人工处理。这套策略听起来简单但能让Agent的完成率从惨不忍睹的六成提升到九成以上。4. 模型选型与部署落地别在最后一步翻车4.1 选型判断逻辑与成本估算AI工程做到要上线的时候第一个躲不开的问题就是到底该用哪个模型。很多人选模型只看一个指标——跑分。排行榜上谁分高选谁这种思路在demo阶段没问题但真到工程阶段你会发现跑分高不等于适合你的场景。我每次选型都会列一张类似的对比表判断维度具体问题举例说明任务类型你的任务是生成、抽取、分类还是多轮推理纯粹的分类任务中小模型就够没必要上旗舰大模型延迟要求用户能接受几秒的等待实时对话场景延迟要低离线批量任务可以牺牲延迟换质量成本约束每百万token的输入输出价格你能承担多少高频调用场景模型便宜一点利润就厚一点上下文长度你的输入要处理多长的文本处理长文档需要大上下文模型但成本随token数线性上涨部署方式数据能出外网吗需要私有化吗敏感业务必须私有化部署选型范围直接缩到开源模型这个表看起来简单但真按它走一遍你会少花很多冤枉钱。我见过一个团队做客服工单分类明明用小模型就能达到95%的准确率非要用旗舰大模型结果每个月模型费用占了运营成本的一半以上。后来换成小模型加微调成本直接降到原来的零头准确率还更高了。4.2 部署方案对比托管API、私有化、边缘端模型选完之后紧接着就是部署。我把主流的部署路径分成三类各有各的适用场景托管API直接用云厂商或者模型厂商提供的在线接口。优点是零运维、配置简单、模型迭代厂商帮你管缺点是数据出外网、单次调用成本高、强依赖厂商的稳定性。适合业务验证阶段和一般互联网产品。私有化部署用开源模型比如最近社区里很火的那几个开源权重模型部署在自己的服务器或私有云上。优点数据安全可控、长期成本低缺点是需要自己维护推理服务、处理GPU资源调度、紧跟模型版本更新。适合数据敏感的行业或调用量巨大的业务。边缘端部署把量化压缩后的模型跑在手机、PC、嵌入式设备上。优点延迟极低、完全离线缺点是模型能力受限只能做有限的轻量任务。适合语音唤醒词、端侧摘要、离线翻译这类场景。选哪条路没有标准答案唯一的判断依据是业务边界。我个人的建议是第一优先级永远是最快验证业务托管API先跑起来等用户量、调用量、数据敏感度都上来了再评估是否切换到私有化部署。一上来就搞私有化往往AI功能还没验证清楚光运维成本就拖垮了项目。4.3 性能与稳定性延迟、并发、容错部署上线只是开始真正的工程考验在性能调优。我踩过的坑主要集中在三个地方延迟优化。大模型的单次推理时间动辄几百毫秒到几秒对用户体验影响很大。我常用的手段包括流式输出一边生成一边返回用户体感延迟大幅下降、结果缓存同样的输入直接命中缓存不再调模型、小模型预过滤先用便宜的小模型做粗筛只有拿不准的才交大模型精排。并发控制。模型接口通常有速率限制高并发场景下直接裸调必挂。我的做法是在代码里加一层简单的令牌桶限流同时把不同优先级的请求分流——比如后台批量任务用低优先级队列用户实时请求用高优先级通道互不挤兑。容错降级。模型服务再稳定也有挂的时候必须准备降级方案。我的默认策略是主模型超时或报错时自动切到备用的次优模型如果备用也失败直接返回预设的兜底话术。注意兜底话术也要写得像人话不能把系统错误这种冰冷提示直接甩给用户。5. 评估体系没有度量就没有工程5.1 离线评测集怎么搭很多AI项目做着做着就乱了原因几乎都是同一个缺少评估体系。改了一版提示词凭感觉觉得好像好了一点再改一版又觉得好像差回去了。这种凭感觉迭代的方式根本撑不起一个正经的工程系统。我从大概第三个项目开始就坚持先搭离线评测集再动手改系统。做法其实不复杂首先从真实业务数据里挑出100到300条代表性输入覆盖各种类型和边界情况。比如分类任务每个类别至少20条样本另加一批模糊不清、故意刁难的样本。然后把这些样本的期望输出标注好。标注可以让专家做也可以先用模型预标再人工校正。最后每次修改提示词、换模型、调参数之后跑一遍完整评测集对比整体准确率和逐类别表现。这里有个经验评测集不要一次做完就扔在那要持续补充线上遇到的新案例。凡是线上出过问题的输入一律追加进评测集。这样评测集越滚越大系统对已知问题的回归防护就越来越强。5.2 线上指标与回归防护离线评测解决的是改坏没改坏的问题线上指标解决的是用户在真实环境里满不满意的问题。两者缺一不可。我常用的线上指标大致分三类质量类、成本类、体验类。质量类比如分类准确率的抽样人工审核结果、回答被点赞/被踩的比例成本类比如单次请求的token消耗、模型调用费用体验类比如首字延迟、完整响应时间、用户重试次数。这三类指标要同时监控因为经常会出现为了降成本牺牲质量结果体验崩了这种顾此失彼的情况。另一个容易被忽略的点是模型版本管理。大模型厂商会定期推出新版本很多场景下新版本和旧版本的行为并不完全一致。我见过不止一个项目因为厂商自动升级了模型版本导致线上输出格式变化、解析逻辑崩溃。正确的做法是固定模型版本升级前先在离线评测集上完整跑一遍确认所有指标不倒退再切换。这不叫保守这叫工程。6. 踩坑复盘与我的工程习惯6.1 几个让我印象深刻的坑做AI工程这一年多我踩过不少坑挑几个有代表性的讲一讲希望大家别再踩。第一个坑是输出格式漂移。明明提示词里写了只输出JSON某天线上突然开始出现带Markdown代码块标记的输出导致解析失败。后来排查发现是模型厂商更新了默认行为对这类任务会自动包裹代码块。从那以后我学乖了解析层不再裸写json.loads而是先做一层清洗——去掉代码块标记、裁剪多余空白、提取第一个{到最后一个}之间的内容再进入解析。第二个坑是上下文无限膨胀。一开始做Agent的时候我把所有历史消息全部塞进上下文结果token消耗越来越大响应越来越慢最后模型开始忘记早期的指令。后来改成窗口策略只保留最近的N轮对话加一个长期摘要既控制了成本又保住了关键信息。第三个坑是静默失败。模型偶尔会返回成功状态但内容其实是空的或者完全跑题的。如果下游逻辑没有校验就直接使用轻则数据质量差重则直接把错误结果写入数据库。现在我的所有模型调用下游都有一道内容有效性检查——空内容、超短内容、置信度过低的情况一律走重试或降级流程。6.2 我现在坚持的工作流最后分享一下经过这些坑之后我沉淀下来的日常工程习惯也算是对前面所有内容的一个收口一切改动走评估。不管是改提示词、换模型还是调参数先跑离线评测集再上灰度。绝不凭感觉直接改线上表现。提示词就是代码。所有提示词进版本管理可diff、可回滚、可追溯。提示词出了问题要像代码出了问题一样认真对待。全链路日志。模型输入、原始输出、清洗后结果、下游处理结果全部记录。出了问题第一件事就是翻日志而不是瞎猜。小步快跑。每次只改一个变量——要么只改提示词里有约束力的一段要么只改温度要么只换模型。混着改出了问题你根本不知道是哪一步导致的。预算设上限。线上模型调用必须有成本监控和告警超过预算自动熔断或降级。不要让一个失控的bug吃掉整月预算。我现在回头看从最初那个只会调API的demo到能独立支撑上线业务的AI系统真正的转折点就是搞清楚了一件事AI工程不是在跟模型较劲而是在跟不确定性较劲。模型的能力边界放在那里我们能做的是围绕它把协议、流程、评估、容错这些工程骨架搭结实。骨架搭好了模型哪怕是换个版本、换个厂商你的系统照样稳稳地转。如果你也正从零开始走这条路我的建议很简单先别急着追新框架、新概念把提示词协议、最小Agent循环、离线评测集这三件事亲手做一遍。这三件事做扎实了AI工程的底子你就真正有了。等你哪天开始为系统稳定性和可迭代性头疼而不是为模型会不会回答头疼恭喜你你已经是一名合格的AI工程师了。