**给 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。
核心链路形态如下：
invoke_agent Hermes
└── react step
├── chat
└── execute_tool <tool_name>
如果一次任务包含多轮推理和多次工具调用，链路会自然展开：
这条链路的意义不在于 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 在什么时候决定调用工具、调用了哪个工具、传了什么参数，以及返回了什么结果。
**Agent 级汇总**
根节点 invoke_agent Hermes span 当前已经可以记录整次运行的聚合结果，包括：
- 累计 Token
- 最终输出消息
- 总时耗信息
**高危行为审计**
全链路记录Agent行为，智能生成审计视图，让危险操作无处遁形
**快速可观测接入：几步完成部署**
Hermes 这套可观测能力的接入路径，我们尽量精简为一个非常直接的流程：先去控制台拿命令，再复制到终端执行，然后开启插件、启动 Hermes，就可以开始上报。
**Tracing接入**
**先去控制台获取安装命令**
登录 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-agent-cms-plugin installed successfully!
════════════════════════════════════════════════════
整个过程中，你不需要手动编辑配置文件，脚本会优先匹配当前环境，只有在当前环境不满足时，才会继续尝试官方默认安装位置。
**开启可观测，然后启动 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 可观测体系。