做AI工程这一年多我最深的感受是很多人不是被技术难倒的而是被工程这两个字难倒的。这里说的AI工程不是让你从零训练一个大模型而是当你手里已经有大模型API、开源模型、Agent框架这些积木之后如何把它们真正组装成能稳定运行、可测试、可维护的产品。我自己从最早只会调API到后来搭起一套包含提示词管理、Agent编排、评估回归、线上监控的完整工程体系中间踩的坑足够写好几篇长文。这篇就围绕AI Engineering From Scratch好好梳理一遍主要是分享给那些正准备从零搭建AI应用工程体系的团队和个人。文章不会给你一堆花哨的概念只讲我验证过的思路、步骤和教训。1. AI工程到底在工程什么1.1 为什么简单Demo和正式产品之间隔着一道鸿沟先聊聊一个最普遍的现象。很多人第一次用大模型API做Demo会觉得这东西简直是魔法几十行代码把用户的输入拼接进提示词推到模型接口一个像模像样的对话应用就出来了。于是很容易产生一个错觉——AI应用开发就这么简单但真正到了要上线一个面向真实用户的产品时你会发现完全不是一回事。Demo阶段你只需要回答能不能跑通产品阶段你需要回答的问题变成了响应延迟能不能控制在两秒以内相近的问题会不会给出不一致的回答用户绕开你精心设计的提示词时怎么办模型的输出如果扰乱了业务逻辑谁来兜底今天用的模型明天涨价了或下架了换哪个这些问题没有一个是靠写更多提示词能解决的它们需要的是工程手段。这就引出了AI Engineering这个概念的真正含义。先明确一个大前提在现在这个时间点从零开始做AI工程已经不再指从零训练模型而是指从零搭建一套围绕大模型构建应用的技术与管理体系。这个体系至少包含五层第一层是模型层负责选型、接入、成本管理和上下文适配第二层是提示词与上下文工程负责把模型的通用能力约束到具体业务上第三层是Agent层负责把单次模型调用编排成多步骤的智能体流程第四层是评估层负责回答这个AI到底行不行第五层是监控与迭代层负责线上行为的追踪和持续优化。这五层每一层都有独立的难点而从零开始意味着不能跳过其中任何一层否则迟早会在某个环节补课。1.2 与传统软件工程相比AI工程的不确定到底在哪传统软件工程的核心是确定性输入确定、逻辑确定、输出确定。我们习惯用单元测试、类型系统、契约测试来保证质量因为代码的行为是可预期的。但大模型应用最核心的特征就是不确定性——同样的输入温度参数设为0也可能得到不完全一样的输出你写了一段精准的提示词用户换一种问法模型的理解可能就偏了模型在逻辑推理任务上可能强得惊人但在一个简单的数字提取上可能犯低级错误。这种不确定性是AI工程与传统工程最本质的区别也是所有新技术、新方法论出现的根源。理解了这一点你才能明白为什么AI工程里会出现一些听起来很虚的做法。例如评估集这个概念本质上就是把这个AI表现好不好从一个主观判断变成一组可量化的测试用例和指标结构化输出本质上是用工程手段把模型的自由文本输出约束成程序可解析的结构护栏机制本质上是在模型输出和业务系统之间加一道校验闸门。凡是你犹疑这有必要吗的做法多半都是在对抗同一个敌人——不确定性。所以从零开始的真正功课不是学会调用模型而是学会与不确定性共处并且用工程手段管理它。2. 搭建AI工程体系的四个关键环节2.1 提示词工程AI应用的第一道门槛先从最容易入门的提示词工程Prompt Engineering说起。很多人以为提示词工程就是把需求描述清楚一点这句话对但远不够。我见过太多失败的案例问题根本不在于提示词写得不好而在于提示词被当作一篇文章在写而不是被当作一套可维护的代码在管理。真正务实的做法是把提示词拆成可复用的模块。举一个我在实际项目里反复使用的结构角色定义区、任务说明区、输入数据区、约束条件区、输出格式区、示例区。这六个区各司其职角色定义区告诉模型你是谁任务说明区描述要做什么输入数据区放置动态变量约束条件区明确不能做什么输出格式区定义返回结构示例区提供few-shot样例。这样做的好处非常明显当业务需求变化时你只需要改对应区域不会因为牵一发动全身而把整段提示词重写当效果变差时你能精准定位是哪一段出了问题而不是对着整段文本瞎调。这个区域的积累就是你的提示词资产。我建议每个团队建一个提示词版本库哪怕最初只是一个文档或表格。我自己会把每次改动记录成类似commit的形式改了什么、为什么改、对应哪个评估用例、效果变化如何。这个习惯在初期看起来有点繁琐但等你的产品迭代三个月以上你会感激当初的记录——否则你根本无法判断是模型升级了还是你的提示词退化导致的效果波动。这里还有个经常被忽略的细节上下文管理。大模型都有上下文窗口限制而工程化的诀窍是区分系统指令和会话数据前者要写进提示词并尽量精简后者要按会话动态灌入。很多新手贪图方便把所有历史对话、大量资料一股脑塞进上下文很快撞上token上限或者让模型被无关信息干扰。记住一个原则上下文不是越多越好而是该有的都有、不该有的别给。2.2 Agent与工作流编排从一问一答到多步任务如果说提示词工程解决的是单次对话的质量那么AI Agent解决的是多步任务能不能自动跑完。这里要澄清一个概念Agent并不是一个具体的技术组件而是一种程序架构——让模型在循环中不断决策下一步动作调用工具、观察结果、再决策直到完成目标。这种决策-调用-观察的循环loop是整个Agent架构的核心也是工程上最有挑战的地方。如果非要类比的话Agent架构很像机器人工程里的感知-决策-行动回路而针对这个循环的工程调优圈内也有人干脆叫它loop engineering。你可能会问为什么不能把多步任务直接写死成固定的函数调用流程答案取决于任务的确定性。如果任务步骤完全固定当然用传统工作流更稳但现实中的很多任务比如研究一下某个行业近一年的融资动态并生成报告步骤是不确定的是先去搜行业报告还是先查融资事件搜到的信息不足时怎么办需要补充哪些维度这些都需要模型在运行时动态判断。所以Agent工程的关键在于如何在让模型自主和保持可控之间找到平衡。我的经验是第一版Agent方案不要搞得过于复杂做成一个单Agent 若干工具的简单架构就够了。先定义好工具接口每个工具负责一件明确的事比如搜索、读取网页、查数据库、执行代码再写一个主循环让模型根据任务描述自主决定调用顺序最后设置终止条件比如达到目标、超过最大步数、或由人接管。这套架构跑通后你才有资格谈论更复杂的多Agent协作。所谓多Agent协作本质上是把一个大任务拆成多个小任务让不同的Agent各自负责一个子任务通过消息或共享状态协同。听起来很酷但它也意味着链路更长、更不稳定、更难调试所以除非单Agent已经解决不了问题否则不要轻易上。在Agent工程里还有一个经常被低估的点就是可靠地回传结果。模型会在复杂任务里不断生成中间步骤但最后交付给用户的必须是一个干净、可验证、符合业务格式的结果。我建议在Agent末端强制走一次结构化输出校验让模型以JSON结构返回结果程序侧再做字段级校验不合法就触发自我修正或重试。这是把看起来智能变成确实可靠的关键一步。2.3 模型选型与调用设计别把鸡蛋放在一个篮子里做AI工程绕不开模型选型。很多人觉得选一个最强的大模型就完事了但工程实践告诉我的恰恰相反单一最强模型往往不是最优解。原因有两个一是成本最强的模型按token计算费用通常是中等模型的数倍甚至一个数量级而你业务里90%的请求可能是简单的分类、提取、改写用最强模型纯粹是浪费二是延迟强模型推理慢对实时性要求高的场景反而拖后腿。所以务实的做法是模型分级策略按任务的复杂度和重要性把请求分配到不同规格的模型上。简单任务用轻量模型复杂任务用强大模型关键任务甚至可以保留人工兜底入口。这本质上是一个路由问题而路由的决策依据可以从提示词长度、意图分类结果、历史成功率等维度来设计。别小看这一层它往往能帮你把单月成本降到原来的三分之一以下同时保持用户体验基本不变。调用的设计同样有讲究。第一超参设置要保持稳定温度和top_p这类参数不要每处随心情改最好在配置中心统一定义第二要统一封装模型调用层让上层业务不感知具体是哪个模型这样以后换模型只需要改底层适配器第三开启重试和退避机制大模型服务经常有偶发的超时和限流调用层要有指数退避的重试策略避免直接报错打断业务流程。这些都是很基础的工程动作但恰恰是很多人从零开始时最容易忽略的部分。2.4 评估体系没有评估AI工程寸步难行我要特别强调这部分内容因为这是AI工程与传统研发最大的不同也是绝大多数从零开始的团队第一个决策失误的地方——他们上线了产品却没有回答这个AI靠不靠谱的评估体系。传统软件有单元测试、集成测试但AI应用的行为高度依赖输入和模型你无法用断言来保证它每次输出都对。所以需要一套专门为AI设计的评估打法。我甚至更愿意把它理解成给AI应用搭建了一个测试护栏harness一个可控的输入输出环境让你能大量注入样本、观察行为、量化表现。最基本的评估集很简单把你业务里最有代表性的真实请求收集起来每个请求配上期望输出或评分标准做成几百到几千条测试用例。跑评估时把测试请求批量喂给你的应用然后逐条判定结果是否达标。判定方式可以是规则校验比如是否包含必填字段、类型是否正确、相似度比对与参考答案的语义相似度、或模型打分用一个更强的模型充当裁判。这三种方式按需组合规则校验最便宜但覆盖有限模型打分覆盖广但要注意裁判模型自身的偏差。评估体系的关键指标我认为有三个功能正确率对常规请求是否输出正确、鲁棒性对异常、刁钻、越界输入是否有合理表现、稳定性相同输入在多次请求中结果是否一致。有了这三类指标你才可能谈迭代。迭代的闭环是这样的线上发现一个坏案例 - 把它加入评估集作为回归用例 - 修改提示词或调整工作流 - 全量跑一遍评估集确认没引入新问题 - 上线 - 再收集新的坏案例。这个循环跑起来AI测试开发和回归保障也就顺理成章地落在同一个闭环里了。我们常说让AI越用越准真正靠的不是玄学而是这套评估驱动的迭代机制。3. 从零到一一套可复制的AI应用搭建路线3.1 一套我实测有效的AI应用架构模板谈了这么多理论接下来给一套我实际验证过的搭建路线你可以直接拿去做参考。无论你的业务是什么一个基础的AI应用架构通常由六个组件组成输入层接收用户请求并进行预处理、提示词组装层从配置中心读取模板填充动态变量、模型调用层统一封装模型API管理重试、超时、成本、工具与知识层外部API、数据库、文档检索等、输出校验层对模型结果做格式和内容校验、以及评估与监控层负责测试、日志、指标上报。以做一个面向内部员工的文档问答助手为例输入层接用户问题先做简短的问题理解和意图分类是查文档还是要总结还是闲聊提示词组装层根据意图选择对应模板把相关文档片段作为知识上下文灌入模型调用层按任务复杂度分配合适模型输出校验层强制模型按JSON格式返回回答引用来源置信度评估与监控层记录每一次问答的请求、响应、token消耗和用户反馈。这个架构大概两三周就能搭出来而且每一层都可以独立扩展——将来要加联网搜索在工具层加一个接口就行要换更强的模型只动模型调用层的适配器。3.2 分四个阶段推进别想一口吃成胖子我强烈建议按四个阶段推进而不是一次性想把所有东西做完美。第一阶段叫跑通目标是让端到端流程运转起来哪怕每步都糙一点重点是打通全链路。第二阶段叫加固把结构化输出、重试机制、异常处理、格式校验一个个加上把线上会翻车的明显漏洞堵上。第三阶段叫测量建立评估集、跑基线、记录指标让好不好变成数字。第四阶段叫迭代根据线上真实反馈持续更新评估集和提示词形成稳定节奏。这四个阶段的先后顺序非常重要尤其是别把第二和第三阶段倒过来没有基本的稳定性你收集到的评估数据本身就是脏的。在这条路上有几个效率工具值得尽早引入。一个是提示词管理工具不需要复杂的平台一个版本化的配置目录就够用一个是本地联调工具能模拟模型响应和超时方便测试异常分支还有一个是可观测性平台把请求日志、token用量、延迟、错误率都集中展示。这些工具的投入都很小但它们决定了你是在黑暗中摸索还是照着仪表盘开车。3.3 多AI协作场景的搭建思路前面提到了多Agent协作这里再展开一下。我理解多AI协作有两种形态。第一种是流水线式协作多个AI模块按固定顺序工作比如先用一个模型做意图识别再用另一个模型做内容生成最后用一个模型做质量校验这种形态工程上最可控适合任务链路固定的场景。第二种是协商式协作多个Agent各有角色和目标通过共享任务列表和结果互相配合适合探索性强的复杂任务。从我踩坑的经验看大多数团队需要的其实是第一种因为第二种虽然听起来更智能但对底层模型的推理能力要求极高很容易陷入循环不收敛、互相推诿、token失控的泥潭。给你一个流水线式协作的具体例子一个自动客服工单处理系统第一步用分类模型识别工单类型第二步用一个Agent抽取关键词和结构化字段第三步用生成模型撰写回复草稿第四步用校验模型检查回复是否合规。每一步的输出都是下一步的输入全程可追踪、可回滚。这种设计的妙处在于任何一个环节出问题你都能精确定位到具体模块去改而不是对着整个Agent系统无从下手。这也是我反复强调的多AI协作的理想目标不是让AI自由发挥而是让不同模型在明确的边界内高效配合。4. 从零开始的路上最容易踩的五个坑4.1 幻觉问题别让AI一本正经地胡说八道大模型幻觉是所有AI应用都必须面对的硬伤。我见过最典型的场景是给AI接了实时天气数据用户在非工作时间问了一个昨天的问题AI由于上下文里没有实时数据直接基于训练记忆编了一个天气关键信息完全错误。解决幻觉没有银弹但有一个组合策略非常有效首选检索增强生成RAG——让模型在回答前先检索可信知识源把它们作为上下文并要求模型没有依据时必须明确说明不知道次选输出校验——用规则或另一个模型检查关键事实性断言最后是引用溯源——要求模型回答时附上信息来源让用户和系统都能核查。这三种手段叠加即使不能100%消除幻觉也能把严重有害的错误大大压下去。4.2 上下文与成本失控预算往往会超出你的预期每轮对话把全部历史都塞进上下文这是成本失控的头号原因。很多人没有意识到大模型API的计费是按token计量的而上下文里的每一个字都在计费。对话历史无限累加每轮的成本就会越来越高如果中间还夹着大段参考资料成本膨胀得更快。我的实践建议是对话历史做滑动窗口只保留最近N轮参考资料做摘要或分段检索只把与当前问题最相关的片段注入长文档的全局背景放到开场总结里。同时给每一个业务场景设置token预算上限超出就降级为简洁模式。成本优化的本质是信息精炼而不是无脑删减。4.3 响应延迟用户没有耐心等你跑完一整轮循环Agent类应用的延迟问题比单轮问答严重得多因为每一轮循环都要调用一次模型再加上工具调用时间用户等待十几秒是常事。解决延迟的核心思路是能并行就并行、能提前就提前、能跳过就跳过。提前指的是把可以预计算的步骤放到前面比如提前把文档向量化并行指的是几个独立的模型调用同时发起跳过指的是在有些场景直接返回部分结果比如先返回一个正在生成的占位响应再用流式输出逐步展示内容。流式输出几乎在所有对话类场景都应该用它让用户在第一字出来时就感到系统已经在工作了对主观体验的提升非常明显。4.4 测试环境的真实性偏差这是我特别想拎出来聊的一个问题。很多团队的AI应用在测试环境表现良好一上生产就崩。原因是测试环境的输入太温柔了用例都是工整的问题、礼貌的表达、规整的格式。而真实用户会乱七八糟地输入会含错别字会在问题里夹带私货甚至会把你的提示词套出来问你是谁让你干什么。所以我会刻意在测试集里加入对抗性样本错别字样本、超长样本、空输入、误导性提问、方言口语等。只有你的应用在这批刁钻输入上仍然不崩、不泄露、不乱答才算具备基本的线上生存能力。测试集里放几个坏样本比放一百个好样本更有价值。4.5 提示词与模型的耦合问题提示词是模型的软配置但很多人把提示词写死在代码里这是后期最大的维护隐患。今天这个模型效果不错明天换了新模型同样的提示词效果可能完全变样今天加一个功能提示词里多塞了一段指令可能连带影响其他功能。正确的做法是把提示词当作一等公民版本化管理、独立于代码存储、支持动态加载和灰度切换。更进一步可以考虑用一个提示词配置中心哪怕只是一个带版本目录的仓库配合线上日志观察不同版本提示词的效果。我踩过最痛的一次坑就是为了修一个边缘case临时改了提示词没意识到它同时影响了一个核心流程结果线上准确率掉了一截还很难定位。从那以后我再也不允许任何人直接在生产环境随手改提示词。5. 过来人的几句心里话5.1 把AI当作协作者而不是更聪明的函数说实话AI工程这条路没有捷径但有方向。从我个人的经验看最重要的认知转变是不要把AI当作一个更聪明的函数而要把AI当作一个需要工程纪律约束的协作者。前者会让你陷入提示词调一调就好了的幻觉后者才会逼你去建立评估、稳定、监控的整套体系。这个体系不是一天建成的但每一块砖都值得砌。先接受不确定性再用工程手段驯服它这是AI工程真正教给我的东西。5.2 每周固定做一次坏案例复盘最后分享一个我特别喜欢的工作习惯每周固定花半天时间把线上收集到的坏案例逐条过一遍分类统计——是幻觉、是理解错、是格式错、还是超时——然后挑出最高频的一类针对性改一个系统点。一个月下来效果往往比盲目迭代提示词好得多。这大概就是AI Engineering从零开始最朴素也最有效的打法。