建构 AI Agent 应用——生产环境中的监控

无论你是产品负责人、机器学习（ML）工程师，还是站点可靠性工程师（SRE），一旦代理（agent）进入生产环境，你就必须能看见它们在做什么、为什么这么做。把代理系统上线只是“半程”；真正的挑战，从它们在动态、不可预测、且高风险的环境中运行那一刻开始。监控是你向现实学习的方式——它让你在故障升级之前捕捉到问题、在用户察觉之前识别回归，并依据真实世界信号去调整系统。

与传统软件不同，Agent 的行为具有概率性。它们依赖基础模型，串联工具，并要应对无界的用户输入。你不可能为每个场景写出穷尽的测试——这就是为什么监控会成为已部署代理基础设施的“神经系统” 。

监控不仅是发现问题。它是紧密反馈环的脊梁，加速学习与迭代。监控做得好的团队，学得更快、发布更安全，并在每一次部署中提升可靠性。

本章聚焦开源监控。虽然市面上有出色的商用平台（如 Arize AX、Langfuse、WhyLabs），这里我们更关注可自托管且可自由扩展的工具。参考技术栈包括：

• OpenTelemetry：对 Agent 工作流进行埋点/插桩
• Loki：日志聚合与搜索
• Tempo：分布式追踪
• Grafana：可视化、告警与仪表盘

我们将展示如何把这些工具与基于 LangGraph 的 Agent 系统集成，随后说明这些部件如何拼合成一个闭环反馈系统，缩短“观察→改进”的距离。

监控是学习的方式（Monitoring Is How You Learn）

要做到主动维护与系统适配，必须理解 Agent 失败的根因——从软件缺陷、基础模型波动，到架构极限。每一类问题都需要定向的检测、分析与修复，以维持生产稳定。

最优秀的 Agent 系统会通过反馈不断改进。传统监控往往在崩溃或吞吐下降时被动响应；但对 Agent 而言，监控是基础：它揭示概率行为中的涌现问题，并在不确定性中指引开发。

Agent 的失败往往很隐蔽——某个工具表面成功却产生连锁错误；某段 LLM 输出流利但误导；一个计划部分奏效却未达成目标。这些不匹配很少让系统直接崩溃；监控必须快速暴露它们，使生产可观测性成为必需。

失败不只是事故，也是测试用例。每次 Agent 在生产中踩坑，该场景都应被捕获并转化为回归测试。成功亦然：当 Agent 妥善处理复杂个案，该轨迹（trace）就应成为值得保留的黄金路径。把失败与成功样本双向导出到测试套件，你就拥有一个反映真实世界的活体 CI/CD 语料。这种做法将监控“左移”：更早在开发中发现问题，并确保新版本持续对照生产复杂度得到验证。

在监控概率系统时，一个关键难点是区分真正的“失败”（需要修复的系统性问题）与期望内的变化（非确定性导致的可接受差异）。可以用一个简单决策树来引导：

1. 从输出开始——是否满足成功标准（如评测分 > 0.8）？若是，持续监控趋势，无需动作。
2. 若否，检查可复现性（重跑 3–5 次；若失败率 > 80%，则为系统性缺陷，交工程修复）。
3. 若不可复现，评估置信度/方差（如 LLM 评分 > 0.7、与基线的 KL 散度 < 0.2）。若在阈内，则属预期波动（记录以监测漂移）；若超阈，判作异常失败（如输入漂移，经 PSI > 0.1 触发再训练或新增防护）。
   将此流程图落地到 Grafana 等工具，有助于不过度反应噪声，同时及早捕捉真实退化。

有效监控既覆盖基础设施信号（延迟、错误率、CPU 等），也覆盖语义行为（意图把握、工具选择、幻觉、任务中途放弃等）。“理解了用户意图吗？”“选对工具了吗？”“是否产生了幻觉内容？”“用户是否半途而废？”——这些是传统监控难以回答、却对 Agent 的可信度与有用性至关重要的问题。

构建分层反馈环：为运行时事件（工具调用、生成、回退）打上上下文，实时流向 Loki（日志） 、Tempo（追踪） 、Grafana（可视化/告警） ；并通过外部评审器实时加入评测信号（如幻觉分、漂移指标）。

值得强调的是，这一切可以也应该融入你的现有可观测性管线。同一套 Prometheus 监控服务健康，也能跟踪Agent 成功率；SRE 使用的 Grafana 仪表盘也完全可以展示语义错误率、模型延迟分布、工具使用曲线。无需单独搭一套栈；Agent 与其他关键服务一样，需要同等的严谨与可见性。

当然，可观测性数据常含敏感内容。日志可能包含用户消息、工具入参、或者中间的 LLM 生成。为合规与隐私，团队应配置隔离的监控集群与严格的 RBAC；将敏感数据路由到加密存储且有访问审计的后端，以保证调试/性能分析可行且不损害信任或合规义务。业界常规还包括在导出前对 PII 做涂抹/哈希/脱敏。OpenTelemetry 在 span 导出时提供数据清洗钩子，便于细粒度控制出边界的数据。

归根结底，监控是将度量转化为行动——帮助团队发现关键问题并快速响应。接下来我们会展示如何用开源工具搭起这一闭环，在真实环境中加速开发、增强稳健性与可靠性。

先定义该“看什么”（选择度量）

在讨论插桩细节之前，先明确你要观察什么。有效监控始于选择正确的指标——不仅判断系统是否“活着”，更要判断它是否按预期工作。

表 10-1：指标分类法（按抽象层次组织）
为你要采集/可视化/告警的内容提供一份实用导引。

指标	目的	示例动作
基础设施
CPU/内存使用	监测系统健康与扩容压力	自动扩容或优化高内存工具
存活/可用性	跟踪服务可用性与故障恢复	触发事件响应
请求延迟（P50/P95/P99）	确保负载下的响应性	调优缓存或重试策略
工作流层
任务成功率	判断 Agent 完成预期工作流的频率	排查失败或更新提示词
Token 使用量	度量工作流层面的 Token 消耗	异常增减提示问题
工具调用 成功/失败率	发现集成退化或工具误用	修补封装或自动回退
工具使用 触发限流	追踪一定窗口内工具调用超限的实例	调整限额或调用频率
重试频率	识别计划或工具的不稳定性	去抖重试或优化规划逻辑
回退频率	暴露主路径失败	增强鲁棒性或升级到人工
输出质量
Token 使用（输入/输出）	追踪冗长度、成本与生成效率	精简长提示或切换模型档位
幻觉指标	度量生成内容的语义准确度	引入检索落地或 LLM 自评
嵌入与基线的漂移	发现用户输入或任务表述的分布变化	调整工作流或微调模型
用户反馈
复询/改写率	衡量是否“一次就懂”	改进意图分类
任务放弃率	识别让用户困惑或挫败的流程	简化流程或加入澄清提示
显式评分（赞/踩）	收集系统有用性的定性评估	用于评审与评测样本分流

上述各类指标都可通过 OpenTelemetry 记录，经 Prometheus/Loki 聚合，在 Grafana 可视化并（必要时）与 Tempo 追踪关联跳转。目标不是“采一切”，而是采集足以识别有意义变化的信号，并以支持快速诊断与持续改进的方式进行。

监控技术栈（Monitoring Stacks）

选择合适的监控方案，会直接加速或拖慢你构建代理系统的节奏。可观测性不仅要覆盖传统的基础设施指标（如延迟、可用性），还要捕捉语义层面的洞察，例如幻觉率、工具有效性、以及用户输入分布的漂移。当前生态强调与 LangGraph、CrewAI、AutoGen 等框架无缝集成的开源工具，既支持分布式追踪、日志与告警，也能处理基础模型的概率性特征。许多公司已经部署了企业级的托管日志方案（如 Splunk、Datadog、New Relic），而基础模型或代理并不一定需要全新的一套监控系统。多数情况下，扩展你已有的栈更明智——利用其熟悉度、可扩展性与生态集成——除非你对面向基础模型原生评测或轻量自托管有强需求。下面几个等价的开源选项会逐一介绍其特性、集成方式与权衡，帮助你根据环境进行选择或适配。

Grafana + OpenTelemetry、Loki、Tempo

这套栈具有很强的可组合性，适合围绕代理构建定制化可观测性的团队。

安装与集成
在你的 LangGraph 应用中初始化 OpenTelemetry（OTel） ，导出 span（如工具调用、LLM 生成）与指标（如 token 使用）。日志经 Loki 做结构化查询，追踪进 Tempo 做端到端可视化；Grafana 统一拉取两者，建立把代理行为（如规划延迟）与系统健康相关联的看板。示例：用 OTel span 包裹一个 LangGraph 节点来跟踪 tool_recall 指标，并导出到 Tempo 以便查询失败会话。

关键特性

• 实时仪表板显示语义指标（如通过插件展示“幻觉分”）；
• 对重试激增等异常进行告警；
• 社区对 AI 扩展活跃（如 2025 Grafana 的 LLM 漂移检测插件）。
  可自托管、生产可扩展、开销较低。

权衡点

• 优点：灵活（组件可自由组合）、无厂商锁定；
• 缺点：多工具协同，需要分别运维 Loki/Tempo；对非基础设施团队学习曲线较陡。
  适合希望把现有基础监控扩展到代理场景的企业。

ELK 栈（Elasticsearch、Logstash/Fluentd、Kibana）

成熟方案，偏重强大的搜索与分析，常在既有企业部署基础上扩展到 AI 场景。

安装与集成
使用 OTel Collector 将代理追踪/日志发送到 Elasticsearch（可通过 Logstash 进行摄入）。Kibana 提供查询与仪表盘。对 LangGraph 的节点做结构化事件日志（如携带工具参数的 JSON），并利用 Elasticsearch 的 ML Jobs 做代理输出的异常检测。示例：查询“置信度 < 0.7 的幻觉事件”并与用户反馈关联。

关键特性

• 强大的全文检索与向量检索（适合对 LLM 输出做嵌入漂移检测）；
• 内置 ML 支持预测告警（如工具失败率的趋势预警）；
• 通过集群实现海量日志的可扩展性。

权衡点

• 优点：搜索/分析能力出众（提示词模糊匹配、长尾失败更易发现）、企业级扩展性强；
• 缺点：资源占用高（Elasticsearch 对内存敏感）、部署复杂（多服务）。
  适合已有 ELK 投资的团队，在不“从零开始”的前提下为代理引入语义日志。

Arize Phoenix

Phoenix 聚焦 LLM 追踪与评测，为现有环境提供面向调试的代理监控扩展。

安装与集成
使用 Phoenix 的 Python SDK 给 LangGraph 插桩（如对 LLM 调用做评测追踪），并支持 OTel 导出以便混合使用。示例：用自动评分器可视化代理 Trace（准确性/幻觉），并导出到 Notebook 做深入分析。

关键特性

• 带评测的结构化追踪（如 RAG 质量、幻觉检测）；
• 与 Jupyter 的良好集成；
• 2025 年增强了多代理协同相关度量。

权衡点

• 优点：对评测/调试高度友好，快速获得代理质量洞察；轻量，适合原型期；
• 缺点：聚焦追踪/评测，对全量日志/系统指标需配套其他工具；更偏开发/数据科学而非运维。
  适合 研究/ML 团队在企业托管栈旁补充代理洞察。

SigNoz

SigNoz 是 OTel 原生的一体化平台，把指标、追踪、日志整合在一个工具里，适合在轻量监控基础上做顺滑扩展。

安装与集成
SigNoz 直接摄入 OTel 数据，支持 Python（如 LangGraph）的自动化插桩。为代理步骤（如规划延迟）添加 span，通过其 UI 查询。示例：追踪多步骤代理流程，筛选 token_usage > 1000 的会话定位低效点，并用内置的 LLM 质量评估。

关键特性

• 内置AI 驱动洞察（如对代理 Trace 的异常检测）；
• 自定义LLM 指标看板（如提示词漂移）；
• 以 ClickHouse 为后端，轻量自托管、效率高。

权衡点

• 优点：部署更简单（单应用）、对小团队开销低、OTel 支持好并有 AI 扩展（如 2025 的幻觉自动打分）；
• 缺点：生态可扩展性略弱、可视化实用但不华丽。
  适合初创或 ML 聚焦团队在不重搭基础设施的前提下扩展监控。

Langfuse

Langfuse 专注基础模型与代理可观测性，便于在既有栈上叠加语义追踪。

安装与集成
通过 SDK 接入 LangGraph（例如用 Langfuse 的 tracer 包裹节点）。它会捕获提示词、输出与评测（可自定义如连贯性评分）。示例：记录完整会话、自动评估幻觉，并把 Trace 导出为回归测试样本。

关键特性

• LLM 原生指标（token 成本追踪、提示 A/B 测试）；
• 会话回放便于调试；
• 可自托管，支持 PostgreSQL 等数据库后端。

权衡点

• 优点：为代理/LLM量身打造（内置评测减少自研工作），开发者易上手、聚焦应用层洞察；
• 缺点：范围较窄（对 CPU 等基础设施指标较弱，需与 Prometheus 搭配）、在非 LLM 遥测方面的可扩展性有限。
  适合在不更换核心监控栈的情况下，为企业日志体系叠加代理特有能力。

小结：如果你已有成熟监控平台，优先扩展它来承载代理语义指标与LLM 特有评测；若需要自托管与高可定制性，Grafana + OTel + Loki + Tempo 与 ELK 都是稳妥之选；若强调评测/调试与快速洞察，看 Phoenix 与 Langfuse；若想要一体化轻量方案，选 SigNoz。关键不在“换不换栈”，而在于把语义可观测性纳入同一条生产级管线，让代理与传统服务共享统一的度量、追踪、告警与回归闭环。

选择合适的技术栈（Choosing the Right Stack）

这些开源技术栈都是可行的等价方案——首先评估你现有的部署。如果你已有企业托管的监控/日志方案，优先通过 OTel 插桩把代理信号接入现有栈；除非你需要 LLM 专属功能（如自动评测，倾向选 Langfuse/Phoenix）或高级搜索能力（倾向 ELK）。对于全新项目，Grafana 或 SigNoz 能提供广覆盖。依据团队经验、数据量级与集成需求来选择——很多方案可以混合（例如 OTel 同时输出到多个后端）。表 10-2给出了这些权衡的一览。

表 10-2. 监控与可观测性技术栈对比（Comparison of monitoring and observability stacks）

栈	关键强项（Key strength）	最佳适用（Best for）	相对 Grafana 的权衡（Trade-off vs Grafana）
Grafana + Loki/Tempo	组合性与可视化	企业运维	需要管理的组件更多
ELK Stack	高级搜索/分析	大规模日志	资源占用更高
Phoenix	追踪与调试	开发迭代	生产规模有限
SigNoz	一体化且轻量	初创/ML 团队	可扩展性较弱
Langfuse	面向基础模型/代理的专属评测	语义监控	基础设施覆盖更窄

虽然可观测性生态提供了多种强有力的选项——在可扩展性、易用性或 LLM 专属特性上各有侧重——这种“百花齐放”推动了创新，也确保团队无论是扩展企业既有栈还是从零开始，都能找到合适方案。接下来示例章节将聚焦 OTel + Grafana、Loki、Tempo：这一组合具有高可组合性、开源、广泛采用，并能与 LangGraph 等代理框架无缝集成，便于在无厂商锁定的前提下演示核心概念。选定栈之后，下一步就是插桩——将遥测直接嵌入代理运行时以捕获有意义的信号，详见下一节。

OTel 插桩（OTel Instrumentation）

构建有效监控闭环的第一步是插桩。如果没有高质量信号直接嵌入代理运行时，你基本上是在“盲飞”。OpenTelemetry（OTel）为追踪、指标、日志提供了结构化、可互操作的基础，并且能很好地与基于 LangGraph 的代理系统集成。

LangGraph 以异步函数调用图组织。图中的每个节点代表代理工作流中的一个功能步骤——例如规划、调用工具或用 LLM 生成响应。因为这些步骤已被清晰地隔离并显式声明，所以很容易用 OTel span 为每个节点插桩。这些 span 形成结构化的追踪，记录每个步骤开始/结束时间、目标与表现。

对每个节点，建议在函数开头启动一个 span，并添加相关元数据。例如在工具调用节点，记录工具名、具体方法、响应时延、成功/失败状态以及错误码。在 LLM 生成节点，可以记录提示词标识、token 计数、模型延迟、以及幻觉风险或置信度。

这种插桩不需要大规模改架构。用 OTel Python SDK 在启动时初始化一次，随后通过上下文管理器创建/关闭 span。分布式追踪上下文会在异步调用链中自动传播，即便在复杂、分支的代理流程里，也能轻松关联端到端行为。下面是为一个 LangGraph 节点包裹 span 的简化示例：

from opentelemetry import trace
tracer = trace.get_tracer("agent")

async def call_tool_node(context):
    with tracer.start_as_current_span("call_tool", attributes={
        "tool": context.tool_name,
        "input_tokens": context.token_usage.input,
        "output_tokens": context.token_usage.output,
    }):
        result = await call_tool(context)
        return result

Span 可包含事件（如触发回退/重试）、子 span（测量下游 API 调用），并在异常时自动打上错误标签。这些追踪会实时导出到 Tempo/Jaeger，并在 Grafana 中与日志和指标并列可视化。

除了追踪，OTel 还能发出结构化日志与运行时指标。例如，记录某工具的调用次数、某规划节点的平均响应时间、或各模型版本的失败任务占比。这些指标对于构建看板与告警极为重要，可用于跟踪长期表现并及早发现退化。

插桩要把握粒度：信息太多会变噪声，太少又难以定位根因。关键是在每步附上恰到好处的上下文——比如请求 ID、会话元数据、代理配置、技能名、评测信号——以便出问题时，证据链连贯、完整、易检索。

Tempo 作为追踪后端：你在 LangGraph 中插桩的每个 span（工具调用、规划生成、回退等）都会进入一条分布式追踪。Tempo 以高扩展方式存储，并支持深度查询：例如筛选“规划步骤时长 > 1.5s”的追踪，或查找某工具以特定错误码失败的所有请求——这对只在真实多步执行中暴露的细微问题尤为有效。

Loki 则是日志聚合层：捕获来自整个代理基础设施的结构化日志（常为 JSON）。每个 LangGraph 节点在执行期间都能发出结构化事件：收到用户查询、调用工具、LLM 输出含糊、触发回退路径等。日志带上 span/trace ID 便于日志↔追踪的会话级关联。若需要全文检索、更强 RBAC 或更高吞吐，可考虑 Elasticsearch 或商用品（如 Datadog logs、Honeycomb）。

Grafana 将以上数据源汇总于同一视图。你可以在其中并排探索 Loki 的日志与 Tempo 的追踪，构建实时面板、下钻单次请求、并将日志与性能指标交叉关联。同时可以配置自定义告警规则：比如当某代理的错误率超阈，或某工具的响应延迟超过界限时触发告警。

综上，OTel + Tempo + Loki + Grafana 组成了一套面向代理系统的完整开源可观测性栈：支持深度行为审查、快速根因定位、历史趋势评估与前瞻异常检测。这种整合将原始遥测转化为可运营情报，再把情报转化为开发加速器，为实时调试、趋势分析与持续学习提供基石，助力智能代理安全、可扩展地运行在生产环境。

可视化与告警（Visualization and Alerting）

当你的 LangGraph 代理完成 OTel 插桩，并开始把日志/追踪流入 Loki/Tempo 后，最后也是最具影响力的一层就是 Grafana 的可视化与告警。Grafana 不只是“做看板”的——它是可观测性的运营前端，在这里信号变故事、指标变行动。

Grafana 与 Loki/Tempo 为原生数据源。在 Tempo 面板中，你可以浏览单次代理运行的完整执行追踪，看到span 层级如何刻画代理从接收用户查询 → 选择计划 → 调用工具 → 生成最终输出的序列与时序。可以按时延、状态、span 名称或在 LangGraph 节点中附加的自定义属性过滤——这对多步骤行为调试与性能退化/边界缺陷定位非常关键。

在 Loki，你可查询代理执行时发出的结构化日志事件。Grafana 的日志面板支持实时查看所有代理日志；按代理名、会话、错误类型、trace ID过滤；并与相关追踪互跳。共享的请求/会话 ID让你能从日志峰值或错误尖刺一键跳转到触发它们的具体追踪。

Grafana 的真正价值在于为代理的语义与成功标准定制看板。如图 10-1（原文说明）所示，一个 GenAI 可观测性面板可以展示请求量、成本、token 消耗、时延分布、向量库/基础模型使用等关键指标。示例面板包括：

• 按代理/小时的 token 使用（侦测话痨/冗长回归）
• 工具调用与规划节点的 P95 时延
• 按工作流或提示版本的任务成功率
• 按工具/技能的回退频率
• 基于嵌入相似度的输入漂移指示器

这些面板既用于观测系统表现，也引导开发优先级：若某工具失败率升高，或 token 用量异常增加，这些信号会驱动调试与优化。

Grafana 还支持自定义告警：可对任意指标设置阈值，并通过 Slack、Email、PagerDuty 等集成触发通知。典型规则如：

• 幻觉率在最近 30 分钟超过 5%
• 重试环在单会话中超过 3 次
• 某关键工具的平均响应时间涨幅 > 50%

告警确保即便没人盯着看板，团队也能实时获知回归与异常。配合 Loki/Tempo，告警能迅速闭合反馈环。

Grafana 的告警与PagerDuty 等事件管理工具无缝集成，用于值班升级与确认流程；若需更细粒度的异常捕获，可叠加 Sentry 捕获代理代码中的异常、堆栈、面包屑与版本健康，与 OTel 并行插桩，特别适合调试基础模型调用或工具调用中的概率性缺陷。
若希望采用面向代理的一体化方案，AgentOps.ai 这类平台提供追踪、指标、评测、告警的整合体验，默认支持语义监控（如自动质量评分），且能与既有栈集成，降低组合化 Grafana 组件的搭建成本——代价是增加厂商依赖。
因此，选择在于你的运营成熟度与关注点：要么用 Grafana+PagerDuty/Sentry 打造强健告警与异常分析；要么用 AgentOps.ai 快速落地代理专项洞察。

将 Grafana 深度纳入代理开发生命周期，你就拥有一个面向已部署系统的“活”界面：产品、工程与可靠性团队共享一块“画布”，一起观察、调试、迭代与改进。在一个缺陷具概率性、失败模式具涌现性的代理世界里，这种统一可视化不仅“锦上添花”，而是刚需。

监控模式（Monitoring Patterns）

当你的可观测性技术栈就位——覆盖插桩、日志、追踪、看板与告警——接下来要回答的问题是：如何在本质上具有概率性、可自适应、且难以完全预测的代理系统上“安全地”发布变更？ 答案是采用面向监控的开发模式，在实验中降低风险，并为生产变更建立安全网。本节介绍数个关键模式，帮助团队在持续演进的同时保持安全与敏捷。

影子模式（Shadow Mode）

在影子模式中，新版或实验版代理与当前生产代理并行运行，处理相同输入，但其输出不对用户生效。这样开发者就能在不影响用户体验的情况下，在真实环境中记录与追踪新代理的行为。

借助 OTel，你可以同时为生产代理与影子代理插桩，并附上共享的请求 ID。来自影子代理的日志与追踪在 Loki 与 Tempo 中打上标签，便于对比：例如工具选择、延迟、token 使用或幻觉频率的差异。此法在试用新模型版本、规划策略或提示词技术时尤其有价值。

影子模式让创新更安全：它让团队持续回答“在真实流量上，新代理更好还是更差？哪里出了问题？哪里变好了？”——并且这一切都在不影响正常业务的前提下进行。

金丝雀发布（Canary Deployments）

影子模式只采集信息而不暴露，金丝雀发布则更进一步：将少量真实用户流量（如 1% 或 5%）导向新版本代理，其余用户仍使用基线版本。

在这种设置下，Grafana 看板至关重要。通过按版本标签过滤所有指标与追踪，你可以直接对比金丝雀与基线在成功率、延迟、工具使用、错误计数等方面的差异。若金丝雀出现显著回归或异常，告警会被触发。

如果金丝雀表现良好，就逐步放量；否则即可快速回滚，对用户影响最小。金丝雀发布为在生产环境中快速迭代提供了运营级的安全护栏。

回归追踪采集（Regression Trace Collection）

每当代理在生产中失败——无论是幻觉、规划错误还是工具误用——都是一次学习机会。通过将这些失败的追踪（来自 Tempo）或日志快照（来自 Loki）自动导出到你的测试套件，你就构建了一个持续更新的回归语料库。

这会把生产失败转化为训练与测试信号：失败的工具调用或不对齐的输出会成为新的测试用例。修复上线后，重放这条追踪应当通过。随着时间推移，你的评测集将被真实世界的边缘案例不断增强，避免相同失败模式再次发生。

自愈式代理（Self-Healing Agents）

监控不仅用于发现失败，也能帮助代理从失败中恢复。能够实时读取自身遥测的代理，可以在检测到问题时执行回退机制。

例如：

• 若某工具调用反复失败，代理可切换到更简单的回退方案，或向用户澄清；
• 若延迟飙升，代理可跳过可选的推理步骤；
• 若幻觉评分偏高，代理可给出免责声明或转交人工。

当这些自愈行为由细粒度监控数据支撑时最有效。对每次回退的决定进行日志与追踪，使团队能分析何时/为何触发，以及是否真正奏效。

将用户反馈视为可观测信号（User Feedback as an Observability Signal）

尽管本章大量关注日志、追踪与指标，用户反馈提供了互补视角——它直接反映代理是否满足人的期望。反馈可以是隐式的（如用户反复改写输入、放弃任务、交互中犹豫），也可以是显式的（点踩、星级、自由文本评论）。两类信号都应接入监控栈。

实践中，隐式反馈指标（如任务放弃率、复询频率）可像其他性能指标一样，记录到 Loki 并在 Grafana 中聚合可视化，作为摩擦或困惑的早期指征。显式反馈事件（如低评分）可与 Tempo 中的具体追踪绑定，并在不满激增时触发告警。将用户情感指标与基于追踪的技术数据放在同一看板，能帮助团队把性能问题与用户挫败关联起来，获得更完整的“代理健康”画像。

关键在于，用户反馈也能驱动改进闭环：与低评分关联的追踪可直接导出到评测集进行复盘；若多个用户在同一流程放弃，可能需要重审规划策略或重写基础模型提示。把用户信号整合进更广义的可观测性—行动框架，能够确保监控实践不仅在运营上有效，也真正做到以用户为中心。

分布式漂移（Distribution Shifts）

在监控代理型系统时，识别与应对分布式漂移是最微妙却也最关键的挑战之一。所谓分布式漂移，是指代理所处环境的统计属性随时间发生变化——可能来自用户语言的演化、新产品术语、API 响应变化，甚至基础模型本身的更新。这类变化往往不会触发显式错误，但会表现为性能下降、输出不对齐或回退使用率升高。

监控系统是抵御这类“缓慢漂移”的第一道防线。追踪任务成功率、工具调用失败以及语义指标（如 token 使用趋势、幻觉频率）的看板能提供早期信号。对量化检测而言，可使用统计检验，例如 Kolmogorov–Smirnov（KS）检验来比较输入特征或输出的分布。KS 检验是非参数方法，对比两组数据的经验累计分布是否来自同一分布，非常适合检测连续特征（如查询长度、时延或数值指标）的漂移，无需正态性假设。它计算两个分布之间的最大垂直距离（KS 统计量），并给出 p-value；实践中常以 KS > 0.1（常与 p < 0.05 搭配）作为显著漂移阈值，从而对输入/输出的潜在漂移告警。下面是用 SciPy 的 ks_2samp 检测查询长度漂移的简例：

import numpy as np
from scipy import stats

# 历史与当前查询长度（单位：字符）
historical = np.array([10, 15, 20, 12])  # 基线数据
current = np.array([25, 30, 28, 35])     # 新数据

ks_stat, p_value = stats.ks_2samp(historical, current)
if ks_stat > 0.1:
    print(f"Drift detected: KS statistic = {ks_stat}")

Kullback–Leibler（KL）散度用于衡量两个概率分布的“偏离程度”，常用于通过token 分布（如词频变化）检测概念漂移。它不对称（KL(P‖Q) ≠ KL(Q‖P)），当当前数据（Q）显著偏离历史基线（P）时，KL 增大——例如 KL > 0.5 可标记为嵌入/词汇的概念变化。下例将频数向量归一化为概率，加入极小 epsilon 避免 log(0)，计算 ∑ P * log(P/Q)：

import numpy as np

def kl_divergence(p, q, epsilon=1e-10):
    p = p + epsilon
    q = q + epsilon
    p = p / np.sum(p)
    q = q / np.sum(q)
    return np.sum(p * np.log(p / q))

# token 频率向量（示例）
historical_tokens = np.array([0.4, 0.3, 0.3])
current_tokens = np.array([0.2, 0.5, 0.3])

kl = kl_divergence(historical_tokens, current_tokens)
if kl > 0.5:
    print(f"Concept drift detected: KL = {kl}")

PSI（Population Stability Index）通过比较历史与当前在各类别或分箱（连续变量离散化）上的占比，来检测类别/分箱分布的漂移，非常适合如“refund/cancel/modify”等工具使用模式。PSI 将各桶上的 (actual% - expected%) * ln(actual% / expected%) 求和；一般经验阈值是：PSI < 0.1 稳定，0.1–0.25 轻度漂移（监控）， > 0.25 重度漂移（需要干预，如重训）：

import numpy as np

def psi(expected, actual):
    expected_percents = expected / np.sum(expected)
    actual_percents = actual / np.sum(actual)
    psi_values = ((actual_percents - expected_percents) * 
        np.log(actual_percents / expected_percents))
    return np.sum(psi_values)

# 工具使用计数（如 ['refund', 'cancel', 'modify']）
historical = np.array([50, 30, 20])
current = np.array([20, 50, 30])

psi_value = psi(historical, current)
if psi_value > 0.25:
    print(f"Major drift: PSI = {psi_value}")
elif psi_value > 0.1:
    print(f"Minor drift: PSI = {psi_value}")

实践中，准确率的骤降（如滚动 24 小时下降 >5–10% ）、任务放弃率上升（ >15% ）、或重试占会话比例激增（ >20% ）都可能提示输入或概念漂移。还可以使用基于嵌入的方法（如当前与历史查询向量的余弦相似度），当均值相似度 < 0.8 时触发复核；工具层面常借助 Evidently AI 与 Grafana 联动做自动告警。

应对漂移是构建韧性系统的一部分：

• 短暂变化可通过调整阈值或更新解析逻辑缓解；
• 持久变化则可能需要重训工作流或适配新 API。
  配套的反馈闭环（如把退化的追踪记录导出复盘）有助判断问题是暂时还是系统性。通常还会在检测后进行A/B 验证修复是否奏效。一个可操作的策略是：当 PSI > 0.25 且持续 48 小时，就优先重训/重配管道。总之，强大的可观测性栈提供实时可见性，使团队能在漂移演变为故障前采取行动。

指标归属与跨职能治理（Metric Ownership and Cross-Functional Governance）

随着代理系统落地，一个不显眼却严重的组织挑战会浮现：谁来“拥有”哪些指标？ 在传统软件中，职责较清晰：基础设施团队管延迟/可用性，产品团队管转化/用户成功，ML 团队管模型健康与性能。但基础模型驱动的代理打破了这些边界——你的监控策略也必须随之调整。

基础模型的响应本身就是产品体验；一长串工具调用、重试、回退与生成构成的链条就是用户旅程；而 5 秒的规划延迟，往往是提示/流程设计带来的，而非“模型天生如此”。因此，代理的日志、追踪与评测信号必须进入核心可观测性平台，与服务健康/系统指标并列。一旦仅在“产品看板”或“模型笔记本”里可见这些数据，就难以看到全貌，也容易将系统性问题掩盖起来。

延迟就是典型例子。团队若默认“基础模型就是慢”，就可能把延迟正常化到一切环节——冗长提示、无谓重试、臃肿规划——缺少基于追踪的严密插桩，这种漂移不易被察觉。久而久之，系统整体显得迟缓，并非因为基础设施不给力，而是产品与 ML 在不经意间把“慢”当成了必然。

解决之道不是把延迟甩给基础设施，或把体验只归到产品，而是建立共享看板，让团队可以：

• 产品负责人看到规划延迟/回退率与任务放弃的关联；
• ML 工程师监控幻觉率/漂移并结合用户反馈；
• Infra/SRE 发现token 峰值与工具不稳定对系统可靠性的影响。

每个团队都要“拥有”一部分代理遥测，且任何单一团队都无法单独解读全部信号。为厘清职责，可采用 RACI 矩阵（Responsible/Accountable/Consulted/Informed）。下面是表 10-3 的模板，可按你的组织与指标进行适配，既避免“无人负责”，也减少“多头管理”。

表 10-3. 监控指标与跨职能职责的 RACI 矩阵（示例）

指标/活动	产品团队	ML 工程师	Infra/SRE 团队
延迟（如规划/工具调用）	A（用户影响所有权）/C（UX 阈值咨询）	R（优化提示/模型）/I（回归知会）	R（监测基础设施原因）/C（扩容咨询）
幻觉率	C（用户语境）/I（趋势知会）	A/R（检测与治理/评测）	I（为告警配置知会）
任务成功率	A（产品目标）/R（定义成功标准）	C（模型改进建议）	I（与系统可靠性关联知会）
Token 使用/成本	C（业务影响）	R（优化生成）/I（峰值知会）	A（预算/扩容）/R（效率监控）
分布式漂移	I（产品调整知会）	A/R（用嵌入/评测检测）	C（数据管道稳定性）
回退/重试频率	C（UX 回退策略）	R（优化规划逻辑）	A（可靠性）/I（模式知会）
用户反馈/情感	A/R（聚合与优先级）	C（与模型关联）	I（运维告警知会）
看板维护与例行评审	C（产品语境）	C（ML 洞察）	A/R（平台与跨团队评审）

举个直观例子：一条追踪显示同一工具被循环调用四次，随后出现一次超长生成、含糊回复，最终用户放弃。这不是“工程细节”，而是产品失败。只有当日志与 span 进入 Loki/Tempo 这类共享平台时，这些问题才会被看见，而不会被埋在“各自为政”的指标页签里。

要让这套机制有效，建议实践：

• 共享看板统一使用版本标签与语义指标。高效团队不争论“哪个看板更准”，而是跨职能协作去改善用户体验。
• 用产品上下文（feature flag、用户分层、workflow ID）标记 span 与日志。
• 建立跨团队的例行分诊，在重要上线或回归后，产品/Infra/ML 一起审阅遥测。
• 一视同仁：别给基础模型的延迟另设一套宽松标准。影响用户的慢就是大家的事。

代理系统需要跨职能的可观测性。 监控栈不只是为“宕机告警”，更是工程、ML 与产品就“系统在做什么、做得如何、该往哪演进”达成共识的共同接口。

结论（Conclusion）

对代理型系统的监控不只是一次“安全检查”——它是一门让智能系统在真实世界环境中茁壮成长的工程学科。本章指出，监控不仅是被动响应：它是团队从生产学习、适应变化、并加速前进的方式。

从用 OpenTelemetry 做基础插桩，到通过 Loki 与 Tempo 进行实时日志与追踪采集，再到在 Grafana 中构建看板与告警，我们勾勒出一条开源反馈闭环：在问题演化为故障前将其暴露，并把每一次发布都变成打磨系统的机会。

我们探讨了影子模式、金丝雀发布、回退日志记录、以及用户情绪追踪等实用技术。我们强调的不只是测什么，还包括如何行动。同时也展示了监控如何帮助识别不仅是显性失败，还包括语境、数据或行为的缓慢漂移——若任其发展，将会悄然侵蚀性能。

前行的路径很明确：那些在可观测性思维下构建代理系统的团队——能够对“飞行中的”代理进行插桩、可视化并持续学习——将获得强大的优势。他们迭代更快、对指标更有信心、并能在问题出现时优雅恢复。

在一个代理型系统日益成为核心基础设施的世界里，健壮的监控不是可选项，而是地基。掌握这门能力的团队，将引领在规模上打造智能、韧性、可信代理系统的未来。