1. 一个人干一个公司的活OpenClaw到底能帮我分担什么我现在的状态说出来很多同行应该都有共鸣创业第四年名义上是个公司实际上就是我自己。产品、运营、客服、文案、财务、售后全部一个人扛。招人舍不得外包不放心于是我把目光盯到了OpenClaw这种个人AI助理框架上希望它真的能当半个员工用。折腾了一段时间之后我发现OpenClaw本身确实能干活但它像个蒙眼干活的员工——你根本不知道它此刻在忙什么、今天烧了多少token、哪个任务挂了、哪条渠道又掉线了。所以我动手给它加了一套大脑中枢一个专门盯住OpenClaw的仪表盘把Agent的状态、成本、任务流、知识沉淀全部可视化出来。这篇文章就是完整记录我怎么做的。OpenClaw是个开源的Agent运行时类似一个虚拟员工的躯壳消息渠道是感官LLM是大脑工具是手脚。而仪表盘就是给这个虚拟员工装上的行车记录仪和指挥台。适合谁看两类人一类是正在部署OpenClaw但卡在环境、渠道、模型各种问题上的新手另一类是已经跑起来了但和我一样觉得看不见Agent在干嘛的进阶用户。全文不涉及改OpenClaw内核所有监控都是旁路采集失败了也不影响主线服务。1.1 OpenClaw是什么先给没接触过的朋友交代背景简单说OpenClaw是一个可以自托管的AI助手运行框架。它本身不含特别强的智力智力来自你给它接的LLM——Claude、GPT、或者国产的Qwen都行它真正强的地方在于连接能力能接入Microsoft Teams、Obsidian这类工作环境能调用外部工具能执行定时任务也能处理消息流。你把它部署在一台服务器上它就是你的7×24小时数字员工。我打个比方。OpenClaw像一个人的身体渠道是眼睛和耳朵模型是大脑工具是手和嘴。我给它配的是阿里云服务器上跑的Ubuntu模型默认接Qwen系列渠道接了Teams和Obsidian。这个组合跑起来之后它每天能帮我处理消息、查资料、整理笔记、记账、写周报草稿。听着挺美对吧但问题马上就来了它到底有没有在认真干活你没法知道。1.2 一人公司真正缺的不是更多AI而是看得见AI在干嘛一个人的公司最尴尬的地方是没有中层管理。大公司有项目经理盯进度有财务盯预算有运维盯系统。我什么都没有。AI员工跑起来了我没有办法给它打绩效不知道它今天值不值回票价。具体痛点有三个状态不可见它是不是卡死了是不是某条渠道断了是不是在某个死循环里反复调用工具没有仪表盘之前我只能靠日志文件猜。成本不可控LLM是按token收钱的。OpenClaw每天进进出出那么多消息有的走快模型有的走强模型月底账单出来才知道花了多少根本来不及止损。产出不可追踪它处理了多少任务哪些成功了哪些失败了知识沉淀到Obsidian里的东西有多少全都是一笔糊涂账。对比一下就清楚了场景没有仪表盘有了仪表盘判断Agent是否存活手动翻日志靠猜心跳曲线一目了然控制成本月底看账单晚了按天按模型实时分摊复盘单个任务从零散日志里拼时间线按task_id一键追溯评估产出感觉好像干了不少数据说话量化到章节1.3 我给大脑中枢定的目标这个仪表盘不是花架子我给自己定了四个硬指标做不出来就算失败知道它还活着心跳在线率、错误率、响应延迟超过阈值就告警。知道它花了多少钱按模型、按渠道、按天统计token消耗成本趋势一眼看清。知道它在处理什么任务从指令进来、模型选择、工具调用、到最终回复整条链路可回溯。知道它沉淀了什么知识Obsidian里的新笔记、行动项、被翻过的旧知识全部量化。总原则只有一条不改OpenClaw本体代码所有数据靠旁路采集。这样OpenClaw升级了我不慌采集器挂了也不影响Agent干活。2. 部署这一关从WSL2的报错到阿里云ECS的最终选择聊仪表盘之前得先把OpenClaw本身部署这件事说清楚因为我在这一步卡了整整一天。如果你们是在Windows上玩大概率会碰到同一个坑。2.1 我在Windows上碰到的无法安全验证WSL2环境当时我想先在本地Windows机器上试跑图个省事。结果在PowerShell里执行一条命令时直接弹出来一段报错大意是无法安全验证WSL2环境请在PowerShell中运行wsl --status。我一开始还以为是OpenClaw的问题反复重新安装折腾到半夜。后来冷静下来排查发现根因跟OpenClaw一点关系都没有是WSL2本身没就绪。排查命令就这三条wsl --status wsl --update wsl --shutdownwsl --status会告诉你内核状态wsl --update把内核补到最新最后wsl --shutdown重启WSL。如果还不行去启用或关闭Windows功能里确认适用于Linux的Windows子系统和虚拟机平台两个开关都打开了然后重启电脑。这一套下来那个报错就消失了。这个坑我写出来是想提醒大家看到OpenClaw相关的报错先怀疑基础设施别一上来就怀疑工具本身。WSL2环境问题在Windows上概率很高但基本都是更新内核、开虚拟化、重启三板斧的事。2.2 为什么最终还是换到了阿里云ECS本地跑通了之后我又做了个决定把正式环境搬到云服务器上。对比下来云方案优势太明显了对比项Windows WSL2阿里云ECS Ubuntu在线时间电脑得一直开着息屏可能断7×24小时在线Teams接入回调公网地址麻烦公网IP天然合适Windows更新随时可能重启Agent跟着遭殃不受影响日志稳定性文件句柄、休眠都容易出幺蛾子Linux下行为稳定成本电费带宽按量付费小实例很便宜我用的是免费试用名额开的2核2G的ECSUbuntu 22.04配置好安全组之后OpenClaw部署在上面非常稳。云服务器还有一个好处以后想扩加个弹性公网IP就能把仪表盘页面暴露出来手机随时看。2.3 环境准备与安装清单云服务器到手后第一批命令如下sudo apt update sudo apt upgrade -y # 安装 Node.js 20建议用 nvm 管理版本 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 node -v # 安装 Git sudo apt install -y gitOpenClaw的安装我当时是clone官方仓库然后npm install也可以直接用npm全局安装对应CLI包。不管哪种方式Node.js版本别低于20太老的版本跑起来会有各种莫名其妙的依赖报错。这里多说一句有人搜node.js官网下载openclaw以为OpenClaw是Node.js官方的东西其实不是Node.js只是它依赖的运行时OpenClaw是独立的开源项目。安装完成之后在/opt/openclaw目录下初始化配置然后先手动跑一次确认Agent能起来、能连接模型再做后面的仪表盘。2.4 配置骨架渠道、模型、数据目录OpenClaw的配置是YAML文件我这份是精简后的关键骨架agent: name: one-person-company-bot timezone: Asia/Shanghai model: provider: dashscope fast: qwen2.5-3b-instruct # 高频低风险任务便宜 strong: qwen-plus # 复杂任务质量优先 channels: teams: enabled: true clientId: your_client_id clientSecret: your_secret tenantId: your_tenant_id obsidian: enabled: true vault: /home/ubuntu/obsidian-vault restApiPort: 27123 apiKey: your_obsidian_api_key data: dir: /opt/openclaw/data每个字段为什么这么配我说下思路。模型那块我用的是阿里云百炼平台的Qwen系列因为走国内API稳定性和延迟都有保障也不用考虑网络问题。fast和strong分开配是后面省钱策略的基础——简单消息用3B小模型复杂任务才切大模型。渠道的teams是为了把OpenClaw接到我日常用的办公群里obsidian是为知识库联动准备的后面第七章会展开。数据目录单独放是为了让日志、状态文件集中管理。后面做日志采集、心跳探测全都围绕/opt/openclaw/data这个目录展开。3. 大脑中枢的总体架构旁观者模式不碰OpenClaw内核仪表盘最核心的设计决策是采用旁观者模式。有朋友问我为啥不直接改OpenClaw源码加个内置监控模块不是更完美吗事情没那么简单。3.1 为什么选择旁观者模式动手之前我考虑过三种方案方案优势致命伤直接改OpenClaw源码数据最准确升级就冲突维护成本高通过SDK/SDK钩子嵌入事件完整依赖API稳定侵入性强旁路采集外部数据零侵入升级不慌需要自己处理数据对齐我选了第三种。旁路采集的意思是我不碰OpenClaw进程内部而是从它必然会产生的外部痕迹里偷数据——日志文件、HTTP回调、网络探活。OpenClaw只要正常运行一定往日志里写东西我只要有一个守护进程盯着日志文件就能还原出它干了什么。这个模式最大的好处是故障不传染。采集器写得再烂最多也就是仪表盘没数据绝不会让Agent本身挂掉。我后面升级过两次OpenClaw一次都没跟仪表盘冲突过这就是旁观者模式的价值。3.2 三条数据通路整个仪表盘的数据来源有三条各司其职通路一日志文件采集。OpenClaw会把任务事件以JSON行格式写到日志目录我写了一个Node.js采集器用类似tail -f的方式读新增行解析出结构化事件。这条通路负责追踪任务流。通路二Webhook事件上报。日志能覆盖大部分情况但有些业务级事件比如这个任务用了哪个模型工具返回了什么)日志里字段不全。我在OpenClaw里注册了一个自定义工具report_event让它在关键节点主动POST结构化事件到我仪表盘的/api/events接口。这条通路负责补齐业务细节。通路三定时心跳探测。日志只能证明它曾经干过活证明不了它现在活着。所以我每60秒主动探测一次OpenClaw的健康接口和端口连通性连续失败3次就标记为degraded或offline。这条通路负责健康度监控。三条通路的数据最终汇到一个SQLite数据库里再由一个轻量API服务提供给前端仪表盘。3.3 组件清单与部署拓扑整套系统跑在同一台2核2G的ECS上组件就五个OpenClaw本体systemd守护采集器Node.js写的常驻进程盯日志和端口SQLite数据库存事件、用量、心跳仪表盘API服务Express提供/api/summary等接口前端页面原生HTMLECharts负责画图。数据流是这样走的OpenClaw产生日志→采集器解析入库OpenClaw调用工具→HTTP POST到Webhook接收器→入库OpenClaw维持运行→心跳探针定时探测→入库。三条通道的终点都是SQLite再往上就是API和页面。这样一套组合没有引入任何重量级组件2G内存跑得很轻松也方便迁移。4. 采集层三件套日志解析、Webhook、心跳探针的具体实现采集层是整个仪表盘的地基。地基打不好上面画什么都白搭。我把三个模块的关键代码和思路都展开讲一遍。4.1 日志解析模块用Node.js写一个tail -fOpenClaw把运行日志写在/opt/openclaw/data/logs/agent.log格式是JSON Lines每行一条结构化事件。我写了一个日志采集器核心思路是记录上次读取的文件位置只处理新增部分const fs require(fs); const readline require(readline); const logPath /opt/openclaw/data/logs/agent.log; let position 0; function tailLog() { const stat fs.statSync(logPath); if (stat.size position) { // 日志被轮转或截断重置读取位置 console.error([collector] log rotated, reset position); position 0; } const stream fs.createReadStream(logPath, { start: position }); position stat.size; const rl readline.createInterface({ input: stream }); rl.on(line, (line) { try { const event JSON.parse(line); handleEvent(event); } catch (e) { // 跳过非JSON行比如启动横幅 } }); } setInterval(tailLog, 2000);这段代码里最容易被忽略的是日志轮转。OpenClaw重启或者日志文件达到一定大小后文件会被截断或重命名如果你只傻傻地接着读就会永久丢失后半段数据。所以我每次读取前都会检查文件size是否比上次记录的位置还小如果小说明文件被重置过就把position归零。这个细节是我第一版没处理第二天发现数据断档时才补上的。解析到事件之后handleEvent做的事就是统一转成我定义的事件结构再写进SQLite的events表。不同的日志类型消息收到、模型调用、工具执行、回复发出分别映射成不同type方便后面按类型聚合。4.2 Webhook接收器让OpenClaw主动汇报业务细节日志采集只能拿到OpenClaw自己写的内容拿不到我自定义的业务上下文。所以我在OpenClaw的工具系统里注册了一个自定义工具名字叫report_event用途是让Agent在任务的关键节点主动向仪表盘上报结构化数据。OpenClaw侧的自定义工具配置思路大致是这样的版本不同写法可能略有差异但逻辑一致async function reportEvent({ task_id, type, payload }) { const res await fetch(http://localhost:3080/api/events, { method: POST, headers: { Content-Type: application/json, x-collector-token: process.env.COLLECTOR_TOKEN }, body: JSON.stringify({ task_id, type, payload }) }); return res.ok ? ok : failed; }接收端是一个Express服务校验token后落库const express require(express); const app express(); app.use(express.json({ limit: 256kb })); app.post(/api/events, (req, res) { const token req.headers[x-collector-token]; if (token ! process.env.COLLECTOR_TOKEN) { return res.status(401).json({ error: invalid token }); } const { task_id, type, payload } req.body; insertEvent(task_id, type, JSON.stringify(payload)); res.json({ ok: true }); }); app.listen(3080, () { console.log(collector webhook listening on 3080); });为什么日志够用了还要Webhook因为日志里没有模型选择的完整链路。比如一条任务日志里只记录收到了消息和发送了回复中间用的哪个模型、调了哪些工具、每个工具花了多久全靠Webhook补充。有了这个通道我就能按task_id把一条完整的事件链拼出来。4.3 心跳探针判断Agent是真的活着还是装了死日志和Webhook都只能证明它历史上有动作不能证明它此刻没挂。所以我加了一个最朴素的探活机制每60秒做一次TCP连接检查并请求一下OpenClaw的健康检查接口统计响应耗时。#!/bin/bash # /opt/openclaw/healthcheck.sh if curl -s -o /dev/null -w %{http_code} %{time_total} \ http://127.0.0.1:3070/health | grep -q ^200; then echo ok else echo fail fi这个脚本的返回结果会写进heartbeats表带上响应耗时和状态。前端仪表盘按小时聚合算出在线率。我设定的告警规则是连续3次探测失败状态从online变为degraded连续10次失败直接标offline并通过OpenClaw本体的通道往Teams里发一条告警。探针还有一个作用记录延迟曲线。你别说OpenClaw启动初期因为模型冷加载响应能飙到十几秒看延迟曲线能明显看到温度变化。这些数据对后面调优很有帮助。5. 数据落库与仪表盘页面SQLite ECharts的轻量组合采集层拿到数据之后得有个地方存更得有个地方看。这一章讲存储选型和前端实现。5.1 为什么选SQLite而不是上一套数据库有人可能觉得做数据可视化至少得上个PostgreSQL吧我的理由很简单单机、单进程、数据量不大一天几万条事件顶天了、需要快速读。SQLite完全够用还省去一个数据库服务的运维成本。方案优点缺点我选不选SQLite零运维、单文件备份并发写弱、不适合分布式选单机完全够PostgreSQL功能强、并发好多一个服务要维护不选杀鸡用牛刀直接扫描日志零存储代价每次查询全量扫描慢不选查询体验太差SQLite还有一个好处备份极简单直接把.db文件复制一份就到别的机器恢复了。我每周日凌晨用cron把数据库文件备份到对象存储成本几乎为零。5.2 三张核心表设计我把数据建模为三张表对应三条采集通路CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_id TEXT, type TEXT, channel TEXT, model TEXT, created_at TEXT, payload TEXT ); CREATE TABLE usage ( day TEXT, hour INTEGER, model TEXT, input_tokens INTEGER, output_tokens INTEGER, cost_cny REAL ); CREATE TABLE heartbeats ( ts TEXT, ok INTEGER, latency_ms INTEGER );events表是最核心的它能回答今天处理了什么任务、结果如何usage表专门记录token消耗和成本按(day, hour, model)粒度聚合heartbeats表记录每一次探活结果用于计算在线率。这里有个设计细节usage表和events表会有数据重叠因为token信息既可能在日志里也可能在Webhook里。所以在写入usage时我用(task_id, model, created_at)做了唯一性约束确保同一笔token消耗不会被重复统计。这个坑我在第七章还会详细讲前期没去重成本虚高了一倍。5.3 仪表盘页面与关键图表前端我没有用重框架就是原生HTML加ECharts。为什么要这样因为仪表盘这个场景本质是定时拉数据画图用Vue/React是自找麻烦。页面结构分四块顶部总览卡片、中间任务时间线、下方成本趋势、右侧渠道分布。刷新策略是前端每30秒轮询一次/api/summary完全够用没必要上WebSocket。成本趋势图的核心配置长这样const option { tooltip: { trigger: axis }, xAxis: { type: time }, yAxis: { type: value, name: tokenk }, series: [{ name: 输入token, type: line, areaStyle: {}, data: inputTokens }, { name: 输出token, type: line, smooth: true, data: outputTokens }] };总览卡片那四个数字是今日任务数、今日token消耗、今日成本、当前在线状态。这四样是我每天早上睁开眼第一个看的。任务时间线则用了一个很简单的列表按时间倒序排列最近20条事件带颜色标签区分成功和失败。5.4 用systemd把整条链路守护起来采集器和仪表盘API都是常驻进程挂在终端里跑早晚会死。我用systemd把整条链路守护起来一共三个服务OpenClaw本体、采集器、仪表盘API。以OpenClaw为例[Unit] DescriptionOpenClaw Agent Afternetwork-online.target [Service] Userubuntu WorkingDirectory/opt/openclaw ExecStart/usr/bin/npx openclaw start Restartalways RestartSec5 EnvironmentNODE_ENVproduction EnvironmentDASHSCOPE_API_KEYxxx [Install] WantedBymulti-user.target采集器和仪表盘API的unit文件结构一模一样只是ExecStart换成对应的Node.js入口。Restartalways是关键——只要进程意外退出systemd在5秒后就帮你拉起来。我用这个方法之后整套系统的可用率从看运气变成了99.9%。6. 一人公司该盯的四类指标健康度、成本、任务流、知识资产仪表盘不是把数据堆上去就完事了得想清楚每个指标解决什么问题。我按照自己作为一人公司老板的需求把界面分成了四个维度每个维度都对应一个实际的经营问题。6.1 健康度先确认员工没在装死指标含义我的告警阈值在线率心跳正常比例低于99%告警任务失败率任务级失败占比高于10%告警p95处理时长95%的任务在多少秒内完成超过60秒告警每次我觉得OpenClaw好像不干活了打开仪表盘一看十有八九是模型API超时导致的失败率飙涨或者Teams通道断了导致消息根本没进来。没有告警之前我可能要等用户发消息抱怨才知道出了问题有了心跳曲线之后通道断开的第一时间仪表盘就标红了。6.2 成本账本AI员工也要发工资LLM的花销是实打实流出去的现金。我把usage表按天聚合就能回答三个问题今天花了多少哪个模型花得最多哪个渠道最烧钱我的模型路由策略是快模型处理高频消息、强模型处理复杂任务成本结构大概是这样的模型用量占比成本占比qwen2.5-3b-instruct70%15%qwen-plus30%85%这个数据是仪表盘跑了一周后我才意识到的3B小模型承担了大多数简单任务成本占比却只有15%。这让我更坚定了路由策略。月度预算上限是100元仪表盘会在用量到80%时告警避免月底失控。6.3 任务流从指令到产出每一环都能回溯任务流追踪是我最满意的功能。每条任务都会生成一个task_id从收到消息到模型选择到调用工具到回复发出整条事件链都能在仪表盘里按时间线展开。我复盘一次失败任务的典型路径是这样的messages.received - model.routed - tool.started(web_search) - tool.failed(timeout) - model.retry - tool.started(web_search) - tool.finished - agent.replied看到没第一次工具调用超时了OpenClaw自动重试了一次才成功。这种细节在没有仪表盘之前我是完全不可能知道的——日志里虽然有但没人会为了查一次个案去翻几个小时的文件。6.4 知识资产Obsidian里的东西要不要被量化这个维度我纠结了很久。知识沉淀这种东西量化不好就是虚荣指标。我最终的方案是记录两个数字每日新增笔记数、行动项完成数。这两个数字的意义在于可被执行。OpenClaw每天会把处理过的值得留存的资料写成Obsidian笔记并生成明日待办行动项。第二天我打开Obsidian看到的不是AI随便摘录的碎片而是仪表盘确认过的、和真实任务挂钩的知识产出。我甚至给OpenClaw加了一道人话规则宁可少记三篇也不要凑数记一篇。因为仪表盘会暴露凑数的行为。7. 给仪表盘装上手脚Teams与Obsidian的双向打通仪表盘一开始只是被动展示我慢慢发现它可以更主动——让OpenClaw在Teams里被时直接查仪表盘的数据库回答我的问题。这才是大脑中枢真正的意义。7.1 Teams接入让虚拟员工出现在公司群里Teams接入OpenClaw核心是Azure上的Bot注册。你需要创建一个Bot应用拿到clientId、clientSecret和tenantId然后在OpenClaw的channels配置里填进去。这块有个容易踩的坑Teams要求回调地址必须是公网可访问的HTTPS地址所以我前面才坚持要把OpenClaw部署在云服务器上本地Windows根本搞不定这个。Teams接好之后OpenClaw就光明正大地出现在我的工作群里了。我在群里它它就能响应。这个能力本身不是新东西但配上仪表盘效果完全不同——因为它现在能查自己的运营数据了。7.2 Obsidian接入知识库与Agent联动Obsidian接入我选了Local REST API插件方案。这个插件会在Obsidian本地开一个REST接口OpenClaw可以通过API读写vault里的笔记。这样设计的好处是笔记仍然存在我自己的仓库里没有经过第三方云数据完全可控。OpenClaw侧注册了两个自定义工具read_note和write_note。read_note用于查询已有笔记write_note用于把新知识写入指定目录。我给OpenClaw定了一个工作流每天下午六点把当天处理过的有价值信息整理成一篇日记笔记放到Daily/目录下标题是当天的日期。这个操作本身由OpenClaw的定时任务触发而执行结果会通过Webhook上报给仪表盘。7.3 用自然语言查仪表盘仪表盘API有了数据库有了OpenClaw本身又是LLM天然能理解自然语言。所以我把仪表盘查询也封装成了一个自定义工具query_dashboard接受一个SQL查询字符串或语义化问句返回图表数据。调用链是这样的我在Teams里发这个周末OpenClaw花了多少tokenOpenClaw收到后自动调用query_dashboard把问题转成SQL去查usage表再把结果组织成一句人话回复我。整个过程我在仪表盘的任务时间线上都能看到——它自己查了自己的账本然后向我汇报。这条链路打通的那一刻我才觉得大脑中枢这个名字名副其实仪表盘不只是给人看的它还能被Agent自己调用形成一个人机共用的操作台。8. 连续跑了一周之后数据长这样坑也踩了不少理论说再多不如实跑。我的OpenClaw加仪表盘系统连续运行了一周以下是真实记录下来的数据以及我踩过的坑。这些经验手册上真不会写。8.1 一周运行数据样本指标数值总任务数327个任务成功率93.9%平均处理时长22.4秒总token消耗约310万总成本约36元在线率99.7%主动告警次数2次327个任务里有大量是消息分类、信息查询、笔记整理这类轻量任务成本大头集中在几个复杂任务上——比如我做竞品分析时一个任务就烧掉了整周成本的20%。这些数据让我做了两个调整一是把每天凌晨的重型定时任务改到下午避免和白天高峰抢模型资源二是把连续多个小任务合并成批量任务减少重复调度开销。8.2 我踩过的坑第一个坑是时区。OpenClaw默认按UTC记录时间仪表盘前端按本地时间显示。结果头两天我看到成本曲线在凌晨4点出现高峰还以为是半夜有爬虫在刷排查了半天最后发现是时区偏移——UTC的晚上8点换算成北京时间就是凌晨4点。解决方案是在日志解析阶段统一转成Asia/Shanghai时间再入库。第二个坑是日志轮转。我第一版采集器没有处理文件截断OpenClaw重启一次之后采集器就闷声不响地卡在旧文件的文件描述符上看起来还在跑实际上一条数据都不进库了。这个问题是我第二天看仪表盘数据一夜没增长才发现的。解决方案就是第4.1节写的文件size比较逻辑。第三个坑是token重复统计。日志里有一份token记录Webhook里又报了一份两边没去重导致成本虚高接近一倍。后来我在usage表的写入逻辑里加了唯一键约束重复数据直接忽略。教训是多通路采集必须有幂等设计否则聚合数据会失真。第四个坑更蠢——阿里云安全组忘了开放仪表盘端口。我在本地curl仪表盘接口一切正常换手机在外面就访问不了排查了一阵才发现是云控制台的安全组规则只开了22和3070端口没开3080。提醒大家云服务器的网络策略和Linux本地的iptables是两层关卡都得检查。8.3 模型路由省钱技巧小模型当守门员大模型当攻坚手最后分享一个和仪表盘深度绑定的省钱技巧模型路由。我的规则很简单消息长度 200字 且 无附件 - qwen2.5-3b-instruct 消息含分析对比方案 - qwen-plus 消息来自指定客户群 - qwen-plus 其余 - qwen2.5-3b-instruct这套路由规则让每周成本从原本的全走大模型的81元降到了36元降幅超过50%。关键是仪表盘能按模型维度验证效果——我可以清楚地看到3B小模型的失败率只比大模型高了2个百分点但成本只有1/6。这种性价比差异没有仪表盘你根本不会知道。我个人这套组合跑到现在最大的体会是给OpenClaw加仪表盘这件事不是给一个玩具装上RGB灯而是给一个虚拟员工建立最基本的经营台账。我现在每天早上雷打不动做三件事看在线率、看昨天成本、看失败任务明细。确定它一切正常之后才开始一天的工作。这个最懂一人公司的仪表盘懂的不是AI技术而是一个人管理一个系统这件事本身——你要能看见才能管理你要能量化才能优化。