先从结论说起我见过太多半路转AI开发的同事第一个项目都是调通一个大模型API跑起来一个Demo然后不知道下一步干什么。如果你也卡在这个状态这篇文章就是给你准备的——一份从零开始做AI工程ai-engineering-from-scratch的完整实战笔记覆盖模型选型、Agent搭建、多Agent协作、质量评测到成本与性能控制全程记录我实际踩过的坑和验证过的做法不写调接口就能用的废话。我为什么强调从零开始因为这两年的技术资料呈指数级增长但大部分内容要么是单点技巧比如某个Prompt的写法要么是过于宏大的架构图。真正缺的是中间那层——从能跑通到能上线稳定跑之间的工程化路径。本文适合有基本编程基础、想系统进入AI工程领域的后端或全栈工程师也适合已经在做AI应用但总感觉在糊的同学。下面这些内容都是我用自己的线上项目验证过的可以放心参考。1. AI工程与传统软件工程的本质差异先搞清我们到底在解决什么问题1.1 从确定性逻辑到概率性系统的认知切换我在刚转型AI开发的前三个月最痛苦的不是不会写代码而是旧经验全部失效。传统软件工程的一切方法论比如需求分析、接口设计、单元测试、异常处理底层都建立在同一个假设上系统行为是确定的。你传入一组参数代码走完if-else输出是固定的测试用例断言什么结果就该是什么。大模型打破了这套假设。同一个Prompt温度设为0和0.7输出完全不同即使温度固定模型也可能给出两种都合理但表述不同的答案。你的系统里多了一个概率性组件这就像在一条笔直的流水线上塞进了一个会自己发挥的环节。这不是AI比传统编程高级而是它带来的工程复杂性是另一维度的。传统工程要管理的是复杂度dependency、状态、并发AI工程要管理的则是不确定性uncertainty。你需要接受一个事实你无法通过静态分析百分之百预测AI在某个输入上的表现你能做的只有通过工程手段把不确定性压缩到可控范围。1.2 传统经验哪些能复用哪些必须放弃先说结论工程基础设施层面的经验全部可以继承逻辑层面的经验大多数要改写法。可以照搬的部分版本管理Git、CI/CD流水线、日志与监控体系模块化设计、接口契约、配置管理灰度发布、容量规划、安全审计的基本思路必须重构的部分测试方法论传统断言式测试几乎失效输出是否符合预期变成了概率事件需求描述方式你没法对模型写精确的验收标准只能写good enough的行为准则错误处理模型不会抛异常它只会悄悄输出错误答案这是最难排查的一类bug性能优化调用的延迟和成本取决于模型参数量和上下文长度跟代码算法复杂度关系不大我早期犯的最大错误就是依然按传统方式去优化AI系统——花大量时间调代码性能却忽略了真正影响体验的是模型选型、上下文管理和Prompt设计。这个认知一旦转变整个工程路径就清晰了。1.3 一个从零起步的AI工程能力地图如果把AI工程拆成可训练的能力项我认为核心是六块能力领域解决的核心问题最低要求模型能力认知什么模型适合什么任务知道每个模型的定位、参数量级、价格与速度上下文工程怎么组织输入信息让模型表现稳定掌握Prompt结构、上下文裁剪、检索增强Agent编排怎么让模型完成多步骤复杂任务会设计工具调用、规划器、状态流转质量评测怎么量化模型输出到底好不好能建评估集、跑回归、设定通过标准成本性能怎么让系统跑得又快又便宜会算token成本、做缓存、分级路由安全对齐怎么防止模型胡言乱语或被攻击能做输出过滤、权限控制、敏感内容拦截这六块不是线性的而是互相咬合。比如你做Agent编排的时候如果忽略了评测设计后面系统复杂度上来根本不知道哪个环节崩了你只调Prompt不做成本核算上线一个月账单会教你做人。所以从零开始不要急着铺大摊子按模型认知→单Agent→多Agent→评测→成本的顺序走每完成一层都要考虑下一层的接入点。2. 第一步落地搭一个能上线的Agent而不是玩具Demo2.1 模型选型不是所有场景都要上最强模型代理圈有个通病一上来就选最强模型理由是效果最好。这句话对了一半——效果确实最好但成本和延迟也是最高的。实际业务里大部分请求是简单任务比如关键词抽取、格式转换、信息总结你让一个顶级模型去干这些就像开大货车去菜市场买菜——不是不能是浪费。我的选型逻辑是这样的简单任务分类、抽取、改写、摘要选7B~14B量级的小模型或极速版API速度块成本低中等复杂度代码生成、结构化输出、基础问答选70B级别的通用大模型高复杂度复杂推理、多步规划、创意生成才上最强模型具体怎么判断任务复杂度一个实用的标准是这个任务你自己用规则能不能大致做出来如果能它的逻辑复杂度不高模型不需要太强。任务里需要多少推理步骤、多少隐性知识、多少上下文关联决定了模型的级别。另外一个容易忽略的点模型能力不只是参数规模还有上下文长度和工具调用能力。如果你的Agent需要频繁接入工具选那种Function Calling稳定、格式化输出好的模型比选一个聪明但输出飘忽的模型更省心。工具调用出问题再强的智力也发挥不出来。2.2 工具调用Function Calling的设计原则Agent和普通聊天最核心的区别就在工具调用。模型根据你的指令决定要不要查数据、要不要执行操作然后按约定的JSON格式返回工具调用参数——这套机制叫Function Calling或Tool Use。我设计工具时遵守三条原则第一工具职责单一。一个工具只做一件事描述一定要具体。比如你写一个天气查询工具描述不要写获取天气信息要写根据城市名获取未来24小时天气预报输入参数为城市中文名称。描述越精准模型选错工具的概率越低。第二工具参数用强类型加枚举约束。比如状态字段明确列出合法值pending|processing|completed。模型在受限选项里做选择比自由发挥稳定得多。第三工具返回值要预处理后再给模型。模型上下文宝贵你直接把几十KB的数据库查询结果丢给它成本高还会干扰注意力。应该在工具内部先做聚合、截断、只保留关键字段让返回值尽量精简。我见过太多人忽略这步结果上下文被无意义数据撑爆模型输出质量直线下降。2.3 记忆与上下文管理的完整实现方案Agent记忆是个被严重低估的问题。很多Demo能跑通但一问多轮就失忆本质是上下文管理没做好。我现在的标准做法是三层结构短期记忆就是窗口内的对话历史。关键是做裁剪策略不能无脑塞最后N轮。我按token数动态裁剪保留最近内容并做摘要压缩——当历史超限时调用一次小模型把旧对话压成一段摘要保住关键信息。长期记忆存到向量数据库或普通KV存储里。用户画像、偏好、历史决策结果都放这里在需要时通过检索取回。很多教程说RAG检索增强生成只用来接知识库其实它更通用的价值是给Agent提供记忆检索能力。工作记忆当前任务的中间状态比如规划步骤、已执行操作列表。这个必须显式管理不能指望模型自己记住。每次请求占用的上下文 系统Prompt 工具定义 短期记忆 工作记忆 检索到的长期记忆。你要对每个部分做token预算建议系统Prompt和工具定义不超过总量的四分之一留足空间给任务本身。3. 能力进阶从单Agent到多Agent协作的工程化3.1 为什么要拆Agent复杂任务不是靠更强的模型解决的当任务复杂度超过单个Agent的能力上限时你会下意识想到换更强的模型。这是直觉但往往不是最优解。更有效的路径是把一个复杂任务拆成多个子任务交给不同定位的Agent分别处理。举个我在做的项目例子做一个行业研究报告生成器。如果用单Agent直接生成输出经常出现前后矛盾、论据不足、结构混乱。后来我拆成四个Agent研究员Agent负责检索和分析资料输出结构化要点规划师Agent根据要点拟大纲设计论证路径写手Agent按大纲逐节成文审查Agent检查逻辑漏洞、补充缺失依据把修改意见返回给写手效果提升非常明显。原因在于每个Agent的Prompt被极大聚焦了——研究员只需要总结资料写手只需要写每个子任务的上下文和职责边界都清晰了。模型在单一任务上的表现往往比在多任务上出色很多。3.2 多Agent协作的三要素编排、通信与状态共享多Agent系统设计如果绕开这三个问题就是空中楼阁。分别来说编排。我常用两种模式。一是流水线式A做完给BB做完给C像工厂流水线适合流程固定的任务。二是规划器-执行器式一个规划Agent拆解任务多个执行Agent并行干各自的活最后汇总。前一种简单可控后一种效率高但管理复杂度上升。从零开始建议先跑通流水线再上规划器。通信。Agent之间传什么我的原则是传成果物不传原始记录。比如研究员Agent只传最后的要点列表不传它看过的所有文档审查Agent只传修改意见清单不传全文复述。这样能极大节省token。通信的数据格式建议用结构化的JSON而不是自然语言解析稳定、出错率低。状态共享。多Agent的共享状态最容易翻车。我的做法是引入一个显式的任务黑板Blackboard——一个存着任务ID、当前阶段、中间产出、状态标记的数据结构。任何Agent在哪个阶段写了什么一目了然。这比在Agent间互相传状态可靠因为你随时能知道整个系统卡在哪个环节。3.3 实测一个规划-执行-审查闭环的最小实现我拿代码生成这个场景来说。很多AI编程工具号称写代码实际效果不行的原因是缺少审查闭环。我自己搭的最小方案长这样# 规划器把需求拆成文件级的修改任务 plan_result planner.run( requirementuser_requirement, repo_structurerepo_tree ) # 输出: [{file: src/api.py, task: 添加create_user接口}, ...] # 执行器按计划逐文件改动 for item in plan_result[tasks]: patch coder.run( file_contextget_file_content(item[file]), taskitem[task] ) # 输出: 改动后的代码片段 apply_patch(item[file], patch) # 审查器让另一个Agent检查改动质量 review_result reviewer.run( diffget_git_diff(), requirementuser_requirement ) # 输出: [{file: src/api.py, issue: 缺少参数校验, suggestion: ...}] if review_result[issues]: # 有问题则把审查意见追加上下文让执行器二次修改 fix_patches coder.run( file_contextget_file_content(src/api.py), task修复以下问题: json.dumps(review_result[issues]) ) apply_patch(src/api.py, fix_patches)核心思路是不让一个Agent一口气写完而是让规划→执行→审查三个角色互相制衡。审查环节用的模型不一定要很强但Prompt要足够尖锐专门挑毛病。实际上我跑过一版审查Agent的模型比写代码的弱一档发现审查效果依然不错——因为找问题比解决问题简单但收益极高。4. 让AI系统真正可靠评测、测试与回归防线4.1 为什么传统单元测试覆盖不了AI系统这个问题我踩了很深的坑。最早我用传统方式给Agent写测试——assert xxx in result跑完发现全是绿的一上线就翻车。原因很简单传统测试断言的是确定行为而AI系统即使输出不同语义上都是对的。你在断言里写死了某句话模型换一种说法测试就挂了反过来模型说了句语义完全错误的话只要包含了你断言的关键词测试还是绿的。所以AI系统的测试必须换思路从断言内容转向评估质量。质量怎么衡量要拆成多个维度相关性、准确性、完整性、格式规范性、安全性。而且评估本身往往也要靠模型来打分——这是和传统测试最本质的区别。4.2 评估集的建设从黄金数据集开始质量评测的第一步是建评估集。没有评估集的AI项目优化就是玄学。我是从黄金数据集开始的从历史真实请求里挑100~200条代表性样本其中要包含正常情况、边界情况输入特别长、特别空、带有语言混杂、容易出错的难例。每一条都人工标注标准的输出回答——这就是参考答案。有了这套黄金集每次你改Prompt、换模型、调参数都跑一遍这个集合然后计算与参考答案的匹配度。注意这里的匹配度一般不是字面相等而是分维度人工或模型打分。我通常用四档评分3分完全满足、2分基本满足但有瑕疵、1分存在明显错误、0分完全不相关。70%的样本达到3分、95%达到2分算及格线。4.3 线上回归与灰度发布的工程实践黄金集评测是离线测试但离线做得好不代表线上没问题。真实用户输入千奇百怪总会出现你没覆盖到的case。所以线上必须有第二道防线。我现在的做法是三层结构第一层输出校验。在返回给用户之前用规则或轻量模型检查输出是否符合基本要求长度、格式、敏感词、必须包含的关键元素。不合格就走重试或降级。第二层线上日志抽样。每天随机抽一定比例的真实请求人工或模型打分统计分数分布。异常波动立刻触发告警。第三层灰度发布。任何Prompt或模型变更先切5%流量跑一天对比旧版本的核心指标用户留存、任务成功率、投诉率没问题再逐步放大。这里要特别提醒一下回归测试的自动化。AI迭代速度快每周都可能改Prompt如果没有自动回归根本不知道改动是变好了还是变差了。我为了跑回归写了套简单的流水线git提交触发→批量跑黄金集和影子集→输出各维度评分对比→发不到群里。虽然简陋但每个版本的改动效果都有据可查。5. 真实项目中的成本与性能控制5.1 Token成本模型的精算调用链路上的隐性消耗很多从零开始做AI项目的同学第一个月的账单会让他们震惊。原因就是只算了单次调用的显性成本没算链路成本。我列一个真实公式给你参考。单次模型调用的成本成本 输入tokens × 输入单价 输出tokens × 输出单价÷ 1,000,000假设某模型输入单价是2.5美元/百万tokens输出单价是10美元/百万tokens。一次简单的Agent调用输入3000 tokens系统Prompt工具定义用户请求输出800 tokens单次成本不过(3000 × 2.5 800 × 10) ÷ 1,000,000 0.0155美元看着不多对吧但别忘了多Agent协作一次任务可能调用5~10次模型失败重试会翻倍上下文累积导致输入token一步步涨月调用量可能是几十万次把这些乘起来一个月大几万美元很正常。我见过最夸张的一个项目80%的token消耗在重试和冗余上下文上真正有效输出的不到20%。控制成本先控制这几块。5.2 降低延迟和成本的工程手段缓存、并行与模型分级先聊缓存。模型调用是允许缓存的尤其是重复性请求。我做了两级精确缓存请求内容哈希完全相同直接返回上次结果。适合那些多个用户同时触发相同问题的场景。语义缓存用向量相似度判断新请求和历史请求是否语义相近相近就直接用历史答案。注意这是个双刃剑相似度阈值设太松会返回不相关内容建议结合业务判断什么时候可缓存。再聊并行。很多任务可以拆成多个独立子任务比如同时检索多个数据源、同时生成多章节内容。串行做一次要等10秒并行做可能3秒就完成了。但并行也不是免费的——多路同时调用如果模型供应商有并发限制QPS、Quota要先确认配额再放开。最后聊模型分级。前面讲选型时提过这里说落地策略在系统层加一个路由模块根据任务复杂度判断走小模型还是大模型。最简单的方式是规则路由任务类型含总结、抽取、分类关键字走轻量模型含分析、推理、规划走强模型。进阶方式是小模型先试置信度低再升级大模型——但这个要有置信度评估能力对团队要求高一些。5.3 稳定性兜底超时、重试与降级设计线上跑AI系统最怕的是两件事模型服务超时、输出质量突然崩掉。超时的根因很多模型推理慢、峰值流量大、网络抖动。我的兜底设计是这样的超时控制。给每次模型调用设置合理的超时时间比如流式输出场景60秒无响应就断开。超时重试要加指数退避——第一次等1秒重试第二次3秒第三次8秒。绝对不能无脑立即重试否则模型服务打满全线雪崩。降级策略。当模型服务不可用或输出质量明显下降时系统要能降级而不是硬扛。我的降级顺序是强模型降级到轻量模型→轻量模型降级到模板回答→模板回答都出不来就返回兜底话术并记录工单。记住一个原则AI系统可以蠢但不能崩。用户宁可得到一条系统繁忙也不愿意看到界面卡死或错误乱码。输出质量的门控。我在上一节说过输出校验的重要性这里再补充一个细节如果输出连续N次校验不通过自动切换备用模型或者挂起该用户的任务避免反复空转。这种熔断机制我亲测能救回很多流量高峰期的翻车事故。6. 最后再分享一点我的实战感受从零开始做AI工程本质上是把不可控的聪明驯化成可控的能力。技术栈一路升级但最核心的变化其实是思维方式——我学会了对每一次模型调用保持敬畏输出可能错、可能慢、可能贵。基于这个敬畏所有工程手段才有了意义。如果非要给刚开始的同学几个具体建议我会说第一先建评估集再碰Prompt优化没有度量体系的优化都会变成拍脑袋第二不要迷信最强模型先算清楚成本账再做选型第三任何Agent设计先跑通流水线再上复杂编排稳定压倒一切。按这个顺序走大概率能避开我当年摔过的那些大坑。