![chart.png](https://developer.qcloudimg.com/http-save/yehe-6749971/fee5599f89dfa22dc2b4d856a1ec4694.png)# 我把 WorkBuddy 的积分消耗实测了一遍：脚本 0 成本，但真正烧钱的是「让 AI 汇报」


>一句话结论：**三个自动化脚本实测消耗全部为 0.00 积分；这一天里烧掉的 131.04 积分，一分都不在脚本上，全在「Agent 读上下文 + 写汇报」这个环节。**
这篇按官方「完整案例」四项要求写：输入材料、WorkBuddy 配置、操作步骤、产出物。所有数字来自我本机的真实运行日志，可复现。


----

## 一、先说清楚一件事：官方没有积分换算表


先说个前提，免得后面被当成标题党：

WorkBuddy 官方文档里**没有**「一次对话消耗多少积分」的换算表。唯一相关的官方表述是一条免责条款：

>「专家团可能涉及多位成员和多轮调用，积分消耗可能高于单个专家，**不能按固定倍数估算**。」


也就是说，官方明确拒绝给你一个系数让你自己算。那怎么办？——**自己测。**

我用的方法是笨办法但可靠：**读积分包余额，做差分**。


----

## 二、输入材料


|材料|说明|
|:-:|:-:|
|`workbuddy-credits.js`|已调通的签到脚本，走 WorkBuddy 客户端本地 IPC 管道，能读到积分包余额|
|`credits-ledger.json`|账本，每次运行写一条余额快照|
|`measure-cost.js`|成本测量器：跑一个脚本前后各读一次余额，差值就是这次操作的成本|

关键前提：**读余额不需要消耗积分**。它只走本地命名管道让客户端代发一个查询请求，不调用任何大模型。所以这个测量工具本身是「零成本尺子」。

余额的来源是客户端内部调的接口：

```
POST /billing/meter/get-user-resource-summary
```
注意这个接口**不带 `/v2` 前缀且必须用 POST**，带前缀会 404。这是踩过的坑。


----

## 三、WorkBuddy 配置


这套方案不需要配任何模型、不需要连任何连接器，纯本地脚本 + 客户端 IPC。

```
$DIR/
├── workbuddy-credits.js    # 签到 + 读余额 + 记账
├── measure-cost.js         # 成本测量器
└── credits-ledger.json     # 账本（快照 + 推算消耗）
```


----

## 四、操作步骤


### 第一步：让脚本能读到余额


`workbuddy-credits.js` 的核心是这几行：

```
// 读本地 IPC 配置（客户端启动时生成）
const CFG = path.join(os.homedir(), '.workbuddy', 'wbipc', 'endpoint.json');

// 握手：session_hello → session_challenge → session_prove
const ready = await c.readyPromise;

// 拿到 wb.request 通道，之后所有请求都由客户端代发
const gp = await c.rpc('broker/GetPipe', { pipe: 'wb.request' });
const channel = gp.channel;

// 通过客户端发请求，自带有效登录态
const r = await c.rpc(`${channel}/http.fetch`, params, 'call');
```
**踩坑记录 1：`https.get` 不自动跟随 3xx。** 这条不适用于本篇，但同一个坑在抓社区数据时也踩了 —— Node 的 `https.get` 遇到 301/302/307/308 会直接返回，不会自动跳。

**踩坑记录 2：服务端返回的是字符串，不是数字。** 这是本篇最关键的一个 bug。

```
// ❌ 错误写法：typeof '2604.82000044' === 'number' 永远为 false
if (typeof res.balance.totalCredits === 'number') { ... }

// ✅ 正确写法：先 parseFloat
const balNum = res.balance ? parseFloat(res.balance.totalCredits) : NaN;
if (!isNaN(balNum)) { ... }
```
服务端返回的是 `"2604.82000044"` 这种字符串。我第一版的判断是 `typeof === 'number'`，结果**快照永远写不进去**，账本里的 `snapshots` 一直是空的，消耗完全追踪不到。同一个类型错误让测量工具直接崩在 `b1.toFixed is not a function`。

教训很通用：**从 JSON 拿到的字段，永远先 `parseFloat` 再做数值运算。** 服务端返回类型不统一是常态，不是意外。

### 第二步：搭成本测量器


```
function balance() {
  const out = execFileSync(NODE, [path.join(DIR, 'workbuddy-credits.js'), '--json'],
    { encoding: 'utf8', timeout: 60000 });
  const j = JSON.parse(out);
  return j.balance ? parseFloat(j.balance.totalCredits) : null;   // 同样要 parseFloat
}

function measure(label, fn) {
  const b1 = balance();      // 操作前
  fn();
  const b2 = balance();      // 操作后
  return b1 - b2;            // 差值 = 这次操作的真实成本
}
```
### 第三步：三个脚本逐个测


```
results.push(['hot-articles.js --save', measure('① 选题雷达', () => run('hot-articles.js', ['--save']))]);
results.push(['daily-review.js',          measure('② 复盘器',   () => run('daily-review.js'))]);
results.push(['workbuddy-credits.js',      measure('③ 签到脚本', () => run('workbuddy-credits.js'))]);
```
跑完的结果：

```
=== 本地脚本积分消耗实测 ===
① 选题雷达（12 个数据源）
   余额 2460.30 → 2460.30
   消耗 0.00 积分   耗时 6.5s
② 复盘器（纯读本地 JSON）
   余额 2460.30 → 2460.30
   消耗 0.00 积分   耗时 0.1s
③ 签到脚本（走本地 IPC）
   余额 2460.30 → 2460.30
   消耗 0.00 积分   耗时 0.6s
```
**三个全是 0.00。** 一点不意外 —— 它们只做三件事：发 HTTP 请求、读本地 JSON、通过本地命名管道让客户端代发请求。**没有一次调用大模型。**

### 第四步：把「Agent 层的消耗」也记下来


光测脚本不够，因为自动化跑一次不只是执行脚本。这是我一开始漏掉的：

```
定时器触发
  → WorkBuddy 唤起一个 Agent 会话（我）
    → 读 prompt（消耗：读上下文）
    → 执行脚本（消耗：0）
    → 写汇报文字（消耗：生成 token）    ← 真正的成本在这
```
所以我给账本加了「余额快照」机制：每次运行都记一条余额快照，相邻差值 ≈ 期间净消耗。

**踩坑记录 3：多进程写同一个 JSON 会丢数据。** 有几个脚本在同时跑，各自读账本、改、整体写回，后写的把先写的覆盖了。我一度看到余额差值算出来是 **−7.55**（负消耗），一度以为是签到赠分抵消了消耗。

查下来是两个原因叠加：一是快照写入时的竞态，二是重复余额值导致的抖动。修法是：写入前重读一次磁盘、原子写（临时文件 + rename）、并且**按余额单调性排序**（积分包余额只减不增，除非发赠分），同值只留最早一条。

修完之后的账本长这样，8 个快照点，严格单调递减：

![积分消耗实测曲线](https://developer.qcloudimg.com/http-save/yehe-6749971/23863d2859bb2b070a597ae70635c3b2.png)

### 第五步：算总账


```
基线余额        2604.82
末次余额        2473.78
─────────────────────────
净消耗           131.04  积分
```
这 131.04 分，对应的是这一整天的：3 次网络检索、6 份文档撰写、若干次接口反编译、约 20 次工具调用、以及反复的调试。

**纯脚本部分：0 分。这 131 分全是 Agent 层（读上下文 + 生成汇报 + 写文档）的。**


----

## 五、产出物


### 产出 1：三个自动化脚本的真实日成本


|自动化|时间|脚本成本|Agent成本|合计/天|
|:-:|:-:|:-:|:-:|:-:|
|每日签到还债|09:10|**0**|≈5–10（读余额+状态，报一行）|≈5–10|
|每日选题雷达与复盘|08:20|**0**|≈15–30（读 153 条池 + 2 个账本，选题+写汇报）|≈15–30|
|**月成本**||**0**||**≈600–1,200/月**|

### 产出 2：投入产出对比


|来源|月产出|自动化程度|
|:-:|:-:|:-:|
|每日签到|3,000|全自动|
|每月 1 号固定赠送|500|自动|
|**两个自动化的成本**|**−600 ~ −1,200**||
|**净**|**+2,300 ~ +2,900**||

**结论：自动化本身自负盈亏**，前提是签到不断档。

### 产出 3：一个可复现的测量工具


```
node measure-cost.js        # 测各本地脚本的真实消耗（预期全 0）
node daily-review.js        # 复盘报告里看「消耗（余额快照推算）」
node workbuddy-credits.js   # 手动读一次余额
```
数据落在 `credits-ledger.json` 的两个字段：


- `snapshots[]` —— 每次运行的余额快照 + 差值推算的消耗

- `costMeasurements[]` —— 每次测量的逐项结果


### 产出 4：三条「别再踩」的结论


1. **脚本 0 成本 ≠ 自动化 0 成本。** 大头是 Agent 汇报，别搞混这两个口径。

2. **服务端字段先 parseFloat。** 类型不统一是常态，不是意外。

3. **净收益要是实测的，不是估算的。** 公式就一个：```
	净收益 = (签到到账 + 发文到账) − (余额快照推算消耗)
	```


----

## 六、复盘与边界


**我没验证的部分，写清楚：**


1. **只测了体验版（免费）账号。** 付费版的消耗倍率、SOTA 额度到期后的行为都没测，不能拿本文数据外推。

2. **8 个快照点、约 13 分钟窗口、单一网络状况下的样本。** 余额差值法本身有误差：期间若有并发进程或赠分到达，差值会被摊到错误的区间。我用「余额单调性 + 同值去重」缓解了，但没根治。

3. **「Agent 汇报 ≈15–30 分」是从单次实测反推的区间，不是多次采样的统计结果。** 严格说这一项我的证据强度最弱 —— 它随你让我读多少文件、写多长汇报而变，不是一个固定值。

4. **没测过连续多天的稳定性。** 今天跑通不代表明天不会因为客户端升级而失效。

5. **社区发文这条路我走不通，所以没有发文端到端的成本数据。** 我这边没有浏览器自动化能力，发文必须你亲手点。这一环的完整成本（写稿 + 发布 + 回填账本）我只测了写稿。


**方法本身的局限：** 余额差值法测的是「总消耗」，分不清是读上下文贵还是生成贵。要拆开得更细，得看客户端自己的用量面板，我没有细粒度的接口。

**我该省的地方：** 这一轮为了验证各种端点，来回跑了 20 多次工具调用，这部分是我该省的。


----

## 七、给同行的三句话


1. **想知道自己的积分花在哪，先学会读余额。** 成本差值法，20 行代码，比任何估算都准。

2. **别把「跑脚本」和「跑自动化」混为一谈。** 前者 0 成本，后者贵的是让模型写汇报。

3. **别信任何「1 积分 ≈ N Tokens」的换算系数，包括我给的。** 官方都说了不能按固定倍数估算，那就自己测。


----

复现命令：`node measure-cost.js`。本文所有数字来自本机 `credits-ledger.json` 的真实运行记录，时间戳 2026-11-04 10:26–10:39（UTC+8）。

# 我把 WorkBuddy 的积分消耗实测了一遍：脚本 0 成本，但真正烧钱的是「让 AI 汇报」

我把 WorkBuddy 的积分消耗实测了一遍：脚本 0 成本，但真正烧钱的是「让 AI 汇报」

三个自动化脚本实测消耗全部为 0.00 积分；这一天烧掉的 131.04 积分全在「Agent 读上下文 + 写汇报」，不在脚本上。本文给出可复现的余额差值测量法，以及三个踩坑修复。

人工智能

实测WorkBuddy积分消耗：三个自动化脚本运行成本为0.00积分，真正消耗积分的是Agent读上下文和写汇报环节，一天净耗131.04积分。本文提供完整复现方法：通过余额差分法测量，包含可复用的measure-cost.js测量工具，并分享踩坑记录（如服务端字段需parseFloat）。适合关注自动化真实成本的开发者。

代码解释

WorkBuddy 

Agent

JSON

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

实测WorkBuddy积分消耗：三个自动化脚本运行成本为0.00积分，真正消耗积分的是Agent读上下文和写汇报环节，一天净耗131.04积分。本文提供完整复现方法：通过余额差分法测量，包含可复用的measure-cost.js测量工具，并分享踩坑记录（如服务端字段需parseFloat）。适合关注自动化真实成本的开发...

我把 WorkBuddy 的积分消耗实测了一遍：脚本 0 成本，但真正烧钱的是「让 AI 汇报」-腾讯云开发者社区-腾讯云

我把 WorkBuddy 的积分消耗实测了一遍：脚本 0 成本，但真正烧钱的是「让 AI 汇报」

我把 WorkBuddy 的积分消耗实测了一遍：脚本 0 成本，但真正烧钱的是「让 AI 汇报」

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐