一句话定义：服务网格（Service Mesh）是一层专门处理「服务之间怎么安全、可靠地互相调用」的基础设施。它把加密、重试、超时、熔断、限流、观测这些通用能力，从业务代码里抽出来，下沉到每个服务实例旁边的轻量代理里。
打个比方。一栋写字楼里有几十家公司互相寄文件。最原始的做法是每家公司自己雇快递员、自己定规矩、自己记账，谁都得会这一套。服务网格的做法是：物业在每家公司门口都安排一个统一的「收发室」。文件进出必须经过它，它负责核对身份（对方是不是真的那家公司）、登记流转记录、对方没回应就自动重发一次、对方明显已经瘫痪就不再白跑一趟。公司里的人只管写文件，不用管收发细节。
技术上怎么实现。这套「收发室」叫边车（sidecar）：每个 Pod 里除了业务容器，还跑一个代理容器，业务的所有进出流量都被透明地劫持到它身上。这一层叫数据平面（data plane）。而「物业总部」叫控制平面（control plane），负责把策略下发给所有边车：谁可以调用谁、重试几次、超时多少、证书什么时候轮换。数据平面和控制平面合起来，就是服务网格。
它和 API 网关（API Gateway）常被搞混，但方向完全不同：
| 维度 | API 网关 | 服务网格 |
|---|---|---|
| 管什么流量 | 南北向：外部用户进入系统 | 东西向：系统内部服务之间 |
| 部署位置 | 入口处，通常是少数几个 | 每个 Pod 旁边，数量随服务规模增长 |
| 主要职责 | 鉴权、路由、限流、对外暴露 | mTLS 加密、重试、熔断、灰度、链路追踪 |
| 谁受益 | 外部调用方 | 内部所有微服务 |
一句话：网关是小区大门，网格是每栋楼每户门口的门禁。两者可以并存，也可以互相替代一部分能力，但解决的不是同一个问题。
对 AI 从业者的实际意义。一个智能体（agent）服务往往要在一轮任务里调用模型 API、检索服务、工具函数、其他 agent，链路又深又长，任何一跳抖动都会被放大。这些恰恰是服务网格擅长的：给所有调用自动加上双向 TLS（mTLS）身份认证，让「这个请求到底来自哪个 agent」不再靠自报家门；给不稳定的下游配置超时和重试，避免一个卡住的工具调用拖垮整条链；用熔断挡住已经故障的依赖；用统一的链路追踪（tracing）把一次任务跨十几个服务的耗时拼成一张图。这些都不需要改一行业务代码，是它最大的价值。
代价也要说清楚：多一跳代理就多一份延迟和资源开销，边车数量随服务数量线性增长，控制平面本身也成了需要运维的组件。服务只有几个、调用关系简单时，引入网格往往是过度设计。
要不要上，判断标准很朴素：当你发现各个团队都在自己复制粘贴重试和加密代码，而且线上排查问题时要挨个服务问日志，那就到了该考虑的时候。具体选型和能力边界，以官方文档为准。