1. AI工程到底是什么做的1.1 从“会训练模型”到“能交付系统”这两年我越来越明显感觉到一个变化身边不少人已经能把一个AI模型跑起来甚至能在notebook上做出漂亮的demo但一到真正交付项目就卡壳。卡的地方不是模型本身而是模型之外的工程链路。这也正是“ai-engineering-from-scratch”这个主题想聊的核心——从零开始做AI工程更准确地说是围绕AI能力构建一个可维护、可评估、可部署的完整系统。很多人对AI工程的第一印象是“我要训练一个模型”但实际做下来你会发现真正花时间的地方往往是数据、提示词、评测、接口、异常处理、监控这些“杂活”。在真实业务里AI工程更像是一门关于“约束”的学问数据质量约束、成本约束、延迟约束、安全合规约束。模型只是一颗强劲的引擎只有装进工程这台车才能载着业务跑起来。我自己的入门经历就是从一次崩溃开始的。当时我接到一个需求想用大模型做智能客服问答。模型选型、Prompt写得自认为很完美结果一到测试阶段代码里出现编码问题、超时问题、token风控问题、上下文长度问题整整改了四天。直到那时候我才意识到AI工程不只是写两段prompt而是一整套从数据到部署的全链路实操能力。所以这篇文章主要是给那些已经会用大模型API、看过几篇Prompt教程、但还没独立交付过一个AI系统的朋友准备的。我会按从零到一的项目生命周期把最容易被忽略的工程细节掰开揉碎讲讲方案选型、实际步骤、常见坑和应对方法。1.2 一个最小AI系统的完整组成很多人对AI系统有误解认为AI系统就是“模型服务器 前端页面”。实际上一个能稳定工作的AI系统即使是最小粒度至少包含五个部分组成作用常见形态接入层处理外部请求REST API、WebSocket、消息队列编排层决定AI能力的调用流程LangChain、自研Pipeline、状态机模型层提供推理能力云API、私有化模型、开源模型数据层提供知识与记忆向量库、知识库、Redis缓存保障层监控、评估、限流、防抖日志系统、评估集、监控面板我第一次做的时候根本没有“编排层”的概念所有逻辑都堆在一个函数里结果每次改需求都要重写一遍测试也没法分开跑。后来开始拆分模块把每一个环节独立出来才体会到“工程化”三个字的价值。工程化的核心是把“不确定的AI能力”封装在“确定的流程”里。大模型的输出有随机性但你的系统不能因此变得随机。对外提供的接口要稳定对内可观测出错了能快速定位。这些不是模型能力而是工程能力。2. 从零开始的第一阶段明确问题与数据准备2.1 问题定义与验收指标从零开始做AI工程第一步往往不是选模型而是把业务问题翻译成技术指标。很多项目最后失败并不是模型不够强而是最开始的目标就定得模糊。老板说“做个智能助手”产品说“能回答用户问题”开发说“调用一下大模型API”最后上线了却没人能说清楚“好用”是什么标准。我习惯用的方法是把问题拆成三层第一层业务目标。比如“减少客服人工介入的比例”。第二层功能范围。比如“覆盖退货、发票、物流查询三类问题”。第三层技术指标。比如“答案准确率超过90%”、“响应时间低于3秒”、“未识别问题必须转人工”。这三层逐级对齐才可能做出真正可验收的AI系统。技术指标里最容易被忽视的是“失败率”。一个AI系统不可能100%正确但你必须定义什么情况下算失败以及失败后系统如何兜底。是返回兜底话术还是转人工还是重试一次这些流程没有提前设计后面上线就会被动。另一个关键决策是评估方式。小团队做AI工程不建议一开始就搞复杂的自动评估平台。可以先整理50到100条覆盖典型场景的测试问题人工跑一遍统计正确率。后面再考虑引入LLM-as-a-judge或者基于规则的自动化评测。我见过太多团队花大力气搭评测平台结果测试集质量一塌糊涂评测结果根本不可信。2.2 数据收集与清洗的实操要点数据是AI工程的地基但很多人对数据的理解停留在“下载一个数据集”。真实项目里数据往往散落在客服记录、工单系统、Excel表格、聊天日志里格式混乱、噪音大、隐私敏感直接丢给模型就是灾难。以知识库问答项目为例数据准备的优先级是这样的首先是收集原始语料。从业务系统里导出常见问答、操作手册、历史工单。导出时务必保留时间和来源字段方便后面做数据溯源。然后是清洗这一步的工作量最大。常见问题包括HTML标签混在正文里、全角半角不统一、敏感信息未脱敏、重复内容过多。写脚本批量处理的时候要特别注意“长文本截断”问题——很多大模型有上下文长度限制超过上限的部分会被直接忽略而截断处往往是答案的关键位置。我的做法是先按标题或段落切块再根据模型的上下文限制做滑窗拼接。第三是构造QA对。很多原始语料是纯文本不是问答形式。你可以用大模型辅助生成候选问题再人工审核。这里有个技巧不要只生成“正面问题”还要生成“边界问题”和“陷阱问题”。比如用户问“你们发票怎么开”和“红冲发票怎么开”是两种难度后者容易被模型答错。最后是数据版本管理。AI工程的数据是可迭代资产每次修改都要像代码一样记录版本。我自己会用一个简单约定原始数据放在raw/目录清洗后的数据放clean/带版本号和日期。别看这件事简单后面做模型回归测试时你会发现没有版本管理根本没法对比效果。3. 模型选择与Prompt Engineering的工程化3.1 面对大模型首先学会写Prompt模型选型是另一个容易纠结的问题。我的建议是先用最直接的云服务API做原型验证效果后再考虑要不要优化成本、换开源模型或私有化部署。一上来就搞私有化部署大概率在卡点和运维上耗尽精力业务效果反而不重要了。选型时的核心考量有四个维度效果、速度、成本、可控性。效果用你自己的测试集说话别只看榜单分数速度要实测不同并发下的响应延迟成本要算的是“单个完整请求”的成本而不是每千token的标价因为Agent类应用一个请求可能调用模型很多次可控性则要考虑数据安全、合规要求以及你对供应商的依赖程度。Prompt Engineering在整个AI工程里属于“看起来容易、做好极难”的部分。从工程角度Prompt不是灵感创作而是需要版本化、可测试、可维护的代码资产。我见过最好的团队是把Prompt当作代码来管理的有版本号、有diff记录、有上线审批流程、有回归测试。而最常见的反例是在代码里硬编码大段Prompt改的时候全局搜索替换改完不知道影响了哪些场景。工程化的Prompt有几个要点。第一结构清晰把系统角色、任务指令、输入格式、输出格式、边界说明分开。第二给例子尤其是narrow格式的示例能显著减少模型的理解偏差。第三定义“不知道”的行为明确告诉模型没有把握时应该如何回应避免编造。第四对输出做约束要求JSON格式时用结构化的输出方式不要只靠Prompt里说“请输出JSON”因为模型仍可能输出多余文字。3.2 模型评估与回归测试Prompt改了一版之后怎么确定效果真变好了光靠肉眼测两三个case远远不够。AI工程的最大陷阱之一就是“感觉变好了”但换个输入就崩。所以我强烈建议从项目第一天就建立自己的回归测试集。它不需要很大但必须有代表性每个核心场景至少5个正例、2个边角例、1个恶意或异常例。每次修改Prompt、换模型、调参数都跑一遍这个测试集记录通过率变化。具体操作上早期可以人工评估。随着case数增多再引入自动评判。用大模型当裁判也就是LLM-as-a-judge是个省力的办法但要注意裁判偏差。我自己常用的做法是给裁判模型一套明确的打分标准包括正确性、完整性和合规性三个维度每个维度用1到5分。然后定期抽样20条让裁判模型打分再人工与模型打分对照观察双方是否一致。如果不一致就调整评分标准。评估还有一个重要对象延迟和token消耗。一个Prompt看似简单但可能让模型多思考几轮导致响应时间翻倍、成本上涨。工程上要监控每次请求的输入token、输出token和耗时建立基线。质量满足要求后再回头压成本和延迟。4. 真正复杂的部分AI Agent与多模块协作4.1 Agent的组成当你的AI系统不再局限于“一问一答”需要自主规划、调用工具、多步推理时就进入了Agent的领域。很多热词都在说AI Agent是AI工程的下一个方向这点我是认同的但工程复杂度会大幅上升。一个最小Agent通常包含几部分模型核心、指令系统、工具集、记忆模块、执行循环。模型负责推理指令系统定义Agent的角色和约束工具集让Agent能调用外部能力查数据库、发邮件、调API记忆模块保存历史交互信息和中间结果执行循环控制Agent如何一步步迭代。我在实际搭Agent时的一个感受是不要让模型“什么都自己决定”。模型自由发挥的空间越大出错后的排查越难。工程上的做法是收紧边界给Agent定义明确的子任务步骤每一步允许调用哪些工具哪些操作需要人工确认。这不叫限制AI这叫工程管控。比如做一个“自动撰写周报”的Agent不要一上来就让它自由汇总全部聊天记录。更好的设计是第一步从知识库提取本周完成事项第二步按照模板生成初稿第三步收集数据指标填入报表第四步让负责人确认后发送。每一步都是独立的函数Agent只负责编排和判断。这样的架构即使模型某一步判断错了你也能快速定位到具体环节。4.2 多AI协作的可靠性问题热词里的“多AI协作”也是我最近重点研究的方向。多个Agent或模型协作理论上可以各司其职比如一个负责计划一个负责执行一个负责审查。但实际工程中有两个问题特别棘手token成本爆炸和错误传播。token成本爆炸很好理解。两个模型来回对话每一轮都消耗上下文token多轮下来一个简单任务可能消耗几千甚至上万token。我测试过一个双Agent协作写文案的场景每一轮互相“点评修改”结果跑一轮的成本直接抵得上普通API调用的10倍。后来加了两个限制最大轮数不超过3轮以及两个Agent共享同一段历史摘要而不是全量传递上下文。错误传播是指上游模型的错误判断会在下游层层放大。比如第一个Agent识别用户意图时错了后面的所有Agent都会在错误方向上继续执行。应对方法有两个一是在关键节点加“人工审核闸门”二是为每个子Agent配备“置信度自评”当置信度低时主动请求人工介入不要硬着头皮往下走。还有一点值得注意多AI协作不等于多模型乱炖。没有明确分工和协议Agent之间的对话就是灾难。工程实现上一定要把协作流程抽象成数据流每一步的输入输出都定义清楚并记录到日志里。这样出了问题你至少能回答“哪个环节错了”。5. 部署与运维把AI系统跑起来5.1 部署形态选择从代码到上线AI工程的最后一公里往往是部署。部署形态选择不是越先进越好而是看你的场景匹配度。如果你的系统调用的云上大模型API部署简单很多只需要做好服务代理、限流和缓存。比如高频重复问题用Redis缓存答案能省下大量调用成本。缓存键可以直接用问题文本的hash但要注意改写问题的召回率可以用embedding相似度做缓存判断不过这会引入额外的模型调用看性价比。如果你用的是开源模型并私有化部署就要考虑GPU资源、推理框架和扩展方式。我的经验是先用vLLM或SGLang这类成熟推理框架而不是自己写推理服务。它们做好了连续批处理、显存管理和流式输出工程坑已经被填平了。部署时另一个关键点是“优雅降级”。模型服务挂了系统不能跟着挂。要在API网关层做熔断模型调用失败时走兜底逻辑比如返回缓存结果或提示“稍后再试”。这一行兜底逻辑往往决定了用户对你的AI系统是“可靠的工具”还是“玩具”。5.2 监控、日志与反馈闭环AI系统上线只是开始监控才是长期维护的核心。传统软件的监控关心QPS、延迟、错误率AI系统还要多关心几项输入内容分布、输出内容质量、幻觉率、用户反馈。日志要结构化。我的习惯是每次模型请求都记录以下字段请求ID、用户ID、模型名、输入输出token数、延迟、Prompt版本号、模型返回内容、用户后续行为点赞、点踩、复制、再次提问。这些数据积累下来就是AI系统迭代的弹药。Prompt版本号这一点很多人会忽略。模型服务端一般不感知你用的是哪个Prompt但你自己的日志系统必须带上。否则哪天线上效果波动你连“现在用的是哪版Prompt”都不知道。用户反馈要设计得轻量。比如回答底部加“有帮助/没帮助”两个按钮。关键不是按钮本身而是“没帮助”的数据要每天有人看、有人分析。我见过很多系统的反馈数据躺在数据库里没人处理那这个反馈闭环等于没做。安全合规方面AI系统的输入输出都必须做内容过滤。输入侧防止恶意指令注入输出侧防止生成违规内容。这里的策略不只是“加一个审核模型”还包括在Prompt里写清边界、限制输出长度、对敏感问题拒答。合规不是上线前的例行公事而是贯穿数据、训练、部署、运营全流程的约束条件。6. 进阶路线与避坑经验6.1 团队角色与工程方法做了一段时间AI工程后我发现一个事实AI工程并不是“AI算法团队”专属的事。它更像是一个交叉领域需要混合角色。在最顺利的项目里至少要有三种能力懂业务的工程师负责把业务问题翻译成AI问题懂数据的工程师负责治理和评估数据质量懂模型的工程师负责模型选型、调优和推理优化。小团队里这三种能力往往要集中在一个人身上。那就要学会区分什么该自己深入、什么该借助工具。模型训练细节可以以后慢慢补但数据治理和评估体系是必须优先掌握的。因为这就是AI工程的“工程”部分。工程方法上我强烈推荐把传统软件工程的好习惯带进来代码评审、单元测试、CI/CD、Code Review。AI工程虽然有不确定性但业务流程的骨架是可以做确定性测试的。比如“输入意图识别”模块就可以写单测给一段话断言返回的意图是否正确。Prompt改动引发的问题往往就靠这些确定性测试兜底。6.2 我踩过的坑总结最后整理一下我在从零做AI工程这条路上踩过的坑希望能帮大家省点时间。第一个坑在项目初期花太多时间调模型效果而忽略了系统的错误处理。模型回答不理想至少用户还能看得懂服务超时、乱码、崩溃用户直接就流失了。正确顺序应该是先保证主流程稳定再优化效果。第二个坑不记录中间结果。Agent流程里模型每一步的输入输出如果没日志出了问题就是一片黑盒。现在我的习惯是核心环节把输入输出快照存进日志方便事后回放。第三个坑Prompt“一把梭”。一个Prompt从500字增到5000字能解决一些问题但很快会进入边际递减。把复杂任务拆成多个子Prompt配合代码逻辑来分步执行往往比超大Prompt更可控、更省钱。第四个坑忽略成本治理。大模型API是按token计费的尤其是加了多轮记忆后每次请求都在烧钱。我现在的规则是和核心任务无关的内容不塞进上下文历史对话只保留摘要能用缓存解决的绝不重复调模型。第五个坑过度设计。项目刚开始就上K8s、上消息队列、上多Agent框架结果一星期还没跑通第一个端到端流程。从零开始做AI工程最快的方式永远是“最简复刻”用脚本把主流程跑通再逐步加工程化能力。你不是在造火箭你是在解决一个具体的业务问题。根据我个人的体会AI工程最有魅力的部分恰恰是你把一堆摆脱不了“不确定性”的组件通过工程手段编织成一个相对稳定的产品。这个过程没有捷径但每一步踩坑、每个细节优化都会在线上运行的数据里看到回报。希望这篇从零开始的记录能给你带来一些有价值的参考。
从零开始构建AI工程：大模型应用的全链路实操指南
1. AI工程到底是什么做的1.1 从“会训练模型”到“能交付系统”这两年我越来越明显感觉到一个变化身边不少人已经能把一个AI模型跑起来甚至能在notebook上做出漂亮的demo但一到真正交付项目就卡壳。卡的地方不是模型本身而是模型之外的工程链路。这也正是“ai-engineering-from-scratch”这个主题想聊的核心——从零开始做AI工程更准确地说是围绕AI能力构建一个可维护、可评估、可部署的完整系统。很多人对AI工程的第一印象是“我要训练一个模型”但实际做下来你会发现真正花时间的地方往往是数据、提示词、评测、接口、异常处理、监控这些“杂活”。在真实业务里AI工程更像是一门关于“约束”的学问数据质量约束、成本约束、延迟约束、安全合规约束。模型只是一颗强劲的引擎只有装进工程这台车才能载着业务跑起来。我自己的入门经历就是从一次崩溃开始的。当时我接到一个需求想用大模型做智能客服问答。模型选型、Prompt写得自认为很完美结果一到测试阶段代码里出现编码问题、超时问题、token风控问题、上下文长度问题整整改了四天。直到那时候我才意识到AI工程不只是写两段prompt而是一整套从数据到部署的全链路实操能力。所以这篇文章主要是给那些已经会用大模型API、看过几篇Prompt教程、但还没独立交付过一个AI系统的朋友准备的。我会按从零到一的项目生命周期把最容易被忽略的工程细节掰开揉碎讲讲方案选型、实际步骤、常见坑和应对方法。1.2 一个最小AI系统的完整组成很多人对AI系统有误解认为AI系统就是“模型服务器 前端页面”。实际上一个能稳定工作的AI系统即使是最小粒度至少包含五个部分组成作用常见形态接入层处理外部请求REST API、WebSocket、消息队列编排层决定AI能力的调用流程LangChain、自研Pipeline、状态机模型层提供推理能力云API、私有化模型、开源模型数据层提供知识与记忆向量库、知识库、Redis缓存保障层监控、评估、限流、防抖日志系统、评估集、监控面板我第一次做的时候根本没有“编排层”的概念所有逻辑都堆在一个函数里结果每次改需求都要重写一遍测试也没法分开跑。后来开始拆分模块把每一个环节独立出来才体会到“工程化”三个字的价值。工程化的核心是把“不确定的AI能力”封装在“确定的流程”里。大模型的输出有随机性但你的系统不能因此变得随机。对外提供的接口要稳定对内可观测出错了能快速定位。这些不是模型能力而是工程能力。2. 从零开始的第一阶段明确问题与数据准备2.1 问题定义与验收指标从零开始做AI工程第一步往往不是选模型而是把业务问题翻译成技术指标。很多项目最后失败并不是模型不够强而是最开始的目标就定得模糊。老板说“做个智能助手”产品说“能回答用户问题”开发说“调用一下大模型API”最后上线了却没人能说清楚“好用”是什么标准。我习惯用的方法是把问题拆成三层第一层业务目标。比如“减少客服人工介入的比例”。第二层功能范围。比如“覆盖退货、发票、物流查询三类问题”。第三层技术指标。比如“答案准确率超过90%”、“响应时间低于3秒”、“未识别问题必须转人工”。这三层逐级对齐才可能做出真正可验收的AI系统。技术指标里最容易被忽视的是“失败率”。一个AI系统不可能100%正确但你必须定义什么情况下算失败以及失败后系统如何兜底。是返回兜底话术还是转人工还是重试一次这些流程没有提前设计后面上线就会被动。另一个关键决策是评估方式。小团队做AI工程不建议一开始就搞复杂的自动评估平台。可以先整理50到100条覆盖典型场景的测试问题人工跑一遍统计正确率。后面再考虑引入LLM-as-a-judge或者基于规则的自动化评测。我见过太多团队花大力气搭评测平台结果测试集质量一塌糊涂评测结果根本不可信。2.2 数据收集与清洗的实操要点数据是AI工程的地基但很多人对数据的理解停留在“下载一个数据集”。真实项目里数据往往散落在客服记录、工单系统、Excel表格、聊天日志里格式混乱、噪音大、隐私敏感直接丢给模型就是灾难。以知识库问答项目为例数据准备的优先级是这样的首先是收集原始语料。从业务系统里导出常见问答、操作手册、历史工单。导出时务必保留时间和来源字段方便后面做数据溯源。然后是清洗这一步的工作量最大。常见问题包括HTML标签混在正文里、全角半角不统一、敏感信息未脱敏、重复内容过多。写脚本批量处理的时候要特别注意“长文本截断”问题——很多大模型有上下文长度限制超过上限的部分会被直接忽略而截断处往往是答案的关键位置。我的做法是先按标题或段落切块再根据模型的上下文限制做滑窗拼接。第三是构造QA对。很多原始语料是纯文本不是问答形式。你可以用大模型辅助生成候选问题再人工审核。这里有个技巧不要只生成“正面问题”还要生成“边界问题”和“陷阱问题”。比如用户问“你们发票怎么开”和“红冲发票怎么开”是两种难度后者容易被模型答错。最后是数据版本管理。AI工程的数据是可迭代资产每次修改都要像代码一样记录版本。我自己会用一个简单约定原始数据放在raw/目录清洗后的数据放clean/带版本号和日期。别看这件事简单后面做模型回归测试时你会发现没有版本管理根本没法对比效果。3. 模型选择与Prompt Engineering的工程化3.1 面对大模型首先学会写Prompt模型选型是另一个容易纠结的问题。我的建议是先用最直接的云服务API做原型验证效果后再考虑要不要优化成本、换开源模型或私有化部署。一上来就搞私有化部署大概率在卡点和运维上耗尽精力业务效果反而不重要了。选型时的核心考量有四个维度效果、速度、成本、可控性。效果用你自己的测试集说话别只看榜单分数速度要实测不同并发下的响应延迟成本要算的是“单个完整请求”的成本而不是每千token的标价因为Agent类应用一个请求可能调用模型很多次可控性则要考虑数据安全、合规要求以及你对供应商的依赖程度。Prompt Engineering在整个AI工程里属于“看起来容易、做好极难”的部分。从工程角度Prompt不是灵感创作而是需要版本化、可测试、可维护的代码资产。我见过最好的团队是把Prompt当作代码来管理的有版本号、有diff记录、有上线审批流程、有回归测试。而最常见的反例是在代码里硬编码大段Prompt改的时候全局搜索替换改完不知道影响了哪些场景。工程化的Prompt有几个要点。第一结构清晰把系统角色、任务指令、输入格式、输出格式、边界说明分开。第二给例子尤其是narrow格式的示例能显著减少模型的理解偏差。第三定义“不知道”的行为明确告诉模型没有把握时应该如何回应避免编造。第四对输出做约束要求JSON格式时用结构化的输出方式不要只靠Prompt里说“请输出JSON”因为模型仍可能输出多余文字。3.2 模型评估与回归测试Prompt改了一版之后怎么确定效果真变好了光靠肉眼测两三个case远远不够。AI工程的最大陷阱之一就是“感觉变好了”但换个输入就崩。所以我强烈建议从项目第一天就建立自己的回归测试集。它不需要很大但必须有代表性每个核心场景至少5个正例、2个边角例、1个恶意或异常例。每次修改Prompt、换模型、调参数都跑一遍这个测试集记录通过率变化。具体操作上早期可以人工评估。随着case数增多再引入自动评判。用大模型当裁判也就是LLM-as-a-judge是个省力的办法但要注意裁判偏差。我自己常用的做法是给裁判模型一套明确的打分标准包括正确性、完整性和合规性三个维度每个维度用1到5分。然后定期抽样20条让裁判模型打分再人工与模型打分对照观察双方是否一致。如果不一致就调整评分标准。评估还有一个重要对象延迟和token消耗。一个Prompt看似简单但可能让模型多思考几轮导致响应时间翻倍、成本上涨。工程上要监控每次请求的输入token、输出token和耗时建立基线。质量满足要求后再回头压成本和延迟。4. 真正复杂的部分AI Agent与多模块协作4.1 Agent的组成当你的AI系统不再局限于“一问一答”需要自主规划、调用工具、多步推理时就进入了Agent的领域。很多热词都在说AI Agent是AI工程的下一个方向这点我是认同的但工程复杂度会大幅上升。一个最小Agent通常包含几部分模型核心、指令系统、工具集、记忆模块、执行循环。模型负责推理指令系统定义Agent的角色和约束工具集让Agent能调用外部能力查数据库、发邮件、调API记忆模块保存历史交互信息和中间结果执行循环控制Agent如何一步步迭代。我在实际搭Agent时的一个感受是不要让模型“什么都自己决定”。模型自由发挥的空间越大出错后的排查越难。工程上的做法是收紧边界给Agent定义明确的子任务步骤每一步允许调用哪些工具哪些操作需要人工确认。这不叫限制AI这叫工程管控。比如做一个“自动撰写周报”的Agent不要一上来就让它自由汇总全部聊天记录。更好的设计是第一步从知识库提取本周完成事项第二步按照模板生成初稿第三步收集数据指标填入报表第四步让负责人确认后发送。每一步都是独立的函数Agent只负责编排和判断。这样的架构即使模型某一步判断错了你也能快速定位到具体环节。4.2 多AI协作的可靠性问题热词里的“多AI协作”也是我最近重点研究的方向。多个Agent或模型协作理论上可以各司其职比如一个负责计划一个负责执行一个负责审查。但实际工程中有两个问题特别棘手token成本爆炸和错误传播。token成本爆炸很好理解。两个模型来回对话每一轮都消耗上下文token多轮下来一个简单任务可能消耗几千甚至上万token。我测试过一个双Agent协作写文案的场景每一轮互相“点评修改”结果跑一轮的成本直接抵得上普通API调用的10倍。后来加了两个限制最大轮数不超过3轮以及两个Agent共享同一段历史摘要而不是全量传递上下文。错误传播是指上游模型的错误判断会在下游层层放大。比如第一个Agent识别用户意图时错了后面的所有Agent都会在错误方向上继续执行。应对方法有两个一是在关键节点加“人工审核闸门”二是为每个子Agent配备“置信度自评”当置信度低时主动请求人工介入不要硬着头皮往下走。还有一点值得注意多AI协作不等于多模型乱炖。没有明确分工和协议Agent之间的对话就是灾难。工程实现上一定要把协作流程抽象成数据流每一步的输入输出都定义清楚并记录到日志里。这样出了问题你至少能回答“哪个环节错了”。5. 部署与运维把AI系统跑起来5.1 部署形态选择从代码到上线AI工程的最后一公里往往是部署。部署形态选择不是越先进越好而是看你的场景匹配度。如果你的系统调用的云上大模型API部署简单很多只需要做好服务代理、限流和缓存。比如高频重复问题用Redis缓存答案能省下大量调用成本。缓存键可以直接用问题文本的hash但要注意改写问题的召回率可以用embedding相似度做缓存判断不过这会引入额外的模型调用看性价比。如果你用的是开源模型并私有化部署就要考虑GPU资源、推理框架和扩展方式。我的经验是先用vLLM或SGLang这类成熟推理框架而不是自己写推理服务。它们做好了连续批处理、显存管理和流式输出工程坑已经被填平了。部署时另一个关键点是“优雅降级”。模型服务挂了系统不能跟着挂。要在API网关层做熔断模型调用失败时走兜底逻辑比如返回缓存结果或提示“稍后再试”。这一行兜底逻辑往往决定了用户对你的AI系统是“可靠的工具”还是“玩具”。5.2 监控、日志与反馈闭环AI系统上线只是开始监控才是长期维护的核心。传统软件的监控关心QPS、延迟、错误率AI系统还要多关心几项输入内容分布、输出内容质量、幻觉率、用户反馈。日志要结构化。我的习惯是每次模型请求都记录以下字段请求ID、用户ID、模型名、输入输出token数、延迟、Prompt版本号、模型返回内容、用户后续行为点赞、点踩、复制、再次提问。这些数据积累下来就是AI系统迭代的弹药。Prompt版本号这一点很多人会忽略。模型服务端一般不感知你用的是哪个Prompt但你自己的日志系统必须带上。否则哪天线上效果波动你连“现在用的是哪版Prompt”都不知道。用户反馈要设计得轻量。比如回答底部加“有帮助/没帮助”两个按钮。关键不是按钮本身而是“没帮助”的数据要每天有人看、有人分析。我见过很多系统的反馈数据躺在数据库里没人处理那这个反馈闭环等于没做。安全合规方面AI系统的输入输出都必须做内容过滤。输入侧防止恶意指令注入输出侧防止生成违规内容。这里的策略不只是“加一个审核模型”还包括在Prompt里写清边界、限制输出长度、对敏感问题拒答。合规不是上线前的例行公事而是贯穿数据、训练、部署、运营全流程的约束条件。6. 进阶路线与避坑经验6.1 团队角色与工程方法做了一段时间AI工程后我发现一个事实AI工程并不是“AI算法团队”专属的事。它更像是一个交叉领域需要混合角色。在最顺利的项目里至少要有三种能力懂业务的工程师负责把业务问题翻译成AI问题懂数据的工程师负责治理和评估数据质量懂模型的工程师负责模型选型、调优和推理优化。小团队里这三种能力往往要集中在一个人身上。那就要学会区分什么该自己深入、什么该借助工具。模型训练细节可以以后慢慢补但数据治理和评估体系是必须优先掌握的。因为这就是AI工程的“工程”部分。工程方法上我强烈推荐把传统软件工程的好习惯带进来代码评审、单元测试、CI/CD、Code Review。AI工程虽然有不确定性但业务流程的骨架是可以做确定性测试的。比如“输入意图识别”模块就可以写单测给一段话断言返回的意图是否正确。Prompt改动引发的问题往往就靠这些确定性测试兜底。6.2 我踩过的坑总结最后整理一下我在从零做AI工程这条路上踩过的坑希望能帮大家省点时间。第一个坑在项目初期花太多时间调模型效果而忽略了系统的错误处理。模型回答不理想至少用户还能看得懂服务超时、乱码、崩溃用户直接就流失了。正确顺序应该是先保证主流程稳定再优化效果。第二个坑不记录中间结果。Agent流程里模型每一步的输入输出如果没日志出了问题就是一片黑盒。现在我的习惯是核心环节把输入输出快照存进日志方便事后回放。第三个坑Prompt“一把梭”。一个Prompt从500字增到5000字能解决一些问题但很快会进入边际递减。把复杂任务拆成多个子Prompt配合代码逻辑来分步执行往往比超大Prompt更可控、更省钱。第四个坑忽略成本治理。大模型API是按token计费的尤其是加了多轮记忆后每次请求都在烧钱。我现在的规则是和核心任务无关的内容不塞进上下文历史对话只保留摘要能用缓存解决的绝不重复调模型。第五个坑过度设计。项目刚开始就上K8s、上消息队列、上多Agent框架结果一星期还没跑通第一个端到端流程。从零开始做AI工程最快的方式永远是“最简复刻”用脚本把主流程跑通再逐步加工程化能力。你不是在造火箭你是在解决一个具体的业务问题。根据我个人的体会AI工程最有魅力的部分恰恰是你把一堆摆脱不了“不确定性”的组件通过工程手段编织成一个相对稳定的产品。这个过程没有捷径但每一步踩坑、每个细节优化都会在线上运行的数据里看到回报。希望这篇从零开始的记录能给你带来一些有价值的参考。
