国士九颜最近把 OpenClaw 接进几个真实业务场景之后，我最大的感受是：它能干的事确实多，但你根本不知道它内部到底发生了什么。飞书机器人回错消息、定时任务“按时执行但结果全错”、某个 skill 时好时坏——这些问题不用可观测性去定位，基本就是盲人摸象。这篇文章是“OpenClaw 全面解析：从零到精通”系列的第 024 篇，重点拆解三个方案：OpenClaw 自带的 Clawmetry、Comet 开源的 Opik、以及行业标准的 OpenTelemetry。如果你已经跑通了 OpenClaw 基础功能，但遇到问题只能靠猜，或者正准备把 OpenClaw 放到生产环境，这篇应该能帮你把“黑盒”变成“透明盒”。
1. 为什么 AI 代理比普通服务更需要可观测性：从一次“看似成功”的定时任务说起
1.1 定时任务执行完毕，但答案完全错误：问题出在哪一层
先讲一个我实际踩过的场景。之前用 OpenClaw 跑了一个每天早上 8 点的定时任务，逻辑很简单：把前一天多渠道的销售数据汇总后发到飞书群。某天早上任务照常执行，日志显示一切正常，飞书也收到了消息，但数字明显不对。一开始我怀疑是数据源接口出了问题，花了大半个小时查上游 API，结果发现一切正常；再查计算逻辑，也找不到毛病。最后实在没办法，把那次任务的完整执行过程扒出来，才发现模型在第二步调用工具时，把“汇总近 7 天”理解成了“只汇总昨天”，更隐蔽的是，那个工具有一个可选参数在 prompt 里没有被传递完整，导致过滤维度直接少了一层。
这就是 AI 代理和传统服务的本质区别。传统服务是确定性的：输入不变，输出基本不变，出了问题按调用链一层层查总能找到根因。但 AI 代理每次执行都经过模型推理，工具参数是动态生成的，执行路径可能不同，甚至同一个任务在不同时间跑出来的结果都会不一样。没有可观测性，你连复现问题都做不到——因为下一次模型可能又理解对了。
1.2 传统监控体系的三个盲区
普通服务的监控体系通常围绕 CPU、内存、请求量、错误率来建设，这套思路放到 OpenClaw 上会漏掉三个非常关键的维度。
第一个是模型层盲区。你完全看不到一次任务消耗了多少 token、模型的输出质量如何、成本是多少。很多人以为 OpenClaw 接上 Ollama 本地免费模型就零成本了，但实际上本地推理的显存占用、延迟、失败重试都是有代价的，而且本地模型能力参差不齐，出错率往往比商用 API 高不少。
第二个是工具调用链盲区。OpenClaw 的核心能力在于调用各种 skill、外部 API 和系统命令，但一次任务往往涉及多个工具的多步调用：工具参数是怎么生成的、返回值有没有被正确解析、失败重试了几次，这些在普通日志里根本看不全。
第三个是审批与安全盲区。OpenClaw 的命令审批机制（exec-approvals）是安全闸门，但审批被拒、审批超时同样会导致任务失败，这类事件需要有审计视角才能快速定位。后面我会专门讲这个。
这三个盲区叠加在一起，会让排查问题变成一个体力活：先猜模型层，再猜工具层，最后猜配置层。而搭建一套针对 AI 代理的可观测性体系，本质就是在模型层、工具层、执行链路层三个维度同时装上“监控探头”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Clawmetry：OpenClaw 自带的遥测底子，先把它用起来
2.1 Clawmetry 到底是什么，怎么打开
Clawmetry 这个名字是 Claw 和 Telemetry 的组合，你可以把它理解成 OpenClaw 生态里负责采集自身运行状态的遥测能力的总称。它不是像 Prometheus 那样需要单独部署的大型系统，而是一套内嵌在 OpenClaw 里的数据采集能力，主要包括事件日志、工具调用记录、运行时元数据、审批记录这几类。
启用方式并不复杂，以我安装的版本为例，核心是修改 OpenClaw 的配置文件。配置文件在用户目录下的 .openclaw 文件夹里，Linux 通常是 ~/.openclaw/openclaw.json，Windows 上是 C:\Users\<用户名>\.openclaw\openclaw.json。找到 telemetry 或 clawmetry 相关的配置段，把 enabled 设为 true，日志级别可以先用 debug，等稳定后再调回 info 减少噪音。修改之后重启 OpenClaw 服务，再用 `openclaw