第1700篇：里程碑特辑——1700篇回顾，AI工程化这条路我们走到哪了
第1700篇：里程碑特辑——1700篇回顾，AI工程化这条路我们走到哪了
写这篇的时候，我在键盘前愣了一下。
1700篇。
这个数字在屏幕上显示着，但感觉有点不真实。我记得当年写到100篇的时候，发了个朋友圈庆祝，现在已经是那个数字的17倍了。
这不是一篇技术教程。今天我想做的事，是回头看——我们走了多远，走对了哪里，走偏了哪里，以及我对接下来的路的一些想法。
从第一篇到现在，这个领域变了什么
我的第一篇文章写的是"如何在Java Spring Boot里集成OpenAI API"，那还是2023年初。那个时候，国内真正在生产环境用大模型做业务的公司屈指可数，大部分人还在观望阶段。
现在是2026年初，景象完全不同了。
每个有一定规模的互联网公司都有AI团队，或者正在组建AI团队。大模型调用已经成为和调用数据库、调用缓存一样普通的基础操作。招聘AI工程师的JD里，Spring AI、LangChain、向量数据库这些词已经成了标配要求。
这个变化速度比我预期的还快。
但有一件事变得比我预期慢：AI工程化能力的建立。
很多公司的AI项目上线了，但在生产环境里跑得非常不稳。高延迟、偶发超时、内存泄漏、成本失控……这些问题在大量项目里反复出现，不是因为工程师水平差，而是因为AI服务的工程化问题本质上比传统服务更复杂，而系统性的知识积累还不够。
这也是我一直在写这个系列的原因。
最近这10篇在讲什么
这1691到1700的一组，我集中打了一个主题：AI服务的性能与可靠性工程。
具体来说：
- 第1691篇 讲JVM调优在AI应用里的特殊性——GC暂停会直接变成用户感知的推理延迟，需要认真对待
- 第1692篇 讲Java虚拟线程——AI服务是I/O密集型，虚拟线程能让代码写法更简单同时支撑更高并发
- 第1693篇 讲WebFlux的流式输出和背压——用了才知道有多复杂，很多坑是踩过才明白的
- 第1694篇 讲连接池优化——AI服务的连接使用模式和普通服务完全不同，连接池配置也要跟着变
- 第1695篇 讲内存泄漏排查——对话历史、Embedding缓存、ThreadLocal……AI场景特有的泄漏源
- 第1696篇 讲超时策略设计——分级超时、快速失败和降级，没有超时保护的AI服务等于裸奔
- 第1697篇 讲JMH基准测试——用数字而不是感觉来评估性能，AI场景的测试有自己的陷阱
- 第1698篇 讲Observability——Micrometer指标、分布式追踪、日志关联，三件套缺一不可
- 第1699篇 讲慢查询分析——找出高延迟AI调用的根因，系统化的优化方法论
- 第1700篇 就是现在这篇，回顾与展望
我觉得这两年讲对了的几件事
第一，架构层面的分离关注
RAG不只是"加一个向量数据库"，它涉及Embedding服务、向量检索、Reranking、Prompt Assembly一整个链路。我很早就在讲这个链路里每一个环节的工程挑战，而不只是调几行API。
事实证明，项目遇到问题的地方，确实主要集中在这些环节，而不是"大模型不够聪明"。
第二，成本意识
大模型按Token计费，这是很多工程师没想透的。我在很早的文章里就讲过Token用量监控、Prompt压缩、语义缓存这些控制成本的手段。
后来见到很多项目出现"Token账单比预期高10倍"的情况，根本原因就是没有建立成本意识和监控。
第三，可观测性先行
很多文章讲功能实现，但我在讲功能的同时一直强调：可观测性要和代码一起写，不能后补。
在AI服务里，你不知道为什么慢、为什么错、钱花在哪了，这些问题如果没有观测能力，是无解的。
我觉得我没讲好的几件事
第一，Agent和工具调用
Function Calling/Tool Use这个方向，我文章写得偏浅。实际上AI Agent在生产环境里遇到的工程问题——工具调用失败的重试策略、多步推理的状态管理、工具结果的安全过滤……这些内容我没有深入讲。这是接下来要补的功课。
第二，模型微调的工程化
LoRA微调、数据集构建、评估流程……这些我涉猎不多。但越来越多的公司开始做领域模型微调，工程化问题越来越突出，这个方向值得深入。
第三，AI安全与合规
Prompt注入、数据隐私保护、输出过滤……这些话题我只是浅尝辄止地提过，没有深入技术实现。随着监管要求越来越严格，AI安全工程会变得非常重要。
现在的AI工程师市场，我的观察
我和很多在找工作的AI工程师聊过，也和很多在招人的团队聊过，发现一个明显的错位：
求职者大多数学了很多工具和框架（LangChain、LlamaIndex、Spring AI），能快速demo出各种功能，但对生产环境的工程化挑战理解不深。
招聘方越来越注重工程化能力：这个人能不能独立负责一个AI服务从开发到上线、监控、性能优化的全流程？能不能在出了问题的时候快速定位和处理？
这个错位就是我写这个系列的核心动力。
工程化能力——这才是AI工程师真正的护城河。会调API不值钱，会调参不值钱，能把一个AI服务跑得稳、快、省，这才是真本事。
接下来1700到2000篇，我打算讲什么
我有一个大体的规划，不是承诺，但算是方向：
AI Agent工程化（约50篇）
- 多步工具调用的状态管理和恢复
- Agent决策链路的可观测性
- 工具调用的沙箱安全设计
- 复杂工作流的编排和回滚
LLM Fine-tuning工程化（约30篇）
- 训练数据集的构建和质量控制
- LoRA微调的实践和踩坑
- 微调模型的评估体系
- 模型版本管理和部署策略
AI基础设施（约40篇）
- GPU集群的资源管理
- 本地推理引擎（vLLM、llama.cpp、Ollama）的工程化
- 模型量化和部署优化
- AI服务的多云部署架构
RAG深水区（约30篇）
- 高级检索策略（HyDE、多步检索、Reranking）
- 向量数据库选型和大规模部署
- 知识库的更新和一致性保证
- 多模态RAG（图片、表格、代码）
当然，热点话题会随时插入。AI领域变化太快，计划永远赶不上变化。
给关注这个专栏的朋友几句话
我从来不把这个专栏当成"输出知识"来做，而是当成一个"记录自己和团队踩坑过程"的地方。
很多文章里的代码，是我们在真实项目里写出来然后改了很多遍的版本。很多"坑"，是真的花了几天时间才弄明白的。写出来，希望你们能少踩一些。
如果你看某篇文章觉得"讲错了"或者"有更好的方案"，欢迎在评论区指出来，我认真看每一条。技术方案本来就没有绝对的对错，有讨论才有进步。
有一类留言我特别喜欢看：某个同学在工作中遇到了文章里讲的问题，试了一下文章里的方案，解决了，然后来分享一下自己的情况。这种留言让我觉得这些文字有了实际价值。
一点感谢
写了1700篇，不是一个人在坚持。
感谢每一个点过在看的人——你们让这篇文章能被更多人看见。
感谢每一个留言讨论的人——技术是需要碰撞的，你们的留言让我也在持续学习。
感谢知识星球里的各位星友——你们的问题让我不得不去搞清楚自己模糊理解的东西。
好，感性环节结束。
第1701篇，回归技术。
我打算写AI Agent里工具调用失败的重试与补偿机制——这个看起来简单但在生产里非常容易翻车的话题。
敬请期待。