为OpenClaw AI Agent构建本地可观测性：安装、配置与深度调试指南

1. 项目概述：为你的AI Agent装上“行车记录仪”

如果你正在运行或开发基于OpenClaw的AI智能体，那么你很可能正面临一个“盲开”的困境。你的Agent们在后台不知疲倦地工作，处理请求、调用工具、生成回复，但你却对它们内部发生了什么、花了多少钱、在哪里卡壳几乎一无所知。这就像驾驶一辆没有仪表盘和行车记录仪的汽车，你只能祈祷它别出故障，别在某个深夜因为一个无限循环的“心跳”请求而烧掉你几十美金的API额度。openclaw-obs就是为了解决这个问题而生的——它是一个本地优先、零数据外泄的AI智能体可观测性平台。

简单来说，openclaw-obs是一个插件+仪表盘的组合。它作为插件嵌入你的OpenClaw网关，悄无声息地记录下每一次会话、每一次LLM调用、每一次工具执行的完整轨迹。所有这些数据都被安全地存储在你本地机器的SQLite数据库中，没有任何信息会离开你的电脑。然后，它提供一个直观的Web仪表盘，让你能像回放监控录像一样，审视Agent的每一次“思考”和“行动”，精确掌握成本构成和性能瓶颈。对于任何严肃使用OpenClaw的开发者或团队而言，这应该是继网关本身之后，第一个需要安装的工具。

2. 核心价值与设计思路拆解

2.1 为什么“可观测性”是AI Agent开发的刚需？

在传统软件开发中，我们有日志、指标和链路追踪（Logs, Metrics, Traces）这三大支柱来构建可观测性。AI Agent应用，尤其是像OpenClaw这样支持复杂工作流和子Agent调用的框架，其复杂度远高于普通的API服务。一次用户查询可能触发主Agent的思考，主Agent又可能调用搜索工具、计算工具，甚至动态生成并调用一个专门的子Agent来处理子任务。这个过程中的变量太多了：LLM的提示词工程是否有效？工具调用参数是否正确？子Agent是否按预期工作？哪个环节消耗了最多的Token和金钱？

没有可观测性，调试就变成了“猜谜游戏”。用户报告“Agent回答不对”，你只能漫无目的地查看网关日志，试图从碎片信息中拼凑真相，效率极低。更现实的是成本问题，LLM API调用是按Token计费的，一次复杂的、包含多轮思考和工具调用的会话，成本可能轻松超过1美元。如果某个Agent逻辑有缺陷，导致在无人值守时（比如夜间心跳检查）反复调用昂贵模型，一觉醒来收到天价账单绝不是危言耸听。openclaw-obs的设计初衷，就是将这种“黑盒”状态变为“白盒”，提供成本、性能和调试三个维度的全面透视。

2.2 本地优先与零数据泄露的架构选择

当前许多云端的AI应用分析平台，功能强大，但需要你将敏感的对话数据、提示词乃至业务逻辑发送到第三方服务器。这对于处理企业内部数据、涉及隐私或个人信息的应用来说是绝对不可接受的。openclaw-obs坚定地选择了“本地优先”架构。

所有数据，从原始的LLM请求/响应消息，到工具调用的输入输出，乃至整个会话的元数据，都被写入一个本地SQLite数据库文件（默认位于~/.openclaw/observability/traces.db）。仪表盘服务（一个本地Node.js服务器）直接读取这个数据库并提供API和前端界面。整个数据闭环都在你的机器上完成。这种设计带来了几个关键优势：

1. 绝对的数据隐私和安全：符合最严格的数据合规要求。
2. 极低的延迟：数据写入和读取没有网络开销，对Agent本身性能的影响微乎其微。
3. 离线可用：即使没有网络，你依然可以查看历史记录和分析数据。
4. 简单部署：无需申请API密钥、配置云服务账号，克隆即用。

2.3 核心数据模型：Trace、Span与事件流

为了清晰地记录Agent的复杂行为，openclaw-obs借鉴了分布式追踪（Distributed Tracing）的概念，设计了一套简洁而强大的数据模型。

• Trace（追踪）：代表一个完整的会话生命周期，从用户发起请求开始，到Agent返回最终结果结束。每个Trace有一个唯一ID，包含了会话状态（成功/失败）、关联的Agent名称、使用的LLM模型、总耗时、总成本等核心元数据。这相当于一次“驾驶行程”的完整记录。
• Span（跨度）：代表Trace中的一个逻辑操作单元。最重要的两种Span是：
  • LLM Call Span：记录一次对大语言模型的调用。包括使用的模型、输入/输出的Token数量、计算出的成本、以及具体的请求和响应消息（可能被截断以避免存储过大）。
  • Tool Call Span：记录一次对工具（如搜索引擎、计算器、自定义函数）的调用。包括工具名称、输入参数、执行结果（或错误信息）以及耗时。
• 消息链：除了Span，系统还会按顺序记录会话中所有的用户消息和Assistant消息，形成一个完整的、可回放的对话历史。
• 子Agent链接：如果一个Agent在执行中动态创建（Spawn）了子Agent，openclaw-obs会创建新的Trace来记录子会话，并通过字段将父子Trace关联起来。这样你就能在仪表盘中清晰地看到一个任务是如何被层层分解和执行的。

这个模型使得我们可以对一次会话进行“瀑布流”式的审视，精确看到时间花在了哪里，钱用在了哪个模型上，错误发生在哪个工具调用环节。

3. 安装与配置全流程实操

3.1 环境准备与前置检查

在开始安装之前，请确保你的基础环境符合要求。这不是走过场，环境不一致是后续绝大多数问题的根源。

首先，确认OpenClaw网关正在运行。打开终端，执行：

openclaw status

你应该能看到网关服务处于活跃（active）状态。如果未运行，请先根据OpenClaw官方文档启动它。

其次，检查Node.js和npm的版本。openclaw-obs构建其前端仪表盘需要现代JavaScript工具链的支持。

node --version # 确保输出为 v20.x.x 或更高版本，如 v20.11.1 npm --version # 确保npm可用，版本通常随Node安装，v10.x.x 以上即可

如果你的Node版本低于20，强烈建议使用nvm（Node Version Manager）来安装和管理多版本Node。在macOS/Linux上，可以运行curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash安装nvm，然后nvm install 20并nvm use 20。

最后，确保Git已安装，用于克隆代码库。

git --version

3.2 逐步安装：插件与仪表盘

安装过程分为两大块：一是构建并安装OpenClaw插件本身，二是构建独立的前端仪表盘应用。请严格按照顺序执行。

步骤一：克隆代码库并构建插件建议在一个统一的开发目录下操作，便于管理。

# 创建并进入项目目录 mkdir -p ~/projects cd ~/projects # 克隆 openclaw-obs 仓库 git clone https://github.com/kkeeling/openclaw-obs.git cd openclaw-obs

进入仓库后，首先安装插件部分的依赖并构建。这里的npm install会安装TypeScript编译器等开发依赖。

# 安装依赖并构建插件（产出在 dist/ 目录） npm install npm run build

npm run build命令通常会执行TypeScript编译（tsc）等操作，将src/下的TypeScript代码编译成JavaScript到dist/目录。构建成功后，你应该能看到dist/目录下生成了一系列.js文件。

步骤二：构建仪表盘前端openclaw-obs采用前后端分离架构，前端是一个基于React和Vite的独立应用，位于dashboard/子目录中。我们需要单独构建它，生成静态文件供后端服务器托管。

# 进入dashboard目录并构建 cd dashboard npm install npm run build cd ..

这个npm run build会调用Vite进行生产环境构建，将React代码打包、压缩、优化，输出到dashboard/dist目录。这些静态文件之后会被主服务器提供。

注意：务必确保在dashboard/目录内执行npm install。有时在根目录执行会因工作区（workspace）配置问题导致前端依赖安装不全，从而构建失败。如果构建过程报错，可以尝试删除dashboard/node_modules和dashboard/package-lock.json后重试。

步骤三：将插件链接到OpenClaw这是关键一步，让OpenClaw网关能够发现并加载我们的观测插件。在openclaw-obs项目根目录下，运行：

openclaw plugins install --link .

这个命令会读取项目根目录下的openclaw.plugin.json清单文件，该文件描述了插件的入口点和元数据。--link参数意味着创建的是一个“链接”而非拷贝，这样你在~/projects/openclaw-obs中对插件代码的任何修改，在重启网关后都会立即生效，非常适合开发调试。

步骤四：创建数据存储目录插件需要一个地方存放SQLite数据库文件。按照惯例，OpenClaw的配置和数据通常存放在用户主目录的.openclaw隐藏文件夹下。

mkdir -p ~/.openclaw/observability

数据库文件traces.db会在插件首次运行时自动在这个目录中创建。

步骤五：重启OpenClaw网关以加载插件插件安装后需要重启网关才能被加载到运行时中。

openclaw gateway restart

执行后，观察终端输出，确认网关重启成功，没有报错信息。

步骤六：启动观测仪表盘服务器插件负责收集数据，我们还需要一个独立的服务器来提供查询数据和展示界面的能力。在项目根目录下：

node dist/cli.js

如果一切正常，你会看到服务器启动的日志，类似Server listening on port 19100。此时，打开你的浏览器，访问http://127.0.0.1:19100，就应该能看到openclaw-obs的仪表盘界面了。

实操心得：第一次启动时，建议保持这个终端窗口在前台运行，方便查看可能的错误日志。如果端口19100已被占用，服务器会自动尝试19101、19102等端口，请留意启动日志中的实际端口号。

3.3 验证安装是否成功

安装完成后，我们需要确认数据链路是否畅通：插件是否在记录数据？仪表盘是否能查到数据？

方法一：触发一次Agent会话最直接的方式是去使用你的OpenClaw Agent。通过你集成了OpenClaw的客户端（可能是聊天界面、CLI工具或API）发送一个简单的请求。例如，如果你有一个名为“research”的Agent，就让它帮你搜索一些信息。

方法二：检查数据库在终端中，使用sqlite3命令行工具直接查询数据库（如果系统未安装sqlite3，请先通过包管理器安装，如brew install sqlite3或apt install sqlite3）。

sqlite3 ~/.openclaw/observability/traces.db "SELECT id, agent_name, status, total_cost_usd FROM traces ORDER BY started_at DESC LIMIT 3;"

如果安装成功且已有Agent活动，这条SQL命令会返回最近的三条追踪记录，包括ID、Agent名、状态和成本。如果表是空的，说明插件可能没有正确捕获到事件，需要进入排查环节。

方法三：访问仪表盘查看概览在浏览器中打开http://127.0.0.1:19100，进入“Overview”标签页。如果插件正在工作，你应该能看到总成本、Token使用量、各Agent的会话数量等统计图表不再是空白或零值。

3.4 高级配置与环境变量

openclaw-obs的所有配置都通过环境变量进行，无需修改任何配置文件，这非常符合云原生和容器化的最佳实践。你可以在启动仪表盘服务器前设置这些变量。

配置示例：如果你想在端口19101上启动服务器，并保留30天数据，最大数据库限制为500MB，可以这样启动：

export OPENCLAW_OBS_PORT=19101 export OPENCLAW_OBS_RETENTION_DAYS=30 export OPENCLAW_OBS_MAX_DB_MB=500 node dist/cli.js

为了方便，你可以将这些export命令写入一个shell脚本（如start_obs.sh），以后每次通过脚本启动。

4. 仪表盘功能深度解析与使用技巧

仪表盘是openclaw-obs价值的集中体现。它不是一个简单的日志查看器，而是一个为分析AI Agent行为量身定制的交互式分析工具。

4.1 总览面板：成本与健康的“驾驶舱”

“Overview”面板是你的指挥中心，一眼就能掌握全局健康状况。它通常包含以下几个核心部件：

1. 成本趋势图：以折线图展示每日（或每小时）的API调用总成本。这是发现“成本异常”最直观的工具。如果你看到某一天的成本曲线突然飙升，那么那天肯定有某个Agent行为异常或遇到了特殊的高负载任务，需要立刻进入Trace列表进行下钻分析。
2. Token消耗分布：以环形图或堆叠柱状图展示不同模型（如gpt-4o, claude-3-haiku, gemini-pro）消耗的输入/输出Token比例。这能帮你回答：“我的钱主要花在哪个模型上了？” 如果发现某个性价比不高的模型消耗了大量Token，可能就是优化提示词或切换模型的机会。
3. 按Agent/状态统计：卡片或表格显示各个Agent产生的会话数量、成功/失败率、平均耗时和平均成本。这有助于你评估不同Agent的稳定性和经济性。失败率高的Agent显然是调试的重点。
4. 关键指标卡片：显示最近一段时间（如24小时）内的总会话数、总成本、平均会话耗时、错误率等核心KPI。

使用技巧：充分利用时间筛选器。Overview面板通常支持选择时间范围（如最近1天、7天、自定义）。在分析一个具体问题（如“昨晚成本为何高？”）时，将时间范围锁定在问题发生时段，能让数据对比更加清晰。

4.2 追踪列表：会话的“搜索引擎”

“Trace List”页面以表格形式列出了所有捕获的会话。每一行代表一个Trace，包含以下关键信息：

• ID/状态：Trace的唯一标识和最终状态（成功、失败、进行中）。失败状态会用醒目的红色标注。
• Agent：执行该会话的Agent名称。
• 主要模型：该会话中使用的主要LLM模型。
• Tokens & 成本：该会话消耗的总Token数和计算出的总成本（通常以美元计）。
• 持续时间：从会话开始到结束的总耗时。
• 时间戳：会话开始的时间。

这个列表的强大之处在于其过滤和搜索能力。你通常可以：

• 按状态过滤：快速找出所有失败的会话进行集中排查。
• 按Agent过滤：只看某一个特定Agent的活动。
• 按模型过滤：分析特定模型的使用情况。
• 按时间范围过滤：聚焦于某个时间段。
• 按成本过滤：找出成本最高的会话（可能是优化重点）。
• 关键词搜索：在会话的输入消息或元数据中搜索关键词。例如，搜索一个出错的任务ID或一个特定的用户问题。

实操心得：当用户报告某个问题时，如果你能大致知道问题发生的时间，在Trace List中通过时间过滤和Agent过滤，能快速定位到对应的会话记录，效率远超翻阅原始日志。

4.3 追踪详情与对话回放：深度调试的“时光机”

这是openclaw-obs最核心的调试功能。点击Trace List中的任意一行，即可进入该次会话的详情页。这个页面通常由两部分组成：

1. 瀑布流时间线：以可视化时间轴的形式，展示会话中所有Span（LLM调用、工具调用）的起止时间和顺序。哪个LLM调用耗时最长？工具调用之间是否有不必要的等待？通过这个视图一目了然。时间线可以缩放，便于查看密集的操作。

2. 完整对话回放：以聊天界面的形式，逐条展示用户消息、Assistant的思考过程、工具调用请求和结果。与普通聊天记录不同，这里的工具调用通常是可展开的。你可以点击一个“调用搜索引擎”的条目，展开后看到Agent具体提交的搜索查询是什么，以及搜索引擎返回的原始结果是什么。这对于判断“是Agent问了错误的问题，还是工具返回了垃圾信息”至关重要。

调试案例：假设用户反馈“让Agent总结某篇长文章，结果它总结得不对”。你找到对应会话的Trace详情，通过对话回放，你可能会发现：

• Agent正确地调用了“读取文章”工具，并拿到了全文。
• 但在调用LLM进行总结时，你展开LLM调用的详情，发现发送给模型的提示词（Prompt）可能模糊不清，导致模型理解偏差。
• 或者，你发现工具返回的文章内容本身格式就有问题，包含了大量无关HTML标签，干扰了LLM。

有了这些信息，你的修复方向就非常明确了：要么优化提示词工程，要么改进文章抓取工具的清洗逻辑。

4.4 子Agent追踪：理清复杂工作流的“地图”

对于OpenClaw这类支持动态创建子Agent的框架，一个任务可能像一棵树一样展开。主Agent是根节点，它可能创建多个子Agent处理不同子任务，子Agent还可能再创建孙Agent。openclaw-obs会自动建立这些Trace之间的父子链接。

在Trace详情页中，留意是否有“Sub-agents”或“Child Traces”这样的板块。这里会列出由当前会话创建的所有子会话。你可以直接点击子会话的ID，跳转到该子会话的详情页进行查看。这个功能对于调试复杂的、多步骤的Agent工作流（如一个研究Agent先调用搜索子Agent，再调用分析子Agent）是无价之宝，它能帮你理清任务分解的逻辑和数据的流动路径。

5. 生产环境部署与运维指南

5.1 以服务形式持久运行仪表盘

在开发环境中，我们可能直接用node dist/cli.js在前台启动仪表盘。但在生产环境或长期运行的机器上，我们需要确保服务在后台稳定运行，并在系统重启后能自动拉起。

方案一：使用 systemd (Linux)这是最规范的方式。创建一个systemd服务文件：

sudo vim /etc/systemd/system/openclaw-obs.service

写入以下内容（请根据你的实际路径修改WorkingDirectory和ExecStart）：

[Unit] Description=OpenClaw Observability Dashboard After=network.target [Service] Type=simple User=your_username # 替换为运行OpenClaw的用户 WorkingDirectory=/home/your_username/projects/openclaw-obs Environment="OPENCLAW_OBS_PORT=19100" Environment="OPENCLAW_OBS_RETENTION_DAYS=30" Environment="OPENCLAW_OBS_MAX_DB_MB=1024" ExecStart=/usr/bin/node /home/your_username/projects/openclaw-obs/dist/cli.js Restart=on-failure RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

然后启用并启动服务：

sudo systemctl daemon-reload sudo systemctl enable openclaw-obs.service sudo systemctl start openclaw-obs.service # 查看状态和日志 sudo systemctl status openclaw-obs.service journalctl -u openclaw-obs.service -f

方案二：使用 PM2 (跨平台)PM2是一个强大的Node.js进程管理器，自带日志、监控和集群功能。

# 全局安装PM2 npm install -g pm2 # 使用PM2启动服务，并设置环境变量 cd ~/projects/openclaw-obs OPENCLAW_OBS_PORT=19100 OPENCLAW_OBS_RETENTION_DAYS=30 pm2 start dist/cli.js --name openclaw-obs # 设置开机自启 pm2 startup pm2 save

PM2会自动管理进程，崩溃后重启，并可以通过pm2 logs openclaw-obs查看日志。

5.2 实现安全的远程访问

仪表盘默认绑定在127.0.0.1，只能本地访问。如果你需要从办公室电脑、手机或其他服务器查看，就需要安全的远程访问方案。强烈不建议直接将服务端口暴露在公网。

推荐方案：使用SSH隧道这是最简单、最安全的方式。在你运行OpenClaw的服务器（假设IP为server_ip）上，仪表盘运行在19100端口。在你的本地电脑上执行：

ssh -N -L 19100:localhost:19100 your_username@server_ip

这个命令会在你本地电脑的19100端口和服务器内部的19100端口之间建立一个安全的SSH隧道。现在，你在本地浏览器访问http://localhost:19100，流量就会通过加密的SSH连接转发到服务器上的仪表盘。

备选方案：使用Cloudflare Tunnel (前文提到的cloudflared)如果你没有SSH权限，或者需要分享给没有服务器访问权限的同事临时查看，Cloudflare Tunnel是一个不错的零配置方案。它会在你的本地服务和Cloudflare的边缘网络之间建立一个安全的、带临时公共URL的隧道。

# 安装cloudflared后 cloudflared tunnel --url http://localhost:19100

执行后会生成一个https://xxxxx.trycloudflare.com的随机URL，该URL在隧道运行期间有效，可以分享给他人。请注意：此URL是公开的，任何拿到链接的人都能访问你的仪表盘。因此，仅限临时、非敏感场景使用，用完后及时关闭隧道。

5.3 数据维护与清理策略

虽然openclaw-obs提供了自动清理（基于时间和大小），但了解其机制并主动管理是有益的。

• 自动清理逻辑：插件在启动时和运行期间会定期检查traces表。它会删除所有started_at时间早于(当前时间 - OPENCLAW_OBS_RETENTION_DAYS)的记录。如果设置了OPENCLAW_OBS_MAX_DB_MB，它会计算数据库文件大小，如果超过限制，则从最旧的记录开始删除，直到文件大小低于限制。
• 手动触发清理：你可以通过向仪表盘API发送请求来手动触发清理和数据库优化（VACUUM）。

  curl -X POST http://localhost:19100/api/prune

• 数据库备份：traces.db是一个标准的SQLite文件，备份非常简单。只需在仪表盘和OpenClaw网关都停止运行（确保没有写入）后，复制该文件即可。你也可以使用sqlite3的.backup命令进行在线备份。

  sqlite3 ~/.openclaw/observability/traces.db ".backup '/path/to/backup/traces_$(date +%Y%m%d).db'"

• 监控数据库增长：定期检查数据库文件大小是一个好习惯。你可以将其纳入你的服务器监控中。

  du -h ~/.openclaw/observability/traces.db

6. 故障排查与常见问题实录

即使按照指南操作，也可能会遇到问题。这里记录了一些常见坑点及其解决方法。

6.1 插件未加载，仪表盘无数据

现象：仪表盘能打开，但Overview页面所有数据都是0，Trace List为空。排查步骤：

1. 确认插件已安装：运行openclaw plugins list。查看输出中是否包含openclaw-obs。如果没有，回到步骤三重新执行openclaw plugins install --link .。
2. 确认网关已重启：安装插件后，必须执行openclaw gateway restart。简单的reload可能不足以加载新插件。
3. 检查网关日志：OpenClaw网关的日志可能包含插件加载错误的信息。查看日志的方式取决于你的部署方式，如果是systemd服务，可以用journalctl -u openclaw-gateway -f查看实时日志。寻找与openclaw-obs或plugin相关的错误行。
4. 验证数据库路径权限：确保运行OpenClaw网关的用户（如your_username）对~/.openclaw/observability/目录有读写权限。

   ls -la ~/.openclaw/ # 确保 observability 目录存在且用户有权写入

6.2 仪表盘服务器启动失败

现象：执行node dist/cli.js后立即报错或退出。排查步骤：

1. 端口占用：这是最常见的原因。错误信息可能包含EADDRINUSE。首先检查端口19100是否被其他进程占用。

   lsof -i :19100 # 或 ss -tulpn | grep :19100

   如果被占用，要么停止占用进程，要么通过环境变量OPENCLAW_OBS_PORT指定另一个端口，如19101。
2. 构建不完整：确保你按照步骤，分别在项目根目录和dashboard/目录下成功执行了npm run build。如果构建过程有警告可以忽略，但如果有错误（Error），必须解决。检查dist/和dashboard/dist/目录是否存在且包含文件。
3. Node.js版本不符：再次确认Node版本为20+。openclaw-obs可能使用了较新的JavaScript特性。
4. 依赖缺失：尝试删除node_modules和package-lock.json后重新安装。

   cd ~/projects/openclaw-obs rm -rf node_modules package-lock.json npm install npm run build cd dashboard rm -rf node_modules package-lock.json npm install npm run build cd ..

6.3 数据库被锁定或写入错误

现象：仪表盘可以访问，但数据似乎没有更新，或者在日志中看到SQLITE_BUSY或database is locked错误。原因与解决：SQLite在并发写入时可能会遇到锁问题。openclaw-obs使用了WAL（Write-Ahead Logging）模式来提高并发性，但在极端情况下仍可能发生。

1. 重启服务：首先尝试同时重启OpenClaw网关和仪表盘服务器，这通常会释放所有锁。
2. 手动执行WAL检查点：如果问题持续，可以尝试在服务停止后，手动清理WAL文件。

   # 先停止仪表盘和OpenClaw网关 sqlite3 ~/.openclaw/observability/traces.db "PRAGMA wal_checkpoint(TRUNCATE);" # 然后重新启动服务

3. 检查磁盘空间：确保数据库所在的磁盘有足够的剩余空间。磁盘满会导致任何写入操作失败。

6.4 仪表盘页面加载缓慢或空白

现象：浏览器打开仪表盘地址后，长时间加载或页面结构错乱。排查步骤：

1. 检查前端资源：打开浏览器开发者工具（F12），切换到“网络”（Network）标签页，刷新页面。查看是否有.js或.css文件加载失败（状态码非200）。这通常意味着前端构建的静态文件缺失或路径错误。确保dashboard/dist目录构建成功，且node dist/cli.js启动的服务器能正确服务该目录。
2. API接口不通：在开发者工具的“网络”标签中，查看对/api/health或/api/traces等API的请求是否成功。如果API请求失败（如404或500），说明后端服务器有问题。查看启动服务器的终端输出是否有错误日志。
3. 数据量过大：如果你已经运行了很长时间，积累了海量Trace数据，且没有设置有效的OPENCLAW_OBS_RETENTION_DAYS或OPENCLAW_OBS_MAX_DB_MB，可能会导致查询变慢。尝试设置合理的保留策略，并手动调用POST /api/prune进行清理。

6.5 成本计算似乎不准确

现象：仪表盘显示的成本与你从OpenAI/Anthropic等平台账单上看到的有差异。理解与调整：

1. 模型价格基准：openclaw-obs内置了一个pricing.ts文件，其中定义了各种模型的每百万Token输入/输出价格。这些价格是从各厂商的公开定价页面抓取的。厂商可能会调整价格，而插件内的价格表可能没有及时更新。你可以检查src/plugin/pricing.ts文件，对比当前官方价格。
2. 计算方式：成本 = (输入Token数 / 1,000,000 * 输入单价) + (输出Token数 / 1,000,000 * 输出单价)。这是一个估算值。实际账单可能包含免费额度、折扣、或其他计费项（如图像生成），插件可能无法完全覆盖。
3. Token计数差异：不同库的Tokenizer（分词器）可能产生细微差异。插件使用的Token计数方式可能与官方计费方式有极小偏差，但对于趋势分析和相对比较而言，这通常是足够精确的。
4. 自定义模型：如果你使用的是通过OpenClaw网关路由的自定义模型或私有部署模型，其价格可能不在默认列表中。你可能需要修改pricing.ts文件，为你使用的模型添加定价规则，然后重新构建插件。

处理建议：将openclaw-obs的成本数据视为相对参考和趋势指标，用于发现异常和对比优化效果，而非绝对精确的计费依据。定期将仪表盘显示的总成本与官方账单进行比对，如果发现系统性偏差，可以反馈给项目维护者或自行修正定价文件。