腾讯、字节正在加快争夺电梯间：WorkBuddy、Trae打响的是一场模型调度战？

办公Agent的商战正在以一种相当朴实的方式展开。

日前，华尔街见闻·全天候科技在北京朝阳区一处住宅小区的电梯里发现，字节旗下TRAE Work开始投放广告。

“复杂工作，就用TRAE Work。”广告旁边附着二维码，新用户扫码可以获得4500积分。

就在不久前，这部电梯里的另一块广告屏上投放的还是腾讯WorkBuddy。

这正是近期办公Agent竞争升温的注脚。

过去几个月，大厂几乎已经完成一轮桌面办公Agent的排兵布阵。阿里推出千问办公，腾讯主推WorkBuddy，百度上线百度搭子（DuMate）；字节旗下既有正在与飞书进一步整合的豆包办公，也有正向通用办公场景扩张的TRAE Work。

几款产品瞄准的任务越来越接近，但从模型层来看路线仍有明显差异。

千问办公以自有模型体系为能力锚点，豆包办公背后同样有字节自有模型和飞书工作流作为支撑；TRAE Work和WorkBuddy则更突出多模型聚合，希望把不同模型的能力装进同一个桌面工作台。

自有模型路线仍然要持续向训练要能力，模型本身越强，Agent能够处理的任务上限也越高；聚合路线面对的则是另一道题，即当手里同时有多个模型，什么时候该用谁？

这些问题暂时都没有标准答案。

电梯里的暗战

过去几个月，大厂围绕办公Agent的竞争，更多发生在产品发布和组织调整层面。

其中，字节7月底对豆包、飞书和火山引擎的调整尤其受到关注。

此前，飞书作为字节独立BU运行，负责人谢欣直接向字节CEO梁汝波汇报。此次调整后，飞书产品团队与豆包产品团队整合，谢欣改为向豆包负责人赵祺汇报；飞书GTM团队则与火山引擎相关团队进一步整合。

这次调整引发关注，还有一个原因是飞书本身的业务表现并不弱。

在这样的背景下，飞书的产品和销售体系依然被重新拆分和组合，字节围绕AI办公重新配置资源的意味也更加明显。

调整完成后，由飞书团队深度参与开发的豆包企业版已经开始在部分飞书客户中内测。飞书原有的文档、表格、会议和群聊等办公能力，也成为豆包进一步进入企业工作流的基础。

一时间，豆包办公成为外界观察字节下一步AI办公布局的重点。但真正先和WorkBuddy打起来的却是TRAE Work。

在北京朝阳区一处住宅小区的电梯里，已经可以看到TRAE Work的广告。

图源：摄于北京朝阳区

就在不久前，同一部电梯里的另一块广告屏上投放的还是腾讯WorkBuddy。如今WorkBuddy的广告已经撤下，TRAE Work又出现在了旁边的另一块屏幕上。

图源：网络

这场发生在电梯里的碰面，也让字节内部另一条办公Agent路线重新进入视野。

TRAE最初从AI编程工具切入。今年6月，TRAE SOLO正式升级为TRAE Work，产品边界也从代码生成进一步扩展至研究、写作、数据分析、方案制定和跨团队协作等通用办公场景。

从SOLO到Work，TRAE想覆盖的已经不只是编程任务，这套产品定位正在被推向更广泛的办公人群。

TRAE向通用办公扩张也并非从零开始。易观统计显示，今年6月WorkBuddy桌面端月访问量达到2097万次；同期TRAE IDE国内版月访问量达到1279万次，排名第二。6月升级后的TRAE Work已经与TRAE IDE实现账号互通和项目资源流转。

豆包办公获得了字节这一轮组织调整的大部分声量，真正先在线下和WorkBuddy争夺用户的却是TRAE Work。

TRAE Work要面临的竞争压力正在进一步加大。

对外，TRAE Work要和WorkBuddy抢用户；对内，它还要回答和豆包办公如何共存。

模型池里的微妙边界

如果继续往模型层看，办公Agent的竞争又出现了另一处分化。

一条路线是押注自有模型。

千问办公目前更以千问模型作为能力锚点。阿里官方将其定义为“基于千问系列大模型”，模型选择器目前提供基础、高级、经济以及Qwen3.8-Max等不同档位；

豆包办公的路径也是依托字节自有的Seed模型。

对这类产品而言，模型能力持续训练和迭代仍然直接决定着Agent能力的上限。

TRAE Work和WorkBuddy走的是另一条路，那就是多模型聚合路线。

WorkBuddy支持多模型切换，内置包括混元、GLM、MiniMax、Kimi、DeepSeek等模型，并提供Auto模式，根据任务自动选择模型。TRAE Work目前也内置各种模型和提供Auto模式。

即便选择聚合路线，两款产品目前拿到的牌也并不完全相同。

从当前产品提供的模型选择来看，WorkBuddy的默认模型池中没有阿里的千问和字节Seed；TRAE Work目前可见的模型选择中则没有腾讯混元，却内置了千问的3.7版本。

这个差异暂时还不足以说明大模型厂商之间已经形成固定阵营，Seed等模型同样可以通过API进入第三方Agent。

从模型池的边界可以嗅得腾讯和字节的竞争硝烟：一方面，WorkBuddy和TRAE Work希望接入更多模型，把自己做成通用工作台；另一方面，腾讯和字节又分别拥有混元和Seed，自家的基础模型本身也在争夺调用量和用户使用。

这也留下了一个新的问题：当办公Agent开始承接越来越多真实任务，它会不会成为新的模型分发渠道？桌面入口之争背后是否还会进一步演变成模型调用量之争？

路由成了下一道题？

当一个Agent手里同时拥有多个模型，如何调度就成为聚合路线绕不开的问题。

这背后首先是模型能力正在进一步分化。

随着模型持续迭代，各家模型在代码、复杂推理、长文本、搜索、响应速度和调用成本上的长板开始变得更加鲜明。

这种差异到了Agent场景会被进一步放大。一项复杂任务往往需要连续调用模型数十次，不同环节使用什么模型会直接影响任务完成效果、耗时和成本。

路由虽然藏在后台，对用户体验的影响却越来越直接。

理想状态下，用户只需要提出任务，后台自动完成模型选择：简单的信息提取交给速度更快、价格更低的模型，复杂推理和代码任务再调用能力更强的模型。

对于个人用户，这最终体现为等待时间和积分消耗；到了企业场景，则进一步变成算力开支。

如何在任务效果和算力成本之间找到平衡，也就成为路由最直接的用户价值。

如果WorkBuddy、TRAE Work这类聚合型Agent最终积累起足够多的用户，路由还可能形成另一价值——数据飞轮。

每一次真实任务都会留下关于模型表现的反馈：什么任务交给哪个模型成功率更高，需要多久、消耗多少Token，又在哪些情况下容易失败。

在符合隐私、授权和数据治理要求的前提下，这些反馈可以反过来优化路由策略。

与此同时，这还可能改变模型厂商与Agent平台之间的关系。

过去，大模型厂商更多争夺用户和开发者主动调用。随着越来越多任务由Agent完成，用户可能逐渐把模型选择交给后台。

对模型厂商来说，进入路由层也就意味着进入更多真实任务。如果某个模型在代码、搜索、推理等特定任务上形成明显优势，就可能获得更多调用。

模型之间的竞争也可能从争夺用户主动选择，进一步延伸至争夺路由系统的选择。

用户需要路由管理模型选择和算力开支，模型厂商则需要借助这一层触达更多真实任务，路由层由此站到了模型供给和用户需求之间。

资本市场也已经开始关注聚合平台的价值。今年5月，全球最大的模型聚合平台OpenRouter完成1.13亿美元B轮融资，投后估值达到13亿美元。

但这套商业价值能否真正跑通还取决于路由能否足够准确。

目前，行业对此尚未形成统一答案。腾讯内部不同研究团队的探索已经体现出这种分歧。

腾讯混元与中国科学院大学研究者提出的DecoR，更关注单次请求，将Query拆成技能、知识和难度等能力需求，再结合历史表现寻找更匹配的模型。

腾讯微信团队与上海交大的另一项研究则把时间尺度拉长，认为当前一步表现更好的模型未必能带来整段任务的最优结果，模型切换还会影响缓存复用和累计成本。

一个关注“这一次请求应该交给谁”，另一个开始考虑“一连串模型选择最后会产生什么结果”。

究竟应该什么时候切换模型、多久切换一次，目前仍然没有标准答案。

但对于聚合型Agent来说，商业问题已经相当具体。谁能够更准确地把真实任务分配给合适的模型，同时把算力成本降下来，谁就更有机会把多模型真正变成产品能力。 风险提示及免责条款

市场有风险，投资需谨慎。本文不构成个人投资建议，也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。