多智能体系统上线后，怎样把一次任务看完整

多智能体系统上线后怎样把一次任务看完整1. 非确定性节点拓扑与线上故障观测痛点在分布式 AI Agent 架构与多 Agent 协作系统场景中当底层 LLM 异步回调挂起或长链条调用发生堵塞时节点执行耗时会显著飙升甚至导致入口网关触发 504 Gateway Timeout 超时。由于大模型LLM在推理和工具调用Tool Calling过程中天然具备非确定性Nondeterminism传统微服务的指标监控手段往往难以精准定位瓶颈。在实际生产场景中即使底层数据库与缓存连接池处于正常负载如 CPU 使用率维持在 15% 以下多 Agent 之间的交互链条仍可能因为某一个 Agent 节点在处理“查询订单发票并申请退款”等复合任务时在中间阶段静默挂起。传统日志检索系统往往仅能捕获[INFO] Agent task started等简单启动日志无法直观反映模型是否已返回结果、是否陷入无限重试死循环、或是否因上下文Context过长导致 Token 消费激增。因此必须构建一套包含 Agent 内部状态演进、Tool Calling 参数打标、Token 消耗以及跨 Agent 上下文透传的统一可观测性治理方案。2. 三维拓扑绘制Token 消耗、Agent 节点状态与 TraceId 贯穿设计持续观察多 Agent 系统在生产环境的运行表现需要将可观测性聚焦到三个核心维度第一是状态演进维度。Agent 的思考链Thought、规划步骤Plan和工具调用Action本质上是一个有限状态机。如果 Agent 陷入死循环必须在 Trace 的 Span 节点中记录当前的 Loop 计数器。一旦超过预设阈值状态机必须强制熔断。第二是资源消耗维度。模型调用的 Prompt Token 和 Completion Token 直接关联系统运行成本。在链路追踪中将 Token 消耗绑定至具体的 Trace 节点有助于精准监控各 Agent 模块的资源开销分布。第三是跨节点上下文透传Context Propagation。多 Agent 协作依赖 RPC 或 HTTP 协议通信。主控 Agent 生成的traceparentHeader需要完整注入到下游 Agent 的 Prompt 上下文与网络请求头中。Trace 节点按照颗粒度可以切分为三类Session Span代表用户发起的完整会话周期。Agent Run Span代表单个 Agent 从接收任务到给出结论的完整生命周期。Tool Call Span代表 Agent 实际发起 HTTP/gRPC 调用或模型 Inference 的底层操作。3. 生产级 Go 观测层实现封装 Multi-Agent Context 与 OTel 追踪器以下为一套基于 Go 语言与 OpenTelemetry 实现的埋点封装方案。该实现支持透传 Trace 上下文并在 Span 中对 Token 消耗与工具调用进行结构化打标package observability import ( context fmt time go.opentelemetry.io/otel go.opentelemetry.io/otel/attribute go.opentelemetry.io/otel/codes go.opentelemetry.io/otel/trace ) const TracerName agent.collaborative.system type AgentMetrics struct { PromptTokens int CompletionTokens int ModelName string LoopCount int } type AgentObservability struct { tracer trace.Tracer } func NewAgentObservability() *AgentObservability { return AgentObservability{ tracer: otel.Tracer(TracerName), } } // StartAgentSpan 开启单个 Agent 节点调用的 Trace func (ao *AgentObservability) StartAgentSpan(ctx context.Context, agentID, agentRole string) (context.Context, trace.Span) { ctx, span : ao.tracer.Start(ctx, fmt.Sprintf(AgentRun:%s, agentRole), trace.WithSpanKind(trace.SpanKindInternal), trace.WithAttributes( attribute.String(agent.id, agentID), attribute.String(agent.role, agentRole), ), ) return ctx, span } // RecordToolCall 记录 Agent 内部 Tool Calling 的详细上下文 func (ao *AgentObservability) RecordToolCall(ctx context.Context, toolName string, inputJSON string, fn func(context.Context) (string, error)) (string, error) { ctx, span : ao.tracer.Start(ctx, fmt.Sprintf(ToolCall:%s, toolName), trace.WithSpanKind(trace.SpanKindClient), trace.WithAttributes( attribute.String(tool.name, toolName), attribute.String(tool.input, inputJSON), ), ) defer span.End() startTime : time.Now() output, err : fn(ctx) duration : time.Since(startTime) span.SetAttributes( attribute.Int64(tool.duration_ms, duration.Milliseconds()), ) if err ! nil { span.RecordError(err) span.SetStatus(codes.Error, fmt.Sprintf(Tool execution failed: %v, err)) return , err } span.SetAttributes(attribute.String(tool.output_summary, truncate(output, 200))) span.SetStatus(codes.Ok, success) return output, nil } // EndAgentSpan 结束 Agent 节点并上报 Token 消耗指标 func (ao *AgentObservability) EndAgentSpan(span trace.Span, metrics AgentMetrics, err error) { if span nil { return } defer span.End() span.SetAttributes( attribute.String(llm.model, metrics.ModelName), attribute.Int(llm.prompt_tokens, metrics.PromptTokens), attribute.Int(llm.completion_tokens, metrics.CompletionTokens), attribute.Int(llm.total_tokens, metrics.PromptTokensmetrics.CompletionTokens), attribute.Int(agent.loop_count, metrics.LoopCount), ) if err ! nil { span.RecordError(err) span.SetStatus(codes.Error, err.Error()) } else { span.SetStatus(codes.Ok, Agent task completed successfully) } } func truncate(s string, maxLen int) string { if len(s) maxLen { return s[:maxLen] ... } return s }4. 压测分析与链路定位在 Prometheus 与 Jaeger 中分析循环重试完成埋点封装后需要对多 Agent 系统实施压力测试与链路定位。使用 Vegeta 模拟并发 100 QPS 冲击多 Agent 入口网关并在 Jaeger UI 中分析高延迟请求的 Trace 拓扑。分析表明在异常链路中AgentRun:FinanceAgent节点并非卡顿在网络层而是在 30 秒内连续触发了 12 次ToolCall:CheckAccount的子 Span。分析子 Span 的tool.input属性可以发现模型生成的 JSON 字段中user_id误填为空字符串。因上游服务未校验输入 Schema返回了 400 Bad Request而 Agent 内部的 ReAct 决策逻辑接收到错误响应后触发重试进而导致系统陷入重复调用循环。结合 Prometheus 监控可配置以下三组核心查询指标# 1. 单请求最大 Loop 深度分布用于识别超过阈值的异常循环 histogram_quantile(0.99, sum(rate(agent_loop_count_bucket[5m])) by (le, agent_role)) # 2. Token 吞吐速率比实时监控各 Agent 成本消费梯度 sum(rate(agent_llm_total_tokens_total[5m])) by (agent_role, llm_model) # 3. Tool Calling 异常率统计 sum(rate(otel_span_status_code{status_codeError, span_name~ToolCall:.*}[5m])) / sum(rate(otel_span_status_code{span_name~ToolCall:.*}[5m]))通过在 Grafana 中联动上述指标可以高效甄别参数校验失效节点以及引起延迟拉长或资源倾斜的具体工具服务。5. 可观测性防线落地日志摘要与采样控制策略在生产环境中落地可观测性方案时需避免直接将大模型返回的全量上下文写入日志。全量日志存储不仅会导致存储开销剧增还可能引发敏感数据合规风险。工程实践中的治理边界包括日志层保留结构化摘要仅存储TraceId、AgentID、State、TokenCount及ErrorSummary。模型原始 Payload 仅保留在内存 Buffer 中。Span 分级采样策略针对状态为codes.Ok的正常请求实施 5% 概率采样当捕获到codes.Error或loop_count 3的异常节点时开启 100% 全量 Trace 留存。熔断降级机制结合 OpenTelemetry 的 Span 指标设置自动告警与熔断阈值。当单个 Agent 的 P95 延时超过 8 秒且 Token 消费速率异常增长时系统自动切断多 Agent 复杂协作逻辑降级为确定性的规则引擎进行处理。将非确定性的 Agent 状态演进接入确定性的 OpenTelemetry 追踪框架能够显著提高系统的可维护性与稳定性。