做 AI 工程这几年我最大的感触是很多人把“让模型跑起来”和“把 AI 做成产品”混为一谈。调通一个 API、跑通一个 demo离真正的 AI 工程还差着十万八千里。所谓 ai-engineering-from-scratch就是抛开那些花哨的框架和包装从最底层开始问自己一个问题我真的知道这套 AI 系统是怎么被设计、构建、测试和上线的吗这篇文章是我自己从零搭建 AI 能力的完整复盘覆盖 prompt engineering、Agent 架构、评测体系、测试开发这些核心环节写给那些想系统入局 AI 工程、而不是只会套模板调接口的人。我会尽量少讲虚的多讲我在实际项目里验证过的东西哪些方案真的能落地哪些环节最容易翻车为什么 AI 工程不能照搬传统软件工程的套路。读完之后你能得到一套可以照着复现的思路而不是一堆概念名词。1. 先想清楚AI Engineering 到底在解决什么问题1.1 从调接口到工程化的关键转变我见过太多团队第一天接上大模型 API第二天就觉得自己已经AI 化了。结果上线第一周就出问题用户输入稍微绕一点回答就开始胡说并发一高成本直接失控换个模型版本之前调好的效果全部作废。说白了调用模型只是一个起点AI Engineering 关注的是模型之外那一整套系统。传统软件工程的核心是确定性输入固定逻辑固定输出可预期。但 AI 系统的核心组件——大模型——是一个概率系统。同一个 prompt 跑十次结果可能不完全一样稍微改几个字输出风格就变。这就导致一个根本性的转变你没法用测试用例全部通过来定义质量你要定义的是在什么分布范围内表现良好。所以 AI 工程不是会写 Python 会调 OpenAI SDK这么简单。它至少包含几层能力第一层是模型能力的使用包括 prompt 设计、上下文管理、工具调用第二层是应用架构包括 Agent 编排、记忆机制、多模型协作第三层是质量保障包括评测集建设、自动化测试、线上监控第四层是成本和稳定性治理。四层缺了任何一层你做的都只是一个 demo不是一个工程。1.2 为什么传统软件工程的思路不能直接搬很多人觉得我都有多年后端开发经验了做 AI 不就多学一个 API 吗实际落地之后你会发现最大的挑战不是技术而是思维方式。传统开发里bug 是确定性的错误可以定位、可以修复、可以写回归测试。AI 系统里的bug往往是一种倾向性偏差——它不是每次都错而是在某些输入分布下表现差。你说它错了它有时候又能答对。这种问题没法靠修一行代码解决只能靠调整数据分布、优化 prompt、增加约束机制来缓解。还有一个容易被忽略的点传统软件的复杂度主要在代码逻辑AI 系统的复杂度主要在数据配置。模型的权重是黑盒你能控制的只有输入组织方式、评测方式和交互流程。所以 AI 工程里配置和数据的地位跟代码一样重要。我见过不少团队把大量精力花在调模型参数上却连一份像样的评测集都没有这属于典型的力气用错了地方。提示判断一个团队是不是真的在做 AI 工程就看两件事——有没有成体系的评测集有没有线上效果监控。两者都没有的基本还停留在调接口阶段。2. 从零起步技术选型与基础架构搭建2.1 模型选型通用大模型与专用方案的取舍从零开始做 AI 工程第一道选择题就是用哪个模型。这个决定几乎影响后面所有环节值得多花点时间。市面上的选项大致分三类。第一类是商用大模型 API优点是好坏可控、迭代不用自己管缺点是成本会随调用量线性增长而且数据要过第三方。第二类是开源模型自己部署比如 Llama、Qwen 系列优点是没有调用成本、数据不出内网缺点是需要 GPU 资源和运维能力效果调优的难度也更高。第三类是针对特定场景的专用模型或微调模型适合瓶颈明确、数据量充足的场景。我的建议是除非有硬性的数据合规要求否则起步阶段直接用商用 API 是最优解。为什么因为你真正要验证的不是模型能力而是产品和场景是否成立。用开源模型从头折腾部署和调优消耗的时间成本足够你迭代好几个产品版本了。等到业务跑通、数据积累够了再做模型层的替换或者私有化那时候你才有足够的评测集来判断新模型到底行不行。模型选型还有个容易被忽略的维度不是所有任务都需要最强模型。我做过一个客服问答系统90% 的问题比较简单用轻量模型就能答好只有 10% 的复杂问题需要大模型。如果一律用最强模型成本是前一种方案的五六倍。合理做法是做模型路由先让轻量模型处理大部分请求拿不准的再升级到强模型。这一层工程优化往往比你在 prompt 上抠半天效果还明显。2.2 基础设施三件套API 层、向量库、可观测系统确定模型之后基础架构其实比很多人想象的简单。我习惯分成三块模型访问层、知识检索层、可观测层。模型访问层要做的事是统一封装不管底层用哪家模型对外提供一致的接口规范。这一点特别重要因为模型的厂商和版本是会换的。我在一个项目里就吃过亏先用了厂商 A 的模型代码里到处是厂商 A 特定的参数写法后来换成厂商 B改了整整两天。统一封装之后换模型只改一个适配文件。知识检索层是 RAG检索增强生成系统的基础。最早的 AI 应用都是裸奔的直接把用户问题丢给模型。但涉及到私有知识或者时效性内容时纯靠模型内部知识根本不够。RAG 的思路是把文档切块、向量化、存进向量数据库用户提问时先检索相关内容再喂给模型生成答案。这套流程看着简单实际坑非常多——切块大小、检索策略、排序逻辑都会直接影响效果后面我会专门展开。可观测层最容易被新手忽略。传统开发有日志、监控、链路追踪AI 系统一样需要。而且 AI 系统多一个必须记录的东西prompt 和模型输出。不记录下来线上出了问题你连复现都无从下手。我在每个项目里都会要求所有模型调用的输入输出必须落库这是排查问题的底线。2.3 入门技术栈参考如果你正准备从零搭一套 AI 工程骨架我给你列一个我实际用下来比较顺手的组合环节常用选择我的使用说明开发语言Python / TypeScriptPython 生态最全TypeScript 适合胶水层和前端联动模型调用框架LangChain / LlamaIndex / 自研封装框架可以帮助起步但不能被框架绑死向量数据库Milvus / Chroma / Qdrant数据量大用 Milvus小项目直接 Chroma 起步Prompt 管理代码仓库 版本管理别用数据库存 prompt要跟代码走评测工具自建脚本 / PromptFoo早期自建足够后期可以引入框架可观测Langfuse / 自建日志表记录模型调用输入输出和耗时注意框架只是拐杖。我见过太多人用 LangChain 写了几千行抽象代码结果一个简单的 prompt 调用被包了三层出了问题都找不到日志。我的习惯是框架用来快速验证核心链路自己写。3. Prompt EngineeringAI 工程的第一堂必修课3.1 一个好 Prompt 的结构化写法Prompt Engineering 是被讨论最多、也最容易被低估的一环。说它被低估是因为很多人觉得就是写段话嘛。实际上prompt 的好坏直接决定了模型能力的上限表现而且它是 AI 工程里投入产出比最高的优化点。我在团队里推行的是结构化 prompt 写法核心要素有五个角色设定、任务描述、输出约束、示例引导、边界声明。角色设定不是花架子。让模型你是一名资深法律顾问跟直接问问题效果差距很大因为角色会激活不同的知识分布和表达风格。任务描述要具体到步骤级。我常举一个例子与其说帮我分析这段文本的情感不如说请先判断文本整体情感倾向正面/中性/负面然后找出表达该情感的关键句子引用原文最后用不多于50个字解释你的判断依据。任务拆得越细模型的行为越可控。输出约束是工程性最强的一部分。要 JSON 就必须告诉它严格的 JSON 结构要长度限制就必须明确说不超过200字要格式就必须给出格式模板。模型不会主动猜你的心思它只会按你给的信息最大化得分。这套逻辑跟数据库表结构设计很像——约束越清晰数据质量越高。示例引导few-shot是成本最高的优化手段。给两个好的示例往往比在 prompt 里多写两百字描述更管用。示例最好是真实业务数据而且要覆盖边界情况。比如做一个分类任务你给的正例全是典型样本模型就学不会怎么处理模糊样本。3.2 上下文窗口管理容易被忽略的隐蔽工程很多人以为 prompt 写得越长越详细越好这是大坑。模型有上下文窗口限制而且窗口被无关信息占满之后跟任务相关的注意力会被稀释效果反而变差。这个现象行业内叫Lost in the Middle意思说模型对长上下文中间部分的信息记忆最差。实际工程里上下文管理要考虑三块内容怎么分地盘系统提示词占多少、检索到的参考资料占多少、历史对话占多少。我的经验是系统提示词控制在 1000 字以内只放最重要的规则参考资料要经过压缩不是把整篇文章塞进去而是只保留跟当前问题相关的段落历史对话要设置滑动窗口超过一定轮数就做摘要存储。处理长对话时我常用摘要 窗口的策略每隔几轮对话让模型把之前的对话生成一段摘要存起来下次请求时把摘要加上最近几轮完整对话一起提交。这样既能保留背景信息又不会让窗口无限膨胀。这个方案实现起来不复杂但对对话类产品的体验提升非常明显。3.3 Prompts 也要版本管理和测试prompt 是代码是产品逻辑的一部分那它就应该有版本管理。我们团队现在的做法是所有 prompt 以模板文件的形式放在代码仓库里用 git 管理变更。prompt 改了之后必须跑一遍评测集通过才能合入。这个流程一开始执行很难因为大家嫌麻烦但执行几个月后你会意识到它的价值——没有版本管理的 prompt 就是一个无人维护的黑洞你不知道现在的效果是哪个版本产生的。prompt 的评测跟代码测试不太一样。代码测试是断言输出等于预期值prompt 评测是判断输出质量。我的做法分两级第一级是硬性规则检查用正则或字符串匹配校验关键信息是否存在、格式是否符合要求第二级是语义评估把模型输出和参考答案一起发给一个评估模型让它打分或者判断好坏。两级结合基本能覆盖大多数场景。4. Agent 架构从单一模型到复杂协作系统4.1 Agent 的核心组成和设计思路如果说 prompt engineering 是让模型回答得更准那 Agent 工程就是让模型做事情。所谓 Agent简单理解就是让大模型具备感知、决策、行动的能力它能理解目标、决定下一步干什么、调用工具、观察结果、调整策略直到完成整个任务。Agent 的核心组件其实不难理解主要是三块大脑大模型、手工具调用能力、记忆短期上下文和长期存储。工程上真正难的是怎么把它们可靠地组织起来。我自己做 Agent 系统的经验是先把确定性和智能性分开。确定性的流程比如固定步骤的审批、固定格式的调用用代码硬写不确定的决策比如这一步该用什么工具、下一步做什么交给模型。很多人犯的错是让模型去处理所有事情包括那些本来用两行代码就能搞定的逻辑结果模型发挥不稳定整个系统跟着飘。工具调用是 Agent 工程的核心机制。现在主流模型都支持 function calling也就是让模型输出一个结构化指令指明要调用哪个函数、传什么参数然后你的代码执行这个函数并把结果返回给模型。设计工具接口时要特别注意两点工具的说明要写得足够清楚包括什么时候用、参数含义、返回值结构工具的粒度要适中太大模型不好控制太小则调用次数过多、既慢又有累计错误风险。4.2 多 Agent 协作的几种实战模式单 Agent 做不了太复杂的任务这是我在实践中得到的结论。复杂任务要么拆成多步要么拆成多角色。多 Agent 协作的常见模式有几种。第一种是编排模式一个主 Agent 负责理解用户需求把任务拆解后分发给子 Agent最后汇总结果。这种模式适合内容生成类任务比如写行业报告一个 Agent 做资料收集一个 Agent 做数据分析一个 Agent 负责撰写一个 Agent 负责校对。第二种是流水线模式任务按固定顺序经过多个 Agent 处理。比如客服工单系统先由分类 Agent 判断工单类型然后由处理 Agent 给出解决方案最后由质检 Agent 审核答案。这种模式的可控性强每个环节都能单独评测和优化。第三种是会商模式多个 Agent 扮演不同角色对一个问题进行讨论最终得出共识。这种模式适合需要多角度分析的场景比如技术方案评审让一个 Agent 扮演架构师、一个扮演运维、一个扮演安全专家分别提意见。多 Agent 协作的难点不在把多个 Agent 串起来而在怎么保证协作的效率和稳定性。每多一个 Agent就多一层错误累积的可能。我的建议是能用单 Agent 解决的就别上多 Agent多 Agent 架构里每个子 Agent 都要有独立的评测指标否则你根本不知道是哪个环节拖累了整条链路。另外不要所有消息都靠模型转发Agent 之间的中间结果可以走结构化数据只在需要语义判断时才调用模型。4.3 Harness把 Agent 关进可控制的笼子里我这两年深有体会的一个概念是 harness——你可能在 AI 工程社区听到过它的名字包括 harness engineering 的提法。这个词直译是马具在 Agent 工程里它指的是把模型行为约束在一个可编程、可观测、可干预的框架内。为什么需要 harness因为大模型天然是不可控的。你问它一件任务它有无数种方式去执行。如果没有约束它可能调用错误的工具、按照错误的方式解析数据、甚至陷入循环出不来。harness 的思路就是给 Agent 套上一层工程骨架规定好思考格式比如必须输出结构化的当前状态-下一步动作、规定好可用工具集合、规定好输出格式和终止条件。我做一个数据查询 Agent 的时候就深刻体会到了没有 harness 的恐怖。模型为了回答一个上季度销售额的问题把数据库所有表都扫了一遍调用了几十个函数耗时好几分钟最后还是答错了。加上 harness 之后我先限定它能用的查询接口强制它先输出查询计划再做执行每一步都记录日志超过 5 步主动终止并降级。结果任务成功率和响应时间都大幅改善。用业内的话说Agent 的能力是模型给的但 Agent 的可靠性是 harness 给的。工程的重点不应该放在期待模型更聪明而应该放在怎么约束和引导模型让它的不稳定性被控制住。5. 让 AI 系统可测试、可评估、可上线5.1 评测集建设先定义好再谈优化AI 工程最核心的质量保障手段是评测集。没有评测集你做的所有优化都是盲人摸象——你觉得 prompt 改好了可能只是碰巧手上几个测试样例表现好换个输入就露馅。评测集的建设思路跟写单元测试很像但有它自己的特点。我习惯把评测集分成几个层次核心功能集覆盖产品最主要的使用场景保证基本盘不出错边界情况集覆盖模糊输入、空输入、超长输入、对抗性输入专门用来测模型的防御能力回归集记录历史上修过的 bug防止问题复发。评测集的规模和标注质量比想象中更重要。我见过有人用几百条样例做评测就觉得自己覆盖得很全面实际效果极不稳定。我的经验是起步阶段至少准备 100-200 条高质量的标注数据并且随着线上运行不断补充真实用户输入。这个数字看着不多但标注要精细——每一条都要明确期望答案和评分标准。这不是一次性的工作而是一个持续演进的资产。评测执行也有讲究。早期可以用人工评但到了后期一定要引入自动化评估。常见的做法是用一个强模型当裁判给模型输出打分。这里有个细节裁判模型本身也可能有偏见所以打分标准要写清楚最好结合具体场景比如回答是否包含关键事实是否给出明确行动建议这种可判别的标准而不是模糊的回答质量好坏。5.2 AI 测试开发自动化测试在智能系统里的应用传统测试开发的经验在 AI 工程里不是没用而是要升级。接口、单元、集成测试照样要做但多了一层模型输出的测试。这个场景业内也经常叫 AI 测试开发核心逻辑是构建一套自动化测试流水线在模型更新、prompt 修改、代码变更之后自动跑评测集输出质量报告。链路的重点是变更必测。我实际落地的一套流程是这样的代码仓库里放评测集和测试脚本每次 prompt 模板或代码有变更CI 流水线自动触发评估任务把变更前后的结果对比输出一份过拟合率原有效果被破坏的比例和改进率。比例不达标就不允许合并。这个流程虽然粗暴但非常有效它强制团队养成每次改动都验证效果的习惯。自动化模型测试有个比较棘手的问题模型输出不稳定。同样的输入和 prompt今天跑和明天跑结果可能略有不同。所以 AI 测试不能只看一次结果我一般每个用例跑 3-5 次取多数结果来判断是否通过。这是一个详细但必要的细节避免你被输出不稳定导致的假性失败/成功干扰判断。5.3 上线之后的监控、反馈与迭代闭环模型上线不是终点是另一个起点。传统系统上线后监控的是错误率、延迟、负载AI 系统除此之外还要监控语义层面的质量指标。线上监控我分成几个维度。第一个是硬指标调用量、响应时间、Token 消耗、成本。Token 消耗尤其要关注成本跟流量是线性关系一个 prompt 设计不好成本能翻好几倍。第二个是软指标用户反馈包括用户主动点踩、投诉、对话中断率。第三个是抽检指标定期从线上日志里抽样人工或者用模型评估回答质量形成一个质量趋势线。闭环迭代是 AI 工程是否成熟的分水岭。线上每天会积攒成千上万条真实用户输入这些都是天然的评测数据。我要求团队每周从线上数据中挑出表现不好的案例分析原因是 prompt 问题、是知识缺失、还是检索不到相关内容补进评测集再针对性优化。这个轮子转起来之后系统的效果会持续改善转不起来的效果就只能靠运气。6. 常见问题与排查技巧实录6.1 高频问题速查表把这两三年遇到的典型问题整理成一份速查表希望能帮你少踩一些我踩过的坑。症状常见原因排查方法回答时好时坏prompt 约束不够、模型版本不稳定跑多次评测检查 prompt 是否足够具体回答偏长/偏短输出约束缺失或无效明确长度限制用示例规范格式回答与事实不符知识时效性问题、检索遗漏引入 RAG对关键事实做验证调用超时一次生成太长、工具循环太多限制 max_tokens、设置工具调用步数上限成本飙升上下文过大、模型选择不合理做上下文压缩、启用模型路由上线正常但一周后效果变化模型方更新了底层版本关注模型版本公告维护固定版本或快速适配检索内容不相关切块策略不合理、检索匹配逻辑太简单调整分块大小、引入重排序rerank补充召回策略对话多轮后跑偏历史管理缺失做滑动窗口 历史摘要策略6.2 我踩过的几个坑和避坑建议第一个坑是过分迷信 prompt 万能论。早期我做智能客服效果不好第一时间就认为是 prompt 写得不够好来回折腾角色设定和语气。后来才发现很多问题出在知识检索——模型根本没拿到正确的信息。做 AI 工程一定不要局限于一个环节要系统诊断整条链路是输入问题、检索问题、模型问题还是输出解析问题逐步排查。第二个坑是忽略输出解析的脆弱性。模型输出格式稍微变化你的解析代码就崩。后来我学乖了所有模型输出一律要求结构化格式而且解析逻辑要写得宽容兼容可能的格式偏差。实在无法保证时就用模型二次修正把输出清洗一遍。第三个坑是低估成本管理的价值。一个项目上线后我仔细核算过发现每个月花在模型上的费用里30% 都是无效消耗——比如把整份文档塞进上下文、反复调用大模型做简单的文本格式化。后来我们做了严格的 token 审计把该省的都省下来成本降了 40%。成本管理不是财务的事是 AI 工程的核心工作之一。第四个坑是数据隐私合规意识不足。处理用户数据时涉及敏感信息一定要做脱敏和授权检查尤其在使用第三方模型时要明确数据边界。我在做企业项目时凡是涉及客户核心数据的场景一律用私有化部署或本地模型这个红线不能碰。6.3 思维模式的最后一点建议从零开始做 AI 工程最重要的不是学会某个具体工具而是建立一套以评测-迭代-监控为核心的工程循环。模型本身会越来越强工具会不断更新但你建立的那套质量保障和数据闭环体系才是真正跟随你的能力。我个人在实际操作中的体会是AI 工程跟传统软件工程最大的区别在于耐心。传统项目是部署上线就基本结束了AI 项目恰好相反部署上线之后真正的优化才刚开始。如果你接受了这个设定把心态从做成调整成持续做好那些枯燥的评测、监控、迭代工作就不再是负担而是系统效果越做越稳的底气来源。有一点我想额外强调在这个领域里被裁减掉的风险永远高于被夸大低估的错误——宁可用最朴素的方案把质量做扎实也不要盲目追逐最新框架让自己陷入失控。根据我的经验那些能长期稳定运行的 AI 系统往往不是用了最酷技术的而是评测和监控做得最扎实的。希望这篇复盘能帮你少走点弯路。