面向 AI 智能体的 OpenTelemetry 日志、评估与 FinOps

1. 引言

Harness 是智能体 AI 世界的新热词。随着 AI 智能体在企业中逐渐普及，开发智能体已经变成了"容易的那部分"，真正难的是如何大规模、稳定地把它们跑起来。

对那些真正在企业里构建智能体 AI 系统、并在大规模场景中应用软件工程最佳实践的人来说，这个趋势并不意外。

虽然 Anthropic 最早是在 智能体代码编写 的语境下提出这个概念的，但它同样适用于任何智能体设计。

核心假设是：关注点已经从 LLM 本身，转移到围绕 LLM 构建一个有效的 Harness，让智能体执行过程可以被可靠且负责任地管理。

这就是从"孤立的智能"转向"可管理的执行"的过程。关键构建模块包括（如图 1 所示）：

• • 推理循环：生成计划（图结构），执行，反思，循环/调整，直到完成目标功能。
• • 上下文（记忆）管理：优化上下文，在存入短期记忆（STM）前先总结，并把 STM 内容转化为长期记忆（LTM）。
• • 评估（Evals）：利用"LLM 担任裁判"来评估响应质量和智能体输出，必要时使用基准真值。
• • 护栏（Guardrails）：防范攻击，例如提示词注入、智能体/工具滥用、记忆投毒。
• • 人在回路（HITL）：让人成为智能体生命周期中的一等公民（不只是监督者），提供支持交互和干预的合适界面。

以上大多数关键模块我之前都单独写过文章——已在上方各自链接。

本文聚焦于智能体 可观测性 层，这一层对监控和管理各个 Harness 组件至关重要。

第 2 节先定义智能体可观测性层的范围、能力和局限。第 3 节定义启用溯源与可观测所需记录的 OpenTelemetry（OTel）属性。

最后，第 4 节和第 5 节分别展示可观测性层如何用于评估和 FinOps（AI 财务运营）——作为持续改进的手段，识别功能效率和成本效率的提升空间。

2. 智能体 AI 可观测性

2.1 智能体 AI 参考架构

下图 2 展示了智能体 AI 平台的关键组件，这些组件构成了第 2.2 节可观测性层的基础：

• • 推理层：分解复杂任务，自适应地调整执行以实现目标；
• • 智能体市场/注册表：管理现有可用的智能体、工具和模型；
• • 编排模块：编排并监控（观测）多智能体系统的执行；
• • 集成模块：通过 MCP 工具连接企业系统，如 ERP、CRM、知识库；
• • 供智能体间数据与上下文共享的 共享记忆管理；
• • 治理层：包括可解释性、隐私、安全、安全护栏等。
  

给定一个用户任务，智能体 AI 平台的目标是找到（组合出）一个能执行该任务的智能体（或智能体组）。因此，第一个需要的是能把任务分解为子任务的推理模块，由编排引擎来协调各智能体的执行。

目前最广泛使用的分解框架是思维链（CoT），它把复杂任务拆成多个可管理的小任务，并呈现出模型思考过程的解释。此外，ReAct（推理与行动）框架让智能体能批判性地评估自己的行动和输出，从中学习，并随后优化推理和计划流程。

智能体的组合需要一个智能体市场/注册表，其中有对智能体能力和约束的清晰描述。例如，Agent2Agent（A2A）协议提出了智能体名片（Agent Card）概念（一个 JSON 文档），作为智能体的数字"名片"，包含以下关键信息：

Identity: name, description, provider information.Service Endpoint: The url where the A2A service can be reached.A2A Capabilities: Supported protocol features like streaming or pushNotifications.Authentication: Required authentication schemes (e.g., "Bearer", "OAuth2") to interact with the agent.Skills: A list of specific tasks or functions the agent can perform (AgentSkill objects), including their id, name, description, inputModes, outputModes, and examples.

由于需要编排多个智能体，需要一个系统集成层，支持不同的智能体交互模式，如智能体间 API、智能体输出供人消费、人触发 AI 智能体、带人在回路的 AI 智能体间协作等。这些模式需要底层的智能体 OS 平台来支撑。

Anthropic 近期提出的模型上下文协议（MCP）用于将 AI 智能体连接到企业数据所在的外部系统/工具。MCP 被称为 AI 模型的"USB-C"，通过三个核心构建模块实现互操作：资源、提示词和工具。通过标准化这些内容，

任何使用 MCP 的 AI 系统都能理解如何通过任何兼容的 MCP 服务器请求数据（资源）、提供指令（提示词）或执行操作（工具）。

由于复杂智能体任务通常是长时间运行的，记忆管理对智能体 AI 系统来说非常关键。这包括任务间的上下文共享，以及在较长时间内维持执行上下文。

标准做法是将智能体信息的向量嵌入存入向量数据库，支持最大内积搜索（MIPS）。为实现快速检索，通常使用近似最近邻（ANN）算法，用一定准确率换来巨大的速度提升。详细讨论请参阅我之前关于智能体 AI 长期记忆的文章。

最后是治理层。我们需要确保用户针对特定任务共享的数据，或跨任务的用户档案数据，只与相关智能体共享（表/报告的鉴权与访问控制）。可参阅我之前关于负责任 AI 智能体的文章，了解构建良好治理智能体 AI 平台所需的关键维度。

2.2 智能体 AI 可观测性

智能体 AI 系统（如上所述）通常涉及编排多个智能体、工具和模型（LLM），产生不确定性的决策路径。因此，智能体可观测性对以下方面至关重要：

• • 对智能体、工具、模型（LLM）、用户、上下游应用的端到端追踪——如图 3 所示。
• • 对 LLM 使用情况、故障、幻觉、延迟峰值、成本超支等的因果分析——进而实现性能和成本优化。
• • 支持可审计性与治理，提供不可篡改的溯源记录、安全护栏证据，以及多智能体流水线的成本（用量）归因。
• • 支持持续改进，让工程团队能够在有验证指标的情况下迭代提示词、智能体逻辑和策略。

还需特别强调，智能体可观测性横跨构建时可观测性和运行时可观测性两个阶段——如图 4 所示。

构建时可观测性专注于在系统部署前分析其代码、配置和产物——在开发周期早期发现问题，检查构建或部署阶段的合规性和潜在问题。

在智能体场景下，这意味着校验智能体流水线各组件的结构和设计相关指标，以及来自模拟或测试运行的功能与性能数据。

运行时可观测性通过生产环境中的日志、指标和追踪等数据，实时了解系统运行时的行为、性能和错误。

在智能体场景中，由于运行的不确定性，运行时可观测性更为重要。

• • 运行时可观测性是持续监控和确保智能体行为与预期目标保持一致的必要手段，尤其是当智能体有能力自主改变目标或计划时。
• • 最关键的对齐风险，如目标漂移或递归死循环，是动态涌现的，仅靠构建时配置无法完全控制。

3. OpenTelemetry（OTel）日志

本节深入介绍实现上述智能体可观测性能力所需的 OpenTelemetry（OTel）属性。

设计原则

• • 规范标准优先：以 W3C 追踪上下文（traceparent、tracestate）作为主要传播格式，避免各类私有 header 泛滥。
• • 一个任务锚点，多个 Span：将"AI 任务"视为锚定到一个追踪（trace）的逻辑操作，模型/工具调用是子 Span，重试作为同一 trace 中的新 Span。
• • 链接而非分叉：用 OTel "links" 表示事件流中的扇出/扇入、定时工作和跨追踪的汇聚。
• • ID 零语义：ID 是不透明的、全局唯一的、不可猜测的——语义应体现在属性中。

目标是确定每个智能体流水线都必须记录、存储和共享的最小可移植属性集。必要的标识符（规范）包括：

• • trace_id：跨运行的任务/全局关联
• • span_id：任务内部的操作
• • parent_span_id：因果关系
• • links[]：非层次化因果关系（扇出/扇入、定时）

建议使用 trace_id 作为跨系统和平台的 AI 关联 ID。AI 特定的标准属性如下表所示。

这些属性需要添加到相关 Span，使智能体流水线可审计——实现带溯源的追踪。属性名称仅供参考，可映射到 OTel 智能体 AI 语义约定（待最终确定）。暂时链接到 OpenTelemetry GenAI 语义约定仓库（链接）。

4. 智能体评估与优化

指标是定量评估的关键，用于衡量智能体实现目标的程度、错误检测能力和工具选择的有效性。它们对评估智能体用例的性能和效率至关重要。

4.1 智能体效率

这些指标衡量智能体工作流的效率。

• • 推理相关性：确保智能体的推理与用户查询保持一致。每次工具调用背后的推理是否与用户的需求明确关联？
• • 推理连贯性：检查智能体推理的逻辑流程。推理是否遵循逻辑的、循序渐进的过程？每一步都应该有所增益，并在任务上下文中有意义。
• • 答案相关性：回答是否与输入相关？
• • 事实依据性：评估智能体响应在多大程度上基于可核实的、与上下文相关的事实来源，最大程度降低幻觉和错误信息。
• • 响应流畅度：评估智能体响应的可读性、语法正确性和自然度。
• • 响应连贯性：衡量智能体的响应是否逻辑清晰，并在整个对话中保持清晰。
• • 任务分解（规划）效率：衡量智能体将复杂任务拆解为可管理子任务的能力。
• • 智能体健壮性：衡量智能体在保持性能和可靠性的同时，处理意外输入、错误和对抗性场景的能力。
• • 智能体一致性：衡量智能体在面对相似输入的多次交互中，产生稳定、可重复且逻辑连贯响应的能力。

4.2 工具使用效率

这些指标评估 AI 智能体选择和使用工具的有效程度。

• • 工具选择准确性：衡量智能体为给定任务选择最合适工具的有效性。
• • 工具使用效率：衡量智能体使用所选工具的最优程度，考虑不必要的调用和资源使用等因素。
• • 工具调用精确性：衡量工具调用中使用的参数的准确性和合理性。
• • 工具调用成功率：总体工具调用的成功率。

4.3 基于 OTel 的实现架构

指标评估有两种类型：离线（开发阶段）和实时（作为可观测性/监控的一部分）。

• • 在基于日志的离线评估中，组件（规划器、智能体和工具）以特定格式生成包含特定信息的日志。基于日志的评估器审查日志并根据内容生成评估结果。这是一种非侵入式评估方法。
• • 在实时评估中，组件向评估服务发起调用并发送所需产物。评估服务汇总端到端执行的所有数据，实时生成评估结果。该方法需要在组件代码中嵌入实时调用，并需要与智能体/工具开发团队协调。

图 5 展示了基于 OTel 的离线智能体评估解决方案架构——步骤如下：

步骤 1：触发评估。 用户通过调用 Evaluate API 启动流程，所需输入包括：

• • 智能体名称
• • 工具描述
• • 所选指标，如工具选择准确性、推理相关性
• • 日期范围

步骤 2：检索交互记录。 系统根据智能体名称和提供的日期范围，查询日志数据库，获取相关的历史交互记录用于评估。

步骤 3：评估处理。 评估引擎使用"LLM 担任裁判"分析检索到的交互。它为每个所选指标计算得分，并为这些得分生成理由说明。评估结果随后安全存储在 BLOB 存储中以持久化。

步骤 4：发布结果。 用户可通过以下方式查看评估结果：

• • Get ResultList API：显示智能体所有评估的汇总列表。
• • Get ResultDetails API：提供每次交互和每个指标的详细得分及其理由说明。

5. 基于 OTel 的智能体 AI FinOps

智能体 AI 的 FinOps 可定义为：

一种将财务、工程和业务结合在一起的最佳实践——通过最大化价值和确保财务问责制来管理智能体 AI 成本。

它通过数据驱动的洞察来管理灵活性、治理、成本与 ROI 之间的权衡，帮助企业通过资源合理调整和高效分配，主动优化 AI 支出。

在典型智能体 AI 场景中，成本通常由以下部分组成：

• • 计算基础设施
• • 模型：大语言模型（LLM）/ 小语言模型（SLM）
• • 存储：记忆、用于搜索的向量数据库等

以一个参考场景为例：以 LangGraph 作为智能体开发框架，部署在 Azure Kubernetes Service（AKS）上：

• • LangGraph 编排智能体执行（通过内部 API 或托管运行时）。
• • 智能体以自定义逻辑或工具的形式，作为容器化智能体端点部署在 AKS 上。
• • AI Search 索引企业数据（向量 + 文本），作为检索增强生成（RAG）的知识源。
• • AKS Pod 调用 AI Search 和/或模型端点（如 Azure OpenAI GPT 或 Azure Foundry 中微调的 LLM/SLM）。
• • OpenTelemetry 日志（如第 3 节所述）存储在带 Application Insights 的 Azure Monitor 中。

成本计算需要考虑以下参数——基于 AKS Pod 的读写、搜索查询延迟：

• • 同时运行多少个智能体 Pod？平均智能体容器镜像大小约为每个智能体 2–4 GB × 并发会话数。
• • AKS 中暂存或缓存了多少个 LLM/检查点？这里的平均值约为 1–10 GB（分词器、本地权重、嵌入缓存）。
• • AKS ↔ AI Search / AI Foundry 之间的流量和延迟，目标 < 200 ms。
• • 向量存储方面，存储在 AI Search 中的嵌入大小（根据用例）可在 100 MB 到 100 GB 之间变化。
• • 日志量约为每 100 个会话每天 100 MB。

对于 5 个并发运行的智能体，代表性的容量数据如下：

• • 5 个 Pod × 每个 2 vCPU × 6 GB RAM → 共 10 vCPU、30 GB RAM
• • 每个 Pod 缓存 5 GB → 25 GB 临时 SSD
• • 每天产生 1 GB 日志 → 每天 10 GB 遥测数据
• • 向量数据约 25 GB，存储在 AI Search 中

上述内容侧重于理解智能体基础设施成本，下一节将重点分析 LLM 调用——因为它仍占整体智能体系统成本的大头。

6. 结论

尽管智能体 AI 系统的价值显而易见，但它们是复杂系统，难以可靠地管理。因此，对多智能体流水线（包括多个智能体、工具和 LLM 调用）的端到端可观测性，对企业采纳来说至关重要。

为此，我们提出了一个全面的智能体可观测性层，涵盖构建时和运行时可观测性。有效的日志记录是实现这一切的关键，我们就 OpenTelemetry（OTel）智能体 AI 语义约定提出了建议，明确了智能体、工具、模型、安全和治理的相关 OTel 属性。最后，我们展示了如何利用 OTel 日志进行智能体评估和 FinOps——实现成本和性能效率的双重提升。

智能体 AI 可观测性仍处于早期阶段，但发展非常迅速！随着智能体开始执行更长的任务（带记忆）、在多智能体场景中协作使用工具、处理日益复杂的工作流，建议尽早开始，并以可适应变化的方式构建可观测性层——而不是试图一步到位地构建一个"面向未来"的可观测性平台。