项目
项目token 消耗分析 协作方式一个人负责到底 基建飞书里的 mew 我的工作在 token 效率上 结果已上线 Kaboo字节内部的开源项目 没有接力提出、解决、测试、上线 mewAgent 嵌入开发流程 问题任务成功了,但浪费 token 已上线由我测试并部署 Token 消耗token 花在哪,为什么 两道保险上线前 Agent 检查,上线后可回滚 接进飞书从想法到上线的路已铺好 解法五类浪费标准、Effective Tokens 覆盖10K+ 名内部用户 协作方式 我做的东西
字节跳动 · 内部开源 · Token 效率 · 10K+ DAU

Kaboo

字节内部的一个 token 消耗分析开源项目,全程没有交接:问题是我提的,Token 效率榜是我设计的,测试和上线也是我自己做的。

公司
字节跳动
项目
Kaboo,内部开源
我负责
Token 效率榜
覆盖
一万多名内部用户

这是什么项目

Kaboo 是字节内部的一个开源项目,做 token 消耗分析。

但这个项目最有意思的不是做了什么,而是怎么做的:它用的是一种全新的协作方式。

协作方式

这里没有“提需求、排期、开发、测试、上线”的多人接力。谁提出问题,谁就自己想解法、自己跑测试、自己部署上线,每个人独立对自己那一块负责。

质量靠两道保险:

  1. 上线前,有 Agent 帮忙检查有没有问题。
  2. 上线后,出了问题可以及时回滚。

为什么能这样

能这样做是因为基建到位了。我们用的是 mew,一个把 Agent 嵌进软件开发流程的项目管理平台,而且接进了飞书。

从想法到实现的这条路已经铺好,只要能把自己的想法说清楚,就可以直接把它做出来、上线。

我做了什么

我在这种方式下负责 Token 效率榜和效率分析模块。

问题是我提的。 大家只看 Agent 失败在哪,没人看“任务成功但过程很浪费”的情况。

解法也是我想的:

  • 定了五类浪费的判定标准。
  • 设计了只用元数据、不碰内容的诊断方案。
  • 用 Effective Tokens 把不同模型的成本归一化。

然后自己测试、自己上线,现在覆盖一万多名内部用户。

我的体会

这段经历让我对 AI 时代的协作有了很具体的认识:当实现的成本被基建抹平之后,瓶颈就变成能不能把问题想清楚、说清楚。

一个人的价值更多在判断上,而不在执行上。

画板

拖动画布移动 · ⌘ / Ctrl + 滚轮或双指缩放 · 全屏查看更清楚

成果

10K+
效率榜和效率分析目前覆盖的内部用户
5
五类浪费,每类都有明确的判定标准
只用元数据
诊断从不读取会话内容