1. 项目概述为什么要从零搭建一套 AI 工程能力我见过太多人接触 AI 工程时是从“调别人的 API 写个小 demo”开始的。demo 跑通的那一瞬间确实很有成就感但真正进入生产环境、数据量上来、业务逻辑复杂起来之后你大概率会撞上一堵墙提示词写的再好模型输出也经常不可控RAG 检索看起来一本正经回答却经常张冠李戴Agent 跑起来时不时发疯还会把不该调的工具给调了。问题出在哪出在你只是在“用 AI”而不是在“做 AI 工程”。这就是我决定把这么长时间的实践整理成一个ai-engineering-from-scratch项目的原因——不说虚的直接把你从“能跑通 demo”带到“能交付一个可靠的 AI 应用”这个层级。标题里的from scratch不是让你从神经网络的反向传播开始写而是让你把 AI 工程的全链路扎扎实实搭起来包括 LLM 应用的调用与编排、检索增强生成RAG底座、Agent 工具调用机制、测试评估体系、可观测性与成本控制。这套东西不是某一门课程能讲完的但通过一个系统化的个人项目串起来完全可以成为你进入 AI 工程领域最扎实的切入点。这个项目适合几种人一是后端开发想转 AI 应用方向二是算法工程师想把模型落地成服务三是产品经理或技术负责人想理解 AI 工程到底包含哪些环节四是对 AI 测试与质量保障感兴趣的质量工程师。无论哪个角色你都能从这里拿到一套可以直接复用的工程骨架、一批踩坑记录以及一份关于“为什么这么做”的深度拆解。2. 整体设计AI 工程不是模型调用而是一条完整链路2.1 从“写 Prompt”到“设计复杂系统”的思维转变很多人把 AI 工程等同于 Prompt Engineering这是最大的误区。Prompt Engineering 确实重要但它只是 AI 工程里最浅的一层。真实场景里你要面对的是数据怎么切分、向量库怎么选、检索阈值怎么定、上下文窗口怎么管理、Token 费用怎么控制、响应延迟怎么优化、模型输出怎么校验这些全部加在一起才叫 AI 工程。打个比方Prompt Engineering 是教一个刚入职的员工“怎么把话说清楚”AI 工程则是把整个公司的业务流程、审批机制、质检标准、容灾预案全设计好。前者靠话术后者靠系统。你在网上看到很多“逆天 Prompt”模板复制过来放在自己业务里却效果平平原因不是你抄错了而是你缺了整套系统的支撑——没有好的召回结果Prompt 写上天模型也只能看着一堆无关文本硬编。所以这个项目的第一个设计原则是一切从“端到端”出发。每一个模块的存在都得能回答“这个组件在整个系统里承担什么职责、如果它挂了会怎样、有没有 Plan B”。在这个原则下哪怕最开始只有一个模型 API 和一个向量库系统的每个接口、每个数据结构也都可以向生产环境靠拢而不是做个玩具。2.2 核心链路拆解LLM 调用、知识注入、工具调用与质量保障我在设计这个项目时把 AI 工程的核心链路拆成了六个模块每个模块解决一类问题模块解决什么问题典型技术方案模型接入层统一模型 API、支持多模型切换与降级LiteLLM、OpenAI SDK、Ollama知识注入层让模型回答事实性问题不靠“背”文档加载、分块、Embedding、向量检索上下文管理层控制送入模型的 Token 与信息密度Prompt 组装、压缩、路由与过滤智能体执行层把“回答问题”升级为“完成任务”工具注册、函数调用、Agent 循环评估与测试层回答得好不好、链路稳不稳、回归隐患离线评测集、在线日志分析、质量门禁可观测与成本层生产环境出了问题能发现、能止血日志追踪、Token 统计、调用链监控这六个模块不是线性的而是互相咬合。比如知识注入层的分块粒度直接影响上下文管理层能塞多少参考内容评估测试层做的得多细又决定了你敢不敢把 Agent 放到生产环境里。因此这个项目虽然叫from scratch但我没有按“先做完第一步再做第二步”的死顺序推进而是搭一个最小闭环然后逐层加厚。这么做的好处很明显每一步你都能在真实运行的系统里看到效果变化。先接一个最简单的问答服务再加知识库再加工具调用再加测试评估改造到哪一层问题就暴露在哪一层排查起来会清晰得多。反过来如果你按“教科书式”顺序先花两周搞数据管道、再花两周搞模型网关最后才发现整体架构选型有问题返工成本就太高了。2.3 关键选型轻量可迭代的起步组合项目起步阶段我没有一上来就上重型 LLMOps 平台而是选了一套“能独立复现、能跑在一台开发机上、又能平滑迁移到平台化方案”的技术组合模型层以 OpenAI 兼容协议为标准方便在不同厂商的模型、本地开源模型之间切换。编排层优先用 Python 的 LangChain 风格组件但不是依赖它的全部封裝而是理解每个组件背后的逻辑尤其是 Prompt 模板和检索器的内部机制。向量库先选支持内存模式运行的轻量级方案比如 Chroma 或 FAISS数据量大了再迁移到 Milvus 这类生产级向量库。Agent 框架不盲从“全自动规划型”而是从工具调用Function Calling做起明确哪些步骤需要模型决策、哪些步骤用规则硬编码这样出错时可解释性会强很多。测试评估用一套本地可跑的“测试集驱动评测”把评测结果做成结构化数据后续可以接入平台化评测体系。选型的核心逻辑是每引入一个新组件都必须能在半小时内跑通一个最小验证。如果你开始创业或者进大厂做 AI 项目这套逻辑依然成立——先验证再扩展永远是控制风险最稳的方式。3. 核心实施从零搭建最小可用的 AI 工程骨架3.1 最小闭环一个带知识库的问答服务项目第一步是把大模型应用的最小闭环跑通也就是“用户问题 → 检索增强组装 Prompt → LLM 调用 → 结构化输出”。我选了一个很常见的场景基于内部文档的智能问答。这样既不需要额外造数据又能验证 RAG 全流程。具体实现分为四步文档加载与清洗把散落在 Word、PDF、Markdown 里的内容规整为纯文本统一编码处理掉页眉页脚、表格装饰性符号。分块与向量化按段落和章节边界做语义分块设定合理块长度和重叠区间然后用 Embedding 模型转成向量。检索与重排针对问题做向量相似度检索同时对召回结果做一次粗粒度过滤。拼 Prompt 调模型把召回片段注入 Prompt同时设置角色指令、引用格式要求、拒答策略最终返回答案及引用来源。这里重点说一下分块策略这是很多人会踩深坑的地方。我一开始单纯按每 500 字切一块切完发现两个问题一是语义被切断了同一段技术方案的“背景”和“结论”被拆成两段检索时匹配上下文会不完整二是大量重叠文本导致向量库膨胀检索时无关片段反而干扰模型判断。后来改成“按 Markdown 标题树拆分 块内补充上下文摘要”召回效果明显提升。可以说分块就是把“长文本的记忆”转换成一个结构化的目录和索引切得不好后面的检索再努力也白搭。3.2 用 Harness 式工程思维做 AI 测试这里要引出热搜词里很关键的harness engineering这个概念。传统软件里的 Test Harness 是指一套能够驱动被测代码、模拟外部依赖、收集执行结果的测试装置。AI 工程里的 Harness 同样重要——你要为整个 LLM 应用搭一圈“测试笼头”让它在可控、可观测、可重复的环境里跑。为什么要这么做因为大模型应用天然有两个痛点结果不确定性和链路不可解释性。同一个问题温度参数改成 0.2 和 0.8 回答可能完全不同某个环节到底是检索错了还是模型理解错了不通过强大的测试装置很难定位。我在项目里构建了一套轻量 Harness包含三个层次单元测试层针对 Prompt 模板、文档分块函数、输出解析器做纯函数级测试。行为测试层用一组带标准答案的测试问题对每个问答链路执行“给定输入 → 断言输出包含关键点 → 断言引用来源正确”的测试。混沌演练层模拟模型超时、向量库返回空结果、上下文超长截断等情况验证系统的降级和容错。这套 Harness 帮我抓到了一个非常隐蔽的 Bug当检索返回空集合时Prompt 模板里如果没有明确的“我不知道”指令模型会硬“编”一个答案出来。这个现象在单个问题测试里很难发现但用 Harness 批量跑测试集后约 12% 的空检索案例都出现了幻觉式输出。加入拒答分支后这个问题彻底解决。3.3 实战案例多智能体协作与工具调用的可靠性在ai-engineering-from-scratch项目的中后期我加入了一个更复杂的场景让多个 Agent 协作完成一个跨步骤任务比如“根据最新周报、历史项目数据和生产环境指标生成一份项目健康度报告并发送给相关人”。这看起来很像日常办公但在 AI 工程落地时多智能体协作要把可靠性放在第一位。我实施的第一步是工具注册体制。每个工具必须声明自己的名称、描述、参数 Schema、权限级别并允许 Agent 通过 Function Calling 精准选择工具。第二步是加入“人来监督”的确认机制任何需要调用外部服务比如发邮件、改配置的工具都不允许 Agent 直接执行而是要生成一个“待确认操作卡片”由用户点击确认后再执行。这一套设计跑下来我对 AI Agent 工程有了一个非常清醒的认识Agent 的“聪明”不是建模出来的而是约束出来的。模型只能负责“提方案”工程系统负责“上锁”“校验”“回滚”。如果设计 Agent 时全指望模型自主规划出了事故都得你来背锅。具体到代码层面我使用 Python 写了一个极简的 Agent 编排器核心逻辑就是一个循环把用户任务和系统提示交给模型解析模型输出判断是否有 tool_calls若有则执行工具并把结果追加回上下文若无则输出最终答案并结束循环。为了控制循环次数和 Token 消耗我为循环加了“最大迭代次数 8 次”的护栏同时监控每一步消耗的 Token 数。整个过程中最值得复用的经验是把每一次工具调用的输入输出完整记到日志里。方便排错是一方面更重要的是给后续的评测系统提供数据知道 Agent 在哪个环节做了错误判断就可以针对性地调整环境变量或工具描述。4. 评估体系与工程化落地细节4.1 离线评测集比想象中更早就要建做 AI 工程最怕的是“感觉变好了”。没有评测集你无法量化地知道改一个 Prompt 是让问答变准了还是变坏了。所以我在项目第二天就开始建评测集而不是等系统完善后再补。评测集的设计要点有三个真实分布要比标答重要。尽可能从真实用户问题中抽样而不是自己拍脑袋写问题。每个问题要标注“期望要点”便于做跟 LLM 相关的部分匹配评估。评测集需要定期迭代每两周扩展一次把线上遇到的 badcase 加入回归集。有了评测集之后改动 Prompt、换模型、调分块参数都可以通过跑同一套测试来计算准确率变化。我用的是“答案覆盖度 引用准确率 拒答准确率”三个指标的加权得分。需要注意的是这些指标主要反映 LLM 应用的“行为正确性”它必须结合下面的质量评估来一起看。4.2 质量评估模块从响应质量到成本效率在ai-engineering-from-scratch项目里我建设了一个专门的质量评估模块用来解决四个核心问题响应是否准确且相关由大模型扮演评审员使用独立的 Prompt 对回答的“事实一致性”“相关度”“完型度”打分。回答是否存在幻觉用检索内容与回答做交叉验证提取回答中的关键主张检查能否在检索片段中找到支撑。每次请求花费多少 Token按输入/输出分开统计按模型单价换算成本按用户会话聚合。延时可接受吗重点看 P50/P95 两个分位P95 高说明链路稳定性不够。这一套质量评估跑起来之后我明显发现自己优化起系统来更有的放矢了。比如我发现某一天的 P95 延迟增长了近两倍排查日志发现是向量数据库连接池耗尽导致的排队跟模型本身一点关系都没有。没有质量评估这种问题很难被发现但一旦你把监控指标做细链路故障都会现出原形。4.3 接口设计与可扩展性AI 工程项目里接口设计的价值往往被低估。我为自己写的所有模块制订了一套接口规范输入一律是结构化的Request对象输出一律是包含answer、sources、cost、latency的Response对象任何异常都不会让调用方拿到非 JSON 内容。这样做最大的好处是前端、后台、评测工具都能共用同一套数据协议后续接入多智能体、客服系统、数据分析平台也比较顺。尤其是在把 AI 能力嵌入复杂业务系统时数据协议的稳定性就是协作效率的保证。5. 常见问题与避坑实录5.1 上下文窗口的“伪安全区”处理 Token 溢出与信息截断几乎所有做 AI 工程的人都会被上下文窗口卡一次。模型宣传支持 8K、32K、128K但实际使用中上下文越长并不意味着效果越好。我在项目初期打开了一扇“大门”把检索出来的 Top 20 文档全塞进 Prompt结果 Token 消耗暴涨回答质量反而下降模型开始忽略关键信息甚至出现复读式输出。后来我做了两个调整一是把 Top K 从 20 降到 6二是加入“Token 预算”机制在组装 Prompt 前先按权重排序超出预算就砍掉相关性最差的片段。这一步优化后单次请求的 Token 消耗下降了近 55%响应质量大幅度改善。上下文窗口的正确用法是“按需裁剪加压缩”而不是“全往里塞”。5.2 模型幻觉测试集只能发现系统设计才能解决治理大模型幻觉做测试只能发现问题真正能解决问题的还是设计上的约束。结合我经历过的场景收敛幻觉的设计手段主要有三类第一类知识约束。检索不到相关内容时明确让模型拒绝回答而不是东拼西凑。第二类输出约束。用 JSON Schema 或受控枚举限制回答的结构模型只能在你给定的框架内生成。第三类过程约束。对关键数据引用强制要求附带来源 ID没有来源 ID 的回答被评估系统判为不合格。这套三层设计叠加起来幻觉比例可以从“偶尔出现”压到“可以接受”的水平。如果你要交付一个 AI 产品这个幅度是决定成败的。5.3 测试与监控中容易被忽略的盲区AI 工程项目特别容易犯一个错误测试做得很全面但上线后就不再关注了。模型输出是概率性的线上运行的数据分布会漂移你今天认为很好的模型下个月可能表现越来越差因为用户问的问题变了。我对此的解决方案是每天拉取线上问答日志抽取 10% 做自动质量评估每周对比评估分变化曲线发现下滑趋势立即暂停模型升级或调整 Prompt每月将线上 badcase 加入离线回归集形成“离线抓回归在线抓漂移”的双轨闭环。这套机制在初期投入不大但长期看它保证了你对系统的每次调整都有反馈。5.4 成本控制别让一次“对话”吃掉一顿饭的钱做 AI 工程成本控制绝对是工程必修课。我见过有团队把每个问答请求的 Token 消耗算到接近一块钱人民币这显然是不可持续的。我总结的省钱三板斧一条 Prompt 模板能发两次就绝不发三次利用缓存机制比如多轮会话内全局上下文变量和摘要化保存。检索能过滤的先过滤不要让模型处理它不该处理的信息。不做无用精读简单的分类、路由请求可以用轻量模型处理复杂推理才用大模型。通过以上优化我项目里单次问答成本从最初的约 0.15 元降到了 0.03 元左右效果却基本持平。成本优化不是小气而是给模型调用加上“纪律约束”它能倒逼你把 Prompt 写的更精炼把链路设计的更合理。6. 项目复盘与后续扩展思路整个ai-engineering-from-scratch项目跑完最大的感受是做好 AI 工程真正的难点全都在模型之外。数据分块、工具调度、评测回归、成本可控、监控告警这些传统的“工程能力”放到 LLM 时代反而变得更重要了。模型能力不够强的时候你需要各种花式 Prompt 去补救模型能力越来越强之后决定产品成败的是外围系统的稳定性和数据质量。这个项目后续可扩展的方向太多了。比如在现有 RAG 链路基础上接入支持结构化查询的数据库 Agent让用户可以直接用自然语言查询业务数据又比如把评测集和评测逻辑做成一键启动的 CI/CD 流水线任何 Prompt 变更都必须通过自动评审后才能上线。如果你用的是支持云端部署的方案还可以把质量评估模块包装成一个独立微服务对多团队复用。如果你准备复刻这一个项目我的一条真心建议是不要跳过 Harness 和评测体系那是这个项目的灵魂而不是加分项。先让系统“可测试”再让系统“可工作”你在 AI 工程上走的弯路会少很多。下一步我打算把多 Agent 协作部分扩展成可以跟本地工具深度交互的平台如果有人对这个方向感兴趣咱们可以继续一起折腾。