给 Hermes 装上显微镜：Agent 执行全知道

Hermes 是 Nous Research 打造的一套自治式 AI Agent 运行框架。它不是单次问答式的模型封装，而是一个能够持续运行、调用工具、积累经验、并随着使用过程不断成长的 Agent Runtime。

当一个 AI Agent 真正开始解决问题，无论它是正确完成，还是出现偏差，真正困难的问题往往都不是结果对不对，而是它到底做了什么。

Hermes 的一次运行并不是一次普通的模型调用。一次看似简单的交互，背后可能包含多轮推理、工具调用、结果回注、上下文膨胀，以及新的推理循环。模型会决定下一步是否需要工具，工具结果会反过来影响后续推理路径，而成本、时延和错误，往往都发生在这个过程中间。

如果系统只能提供最终回复、几条分散的日志，或者一次调用的 usage 汇总，那么 Hermes 依然是一个黑盒。你知道它完成了任务，却很难知道它是怎样完成的；你知道这次请求花了很多 Token，却很难知道是哪一步把成本拉高了；你知道用户体感变慢了，却很难判断到底是模型生成变慢、工具执行异常，还是 ReAct（Reasoning + Acting）轮次失控。

这正是我们为 Hermes 建设可观测能力的出发点。

今天这篇文章介绍的，是阿里云为 Hermes 提供的一套可观测插件方案。它能够把 Hermes 的真实执行过程还原为一条结构化调用链：一次会话从哪里开始，经过了多少轮推理，调用了哪些工具，花费了多少 Token，哪一步最耗时，错误又发生在哪一个节点。哪些操作是恶意的，有多少敏感数据被泄露出去了。

如果你正在把 Hermes 用到真实任务里，这些问题基本都会遇到：

• 它为什么这次这么贵？

• 它为什么这次这么慢？

• 它到底有没有真的调用那个工具？

• 它用的那个工具，有没有泄露数据？

这些问题的共同点是，它们都不是“结果”，而是“过程”。所以，如果我们只能看到最后一条回复，那么从观测角度看，Hermes 依然是不可解释的。

阿里云 Hermes 可观测插件重点解决以下四类问题。

第一类，是过程不可见。

很多系统在接入大模型之后，依然只能看到用户输入、最终输出和一条 usage 汇总。但 Hermes 的真实运行远不止如此。一次响应背后，可能有多轮推理、多次工具执行、上下文持续扩张，以及新的推理循环。没有调用链时，中间过程基本就是空白的。我们做的第一件事，就是把这段空白补出来。

第二类，是成本不可归因。

Token 账单本身不是最难的问题，最难的是你不知道钱到底花在哪里。一次 Hermes 运行之所以贵，可能是某一轮上下文突然膨胀，也可能是某个工具返回了过大的结果，还可能是最后一轮回答输出过长，或者某类任务天然就会触发更多 step。如果看不到每一轮模型调用的 Token，成本分析就只能停留在猜测。

第三类，是性能不可拆解。

用户只会告诉你“它变慢了”，但“慢”本身其实没有信息量。真正需要区分的是：首 Token 慢还是整体生成慢？是工具执行慢，还是多轮 ReAct 推理本身就跑得太长？只有把这些阶段拆开，一次“变慢”才会变成一个可以继续定位的问题。

第四类，是结果不可复盘。

很多时候最难处理的并不是明确报错，而是“看起来成功了，但结果不对”。这类问题在 Agent 系统里很常见：Hermes 调用了错误的工具，工具返回了不完整结果，Hermes 基于局部信息继续推理，最后给出了一个表面上合理、但路径已经偏掉的答案。没有链路，复盘几乎无从下手；有了链路，问题才能从“猜原因”变成“看路径”。

我们为 Hermes 构建的是一套基于 OpenTelemetry（开放遥测框架）的链路追踪能力。

它做的核心事情并不复杂：在 Hermes 所在的 Python 环境中安装 runtime instrumentation，围绕 Hermes 的关键执行边界建立 span，再通过 OTLP（OpenTelemetry Protocol）标准协议把 Trace 和指标上报到观测后端。

我们关注的不是“最后这一行回复长什么样”，而是 Hermes 的运行过程本身。

值得一提的是，这套插件并不是一套临时拼出来的埋点脚本，而是沿着 OpenTelemetry 体系来设计的。

第一，它在语义层面尽量遵循 GenAI 标准规范。当前上报的 Trace 数据优先对齐 OpenTelemetry GenAI 语义约定；对于 Agent runtime 中一些更贴近执行过程的结构，则结合 LoongSuite Semantic Conventions 做扩展。我们不是自己拍脑袋定义一批只有内部才能理解的字段名，而是尽量使用一套标准、可复用、可迁移的语义表达方式。换句话说，这不是野路子，而是一套更像“正规军”的可观测设计。

第二，它并不只提供 Trace，也提供基础 Metrics 信号。除了单次请求的调用链，我们还可以从趋势上看到调用次数、错误次数、调用耗时、Token 使用量等指标。这样既能沿着一条 Trace 复盘单次请求，也能从全局视角观察成本波动、性能变化和异常趋势。

第三，它对 streaming 场景单独记录了 TTFT。很多时候用户感知到“慢”，并不一定是整段生成都慢，而是第一个字迟迟没有返回。有了 TTFT，性能问题才能从“感觉慢”进一步拆成“首字慢”还是“整体生成慢”。

第四，它在后端对接上并不绑定单一云服务。当前方案可以直接接入阿里云 ARMS，但底层走的是 OTLP 标准协议，设计上并不是锁死在某个私有数据结构里。今天接 ARMS 没问题，后续如果需要对接其他兼容 OTLP 的后端，也保留了迁移空间。

第五，它支持对 Hermes 高危行为进行安全审计。通过采集 Hermes 系统全量操作日志、访问记录及用户行为数据，结合异常检测算法建立动态审计模型，它可精准识别越权访问、异常数据导出、恶意提示词注入等可疑行为。

当前版本的 Hermes 可观测能力，已经可以把一次真实的 Agent 运行还原成 ReAct 结构化 Trace。

核心链路形态如下：

如果一次任务包含多轮推理和多次工具调用，链路会自然展开：

这条链路的意义不在于 span 变多了，而在于 Hermes 的真实执行方式第一次变得可见。

一次执行到底跑了几轮，哪一轮触发了工具，工具又是怎样影响后续推理的，现在都可以在同一条 Trace 中展开查看。

每个 chat span 当前已经可以记录：

• gen_ai.request.model

• gen_ai.usage.input_tokens

• gen_ai.usage.output_tokens

• gen_ai.usage.total_tokens

• gen_ai.response.time_to_first_token

这代表我们终于可以按“每一次真实模型调用”来看 Token 和时延，而不是只看一次会话的总账。尤其是在 streaming 场景下，TTFT（Time To First Token，首字延迟）可以帮助我们进一步区分：到底是首字返回慢，还是整体生成过程慢。

每个 execute_tool span 当前已经可以记录：

• gen_ai.tool.name

• gen_ai.tool.call.arguments

• gen_ai.tool.call.result

工具不再只是过程中的空白节点。我们能够看到 Hermes 在什么时候决定调用工具、调用了哪个工具、传了什么参数，以及返回了什么结果。

根节点 invoke_agent Hermes span 当前已经可以记录整次运行的聚合结果，包括：

• 累计 Token

• 最终输出消息

• 总时耗信息

全链路记录 Agent 行为，智能生成审计视图，让危险操作无处遁形。

Hermes 这套可观测能力的接入路径，我们尽量精简为一个非常直接的流程：先去控制台拿命令，再复制到终端执行，然后开启插件、启动 Hermes，就可以开始上报。

先去控制台获取安装命令

登录 CMS 2.0 （Cloud Monitor Service 2.0）控制台（https://cmsnext.console.aliyun.com/），进入对应的应用监控 Workspace（工作空间），选择接入中心 - AI 应用可观测，点击 Hermes。

在侧边栏中，输入应用名，点击获取，即可立即生成接入命令，点击右上角便可一键复制！

一行命令，开始安装

在 Hermes 所在机器上打开终端，把刚刚复制的命令粘贴进去执行：

curl -fsSL https://arms-apm-cn-hangzhou-pre.oss-cn-hangzhou.aliyuncs.com/hermes-agent-cms-plugin/hermes-cms.sh | bash -s -- install \  --x-arms-license-key "auto" \  --x-arms-project "你的Project" \  --x-cms-workspace "你的Workspace" \  --serviceName "hermes" \  --endpoint "https://你的ARMS-OTLP地址/apm/trace/opentelemetry"

首次执行安装命令时，除了安装插件本身，系统还会在本机注册 hermes-cms 命令，供后续执行 enable、disable、uninstall 等操作。

如果终端出现下面这段提示，就说明插件已经安装成功：

整个过程中，你不需要手动编辑配置文件，脚本会优先匹配当前环境，只有在当前环境不满足时，才会继续尝试官方默认安装位置。

开启可观测，然后启动 Hermes

安装完成后，先不要急着看控制台。

第一步是先把可观测开关打开：

hermes-cms enable

然后再启动 Hermes。

前台运行可直接执行：

hermes

后台运行可执行：

hermes gateway install

hermes gateway start

怎么确认埋点真的生效了

如果启动后终端出现下面这条提示，就说明可观测埋点已经生效：

loongsuite-site-bootstrap: started successfully (OpenTelemetry auto-instrumentation initialized).

确认埋点生效之后，再向 Hermes 发送几条测试请求，跑一个会触发多轮推理和工具调用的真实任务。等一两分钟后，回到 CMS 2.0 控制台，就可以在 AI 应用可观测里看到你的 Hermes 应用了。

到这一步，Hermes 就不再只是一个黑盒回复器了，它开始变成一个能被展开、能被追踪、能被分析的运行系统。

进入我们的可观测应用中，不仅能实时看到 Hermes 的模型调用次数、Token 消耗趋势、请求波动、平均每次请求的 LLM 调用轮数，以及 AGENT、LLM、TOOL 各阶段的耗时与调用分布；还可以沿着一条完整 Trace 还原 Hermes 的真实执行过程，清楚看到一次任务经过了多少轮推理、调用了哪些工具、哪一步最耗时、哪一轮最费 Token。

演示示例可在 https://sls.aliyun.com/doc/playground/cmsdemo.html 中查看 hermes_agentloop_support 示例。

想关闭或卸载？也很直接

如果你只是临时关闭可观测，可以执行：

hermes-cms disable

如果你想彻底卸载插件，可以执行：

hermes-cms uninstall

在接入卡片配置应用信息

接下来，点击“日志接入”页面，设置好自定义的应用名并点击初始化资源，填入前面设置的 Project 名，并按照提示配置好机器组，就一键完成了 Hermes 审计功能。

审计大盘自动生成

完成接入后，在左侧侧边栏依次点击“审计”-“Hermes 洞察”-“Hermes 审计”，就可以看到你的 Hermes Agent 的审计大盘。

这套方案已经能够稳定解决链路追踪、Token 归因和基础性能拆解问题，同时也提供了可用于趋势分析的基础 Metrics 信号；但它并不意味着 Hermes 的所有可观测工作都已经完成。

接下来，我们还会沿着几个方向继续推进。

• 在数据面上，继续从 Trace、Span 属性和基础指标向更完整的日志审计与运行诊断能力扩展。

• 在链路面上，继续细化 Agent、step、llm、tool 之外的 Hermes 特有执行阶段，例如 memory lifecycle（记忆管理生命周期）、delegation orchestration（委托编排）、runtime recovery（运行时恢复） 等能力。

• 在治理面上，继续加强内容采集控制、更细粒度的数据治理能力，以及统一脱敏和安全策略建设。

我们今天已经有了一套可用的 runtime 可观测基础设施，而接下来的目标，是把它进一步演进成一套更完整、更细致、也更适合真实生产环境的 Agent 可观测体系。