上周有个做后端的朋友问我他追了两个月的AI相关文章Agent、RAG、提示词工程这些词都眼熟但真要他从零给业务加一个AI功能完全不知道从哪里下手。这个问题我太有共鸣了。我刚开始做AI工程时也是这个状态——看了无数教程、跑通了无数demo可一到真实项目就发现demo和生产之间隔着一整条工程化的鸿沟。这篇内容就是为从零开始的人写的。它不教你训练大模型也不灌宏观叙事而是聚焦一个AI工程师每天真正在做的事写提示词、搭Agent、设计harness和循环、建评测体系、做AI测试开发把一个通用大模型变成能稳定交付的业务能力。适合想从会用API走向会做系统的研发、想给产品加AI能力的技术负责人以及刚入行但被各种概念轰炸到迷茫的初学者。1. 我理解的AI工程从零开始它既不是炼丹也不是调参1.1 三个工种之间的边界在哪里很多人把AI工程和机器学习混为一谈这是第一个要破除的误解。机器学习工程师的核心战场是模型本身数据清洗、特征工程、算力调度、loss收敛、超参搜索他们的交付物是一个训练好的模型权重。传统软件工程师处理的是确定性系统接口协议、状态流转、异常处理、幂等重试他们的交付物是逻辑可复现的代码。AI工程师恰好夹在中间。你手里的模型通常是别人训练好的——要么调云端API要么用开源权重部署——真正的问题变成了怎么让这个概率模型在真实业务里稳定、正确、可控地干活。打个比方ML工程师负责造发动机传统后端负责造车身和电路AI工程师负责把这台发动机装进车里还要保证它在各种路况下不熄火。大多数人缺的不是发动机而是装车、调校、跑路测的系统能力。所以ai-engineering-from-scratch里的from scratch不是让你从反向传播开始手写神经网络而是说当你的起点只有一张API调用凭证和一个具体的业务问题时你该如何一步步构建出一套能上线的AI系统。1.2 为什么现在从零开始反而更难了按说工具越来越多入门应该更容易才对但现实恰恰相反。我观察到的原因有三点。第一大量教程停在demo层面跑通一个聊天窗口就结束了距离生产环境隔着十万八千里第二抽象层和框架越来越厚很多人会用LangChain的链式调用却说不清底层每次调用了多少token、上下文是怎么拼出来的第三热词迭代速度太快——去年聊prompt engineering今年聊AI Agent再过一阵又是harness engineering、loop engineering——追逐概念的人永远在起跑线而做事的人默默沉淀基本功。我自己带过几个新人最后能独立扛项目的无一例外是先把三件事练扎实了提示词工程、Agent编排、评测体系。这三块基本可以看作AI工程的三大支柱后面所有花哨的技术名词几乎都是在这三根柱子上长出来的。1.3 这篇内容解决什么问题我尽量不看菜谱、不讲空话直接讲我实际怎么做。文章主线是一条完整链路从提示词设计出发到Agent工具调用和编排再到harness与循环控制最后落到评测闭环和落地路线图。每一部分都会讲清楚为什么这么做也会把我踩过的坑直接摆出来省得你再踩一遍。2. 提示词工程从能聊天到可交付的分水岭2.1 提示词的本质是定义边界而不是讨好模型很多人把写提示词理解成跟AI好好说话觉得语气客气点、描述详细点就行。这个认知在玩具项目里够用在生产环境里会出事。我的定义是提示词是一份任务说明书它的核心职责是划定边界。一份能进生产系统的提示词至少包含四个要素角色告诉模型你是谁比如你是客服工单分类助手——角色不同输出风格和知识范围完全不同。任务具体要做什么尽量写清楚输入是什么、目标是什么。约束明确不能做什么比如不要编造订单号拿不到信息时如实说不知道。输出格式要求返回什么结构这是工程化最关键的一环。举个例子我之前做过一个客服工单分类功能提示词的骨架长这样你是客服工单分类助手。 任务根据用户工单内容判断所属类别、紧急程度并给出回复建议。 约束类别只能从[订单问题, 物流问题, 退款问题, 产品咨询, 其他]中选择 紧急程度只能填[低, 中, 高]如果信息不足紧急程度填中并说明原因。 输出严格按JSON格式返回 {category: ..., urgency: ..., reason: ..., reply_suggestion: ...}这四条缺一不可。缺角色模型可能用百科全书的语气回你缺约束模型会给你发明一个不存在的类别缺输出格式后面接结构化解析时你就等着哭吧。2.2 结构化输出让模型进入你的工程体系模型的输出本质是一段文本文本本身没法被程序可靠消费。工程化的第一步就是要求模型输出可解析的结构。现在主流模型厂商的API基本都支持JSON模式直接声明response_format就行。比如OpenAI风格的调用from openai import OpenAI import json client OpenAI() resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是客服工单分类助手只输出JSON。}, {role: user, content: f工单内容{ticket_text}} ], response_format{type: json_object}, ) data json.loads(resp.choices[0].message.content)但这只是第一步。我强烈建议解析之后再做一次schema校验别把json.loads的成功当作万事大吉。模型可能在JSON里漏字段、多加字段、甚至把字段名给你改个拼写。用JSON Schema或者Pydantic校验一遍不合格就走重试或降级路径。这里有一个我从实践中得出的关键配置生产环境的temperature别开太高。很多教程把temperature当成创意旋钮但对结构化输出任务来说temperature越高JSON出错的概率越大。0到0.3是我在多数业务场景里的取值范围既能保留一定多样性又不会让输出碎掉。2.3 把提示词当代码来管理提示词是会变的而且变化的影响比改代码更隐蔽——代码改错了编译阶段就可能报错提示词改坏了可能只是某类case悄悄变差了线上根本不会报警。所以我一直坚持把提示词当代码管至少做到三件事版本化管理一套提示词放一个版本控制目录每次修改都走diff、提交、记录变更原因。配一套golden set每个提示词版本配套一批代表性输入和期望输出改完提示词必须跑一遍回归。变更可回滚线上效果变差时能一键切回上一个稳定版本而不是翻聊天记录找之前那个好使的版本。听起来麻烦但真到线上出问题的时候这是救命稻草。我见过太多团队因为也不知道哪次改坏的几周都定位不了问题。2.4 提示词实战中的四个坑提示词越长越容易自信地错堆砌大量条件反而让模型抓不住重点把你精心写的某些规则当耳旁风。建议主提示词控制在任务能说清的范围内复杂约束通过少量示例来传递。少样本不是越多越好few-shot示例要体现真实分布的多样性尤其是边界case。放20个雷同示例不如精心挑5个涵盖典型和非典型情况的。格式指令放system层最稳把只输出JSON不要解释不要输出markdown这类硬约束放在system消息里别放在user消息末尾实测稳定性高很多。别让模型编造知识生产系统里凡是涉及事实和数据的要么通过工具查询要么在提示词里明确不知道就承认。幻觉这东西只能压低概率没法彻底消灭。3. Agent架构拆解让模型从回答问题变成完成任务3.1 Agent的最小组成模型、工具、记忆、循环单次调用模型做的是回答把模型放进一个能感知环境、调用工具、积累上下文、反复迭代的框架里它才在做任务。AI Agent的最小组成我用一个员工来类比模型 大脑负责理解、决策、表达。工具 手查询订单、读写文件、执行计算、调用第三方接口。记忆 笔记本记录对话历史、业务状态、查过的资料。循环 工作节奏做完一步观察结果决定下一步干什么直到任务完成或放弃。缺任何一环都只能叫加了壳的聊天接口不叫Agent。3.2 Function Calling给模型接上手工具调用function calling是Agent落地的关键机制。模型本身不会主动调你的接口它只是决定要调用哪个工具、传什么参数真正执行的是你的代码。工具声明本质上是一份JSON Schema比如一个查订单的工具{ name: query_order, description: 根据订单号查询订单状态返回物流与退款状态, parameters: { type: object, properties: { order_id: { type: string, description: 订单号通常在消息中由用户提供 } }, required: [order_id] } }工程上要注意三个细节。第一参数必须校验模型传的order_id可能带着空格、标点甚至完全不存在执行前要过一遍校验逻辑。第二工具结果要裁剪数据库查询可能返回100条记录全塞回上下文既费token又分散模型注意力先截断、聚合、提取关键字段再喂回去。第三工具权限要隔离尤其是涉及执行代码、访问文件、操作数据库的场景一定要做白名单和沙箱这个放到下一节harness里细说。3.3 记忆分层别把什么都塞进上下文上下文窗口再大也是预算而不是仓库。把每轮对话、每次工具返回都推进上下文要么很快撑爆窗口要么每轮调用成本高得离谱。我的做法是把Agent记忆分成三层会话记忆保存最近几轮对话摘要长期历史可以滚动压缩。业务状态任务相关的结构化状态比如已确认订单号已查完物流待生成回复存成变量或数据库记录而不是让模型从对话里自己猜。长期知识需要频繁查询的事实性内容放向量检索或普通数据库需要时通过工具取而不是塞在system提示词里。这个分层的直接收益是token成本可控。我实测过不做记忆管理的话一个多轮Agent任务跑下来光重复传递历史内容就能比优化后多花三五倍token。3.4 单Agent多工具还是多Agent协作多Agent协作是热点词但我的态度是先别急着上多数场景一个Agent加一套工具集就够了。什么时候才值得拆任务有清晰的专业边界比如客服Agent和质检Agent各管一摊职责不重叠。不同环节需要不同的权限边界比如一个只能读订单、另一个才能操作退款。单个Agent的上下文和工具列表太长导致决策质量下降。多Agent根本的问题是协调成本任务怎么分结果怎么合边界处出错谁来背锅模型之间的错误还会互相传播。我自己踩过一次两个子Agent互相踢皮球一个说数据已转交另一个说没收到最后跑成一个死循环。后来我改回单Agent多工具问题立刻消失。所以做技术选型时我会先问单Agent更清晰的工作流能不能解决能就不拆。4. Harness与Loop真正的工程化藏在两个低频热词里很多人聊AI工程总盯着模型本身但运行稳定性的关键其实在模型外面那一圈控制逻辑。这两年出现的两个词harness engineering和loop engineering说的就是这层东西。4.1 Harness Engineering给Agent套上缰绳和安全带Harness直译是安全带在AI工程里指的是包裹在Agent外面、负责约束和引导它的一整层控制机制。它的职责包括工具权限控制Agent只能用白名单内的工具只能访问授权内的资源。输出校验与兜底每次模型输出都经过格式、语义、安全校验不合格就拦截。分支与反馈注入系统根据执行结果决定要不要把错误信息、测试结论喂回给模型引导它修正。执行环境隔离Agent的代码执行、文件读写、网络请求都跑在沙箱里防止它闯祸。拿CodeBuddy这类AI编程助手来举例就非常直观。让Agent写代码你不可能让它直接在生产环境里跑改了哪个文件、执行了哪些命令、访问了哪些路径都要受控。一个典型的harness循环是这样的Agent提出修改方案 → 系统在沙箱里应用变更 → 跑测试 → 把测试结果回传给Agent → Agent根据失败信息继续修。这里真正的控制者不是模型而是harness——模型只是被驯服地关在笼子里干活。我见过不少团队忽略这层直接把Agent的返回值当可信变量用结果就是模型一次灵光乍现的输出把生产库给改了。凡是Agent能对外部系统产生影响的动作都必须过harness。4.2 Loop Engineering把一次调用变成可收敛的迭代过程单次模型调用解决不了复杂任务这是共识。于是就有了循环计划 → 执行 → 观察 → 修正 → 再计划。loop engineering就是设计这个循环让它高效、可控、能收敛。关键是定义清楚三件事成功标准什么情况下判定任务完成写代码任务可以是测试全通过写作任务可以是评分达标。没有成功标准Agent就会一直努力。终止条件迭代多少次后必须停超时怎么办达不到成功标准时的降级路径是什么反重复机制模型经常会在同一个错误上打转。我会在每轮反馈里追加一句你上轮的方案已失败原因如下...禁止原样重试实测能明显减少原地兜圈。4.3 循环参数怎么定一张配置参考表以下是我在多个项目里用下来比较稳妥的参数起点具体数值根据任务复杂度调整参数典型取值设计意图最大迭代轮数3~8防死循环和成本失控的第一道闸成功指标测试通过率 / 评分阈值给循环一个明确的终点单轮超时30~120秒避免单次工具调用卡死整个流程temperature0~0.4越靠质量把关的任务越要低反馈窗口最近一次失败详情只喂必要上下文防止越改越乱预算上限按token或按金额写死硬性护栏超了就自动降级人工处理记住一个原则循环是手段不是目的。如果两轮之内没有明显进展说明当前方案或任务拆解有问题继续循环只会烧钱。很多项目上线初期效果不稳不是模型不行纯粹是循环参数没设好——要么死循环烧到账单爆炸要么跑两轮就无脑放弃。4.4 常见失败模式与应对我总结过Agent循环最常见的四种失败自说自话模型假装执行了工具实际在编造结果。应对工具执行要有真实返回并且把返回内容原样呈现。原地打转反复提出同一方案。应对harness里记录历史动作检测到重复就强制切换方向。越改越差反馈注入太多模型被乱七八糟的信息淹没。应对反馈要精炼、结构化只给最相关的失败信息。过早放弃模型判定做不到就停了。应对区分真的做不到和暂时没找到方法用提示词要求它先穷举可行步骤。5. 评测体系没有度量AI工程就是盲飞5.1 确定性系统有单测AI系统靠什么兜底传统软件工程里单元测试、集成测试、回归测试构建了一条确定性的质量线——代码变了能不能通过测试有明确答案。但AI系统天生是概率性的同样的输入两次输出可能不同而且没有一个assert能断言模型输出对不对。所以AI工程必须重新回答一个问题输出好不好怎么度量。我的经验是先把好拆成可检验的维度。比如一个客服回复功能好至少包括三个维度格式正确性JSON能解析、字段齐全、内容准确性类别判断、紧急程度是否符合人工标注、表达质量语气、信息完整度。每个维度对应不同评测方法。5.2 三层评测结构从便宜到贵我会把评测搭成三层每层的成本和粒度都不同层级方法适用场景成本主要弱点第一层规则校验格式、枚举、长度、必填字段、敏感词极低只能查表面查不了语义第二层参考答案比对分类、抽取、摘要等有标准答案的任务中需要准备高质量标注集第三层模型打分LLM-as-Judge问答质量、代码可读性、创意类任务高裁判模型自身有偏差在实际项目里我建议优先把第一层做扎实。很多线上AI翻车翻的其实是格式和基础约束——输出多了句废话、字段缺失、JSON解析失败。这些规则校验就能拦住根本不用动用大模型当裁判。5.3 LLM-as-Judge的实操要点让另一个大模型来给AI输出打分现在很流行但用不好会得出完全误导性的结论。我踩过的坑和对应做法打分必须有量表Judge提示词里明确1-5分各代表什么否则裁判模型的分数没可比性。多裁判投票单个裁判模型的位置偏差和自偏好都是真实存在的——同一个回答放在前面打3分放后面可能打4分。至少用两三个不同模型或随机打乱顺序取平均。用人工标注标定先抽50条人工打分调Judge提示词让模型分数和人工分数趋近再批量跑别直接信模型的分。警惕赞美偏差裁判模型普遍倾向于给分偏高尤其是对表达流畅但不准确的答案。所以评测指标里准确率、召回率这类客观指标永远优先于主观打分。5.4 AI测试开发怎么落地AI测试开发不是让AI帮你写一遍普通单测而是围绕AI行为特征建一套专门的测试资产。我建议至少包含四类黄金用例集覆盖最常见的业务场景改提示词或调循环参数后必须全量回归。边界与对抗用例空输入、超长输入、拼写错误、恶意注入、语义歧义验证边界稳定性。降级路径用例模型超时、服务不可用、输出无法解析时系统是否走兜底流程。成本与延迟监控用例每次评测顺带记录token消耗和响应耗时防止一次改版把成本翻倍还毫无察觉。这四类测试资产最好沉淀成可重复执行的评测套件接进CI/CD流程。每次改动前先跑一遍基线改动后对比增量这个习惯会让你的AI功能从玄学调优变成工程迭代。6. 从0到1的实践路线图六步走完一个AI工程闭环6.1 六步路线图前面几节拆的都是独立能力最后把它们串成一条可执行的路线图。这是我带过多个从零项目的通用节奏步骤核心动作阶段产出验收标准第1步定义成功指标一段量化描述能说出达到什么数字算上线第2步选模型与调用方式模型选型说明效果、成本、数据合规三者有取舍结论第3步搭提示词基线结构化输出可复现的提示词v0.1黄金用例集通过率≥80%第4步加工具调用与Agent编排可运行的Agent流程harness与终止条件齐全第5步建设评测与回归体系评测套件接进CI改动提示词能自动跑回归第6步灰度、监控、迭代线上监控大盘有badcase回流闭环机制第1步最容易被跳过但恰恰最关键。很多人上来就让我做个AI助手我问做成什么样算成功对方答不上来。没有量化目标后面每一步都没有判断标准最终项目沦为聊天demo。6.2 避坑清单我从真实项目里提炼的六条经验坑一有提示词无评测。改提示词全凭感觉线上效果波动也归因不了。评测资产最晚在第3步就要动手攒。坑二Agent循环不设护栏。一台机器半夜跑Agent写代码早上看到账单差点心梗。max_iterations和预算上限必须写死。坑三上下文无脑堆。把整个知识库塞进system提示词既贵又容易让模型抓不住重点。能检索就别塞全量。坑四拿生产数据直接测。隐私和数据合规问题在AI项目里尤其突出测试数据要么脱敏要么合成。坑五忽视延迟。模型推理有延迟一次Agent循环可能要十几次调用用户等不了。优先考虑小模型、缓存、提前并行的手段。坑六不留人工兜底出口。AI功能必须设计降级路径模型不可用时切回规则或人工流程。这是工程成熟度的重要标志。6.3 一点个人体会最后说点题外话。我做了几年AI工程一个很深的感受是你不需要成为大模型专家但你必须成为一个系统层面的把关人。大模型的进步会替你解决模型强不强的问题但模型在业务里稳不稳、准不准、贵不贵、有没有兜底这件事永远是工程问题。另外一个我最近特别强调的小技巧给每个AI功能准备一条人肉逃生通道。无论是回复审核、订单确认前的人工复核还是降级到固定规则模板这条通道的成本不高但它在关键时刻能拦住一次灾难性事故。工程稳健靠的不是模型每次都对而是系统允许模型偶尔犯错且错误不会被放大。
