面向 AI Agents 的 OpenTelemetry 日志、Evals 与 FinOps
1. 引言
Harness 是 agentic AI 领域的新热词。随着 AI agents 在企业中的采用不断增加，开发 agents 已经变成了相对容易的部分。真正具有挑战性的，是如何以一致的方式、在大规模场景下运行它们。
对于那些真正正在企业中构建 agentic AI 系统，并在大规模场景下应用软件工程最佳实践和良好架构框架的人来说，这一切都不应令人意外。
虽然 Anthropic 提出了 agentic codinghttps://www.anthropic.com/engineering/harness-design-long-running-apps 的概念，但它同样适用于任何 agentic 设计。
核心假设是，关注点已经从 LLM 转移到围绕 LLM 构建一个有效的 harness，从而使 agentic 执行能够在可靠性和可问责性保证下进行管理。
因此，行业正从 isolated intelligence 转向 managed executions. 其关键构建块包括（如图 1 所示）：
推理循环：生成计划（graph）、执行、反思并循环 / 适应，以实现底层功能。
上下文（memory）管理：优化上下文，在存入短期记忆（STM）之前对记忆项进行摘要，并将 STM 项转换为长期记忆（LTM）。
Evals：利用 LLM-as-a-Judge 评估响应和 agent 结果的质量，并在适用时利用 ground truth。
Security：用于用户 → 应用 → agents → tools →（数据）源系统之间标准化且可扩展交互的模式。
Guardrails：防御攻击，例如 prompt injection、失配的 agent / tool 滥用、memory poisoning。
Human-in-the-loop (HITL)：将人类作为 agentic 生命周期中的一等公民加以集成（而不只是监督者），并提供合适的 UI/UX 以支持交互和干预。
我之前已经就上述大多数关键构建块撰写过文章——相关链接已附上。
在本文中，我们关注对监控和管理 harness 组件至关重要的 agentic observability 层。
我们首先在第 2 节定义 agentic observability 层：其范围、能力和架构——将其置于一个参考 agentic 平台中。随后我们在第 3 节定义需要记录的 OpenTelemetry（OTel）属性，以支持 lineage 和 observability。
最后，我们将在第 4 节和第 5 节分别展示如何将 observability 层用于评估和 FinOps——作为持续改进的一部分，用于识别功能效率和成本效率的改进空间。
2. Agentic AI Observability
2.1 Agentic AI 参考架构
图 2 展示了构成第 2.2 节所述 observability 层基础的 agentic AI 平台关键组件：
Reasoning 层：用于分解复杂任务，并调整其执行以实现给定目标；
Agentic marketplace / registry：用于管理现有及可用的 agents、tools 和 models；
Orchestration 模块：用于编排和监控（observe）多 agent 系统的执行；
Integration 模块：用于与企业系统集成的 MCP tools，例如 ERP、CRM、KB repositories；
共享 memory 管理：用于 agents 之间的数据和上下文共享；
Governance 层：包括可解释性、隐私、安全性、安全护栏等。
给定一个用户任务，agentic AI 平台的目标是识别（组合）一个能够执行该任务的 agent（或 agent 组）。因此，我们首先需要一个能够将任务分解为子任务的 reasoning 模块，而相应 agents 的执行则由 orchestration engine 进行编排。
Chain of Thought（CoT）是当今最广泛使用的分解框架，用于将复杂任务转化为多个可管理的任务，并揭示对模型思考过程的解释。此外，ReAct（reasoning and acting）框架允许 agent 批判性地评估自身的动作和输出，从中学习，并随后优化其计划 / 推理过程。
Agent 组合意味着必须存在一个 agent marketplace / agents registry，并对 agent 能力和约束作出清晰定义。例如，Agent2Agent（A2A）协议定义了 Agent Card 的概念（一个 JSON 文档），它充当 agent 的数字“名片”。其包含以下关键信息：
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.
鉴于需要编排多个 agents，就需要一个支持不同 agent 交互模式的 systemintegration layer，例如 agent-to-agent API、面向人类消费的 agent API、人类触发 AI agent、带 human in the Loop 的 AI agent-to-agent。底层 Agent OS 平台需要支持这些集成模式。
我们在这里参考 Anthropic 近期提出的模型上下文协议（MCP），用于将 AI agents 连接到存放企业数据的外部系统 / tools。MCP 被称为 AI models 的“USB-C”，它通过三大构件实现互操作：resources、prompts 和 tools。通过对这些内容进行标准化，
任何使用 MCP 的 AI 系统都可以理解如何通过任何兼容的 MCP server 请求数据（resources）、提供指令（prompts）或执行操作（tools）。
鉴于复杂 agents 具有长时间运行特性，memory 管理对于 agentic AI 系统至关重要。这既包括任务之间的上下文共享，也包括在较长时间跨度内维持执行上下文。
这里的标准做法是，将 agent 信息的 embedding 表示保存到一个向量存储数据库中，以支持 maximum inner product search（MIPS）。为了快速检索，会使用 approximate nearest neighbors（ANN）算法，以在精度与极大速度提升之间进行权衡，返回近似 top k-nearest neighbors。关于该主题的详细讨论，请参考我之前关于 Long-term Memory for Agentic AI 的文章。
最后是 governance 层。我们需要确保用户针对某个任务共享的数据，或跨任务的用户画像数据；只能与相关 agents 共享（表 / 报告认证与访问控制）。请参考我之前关于 Responsible AI Agents 的文章，其中讨论了构建一个治理良好的 agentic AI 平台所需的关键维度。
2.2 Agentic AI Observability 层
如上所述，Agentic AI 系统通常需要编排多个 agents、tools、models（LLMs），并沿着 agent 的推理形成非确定性的决策路径。在这种情况下，agentic observability 对以下方面至关重要：
对 agents、tools、models（LLMs）、users、上游和下游应用进行 端到端 tracing —— 如图 3 所示。
对 LLM 使用、故障、hallucinations、延迟峰值、成本超支等进行 因果分析 —— 从而实现性能与成本优化。
通过 可审计性 与治理，支持不可篡改的 lineage、安全与 guardrail 证据，以及多 agent 流水线的成本（usage）归因。
通过 持续改进，让工程团队能够在经验证的指标基础上演进 prompts、agent logic 和 policies。
同时还需要强调，agentic observability 横跨 build-time 和 runtime observability —— 如图 4 所示。
Build-time observability 侧重于在系统部署之前分析其代码、配置和 artifacts——通过在 build 或 deployment 阶段检查合规性和潜在问题，在开发周期早期发现问题。
在 agentic 场景中，这对应于验证与 agentic pipelines 中各组件结构和设计相关的指标，以及来自模拟或运行的功能和性能数据。
Runtime observability 在系统运行时，利用日志、指标和来自 production environment 的 traces，对系统行为、性能和错误提供实时洞察。
在 agentic 场景中，由于运行具有非确定性，runtime observability 更为重要。
Runtime observability 对于持续监控并确保 agent 的行为始终与其预期目标保持一致是必要的，尤其是在它具有自主改变目标或计划的能力时，
最关键的对齐风险，例如 goal drift 或 recursive loops，会动态出现，无法仅通过 build-time 配置完全控制。
3. OpenTelemetry（OTel）日志
在本节中，我们将深入探讨启用上述 agentic observability 能力所需的 OpenTelemetry（OTel）属性。
Design principles
Canonical standard first: 使用 W3C trace context（
traceparent、tracestate）作为主要传播格式，避免自定义 headers 的泛滥。One task anchor, many spans: 将一个“AI task”视为锚定到单个 trace 的逻辑操作，其中 model / tool 调用是子 spans，重试则作为与同一 trace 关联的新 spans。
Link, don't fork: 使用 OTel
links表示 fan‑out / fan‑in、计划任务，以及基于事件流的跨 trace joins。Zero semantics in IDs: ID 应当是不可解释、全局唯一且不可猜测的——语义应放在 attributes 中。
接下来我们的目标是识别一组最小且可移植的属性，供每个 agentic pipeline 记录、存储和共享。所需的标识符（canonical）包括：
trace_id: 跨运行的任务 / 关联标识
span_id: 任务内的操作
parent_span_id: 分层因果关系
links[]: 非层级因果关系（fan‑out / fan‑in、scheduled）
建议将 trace_id 作为跨系统和平台可见的 AI correlation ID。下面的表格概述了 AI 特定的标准属性：
这些属性需要添加到相关 spans 中，以使 agentic pipelines 具备可审计性——并支持 lineage 跟踪。属性名称仅供说明，最终可映射到 OTel Agentic AI semantic convention（待最终确定）。与此同时，可先参考 OpenTelemetry GenAI semantic conventions repository（link）。
4. 基于 Agentic Evaluation 和优化
Metrics 是定量评估的关键，用于衡量 agent 在多大程度上实现目标、检测错误并做出有效的 tool 选择。它们对于评估 agentic use-cases 的性能和效率至关重要。
4.1 Agent 效率
这些 metrics 用于衡量 agentic workflow 的效率。
Reasoning relevancy: **** 确保 agent 的推理与用户查询一致。每次 tool call 背后的推理是否清晰地对应于用户的请求？
Reasoning coherence: **** 检查 agent 推理中的逻辑流。推理是否遵循逻辑清晰、逐步展开的过程？每一步都应在任务上下文中有价值且合理。
Answer relevance: 检查答案是否与输入相关？
Groundedness: **** 评估 agent 的响应在多大程度上锚定于事实、可验证且与上下文相关的来源，从而尽量减少 hallucination 和错误信息。
Response fluency: **** 评估 agent 响应的可读性、语法正确性和自然程度。
Response coherence: 衡量 agent 的响应是否在逻辑上结构清晰，并在整个对话中保持明确性。
Task decomposition (planning) efficiency: 衡量 agent 将复杂任务拆分为可管理子任务的能力。
Agent robustness: **** 衡量 agent 在保持性能和可靠性的同时处理意外输入、错误和对抗性场景的能力。
Agent consistency: 衡量 agent 在多次交互中、面对相似输入时输出稳定、可重复且逻辑一致的响应的能力。
4.2 Tool 利用效率
这些 metrics 用于评估 AI agent 选择和使用 tools 的有效性。
Tool selection accuracy: **** 衡量 agent 为给定任务选择最合适 tool 的有效性。
Tool usage efficiency: 衡量 agent 使用所选 tools 的最优程度，考虑不必要调用和资源使用等因素。
Tool call precision: 衡量 tool call 中所用参数的准确性和适当性。
Tool call success rate: **** 整体 tool calls 的成功率。
4.3 基于 OTel 的实现架构
评估指标有两类：离线（开发期间）和实时（作为 observability/monitoring 的一部分）。
在基于日志的离线评估中，各组件（planner、agents 和 tools）以指定格式生成包含特定信息的日志。日志评估器会审查这些日志，并根据日志内容生成评估结果。这是一种 non-invasive 的评估方法。
在实时评估中，各组件会调用评估服务并发送所需的 artifacts。随后评估服务会汇总一次端到端执行的全部数据，并实时生成评估结果。该方法要求在组件代码中嵌入实时调用，并需要与 agent/tool 开发团队协作。
下图 5 展示了基于 OTel 的离线 agentic evaluation 解决方案架构——步骤如下：
步骤 1：触发评估： 用户通过调用 Evaluate API 发起流程。所需输入：
Agent name
Tool description
Selected metrics, e.g., tool selection accuracy, reasoning relevancy
Date range
步骤 2：交互检索。 根据 agent name 和提供的日期范围，系统查询日志数据库以获取与评估相关的交互历史。
步骤 3：评估处理。 评估引擎使用 LLM-as-a Judge 分析检索到的交互。它会为每个选定 metric 计算分数，并生成这些分数的说明。随后，评估结果会被安全地存储到 BLOB storage 中以便持久化。
步骤 4：发布结果。 用户可以通过以下方式查看评估结果：
Get ResultList API：显示该 agent 的所有 evaluations 摘要列表。
Get ResultDetails API：提供每次交互和每个 metric 的详细分数，以及相应说明。
5. 基于 OTel 的 Agentic AI FinOps
Agentic AI 的 FinOps 可定义为：
一种最佳实践，旨在将 finance、engineering 和 business 结合起来，通过最大化价值并确保财务问责来管理 Agentic AI 成本。
它涉及使用数据驱动的洞察来管理 agility、governance、cost 与 RoI 之间的权衡，使企业能够通过资源 right-sizing 和高效分配主动优化 AI 支出。
在典型的 agentic AI 场景中，它通常由以下部分组合而成：
compute infrastructure
model：large language models（LLMs）/ small language models（SLMs）
storage：memory、用于搜索的 vector databases 等
让我们考虑一个参考场景：使用 LangGraph 作为 agentic 开发框架，并部署在 Azure Kubernetes Service（AKS）上：
LangGraph 负责编排 agent 执行（通过内部 API 或 managed runtime）。
Agent 通过自定义逻辑或 tools 部署为 AKS 上的容器化 agent endpoint。
AI Search 为企业数据建立索引（vector + text），并作为 retrieval-augmented generation（RAG）的知识来源。
AKS pods 调用 AI Search 和/或 model endpoints（例如 Azure OpenAI GPT 或 Azure Foundry 中的 fine-tuned LLMs / SLMs）。
OpenTelemetry logs（如第 3 节所述）存储在 Azure Monitor with Application Insights 中。
随后，成本计算需要考虑以下参数——基于 AKS pod 的读 / 写和 search query latency：
有多少 agent pods 同时运行？平均而言，每个 agent 的容器镜像大小约为 2–4 GB × 并发会话数。
有多少 LLMs / checkpoints 被预置在 AKS 中或被缓存？这里的平均值约为 1–10 GB（tokenizer、本地权重、embeddings cache）。
AKS ↔ AI Search / AI Foundry 之间的流量以及延迟，例如 < 200 ms。
vector storage 中 embedding（索引在 AI Search 中）的大小可因 use-case 而异，从 100 MB 到 100 GB 不等。
日志量大约为每 100 个会话每天 100 MB。
对于 5 个 agent 同时运行，代表性的容量如下：
5 pods × 每个 2 vCPU × 6 GB RAM → 10 vCPU，30 GB RAM
每个 pod 缓存 5 GB → 25 GB ephemeral SSD
每天日志 1 GB → 每天 10 GB telemetry
向量数据总计约 25 GB，存储在 AI Search 中
虽然以上内容重点在于理解 agentic infrastructure cost，但下一节我们将聚焦分析 LLM invocation calls——因为它们仍然构成整体 agentic 系统成本的大头。
6. 结论
尽管 agentic AI 系统的优势显而易见，但它们是难以可靠管理的复杂系统。因此，对多 agent 流水线（包括多个 agents、tools 和 LLM invocations）进行端到端 observability，对于企业采用至关重要。
为此，我们提出了一个全面的 agentic observability 层，涵盖 build-time 和 runtime observability。有效的日志记录是实现这一目标的关键，我们也提出了 OpenTelemetry（OTel）agentic AI semantic conventions 的建议。其中概述了与 agents、tools、models、safety 和 governance 相关的 OTel 属性。最后，我们展示了如何利用 OTel logs 同时支持 agentic evaluation 和 FinOps——从而实现成本与性能效率。
Agentic AI observability 仍处于早期阶段，但发展非常迅速！随着 agents 开始执行带有 memory 的长任务，在使用 tools 的多 agent 场景中协作，并处理越来越复杂的 workflows；我们的建议是尽早开始，并以能够适应变化的方式构建 observability 层——而不是试图构建一个“面向未来”的 observability platform。