十年前的微服务热潮，最后沉淀下来的不是微服务本身，而是围绕微服务长出来的一整层基础设施——服务注册、服务发现、负载均衡、熔断、限流、可观测性。它们被统称为 Service Mesh。
今天这一幕正在 Agent 世界里重演。
过去一年，Agent 从一个「玩具」变成了「生产基础设施」。但绝大多数团队对 Agent 的理解还停留在「写好 prompt、调好工具、跑起来」的层面。当 Agent 的数量从 1 个变成 10 个、100 个、1000 个，当它们开始互相调用、共享工具、争夺资源的时候，你需要的不是更多 Agent，而是管理 Agent 的基础设施。
这是「多Agent 系统架构设计」系列的收官篇。前三篇我们分别聊了编排模式、通信层、演进路径。这一篇，我们把视角从「怎么搭一个多 Agent 系统」抬升到「大规模 Agent 部署需要什么样的基础设施」。
核心论点：Agent 即服务（Agent as a Service）。当 Agent 变成微服务，Agent Mesh 就是新的 Service Mesh。
从 Service Mesh 到 Agent Mesh：历史的镜像
微服务解决了单体应用的扩展性问题，但代价是引入了全新的分布式系统复杂度。Service Mesh 就是为了吸收这种复杂度而生的：
微服务时代 Agent 时代
────────────────────────────────────────────────
服务注册中心 (Consul/etcd) → Agent Registry
服务发现 (DNS/Service Discovery) → Agent Discovery
通信代理 (Envoy Sidecar) → Agent Gateway
流量管理 (路由/熔断/限流) → Agent 路由与策略
可观测性 (Tracing/Metrics) → Agent 观测
安全 (mTLS/零信任) → Agent 安全
这个映射不是牵强附会。Agent 在架构上的本质，和微服务惊人地相似：
| 维度 | 微服务 | Agent |
|---|---|---|
| 基本单元 | 独立部署的服务 | 独立运行的智能体 |
| 接口 | REST/gRPC API | Tool/MCP 接口 |
| 生命周期 | 启动/健康检查/下线 | 创建/心跳/销毁 |
| 通信 | 服务间调用 | Agent 间协作（A2A） |
| 治理 | 注册/发现/流量管理 | 注册/发现/任务路由 |
| 故障 | 宕机/超时/雪崩 | 幻觉/卡死/级联失败 |
微服务用「进程」封装了业务逻辑，Agent 用「智能」封装了任务执行。 当智能体变成组织的基本执行单元，它们就必须被当作一等公民来治理——而治理智能体的一整套基础设施，就是 Agent Mesh。
Agent Registry：Agent 的「户口本」
Agent 要协作，第一步是互相发现。而发现的前提，是注册。
在微服务世界，服务启动后向注册中心登记自己的地址、端口、健康状态。在 Agent 世界，Agent 启动后向 Agent Registry 登记：
{
"agent_id": "agent-finance-001",
"name": "财务分析 Agent",
"version": "2.3.1",
"capabilities": ["read_reports", "analyze_expense", "predict_budget"],
"endpoint": "agent://finance/001",
"tools": ["mcp://financial-reports", "mcp://budget-api"],
"auth": {
"scope": "read-only",
"principal": "org:finance"
},
"status": "ready",
"created_at": "2026-08-07T09:00:00Z"
}
Agent Registry 和传统服务注册中心的关键区别：
- 注册的不是地址，是能力。微服务注册的是 IP:Port，Agent 注册的是 capabilities——它能干什么。这决定了 Agent 的发现是语义发现（找一个能分析财报的 Agent）而不是位置发现（找一个 10.0.0.1:8080 的服务）。
- 能力描述是可执行的。Agent 的能力通常绑定一组 Tool/MCP 接口，Registry 需要保存能力与工具的映射关系，供调用方做动态规划。
- 生命周期更复杂。Agent 可以瞬时创建（一次任务一个实例）、可以长期驻留、可以休眠唤醒。Registry 需要支持比微服务更丰富的状态机。
这是我做 MCPZERO 时最深的体会：MCP 解决了「Agent 怎么调用工具」，但没解决「哪个 Agent 该用哪个工具」。当工具的数量超过几十个，靠 prompt 让 Agent 自己选工具已经不可靠了——需要一层 Registry 来做语义匹配和权限绑定。
Agent Discovery：从「找地址」到「找能力」
有了 Registry，下一步是 Discovery。但在 Agent 世界，Discovery 的含义被扩展了。
微服务的 Discovery 是静态的：根据服务名查地址，返回可用实例列表。Agent 的 Discovery 是动态的、语义化的：
用户: "帮我把上季度东南亚市场的保险理赔数据做个分析"
Agent 发现过程:
1. 语义解析: 需要「数据读取」+「数据分析」两类能力
2. Registry 查询: 找到具备 read-insights 的 Agent A 和具备 analyze-data 的 Agent B
3. 工具匹配: Agent A 绑定的 MCP 工具是否有权限访问理赔数据库?
4. 策略校验: 跨部门数据访问是否需要审批? 是否需要最小权限拆分?
5. 返回候选集: [Agent A → 读数据, Agent B → 分析] 或 [Agent C(全能) → 一次完成]
这种 Discovery 本质上是「能力路由」：把一个复杂任务分解成能力需求，再路由给具备对应能力的 Agent。这比微服务的地址发现复杂一个数量级，因为它引入了语义匹配、权限校验、任务规划三个层次。
Agent Discovery 的三种模式：
| 模式 | 适用场景 | 类比 |
|---|---|---|
| 点对点 | 少量固定 Agent，手动配置 | 微服务时代的静态配置 |
| 中心化 Registry 查询 | 中规模，Agent 类型固定 | Consul/DNS |
| 语义化能力路由 | 大规模，动态创建 Agent | 新一代 AI Gateway |
大规模场景下，我强烈建议走第三种。这和我之前写的「MCP Gateway 横向评测」里观察到的趋势一致：网关层正在从「协议转换」进化到「智能路由」。
Agent Mesh：治理 Agent 的基础设施层
Registry 和 Discovery 解决了「Agent 怎么被找到」，但大规模 Agent 部署还需要解决「Agent 怎么被治理」。这一整层，就是 Agent Mesh。
Agent Mesh 由四部分组成：
┌─────────────────────────────────────────────┐
│ Agent Mesh │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ 网关层 │ │ 运行时层 │ │ 观测层 │ │
│ │ Gateway │ │ Runtime │ │ Observability│ │
│ │ 认证/授权 │ │ 沙箱/隔离 │ │ 链路追踪/指标 │ │
│ │ 路由/限流 │ │ 状态管理 │ │ 审计/成本 │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
│ ┌─────────────────────────────────────────┐ │
│ │ 安全策略层 (Policy) │ │
│ │ 数据脱敏 / 工具白名单 / 权限最小化 │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
▲ ▲ ▲
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ Agent A │ │ Agent B │ │ Agent C │
└─────────┘ └─────────┘ └─────────┘
1. 网关层（Gateway）：Agent 的「前门」
我在 MCPZERO 里做的事情，本质上就是 Agent Mesh 的网关层：所有 Agent 对外部工具和服务的调用，都经过网关统一鉴权、限流、审计。
网关层解决三个问题：
- 认证授权：哪个 Agent 有资格调用哪个工具？权限粒度到 API 级别
- 流量控制：Agent 并发调用工具时，防止打爆下游服务
- 协议转换：MCP、A2A、HTTP、内部 RPC 之间的统一转换
2. 运行时层（Runtime）：Agent 的「沙箱」
Agent 不是普通进程——它可能长驻、可能访问敏感数据、可能执行危险操作。运行时层提供隔离和生命周期管理。
我之前写的「Agent 安全攻击面全景」里强调过：Agent 最大的安全风险不在模型，而在工具调用链。运行时层的沙箱隔离、eBPF 观测、异常检测，是 ClawGuard 在做的事——把 Agent 的行为约束在策略边界内。
3. 观测层（Observability）：Agent 的「监控室」
微服务的可观测性指标是延迟、错误率、饱和度。Agent 的观测指标完全不同：
传统微服务指标: Agent 特有指标:
latency token 消耗 / 成本
error rate 工具调用成功率
saturation LLM 幻觉率
throughput 任务完成率
规划-执行偏差度
级联失败传播
Agent 的「故障」不是宕机，是「看似成功实则错误」。一个 Agent 生成了看似合理的分析报告但数据来源错了，这在传统监控里根本不会报警。Agent 观测层需要新的信号：工具调用链路、决策可解释性、输出置信度。
4. 策略层（Policy）：Agent 的「交通规则」
最后，也是最重要的——Agent Mesh 的安全策略层。它把前面三层串起来：
策略示例:
- 财务类 Agent 只能调用只读工具，禁止写操作
- 涉及用户 PII 的请求必须脱敏后才能进入模型上下文
- Agent 之间的调用链深度不能超过 3 层（防止级联失控）
- 高风险操作（付款、删除、外发）需要人工审批闸门
这层正是我做 MCPZERO + ClawGuard 全栈安全的核心论证：网关层负责「谁能调用」，运行时层负责「调用时发生了什么」，策略层把两者统一成可执行的规则。
我们正在构建的 Agent 原生基础设施
说了这么多理论，回到实践。我在构建 MCPZERO（网关层）和 ClawGuard（运行时层）的过程中，验证了 Agent Mesh 的核心假设：
假设一：Agent 通信的安全不能靠 Agent 自己自觉。
Agent 调用工具就像人使用 API——需要身份、权限、审计。MCPZERO 把安全从「Agent 内部逻辑」抽离到「网关层」，所有工具调用统一经过网关。这和 Service Mesh 把通信安全从「业务代码」抽离到「Sidecar」是同一个模式。
假设二：Agent 的行为可观测是治理的前提。
ClawGuard 在运行时层用 eBPF 观测 Agent 的系统调用和工具访问，建立行为基线，检测异常。没有这层观测，Agent Mesh 的策略层就是空转——你无法知道策略有没有被执行。
假设三：Agent Mesh 最终会像 Service Mesh 一样「下沉」为基础设施。
十年前没人想到 Istio 会成为云原生标配。今天的 Agent 基础设施也在走同样的路：先是各团队自建，然后是开源协议统一（MCP/A2A），最后是平台级产品化。
写在最后：Agent 时代的「下一代基础设施」
让我用一句话总结这个四篇系列：
编排模式决定「谁指挥谁」，通信层决定「谁跟谁怎么说话」，演进路径决定「什么时候该拆」，而 Agent Mesh 决定「拆完之后怎么治理」。
前三篇是「怎么搭」，这一篇是「搭起来之后怎么活下来」。
展望未来，Agent 原生基础设施会沿着三个方向演进：
- 从协议到平台：MCP 和 A2A 解决了「连通性」，接下来是「治理」——Agent Registry、能力路由、策略引擎会产品化
- 从单租户到多租户：当 Agent 不再是某个团队的内部工具，而是跨部门、跨公司的协作单元，Agent Mesh 必须支持租户隔离和跨组织协作
- 从安全到信任：最终 Agent Mesh 要解决的不只是「能不能调用」，而是「该不该信任」——信任评估、行为信誉、审计留痕会成为标配
我在 MCPZERO 和 ClawGuard 上做的事，只是 Agent Mesh 的冰山一角。但方向已经清晰：Agent 即服务，服务需要 Mesh，Mesh 会成为新的云原生基础设施。 下一个 Istio，正在 Agent 世界里孕育。