AI 云原生后端架构与智能服务网格治理：上下文与工具如何分工

大模型接入云原生微服务体系后，很多团队习惯直接把模型 API 当作普通 HTTP 接口挂在 Envoy 或 Istio 后面。跑了两个月发现 Sidecar 经常频繁触发 OOM Killer，或者 Tool Call 调用的内部微服务因为 Gateway 超时设置不当产生大量悬挂连接。

智能服务网格治理的核心，在于彻底厘清“上下文（Context）”与“工具（Tools/Plugins）”在控制面和数据面的责任边界。

Envoy 内存抖动与超大 Payload 传输控制

传统 RPC 调用的 Request Body 通常在几十 KB 以内。但在 LLM Gateway 场景下，多轮对话上下文（Context Window）动辄包含数万 Token，序列化后的 JSON 字符串经常突破 2MB 到 5MB。

当这些大 Payload 密集穿过 Envoy Sidecar 时，默认的 Buffer 机制会迅速撑爆容器内存 limits。

flowchart TD Client[客户端 Client] -->|1. 发送 Request 包含 4MB Context| EnvoyGateway[Envoy AI Gateway] EnvoyGateway -->|2. 检查 Buffer Limit| BufferCheck{是否超过 1MB Buffer?} BufferCheck -- 是 -->|3. 触发 Stream Pause 暂停读取| LocalPause[暂停 Socket 读事件] BufferCheck -- 否 -->|4. 转发上游| ModelServer[LLM 服务端 / vLLM Engine] EnvoyGateway -->|5. 分流 Tool Call 契约| ToolRouter[Tool Execution Gateway] ToolRouter -->|6. 执行微服务调用| InternalMicroservice[内部业务微服务] InternalMicroservice -->|7. 结果返回| ToolRouter ToolRouter -->|8. 工具执行结果回填上下文| EnvoyGateway

解决这个问题的关键，是在 EnvoyFilter 中显式关闭无意义的 Full-Body Buffering，改用 Streaming Direct Pipe。同时在 Gateway 入口处将“历史会话上下文”与“当前 Turn 增量输入”分离。

历史上下文不应当每次都由 Client 穿透整个 Mesh 发送，而应保留在近 Model 侧的 Context Cache 服务（如 Redis / Memcached 集中缓存）中，Gateway 仅校验context_id和摘要 Diff。

Tool Execution 与 Proxy Layer 的契约隔离

很多人在设计 Agent 架构时，把大模型返回的tool_callsJSON 直接透传给前端，由前端去调业务 API；或者在 Envoy 内部写 Lua / Wasm 脚本去直接反射调用下游 Go/Java 微服务。

这两种方案在工程上都是灾难。前者泄漏了内部微服务拓扑与敏感参数，后者让 Envoy 承担了复杂的业务数据组装与重试逻辑，失去了 Proxy 的纯粹性。

标准的工程分工应当是：

1. 服务网格（Envoy AI Gateway）：只做协议转换（如 SSE 转 gRPC）、Token 限流（Token Bucket based on Prompt+Completion Count）、鉴权与超时断开。
2. 工具执行引擎（Tool Router / Executor）：独立部署的微服务，定义严格的 OpenDefinition 格式契约。LLM 吐出工具名称和 JSON 参数后，发送给 Tool Router，由 Tool Router 校验参数 Schema 并发起 RPC。

{ "tool_call_id": "call_982341029", "function_name": "query_user_account", "strict_schema_validation": true, "arguments": { "user_id": "USR-99021", "query_type": "BALANCE" }, "execution_policy": { "timeout_ms": 1500, "retry_count": 1, "circuit_breaker_ref": "user-service-cb" } }

Tool Router 应具备 Schema 校验强断言机制。若 LLM 幻觉生成的参数缺少必填字段，应当在 Tool Router 这一层直接截断并返回结构化修复提示（Self-Correction Prompt），而不是把非法参数直接送入下游微服务造成 DB 查询报错。

流式响应断连与 HTTP 状态码映射

在 SSE（Server-Sent Events）流式传输过程中，HTTP 响应头200 OK已经在首个 Chunk 发送时写入了 Socket。如果模型在生成到第 500 个 Token 时发生内部推理崩溃、超内存或者下游 Tool 失败，网络层已经无法改变 HTTP 状态码。

工程上应引入流状态协议封装（Stream Chunk Protocol）。在 Chunk Data 内部定义标准状态语义：

package streaming import ( "encoding/json" "fmt" ) type EventType string const ( EventContent EventType = "content" EventToolCall EventType = "tool_call" EventError EventType = "error" EventEnd EventType = "end" ) type StreamChunk struct { Event EventType `json:"event"` Sequence int64 `json:"seq"` Payload interface{} `json:"payload,omitempty"` ErrDetail *ErrorMeta `json:"error,omitempty"` } type ErrorMeta struct { Code string `json:"code"` Message string `json:"message"` Retryable bool `json:"retryable"` } func FormatErrorChunk(seq int64, errCode string, msg string, canRetry bool) string { chunk := StreamChunk{ Event: EventError, Sequence: seq, ErrDetail: &ErrorMeta{ Code: errCode, Message: msg, Retryable: canRetry, }, } bytes, _ := json.Marshal(chunk) return fmt.Sprintf("data: %s\n\n", string(bytes)) }

当模型推理或者工具链中途异常时，Mesh 层的 Envoy 代理不会强制关闭 TCP 链接（防止前端触发全局异常弹窗），而是由 Gateway 注入最后一个带有EventError的特制 Chunk，前端 SDK 捕获该事件后做针对性的 UI 降级或局部重试。

网格治理层的 Token Bucket 限流策略

常规的 QPS 限流在 AI 网格中失效了。一个请求可能只耗费 10 个 Token，另一个请求可能消耗 8000 个 Token 并触发 3 次 Tool Call。

应在 Envoy Sidecar 中部署基于 Token 数量的动态配额控制器：

apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: ai-token-rate-limit namespace: istio-system spec: workloadSelector: labels: app: llm-gateway configPatches: - applyTo: HTTP_FILTER match: context: SIDECAR_INBOUND listener: filterChain: filter: name: "envoy.filters.network.http_connection_manager" patch: operation: INSERT_BEFORE value: name: envoy.filters.http.local_ratelimit typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit stat_prefix: ai_token_limit token_bucket: max_tokens: 100000 tokens_per_fill: 20000 fill_interval: 60s filter_enabled: default_value: numerator: 100 denominator: HUNDRED

在网格数据面，根据 Token 估算算法动态扣减 Token 配额。如果客户端请求的 Prompt 超过了租户剩余的 TPM（Tokens Per Minute），在 Gateway 侧直接返回429 Too Many Requests，并在 Header 中附带X-RateLimit-Reset-Tokens。

生产落地的运维观察点

排查 AI 服务网格故障时，日志记录习惯需要调整。把注意力从单纯的响应延迟（Latency），转向以下三个指标：

第一个是TTFT（Time to First Token）：首字延迟反映了 Mesh 建立连接、发送 Prompt 及 Gateway 鉴权的开销。若 TTFT 很高但后续 Chunk 很快，瓶颈通常在 Envoy 的 Buffer 设置或 upstream HTTP/2 connection pool 设置上。

第二个是Tool Loop Count：单个 Request 内触发的 Tool 迭代次数。如果某类请求的 Tool Loop 平均超过 5 次，说明 Tool Router 的 Schema 描述模糊，导致 LLM 陷入自我修正死循环。

第三个是Context Chunk Dropped Ratio：网格因为超时或客户端断开而丢弃的生成中 Token 比例。通过在这个维度配置 Alerting，能第一时间定位到线上上游网络抖动与无用算力浪费。