❓ 你有没有过这样的经历？

OpenClaw（一款开源 AI Agent 框架）这只 🦞 正在成为越来越多企业的"数字员工"，它能帮你处理邮件、写代码、操作文件、执行命令——几乎无所不能。不少团队一口气采购了几十台甚至上百台 OpenClaw 实例，组成了一个规模可观的"数字龙虾养殖场"。

但问题来了。

养龙虾的人至少还有个鱼塘可以看。而你的 OpenClaw 呢？你知道今天消耗了多少 Token？你知道哪个模型在默默吞噬你的预算？你知道凌晨三点有没有哪只"龙虾"被人诱导去读了 /etc/passwd？

大部分人的回答是：不知道。 😶

你精心部署了 OpenClaw，但当遇到这些问题时，你发现自己完全没有趁手的工具来定位问题。

今天这篇文章，我们就来聊聊如何用一行命令，给你的 OpenClaw 装上一台 X 光机——让每一次 LLM 调用、每一步工具执行、每一个 Token 的消耗，都从水下浮出水面。

一、你的龙虾在干什么？三个"看不见"正在影响你的信心

📚 在正式动手之前，我们先聊三个"看不见"。如果你正在使用 OpenClaw，大概率已经被其中至少一个困扰过。

看不见一：推理过程像迷宫，出了错只能靠猜

OpenClaw 处理一条用户消息的完整链路远比你想象的复杂。一条看似简单的提问，内部可能经历了这样的旅程：

用户输入 → 系统提示词拼装 → 模型推理第一轮 → 判断需要调工具 → 工具调用（可能是搜索、可能是代码执行）→ 工具结果回传 → 模型推理第二轮 → 再调一个工具 → 最终生成回复

任何一个环节出问题，最终的输出就可能偏离预期。如果没有链路追踪，你面对的就是一个只有"输入-输出"的黑盒，你只能猜测问题出在哪一步——是提示词写得不好？是模型幻觉？还是工具返回了错误数据？

调 Prompt 靠灵感，排查问题靠缘分。这不是科学，是玄学。🎲

看不见二：Token 账单像开盲盒，月底才知道心痛

大模型按 Token 收费，这个大家都知道。但 OpenClaw 作为 Agent，它的 Token 消耗模式和你直接调 API 完全不同——它有上下文滚雪球效应。

每一轮对话，Agent 都会把之前的对话历史、系统提示词、工具调用结果一股脑塞进上下文。第一轮可能 2000 Token，到了第五轮可能膨胀到 2 万。如果中间工具返回了一大段 HTML 或者 JSON，那更是雪上加霜。

更可怕的是，你完全不知道"贵"在哪里。是某个模型太贵？是某个 Agent 的提示词太啰嗦？还是上下文没有及时裁剪？没有细粒度的消耗数据，优化就无从下手。💸

看不见三：系统状态像薛定谔的猫，不看不知道死活

OpenClaw 在运行态会涉及消息队列、Webhook 处理、会话管理等多个环节。当用户说"它怎么不回我了"，问题可能出在任何一层：模型推理超时了？工具调用卡住了？消息队列堆积了？网关出了问题？

没有实时指标监控，你只能等问题被用户投诉后才知道——而这时候，可能已经影响了一批用户。⏰

二、解药来了：openclaw-cms-plugin + diagnostics-otel，Trace 和 Metrics 双管齐下

🛠️ 针对上面这三个"看不见"，我们给出的方案是两个插件协同工作，分别解决不同层面的问题：

两者都基于 OpenTelemetry 标准协议，数据统一上报到阿里云 CMS 2.0（云监控 2.0）平台，在同一个平台上查看和分析。

openclaw-cms-plugin 是本文的主角。它是一个专门为 OpenClaw 设计的 Trace 上报插件，遵循 OpenTelemetry GenAI 语义规范，会为 OpenClaw 的每一次运行生成结构化的调用链路。

具体来说，它会记录以下几种 Span（链路节点）：

这些 Span 之间有父子关系，串起来就是一条完整的调用链。你可以在 CMS 2.0 控制台上看到类似这样的 Trace 视图：

一眼就能看到：这次请求调了几次 LLM、每次用了多少 Token、中间调了哪些工具、哪一步最耗时、有没有报错。

从"猜"到"看"，就这么简单。 👁️

而 diagnostics-otel 是 OpenClaw 自带的内置扩展，负责输出运行时的 Metrics 数据，包括 Token 消耗速率、调用 QPS、响应耗时分布、队列深度、会话状态等。安装脚本会自动帮你找到它并启用，你不需要额外操心。

等等，diagnostics-otel 不是也能上报 Trace 吗？为什么还需要 openclaw-cms-plugin？

好问题。diagnostics-otel 确实支持 Trace 上报，但如果你仔细看它生成的 Trace，会发现一个根本性问题——所有 Span 都是独立的，没有父子关系。

diagnostics-otel 采用事件驱动架构生成 Span，每个事件独立创建 Span，各自拥有不同的 traceId。它产生的 5 种 Span 是：

• openclaw.model.usage——模型调用（记录 Token 用量）
  
• openclaw.webhook.processed / openclaw.webhook.error——Webhook 处理
  
• openclaw.message.processed——消息处理（记录处理结果和耗时）
  
• openclaw.session.stuck——会话卡住告警
  

这些 Span 之间没有 Trace Context 传播。简单来说，它们只是一个个"独立打点"，唯一的关联手段是 sessionKey 等业务字段。

Webhook  [openclaw.webhook.processed]  traceId: abc123
Message  [openclaw.message.processed]  traceId: def456  ❌ 不同 traceId
Model    [openclaw.model.usage]        traceId: ghi789  ❌ 不同 traceId

而 openclaw-cms-plugin 从设计上就是完整的链路追踪——所有 Span 共享同一个 traceId，通过显式的父子关系串联成一棵调用树，可以完整的看到一次请求的全貌：

enter_openclaw_system              traceId: aaa111
  └── invoke_agent main            traceId: aaa111  ✅ 相同 traceId
        ├── chat qwen3-235b        traceId: aaa111  ✅ 相同 traceId
        ├── execute_tool search    traceId: aaa111  ✅ 相同 traceId
        └── execute_tool exec      traceId: aaa111  ✅ 相同 traceId

除了链路完整性，两者在数据丰富度上也有本质差异：

简单来说：diagnostics-otel 的 Trace 是一组独立的"记录卡片"，openclaw-cms-plugin 的 Trace 是一条完整的"调用地图"。 前者只告诉你"发生了什么事"，后者会告诉你"事情的每一步"。两者搭配使用，一个管系统指标，一个管业务链路，刚好互补。🤝

三、一分钟搞定：一行命令接入教程

🚀 理论讲够了，开始动手。 整个接入过程，一分钟内保证搞定！

3.1 点击获取安装命令

登录 CMS 2.0 控制台，进入你的应用监控 Workspace，选择接入中心 - AI 应用可观测，点击 OpenClaw

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

3.2 一行命令，开始安装

打开 OpenClaw 所在机器的终端，粘贴你上一步复制的命令然后回车：

curl -fsSL https://arms-apm-cn-hangzhou-pre.oss-cn-hangzhou.aliyuncs.com/openclaw-cms-plugin/install.sh | bash -s -- \
  --endpoint "https://你的ARMS-OTLP地址" \
  --x-arms-license-key "你的License-Key" \
  --x-arms-project "你的Project" \
  --x-cms-workspace "你的Workspace" \
  --serviceName "你的服务名"

然后，坐下来看它跑。☕

安装脚本会自动完成以下所有事情：

[INFO]  Checking prerequisites...
[OK]    Node.js v24.14.0
[OK]    npm 11.9.0
[OK]    OpenClaw CLI found
[INFO]  Downloading plugin...
[OK]    Downloaded
[INFO]  Extracting...
[OK]    Extracted
[INFO]  Installing npm dependencies...
[OK]    Dependencies installed
[INFO]  Locating diagnostics-otel extension...
[OK]    Found diagnostics-otel at: /home/.../extensions/diagnostics-otel
[OK]    diagnostics-otel dependencies already present
[INFO]  Updating config...
[OK]    Config updated
[INFO]  Restarting OpenClaw gateway...
[OK]    Gateway restarted
════════════════════════════════════════════════════
  ✅ openclaw-cms-plugin installed successfully!
════════════════════════════════════════════════════

一共做了什么？

1. ✅ 检查环境（Node.js、npm、OpenClaw CLI）
   
2. ✅ 下载并解压 openclaw-cms-plugin 到 OpenClaw 扩展目录
   
3. ✅ 安装插件的运行时依赖
   
4. ✅ 自动定位 diagnostics-otel 扩展，如果没装过依赖会自动安装
   
5. ✅ 更新 openclaw.json 配置（两个插件的配置一次写完）
   
6. ✅ 重启网关使配置生效
   

全程无需手动编辑任何配置文件。安装脚本会智能处理各种边界情况——已有配置会合并更新而不是覆盖，diagnostics-otel 会按优先级自动搜索多个可能的安装位置。

3.3 验证安装

安装完成后，去和你的 OpenClaw 聊几句。等个一两分钟，打开阿里云 CMS 2.0 控制台，在右侧边栏进入AI应用可观测，你就可以看到你的 OpenClaw 应用了，恭喜——你的龙虾从此不再是黑箱了！🎉

3.4 想卸载？更简单

如果哪天不想用了（虽然我不信），一行命令搞定：

curl -fsSL https://arms-apm-cn-hangzhou-pre.oss-cn-hangzhou.aliyuncs.com/openclaw-cms-plugin/uninstall.sh | bash

卸载脚本会自动清理插件目录和 openclaw.json 中的所有相关配置，包括 diagnostics-otel 的配置也会一并禁用。如果你只想卸载 Trace 插件但保留 Metrics，加个 --keep-metrics 参数即可。

干净利落，不留后遗症。🧹

四、重头戏登场：装完之后能看到什么？

📈 接入只是开始，真正让人兴奋的是接入之后你能看到什么、解决什么。

4.1 完整调用链路——终于知道它的"脑回路"了

这是 openclaw-cms-plugin 最核心的价值。每一次用户请求，你都能在 CMS 2.0 上看到一条结构化的调用链：

enter_openclaw_system （请求入口：谁发的、从哪来的）

　└── invoke_agent main （Agent 执行过程）

　　　├── chat qwen3-235b （LLM 调用：模型推理 + Token 消耗明细）

　　　├── execute_tool search （工具调用：搜索）

　　　└── execute_tool exec （工具调用：代码执行）

在一次对话轮次中，插件会记录 Agent 层面的 LLM 调用和每一次独立的工具调用。如果 Agent 在内部进行了工具循环（比如"调用工具 → 拿到结果 → 再调用下一个工具"），每一次工具调用都会被独立记录为一个 TOOL Span，包括入参、返回值和执行状态，让你清楚看到工具链的完整执行过程。

💡 当前版本中，一次对话轮次内的 LLM 调用会聚合为一个 LLM Span，记录该轮次最终的 Token 消耗总量和输入输出内容。后续版本将进一步细化，支持每一次独立的 LLM 推理都生成单独的 Span，届时即使是多轮工具循环中的中间推理步骤也将完整可见。

每个 Span 上都标注了丰富的属性：

• 耗时——哪一步最慢，一目了然
  
• 模型信息——用了哪个模型、哪个 Provider
  
• Token 消耗——input_tokens、output_tokens、cache_read_tokens、total_tokens，逐项拆解
  
• 工具参数和返回值——调了什么工具、传了什么参数、返回了什么结果
  
• 错误信息——如果有报错，直接标红显示
  

这意味着什么？

以前用户说"回答不对"，你只能翻聊天记录猜。现在，打开 Trace 一看——哦，搜索工具返回了空结果，模型基于空结果"创造性"地编了一段话。问题定位从"两小时"变成了"两分钟"。⚡

4.2 Token 消耗拆解——每一分钱花在哪，门清

Trace 里的每个 LLM Span 都带有完整的 Token 用量属性：

配合 gen_ai.request.model 和 gen_ai.provider.name，你可以精确知道：哪个模型、在哪一步、吃掉了多少 Token。

举个真实场景：你发现某次对话的 Trace 里有 5 次 LLM 调用，其中第 3 次的 input_tokens 高达 12000——点进去一看，原来是工具返回了一整页 HTML，全部被塞进了上下文。找到了"吞 Token 的黑洞"，优化就有了方向。

Token 从"一笔糊涂账"变成了"逐笔明细账"。💰

4.3 系统运行指标——脉搏实时可见

diagnostics-otel 插件导出的 Metrics 数据，在 CMS 2.0 上可以构建运行指标仪表盘，实时监控：

• Token 消耗速率和费用趋势 —— 按模型、按时间维度拆分
  
• 调用 QPS 和响应耗时 —— 系统吞吐是否正常
  
• 消息队列深度和等待时间 —— 有没有积压
  
• 会话卡死计数 —— 有没有龙虾在"装死"
  
• 上下文大小趋势 —— 上下文是不是在失控膨胀
  

这些指标配合 CMS 2.0 的告警功能，可以实现：Token 日消耗环比突增 50% 自动告警、队列深度超过阈值自动告警、会话卡死自动告警——问题发生的第一时间你就知道，而不是等用户来投诉。 🔔

4.4 GenAI 语义规范——不是野路子，是正规军

值得一提的是，openclaw-cms-plugin 上报的 Trace 数据严格遵循 OpenTelemetry GenAI 语义规范。这不是我们自己拍脑袋定义的字段名，而是国际标准。

这意味着：

1. 数据结构标准化——gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.tool.name 等属性名与业界一致，方便和其他工具对接
   
2. 消息格式规范化——gen_ai.input.messages、gen_ai.output.messages、gen_ai.system_instructions 都按照标准 JSON Schema 格式化，支持 TextPart、ReasoningPart、ToolCallRequestPart、ToolCallResponsePart 等多种消息类型
   
3. 未来可扩展——随着 GenAI 语义规范的演进，插件可以平滑升级
   

4.5 不止于标准——阿里云 GenAI 规范的"额外加餐"

在兼容 OTel 开源标准的基础上，openclaw-cms-plugin 还实现了阿里云 GenAI 语义规范中的扩展能力。相比社区标准版，你能获得一些"额外加餐"：

🏷️ ENTRY Span——给调用链一个明确的"入口"

OTel 社区规范只定义了 LLM（推理）、Tool（工具调用）、Agent（智能体） 等 Span 类型，但没有"入口"概念。阿里云规范扩展了 ENTRY 类型的 Span，专门标识一次 AI 应用的调用入口。在 openclaw-cms-plugin 中，这就是 enter_openclaw_system Span——它记录了"是谁发起的请求"（gen_ai.user.id）和"当前会话 ID"（gen_ai.session.id），让你不仅能看到调用链，还能按用户和会话维度进行分析和追踪。

🔗 会话级关联——gen_ai.session.id

OTel 标准提供了 gen_ai.conversation.id，但对于 Agent 类应用，"会话"比"对话"更贴切。阿里云规范引入了 gen_ai.session.id，贯穿 ENTRY、AGENT、LLM 等所有 Span。这意味着你可以在 CMS 2.0 中直接按会话 ID 搜索，一次性拉出该会话下的所有 Trace，快速还原完整的会话内容。

📊 gen_ai.span.kind——AI 专属的 Span 分类体系

OTel 标准中的 SpanKind 只有通用的 CLIENT、INTERNAL、SERVER 等类型，面对一个 AI 应用的调用链，你无法仅凭 SpanKind 区分"这是一次 LLM 推理还是一次工具调用"。阿里云规范引入了 gen_ai.span.kind 属性，定义了一套 GenAI 专属分类体系：LLM、TOOL、AGENT、ENTRY、TASK、STEP（ReAct 轮次）、CHAIN、RETRIEVER、RERANKER 等。CMS 2.0 平台基于这个分类，能够自动识别 AI 应用的结构，渲染专属的 AI 调用链视图——LLM 调用标橘色、工具调用标粉色、Agent 标绿色一眼就能看懂整条链路的"角色分工"。

💡 这些扩展并不会破坏标准兼容性。openclaw-cms-plugin 上报的数据在任何支持 OTel 的后端都能正常展示基础信息，而在 CMS 2.0 上则能解锁完整的 AI 应用可观测体验。

正规军打法，对后续的数据分析和平台演进都是利好。

五、从黑箱到透明：可观测如何改变你的龙虾养殖方式

📈 装了 X 光机之后，你的"龙虾养殖"方式会发生根本性的转变：

这不是"锦上添花"，这是从"盲养"到"精养"的跨越。

就像一个养殖户从"肉眼看水色"升级到"水质传感器 + 摄像头 + 自动投喂系统"——你管理的还是同一群龙虾，但你对它们的掌控力完全不是一个量级。🦞📊

还有一件事：安全审计

除了性能调优和成本管控之外，企业级 AI Agent 部署还有一个绕不开的话题——安全合规与行为审计。Agent 能执行命令、读写文件、发起网络请求，如果缺少行为审计能力，你甚至不知道它有没有在凌晨三点悄悄读了一把 SSH 密钥。

这部分能力由我们可观测团队的另一个方案覆盖：阿里云 SLS（日志服务）OpenClaw 一键接入方案。它通过采集 OpenClaw 的 Session 审计日志和应用运行日志，提供开箱即用的安全审计大盘，包括高危命令检测、提示词注入识别、敏感数据外泄分析等能力，让 Agent 的每一步操作都有据可查、有迹可循。

如果你对安全审计感兴趣，强烈推荐阅读这篇文章：《SLS 一键接入与审计方案，让 OpenClaw 受控运行成为可能》。

CMS 2.0 管性能和成本，SLS 管安全和合规——两者搭配，才是"龙虾养殖场"的完整管控体系。🔐

六、常见问题速答

💡 最后回答几个接入过程中大家常问的问题：

Q：接入会影响 OpenClaw 的性能吗？

A：影响极小。openclaw-cms-plugin 使用 OpenTelemetry 的批量导出机制，Span 数据在内存中缓冲、定时批量上报，不会阻塞 Agent 的正常处理流程。

Q：可以只装 Trace 不装 Metrics 吗？

A：可以。安装时加 --disable-metrics 参数即可跳过 diagnostics-otel 的配置。

Q：diagnostics-otel 的 Traces 和 openclaw-cms-plugin 的 Traces 会冲突吗？

A：安装脚本默认将 diagnostics.otel.traces 设为 false，由 openclaw-cms-plugin 专门负责 Trace 上报。两者各司其职，不会重复。

Q：已经配置过 diagnostics-otel 了，安装会覆盖我的配置吗？

A：不会。安装脚本采用合并更新策略——只更新 endpoint、headers 等必要字段，保留你已有的 traces、logs、sampleRate 等配置不变。

Q：支持哪些 OpenClaw 版本？

A：版本需 >= v26.2.19（低版本不包含 diagnostics-otel 插件）。openclaw-cms-plugin插件通过 OpenClaw 的标准 Hook 机制工作，不依赖特定版本的内部 API。

Q：为什么 Token 消耗一直是0？

A：OpenClaw 从 v2026.3.8 版本开始，引入了一个 BUG ，会导致 Token 消耗采集有误，已在推进社区加速修复，相关 issue 链接：https://github.com/openclaw/openclaw/issues/46616。

七、总结

📋 回到最开始的问题：你的龙虾在水下干什么，你知道吗？

如果答案是"不知道"，那现在是时候装一台 X 光机了。

openclaw-cms-plugin + diagnostics-otel，一行命令，十分钟接入，给你的 OpenClaw 带来三个核心能力：

✅ Trace 链路追踪 —— 每一次 LLM 调用、每一步工具执行、每一个 Token 的流向，全链路可视化

✅ Metrics 实时指标 —— Token 消耗速率、调用 QPS、队列深度、会话状态，系统脉搏实时掌握

✅ GenAI 语义规范 —— 标准化数据结构，为后续的成本分析、性能优化、异常检测打下基础

别再让你的龙虾在黑箱里"自由泳"了。给它装上 X 光机，让每一步都看得见、查得到、优化得了。

毕竟，看得见的龙虾，才是好龙虾。🦞✨

❓ 互动时间！

1. 你在使用 OpenClaw 的过程中，遇到过最头疼的"黑箱问题"是什么？
   
2. 你现在是怎么排查 OpenClaw 出问题的？有没有什么土办法想分享？
   
3. 接入可观测后，你最想看到哪些数据？
   

欢迎在评论区聊聊你的"养虾"心得，也欢迎带着问题来——我们都在！🦞🎉