中间件（Middleware）是夹在底层运行环境与上层业务代码之间、或者夹在两个业务系统之间的一层通用软件，专门提供“每个业务都要用、但谁都不该自己重写”的能力。
先看一个不写代码的比方
一栋写字楼里，每家公司自己决定卖什么、怎么排班、怎么考核，这是业务。但电力、消防、中央空调、电梯、门禁、保安，没有任何一家公司会自己挖井发电、自己雇一支消防队，这些由物业统一提供。物业就是这栋楼的中间件：它不生产任何一家的业务，但每家都离不开它，而且它做得越稳，大家越感觉不到它存在。
落到系统里，这层“物业”包括：消息队列（Message Queue）让两个系统不必同时在线也能传话；RPC 框架（Remote Procedure Call）让跨机器调用写起来像调本地函数；还有数据库连接池、缓存客户端、统一鉴权、限流熔断、日志与链路追踪。
AI 场景里的中间件长什么样
一个团队做客服机器人，第一版直接在业务函数里调模型：超时重试、密钥轮换、超长文本截断、敏感词过滤、用量统计，全塞在一起。半年后第二个产品上线，这段代码被复制过去改了个变量名。等到第三个产品要换模型供应商，才发现得改三个地方、测三遍。
于是他们抽出一层模型网关（LLM Gateway）：业务只对网关说话，重试、路由、配额、脱敏、计量都交给网关。业务代码从两百行调用细节退回成一行 generate(prompt)。这层网关就是 AI 时代的中间件，同类还有 Agent 编排框架、RAG 管道、向量库访问层。
和相邻概念的区别
| 谁调用谁 | 部署形态 | 改动的影响面 | |
|---|---|---|---|
| 业务代码 | 自己就是终点 | 随应用 | 单个功能 |
| 库（Library） | 你的代码调用它 | 打包进你的程序 | 一次构建 |
| 框架（Framework） | 它调用你的代码 | 打包进你的程序 | 整个应用结构 |
| 中间件 | 双方都可能调它 | 通常独立进程、独立部署，可单独扩缩容与监控 | 所有接入方 |
一条实用判断线：能不能单独部署、单独监控、单独扩容。能，多半是中间件；不能，只是一个库。
对两类人的实际意义
对做技术的人：判断一段逻辑该不该抽出去，最可靠的信号是“第三个调用方出现了”。第一次写死没问题，第二次复制开始有味道，第三个调用方出现时，抽取的收益才真正大于成本。反面同样要记住：中间件不是免费的，它多一跳网络、多一个要运维排障的组件、出故障时多一个环节。抽象不足会重复劳动，抽象过度会养出一个没人敢改的黑盒。
对普通职场人：公司里那些“统一登录”“统一支付”“统一工单”的收口动作，本质上就是在建中间件。它们不好看、也不直接产生收入，却决定了下一个新业务上线要花三周还是三天。所以中间件的成熟度，某种程度上是一个组织重复劳动量的温度计。