LobsterAI 报告：办公 Agent 单任务 Token 规模为 3 月的 3.2 倍，77% 的 IM 派活走微信

• 任务规模变化：报告显示，9 月单次任务的 Token 规模是 3 月的 3.2 倍。这一口径衡量的是用户交给 Agent 的单次工作量，而非调用次数——同一时间段内单任务负载扩大三倍以上，意味着上下文长度、工具调用轮次与中间产物的总量同步上升。
• 任务类型结构：设计、影视与创作类任务占比升至 17.2%。报告方的解释是，图片与视频生成完成后仍有整理、修改、交付等大量后续工作，这些环节由 Agent 承接，使多模态内容生产从「生成一次」变为「生成后处理」的长链路。
• 派活入口分布：报告统计的 IM 派活用户中，77% 使用微信。入口选择直接影响 Agent 的触发时机与任务形态——用户在手机上想到什么就先发过去，任务在本人不在工位时启动。
• 成本结构提示：报告建议关注缓存命中情况。Agent 执行任务需反复读取前文，缓存能否命中、命中后的折扣比例会显著改变最终费用，单 token 单价低不等于单任务成本低。
• 城市分布：郑州进入城市前十，重庆用户有深夜使用特征。报告未披露各城市的具体用量与统计口径。
• 信息边界：上述数据来自 LobsterAI 报告，本次素材为第三方对其的解读帖，未提供样本量、统计周期、付费与免费用户划分、Token 计费口径，也未说明「单次任务」如何界定。城市排名与深夜使用特征缺少可核对的数值。
• 行业观察：这条数据的价值在于把观察点从模型跑分移到使用侧——单任务负载扩大 3.2 倍，直接对应推理侧的长上下文压力与缓存设计权重；创作类任务占比上升，说明 Agent 的交付物正从文本扩展到需要后续整理与修改的多模态资产；而 77% 的派活集中在一个 IM 入口，意味着 Agent 产品的分发位置可能不在独立应用内，而在用户已有的沟通流里。三项数据都指向同一个工程约束：任务越长、入口越轻，中间状态的保持与成本控制就越关键。

🔗 小互原帖