AI工程从零到上线：需求拆解、RAG落地与Agent编排实战

说个真实感受：跟“AI工程”打交道两年多，我从最初的“会写Prompt能跑通Demo”走到今天能稳定交付线上系统，最大的体会是，这个领域真正难的不是某个模型有多强，而是把你手上的大模型能力，拆成一个能接业务、能测试、能回滚、能监控的完整工程链路。这个项目叫“ai-engineering-from-scratch”，目标也很直白：从零开始，把AI应用从想法一步步做成可用的工程系统，而不是停留在调接口、跑通Demo的阶段。

这篇文章的风格偏实战，我尽量把踩过的坑和沉淀下来的套路都倒出来，内容包括面向业务的需求拆解、Prompt工程、RAG落地、Agent编排、模型选型、评测体系和线上运维。适合刚接触AI应用开发的开发者，也适合团队里准备从0到1搭AI项目的技术负责人。我不讲复杂的模型训练理论，只讲那些你画架构图、写代码、排障时真正用得上的东西。

1. 项目整体设计与思路拆解

1.1 “from scratch”到底指什么

先说清楚这个项目名的定位。很多人看到“AI engineering from scratch”，第一反应是要从神经网络反向传播开始学起。但说句实在话，绝大多数业务场景不需要你重新训练模型，你需要的是把一个已经很强的基础模型，接进你的业务流程里，让它稳定、可控、可评估地干活。

所以这里的“from scratch”我理解成三层含义：

第一，从业务问题出发。不是先选模型，而是先搞清楚业务到底要解决什么痛点，比如“客服响应慢”“文档检索效率低”“代码审查靠人肉”，这些才是项目的起点。

第二，从零搭建工程链路。包括数据接入、知识库构建、Prompt编写、Agent编排、评测体系、部署监控，这一整套东西在项目开始时几乎是空白的，需要你逐块搭建。

第三，从“能用”做到“好用”。很多项目死在“能跑”和“能用”之间——Demo跑通了，一上生产就各种幻觉、超时、成本失控。from scratch意味着你要把这些问题从设计阶段就考虑进去。

1.2 AI工程的完整闭环设计

我在实际项目里，把AI工程拆成六个环节，每个环节都有明确的输入输出和验收标准：

• 需求定义：把业务问题翻译成模型能力问题，定义“什么叫答得好”。
• 数据与知识库建设：收集、清洗、切分、向量化领域数据，这里决定系统的知识上限。
• 模型接入与服务化：选型、部署、封装API、做限流和降级，这是系统的底座。
• 应用能力组织：Prompt、RAG、Agent、工作流编排，把模型变成能完成任务的“员工”。
• 评测与调优：离线评测集 + 线上监控，用数据说话而不是靠感觉。
• 上线与运维：日志、追踪、告警、灰度、回滚，保证系统长期稳定。

这六个环节不是瀑布式的，而是一个循环。尤其“评测与调优”和“上线与运维”经常是同时进行的，我见过太多团队只埋头做前四个环节，结果上线第一天就被用户反馈“答非所问”折腾得焦头烂额。

1.3 技术栈全景与设计选择逻辑

我目前一个典型项目的技术栈长这样：

选择这套结构的原因很简单：每一层都是可替换的。比如向量数据库今天用Qdrant，明天想换Milvus，只需要改配置层；商业API不稳定时，可以切到本地开源模型，不影响上层业务逻辑。

这种“分层解耦”是AI工程和普通算法Demo最大的区别。Demo只关心“模型能不能答对”，工程还要关心“某个环节挂了系统怎么办”“换一个模型会不会影响整体效果”“怎么知道今天比昨天答得更好了”。这些问题的答案都来自架构设计时的取舍。

2. 核心细节解析与实操要点

2.1 Prompt工程：从“会写”到“工程化”

Prompt工程现在被讨论很多，但多数人停留在“怎么跟ChatGPT聊天”的层面。真正工程化的Prompt设计，至少要满足三个要求：稳定、可测、可维护。

先说稳定。生产环境的Prompt必须对同一输入反复产生一致输出，这就要求把角色、任务、约束、输出格式全部写清楚。举个例子，我做一个“合同风险审查”助手时，系统提示词是这样组织的：

角色：你是一名经验丰富的合同审查律师，擅长识别商业合同中与付款、违约责任、知识产权相关的风险条款。 任务：根据用户提供的合同文本，逐条列出风险点，给出风险等级（高/中/低）和修改建议。 约束： - 只分析用户提供的文本，不要引入外部知识； - 无法判断的风险标注“信息不足”，禁止编造； - 输出必须使用JSON格式，字段包括risk_level、risk_desc、suggestion。

这套Prompt上线后，输出结构几乎没出过错。关键是最后一条约束——用JSON格式约束输出，后续直接解析，不用跟大段自然语言纠缠。

再说可测。Prompt在生产里要像代码一样有版本号和测试用例。我每次改Prompt都会记一条changelog，同时准备一组“黄金测试集”，包含系统必须答对的典型问题和必须拒绝的敏感问题，改完Prompt先跑一遍回归，防止“修好A问题、搞坏B问题”的情况。

最后是可维护。不要把一段几百字的Prompt写死在代码里，我会单独建prompt目录，用模板语言管理，变量用占位符替换。这样运营同学可以直接调整语气，不需要动代码。

2.2 RAG落地：检索决定质量上限

RAG（检索增强生成）是目前让大模型“懂”私有知识最可靠的方案，因为它不需要训练，也不容易泄露数据。但这里有一个经常被忽视的事实：RAG系统的质量上限由检索决定，不在生成环节。模型答得再漂亮，你喂给它的检索结果是错的，它也无力回天。

文档处理是RAG最容易翻车的地方。最常见的坑是直接拿PDF按页码切块，结果语义被切得稀碎。我现在的做法是“父子分块”：先把文章按章节结构切成“父块”，每个父块再切成适合embedding的“子块”，向量检索命中子块后，把整个父块拼进上下文。这样既保证了检索精度，又给模型提供了完整上下文。

切分策略上，我按文档类型做了区分：

• 合同、政策文件：按条款编号切分，每一条是一个最小单元。
• 技术文档、文章：先按标题层级分段，再对过长段落做二次切分。
• 对话记录、FAQ：按“问-答”对整体保留，不切分。

embedding模型的选择也很关键。我的建议是先从bge-m3、text-embedding-3这类主流模型开始，用你的业务数据实测top-k召回率，再决定是否投入重排序（reranker）环节。重排序模型一般能把命中率提升5到10个百分点，是RAG链路里性价比很高的优化点。

此外，别迷信向量检索。混合检索（向量 + BM25关键词）在专业名词、编号、代码片段这类场景下效果更好，因为向量模型对生僻词和精确编号的匹配能力很弱。我项目里用的是“向量召回 + BM25召回 + 重排序融合”，实测比纯向量方案命中率提高不少。

2.3 Agent与工具调用：从单模型到多协作

当任务从“回答一个问题”变成“完成一系列动作”时，就需要Agent了。比如“查一下这周的销售数据、对比上季度、生成分析邮件发给团队”，这不是一次模型调用能完成的，而是要多次调用、操作工具、跨系统协作。

Agent的核心机制叫工具调用（Function Calling或Tool Use）。模型本身不会执行代码，它只负责根据用户意图，输出一个“要不要调用工具、调用哪个、传什么参数”的决策，再由你的程序去真正执行。这个设计的好处是可控——模型永远只做“决策”，“执行”由确定性代码完成。

在实际做Agent时，我把任务编排分成了两种模式。一种是线性流程，适合步骤明确的任务，比如“先检索知识库，再总结，再发邮件”，用工作流引擎把每一步固定下来，稳定性高。另一种是动态决策模式，适合开放任务，让Agent自己决定调用什么工具、调几次，灵活性高但调试成本也大。

这两种模式对应两种不同的工程策略。固定流程用DAG（有向无环图）编排，每个节点可以是一个Prompt调用或者一个工具，节点之间传参。动态决策则要用ReAct模式，让模型“思考-行动-观察”循环。我会优先推荐固定流程——在绝大多数业务场景里，稳定性比灵活性重要得多。只有确实无法预定义流程的时候，才让Agent自我规划。

多AI协作则是另一个阶段的事。当一个Agent搞不定复杂任务时，可以拆成多个角色化Agent，比如“研究员Agent负责收集资料”“分析师Agent负责解读”“写手Agent负责成稿”，由一个主控Agent调度。这就是所谓的“Harness Engineering”思路——重点不是单个智能体，而是为多个智能体设计“缰绳”：谁能调用谁、任务的交接格式是什么、失败重试策略怎么定、质量闸门在哪里。我实践下来发现，多Agent项目最关键的工程约束有两个：一是每个子Agent的工具边界要清晰，否则会出现两个Agent抢同一个工具的混乱；二是Agent之间的输出必须用结构化格式传递，不能传一段自然语言让人家自己猜。

2.4 上下文与记忆管理

聊上下文管理之前，先理解一个事实：大模型的上下文窗口虽然越来越大，但“无限制地塞上下文”既浪费钱又伤害效果——模型容易被无关信息干扰，对真正重要的信息反而关注不够。我一般把上下文分成三块来管理。

工作记忆：当前任务相关的信息，比如用户的当前问题、检索到的知识、上一轮对话的关键状态，这些必须完整保留。

短期记忆：同一个会话里几轮之前的内容，不需要全部保留原始文本，可以每轮结束后用模型生成一个“对话摘要”，把关键结论压缩进去。这个做法能显著降低Token消耗。

长期记忆：跨会话的用户偏好、历史事实，放在向量数据库里，需要时检索出来注入。比如客服系统要记住用户的会员等级、历史投诉记录，这些通过RAG通道接入。

还有一个经验之谈：上下文的组织顺序有讲究。系统提示词在最前面，然后是按用户需要优先排序的检索内容，最后是当前问题。模型对中间部分的注意力会衰减，重要信息尽量放开头和结尾。我用这个顺序做调整后，几个项目的准确率都有了明显提升。

3. 实操过程与核心环节实现

3.1 需求拆解与效果指标定义

AI项目的需求拆解，最忌讳直接说“我要一个智能客服”“我要一个AI助手”。这些口号没法落地。我习惯用“输入-动作-产出”的结构来定义需求：

• 输入：用户会输入什么形式的内容？文本、图片、语音？最长多长？有没有格式要求？
• 动作：系统需要对输入做什么？回答问题、执行操作、还是生成文档？
• 产出：输出的形式是什么？纯文本、结构化JSON、还是触发一个业务流程？
• 边界：哪些情况系统必须拒绝？哪些情况允许回答“不知道”？

同时定义效果指标。我常用的指标分四类：准确率/任务完成率（答得对不对）、拒绝率（不该答的是否挡住了）、成本和延迟（每百万Token价格、P95响应时间）、人工介入率（多少比例需要人工兜底）。

拿我做过的一个“内部知识问答系统”举例，业务方一开始说“员工问什么都能答”。我把它拆成：能覆盖HR政策、IT支持、报销流程三类问题；当问题不在知识库范围内时，必须引导到对应人工入口；响应时间控制在3秒内；单次回答成本控制在0.05元以内。有了这套指标，后面每次迭代都有的放矢。

3.2 数据准备与知识库建设

知识库建设是AI工程里最能体现“脏活累活”的地方。我踩过最大的坑，是初期贪多求全，把几百份从来不更新的制度文档一股脑塞进去，结果检索器经常召回过期政策，闹出了不少尴尬。后来我定了规则：知识库要有严格的生命周期管理，文档必须有责任人、更新日期和有效期，超过有效期自动下线。

数据清洗这一步不能省。常见问题包括：PDF文字提取出乱码、扫描件没有OCR层、表格转成文本后丢失结构、文档里有大量版权声明和页眉页脚噪音。我的做法是：先用解析器提取文本，再做规则清洗（去页眉页脚、统一换行、压缩空白），最后抽检20%的切分结果，看语义是否完整。

切分策略前面说了父子分块。embedding模型我推荐用bge-m3，中文效果稳定，支持稀疏检索和稠密检索联合使用。向量库方面，如果项目不大，直接用pgvector最省事，不用额外维护组件；数据量到百万级再上Milvus或Qdrant。

3.3 模型选型与部署双轨策略

模型选型我这里直接给一个对比框架，大家按自己的预算和数据敏感度套用：

我目前的主力架构是混合双轨：对外的产品走商业API，保证效果；对内的敏感数据处理走本地部署的开源模型，保证合规。关键设计是做一个统一的模型网关层，上层业务不感知具体用哪个模型，只设置“模型等级”（高效果版/高性价比版/本地敏感版）。

本地部署开源模型时，有几个实用参数可以优化推理性能。量化精度首选INT8或INT4，显存占用能降一半以上，效果损失完全可接受；vLLM的Continuous Batching要开，能把吞吐量提升数倍；KV Cache对长上下文场景很有用，但注意显存占用。我实测部署Qwen2.5-72B时，用INT4量化，单卡A100可以支撑每秒15到20个请求的并发，延迟稳定在2秒以内。效果相比FP16几乎无感。

3.4 从原型到生产：分阶段替换策略

我强烈建议不要一开始就追求完美的架构，而是遵循“最简原型 -> 业务验证 -> 组件升级 -> 灰度上线”的节奏。

第一版原型，我通常用最笨的方式实现：写死一个Prompt，把知识用关键词硬匹配，逻辑全部写在脚本里。这个阶段的目标只有一个——用最小成本验证业务价值。说实话，很多项目在第一版就被否了，那总比花三个月搭完系统才发现方向错了强。

业务验证通过后，再逐块替换。先把硬匹配替换成向量检索，再把单轮问答升级成多轮对话，然后逐步引入工具调用和Agent编排。每次替换只改一个环节，其他保持不变，出了问题能立刻定位。

系统稳定后，进入灰度环节。我会先开放给内部一个小组试用，同时保留完整对话日志。灰度期至少两周，重点看三个数据：人工纠错率（用户是否频繁说“不对”“重新回答”）、失败兜底率（系统是否被触发降级）、平均会话轮数（用户是否愿意持续使用）。这三个数据比单条用户反馈可靠得多。

3.5 评测体系与自动化回归

评测体系是AI工程里我最后悔没早点做的事情。早期项目全靠肉眼体验，结果就是“这周感觉好了点，下周又感觉坏了”，完全不可持续。后来我搭了一套三层评测体系：

第一层是离线评测。整理一批黄金问题集，覆盖典型问题、边界问题、拒绝场景，每个问题预标记标准答案。每次改动Prompt、换模型、调整检索参数，都跑一遍这组问题，用ROUGE、BERTScore加人工复核来评估。这套机制能挡住80%的回归问题。

第二层是自动评估。用“AI评委”（LLM-as-a-judge）来批量评测开放式回答，让一个更强的模型作为评审，按你定义的维度打分。这个方法的可靠性有很大争议，但我的实践结论是：设计好评审Prompt，让评委先看参考答案再看待评答案，并要求给出理由，它的评分和人工评分的相关性可以达到0.8以上，能用。

第三层是在线监控。记录线上数据，定期采样评估回答质量，同时追踪“用户调了几天没再用”这类行为指标。行为指标虽然不是直接的效果评估，但它能提示你是否需要人工介入检查。

4. 常见问题与排查技巧实录

4.1 幻觉问题：不能根除但可以控制

幻觉是生成式AI的固有属性，工程上能做的是通过三层防护把风险压到业务可接受的程度。第一层从Prompt约束入手，在系统提示词里明确“禁止编造、信息不足时明说”；第二层靠RAG给模型“兜底答案”，让它在检索结果范围内发挥，而不是自由发挥；第三层是输出侧校验，对高风险场景增加正则或规则校验，比如法律建议类系统要检查“依据”字段是否包含真实的条款编号，不满足就拒绝输出。

即使这样，我的经验是线上系统仍然需要人工兜底通道。这是工程良心，也是业务底线。理想状态下幻觉率可以从百分之十几压到1%到2%，但不要承诺零幻觉。

4.2 检索不到关键信息：优先查三个环节

“模型回答得不对”很多时候根源不是模型，而是没检索到正确资料。排查顺序是：先看切分——是不是关键内容被切碎了，导致embedding时语义不完整；再看向量化——是不是用了对领域不友好的通用embedding模型，专业术语匹配不上；最后看召回策略——是不是漏了BM25关键词召回，导致精确编号没被命中。

我遇到过最典型的一次案例，是用户问“去年第三季度的差旅报销上限是多少”，系统死活答不对。排查后发现，原文档用的是“秋季”而非“第三季度”，向量检索和关键词都没对上，解决方式是做了一轮同义词扩充，在检索前先把用户问题做一次改写。

4.3 上下文溢出与性能瓶颈

上下文过长会带来两个问题：一是Token成本爆炸，二是响应变慢。如果发现单次请求消耗Token在持续上升，优先做摘要压缩和消息裁剪。对历史对话做摘要，对检索内容做重排序后只取前几段，比简单粗暴地“截断最早的对话”效果好得多。

本地部署的推理性能瓶颈，一般出现在显存和batch策略上。如果并发一上来延迟就飙升，先检查是否开了Continuous Batching，再看KV Cache是否挤占了可用显存。实测vLLM不开Continuous Batching时，并发请求会导致排队，延迟翻倍；开启之后吞吐量明显提升。另外，长文档场景下建议总是启用FlashAttention，否则KV Cache计算会拖垮整体速度。

4.4 常见问题速查表

4.5 我自己一直在用的几条排障技巧

第一个技巧：把“输入输出日志”当成第一优先级来设计。AI系统的调试特别依赖完整链路日志，包括用户问题、检索到的文档、最终Prompt、模型输出、Token消耗、耗时。缺了任何一条，出问题就两眼一抹黑。我现在的做法是给每轮请求生成trace_id，贯穿全链路。

第二个技巧：做变更时“一次只改一个变量”。有时候为了优化效果，同时换了模型、改了Prompt、又调了检索参数，结果好了或坏了，根本不知道哪个因素起了作用。后来我严格执行单一变量原则，效果回归分析才清晰起来。

第三个技巧：建立“坏样本回收机制”。线上用户反馈差的问题，定期回收进评测集。这个动作让系统越用越稳定，因为评测集覆盖面越来越广，回归测试能挡住的问题也越来越多。

第四个技巧：控制temperature不是越低越好。对需要创造性的任务稍微调高一点，对事实性问答调低到0到0.2。默认值往往不是最优解。

结尾

把“AI工程”做成什么样才算合格，我自己有三个评判标准：底线可预期（不该出错的地方坚决不出错）、效果可量化（每次改动能用数据说好坏）、故障可排查（出了问题能快速定位哪一环）。这三点听起来朴素，但每一个都需要在需求、数据、模型、评测、监控各个层面下功夫。

最后分享一个我反复跟团队强调的体会：模型能力决定系统的上限，工程能力决定系统的下限。你选再强的模型，如果没有配套的评测、检索、护栏和监控，上线后照样被用户骂；反过来，把工程基础打扎实了，哪怕模型稍弱一步，系统整体表现依然可圈可点。这也是“from scratch”这个项目名真正想传递的东西——别急着追最新最强的模型，先把你自己的工程底座做扎实。