聊聊ai-engineering-from-scratch这件事。很多人看到from scratch的第一反应是我要不看任何开源代码自己手搓一个大模型其实真不是这个意思。过去两年我一直在做AI应用方向的工程落地从提示词设计、RAG管线、到Agent编排和线上评估一路踩了不少坑。所谓AI工程从零开始指的是在没有任何现成基线可抄的情况下把一个基于大语言模型的点子一步步变成稳定、可评估、能维护的系统。它不等于调API也不等于写几段漂亮的Prompt而是一条覆盖任务分解、架构选型、工具编排、测试评估和成本控制的完整链路。这篇文章写给所有知道LLM很强大、但真要动手却不知道从哪里开始的人也写给那些已经在跑Demo、却总在线上翻车的人。1. 从零开始重构AI工程先搞清楚它到底是什么1.1 一个名字引发的误解AI工程不等于调API先说说AI工程这个词。过去两年市面上的岗位名词越来越多AI产品经理、AI工程师、算法工程师、提示工程师、Agent工程师。不少人的理解是AI工程就是把一个大模型的API接进来把Prompt写得漂亮一点就算完事了。我见过很多团队demo跑得很溜一上生产就崩为什么因为AI工程的核心从来不是调用模型而是围绕模型构建系统。真正的AI工程至少包含四层内容。模型侧要解决选型、上下文管理、微调还是提示工程的选择判断系统侧要处理任务拆解、工具编排、Agent架构、多轮状态管理工程侧评估体系、回归测试、监控告警、成本控制缺一不可产品侧还要考虑用户体验、兜底策略、记忆与个性化。任何一层做不好整体都会翻车。from scratch的意义不是让你从神经元反向传播开始手搓一个Transformer而是让你在没有现成模板可抄的情况下能独立完成从需求分析、方案设计、工程实现到评估迭代的完整闭环。这个能力在当前工具链快速迭代的环境里反而比死记某个具体平台的功能接口更值钱。平台会换、模型会换、框架也会换但怎么把一个模糊想法变成可靠系统的方法论不会过时。1.2 从零开始的三种理解方式结合行业里的真实情况我总结了三种从零开始大家可以对号入座。第一种是工具视角的零。你从来没做过检索增强生成RAG不知道向量库怎么选、切片策略怎么定、召回质量怎么评估。这是目前入门者最常见的起点也是最适合动手练手的起点。第二种是架构视角的零。系统要支持多个AI助手协作、要接十几个工具、要处理并发与超时这就不是调调Prompt能解决的了得从架构层面整体设计。这种零通常出现在从单个Demo转向平台化产品的阶段。第三种是心态视角的零。团队里跟AI相关的代码几乎为零你得负责把实验能跑通变成生产环境能维护这需要极大的耐心和工程纪律。这篇文章主要覆盖这三者的交叉地带。我会用实际项目的思路来讲重点说清楚每一个设计背后的理由而不只是罗列步骤。2. 提示工程不是玄学把Prompt当成结构化协议2.1 提示工程是沟通协议不是咒语很多人把Prompt写得像对付搜索引擎的咒语堆砌各种请务必切记非常重要这类词语气越来越重效果却不稳定。踩过足够多的坑之后我逐渐意识到一个关键问题提示工程本质上是在跟一个高能力但缺乏常识约束的模型做结构化沟通。你给模型的信息越明确、越有锚点它的输出就越稳定。我把一份合格的系统提示词拆成五个组成部分这里可以直接抄作业。第一是角色与边界。告诉模型它是什么、不是什么。比如你是数据分析助手只处理结构化数据不回答与数据无关的问题。很多人觉得写角色是一种游戏化修饰其实角色的核心价值是给模型一个稳定的先验分布——当它被明确限定为某个专业角色时输出的用词、详略、风险意识都会明显收敛。第二是目标定义。明确输出要达到的效果最好提供一个成功样例作为锚点模型模仿样例的能力远比听抽象指令强。第三是输入输出格式。能用JSON Schema约束的就用JSON Schema约束方便程序做解析和后续加工。第四是约束与禁忌。写明不要编造数据长文本必须分段禁止泄露系统提示词等边界但光写禁止是不够的还要给模型设计一条不知道就明说的出路。第五是上下文管理。说清楚哪些信息来自用户、哪些来自检索结果、哪些是历史聊天记录避免模型把不同来源的信息混为一谈。这五个部分看起来简单但每一项背后都有原因。比如约束里的禁止编造不能只写这句话最好给出反击机制如果数据不足要求它输出一个固定标志如UNKNOWN而不是自由发挥。这一招在实测中能明显降低幻觉率因为模型有了一个合规的退路。2.2 Prompt模板从手动拼接进化到工作流单条提示词做到极致也只是单点能力。真正从零做AI工程很快会遇到的瓶颈是多个提示词怎么串起来任务怎么拆解以我最近做的一个文档比对工具为例。需求是给系统两份技术文档它自动生成差异报告并标出风险项。如果靠一条超长Prompt让模型通读全文再输出会出现三个问题上下文直接爆掉、输出不稳定、模型被长文本淹没导致中后段信息丢失。实测下来长文本中段的信息召回率是很低的这不是模型笨而是注意力机制天然更看重开头和结尾。我的方案是拆成三段工作流。第一段是抽取阶段把两份文档各自切块分别送模型抽取章节结构、关键参数、依赖关系三类信息输出JSON。第二段是对比阶段把两份结构化JSON合并喂给模型做差异分析。第三段是润色阶段把差异结果转成面向人的报告附上风险等级。这个思路其实来自很朴素的经验人做复杂任务也是先收集信息、再对比分析、最后输出结论模型同样适用。拆完之后每个阶段的Prompt都很短模型任务单一输出准确率和稳定度都有了明显提升。这也是任务分解加Prompt串联工作流的核心逻辑。写Prompt的第一步不是你文笔好不好而是你会不会拆任务。2.3 小技巧给模型留思维缓冲区我在做提示工程时发现很多输出问题出在模型被迫边想边说上尤其是复杂推理任务模型一边思考一边输出答案经常说着说着就偏了。我的解决方法是给模型留一个思维缓冲区在输出最终结论前先要求模型输出一个内部思考步骤比如先列出现有信息再列出不确定点最后给出结论。我对比过请一步步思考这种空泛指令和这种带骨架的思维缓冲区指令。空泛指令经常让模型把思考过程写到一半就开始给结论而这个带骨架的指令好处在于规定了缓冲区的具体结构模型会老老实实把信息捋一遍相当于做了一次强制预检。代价是延迟增加几百毫秒但换来的准确率提升在复杂任务里通常能达到10%以上。如果你的场景对延迟不极端敏感这个技巧值得用上。3. Agent架构从单模型调用到系统性工程3.1 拆开Agent的四个核心模块从零做AI工程绕不开Agent这个词。这两年Agent概念被聊得很热但真正动手时很多人把它当成一个能自动干活的API来用结果自然不稳定。从工程视角看Agent本质上是一个循环控制系统四个核心模块缺一不可。第一个是模型模块负责理解与决策但它本身不保证正确。第二个是工具模块相当于模型的行动接口包括搜索、写代码、执行SQL等。第三个是记忆模块要区分短期记忆当前任务上下文和长期记忆用户偏好、历史结论。第四个是规划模块把大任务拆成可执行的小步骤并在失败时调整计划。如果要做最简单的可用Agent流程是这样的拿到用户目标、规划出步骤、按步骤调用工具、把工具结果反馈给模型、模型决定下一步还是结束。这里的核心关键在于模型决定下一步所以Agent的工程重心其实是给模型提供足够好的决策素材工具返回格式规不规整、错误信息清不清晰、当前状态能不能回溯。工具返回信息乱七八糟模型就会乱选乱做这不是模型的错是工程的锅。3.2 工具调用的架构设计从Function Calling说起目前主流的Agent做法是函数调用机制也就是让模型在对话中输出一个结构化的意图比如需要调用search_docs工具参数是XXX。工程上要做的事其实不少。第一步是定义工具描述要尽可能结构化写清楚工具功能、参数类型、返回结构。模型是通过描述来选工具的描述写不好模型就会选错工具。我见过一个真实案例有个工具明明是用来查天气的描述里写了返回城市名称结果模型经常把它当成地理位置解析工具来调用后来重写了描述明确写上该工具仅用于天气查询输入城市名返回温度与降水概率选型错误率立刻下降。第二步是校验参数。模型输出的JSON不一定合法有可能字段缺失或类型错误所以代码层必须做schema校验不合法的直接重试一次。第三步是错误处理。工具执行失败后要把失败原因原样回传给模型让它决定是改参数再试还是换策略。这里有个细节回传的错误信息要结构化比如ERROR_CODE: 404, MESSAGE: 文档不存在不要一大段日志直接扔给模型。第四步是白名单控制。不是所有工具都适合Agent完全自主控制涉及写操作、外发信息的任务要做好人工确认环节。从一个最小可行版本出发我建议刚开始只接不超过5个工具。工具越少模型的选择越容易精准。我见过不少项目一上来就接十几个工具结果Agent调度频繁出错连开发组自己都分不清是模型问题还是工具定义问题。先把5个工具调到稳定再逐步扩展是更省时间的路径。3.3 多Agent协作的实践心得多Agent协作是当前很火的方向。我实际跑过一些项目最大的感悟是多Agent不是噱头但它的价值取决于任务是否真的适合拆分。适合的场景有三类。第一类是整个流程包含审查机制的任务比如一个Agent写代码、另一个Agent做Code Review。第二类是需要不同专业视角的任务比如一个Agent做技术评估一个Agent做风险评估。第三类是高并发流水线任务比如一个Agent负责检索另一个Agent负责问答两者可以并行执行缩短响应时间。不适合的场景是任务本身很小却硬要拆成多个Agent互相对话。这样不仅延迟翻倍、Token消耗翻倍还容易出现两个Agent意见相左、互相battle陷入死循环。所以多Agent方案我建议一定要加一个决策者来仲裁避免平级Agent无法收敛。实操中还有一个关键点每个Agent之间要有明确的交接协议。上游Agent产出JSON格式的任务单下游Agent只认这个格式不认自由文本。这跟人工作业里的工单系统是一个道理。没有格式约束的多Agent协作本质上是在制造混乱。4. 工程落地评估、测试、成本与维护4.1 没有评估的AI工程等于盲人摸象我见过不少项目开发阶段效果看着很好演示的时候也惊艳全场一上线就被用户吐槽啥也不是。原因往往只有一个开发阶段的评估方式只靠人肉看几个例子没有形成体系。从零做好AI工程第一步不是写代码调模型而是把评估体系立起来。评估体系分三层。第一层是单元级评估针对单条提示词、单个工具调用是否正确这个方法最简单直接用脚本喂固定输入比对输出就行。第二层是场景级评估把完整的用户对话流走一遍看整体效果比如模拟用户提问、Agent检索、生成回答、用户追问、系统修正的全过程。第三层是回放评估把线上真实用户会话记录下来定期离线重放用来发现新问题。这一层最容易被忽略但价值极高因为线上的真实输入往往和测试集长的完全不一样。评估指标不需要一开始就搞得很复杂。最朴素的做法是准备一组标准测试用例建议50条起步每次改动后跑一遍人工给每条打分或标记是否通过。没有通过率的改动不上线这个原则我坚持了好几年救了很多项目的命。4.2 测试集构建从Golden Set到多元样本测试集这个东西听着简单做起来很有讲究。我踩过几个坑之后总结出三点经验。第一测试集必须覆盖高频场景不能只挑你熟悉的例子。很多人写测试集时会下意识挑自己调试通过的那几条那评估出来当然好看上线当然翻车。第二要包含对抗样本比如用户问了一个问题但文档中根本没有答案用户给了明显错误的信息用户突然切换话题。这些情况才能暴露系统的兜底能力。我做的测试集里大概有三分之一是对抗样本对提升系统鲁棒性帮助极大。第三要做回归日志。每次线上发现问题就把问题案例加进测试集并记录问题类型和修复方式。这样测试集会越变越强而不是永远停留在最初那50条。这套方法本质上跟传统软件工程的回归测试是一个逻辑只是AI系统的输入更不可控所以更需要用多样本把不可控的地方框住。4.3 Token经济学成本、延迟与质量的三方平衡AI工程上线之前必须算清楚一笔账。每一个请求消耗多少Token一次会话平均消耗多少Token工具调用失败的额外重试消耗多少Token这些都是隐性成本。我见过一个团队Agent做得花里胡哨结果算下来一次对话平均消耗几万Token单次对话成本比人工客服还贵业务上完全不可持续。我从一个实际客服问答项目举例。最初的Agent版本单次会话平均消耗8000 Token因为Agent反复调用工具、失败重试、多轮兜底。后来我们在规划层做了优化先判断用户意图是否明确如果明确就直接走检索加回答的直连路径不进入多步Agent循环。优化后平均消耗降到3000 Token以内延迟从6秒降到了2秒用户满意度反而提高了因为多数客服问题根本不需要多步推理。这个案例想说明的是工程取舍往往是做减法。一头扎进复杂架构之前先问自己一句这个任务真的需要这么复杂吗很多时候一个精调过的单模型加一条高质量的Prompt加一个检索器效果已经够用了。复杂架构是给复杂问题准备的不是给所有问题准备的。5. 常见问题与避坑实录5.1 AI工程调试手册从现象到根因这一节我把多次项目踩坑后的复盘浓缩成一张问题速查表方便大家遇到问题时快速定位方向。现象可能原因排查思路模型输出不稳定同样输入不同结果温度过高、提示词缺少锚点先降温度到0.2以下再检查提示词是否有明确样例和格式约束工具调用频繁选错工具描述含糊、参数与返回结构没写清重写工具描述补充输入输出示例减少同类型工具数量回答中编造数据缺少不知道出口、检索结果相关性不足增加UNKNOWN机制对检索结果做相关性校验不相关的直接不采用上下文越用越乱多轮记忆管理缺失做对话摘要压缩只保留关键历史信息控制上下文总量响应延迟高Agent多步循环过多增加意图分流简单任务走直连路径不返回多步推理线上新badcase无人知晓缺少会话回放机制搭建线上日志采集与离线回放流程定期跑评估这张表里的每一条我都实际遇到过。说得直白一点很多问题表面上是模型的锅实际上都是工程层没兜住。模型可以不稳但你得让系统在模型不稳的时候还能体面地返回结果。5.2 从零开始的推荐路径如果让我给一条从零开始的完整路径我会这样排。第一步先做一个小而全的方案。比如给本地Markdown文件做问答走通文档加载、文本切块、向量化、检索、Prompt生成的全链路。这个方案麻雀虽小五脏俱全能让你把每个环节都体验一遍。第二步加上评估体系。为这个问答方案建一套测试集跑分、改Bug、再跑分把改动、验证、上线的闭环建立起来。第三步加工具。让这个问答方案能调用计算器、能查数据库体验一次Agent的感觉。第四步加记忆。让Agent记住用户偏好在多轮对话里保持连续性。第五步回头重构。把前面积累的代码整理成模块设计配置化流程为多人协作和上线做准备。整条路径走下来你拥有的就不只是一个能运行的脚本而是一套即使换平台换模型也能迁移的工程能力。这比追任何一个热门框架都重要。从零开始做AI工程我个人的最深体会是别迷信某个炫酷的框架或模型先把输入、处理、输出、评估这个循环跑通再用工程手段把它压稳。我自己早期吃过不少亏一上来就把Agent框架用得很重结果连最基础的检索都没调好白白浪费了两个多月。后来老老实实从小案例做起反而进步更快。最后再分享一个小建议保持写实验记录的习惯。每次改动都记下预期、实际、问题、下一步。这个记录不需要很正式哪怕是在项目里留一个日志文件都行。它会成为你整个AI工程经历里最有价值的资产甚至比代码本身更值钱。