Service Mesh 跑 Agent，网络超时和业务重试要分开
当 Service Mesh 遇上 Agent 多轮工具调用，长连接断开的主要原因分析
Agent 工具调用经过 Istio 后，Envoy 能处理传输超时、mTLS 和路由，却不知道一次工具调用是否已经产生业务副作用。网络层与业务状态机不分工，断连后的自动重试很容易造成重复写入。
Agent 编排通常会依次查询数据库、计算服务和向量检索。实际生效的 stream_idle_timeout、路由超时与客户端 Deadline 只要有一个先到，就可能取消连接。排查时从 Envoy 配置 dump 和 Trace 对齐这些时间点，不使用构造日志冒充现场。
连接取消并不能说明工具有没有产生副作用。应用层要用任务 ID 和步骤 ID 查询状态：尚未开始可以重试，执行中先查询，已成功则复用结果，状态不明进入对账或人工处置。
在服务网格落地实践中，必须清晰界定应用层（负责 Context 状态一致性与业务重试）与网格基础设施层（负责网络传输可靠性与拓扑路由）的职责边界。
Envoy 长连接超时与 Agent 状态一致性损耗算式
长连接频繁断开会导致系统吞吐下降与无效重试增加，可建立基于超时概率与状态恢复开销的损耗计算模型：
$$Retry\\ Overhead \\approx R_{request} \\times P(T_{tool} > T_{idle}) \\times (C_{compute} + C_{tokens})$$
$$State\\ Consistency\\ Index = \\frac{N_{atomic_success}}{N_{total_requests}}$$
用当前 Trace 统计工具耗时分布 $T_{tool}$，从生效配置读取空闲超时 $T_{idle}$，即可计算超时比例 $P(T_{tool}>T_{idle})$。再把发生超时的任务分为未执行、执行中、已成功和状态未知四类，分别统计重试 Token、重复副作用与恢复耗时。这里不预设请求量、错误比例或 P99 变化。
配置 Envoy EnvoyFilter 调整超时参数与实现幂等状态机
解决网格层与工具长连接冲突，工程设计需要在网格侧配置 EnvoyFilter 针对特定 Agent 服务调整超时限制；同时在应用层实现带版本校验的状态机。在 EnvoyFilter 配置中声明防错规则：
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: extend-agent-tool-timeout
namespace: istio-system
spec:
workloadSelector:
labels:
app: agent-orchestrator
configPatches:
– applyTo: HTTP_FILTER
match:
context: SIDECAR_OUTBOUND
listener:
filterChain:
filter:
name: "envoy.filters.network.http_connection_manager"
patch:
operation: MERGE
value:
name: "envoy.filters.network.http_connection_manager"
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stream_idle_timeout: ${STREAM_IDLE_TIMEOUT}
request_timeout: ${REQUEST_TIMEOUT}
在 Agent 应用程序侧，必须配合事务状态机与上下文传参协议（通过 HTTP Header 透传 x-agent-context-id 与 x-agent-step-id），基于 Go 语言实现幂等工具调用包装器：
package orchestrator
import (
"context"
"fmt"
"time"
)
type ToolExecutor struct {
stateStore StateRepository
}
func (e *ToolExecutor) ExecuteToolWithState(ctx context.Context, contextID string, stepID string, lockTTL time.Duration, toolFunc func() error) error {
// 校验状态机版本，防止并发重复执行
locked, err := e.stateStore.AcquireLock(ctx, contextID, stepID, lockTTL)
if err != nil || !locked {
return fmt.Errorf("state conflict: step %s already processing or completed", stepID)
}
defer e.stateStore.ReleaseLock(ctx, contextID, stepID)
// 执行工具逻辑
if err := toolFunc(); err != nil {
e.stateStore.MarkStepFailed(ctx, contextID, stepID, err.Error())
return err
}
return e.stateStore.MarkStepSuccess(ctx, contextID, stepID)
}
锁 TTL 由调用方根据任务预算传入，并在长任务执行时续租；固定 TTL 可能在任务尚未结束时失效，反而造成并发重复执行。
建立 Service Mesh 下 Agent 架构最佳实践
为保证 Agent 复杂工具链在 Service Mesh 环境中的稳定运行，研发团队需遵循如下治理规范：
网格超时要与客户端 Deadline 对齐，业务层则靠幂等键和状态查询恢复。两层各自负责确定的事情，取消请求才不会自动变成重复写入。
