WorkBuddy 两千万月活:Agent 创业者先问数字怎么来的Chapters1×0:08开场:一个两千万数字,为什么值得拆开1:26一、Agent 共识先改变工作入口3:36二、用户量先要问口径6:40三、Agent 产品评估的是任务8:37四、Token 和收入要互相校验11:25五、把行业叙事换成自己的任务账本0:0014:320:08主持人一个产品被报道成有两千万月活,最容易发生的反应,是立刻把它当成市场规模和融资故事的证据。但「屠龙之术」这期节目真正有用的地方,恰恰是把这个数字拆回它原来的口径。0:24主持人节目从 WorkBuddy 的两千万月活讲起,往前讨论模型竞争、Codex、Agent 基础设施和评估,往后又追问用户量、Token,以及最后更硬的收入指标。它不是一篇关于某个产品真假的裁判报告,而是一场对 AI 应用指标的现场质疑。0:43主持人本期我们保留原集的上下文,提炼五个给 AI 产品创业者的判断。第一,工作型 Agent 的共识改变了什么。第二,用户量为什么最容易被误读。第三,Agent 产品应该怎么评估。第四,Token 和收入怎样互相校验。第五,一周之内怎样把这些判断变成自己的任务账本。1:09主持人先把结论放在前面:媒体数字可以帮助你发现一个市场,但不能替你证明产品成立。真正需要证明的,是用户是否把一段工作交给了产品,产品是否完成了这段工作,以及客户是否愿意为结果持续付费。1:26主持人第一个判断是,工作型 Agent 的共识,首先改变的是工作入口,不是产品名称。过去大家讨论 Chat,重点是用户问什么、模型答什么。现在讨论 Agent,重点变成用户能不能把一段任务交出去,让系统自己调用工具、处理上下文,再把结果交回来。1:46主持人这会让产品竞争从回答质量,移动到任务边界。一个 Agent 不是把聊天窗口换成一个更大的按钮,而是要回答四个问题:任务从哪里开始,系统可以替用户做哪些动作,什么结果算完成,失败时谁接手。2:03主持人这也是为什么节目把模型、Agent Infra 和评估放在一条线上。模型能力决定上限,基础设施决定能不能稳定跑,评估决定团队是否知道哪里真的变好了。少掉任何一环,产品都可能只剩下一次演示。2:21主持人共识形成得快,对创业者既是机会也是警告。机会是用户已经开始接受把工作交给 Agent,警告是所有团队都可能用同一句话描述自己。你不能只说自己在做 work agent,要说清楚自己接管的是哪一段工作,替谁减少了哪一种重复劳动。2:41嘉宾原声范式,尤其是在所谓的 work agent 这个板块,这个共识形成得非常非常快。那在这里我就引用了一张国内的图表,就是易观这家数据机构。2:56主持人这段原声里的「共识」不是需求已经被证明,而是市场开始用同一套语言描述机会。对早期团队来说,下一步不是把首页改成 Agent,而是找一个能重复发生、能被验收的任务,把输入、执行、结果和失败处理完整记录下来。3:16主持人如果你做的是销售研究,就不要只统计用户问了多少次问题,要看报告是否真的交付,销售是否少做了一轮人工核对。如果你做的是代码 Agent,就不要只看生成了多少行代码,要看测试是否通过、返工是否减少、最后谁承担上线风险。3:36主持人第二个判断,是「两千万月活」这句话本身不够成为判断。月活这个词听起来很硬,但它至少可能混进五种不同东西:登录账户、打开页面、和 Agent 交互、完成一次任务,以及持续回来并产生付费行为。3:55主持人这几种行为对产品的意义完全不同。打开过一次,说明传播或分发触达了用户;完成过一次任务,说明产品有用;下周还回来,说明它可能进入工作流;愿意付费并且续费,才开始接近商业价值。4:12主持人原节目提到的数字,来自一份对桌面端 AI 原生办公智能体平台访问量的报告。这里的关键词是「访问量」和「交互次数」,它们不是天然等于独立用户,更不能直接等于月活。数字越大,越需要把分子和分母写出来。4:30主持人这件事对创业公司的提醒很具体。你们的用户指标表至少要拆成账户数、真正发起过任务的用户数、完成过任务的用户数、第二次回来的人数、付费账户数。每一列都要有时间范围,不能把访问、调用、任务和收入放在一张增长曲线里。4:51主持人还要把一个用户的重复行为拆出来。一个人一天点了二十次,可能是高频使用,也可能是任务失败后不断重试。一个账户里有十个人轮流使用,可能是团队扩散,也可能只是一个管理员在替别人试用。总次数本身不告诉你是哪一种。5:09主持人所以创业者遇到一个漂亮的行业数字时,第一反应不该是把它写进融资材料,而是追问四件事:统计对象是谁,行为发生了什么,数据覆盖哪个时间段,独立用户和重复行为怎么区分。缺一项,数字就只能当线索,不能当结论。5:29嘉宾原声一点点小的吐槽。先说易观那份报告,我推荐所有要引用的媒体朋友、分析师朋友,都稍微谨慎一点。第一,所谓的访问次数是指用户和 Agent 的交互次数,这不是 MAU,也不是 UV,甚至连 PV 都算不上。你可以理解成类似用户对话和点击的次数。我拍脑袋算一下,真实的 UV,或者说 MAU 的数字,应该是图表里的这个数字的十分之一,甚至几十分之一才对。5:59主持人这段原声最值得带回团队的,不是「十分之一」这个估算,而是估算之前的动作。庄明浩先区分访问次数、交互次数和独立用户,再对报告能不能支持媒体标题提出质疑。创业公司做自己的数据分析,也应该保留这一步,不要让图表标题替你完成定义。6:21主持人当然,这并不证明 WorkBuddy 的真实用户量就是某个更小的数字。原节目提供的是口径质疑和估算,不是经过产品方审计的用户数据。本期也不把两千万当成已证实事实,而是把它当成一个练习:任何增长数字都要回到行为定义。6:40主持人第三个判断,是 Agent 产品的评估对象必须从模型分数转向任务结果。传统模型评测可以告诉你某个能力在标准数据集上的表现,但用户交给 Agent 的任务,往往还包含浏览、调用工具、记住上下文、处理异常和交付结果。6:58主持人因此,团队至少要记录五件事:任务完成率,人工接管率,失败后的恢复率,用户等待时间,以及完成一次任务的模型和人工成本。它们共同回答一个问题:用户把工作交给产品以后,是否比原来的流程更可靠。7:18主持人这里最容易出现的误区,是把评估做成一张漂亮的排行榜。模型版本升级了,分数上升了,团队就认为产品变好了。但如果真实任务的人工接管次数变多,或者用户需要把同一个需求反复说三遍,排行榜的变化对客户没有帮助。7:37主持人Agent 的评估还必须包含失败。系统第一次没做对并不可怕,关键是能不能解释失败发生在哪一步,能不能让用户补充信息,能不能恢复到可交付状态。如果每次失败都靠人工在后台擦掉,平均完成率会很好看,交付成本却会悄悄失控。7:58主持人做评估集也不能只挑最适合演示的任务。你要把真实用户最近一周失败过的案例放进去,保留权限不足、数据缺失、工具超时、上下文错误和用户临时改要求这些情况。评估不是为了证明产品聪明,而是为了告诉团队下一次该修哪里。8:18主持人对早期团队来说,最小的评估闭环并不复杂。每周固定抽取一批真实任务,标记完成、部分完成和失败,记录人工补救的分钟数,再把同一批任务跑过新版本。只要任务和成本能连续比较,模型路线就不再靠感觉选择。8:37主持人第四个判断,是 Token 用量也可能成为另一种虚荣指标。用户量容易被访问次数放大,Token 量则容易被长上下文、重复调用和失败重试放大。它能说明系统很忙,却不能单独说明系统创造了价值。8:55主持人节目后段把问题推得更远:如果大家已经不再频繁比较某个 Coding Agent 有多少用户,也不再迷信消耗了多少 Token,那到底什么是标准。这个问题不舒服,但它迫使创业者把增长指标和商业结果放在同一张表里。9:13嘉宾原声问一个问题,你关心 Claude Code 有多少用户量?没有人关心了。为什么?还有一个问题,很多人说 Token 量是不是一个好的数字呢?我在上一次 PPT 也讲过,没有人再去所谓的 Token maxing 了,对吧?没有人再去研究所谓的今天你耗费了十亿还是二十亿的 Token 了,Token 量也不是一个好的指标。那什么是标准呢?似乎又是那个特别特别悲观的结论,钱永远是最赤裸裸的标准。所有人都看 ARR,不是吗?你根本不关心 Claude Code 多少用户,你只关心 Claude Code 的 ARR 到多少,不是吗?9:51主持人这段原声里的「看收入」不是说收入天然正确,而是说收入比访问次数和 Token 更接近客户的真实选择。对创业团队,收入还要继续拆成客户数、合同金额、续费率、毛利、单个任务成本和人工兜底成本。只看总收入,也可能把亏损的交付包装成增长。10:14主持人一个更有用的关系是:Token 增长时,任务完成率是否上升;完成率上升时,人工接管是否下降;成本下降时,客户是否愿意续费。如果 Token 翻倍,客户没有多买,人工也没有少做,说明你只是把更多计算花在了同一个问题上。10:35主持人反过来,Token 量下降也不一定是好事。模型变小了,成本降了,但结果质量下降,客户开始自己返工,表面上的单位成本就会掩盖真实成本。所以指标要围绕完整任务算,不能只截取模型调用这一段。10:53主持人对于个人订阅产品,重点可以是付费转化、连续使用和退款;对于企业产品,重点还要加上部署成本、权限配置、交付周期和续约。不同产品的收入形态不同,但都要回答同一个问题:客户为什么在下一周期继续付钱。11:12主持人如果这个问题回答不了,用户量、Token 和收入都可能只是孤立的数字。创业者要做的不是挑一个最漂亮的指标,而是把一条从用户任务到现金回款的链路接起来。11:25主持人第五个判断,是当所有人都宣布进入 work agent,创业者更需要一张自己的任务账本。行业共识可以帮你找到方向,但不能帮你选择场景,也不能替你承担失败后的成本。11:40主持人第一天,选一个最常发生、最容易复现的任务,写出用户是谁、输入是什么、什么结果算完成。不要用「体验更好」当验收线,要写成另一位同事可以复核的条件。11:55主持人第二天,把最近一周真实失败的任务放进评估集。记录用户在哪一步退出,模型在哪一步出错,工具有没有返回错误,人工花了多长时间补救。不要先删掉不好看的案例,它们才是产品下一版最便宜的需求文档。12:12主持人第三天,把一次完整任务的成本算清楚。模型调用、Token、工具调用、重试、人工审核和客户支持都算进去。轻度用户和重度用户分开看,平均值不能盖住最贵的那一批任务。12:27主持人第四天,把产品、模型和销售放在同一张表前面。产品说完成率变好了,模型说评测分数变高了,销售说客户更愿意买了,三句话必须能指向同一批任务,否则团队只是各自拥有一组好看的数字。12:45主持人第五天,做一次反向检查:如果删除行业报告、媒体标题和竞品估值,你们还剩下哪三个数据,能证明用户真的把工作交给了产品,并愿意继续付费。如果答不上来,就先停止扩张场景,补证据。13:01主持人这五天的目标不是做出一张完美仪表盘,而是让团队从「大家都在做 Agent」回到「我们替谁完成了什么任务」。能把这句话说清楚,才知道下一步该换模型、加工具、改流程,还是干脆放弃这个场景。13:18主持人也可以把它变成团队的五个复盘问题:你们的月活到底是什么,任务完成如何定义,失败由谁接住,Token 和人工成本是否可解释,客户为什么续费。每个问题后面都要有数字和样本,不要只留一句判断。13:35主持人回到 WorkBuddy 两千万月活这个标题,本期没有替听众判定这个数字真假。更有用的判断是,访问量、用户量、Token 和收入分别回答不同问题,任何一个数字都不能越权替另一个数字背书。13:52主持人工作型 Agent 的竞争才刚进入更具体的阶段。模型能力仍然重要,但创业者要把注意力放到任务边界、失败恢复、交付成本和客户续费上。数字越大,越要问它到底测量了哪一种行为。14:09主持人这里是七档 AI 创业者精选播客缩短版。本期内容依据「屠龙之术」公开原音频和 shownotes 整理,原声片段保留了原集对应时间线。感谢收听,我们下期再见。