用OpenSearch观测AI智能体：Hermes-agent的可观测性实践

当AI智能体进入生产环境，我们如何观测它们？

在RIOS网络大使、CECOM负责人Stefano Pampaloni的这场演讲中，他抛出了一个越来越真实的工程问题：当自主AI智能体（autonomous agents）真正运行在生产环境中，我们该如何感知、理解和观测它们？

这个问题并不局限于某一个具体的智能体框架（如演讲中反复提到的Hermes-agent），而是所有自主智能体系统都要面对的共性挑战。传统的IT可观测性体系已经相当成熟，但面对智能体这类非确定性、依赖LLM推理的系统，它显得力不从心。

可观测性应用开发

为什么传统可观测性不够用

演讲中强调，OpenTelemetry已经成为可观测性领域的事实标准（de facto standard）。它由CNCF（Cloud Native Computing Foundation）托管，厂商中立，覆盖追踪（traces）、指标（metrics）和日志（logs）。而其中最关键的，是它为所有这些数据提供了统一的语义约定（semantic conventions）。

OpenSearch这边的进展同样值得关注：从Data Prepper支持OpenTelemetry，到OpenSearch 3.6版本成为原生的OpenTelemetry平台，整个观测栈已经相当成熟。目前指标存储仍以Prometheus为主，但路线图中已规划通过Prometheus API集成，让OpenSearch承担指标长期存储的角色。

问题在于，智能体系统与传统系统的运行逻辑截然不同。传统监控关注服务是否存活、调用是否成功——如果出错，我们知道哪里出了问题。但智能体会自主规划、调用各种API、与LLM交互、产生不确定的中间结果。一个关键观点是：

即使所有的API调用都成功，智能体也可能什么有价值的结果都没产出。

换句话说，你可能看到几十个"成功"的调用、正常的token消耗，但智能体实际上陷入了无意义的循环，或走向了错误的目标。单看单次调用的成败毫无意义，必须观测整个运行（the whole run）。

OpenTelemetry（简称OTel）是由CNCF于2019年整合OpenTracing与OpenCensus两个项目后创立的开源可观测性框架。它的核心价值在于提供厂商中立的统一规范：开发者只需在代码中插入一次OTel的SDK，就能同时将追踪、指标和日志导出到任意兼容后端（如Jaeger、Prometheus、OpenSearch等），避免被单一厂商锁定。其中"语义约定（Semantic Conventions）"是OTel的重要设计——它规定了特定领域（如HTTP请求、数据库操作、GenAI调用）中各属性的标准命名与含义，使不同系统产生的遥测数据可以被统一解读和关联。正因为有了这套公共语义，一个监督智能体才能跨越不同子系统，理解各组件上报数据的真实含义，而不只是看到一堆杂乱的键值对。

Hermes的OpenTelemetry插件：补齐语义缺口

基于这个认识，团队为Hermes开发了OpenTelemetry插件。起点是GenAI的标准语义约定，但他们发现标准不足以描述智能体的完整生命周期，于是在遵循标准的基础上，补充了Hermes上下文中特有的信息字段。

这样做的目的，是能够关联不同信号（traces、logs、metrics），真正还原"智能体是如何一步步走到当前状态的"，而不只是看到孤立的日志条目。他们还特别考虑了隐私问题——很多同类插件会把智能体的全部信息一股脑收集上来，这从隐私视角很难接受。因此Hermes的插件默认只采集元数据（metadata），并提供参数控制采集哪些附加信息。

为监督者构建专用观测智能体

另一个独立的设计是SPAN验证机制，用于以独立方式判断智能体的行为是否被授权、是否越界。这与采集插件相互配合，构成两个层面的治理能力。

把智能体接入OpenSearch：数据与分析的闭环

演讲的核心亮点，是展示了Hermes与OpenSearch的双向集成。一方面，智能体产生的遥测数据写入OpenSearch的观测栈；另一方面，Hermes智能体本身可以作为分析者，去查询和解读OpenSearch中的数据。

这里引入了"Agentic Health"（智能体健康度）的概念——一个用于评估AI智能体健康状况的平台。它能定义关键任务、执行测试、借助AI分析智能体行为，甚至在同一系统上测试不同场景以对比结果。本质上，它回答的是："我们本来期望智能体做什么，它实际做了什么，二者是否一致？"

OpenSearch中的可观测性数据面板

集成的技术路径是通过OpenSearch的MCP服务器（Model Context Protocol）。Hermes Supervisor连接到OpenSearch的MCP server后，一分钟内就能调用OpenSearch中已有的工具（tools），其中包括运行在OpenSearch上的AI agents。演讲中展示的工具包括"OpenSearch Observability Investigation"、"Hermes Session Health"和"Hermes Golden Path"等。

这种设计的价值在于：无论通过哪种接口，都指向同一个"真相源"——OpenSearch。既保留了自主智能体的灵活性，又让人类可以通过统一入口进行治理和控制。

MCP（Model Context Protocol）是由Anthropic于2024年底提出并开源的协议，旨在为LLM/AI智能体提供一种标准化的"工具调用接口"。它的思路类似于USB接口：MCP Server暴露一组工具（tools）和资源（resources），任何支持MCP的客户端（智能体）无需为每个外部系统单独编写适配代码，只需连接到对应的MCP Server即可调用其能力。OpenSearch实现MCP Server后，意味着Hermes这类智能体可以用统一的协议发现并调用OpenSearch中已注册的所有分析工具，包括运行在OpenSearch上的其他AI agents。这种标准化极大降低了异构系统之间的集成成本，也是演讲中强调"一分钟内就能调用工具"的技术前提。

用智能体治理智能体，但保留Human-in-the-Loop

一个值得玩味的架构思路是：用一个专门的监督智能体（supervisor agent）去管理一群其他智能体。欧洲式的自主智能体（如Hermes）往往会自我迭代——创建新东西、修改旧代码、学习并重写脚本——因此增长很快，必须有一个更高层级的协调者。

这个监督者整合了前面提到的全部栈：OpenTelemetry、观测栈、智能体生命周期数据，并在此之上做动态分析。关键设计是：监督智能体不需要自己重新采集数据，它直接基于OpenSearch中已有的数据工作，并在必要时把人类拉回决策环中（human-in-the-loop）。

追踪与执行数据的可视化

在现场演示中，Stefano在桌面上同时运行了三个智能体：一个跑在Docker中的生命周期智能体、一个跑在Mac本地、以及监督者本身。他通过Telegram与个人助理交互，并在Hermes Desktop界面上展示了智能体从OpenSearch读取信息、生成问题分析报告的完整链路——包括谁发起、谁关注、谁记忆了相关事件。

Human-in-the-Loop（HITL）在AI系统中指在关键决策节点引入人工审核或确认，而非让系统完全自主运行。在自主智能体场景下，HITL尤为重要：智能体可能修改代码、调用外部API或产生不可逆操作，若无人工介入机制，错误决策的影响范围难以控制。监督智能体（supervisor agent）在此架构中并非取代人类监管，而是充当"自动筛选层"——它持续分析下层智能体的行为是否偏离预期，并在检测到异常或需要授权的情况下，将上下文整理后推送给人类操作者进行决策。这样既保留了智能体自主运行的效率，又避免了"全自动、无监督"带来的不可控风险，是当前生产环境中部署自主智能体的主流安全架构思路。

关于LLM选择与运行环境的工程取舍

在问答环节，演讲者分享了几点务实的工程经验：

模型选择：演示中他用了OpenAI API（因其性能强），也用过Anthropic的模型；在Docker中则运行本地LLM。对于这类垂直、专项的任务，他认为本地LLM非常值得使用，既能保护隐私，又足够胜任特定场景。
隐私控制：系统默认只采集元数据，但可通过参数配置是否发布更多信息，由此决定分析深度与隐私保护之间的平衡。
运行环境难题：他们当前在DevOps/GitOps场景中用Docker运行智能体作为开发者助手，但遇到了会话（session）管理的挑战——如何复用会话、如何处理大量并发会话。团队正在评估Kubernetes、以及像Daytona这样的沙箱平台，来运行那些"不活跃但仍需随时唤醒"的智能体。

三点总结

Stefano用三句话收束了整场演讲，这也是智能体可观测性的核心框架：

OpenTelemetry很重要，因为它是提供统一语义的通用语言；
OpenSearch是数据的落地与存储层；
智能体（agent）是控制平面（control plane），负责在所有这些数据之上做分析与治理。

从最初的问题"智能体做得怎么样"出发，答案落在了"用另一个专门的智能体去观测和治理"。这是一个仍在演进中的方向，但它清晰地指出了智能体工程化落地的下一个必答题：可观测性，不再是锦上添花，而是生产环境的刚需。