第 17 期 | 日志系统与可观测性实践

20 分钟阅读 | 更新于：2026-05-07

深入 Hermes 的日志体系——对话历史追溯、Skill 执行追踪、错误诊断与调试。接入 Langfuse/LangSmith 等 LLM 可观测性平台实现全链路监控。

🎯 学习目标

理解 Hermes Agent 内置的日志体系，包括日志级别、存储位置与输出格式。
掌握如何利用 Hermes Agent 的日志来追溯对话历史、追踪 Skill 执行流程及进行错误诊断。
了解 LLM 可观测性（Observability）的核心概念，以及 Langfuse/LangSmith 等平台的价值。
探索将 Hermes Agent 的运行数据与外部 LLM 可观测性平台进行集成或同步的策略。

📖 核心概念讲解

17.1 Hermes Agent 的内置日志体系

作为一款自进化的 AI 代理，Hermes Agent 在其运行过程中会产生大量的内部信息，这些信息对于理解代理的行为、调试问题以及优化性能至关重要。Hermes Agent 内置了一套完善的日志体系，记录了从启动到任务完成的每一个关键环节。

Hermes Agent 的日志主要记录以下几类信息：

代理思考过程 (Agent Thoughts)：这是代理进行决策、规划、反思的核心记录。包括代理对当前任务的理解、选择工具/Skill 的理由、生成下一步行动计划等。这些日志是理解代理“心智”的关键。
LLM 调用 (LLM Calls)：代理与大型语言模型（LLM）之间的每一次交互都会被记录。包括发送给 LLM 的提示词 (prompt)、接收到的响应 (response)、使用的模型名称、Token 消耗等。这对于分析 LLM 的表现、成本以及调试提示词非常有用。
Skill 执行 (Skill Execution)：当代理决定调用一个 Skill 时，其调用过程、输入参数、执行结果（成功或失败）以及任何错误信息都会被详细记录。这与我们在第 03 期 | Skills 系统深度剖析中讨论的 Skill 生命周期紧密相关。
内存操作 (Memory Operations)：Hermes Agent 具有跨会话记忆能力（参见第 04 期 | Memory 与用户画像）。对记忆的读取、写入、更新等操作也会被记录，有助于理解代理如何利用历史信息。
系统事件与错误 (System Events & Errors)：包括代理启动/停止、配置加载、外部服务连接状态、以及任何在运行过程中发生的异常或错误。

日志级别与配置：

Hermes Agent 支持标准的日志级别，如 DEBUG, INFO, WARNING, ERROR, CRITICAL。默认情况下，通常会以 INFO 级别输出。我们可以通过 hermes config set 命令来调整日志级别，以获取更详细或更简洁的输出。

INFO: 提供高层级的操作信息，例如任务开始、任务完成、主要决策点。
DEBUG: 提供最详细的内部操作信息，包括 LLM 的完整提示词和响应、Skill 的详细执行步骤、中间思考过程等。在开发和调试阶段非常有用。
WARNING, ERROR, CRITICAL: 用于报告潜在问题、错误和严重故障。

日志的输出位置：

Hermes Agent 的日志默认会输出到标准输出 (stdout)，这意味着你在终端运行 hermes 命令时会直接看到日志信息。在生产环境中，通常会将日志重定向到文件，或者通过日志管理工具进行收集。

# 查看当前日志级别配置
hermes config get log_level

# 将日志级别设置为 DEBUG，以便获取最详细的输出
# 这对于调试和深入理解代理行为至关重要
hermes config set log_level debug

# 运行一个 Hermes Agent 任务，观察详细的 DEBUG 日志输出
# 例如，让 Agent 编写一个简单的 Python 函数
hermes "写一个 Python 函数，计算斐波那契数列的第 n 项。"

通过将日志级别设置为 DEBUG，你将能够看到代理的每一个思考步骤、LLM 的完整输入输出，以及 Skill 调用的详细过程。这为我们提供了强大的可观测性，帮助我们理解代理的决策路径和潜在问题。

17.2 日志解读与问题诊断

深入理解 Hermes Agent 的日志是高效使用和调试的关键。日志不仅记录了代理的“足迹”，更是我们追溯问题、优化行为的“侦探工具”。

追溯对话历史与代理思考：

当 Hermes Agent 运行时，它会进行一系列的思考、规划和执行。这些过程在 DEBUG 级别的日志中清晰可见。

代理思考 (Agent Thoughts)：日志中会包含 [AGENT THOUGHT] 或 [PLAN] 等标记，后面跟着代理的内部独白。例如，代理可能会说：“我需要一个 Skill 来生成代码，然后测试它。”
LLM 交互 (LLM Interaction)：你会看到 [LLM CALL] 或 [PROMPT] 标记，后面是发送给 LLM 的完整提示词，以及 [LLM RESPONSE] 或 [RESPONSE] 标记，后面是 LLM 的回答。这对于分析提示词效果、调试 LLM 行为非常重要。

# 示例日志片段 (DEBUG 级别)
[2023-10-27 10:30:05.123 DEBUG] [AGENT] Current Task: 写一个 Python 函数，计算斐波那契数列的第 n 项。
[2023-10-27 10:30:05.124 DEBUG] [AGENT THOUGHT] 我需要思考如何完成这个任务。首先，我需要一个能够生成 Python 代码的工具。
[2023-10-27 10:30:05.125 DEBUG] [LLM CALL] Sending prompt to LLM (model: gpt-4-turbo-preview):
---
You are a helpful AI assistant.
... (truncated prompt for brevity) ...
User: 写一个 Python 函数，计算斐波那数列的第 n 项。
---
[2023-10-27 10:30:07.890 DEBUG] [LLM RESPONSE] Received response from LLM:
---
<tool_code>
print_python_code("def fibonacci(n):\n    if n <= 0:\n        return []\n    elif n == 1:\n        return [0]\n    else:\n        list_fib = [0, 1]\n        while len(list_fib) < n:\n            next_fib = list_fib[-1] + list_fib[-2]\n            list_fib.append(next_fib)\n        return list_fib\n")
</tool_code>
---
[2023-10-27 10:30:07.891 DEBUG] [AGENT] Tool call detected: print_python_code
[2023-10-27 10:30:07.892 DEBUG] [SKILL EXECUTION] Calling skill 'print_python_code' with args: {'code': 'def fibonacci(n):\n    ...'}
[2023-10-27 10:30:07.895 INFO] [SKILL] Skill 'print_python_code' executed successfully.

通过这些日志，我们可以清晰地看到代理如何接收任务，如何思考，如何与 LLM 交互，以及最终调用了哪个 Skill 来完成任务。

Skill 执行追踪与错误诊断：

Skill 是 Hermes Agent 完成任务的核心能力单元。当 Skill 执行失败时，日志是诊断问题的首要来源。

Skill 调用追踪：日志会明确指出哪个 Skill 被调用，传入了哪些参数。这有助于确认代理是否正确理解了任务并选择了合适的 Skill。
Skill 内部错误：如果 Skill 在执行过程中发生异常（例如，代码错误、外部 API 调用失败），这些错误通常会在 [ERROR] 或 [WARNING] 级别被记录，并附带堆栈跟踪 (stack trace)。

常见的 Skill 错误诊断场景：

参数错误：代理向 Skill 传递了不正确的参数类型或值。日志会显示 Skill 接收到的参数，你可以与 Skill 的预期参数进行对比。
外部服务故障：如果 Skill 依赖于外部 API 或服务（例如，查询天气、发送邮件），当这些服务不可用或返回错误时，Skill 会捕获并记录相关错误。
Skill 逻辑错误：Skill 自身的 Python 代码存在 bug。日志中的堆栈跟踪会指向具体出错的代码行。
权限问题：Skill 尝试执行某个操作但缺乏必要的权限。

# 假设我们有一个名为 'read_file' 的 Skill，但尝试读取一个不存在的文件
# 在 DEBUG 模式下运行，观察错误日志

# 首先确保 log_level 是 debug
hermes config set log_level debug

# 尝试让 Agent 读取一个不存在的文件 (假设当前目录下没有 'non_existent_file.txt')
# 假设 Agent 会尝试调用一个名为 'read_file' 的 Skill
hermes "读取文件 'non_existent_file.txt' 的内容。"

预期日志输出示例（部分）：

[2023-10-27 10:35:10.123 DEBUG] [AGENT THOUGHT] 我需要读取一个文件，我将使用 'read_file' Skill。
[2023-10-27 10:35:10.124 DEBUG] [LLM CALL] Sending prompt to LLM (model: gpt-4-turbo-preview):
...
[2023-10-27 10:35:12.567 DEBUG] [LLM RESPONSE] Received response from LLM:
---
<tool_code>
read_file("non_existent_file.txt")
</tool_code>
---
[2023-10-27 10:35:12.568 DEBUG] [AGENT] Tool call detected: read_file
[2023-10-27 10:35:12.569 DEBUG] [SKILL EXECUTION] Calling skill 'read_file' with args: {'file_path': 'non_existent_file.txt'}
[2023-10-27 10:35:12.570 ERROR] [SKILL] Skill 'read_file' failed with error:
Traceback (most recent call last):
  File ".../hermes-agent/skills/read_file.py", line 15, in execute
    with open(file_path, 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: 'non_existent_file.txt'
[2023-10-27 10:35:12.571 DEBUG] [AGENT] Skill 'read_file' execution failed. Error: FileNotFoundError: [Errno 2] No such file or directory: 'non_existent_file.txt'
[2023-10-27 10:35:12.572 DEBUG] [AGENT THOUGHT] Skill 'read_file' 失败了，因为文件不存在。我需要向用户报告这个错误。

通过上述日志，我们可以清晰地看到 read_file Skill 尝试读取文件，但由于 FileNotFoundError 导致失败，并且代理捕获了这个错误并准备向用户反馈。

17.3 LLM 可观测性平台概览

随着基于大型语言模型（LLM）的应用日益复杂，传统的日志系统已不足以提供全面的洞察。LLM 可观测性平台应运而生，旨在提供端到端的可见性，帮助开发者理解、调试和优化 LLM 驱动的应用。其中，Langfuse 和 LangSmith 是两个领先的解决方案。

为什么需要 LLM 可观测性平台？

复杂性：LLM 应用通常涉及多轮对话、工具调用、RAG（Retrieval-Augmented Generation，检索增强生成）、Agent 决策链等，其内部状态和流程难以通过简单的日志追踪。
不确定性：LLM 的输出具有非确定性，同样的输入可能产生不同的输出。可观测性平台有助于理解这种变异性。
黑盒问题：LLM 本身是一个黑盒，很难直接看到其内部推理过程。平台通过记录提示词、响应、中间步骤来“揭示”黑盒。
性能与成本：LLM 调用会消耗 Token 和计算资源，产生费用。平台可以监控 Token 使用、延迟和成本，帮助优化。
质量与迭代：评估 LLM 应用的质量并进行持续改进需要大量的实验数据、A/B 测试和用户反馈。平台提供了收集和分析这些数据的能力。

核心功能：

LLM 可观测性平台通常提供以下核心功能：

追踪 (Traces) 与跨度 (Spans)：
- Trace (追踪)：表示一个完整的用户请求或 Agent 任务的端到端执行流。例如，从用户输入到 Agent 最终响应的整个过程。
- Span (跨度)：Trace 的一个组成部分，代表一个独立的操作或步骤。例如，一个 LLM 调用、一个 Skill 执行、一个数据检索操作。Spans 可以嵌套，形成一个树状结构，清晰地展示了操作的因果关系和时间序列。
- 通过 Trace 和 Span，我们可以可视化地看到 Agent 的决策路径、LLM 交互、工具使用等所有步骤，以及它们之间的关系和耗时。
输入/输出记录 (Inputs/Outputs)：记录每次 LLM 调用或 Skill 执行的完整输入（例如，提示词、参数）和输出（例如，LLM 响应、Skill 结果）。
元数据与标签 (Metadata & Tags)：允许为 Trace 和 Span 附加自定义元数据（例如，用户 ID、会话 ID、模型版本），以便进行过滤、搜索和聚合分析。
成本与性能监控 (Cost & Performance Monitoring)：自动计算每次 LLM 调用的 Token 消耗和费用，以及每个步骤的延迟。
评估与标注 (Evaluation & Annotation)：支持人工对 LLM 输出进行质量评估、标注，或集成自动化评估指标，从而持续改进模型和应用。
数据集管理 (Dataset Management)：从实际运行数据中提取有价值的提示词、响应、工具调用序列，构建用于微调、回归测试和评估的数据集。

Langfuse 和 LangSmith 的特点：

Langfuse (https://langfuse.com/): 开源且可自托管，提供了强大的追踪、评估、提示工程和数据集管理功能。它与 LangChain 等框架紧密集成，也支持其他 LLM 框架和自定义集成。
LangSmith (https://www.langchain.com/langsmith): LangChain 官方提供的平台，与 LangChain 生态系统无缝集成，提供类似的追踪、调试、评估和监控功能。

这些平台通过提供结构化的数据捕获和强大的可视化界面，极大地提升了 LLM 应用的开发、调试和维护效率。

17.4 Hermes Agent 与外部可观测性平台的集成策略

Hermes Agent 本身是一个独立的 CLI 工具，其核心交互通过终端进行。虽然它没有直接内置 Langfuse 或 LangSmith 的客户端集成，但我们可以通过几种策略将其运行数据与这些外部可观测性平台进行桥接，实现更高级的监控和分析。

集成策略主要围绕如何从 Hermes Agent 的运行中捕获关键事件，并将其转换为可观测性平台所需的结构化数据格式（例如，Trace 和 Span）。

策略一：利用 Hermes Agent 的详细日志输出进行后处理

这是最直接且无需修改 Hermes Agent 核心代码的方法。

启用详细日志：将 Hermes Agent 的 log_level 设置为 DEBUG，确保所有内部思考、LLM 调用、Skill 执行等信息都被输出。
捕获日志流：将 Hermes Agent 的标准输出重定向到一个文件，或者通过管道 (pipe) 发送给一个自定义的日志解析器。
日志解析器：编写一个 Python 脚本或一个独立的进程，实时或定期地解析 Hermes Agent 的日志文件。这个解析器需要：
- 识别关键的日志模式（例如 [AGENT THOUGHT], [LLM CALL], [SKILL EXECUTION], [ERROR]）。
- 从日志条目中提取结构化信息（例如，LLM 模型名称、提示词内容、响应内容、Skill 名称、参数、执行结果、错误信息）。
- 将这些信息映射到可观测性平台（如 Langfuse SDK）的 Trace 和 Span 模型。
例如，当解析器看到 [LLM CALL] 时，可以创建一个新的 Langfuse span，类型为 llm；当看到 [SKILL EXECUTION] 时，创建一个类型为 tool 的 span。通过关联 trace_id 和 parent_span_id，可以构建出完整的执行链。

优点：无需修改 Hermes Agent 源码，通用性强。缺点：解析复杂，可能存在漏报或误报，实时性取决于解析器的实现。

策略二：通过自定义 Skill 报告关键事件

如果希望在特定 Agent 行为发生时进行报告，可以创建自定义的 Skill 来与可观测性平台交互。

创建报告 Skill：编写一个或多个新的 Hermes Skill，例如 report_llm_call, report_skill_execution, report_agent_thought。
集成 SDK：在这些 Skill 的 Python 代码中，集成 Langfuse 或 LangSmith 的 Python SDK。
Agent 决策调用：通过提示工程，引导 Agent 在完成 LLM 调用或 Skill 执行后，主动调用这些报告 Skill，将相关信息传递给它们。

例如，Agent 在完成一个 code_generation Skill 后，可以调用 report_skill_execution(skill_name="code_generation", result="success", ...)。

优点：事件报告更精确，可以捕获 Agent 内部的更高级别决策。缺点：需要修改 Agent 的行为（通过提示词引导），增加了 Agent 任务本身的复杂性，并且可能无法捕获所有底层细节。

策略三：修改 Hermes Agent 核心代码（高级）

对于需要深度集成和最高控制力的场景，可以直接修改 Hermes Agent 的 Python 源代码，在其关键执行点（例如，LLM 调用的地方、Skill 执行器）注入可观测性平台的 SDK 调用。

定位关键代码：找到 Hermes Agent 中负责 LLM 调用、Skill 调度、Agent 思考循环的代码位置。
注入 SDK 调用：在这些位置添加 Langfuse 或 LangSmith SDK 的 trace、span、event 等 API 调用，将相应的输入、输出、元数据发送到平台。

优点：最彻底的集成，可以捕获所有细节，实现实时、结构化的数据上报。缺点：需要熟悉 Hermes Agent 的内部实现，修改后需要自行维护，不易升级。

实施 Langfuse 集成的概念性步骤 (基于策略一或三)：

这里以 Langfuse 为例，假设我们通过日志解析器或直接修改代码的方式进行集成。

安装 Langfuse SDK：
```
pip install langfuse
```

配置 Langfuse 环境变量：

export LANGFUSE_PUBLIC_KEY="pk_..."
export LANGFUSE_SECRET_KEY="sk_..."
export LANGFUSE_HOST="https://cloud.langfuse.com" # 或你的自托管地址

在解析器或修改后的代码中初始化 Langfuse：
```
from langfuse import Langfuse
langfuse = Langfuse()
```

创建 Trace 和 Span：当一个用户请求进入 Hermes Agent 时，创建一个 trace。

trace = langfuse.trace(name="Hermes Agent Task", input={"user_prompt": "..."})

当 Hermes Agent 进行一次 LLM 调用时，创建一个 span 并关联到当前 trace。

llm_span = trace.llm(
    name="Agent Decision LLM Call",
    input={"messages": [{"role": "user", "content": "..."}]},
    model="gpt-4-turbo-preview",
    metadata={"step": "planning"}
)
# 模拟 LLM 响应
llm_span.end(output={"completion": "..."})

当 Hermes Agent 执行一个 Skill 时，创建一个 span 并关联到当前 trace。

skill_span = trace.span(
    name="Execute Skill",
    input={"skill_name": "...", "args": {...}},
    metadata={"skill_type": "tool"}
)
# 模拟 Skill 结果
skill_span.end(output={"result": "..."})

在 Trace 结束时，调用 trace.end()。

通过上述策略，我们可以将 Hermes Agent 的内部运行状态、决策过程、LLM 交互和 Skill 执行结果，以结构化、可追溯的方式呈现到 Langfuse/LangSmith 等可观测性平台上，从而获得对 Agent 行为的全面监控和深度洞察。

💻 实战演示

我们将通过终端交互来演示如何利用 Hermes Agent 的日志进行调试和追踪。

场景一：追踪 Agent 的思考过程与 Skill 调用

我们将让 Hermes Agent 执行一个涉及 Skill 调用的任务，并观察其在 DEBUG 级别日志下的详细输出。

操作步骤：

设置日志级别为 DEBUG：

hermes config set log_level debug

预期输出：

Set 'log_level' to 'debug'.

启动一个涉及 Skill 调用的任务：我们假设 Hermes Agent 默认集成了 write_file 和 read_file 这样的基本文件操作 Skill。我们将让它写一个文件，然后尝试读取它。
```
hermes "创建一个名为 'my_notes.txt' 的文件，内容是 'Hermes Agent 学习笔记。'。然后读取这个文件的内容并告诉我。"
```

预期输出（部分关键日志）：

你将看到大量的 DEBUG 级别日志。以下是关键部分的示例：

[2023-10-27 11:00:01.123 DEBUG] [AGENT] Current Task: 创建一个名为 'my_notes.txt' 的文件，内容是 'Hermes Agent 学习笔记。'。然后读取这个文件的内容并告诉我。
[2023-10-27 11:00:01.124 DEBUG] [AGENT THOUGHT] 我需要先创建一个文件，然后读取它。这需要两个步骤：首先使用 'write_file' 工具，然后使用 'read_file' 工具。
[2023-10-27 11:00:01.125 DEBUG] [LLM CALL] Sending prompt to LLM (model: gpt-4-turbo-preview):
---
You are a helpful AI assistant.
...
User: 创建一个名为 'my_notes.txt' 的文件，内容是 'Hermes Agent 学习笔记。'。然后读取这个文件的内容并告诉我。
---
[2023-10-27 11:00:03.500 DEBUG] [LLM RESPONSE] Received response from LLM:
---
<tool_code>
write_file("my_notes.txt", "Hermes Agent 学习笔记。")
</tool_code>
---
[2023-10-27 11:00:03.501 DEBUG] [AGENT] Tool call detected: write_file
[2023-10-27 11:00:03.502 DEBUG] [SKILL EXECUTION] Calling skill 'write_file' with args: {'file_path': 'my_notes.txt', 'content': 'Hermes Agent 学习笔记。'}
[2023-10-27 11:00:03.505 INFO] [SKILL] Skill 'write_file' executed successfully.
[2023-10-27 11:00:03.506 DEBUG] [AGENT THOUGHT] 文件已创建。现在我需要读取它。
[2023-10-27 11:00:03.507 DEBUG] [LLM CALL] Sending prompt to LLM (model: gpt-4-turbo-preview):
...
[2023-10-27 11:00:05.800 DEBUG] [LLM RESPONSE] Received response from LLM:
---
<tool_code>
read_file("my_notes.txt")
</tool_code>
---
[2023-10-27 11:00:05.801 DEBUG] [AGENT] Tool call detected: read_file
[2023-10-27 11:00:05.802 DEBUG] [SKILL EXECUTION] Calling skill 'read_file' with args: {'file_path': 'my_notes.txt'}
[2023-10-27 11:00:05.805 INFO] [SKILL] Skill 'read_file' executed successfully. Output: Hermes Agent 学习笔记。
[2023-10-27 11:00:05.806 DEBUG] [AGENT THOUGHT] 我已成功读取文件内容。现在我将向用户报告。
[2023-10-27 11:00:05.807 DEBUG] [LLM CALL] Sending prompt to LLM (model: gpt-4-turbo-preview):
...
[2023-10-27 11:00:07.900 DEBUG] [LLM RESPONSE] Received response from LLM:
---
文件 'my_notes.txt' 的内容是："Hermes Agent 学习笔记。"
---
[2023-10-27 11:00:07.901 INFO] [AGENT] Task completed.
文件 'my_notes.txt' 的内容是："Hermes Agent 学习笔记。"

分析： 从这些日志中，我们可以清晰地看到 Agent 的多步思考过程：先是规划使用 write_file，然后是 read_file。每次 LLM 调用都记录了发送的 Prompt 和接收的 Response，以及 Skill 的调用和结果。这对于理解 Agent 如何分解任务、如何与 LLM 交互以及如何执行 Skill 提供了全面的视图。

场景二：诊断 Skill 执行错误

我们将通过一个故意制造的错误来演示如何利用 DEBUG 日志诊断 Skill 执行失败。

操作步骤：

确保日志级别仍为 DEBUG (如果不是，请先执行 hermes config set log_level debug)。

尝试让 Agent 调用一个不存在的 Skill：

hermes "使用一个叫做 'non_existent_skill' 的工具，参数是 'hello world'。"

预期输出（部分关键日志）：

[2023-10-27 11:05:01.123 DEBUG] [AGENT] Current Task: 使用一个叫做 'non_existent_skill' 的工具，参数是 'hello world'。
[2023-10-27 11:05:01.124 DEBUG] [AGENT THOUGHT] 用户要求我使用一个特定的工具。我需要尝试调用它。
[2023-10-27 11:05:01.125 DEBUG] [LLM CALL] Sending prompt to LLM (model: gpt-4-turbo-preview):
---
You are a helpful AI assistant.
...
User: 使用一个叫做 'non_existent_skill' 的工具，参数是 'hello world'。
---
[2023-10-27 11:05:03.500 DEBUG] [LLM RESPONSE] Received response from LLM:
---
<tool_code>
non_existent_skill("hello world")
</tool_code>
---
[2023-10-27 11:05:03.501 DEBUG] [AGENT] Tool call detected: non_existent_skill
[2023-10-27 11:05:03.502 ERROR] [SKILL] Skill 'non_existent_skill' not found. Available skills: write_file, read_file, ... (此处会列出所有可用 Skill)
[2023-10-27 11:05:03.503 DEBUG] [AGENT] Skill 'non_existent_skill' execution failed. Error: Skill 'non_existent_skill' not found.
[2023-10-27 11:05:03.504 DEBUG] [AGENT THOUGHT] 我尝试调用 'non_existent_skill'，但它不存在。我需要向用户报告这个错误。
[2023-10-27 11:05:03.505 DEBUG] [LLM CALL] Sending prompt to LLM (model: gpt-4-turbo-preview):
...
[2023-10-27 11:05:05.800 DEBUG] [LLM RESPONSE] Received response from LLM:
---
我无法找到名为 'non_existent_skill' 的工具。请检查工具名称是否正确，或者我是否拥有该工具。
---
[2023-10-27 11:05:05.801 INFO] [AGENT] Task completed.
我无法找到名为 'non_existent_skill' 的工具。请检查工具名称是否正确，或者我是否拥有该工具。

分析： 日志清晰地显示了 Agent 尝试调用 non_existent_skill，但紧接着就出现了 [ERROR] [SKILL] Skill 'non_existent_skill' not found. 的错误信息。Agent 捕获了这个错误，并向用户返回了相应的错误提示。这演示了日志如何帮助我们快速识别和诊断 Skill 相关的配置或调用问题。

场景三：使用 `hermes doctor` 进行初步诊断

hermes doctor 命令提供了一个快速检查 Hermes Agent 运行时环境和配置的工具，虽然不是日志系统本身，但它与可观测性紧密相关，可以作为初步诊断的一部分。

操作步骤：

运行 hermes doctor 命令：
```
hermes doctor
```

预期输出：

Checking Hermes Agent environment...

✅ Python version: 3.x.x
✅ Hermes Agent installed: x.x.x
✅ Configuration loaded: ~/.config/hermes/config.json
✅ LLM Provider configured: OpenRouter (or your configured provider)
✅ OpenRouter API Key set: True (if configured, or False if not)
✅ Skills directory found: ~/.config/hermes/skills
✅ Memory directory found: ~/.config/hermes/memory
✅ Network connectivity: OK

All checks passed! Your Hermes Agent seems to be in good health.
(Or, it might show warnings/errors if any issues are found, e.g., missing API key)

分析： hermes doctor 快速检查了关键的系统依赖、配置、API 密钥和目录结构。如果其中任何一项有问题，它会立即报告，这有助于在深入分析日志之前排除常见的环境或配置问题。例如，如果 OpenRouter API Key set: False，那么 Agent 所有的 LLM 调用都将失败。

🔧 涉及的命令与工具

| 命令/工具 | 描述 | 示例 | 关联课程 ```


---

## 📝 本期要点回顾

*   Hermes Agent 具备强大的内置日志系统，用于追踪代理思考、LLM 调用、Skill 执行和系统事件，是理解和调试代理行为的关键。
*   通过将 `log_level` 设置为 `debug`，可以获得最详细的日志输出，包含代理的决策过程、完整的 LLM 提示词和响应。
*   日志是诊断 Skill 执行失败、LLM 交互问题以及代理行为异常的首要工具，通过关键词和错误栈可快速定位问题。
*   LLM 可观测性平台（如 Langfuse、LangSmith）为复杂的 LLM 应用提供了端到端的可视化追踪、评估和监控能力，弥补了传统日志的不足。
*   将 Hermes Agent 与外部可观测性平台集成，可以通过解析其详细日志、创建自定义报告 Skill 或直接修改源代码等策略实现，从而获得更全面的洞察。

---

## 🔗 参考资料

1.  **Hermes Agent 官方文档**：深入了解 Hermes Agent 的架构与功能。
    [https://hermes-agent.nousresearch.com/docs/](https://hermes-agent.nousresearch.com/docs/)
2.  **Hermes Agent GitHub 项目**：查阅最新的代码、Skill 实现和社区讨论。
    [https://github.com/NousResearch/hermes-agent](https://github.com/NousResearch/hermes-agent)
3.  **Langfuse 官方文档**：了解 LLM 可观测性平台的概念和 Langfuse 的使用方法。
    [https://langfuse.com/docs](https://langfuse.com/docs)
4.  **LangSmith 官方文档**：了解 LangChain 官方的可观测性解决方案。
    [https://docs.smith.langchain.com/](https://docs.smith.langchain.com/)

← 上一课时第 16 期 | 性能调优与 Token 经济学

下一课时 → 第 18 期 | 生产环境部署：VPS 到 GPU 集群

🎯 学习目标

📖 核心概念讲解

17.1 Hermes Agent 的内置日志体系

17.2 日志解读与问题诊断

17.3 LLM 可观测性平台概览

17.4 Hermes Agent 与外部可观测性平台的集成策略

💻 实战演示

场景一：追踪 Agent 的思考过程与 Skill 调用

场景二：诊断 Skill 执行错误

场景三：使用 hermes doctor 进行初步诊断

🔧 涉及的命令与工具

场景三：使用 `hermes doctor` 进行初步诊断