WorkBuddy DAU 1300万、MAU超2000万，凭什么在效率类AI产品中登顶？本文从产品经理视角拆解其底层架构，发现它不是聊天框，而是三层工作台；核心不是主从Agent，而是路由+Skill市场。更关键的是，多Agent协作的真相与官方说法截然不同。这些设计决策揭示了AI产品竞争的新趋势：从模型能力转向工作流嵌入深度。 科技新闻。
助理、项目、自动化，分别对应试用、依赖、托管三个阶段的信任递进。
– 连接器配置：已经对接好的飞书、企微、数据库等工具链
拆了背景与起因
WorkBuddy不是做得最好的AI产品，但它可能是目前工作流嵌入这条路走得最远的。
如果你也在做AI产品，不妨问自己三个问题：
谁的模型最强、谁能生成最好的文案，这些很快会被拉平。真正的差距在于：谁能更深地嵌入用户的工作流，沉淀更多不可替代的资产，建立更高的切换成本。
拆了事件经过
拆完这个产品，我觉得有三个层面的设计可以迁移到其他AI产品。
一个赚开发者的注意力，一个赚组织的切换成本。同一个时代的技术底座，完全不同的商业逻辑。
为什么这个发现重要？
拆了各方回应
拆完我发现，WorkBuddy最值得学的不是它的多Agent营销话术，而是藏在底层的三个产品设计决策。
这不是只有平台型产品才能做的事。哪怕你做的是一个垂直的AI写作工具，只要用户的历史偏好、模板、风格指南能沉淀下来并越用越准，你就在建飞轮。
那它的护城河在哪？
拆了影响分析
这个思路，任何做内容生成的AI产品都可以借鉴。
先拿助理模式试试水，觉得好用了就上项目模式处理复杂任务，最后把重复性工作丢给自动化。
拆完WorkBuddy，我最大的收获不是了解了一个产品，而是看清了一个趋势：
这意味着系统的能力扩展不需要改核心代码。路由层像搜索引擎，Skill的description像SEO关键词，系统自动匹配。
所以多Agent协作是真的，但不是官方描述的一开启就全员上阵，而是创作阶段单Agent，评审阶段才切多Agent。
– Skills：团队打磨好的工作流技能，下次直接复用
我实测下来，发现实际情况比官方说法更微妙。
这个选择没有对错，但你必须做。两头都想要，往往两头都做不好。
但进入评审阶段时，事情变了。
这意味着模型层的军备竞赛对它来说是好事。模型越卷越便宜，它的成本越低，能力越强。模型commoditize，WorkBuddy反而受益。
上下文飞轮的核心逻辑是：用户的使用行为本身在创造资产，这些资产反过来让产品更好用，形成正循环。
– WorkBuddy是用Agent的产品，给普通上班族用，嵌入日常做事。
WorkBuddy的模型策略很务实：规划任务用强模型（Claude Fable 5、Kimi K3），执行任务用快模型（GPT-5.6 Sol、GLM-5.2）。不绑定任何一家。
大多数AI产品只做了聊天这一层。用户来了聊两句走了，什么也没留下。WorkBuddy把三层串起来，用户不会用完就走，而是越用越深、越用越离不开。
系统自动拉起了三个专家Agent：合规审查、技术评审、交互评审。三个Agent并行工作，各自从专业视角审核PRD，最后汇总出54个问题，16个是阻塞项。
带着这个问题，我花了一天把它拆了个底朝天。三种模式全走了一遍，架构逻辑扒了出来，还用腾讯云官方技术文档做了交叉验证。
本文由 @Amber 原创发布于人人都是产品经理。未经作者许可，禁止转载
WorkBuddy的底层不是传统的一个主Agent调度多个子Agent的架构，而是路由+Skill市场。
用Agent vs 建Agent则是一个更根本的选择。同样的底层能力，面向开发者还是面向终端用户，决定了完全不同的产品形态、增长路径和商业模式。WorkBuddy和Coze用同一个时代的技术，走出了两条路。
我用腾讯云官方技术文档做了交叉验证，6项核心结论全部得到证实：路由+Skill架构、SkillHub生态、MCP协议集成、沙箱执行生态、双模运行（云端+本地）、同源底座（与CodeBuddy共享runtime）。
打个比方：
不是所有产品都需要Skill市场，但几乎所有AI产品都需要路由和模块化。
前段时间WorkBuddy的数据刷了一波屏。DAU 1300万，MAU超2000万，效率类AI产品排第一。
用户在WorkBuddy里沉淀的不是聊天记录，而是三类组织资产：
对比Coze，两者的定位差异就清楚了：
这些资产用得越久越值钱，换平台的成本越高。这不是用户粘性，是组织粘性。即使某个员工觉得另一个工具更好用，公司层面的迁移成本也让他走不掉。
这个结论在官方文档里没有显式提及。官方确认了专家团机制和联邦式并行能力的存在，但没说创作阶段单Agent、评审阶段才切多Agent。这是实测才能发现的。
做垂直AI产品的建议：先把路由层和Skill封装做好，市场那一层等验证了PMF再说。
这里最关键的设计是，每个Skill是一个自包含的mini-Agent。它自带路由规则、自带工具、自带执行逻辑。新Skill上架时不需要改路由层的代码，它通过description字段的关键词，声明式地告诉路由层自己能处理什么意图。
合规Agent抓出了数据合规风险和权限边界问题。技术Agent质疑了架构选型的可行性。交互Agent提了信息密度和操作流程的优化建议。质量相当扎实。
具体来说，路由分四层：
大部分AI产品的问题是只做了助理这一层。用户第一天和第一百天的使用方式完全一样，没有留下任何资产，也没有深入使用的路径。
参考资料
打开WorkBuddy，第一眼你会觉得它就是个聊天框。但用下来发现，它有三种完全不同的工作模式。
WorkBuddy的设计是：先用助理模式体验到价值，然后自然地尝试项目模式处理更复杂的任务，最后把重复工作丢给自动化。每一层都比上一层更深地嵌入工作流，每一层都沉淀更多资产。
这三个问题的答案，可能比你选哪个大模型重要得多。
– SOP：跑通的流程自动沉淀为标准操作模板
-WorkBuddy更像一个购物中心，有一个导购台（路由层），楼里有几万家独立店铺（Skills），你说想买什么，导购台帮你找到最合适的那家店。
WorkBuddy的营销一直在讲多Agent并行协作，官方原话叫一句话拉起一支助理团。
市面上能聊天的AI工具多了去了，ChatGPT、豆包、Kimi都能帮你写东西查资料。WorkBuddy做了什么不一样的事，能把DAU拉到这个量级？
这三种模式对应的是用户的三个成熟度阶段：
– Coze是建Agent的工具，给开发者用，做Agent的POC验证。
在资产层。
传统多Agent架构像一个公司，有CEO（主Agent），下面有各部门经理（子Agent），CEO把任务分下去。
这是我拆出来最有价值的发现。
作为一个AI产品经理，我的第一反应不是好厉害，而是它凭什么。
AI产品的竞争正在从模型能力转向工作流嵌入深度。
因为它揭示了一个产品决策：让一个Agent从头到尾保持上下文一致性地完成创作，比让多个Agent分工写不同部分更靠谱。多Agent的价值不在一起干活，而在交叉校验，用不同视角发现单一视角的盲区。
还是那个比喻：购物中心需要招商部（Skill行业动向），但专科医院不需要，你不会让外面的医生随便来坐诊。 但两者都需要导购台（路由）和标准化的科室建设（模块化）。
我在项目模式下让它帮我写一份Agent产品的PRD。创作阶段，全程只有一个主Agent在工作，没有拆计划、没有分角色，一个人从头干到尾。
你的产品不需要也做三种模式，但要问自己一个问题：用户有没有用得更深的路径？ 如果没有，你就没有建立任何壁垒。
题图来自Unsplash，基于CC0协议
