系列：AI工程化学习助手实战 · 第一篇
作者：一名 SRE / 运维工程师的 AI 探索之旅（炼丹土拨鼠）
写在前面：一个SRE工程师的困惑
我是一名 SRE（网站可靠性工程师），每天的工作是让系统稳定运行——监控告警、故障排查、自动化运维、容量规划。
2023 年，ChatGPT 横空出世的那一刻，我和大多数人一样，第一次感受到了 AI 的震撼。我开始频繁使用它写脚本、查文档、问问题。但随着用得越来越深，一个问题开始困扰我：
"我只是在'用' AI，还是真的在'懂' AI？"
打开 GitHub，到处都是 LangChain、RAG、Agent、Prompt Engineering……每个词我都认识，放一起却像读天书。
更尴尬的是：作为一名搞基础设施的工程师，我深知一个道理——
会用工具，和能把工具做成可靠系统，是两件完全不同的事。
所以我决定：系统学习 AI 工程化，并且边学边做，把它做成一个真实可用的学习助手。这个系列文章，就是我的学习实战录。
第一个问题：什么是 AI 工程化？
在聊为什么做之前，先搞清楚「AI 工程化」到底是什么。
我最初以为它等于"训练模型"——错了。后来以为是"调 API"——也不全对。
真正让我想明白的，是把它和我熟悉的东西类比：运维不等于装软件，AI 工程化也不等于跑模型。
更准确地说，AI 工程化做的事是：把一个"在实验室能跑通"的 AI 能力，变成一个"在生产环境能稳定运行"的系统。这中间的鸿沟，才是工程师真正要填的东西——它包括容错、监控、版本管理、权限控制……每一项都是我们 SRE 日常在干的事。
换句话说，AI 工程化关注的不是模型本身有多聪明，而是如何让它在真实世界里可预期、可观测、出了问题能快速恢复。
分层，是工程师驯服复杂度的万能药
学 AI 工程化遇到的第一道坎，是"不知道从哪下手"——概念太多，全搅在一起。
后来我发现，解法其实我早就用过了：分层。
OSI 七层模型我学过，当时觉得"有点抽象，但好用"。它最大的价值不是那七层本身，而是背后的思路：把复杂系统切开，每一层只做一件事，层与层之间通过接口通信，互不干扰。物理层坏了换网线，不影响应用层；HTTP 协议升级了，IP 路由层不用动。
AI 工程化用的是同一套思路：
从底层的基础能力（调 API、写 Prompt），到顶层的业务应用，每层有自己的职责边界。这意味着——你换个向量数据库，不用重写上层的 Agent 逻辑；你优化了 Prompt 模板，也不影响底层的模型调用方式。
这个架构图贴出来的那一刻，我脑子里自动映射上去的是：这不就是我们的基础设施栈嘛？网络层、存储层、计算层、应用层……形式不同，道理一样。
Demo 能跑，不等于系统能用
这是我在 SRE 工作里见过最多的事故根源，没想到在 AI 领域撞得更频繁。
GitHub 上那些 Star 过万的 AI 项目，很多跑起来效果惊艳——在 Notebook 里，在演示数据上，在作者自己的机器上。但你真的把它接进生产系统，问题就来了：它不知道怎么处理超时，出错了没有任何日志，换一批数据就开始胡说，并发一高直接崩。
这不是模型的问题，这是工程的问题。
做 SRE 这几年，我有个经验：一个系统的质量，不看它最好时的表现，而看它最差时的边界。实验原型的"最差"是偶尔回答错；工业级系统的"最差"必须是可预测、可恢复、可追溯的——这恰好就是稳定性、可维护性、可观测性、安全性、性能这五个维度在 AI 系统里的落地要求。
而这五项，和我们 SRE 的值班 checklist 几乎是同一张单子。这个发现让我松了口气：原来不是一门新学科，而是把老本行的要求迁移到新的技术组件上。
模型只是组件，这句话改变了我的思路
学 AI 工程化最让我"咔"一声开窍的，是意识到一件事：
在工程化的视角里，模型只是组件之一。
这话听起来平淡，但对我的冲击很大。之前我看那些 AI 项目，下意识地把"模型"当成系统本身——模型好，系统就好；模型换了，系统就要重做。
但工程师不这么思考。数据库只是系统的组件，消息队列只是系统的组件，没有人说"我把 MySQL 装上去，系统就完成了"。同理，LLM 也只是系统里一个具备推理能力的组件，它上面还需要流程编排、上下文管理、工具调用、监控告警……
这个视角一转，很多东西就对上了：
- Prompt 写死在代码里，等于配置硬编码——这在运维里是大忌
- 单次调用没有状态，等于无法做多轮任务——就像 HTTP 无状态一样，需要在外层设计 session
- 没有日志和链路追踪，出了问题根本不知道哪个环节崩的——这在 SRE 里叫"盲区"
看到 Docker、Kubernetes、Prometheus 了吗？——这些都是我每天在用的东西。
AI 工程化不是另一个世界，而是我熟悉领域的延伸。
真正开始学之后，我被三个问题卡住了
理解了"什么是 AI 工程化"之后，我开始动手。然后立刻撞墙。
不是撞在模型上，而是撞在三个工程问题上，几乎每一个 AI 系统都绕不开：
第一个：AI 怎么和外部世界交互？ 光靠对话生成文字没用，我需要它能查数据库、调接口、执行操作。但模型本身不能直接"做事"，这中间的桥梁怎么搭？
第二个：AI 怎么处理需要多步骤的任务？ 用户问"帮我分析最近三个月的告警趋势并给出优化建议"——这不是一次推理能搞定的，它需要先查数据、再分析、再推理、再输出。怎么让模型一步步来，而不是直接胡说一段？
第三个：一个 AI 不够用时，怎么让多个协同工作？ 复杂任务往往需要角色分工——有的负责查信息，有的负责判断，有的负责最终输出。怎么让它们像一个团队一样运转，而不是各说各话？
这三个问题，后来我知道了对应的名字：Function Calling、Chain of Thought + Agent Loop、Multi-Agent 协作。但当时我是先碰壁，后来才对上号的——这种顺序，反而让我理解得更深。
一个真实场景感受复杂度
来感受一下真实系统的复杂度。假设收到一条生产告警：
"服务 A 错误率突增，P99 延迟从 200ms 飙升到 3s，影响范围未知。"
一个有经验的 SRE 接到这条告警，会自然地：
- 确认告警 — 查原始告警，确认触发时间、指标、影响服务
- 影响评估 — 查业务日志/系统日志，确认影响范围和严重程度
- 紧急止损 — 优先恢复服务：限流 / 降级 / 回滚 / 扩容
- 拉起应急协同 — 通知相关方，同步进展，协调研发/测试资源
- 根因定位 — 服务恢复后深度排查，找到根本原因
- 复盘与改进 — 沉淀经验，输出改进方案，防止复发
但一个 AI 系统要做到这件事，需要：
每一步都需要工程化的设计：工具如何定义、Agent 如何调度、失败如何重试、结果如何验证……
这就是 AI 工程化要解决的问题。
为什么是「学习助手」？
说了这么多背景，回到最初的问题：为什么我要做一个 AI 工程化学习助手？
原因很简单，三条：
1. 用最好的方式学习
做中学（Learning by Doing）是工程师最高效的学习方式。构建一个真实系统，比读一百篇教程收获更多。
2. 解决自己的真实痛点
学 AI 工程化的资料很碎，从 Prompt Engineering 到 RAG、从 LangChain 到 Multi-Agent，需要一个助手帮我整合、追踪、答疑。
3. 验证 AI 工程化的可行性
SRE 的本能：不相信没经过验证的东西。自己做一遍，才知道哪些是真正的工程挑战，哪些是营销概念。
这个系列会做什么？
我们要做的是一个真实可用的 AI 工程化学习助手——它的知识来源是你自己积累的资料：课程 PDF、学习笔记、公众号文章，每一篇文章都给它增加一个新能力，最终做成一个完整的 Agent 系统。
| 阶段 | 主题 | 助手获得的能力 | 知识来源 |
|---|---|---|---|
| 第 1 阶段（本篇） | 什么是 AI 工程化 | — | — |
| 第 2 阶段 | 大模型调用 & Function Calling | 能对话，能调工具 | — |
| 第 3 阶段 | LangChain 核心组件 | 有工作流，能串联多步骤 | — |
| 第 4 阶段 | RAG 知识增强系统 | 能检索你的学习资料回答问题 | 学习笔记 + 公众号文章 + 掘金 + 知乎 |
| 第 5 阶段 | Prompt Engineering | 回答更准确、更可控 | 同上 |
| 第 6 阶段 | Agent 设计与多轮对话 | 能主动规划学习路径 | 同上 |
| 第 7 阶段 | 多 Agent 协作 | 拆解复杂问题，多角色协同 | 同上 |
| 第 8 阶段 | 部署与生产化 | 跑在服务器上，有监控告警 | 同上 |
助手的知识从哪来？
不是让 LLM 凭空回答，而是让它基于你自己积累的资料来回答——这才是真正属于你的学习助手。
每一阶段都会有：
- 理论解析：搞清楚"是什么、为什么"
- 代码实战：可运行的模块，直接拼进助手
- 工程思考：SRE 视角的可靠性、可观测性思考
写在最后
作为一名 SRE，我坚信：
AI 是一场时代的潮流，而工程化是让浪潮变成可用系统的关键。
我们不需要成为 AI 研究员，但我们需要有能力把 AI 能力可靠地集成进系统。这正是工程师最擅长的事情。
这个系列记录的是一个运维工程师学 AI 工程化的真实历程——包括收获、包括踩坑、包括那些"哦，原来是这样"的顿悟时刻。
如果你也是工程师，对 AI 感兴趣但不知道从哪里下手——欢迎跟我一起探索。
下一篇：《大模型调用基础 & Function Calling：让 AI 学会"使用工具"》
点击关注，持续更新中……
关于作者 SRE / 运维工程师，AI 工程化学习者。 相信每一行可靠的代码背后，都有一个工程师在认真思考。
