AI 工程从零开始一个老工程师的完整落地路径这几年我见了太多团队拿着大模型 API 却做不出能上线的产品不是因为模型不够强而是整个工程链路七零八落。提示词靠拍脑袋上下文管理靠拼接字符串评估靠肉眼观察上线之后效果漂移了也没有监控。这不叫 AI 工程这叫用 API 写脚本。我整理了自己从零搭建 AI 工程体系的完整路径从 Prompt Engineering 到 Agent 再到多 AI 协作每一步都附上踩坑记录和可直接抄作业的配置方案。这篇文章不聊大模型内部原理纯讲怎么把大模型能力变成稳定、可控、可评估的产品功能适合后端工程师、测试开发、以及所有想把 AI 能力真正落地的人。1. 整体架构思路别一上来就写代码1.1 先分清你做的到底是个什么 AI 应用AI 应用和传统软件最大的区别在于传统软件的输入输出是确定性映射AI 应用则引入了概率性。这意味着你的工程体系必须围绕不确定性来设计。我见过太多人拿到需求就直接调 API结果 prompt 写了三天调通了就以为完事了上生产第二天就被用户骂出幻觉。做 AI 工程动手前先想清楚你属于哪一类。我自己习惯把 AI 应用分成四层第一层是单轮问答也就是输入一段文本输出一段文本典型场景是内容改写、翻译、总结。这类应用最简单一个 prompt 加一个 API 调用就完事难点只在 prompt 质量和输出稳定性上。第二层是多轮对话需要维护会话上下文典型场景是客服机器人、聊天助手。这类应用必须设计上下文管理策略否则对话超过十轮就开始失忆。第三层是 Agent也就是让模型调用工具、执行动作典型场景是自动化测试、数据分析、代码生成。Agent 的核心难点不在模型本身而在工具调用链路的可靠性和错误恢复机制。第四层是多 AI 协作也就是多个不同角色的模型协同完成复杂任务。这层我一直认为是 AI 工程的终极形态我在后面的实操章节会专门拆解一个完整案例。1.2 技术选型的三条铁律选模型和服务商的时候我给自己定了三条铁律每条都是踩过坑之后总结的。第一条铁律是先算成本再选模型。大模型 API 计费看着差别不大实际用量上来之后差距惊人。我做过一个内容分析项目一开始用高精度大模型做全文总结一个月烧了四万。后来改成两段式方案先用平价模型做过滤和预处理只把一小部分难处理的请求交给高性能模型成本直接降了 80%效果几乎没有差别。所以选型前先估算你的调用量级和每轮请求的 token 消耗把冷热路径分开别一股脑全上最好的模型。第二条铁律是私有化部署不是必需品。很多人一上来就要部署开源模型担心数据安全。实际上如果你用的是公有云服务商只要做好数据脱敏和合规审查大多数场景都能用托管 API。私有化部署一个 70B 参数模型光 GPU 采购就是几十万起还有运维成本这笔账算下来绝大多数团队根本不合算。做了三年 AI 工程我手里真正需要私有化部署的场景只有两个一是数据出域有强合规要求二是单次调用量极大并且对延迟极其敏感。第三条铁律是把模型当可替换组件来设计。我见过最痛苦的事是代码里到处直接调用某个模型 API模型名写死在参数里。一旦要切换模型或者某个 API 升级了接口格式整个项目都跟着重构。正确做法是抽象出一层模型网关接口所有业务代码只依赖这个接口这样换模型只需要改网关层配置。2. 核心基础Prompt Engineering 与 Harness Engineering2.1 Prompt 提示词工程的关键参数拆解Prompt Engineering 现在都快变成显学了。我梳理一下真正工程化必用的七个参数每个参数在不同场景下该怎么配。temperature温度是控制随机性的核心参数。粗略理解温度越低输出越保守越稳定温度越高越有创造性。我的习惯是做事实性任务比如信息抽取、分类、格式化输出把温度调到 0这是为了让输出尽量可复现做创意生成比如文案、头脑风暴调到 0.7 到 0.9做代码生成调到 0.2 左右让代码尽量规整而不是有创意。很多人不知道温度调到 0 后模型仍有可能输出不同结果因为采样器还有其它随机因素但这个参数依然是降低输出波动最有效的手段。top_p核采样也叫 nucleus sampling控制模型只从累计概率达到该阈值的 token 集合中采样。实际工程中我经常只调 temperature把 top_p 固定在 0.9 附近。如果你的应用对输出多样性敏感可以试着同时调低 temperature 和 top_p但记住两个参数一起拉高会让输出变得非常随机生产环境要谨慎。max_tokens最大生成长度很多人把它当输出长度限制但更需要关注的是它会截断输出。如果模型在思考中途就被截断你得到的就是一段残缺内容。所以我习惯把它设成预估回答长度的一倍宁可浪费一点不要让回答被切断。另外代码生成场景 max_tokens 要调大一段完整函数的代码通常比你想象的长得多。frequency_penalty 和 presence_penalty这两个参数的作用是抑制重复表达。frequency_penalty 按频率惩罚presence_penalty 按是否出现过惩罚。我当时做技术文档生成时发现模型写长文会在同一个观点上反复绕圈子调降了重复内容之后就是把 presence_penalty 调到 0.2 左右效果好很多。日常场景我推荐这两个参数只在长文本生成时调整短对话维持默认。stop_sequences停止序列是控制生成边界的关键。比如你想让模型只输出 JSON就把}之后的换行符作为停止序列或者用更稳妥的方式让模型只输出一段 JSON 代码块解析时严格提取代码块内容。这个参数能让输出变得非常干净我强烈建议所有做结构化输出的项目都用上。系统提示词system prompt的长度与优先级我做过对比测试系统提示词越往后写的内容优先级越高。所以把最重要的指令放在系统提示词末尾模型遵从度会更高。这是个奇怪的规律但多轮测试验证下来确实如此。另外系统提示词要写成行为规范而不是任务描述。比如写你是资深测试工程师不如写输出格式必须为 Markdown 表格每行一个测试用例包含前置条件、执行步骤、预期结果三列。2.2 Harness Engineering 不是 Prompt 的替代品大家现在都在聊 Harness Engineering这个词直译是挽具工程意思是给模型套上一套缰绳让它按照你的规则来做事。和纯靠提示词引导不同Harness Engineering 强调的是控制模型输出结构和行为的所有外部机制本质上是一套工程框架。我理解 Harness Engineering 的核心就是三件事第一输出约束。用结构化输出协议比如 JSON Schema强制模型按特定格式返回而不是回到文本里请以 JSON 格式输出这种靠自觉的方式。第二行为编排。把复杂任务拆成流水线式的多个阶段每个阶段有独立的模型调用和校验逻辑。第三错误恢复。对模型的失败输出设定重试、回退、人工兜底机制。举个我自己实践过的案例我用 CodeBuddy 实现了一套叫测试用例生成流水线的 Harness 方案。整个流程分成四段第一段用低能力模型做需求理解和信息抽取输出规格化需求描述第二段用高能力模型生成测试用例但生成的不是自然语言而是按我定义的用例 Schema 输出结构化数据第三段用代码生成模型把结构化的用例转换成可执行的测试脚本第四段是执行引擎拿真实 API 跑一遍测试失败的用例自动回填到生成模型中重新生成。这套流程跑下来测试用例生成的有效率从最初的 45% 提到了 87%光靠调 prompt 根本做不到这个效果关键是在生成和校验之间形成了闭环。这种工程化的路子我把它理解为用系统能力弥补单次模型能力的不稳定性。每次模型输出都是概率性事件但多个校验关卡加进去之后整个系统的稳定性就被兜住了。这比单纯优化提示词更有工程价值。2.3 Harness 化三个步骤你也能自己搭第一步先定义输出协议。不管模型返回什么先规定好你的 JSON Schema。拿测试用例生成举例我不会让模型自由发挥写测试步骤而是定义成{ test_case_id: TC-001, title: 验证用户使用正确凭据可以登录系统, precondition: 用户未登录且无激活会话, steps: [ {action: open_page, target: /login, input: {}}, {action: fill_field, target: #username, input: {value: tester01}} ], expected: 用户跳转到 /dashboard 页面 }还真有人质疑我让模型输出 JSON 太死板了。但恰恰这种死板才是生产环境最需要的东西。模型自由发挥的结果就是解析器三天两头爆异常每次爆异常还得人工排查。用了 Schema 约束后生成结果可以直接进执行引擎根本不需要人肉翻译。第二步搭校验层。模型输出之后不要直接信任而是加一道结构化校验。把输出解析成 JSON 之后用 JSON Schema 校验器验一遍字段类型不对的、必填字段缺失的、枚举值不合法的全部打回重试。这一步能过滤掉大约 20% 到 30% 的错误输出。第三步建立重试与降级策略。模型第一次输出不合格不要无限重试设定两到三次的最大重试次数。重试仍失败就把这条数据标记为需要人工处理放进待办列表。生产环境里 95% 的请求走自动链路剩下 5% 的人工兜底比追求 100% 自动化要靠谱得多。3. 进阶核心从 AI Agent 到多 AI 协作3.1 AI Agent 的核心机制拆解Agent 系统近几年在各大 AI 应用里都快成标配了。我先说结论Agent 系统做得好不好关键不在那个大脑模型选得有多强而在于你给它设计的手脚够不够稳。Agent 的经典执行循环是感知Perception- 推理Reasoning- 行动Action- 观察Observation循环往复直到任务完成。听起来很简洁真正落地的时候有三件麻烦事。麻烦事一是工具调用不可靠。模型返回一个调用函数的 JSON但它经常把函数名写错或者参数结构给错。我的解法是给每个工具写严格的参数 Schema并且让模型先看 Schema 再调用。同时在网关层加一道工具参数校验不合法就自动修正或者报错返回给模型重新生成。麻烦事二是循环会卡死。Agent 在一个错误分支上反复重试浪费 token 还浪费时间。这个必须在系统层面强加最大迭代次数限制我通常设 10 次左右超了就终止任务并返回当前状态。麻烦事三是状态管理混乱。多步任务执行到一半Agent 需要记住前面做了哪些事。我最开始用把所有对话历史一股脑塞给模型的办法结果很快就把上下文窗口塞满了。后来我改用显式状态跟踪把任务的中间结果存成结构化变量关键节点的状态用变量引用而不是把所有历史记录重新推给模型。这个改造的效果非常明显复杂任务的成功率提升了将近两倍。3.2 实操案例用 Agent 做自动化测试开发我团队里最成熟的 Agent 应用是自动化测试开发助手。流程设计如下用户提交需求描述和接口文档Agent 先读取文档做分析再生成测试方案然后调用代码生成工具写测试脚本最后调用测试执行工具跑一遍。这中间 Agent 需要调用四个独立工具文档解析器、用例生成器、代码生成器、测试执行器。这个系统在测试开发这个岗位上替代了大量重复性工作。过去一个测试工程师写一套接口测试脚本耗时半天现在 Agent 大约十分钟生成初稿人只要审改一下即可。我在这里面建了一套非常严格的工具接口协议每个工具都有输入输出的 JSON SchemaAgent 调用失败时还会自动读报错信息修正调用参数。实测下来工具调用的成功率从 71% 提到 96%原因就是在每个工具调用点加了一个自纠错环节。3.3 多 AI 协作的两种主流架构多 AI 协作听起来很高大上实际上做工程就是两种架构选一种。一种是中心化调度架构。有一个主导 Agent 负责理解任务、拆解分配再调度多个子 Agent 分别执行。像我自己做的需求分析系统就这么设计的调度 Agent 接收需求文本把内容抽取任务分给子 Agent 一把测试用例生成任务分给子 Agent 二把代码生成任务分给子 Agent 三最后自己汇总校验结果。这种架构比较直观但缺点是所有流量都过中心节点调度 Agent 一旦出错整个链路就瘫了。另一种是去中心化协作架构。多个 Agent 各有职责通过消息队列或者共享黑板Blackboard机制交换信息没有中心节点。我做一个文档协作系统用的就是这种一个 Agent 负责写作一个 Agent 负责审校一个 Agent 负责排版各自独立运作通过共享文档状态协调。这种架构容错性高但协调成本也高需要设计好任务互斥和数据一致性的处理。我的经验是初学阶段先做中心化调度因为它最容易理解和调试。等你的多 Agent 系统到了需要高并发或者强容错的时候再演进到去中心化架构。3.4 多 AI 协作完整案例AI 短剧剧本生成流水线我前阵子帮做内容的朋友搭了一条 AI 短剧剧本生成的流水线用到了多 Agent 协作正好拿来说说完整方案。短剧剧本生成一共四步选题定位、大纲设计、逐场对白生成、修改润色。我建了四个 Agent 分别负责。选题 Agent 读取热点数据输出带有热度评分和高概念描述的选题卡。大纲 Agent 读取选题卡后按情节起承转合写出分集大纲每集大概 150 字。对白 Agent 读取大纲后逐集生成角色对白这是全流程中唯一调用高性能模型的环节。润色 Agent 检查所有对白修正逻辑不通的地方并统一角色语言风格。这套系统跑下来的效果是原来人工写一集短剧剧本大约需要两小时现在整条流水线跑完一集大约十几分钟而且内容的可读性相当不错。你可以想象一下如果是一家一个月上架上百集短剧的工作室这个效率提升意味着什么。最关键的点在于多 AI 并行工作不是把所有 Agent 同时调起来就完了而是要在 Agent 之间设计清晰的交接协议每个 Agent 的输入输出都是结构化数据下一个 Agent 不需要也不应该去看上一个 Agent 的全部思考过程只需要读取它需要的输入即可。这就像工厂流水线每个工位只对接上一工位交给你的零件。4. 工程化落地全流程从需求到上线4.1 数据准备与上下文工程AI 应用要做得好喂给模型的上下文质量比模型本身的能力更关键。我们团队做过一个文档问答系统一开始怎么调 prompt 答案质量都一般。后来我做了一件事把所有上下文中和问题无关的内容全部过滤掉只留与问题最相关的段落正确率直接上了一个台阶。上下文工程的核心是 RAG。整个流程先对源文档做切片chunking再做向量化存进向量数据库查询时先做语义搜索找最相关的片段再拼进 prompt 送给模型。这里有两个坑必须讲。第一个坑是切片策略。切片切得太小语义完整性不够切得太大向量匹配的精确度下降还可能超出模型上下文限制。我的实践标准是一般技术文档按段落切每个切块控制在 200 到 500 字之间保留段落标题。第二个坑是元数据。如果每个切块都带上来源文件名、章节路径、更新时间追踪结果时可以回溯到原始出处这个能力在产品上线后排查问题是一个刚需功能。4.2 模型网关与统一接入层我强烈建议所有 AI 工程都搞一个模型网关。网关的作用不单纯是转发请求还能做三件事第一统一接口格式业务层不感知后端用的什么模型第二做限流和降级某个模型服务不稳定时自动切换备选第三记录所有请求日志为后续的评估和监控提供数据基础。网关层的配置我一般这样写# 模型网关配置示例 MODEL_ROUTES { default: { provider: openai_compatible, model: gpt-4o-mini, temperature: 0.2, max_retries: 2 }, high_quality: { provider: openai_compatible, model: gpt-4o, temperature: 0.1, max_retries: 3, fallback: default }, code: { provider: anthropic, model: claude-3-5-sonnet, temperature: 0.0, max_retries: 2 } }看这个配置不同任务走不同的模型路由某个路由失败了可以降级到另一个。这个设计最大的优点就是你有一天想把某条路线切换成国产模型或者开源部署模型只需要改配置业务代码一行都不用动。4.3 评估体系与测试方法AI 工程和传统软件工程最大的差别在于你不能用断言来测模型输出。传统测试用例能精确判断结果对不对模型生成的内容只能用质量评分衡量。所以 AI 工程的测试体系要设计成多层并行的结构。第一层是格式校验。检查输出是不是合法 JSON、是否满足 Schema、必填字段是否都有。这层用程序可以自动完成也是拦截野输出最有效的一道关卡。第二层是规则校验。针对业务自定义规则比如不能包含禁忌词、结果必须包含指定字段、长度必须在指定区间。这类规则也可以用程序写。第三层是语义校验。这就需要第二个模型来打分或者做对比。评审一个模型输出质量好不好最常用的方案是拿一个更强的模型当裁判要求它对输出按多个维度打分比如相关性、完整度、忠实度。当然裁判模型也会有偏差所以最好是多种校验手段混用而不是全部押在模型裁判上。第四层是回归测试集。这一层是最重要的。我维护了一套大约两百条测试样本的标准数据集每次换模型、改 prompt 之后都必须跑一遍回归集对比整体通过率和平均质量分。没有这套机制你永远不知道一次 prompt 修改是不是顾此失彼、按下葫芦浮起瓢。4.4 上线投产效果监控与持续调优AI 应用上线后不能当甩手掌柜。传统应用上线后看错误率和延迟AI 应用要额外盯三样东西。第一是 token 消耗成本监控。AI 应用成本是随用量线性增长的如果某个接口调用量暴涨而业务量没涨多半是有人在刷接口或者某个环节出了问题。我习惯按天统计每个功能的 token 开销和前一天做对比异常偏离就拉告警。第二是输出质量抽样监控。每天从线上请求中随机抽一部分让人工或者裁判模型评估输出质量跟踪平均质量分的趋势变化。我当时做客服助手的时候上线两周后发现某个话术类型的质量分持续走低排查下来是上下文长度增长导致关键信息被挤出了窗口后来通过调整摘要策略解决了。没有质量监控这个动作这类问题根本不可能及时发现。第三是用户反馈回收。AI 应用尤其需要做点赞/点踩按钮用户一句话的回答错误比你跑一百次自动评估都有价值。我建议把所有负面反馈的请求日志单独存一个池子定期用它们刷新回归测试集这样做模型调优的时候才不会偏离用户真实关注的方向。5. 常见问题与排查避坑实录5.1 高频问题速查表我整理了一张快速排查表几乎覆盖了我做 AI 工程时遇到的大部分常规问题。症状排查方向解决方案输出频繁不符合格式检查是否用了结构化输出协议上 JSON Schema 校验 重试机制回答与问题不相关检查上下文检索环节是否召回错误相关文件优化 RAG 切片和检索策略对话超过几轮开始失忆上下文管理策略有缺陷引入摘要和关键信息记忆模块复杂任务执行一半进程就崩了缺少状态持久化设计显式状态跟踪关键节点落库切换模型后效果明显下降新模型对细节遵守度不同重新跑一版 Prompt 工程调优成本快速增长无法控制缺少用量监控与路由分流建冷热路径低价模型处理简单请求Agent 反复调用同一工具不肯结束缺少最大迭代限制强加 iterations 上限和退出机制输出偶尔出现幻觉且影响业务缺少事实校验层引入检索校验 人工兜底审批5.2 三个最值钱的避坑经验第一个经验结构化输出的可靠性远高于自然语言约束。让模型请严格按照 JSON 格式输出的结果就是模型给你一段 JSON 包在 Markdown 代码块后面或者某个字符串值里带了一堆注释解析器直接炸开。正确做法是使用强制 JSON 输出模式同时你的解析逻辑要能容忍 Markdown 代码块包裹的 JSON。第二个经验Prompt 越短往往效果越好。系统提示词不是论文不要想着把所有规则写进去。你把规则写得越长模型就越容易在细枝末节上犯浑。核心指令不超过五条每条讲清楚要什么和不要什么比长篇大论更能提效果。第三个经验上下文窗口不是越大越好。很多人以为模型上下文长了把所有历史一股脑塞进去就行。实际效果恰恰相反历史信息太多很容易把关键指令淹没。我的做法是只需要最近三到五轮的完整对话更早期的内容压缩成摘要每轮对话都标记时间戳和角色。这个做法让长对话场景的准确率比全部塞入高了不少同时 token 消耗也降下来了。5.3 技术债务案例复盘最后分享一个真实翻车案例。当时做一个知识库问答系统上线之前所有基于回归测试集的指标都表现很好结果上线两周后用户投诉准确率骤降。排查流程是这样的先看服务日志没发现报错再看模型调用记录发现一样的问题请求用户输入的问法在搜索引擎里带了新词然后检查了上下文管理逻辑发现用户历史对话越来越长系统在第十五轮左右开始因为 token 超限丢失关键信息模型拿不到准确的背景只能靠猜。最终解决方案是加了一个全局状态记忆模块把用户的核心属性会员等级、业务类型、历史偏好向量化存储不再依赖对话历史的全文拼接。改完之后准确率恢复并且还稳中有升。这件事给我的启发是AI 系统上线后的性能下降不一定是模型本身出问题多半是你自己的上下文管理、路由策略、检索质量这些周边设施出了状况。所以监控体系里永远不要只盯着模型输出那一环上下文管理、工具调用、数据流转这些基础设施更值得你花精力去监测。我在实际开发中最深的体会是AI 工程走到最后大家比的已经不是谁的模型更聪明而是谁的工程体系更扎实。Prompt 写得好只能让你在 demo 里赢要真正扛住线上流量和用户挑剔的检验还是得靠完整的评估、监控和容错体系。你不需要懂得怎么从零训练一个模型但你必须懂得怎么把大模型这个能力原子接入到你的产品血脉里让它稳定地发光发热。这才是 AI 工程师真正的价值所在。