DAA（日活智能体数）提出来以后，智能体产品怎么对齐口径

AAI空间站calendar_month2026年5月15日visibility站内阅读thumb_up约 7 分钟

百度在 2026 年 5 月 13 日 Create2026 上提出 DAA（日活智能体数），把“智能体有没有真的在干活”抬到比调用量更靠前的位置。对做智能体产品的人，更重要的是先对齐口径：什么算一个智能体、一次活跃需要完成到哪一步、失败与人工接管怎么算。

百度在 2026 年 5 月 13 日的 Create2026 上提出 DAA（日活智能体数，Daily Active Agents）。这类指标一旦被传播开，很容易被当成一句口号，但它指向的问题其实很具体：当你说“我们有很多智能体在用”，你到底在数什么。

如果把 DAA 当成“新的 DAU”，它很快会失真。智能体和普通 App 的差别在于，它更像一段任务过程：触发、规划、调用工具、产出结果、失败重试、人工接管都可能发生。口径不先对齐，DAA 只会变成一个好看的数字。

先把“智能体”从功能点里拆出来

很多产品里所谓的智能体，本质上是一个预置流程：固定 prompt 加上若干工具调用。也有一些产品把智能体做成可自定义的任务执行器，允许用户改指令、改工具、改触发条件。

这两种形态能不能放在同一个 DAA 里统计，取决于你要回答的问题是什么。更常见的做法，是先把智能体分成两类：一类是“固定职责的内置智能体”，一类是“用户可配置的智能体”。两类的活跃意义不一样，混在一起会让你很难判断增长来自哪里。

把活跃定义得太轻，DAA 会被聊天噪声撑大；定义得太重，又会把真实使用压扁。对多数智能体产品，更接近事实的定义通常是：一次活跃至少要完成一次可交付动作。

可交付动作不一定是“最终交付给老板的文档”，但至少要落在可回查的结果上，例如生成一份表格、完成一次结构化整理、触发一次自动化工作流、或对外部系统执行一次低风险操作。你要统计的是“它有没有真的推进过任务”，而不是“它有没有被打开过”。

智能体任务天然会失败。模型输出不稳定、工具调用报错、权限不足、材料不全，都会让任务走不下去。把这些失败都忽略掉，只统计成功，会让 DAA 看起来很漂亮，但你会错过最重要的改进方向。

更实用的做法，是在 DAA 旁边保留三条配套口径：失败率、重试次数、人工接管比例。这样你才能回答一个更现实的问题：今天的活跃到底是“顺利完成”，还是“来回折腾了一圈”。

很多智能体平台会出现一个现象：同一个用户会在 Dify、Coze、n8n 或内部工具之间切换，把任务拆成几段去完成。你如果只按“某个平台里的智能体触发”统计 DAA，很容易得到一个局部真相。

更贴近真实使用的做法，是把 DAA 先绑定到任务链路：一个任务从触发到交付，在哪些环节有智能体参与，参与到了什么程度。这样你才能判断问题出在“入口不够顺手”，还是“执行阶段总失败”，或者“交付环节缺一口”。

落地 DAA 时，建议把三条边界直接写进指标说明里：

1) 计入的最小动作是什么（比如一次成功的工具调用，或一次可回查的结构化结果）。

2) 失败与重试如何处理（失败算不算活跃，重试算一次还是多次）。

3) 人工介入到什么程度就算接管（比如用户手动改了关键参数，或把结果完全重写）。

这三条如果不写清，你们后续做增长、做产品迭代、做对外汇报时，会在同一个数字上产生很多无效争论。