AI应用工程化实战：从模型选型到上线监控的完整链路-平芜编程栈

1. 为什么90%的AI项目都死在Demo到产品这条路上

在AI这行干久了你会发现一个很残酷的现实：Demo谁都能做，产品不是谁都能做。我见过太多团队拿着一个跑通的对话Demo，把PPT包装得天花乱墜，结果一上生产环境就被用户真实的输入打回原形。模型的回答时好时坏、上下文一长就乱、同一个问题换个说法答案完全不一样——这些在演示时都不会暴露，因为Demo里全是精心挑选的完美样本。

我说的"ai engineering from scratch"，指的不是从零写一个深度学习框架，而是从零搭建一整套AI应用的工程化体系。从第一版提示词开始，到模型选型、数据流设计、Agent编排、自动化测试、线上监控——把AI能力真正变成一个可信、可控、可维护的业务系统。这个过程中最大的挑战不是"让模型回答问题"，而是"让模型稳定地回答对问题"。

那工程化到底要解决什么？我总结下来就四件事：

确定性：让模型在合理范围内稳定输出，而不是每次推理都像抽奖。
可观测性：模型为什么这么回答？中间发生了什么？出问题时能追溯。
可迭代性：换模型、改提示词、调参数之后，怎么知道变好了还是变坏了。
兜底能力：模型出错时，系统要有降级方案和安全边界，而不是裸奔。

如果你正准备从零开始做AI应用，或者已经做完Demo但不知道怎么往产品方向推进，这篇文章会把这四件事全部拆开讲清楚。我不讲那种"加载LangChain跑一下Hello World"的新手教程，我讲的是我踩过坑之后沉淀下来的那套完整链路。

2. 从需求到架构：AI工程的第一张设计图应该怎么画

2.1 模型选型的前提是"够用就好"，不是"越强越好"

很多人做AI工程的第一步就是选模型，这是个陷阱。真正正确的顺序是先想清楚任务边界，再倒推需要什么能力的模型。

举个例子，我做过一个企业内部知识库问答机器人。最初团队直接上了当时最强的通用大模型，理由是"大模型能力强，什么都能答"。结果上线两周就出问题了：一是单次调用成本高得离谱，二是知识库问答这种任务根本不需要模型具备写诗和写代码的能力，三是大模型的"泛知识"反而会干扰它对内部文档的判断，一本正经地编造出不存在的公司制度。

后来我们把任务拆成三类：文档检索（用向量数据库召回）、结构化抽取（从文档里提取关键信息）、自然语言生成（把答案组织成流畅的表述）。前两类完全可以用传统NLP工具加小模型搞定，只有第三类才需要调用大模型。这么一拆，大模型的调用量下降了70%，成本和延迟都降下来了，回答准确率反而提高了。

模型选型时我建议你关注三个维度：

维度	思考方式
能力边界	任务需要什么能力？普通对话、复杂推理还是专业领域知识？
成本预算	每日调用量乘以单次Token消耗，再乘模型单价，算完你就不纠结了
延迟要求	用户能接受几秒出结果？这决定了模型参数量级和是否要用流式输出

做这个决策有个很实用的办法：先做人工标注。把50条真实业务问题整理出来，人工写出标准答案，再拿不同模型去跑，人工打分对比。别迷信榜单分数，榜单跑的是通用任务，你的业务问题才有发言权。

2.2 数据流设计：你的AI系统每天在"吃"什么

模型选完，紧接着就是数据流。AI工程的数据流和传统软件不一样，它的核心是上下文管理：每一次模型调用，你要喂给模型什么信息？这些信息从哪来？怎么拼装？

还是说知识库问答这个例子。用户问"今年年假政策有没有变化"，系统需要做三件事：

从向量数据库检索出与"年假政策"最相关的3-5段文档切片；
把用户问题、检索回来的文档切片、历史对话摘要拼装成系统提示词；
设置温度参数（我一般用0.1到0.3），确保回答严谨、不发挥。

这段链路听起来简单，实际工程里最容易被忽略的是上下文窗口的管理。大模型的上下文窗口是有限的，你不能把所有历史对话一股脑全塞进去。我的做法是维护一个三级缓存：

短期记忆：最近5轮对话的原始内容，直接放进上下文；
中期摘要：每10轮对话结束后，让模型把要点压缩成摘要，放进系统提示词；
长期记忆：用户画像、偏好等结构化工数据，按需检索注入。

这么设计的目的是在有限的上下文窗口里，把最高价值的信息递给模型。很多项目上线后出现"聊到第20句就胡言乱语"的问题，基本就是上下文管里堆了太多垃圾信息，把真正关键的指令给稀释了。

2.3 状态与可控性：AI应用最容易忽视的地基

传统工程里，状态管理是好学生的必修课；但到了AI工程里，很多人反而把状态给扔了——他们觉得"模型自己能理解一切"。这是大忌。

AI应用本质上是一个有状态的计算系统。用户说"再解释一下第二点"，模型需要知道"第二点"指的是你上一轮回答里的第二个要点。如果每一轮调用都是无状态地独立发起，这类指代问题模型就会瞎猜。所以工程上必须显式维护对话状态，把用户意图、当前话题、待确认信息等结构化地存储下来，在组装上下文时动态注入。

这一点在Agent类应用里尤其致命。我后面会细说Agent编排，这里先记住一个结论：不要让模型去"记忆"状态，要用代码去"管理"状态。模型负责理解和生成，工程代码负责状态流转和持久化。这个分工一旦模糊，你的AI系统就会变成一个不可预测的黑盒。

3. 提示词工程：从复制粘贴到可版本管理的工程资产

3.1 提示词的模块化拆分

提示词工程是AI工程里最容易被低估的一环。很多人觉得提示词就是"写一段话让模型干活"，复制粘贴就完事了。但实际上，只要提示词进入产品代码，它就成了需要被版本管理、测试、迭代的软件资产。

我自己的做法是把一个复杂的系统提示词拆成五个模块，分别维护：

角色定义（Role）：模型以什么身份回答问题。比如"你是一名资深的HR政策客服，回答必须基于提供的企业内部文档，不得使用文档之外的信息。"

任务描述（Task）：模型这一轮具体做什么。比如"根据以下检索到的文档片段，回答用户关于年假政策的问题。如果文档中没有相关信息，明确告诉用户'资料库中暂未找到相关内容'。"

输入数据（Data）：动态注入的文档片段、用户历史、查询结果等。这个部分不写死，用占位符在运行时填充。

输出约束（Format）：规定输出格式和风格。比如"回答需分点列出，每条控制在50字以内；严禁编造文档中不存在的内容；使用简体中文。"

兜底指令（Fallback）：当模型遇到不确定情况时的处理策略。比如"如果你无法从文档中确定答案，直接说'不确定'，不要尝试猜测。"

这套拆分有两个好处。第一，日常迭代时不用重写整段提示词，只改对应模块就行；第二，每一个模块都可以单独做测试，出了问题能精准定位是角色设定不够明确，还是输入数据有问题。我见过太多人改提示词靠"整体重写一次然后看运气"，改完发现A问题解决了B问题又冒出来了，就是这个原因。

3.2 Prompt版本管理与A/B实验

模块化拆完之后，提示词的版本管理就顺理成章了。我强烈建议你给每一版提示词打上版本号，记录改动内容和变更原因，就像管理代码一样管理Prompt。

在我的项目里，每条生产环境的提示词都对应一个JSON配置文件，大致长这样：

{ "prompt_id": "hr_policy_answer_v3.2", "modules": { "role": "你是一名资深的HR政策客服...", "task": "根据以下检索到的文档片段...", "data": "{{retrieved_docs}}\n用户问题：{{user_query}}", "format": "回答需分点列出，每条控制在50字以内...", "fallback": "如果你无法确定答案，直接回答'不确定'..." }, "model": "gpt-4o-mini", "temperature": 0.2, "updated_at": "2025-06-18T10:30:00Z", "change_log": "v3.2：将兜底指令从'可以说不知道'改为'直接说不确定'，减少模型过度解释" }

配好之后，每次提示词变更都走一次A/B实验：把线上流量切一部分到新Prompt版本上，对比新旧版本的程序化指标和人工抽评分数，再决定是否全量上。这套机制看起来很重，但它能让你的AI系统在持续迭代中保持稳定，不会出现"今天改了提示词，明天线上效果崩了"的尴尬。

3.3 结构化输出：让模型遵守你的数据契约

提示词工程里另一个高频翻车点就是输出格式不稳定。你让模型返回JSON，它偶尔给你夹一句"好的，以下是您需要的JSON格式答案："，把下游解析直接搞崩。

解决这个问题的工程手段叫结构化输出约束，也就是在调用API时告诉模型"必须返回符合某个JSON Schema的数据"。现在主流大模型的API基本都支持这个能力，你只需要定义好Schema：

{ "type": "object", "properties": { "answer": { "type": "string", "description": "对用户问题的直接回答" }, "confidence": { "type": "number", "description": "置信度，0到1之间" }, "need_human_handoff": { "type": "boolean", "description": "是否需要转人工" } }, "required": ["answer", "confidence", "need_human_handoff"] }

配合这个Schema，每次模型输出都是规规矩矩的JSON，下游代码不用再做容错处理。这一步很值得做：它把"模型输出"这个不确定事件，变成了"可解析的数据"，是AI工程确定性的关键一环。

另外提醒一个细节：结构化输出不等于模型"理解"了你的业务约束。它只是格式上合规了，内容上可能还是错的。所以Schema解决的是"解析崩溃"问题，"内容正确性"问题要靠评估体系去保障——这就是我后面要讲的重头戏。

4. Agent编排：让模型学会调用工具，而不是背诵答案

4.1 Agent的核心是工具与循环

当你的AI应用不只是"回答问题"而是要"完成任务"，比如帮用户查天气、订会议、提交工单，那你就需要Agent了。Agent的本质是让模型具备使用外部工具的能力。

做一个Agent，工程上要做两件事：定义工具集、编排推理循环。

工具集就是一组可被模型调用的函数，通过JSON描述它们的名称、参数和返回值。模型在对话过程中如果判断需要某个工具来完成用户需求，就会输出一个工具调用请求，由你的代码去实际执行，再把执行结果回传给模型，让它继续推理。这个"模型思考 — 调用工具 — 拿到结果 — 继续思考"的过程，就是循环。

以我做的工单Agent为例，我给模型挂了三个工具：

[ { "name": "search_articles", "description": "在知识库中搜索与用户问题相关的文档", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词" }, "top_k": { "type": "integer", "description": "返回的文档数量" } }, "required": ["query"] } }, { "name": "create_ticket", "description": "为用户创建工单", "parameters": { "type": "object", "properties": { "title": { "type": "string" }, "description": { "type": "string" } }, "required": ["title", "description"] } } ]

工具描述的质量直接决定了模型能不能正确调用。我调试过很多次发现，工具描述里最关键的不是"做什么"，而是"什么情况下该用、什么情况下不该用"。否则模型会乱调工具，把应该直接回答的问题也去触发工单创建。

4.2 循环控制与失败兜底：Agent安全的第一道防线

Agent的推理循环给了模型极大的自由度，也让系统面临失控风险。你见过Agent触发工具调用后进入死循环吗？我见过。一个工具执行结果没达到模型预期，于是它反复调用，把API配额刷爆了。

这就是行业里常说的"循环工程"问题——Agent循环不是让模型无限转圈，工程上必须对循环过程做硬性约束。我的做法是两个参数：最大循环次数和单次工具调用超时时间。循环次数一般设3到5次，超过就强制让模型基于已有信息做最终回答；工具调用超时设定为10到20秒，超时后直接抛出可读的错误提示。

另一个关键点是失败兜底。工具调用可能失败、可能返回异常数据、可能超时，你的Agent系统要把这些失败场景当成正常业务路径来设计：

工具调用失败：把错误信息回传给模型，让模型决定重试还是换一种方式；
模型连续两次循环没有进展：中断循环，输出"我暂时无法完成这个任务，已为你转接人工"；
用户输入涉及敏感操作（如删除数据、大额转账）：Agent拦截并转人工确认。

这些兜底逻辑不该写在提示词里让模型"自觉遵守"，而应该用代码在Agent执行层面硬性拦截。模型是概率系统，让它承担安全职责显然不靠谱。

4.3 从单Agent到多Agent协作：分工与上下文隔离

做完单Agent，你很快会遇到单Agent的能力瓶颈：一个Agent既要负责理解用户意图，又要负责检索知识，还要负责生成最终答案，即使模型能力再强，任务变复杂之后也会出现"顾此失彼"的局面。于是多Agent协作就登场了——让多个专精的Agent各管一摊，配合完成复杂任务。

我在实际项目里用一个"主控Agent + 多个专家Agent"的架构：

主控Agent负责理解用户整体意图，将任务拆解，路由给对应的专家Agent；
检索Agent只负责查文档、返回检索结果；
工单Agent只负责创建和更新工单；
质检Agent负责审核最终回复是否有事实错误。

多个Agent之间如何协作？这比单Agent复杂得多。我的经验是：不要让Agent之间直接对话，而是通过共享的"工作记忆"来协作。主控Agent把任务上下文写入一个结构化的共享缓冲区，专家Agent只读取与自己相关的部分，产出结果后写回。这么做的好处是上下文隔离——每个Agent只看到自己需要的信息，既节省Token，又不会因为无关上下文干扰专家Agent的判断。

这里还有一个容易踩的坑：多Agent的调用成本是成倍增加的。我做过多Agent架构后，单次完整对话的成本从约0.02美元涨到了0.08美元，翻了4倍。所以设计时要考虑清楚，是不是所有任务都需要全流程的多Agent协作。我后来加了一条分流规则：简单问答直接走单Agent快速通道，只有需要工具调用或多步骤推理的复杂任务才走多Agent协作链路。这么一改，成本又降回了一半。

5. 多AI协作的调度问题：让"模型团队"高效运转

5.1 什么样的任务才需要多AI协作

多AI协作不是把一堆模型往系统里一扔就完事。它要解决的真正问题是异构模型的调度——不同任务交给不同能力的模型，再把各自的结果合并加工。

举例来说，我的知识库问答系统同时使用了三个模型：一个小参数模型负责意图识别和任务分类，一个中等参数模型负责常规的文档问答，一个强推理模型只在用户问复杂对比分析时才会被调用。三者按任务难度分流，形成一条"推理成本梯度"。

这种设计背后的逻辑很简单：用户问"公司年假有几天"和小模型就能答好，没必要动用强推理模型；但用户问"如果把入职时间从9月改到7月，年假额度怎么变化"这类需要多步计算的问题，小模型就容易出错，这时候才值得花更高成本调用强模型。

实际做的时候，任务分类的准确率至关重要。分发错了，要么多花钱，要么答错题。我建议在分流层做一次轻量级校验——用第二个模型（或规则引擎）对路由结果做个快速确认，发现拿不准的任务就默认走强模型通道，宁可多花成本也不能答错。

5.2 协作的三种模式：路由、编排与协商

我梳理下来，多AI协作的常用模式大概有三种：

模式一：路由分发。根据输入内容把任务分给最合适的单一模型处理。这是最轻量的模式，适合"不同任务类型有不同最佳模型"的场景。

模式二：流水线编排。任务按固定顺序经过多个模型，前一个模型的输出是后一个模型的输入。典型场景是先做意图识别，再做检索，最后生成回答。这种模式链路稳定，适合处理流程相对固定的业务。

模式三：协商合并。多个模型对同一问题各自产出结果，再由一个汇总模型或投票机制选择最优答案。成本最高，但确实能提升回答质量。一般只在高价值场景使用，比如医疗咨询、法律建议这类容错率极低的输出。

实际工程中，三种模式经常混用。我的建议是：先按业务逻辑画出任务流程图，再为每个节点选择模型。这条规则听起来简单但极有用——因为一旦动辄"让所有模型大乱炖"，你连问题出在哪都定位不到。

6. 测试、评估与监控：AI工程的生死线

6.1 给LLM写自动化测试：不是只测"能跑通"

AI工程的测试和传统软件的测试有本质区别。传统软件测试断言"函数返回了预期值"，AI测试断言"答案在可接受范围内"——这个"可接受范围"需要人先定义清楚。

我给AI应用搭建测试体系时，先做了三件事：

第一，建回归测试集。从真实业务中挑选200条代表性输入（覆盖常见问题、边界情况、历史踩坑问题），手工标注理想回答。每条数据都记录"为什么选这条""理想结果是什么"，未来提示词或模型的任何变更，都要先过这200条回归测试。

第二，定义评估指标。纯人工评估一天看不了几个样本，必须有程序化指标辅助。以下是我常用的几个指标：

指标	计算方式	适用场景
回答相关性	用另一个模型，或余弦相似度计算回答与标准答案的接近程度	快速筛选明显不合格的回复
事实一致性	用另一个模型检查回答是否与提供的文档内容矛盾	防幻觉、防编造
格式合规率	生成的JSON能否被解析，字段是否齐全	保障下游链路稳定性
端到端成功率	整个Agent流程中，用户目标是否在N步内达成	Agent类应用最核心的指标

第三，把评估变成CI/CD的一环。我搭过一套这样的流程：每次修改Prompt或更换模型，自动跑一遍互联网问答测试集，生成对比报告。那些"感觉新Prompt更好"的模糊判断，在这个报告面前瞬间真相大白。很多次我直觉以为新版效果不错，结果一看回归报告，老版本在几十个边界案例上处理得更好，果断回滚。

6.2 LLM-as-a-Judge：用一个模型给另一个模型打分

"LLM-as-a-Judge"是我强烈推荐每个AI工程团队上手的一个方法。它指的是用一个模型充当评审员，对被测模型的回答进行质量评分。听起来有点套娃，但实测下来效果很可靠，特别是用于做大面积的初筛。

实践中要注意几个细节：

评审模型与被评模型最好不同厂商，避免"自卖自夸"的偏差；
给评审模型明确的评分标准（考卷rubric），比如分4个维度各1-5分，总分取加权平均；
每批评审结果抽样20%做人工复核，防止评审模型自身的偏好带偏整体评估。

我的经验是，LLM-as-a-Judge能帮你把"全量人工评测"的工作量压缩到原来的20%，剩下那20%人工方式重点盯——这就够了。

6.3 上线后的监控：模型也会"漂移"

你的AI应用上线后，千万别觉得万事大吉。模型推理会随着时间有性能漂移：业务数据变化、用户输入分布变化、模型服务端更新，任一环节出问题，线上效果就会悄悄退化。

我搭建的监控体系分三层：

请求日志层：记录每一次调用的输入、输出、耗时、费用和模型版本，作为后续分析的原始素材；
质量指标层：每天跑一批评估任务，计算事实一致性、格式合规率等指标，检测质量滑坡的早期信号；
业务结果层：跟踪最终业务指标——比如用户是否真的解答了问题、工单创建成功率等。这一层才是老板真正关心的。

监控的黄金法则是"把异常报警接到IM上"。现在我的团队每天都能收到一份质量日报，指标正常就静默，一有滑坡立刻报警并附上趋势曲线。这比出了问题靠用户投诉反馈要主动得多。

关于质量监控还有一个容易忽略的点：成本监控。大模型的API计费是按Token走的，你的Agent如果循环失控或者多Agent协作频繁触发强模型调用，成本可能直接翻几倍。我一直用实时费用面板跟踪每次请求的消耗，设置日费用阈值，超了自动切换降级模型。很多人把成本问题留到月底账单出来才意识到，那个时侯就晚了。