惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
Docker
博客园 - 三生石上(FineUI控件)
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园_首页
Microsoft Azure Blog
Microsoft Azure Blog
GbyAI
GbyAI
腾讯CDC
酷 壳 – CoolShell
酷 壳 – CoolShell
M
MIT News - Artificial intelligence
Stack Overflow Blog
Stack Overflow Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Jina AI
Jina AI
爱范儿
爱范儿
博客园 - 【当耐特】
雷峰网
雷峰网
S
SegmentFault 最新的问题
美团技术团队
Blog — PlanetScale
Blog — PlanetScale
The GitHub Blog
The GitHub Blog
有赞技术团队
有赞技术团队
G
Google Developers Blog
大猫的无限游戏
大猫的无限游戏
Google DeepMind News
Google DeepMind News
J
Java Code Geeks

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
豆包“包圆”互联网
字母榜 · 2025-12-19 · via 人人都是产品经理

字节跳动发布的豆包 1.8通用agent模型,标志着其从手机助手向PC端及更多智能设备扩展的重大进步。该模型不仅能理解多模态信息、执行复杂任务,还能实现跨设备协同操作,为用户提供前所未有的便捷体验。尽管面临来自应用开发商的阻力,豆包 1.8展示了AI agent在重塑互联网流量入口方面的巨大潜力。

豆包手机才发布半个多月,字节就发布了通用agent模型豆包 1.8。这是一个能在真实世界中“做事”的多模态大模型。

豆包 1.8可以直接操作你的手机、电脑和浏览器。它能看懂屏幕上的按钮和界面,然后像人一样点击、滑动,帮你完成各种任务。

这是字节一次非常大胆的尝试。要知道,在12月1号的时候,字节才发布了豆包手机。通用agent大模型的推出,让豆包的领地从手机一下就扩张到了PC端,再加上智能硬件以及未来可以预期的智能座舱,豆包算是把互联网从入口层面“一网打尽”了。

此前,曾因为豆包手机,字节已然成为了移动互联网的敌人,微信、淘宝等超级流量APP明确表示拒绝豆包调用。

而现在,随着豆包 1.8的发布,字节的敌人只增不减。

01

先来说说豆包 1.8的评分,更直观的感受它作为agent是否合格。

在多模态理解方面,豆包 1.8的表现具有竞争力。模型能够处理图像和视频内容,单次视频理解的帧数从前代的640帧提升至1280帧。该项提升并非仅体现在数值层面,在实际应用场景中,模型能够以低帧率理解长视频的整体内容,在遇到关键片段时调用工具进行高帧率分析。

比如官方演示中,豆包 1.8就对篮球视频进行分析,最终浓缩出正常比赛的内容。

在公开评测中,豆包 1.8在ZeroBench主集上获得了11.0分,超越Gemini-3-Pro的10.0分,位居业界首位。ZeroBench是极限视觉推理基准测试中的核心部分,评分越高,代表模型越能理解复杂的视频。

在视觉推理任务上,模型在MathVista得分87.7,MathVision得分81.3,LogicVista得分78.3,虽然整体略逊于Gemini-3-Pro,但是仍处于第一梯队。

视频理解方面,模型在VideoHolmes测试中得分65.5,EgoTempo得分67.0,MotionBench得分70.6,在长视频和流式视频处理上同样保持了竞争力。

更为关键的是模型的agent能力。

豆包 1.8能够执行代码、操作图形界面、使用各类工具,这些能力使其能够完成多步骤的复杂任务。在BrowserComp-en搜索任务基准测试中,模型得分为67.6,在智能编程和经济价值领域的相关测试中也表现稳定。

字节在技术报告中提及,模型支持search、code execution、GUI interaction三种核心交互方式,这些能力通过统一的agentic接口实现。

在基础能力方面,豆包 1.8在数学推理、代码能力、复杂指令遵循、知识覆盖等维度均保持了主流水平。在AIME-25测试中得分94.3,BeyondAIME得分77.0,AMO-Bench得分60.0,LiveCodeBench得分79.5。

这些数据表明豆包 1.8的底层能力扎实,字节并未因agent能力而忽视基础建设。

字节专门构建了一些内部评测基准,覆盖教育、客服问答、复杂工作流等高价值场景。

在教育场景的测试中,豆包 1.8得分60.8,在客服问答中得分69.0,均为参与测试模型中的最高分。该结果验证了模型在实际业务场景中的表现。

豆包 1.8提供了四种thinking模式:no_think、think-low、think-medium、think-high。

该设计旨在平衡延迟、计算成本和解决方案质量之间的关系。用户可根据任务的复杂程度选择不同的模式,在需要快速响应的场景使用低算力模式,处理复杂任务时切换至高算力模式。

而且豆包 1.8在视觉编码上进行了优化,减少了图像和视频输入的token消耗。在长上下文处理方面,模型支持256K的上下文长度,并提供了原生API级别的上下文管理。

直白来说,字节已经提前规划好了豆包 1.8有哪些实际用途,以及部署上该如何优化。

02

有意思的是,豆包 1.8的能力范围不限于手机助手,浏览器以及PC端都可以使用。也就是说,字节正在用AI包圆整个互联网。

其实这两年浏览器市场的变化是非常显著的。传统浏览器,比如谷歌的Chrome和微软的Edge,都在加入AI能力。也诞生了许多基于大模型的AI浏览器。

Atlas是OpenAI在2025年10月推出的产品,本质上是Chrome与ChatGPT的结合,将对话助手嵌入传统浏览器。Disco是Google Labs的实验项目,拥有名为GenTabs的机制,能够将用户浏览的标签页直接生成可交互的Web应用。

AI浏览器是一个非常大的市场。Market.us数据显示,2024年全球AI浏览器市场规模约45亿美元,预计2034年将达到768亿美元,年复合增长率达32.8%。

然而豆包 1.8其实可以让设备拥有更神奇的玩法。

该模型的云端架构使其能够实现跨设备协同,也就是说,理论上用户可在手机上向豆包 1.8下达命令,由电脑上的浏览器执行。

比如在手机上浏览抖音时发现感兴趣的内容,想要切换至大屏观看。那么就可以向豆包 1.8发出“在网页上打开该页面”的指令,电脑浏览器便能打开手机上的视频。

这种跨平台能力是传统浏览器AI化难以实现的,也是Atlas、Disco等独立浏览器产品目前尚未拥有类似的能力。

实际上,字节也在效仿微软。微软曾在Ignite 2025大会上宣布Windows正在成为“AI agent操作系统”。

然而字节的想法和微软是不相同的。

微软需要从底层改造Windows系统架构,将agent能力深度集成到内核和API层面。而豆包 1.8的做法更轻量,它是一个系统外部的代行者,就像是外骨骼一样简化用户的操作。

为了实现这个目标,首先就是要理解文字和图表。豆包1.8在这个领域有专门优化。

它不仅能阅读文字,还能理解复杂的学术图表、数据可视化、技术文档中的示意图。在处理包含大量公式、图表和专业符号的学术论文时,模型能够提取关键信息、理解图表含义、建立文字与图示之间的对应关系。

而且PC端的任务往往比移动端要复杂。于是豆包1.8在复杂推理任务中,加入了并行思考机制。通过分配额外的计算资源,它可以同时探索多个解决方案路径,评估不同方案的可行性,最终选择最优解。

实际应用测试显示,豆包能够处理综合性的规划任务。在旅行规划场景中,它可以同时处理多模态信息,从地图、图片、文字描述中收集信息,综合考虑预算、时间、偏好等约束条件,生成详细可行的行程安排。

03

字节想要把AI的蛋糕做大,但是豆包手机已然让字节成为众矢之的,继续升级agent,只会为自己引来更多的敌人。

互联网行业当前的商业逻辑是,用户在应用中停留的时间越长,观看的广告越多,平台获得的收益越高。应用开发商投入大量精力优化界面、设计转化路径、增加用户黏性,目的是让用户尽可能多地接触商业化内容。在该逻辑下,应用是流量的关口,掌握应用即掌握用户。

agent模型的出现,对该逻辑形成了颠覆。在字节的演示中,豆包 1.8能够调用十余个工具完成电商平台的全网比价和下单。

用户无需打开淘宝、京东、拼多多,无需在各应用之间切换,只需告诉大模型“购买性价比最高的某产品”,agent便会自动搜索、比价、筛选、下单。在整个过程中,用户完全不接触应用界面,自然也无法看到任何广告。

实测显示,豆包 1.8可通过playwright MCP工具,按指令在淘宝筛选500-1000元区间销量第一的半入耳式蓝牙耳机,再到唯品会、京东比价并完成加购。

该能力对用户而言是效率的提升,但对应用开发商而言则构成威胁。

广告展示失去了核心场景,原有的流量价值被大幅压缩。更为关键的是,用户对应用的认知可能发生改变。

过去用户的认知是“购物使用淘宝,打车使用滴滴”,现在转变为“向agent说明需求,由其决定使用何种服务”。应用从流量的关口转变为agent可选的工具,互联网的统治权从应用层转向模型层。

豆包手机遭遇的封禁和限制,本质上是应用开发商的防御反应。但该防御能够持续的时间,取决于用户的选择。

但是,规矩是人定的。如果足够多的用户认为agent的使用体验明显优于传统的应用操作,APP开发商将不得不调整策略。

开发商可能开放API接口使agent更好地调用,也可能在agent调用时保留部分广告展示,或者改变商业模式,从流量变现转向服务收费。

况且,AI agent的玩家越来越多。

12月9日,智谱就宣布开源其核心AI agent模型AutoGLM。与豆包手机助手的能力相似,AutoGLM能够稳定完成外卖点单、机票预订等长达数十步的复杂操作流程,并且已支持微信、淘宝、抖音、美团等超过50个高频中文应用。

质谱开源的AutoGLM-Phone-9B总共只需要36GB的空间,就可以完全在手机本地运行。且开源采用MIT和Apache-2.0双许可证,意味着任何人都可以免费下载并用于商业用途。

在移动互联网时代,谷歌凭借开源的Android系统建立了庞大的生态,智谱显然想要在AI操作系统时代复制这一路径。

而且从豆包和智谱的技术实现来看,这个领域的核心壁垒和大模型是完全相同的,腾讯、阿里等等互联网大厂,手里都握着门票。

不过从行业竞争的角度观察,谁能让agent与现有APP生态共存的一方,谁才能占据优势。

字节既拥有模型能力,也拥有应用生态。抖音、今日头条等产品本身即为流量大户,字节能够先在自身应用中测试agent能力,积累经验后再向外扩展。

且字节的云端架构使其能够快速迭代,豆包手机上线半月即推出多次更新,该迭代速度是传统硬件厂商难以达成的。

不可否认的是,豆包1.8是字节的探索性尝试。

它们展示了一种可能性,但距离成熟的产品形态仍有距离。至于最终能够走多远,取决于字节在技术、生态、商业模式上能够实现多少突破。

撰文:苗正 编辑:王靖

本文由人人都是产品经理作者【字母榜】,微信公众号:【字母榜】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。