据《华尔街日报》报道,人工智能公司OpenAI将以65亿美元的全股权交易方式收购由苹果前首席设计师乔纳森·艾夫(Jony Ive)与OpenAI首席执行官萨姆·奥特曼(Sam Altman)共同创办的设备初创公司io。此次交易完成后,艾夫及其设计公司LoveFrom将全面负责OpenAI的创意与设计工作。 奥特曼在社交平台X上表示,“与乔纳森合作令人兴奋,个人认为他是世界上最伟大的设计师”,并对打造新一代由人工智能驱动的计算设备充满期待。 此次合作使乔纳森·艾夫,这位曾主导设计iPhone、iPod、iPad与Apple Watch等标志性产品的苹果前设计主管,成为生成式人工智能新一波技术浪潮的核心人物。自2022年ChatGPT推出以来,OpenAI持续扩大其面向消费者的业务。本月早些时候,OpenAI还任命前Meta高管、Instacart前首席执行官Fidji Simo负责公司消费者应用的发展。 业内人士分析指出,艾夫的加入将增强OpenAI在消费类硬件市场的竞争力,对苹果构成更大压力。近年来,苹果在人工智能功能方面的发展步伐落后于OpenAI和谷歌。受该消息影响,苹果股价在周三下跌了2%。 据《华尔街日报》透露,io拥有约55名员工,涵盖工程师、科学家、研究人员、物理学家以及产品开发专家,其中不少人曾在苹果任职,包括Scott Cannon、Evans Hankey与Tang Tan等,这些人才将全部加入OpenAI。 尽管参与OpenAI的设计工作,艾夫仍将保留其LoveFrom设计公司的控制权,LoveFrom将继续独立运营。 在此次收购后,io将成为OpenAI旗下专注于AI驱动消费设备及相关项目的子公司。外界普遍认为,奥特曼与艾夫正合作开发一种能让用户“超越屏幕”的设备。彭博社报道指出,首款设备预计将在2026年面世。《华尔街日报》还补充称,艾夫未来将在ChatGPT的后续版本以及其他OpenAI项目中扮演关键角色。 据《纽约时报》报道,OpenAI早在去年就已通过与io的协议持有该公司23%的股份,因此这次收购将以50亿美元的金额完成剩余部分股份的收购,成为OpenAI史上最大一笔收购案。另有消息指出,OpenAI的创业基金去年也对io进行了独立投资。 在OpenAI发布的视频中,奥特曼表示,io的使命是打造一系列AI设备,帮助人们借助人工智能“创造各种奇妙事物”。艾夫在视频中称,相信过去30年所积累的一切经验都指向了现在这一时刻。他表示,io目前正在开发的第一款AI设备已经“彻底激发了他的想象力”。 目前AI硬件设备仍处于发展初期阶段。值得一提的是,奥特曼早前也投资了另一家由苹果前员工创立的AI硬件公司Humane,该公司推出了AI驱动的“胸针”设备,但在经历一系列挫折后被惠普收购,其产品线也被终止。 与此相比,其他AI设备形态则显示出更多潜力。Meta与眼镜制造巨头EssilorLuxottica合作推出的AI智能眼镜在消费者中获得了良好反响。本周,谷歌也宣布与三星、Warby Parker及其他合作伙伴联合开发AI智能眼镜。 尽管如此,OpenAI的设备最终将呈现何种形态仍未可知。在视频后半段,奥特曼指出,通过笔记本或智能手机访问ChatGPT体验繁琐,他更倾向于使用一种能深度融入日常生活的设备。 据《The Information》早在今年三月披露,OpenAI与io的收购谈判已启动。彼时两家公司正在探讨打造一款设备,以实现电影《她》中的AI交互式体验。
Author: aitrendtrackers@rengongzhineng.io
2025年Google I/O开发者主题演讲重点内容:开发者应关注的AI与平台创新
2025年5月20日,Google I/O团队发布了年度开发者主题演讲,其中聚焦于如何在Google不同平台上开发,并通过DeepMind旗下的先进AI模型推动创新。以下为此次演讲中的重要发布内容整理与解读: 一、Gemini模型与AI平台工具革新 Google AI StudioGoogle AI Studio成为使用Gemini API进行原型开发的最快方式。最新集成了Gemini 2.5 Pro,结合GenAI SDK,可根据文本、图像或视频提示即时生成网页应用,展示项目案例、快速启动开发。 Gemini API支持构建代理式体验利用Gemini 2.5的高级推理能力,开发者可通过“URL上下文”功能让模型仅凭链接抓取网页内容。同时,Gemini SDK将支持Model Context Protocol(MCP)定义,便于集成开源工具。 Gemini 2.5 Flash原生语音能力Live API新增原生语音生成能力,支持24种语言,对语速、语调、风格等实现高度控制。模型能更好理解对话节奏,过滤杂音,带来自然流畅的互动体验。 Stitch:AI生成UI与前端代码工具Stitch能生成高质量的用户界面设计,并输出对应CSS/HTML或Figma资源。用户可通过对话形式进行主题调整与快速迭代,加快Web前端开发流程。 Jules异步代码代理上线公开测试Jules是一款并行异步代码智能代理,能直接操作GitHub代码库,自动处理版本升级、测试编写、功能迭代与Bug修复。其会自动在云端运行虚拟机,修改代码并提交PR。 二、Android平台:设备与AI能力融合 生成式AI增强移动应用体验基于Gemini Nano的ML Kit GenAI API面向本地设备推出,支持常见任务。展示应用Androidify通过自拍生成个人化Android机器人。 支持跨500M设备适配的卓越体验从手机、折叠屏、平板、ChromeOS拓展至汽车与XR平台。Material 3 Expressive帮助开发者打造更具表现力的应用界面。 Android Studio中集成Gemini AI助手Gemini协助开发者完成测试编写、依赖更新等任务。全新“Journeys”功能支持端到端测试场景;“Version Upgrade Agent”协助管理依赖更新。 三、Web开发者新功能亮点 简化轮播图组件开发借助Chrome 135引入的全新CSS原语,开发者仅需几行代码即可创建响应式、可访问的轮播图与其他动态UI。 Interest Invoker API试验发布结合Popover与Anchor Positioning API,允许开发者无需JavaScript即可创建复杂的响应式UI组件(如工具提示、悬停卡片)。 Baseline功能状态整合至开发工具VS Code现已集成Baseline状态显示,未来还将支持WebStorm等IDE。通过RUMvision结合真实用户数据评估功能兼容性。 Chrome DevTools集成Gemini AI调试助手调试工作流新增“Ask AI”能力,在Elements面板中可直接应用模型建议。性能面板提供上下文分析,助力优化Web性能指标。 内置AI API全面上线自Chrome 138起,Summarizer、Language…
《AI工程技术栈》:三层结构解析,AI工程如何区别于ML工程与全栈工程
《AI工程技术栈》:三层结构解析,AI工程如何区别于ML工程与全栈工程 由Gergely Orosz与Chip Huyen联合发布2025年5月20日 在2025年6月16日周一,于伦敦举办的LDX3大会将迎来《务实工程师(The Pragmatic Engineer)》播客的现场录制环节。该环节是当日大会的闭幕环节,嘉宾为Shopify工程负责人Farhan Thawar。两人将围绕以下议题展开讨论: 当天Gergely本人还将发表大会主旨演讲,听众将有机会现场见到《务实工程师》团队成员,包括Elin与Dominic。如果无法亲临现场,录制内容也将在事后通过播客发布。 接下来进入正题——AI工程技术栈的核心内容。 AI工程的崛起与背景 “AI工程”一词在两年前还鲜有人知,但如今,AI工程师成为科技行业的紧缺人才。不少企业如Meta、Google、Amazon等给予AI工程岗位比普通软件工程师更高的薪酬待遇,AI初创公司与规模型企业也在大力争抢相关人才。 但进一步观察可以发现,很多AI工程师其实是熟练掌握大型语言模型(LLM)基础操作并能实现集成的资深软件工程师。 在这一领域,目前最具代表性的著作之一是Chip Huyen于2025年初由O’Reilly出版社出版的《AI Engineering》。作者曾在Netflix担任研究员,在NVIDIA核心开发NeMo生成式AI框架,并共同创办Claypot AI,同时还曾于斯坦福大学教授机器学习课程。 本文引用该书第一章节选,旨在深入介绍AI工程栈的结构,解析AI工程如何从机器学习(ML)工程发展而来,又如何区别于全栈开发。 AI工程三层技术栈概览 AI应用的技术栈可拆解为三层:应用开发层、模型开发层与基础设施层。开发AI应用通常从顶层的应用开发开始,逐层深入至模型与基础设施: 研究者在GitHub上检索了星标数量超过500的AI相关开源仓库,发现自Stable Diffusion与ChatGPT问世后,AI工具类仓库数量大幅上升,尤其以应用开发层最为显著,而基础设施层相对稳定。这表明尽管模型与应用迅速演进,资源调度与服务管理的底层基础设施变化较小。 尽管AI模型能力突飞猛进,但企业级应用依旧需要通过商业指标与机器学习指标的映射,并进行系统性实验与持续反馈优化。这些依旧沿袭传统ML工程的核心逻辑。 AI工程 vs. ML工程:核心差异 尽管AI工程继承了大量ML工程的基础方法,其核心区别包括: 因此,AI工程重点在于适配与评估模型。适配方式分为两类: 模型开发层详解 该层工作传统上归属ML工程,包含: 此外,作者还对预训练(pre-training)、**微调(fine-tuning)与后训练(post-training)**之间的区别做了详尽说明。 应用开发层详解 随着大模型普及,众多团队使用相同模型,差异化更多体现在应用开发层: AI工程 vs. 全栈开发 随着接口设计比重提升,AI工程越来越接近于全栈开发。传统ML工程以Python为核心语言,但如今也出现了JavaScript生态支持,如LangChain.js、OpenAI Node库、Vercel AI SDK等。 全栈开发者凭借前端与产品构建能力,在当前AI模型随取即用的环境中,可以先建产品、后训练模型,快速实现想法、获取反馈并快速迭代。 如图所示(图1-16),全新的AI工程流程更重视产品与用户,而非一开始即深耕建模。 总结 本章节旨在阐明AI工程作为一门独立学科的兴起背景及其核心开发流程。AI工程虽然源自ML工程,但又有所区别。其突出特征是建立在基础模型上的开发流程创新,以及如何以最快速度将AI能力转化为具备实用价值的产品。 AI工程不仅是技术的革新,更是社区创造力的集中体现。虽然知识更新速度惊人,但也正因如此,更需要系统框架来帮助从业者理解与应对变化。 本书将以本章为起点,逐步展开对整个AI工程流程的深入讲解,从支持这一切的基础模型出发,帮助读者全面掌握AI时代的核心工程能力。
Nvidia – NVLink Fusion
在本周于台北举办的 Computex 大会上,Nvidia 宣布将其高速互联技术 NVLink 的应用范围扩大,引入名为 NVLink Fusion 的新版本,以支持更广泛的计算生态系统。这一变化标志着 Nvidia 正在尝试将其长期封闭的加速器互联标准向部分第三方芯片设计商开放。 NVLink 简介与演进 NVLink 是 Nvidia 自研的一种高带宽互联技术,用于将多个 GPU 在一个系统或服务器机架中连接起来,使其能像单一加速器一样共享计算与内存资源。目前第五代 NVLink 支持每块 GPU 高达 1.8 TB/s 的带宽(双向各 900 GB/s),可在一个机架中连接多达 72 块 GPU。 然而,直到此次发布之前,NVLink 仅限用于 Nvidia 自家的 GPU 和 CPU,其他厂商的芯片无法接入该互联网络。 NVLink Fusion 带来的突破 NVLink Fusion 的推出意味着 Nvidia 将允许部分 非 Nvidia 设计的加速器(包括半定制 CPU 和 ASIC) 接入该高性能互联网络。根据 Nvidia 高性能计算、云与…
GitHub 正式推出其 Copilot 新版编码代理工具
GitHub 正式推出其 Copilot 新版编码代理工具,为开发者提供一种更加自动化、集成度更高的开发体验。这一代理功能直接嵌入 GitHub 平台,通过 GitHub Actions 启动一个安全、可定制的开发环境,一旦开发者将某个 Issue 分配给 Copilot 或通过 VS Code 发出指令,代理即开始在后台运行,并将其工作成果以拉取请求(Pull Request)的形式提交。 使用方式与功能特点 开发者只需在 GitHub 网站、GitHub Mobile 应用或使用 GitHub CLI 工具中,将问题指派给 Copilot,操作方式与指派给团队成员类似。也可以通过 GitHub Chat 或 VS Code 内的指令形式发出请求,例如: @github Open a pull request to refactor this query generator into its own class 收到任务后,Copilot 代理会自动添加 👀 表情以示接收,并在后台启动一台虚拟机,克隆代码仓库、配置开发环境,并使用 GitHub Code Search 支持的先进检索增强生成(RAG)技术分析代码库。整个过程中,代理会将修改内容不断推送至草稿拉取请求,并同步更新其描述信息。开发者可通过代理的日志追踪工作流程、验证步骤与逻辑推理,从而清晰了解每项决策的来龙去脉。…
Jules 从私有预览阶段推向全球公测
谷歌近日悄然将其实验性质的编码代理工具 Jules 从私有预览阶段推向全球公测,允许任何拥有 Google 账号的开发者使用该人工智能工具代表他们提交拉取请求(pull requests)。这款工具最早于 2024 年 12 月与 Gemini 2.0 一同首次亮相,目前已升级至 Gemini 2.5 Pro 版本,并提供每天五个免费任务的起始配额,成为谷歌迄今为止对 GitHub Copilot 新版“编码代理”以及 OpenAI Codex 的最直接挑战。 Jules 的功能定位 与传统自动补全工具不同,Jules 启动时会在云端创建一个临时虚拟机(Cloud VM),克隆目标代码库,在修改任何文件前制定一个多步骤的操作计划。该代理能够进行依赖项升级、代码重构、文档撰写、测试编写,甚至解决现有的开放问题。所有更改都会以标准的 GitHub 拉取请求形式呈现,供人工审阅。 技术底层 谷歌表示,Jules 能“理解代码库”的原因在于其搭载了最新的多模态 Gemini 模型,具备对大型文件结构和项目历史进行推理的能力,并能遵循特定代码库的贡献指南。这种深度理解能力让该工具在执行任务时更加精准。 全球公测与定价策略 此次公测取消了等待名单,任何用户只需通过 GitHub 账号在 jules.google 认证后,即可使用即将推出的“assign-to-jules”标签从问题页直接分配任务。谷歌为了促进早期采用,还提供每天五个免费任务的额度。更多使用额度和企业级控制功能预计将在“今年晚些时候”推出。 与 Copilot 和 Codex 的对比 微软也在今日的 Build 大会上公开了 GitHub Copilot 背后的编码代理功能,重点展示了类似的漏洞修复和功能实现流程。而 Jules 则将整个工作流程——计划制定、差异生成、拉取请求创建——整合为一个单一工具,可能会减少对谷歌云平台上开发团队的集成代码需求。 上线信息与交流活动…
苹果的人工智能领域慢热
在苹果公司内部,关于何时能够真正推出新功能的市场宣传策略问题上,越来越多的声音呼吁应更为坦率。软件方面的最终决策由克雷格·费德里吉(Craig Federighi)做出,而苹果整体产品开发文化的塑造者,则是首席执行官蒂姆·库克(Tim Cook)。 2024年12月,库克在阿布扎比现身,佩戴墨镜、面露阴影。这位掌舵者曾依靠苹果强大的市场主导力和雄厚现金储备,重塑了从半导体到智能手机玻璃等全球供应链。然而,曾任首席财务官的卢卡·梅斯特里(Luca Maestri)在购买人工智能关键组件GPU方面的保守态度,如今看来并不明智。当全球对GPU的需求超过供应时,苹果却依旧保持其一贯在对新兴技术尚未完全认同前缓慢采购的节奏,最终导致在AI浪潮中落后。亚马逊和微软等竞争对手抢先购入大量GPU资源,使苹果的AI模型训练速度大幅放缓。有AI团队成员坦言:“当竞争者已经将所有GPU抢走时,是不可能凭空变出更多GPU的。” 苹果一直以来对用户隐私的高度重视也对AI发展形成牵制。尽管苹果目前活跃设备数高达23.5亿台,理论上能够接触到大量关于网页搜索、个人兴趣和通信的用户数据,但其对AI研究人员获取这些数据的限制远比谷歌、Meta和OpenAI严格。这种隐私承诺甚至涵盖非用户的数据。例如,苹果用于Siri、Spotlight等搜索功能的数据抓取工具Applebot,允许网站轻松选择不被采集内容用于提升AI能力,许多网站也确实选择了退出。 这使得苹果研究人员更加依赖第三方授权数据集以及“合成数据”——即为AI训练特别制造的人工数据。据一位熟悉苹果AI及软件开发的内部人士称,在隐私相关事务上,“每一步都要先经历无数次否定,还得与‘隐私警察’作斗争。”一位持类似观点的高管表示:“看看X平台的Grok助手,他们会持续进步,因为拥有全部X的数据。苹果要拿什么来训练模型?” 这进一步显示出AI并非苹果所擅长的技术领域。一位长期高管坦言:“过去的策略一直是——我们起步晚,但有十亿用户,会一路坚持并最终胜出。但这一次,这种策略行不通。” 在试图重振AI计划的过程中,苹果也面临外部独特挑战。据知情人士透露,为应对即将到来的欧盟监管,苹果正在调整操作系统,首次允许用户将Siri更换为第三方语音助手。若苹果产品未能在AI方面实现突破,许多用户可能会选择更换默认助手。除OpenAI、Anthropic、Meta和Alphabet的产品外,一些新兴初创公司如DeepSeek也在不断推出创新解决方案。 苹果位于苏黎世的AI办公室正致力于开发新型软件架构,以取代当前存在问题的Siri混合模式。这项被称为“LLM Siri”的秘密项目旨在打造完全基于大语言模型引擎的“单体模型”,从而使Siri更自然对话、信息整合能力更强。与此同时,苹果在德州、西班牙和爱尔兰等地的上千名分析师正比对Apple Intelligence生成的摘要与原始资料,以评估AI出现“幻觉”(即内容失真)的频率。最近的一次软件更新还使iPhone用户设备参与合成数据优化,通过与邮件内容对比,提升合成数据质量,而无需将用户真实数据输入训练模型中。 2025年春,苹果CEO库克已将产品开发的权力从AI主管约翰·贾南德里亚(John Giannandrea)手中剥夺,包括Siri工程项目及未来机器人设备开发。据多位高管透露,这一调整源于库克对其领导新产品研发能力的失望。Siri目前由Vision Pro混合现实头显项目主导者迈克·洛克韦尔(Mike Rockwell)接管,其向费德里吉汇报工作,后者在AI软件产品路线图上的责任也进一步加重。贾南德里亚的产品管理团队已归费德里吉管理,而洛克韦尔则用来自头显项目的核心团队重组Siri管理层。曾在贾南德里亚手下主管Siri的达伦·沃克(Darren Walker)被调离大部分工程师,负责新的项目。 贾南德里亚目前仍负责AI研究、大语言模型的开发与优化、AI分析师团队及部分基础设施部门。据内部人士称,部分高管曾讨论进一步削减其职责,甚至考虑将其推向退休道路(其年纪为60岁),但费德里吉等人担忧若他离开,他带入的核心研究员与工程师也会随之出走。至少目前,他表示仍希望继续留任,直到AI项目步入正轨。他私下向同事坦承,对于不再主管Siri,感到如释重负。 接替他的人选洛克韦尔,起初对向曾持AI怀疑态度的费德里吉汇报工作感到犹豫。但这也是他实现长期以来对Siri改革设想的机会。早在2015年加入苹果时,洛克韦尔便主张将Siri打造为全天候的生活助手,在用户体验中占据核心地位。一位熟悉洛克韦尔的员工表示:“他过去经常激动地讲Siri的重要性,认为那会成为人们使用手机的主要方式。”当时,他推动公司投资高端录音棚和聘请专业演员升级Siri语音,但在推动Siri成为Vision Pro导航核心时却未能得到Siri团队配合。如今他掌控更多资源,有望推进打造类似ChatGPT语音模式的助理体验。目前,他正在重组团队,重点提升语音助手的反应速度与理解能力。 与此同时,苹果也意识到用户习惯正在发生变化。谷歌搜索在苹果设备上的使用量上月首次出现下降。高级副总裁艾迪·库(Eddy Cue)在法庭作证时指出:“这是22年来首次出现此类情况”,并归因于AI的影响。因此,苹果正考虑与OpenAI、Anthropic等公司达成合作,用其作为Safari浏览器的搜索替代方案,反映出用户越来越倾向于使用基于大语言模型的助手寻找信息。据知情人士透露,去年贾南德里亚曾提出将Google Gemini整合进Siri,目前计划在iOS 19中推出,作为ChatGPT的替代方案。苹果还在初步洽谈,将初创公司Perplexity引入Siri及Safari中,作为AI搜索引擎提供商。 关于苹果自研聊天机器人的努力,有高管推动将Siri转型为真正的ChatGPT竞争者。公司已开始探讨赋予助手读取和整合开放网络信息的能力。员工透露,公司内部测试的聊天机器人在过去六个月取得明显进展,部分高管认为其表现已与最新版本的ChatGPT相当。若该聊天机器人整合至Siri,将有助于苹果缓解谷歌每年支付的200亿美元默认搜索引擎协议失效可能带来的财务风险。目前该协议正受到美国反垄断监管的挑战。苹果还寄望于另一项延期AI功能:让Siri能与iPhone应用深度整合,通过语音控制设备,从而维持App Store每年200亿美元的营收不受聊天机器人替代应用的冲击。 据苹果内部消息透露,公司计划在2025年6月WWDC大会上推出的下一版iOS中,主要聚焦于现有Apple Intelligence功能的升级,并新增如AI优化的电池管理模式与虚拟健康教练等功能。尽管一年前曾承诺的Siri重大升级仍未准备就绪,预计不会在此次大会上详细介绍。另据知情人士称,公司计划将Apple Intelligence品牌在营销中与Siri逐步区分,以应对Siri口碑不佳对AI推广造成的负面影响。苹果还将调整发布策略,今后大多数功能将在距离实际发布不远的时间内才对外公布。 而Siri的联合创始人、现仍在苹果供职的达格·基特劳斯(Dag Kittlaus)仍对AI版Siri持乐观态度。他指出:“所有大模型公司其实都不知道什么是‘助理’,而苹果从2010年起就在开发这个概念。”他认为,只要苹果能对Siri进行一次“大脑移植”,结合其按钮和品牌优势,依然有机会成为用户首选的智能助手。
Meta近期在人工智能领域的野心不断扩展,从分子研究到虚拟化身均有涉足,但其前行之路也伴随着技术挑战与法律风险。
Meta近期在人工智能领域的野心不断扩展,从分子研究到虚拟化身均有涉足,但其前行之路也伴随着技术挑战与法律风险。 据知情人士透露,Meta已推迟原定于2025年春季发布的新一代Llama模型“Behemoth”。该模型原计划于4月推出,后延期至6月,而如今则再次推迟至秋季。此次延迟的主要原因在于内部工程师对模型训练结果表示失望。尽管Meta方面宣称“Behemoth”在多个基准测试中优于OpenAI与谷歌的同类产品,但公司内部对于其是否真正较Llama 2带来实质性改进存在持续争议。一些内部人员指出,在实际应用环境中,“Behemoth”的性能提升并不显著。 此项延期也引发了外界对Meta 2025年高达650亿美元的预计资本支出(CapEx)的进一步关注。更严重的是,在14位最初开发Llama模型的研究人员中,已有11人离职,这对Meta的技术公信力造成了不小的打击。 尽管在大语言模型领域遇挫,Meta在科学AI方面则动作频频。公司近日正式发布了“Open Molecules 2025”(OMol25)https://huggingface.co/facebook/OMol25 ,这是一个规模庞大的开放数据集,涵盖超过一亿条量子化学计算结果。据介绍,生成这一数据集共耗费60多亿计算小时,内容涵盖生物分子、有机物、金属配合物,并包含电子自旋、电荷状态、构象等丰富信息,旨在支持AI驱动的药物开发与材料科学研究。 与此同时,Meta还发布了UMA模型(Universal Molecular Architecture),这是一款基于图神经网络(GNN)的预测模型,采用线性专家混合架构(Mixture of Linear Experts)。据称,UMA在分子属性预测方面兼具高速度与高准确率,并在多个专业领域的基准测试中超越了现有专用模型。 此外,Meta还推出了一项名为“Adjoint Sampling”的新型生成方法。该方法以扩散建模为核心,可在样本数量极少的情况下探索分子构象空间,为分子模拟与结构生成提供了新的路径。 Meta官方账号“AI at Meta”于5月14日通过社交媒体宣布了这些发布内容,并强调其在分子属性预测、语言处理和神经科学等领域具有变革意义。值得一提的是,所有相关工具与模型均已通过Hugging Face与GitHub向研究社区开源。 尽管Meta目前在大型语言模型方面面临不小压力,其在科学研究领域的布局则显示出公司试图在AI应用中找到更多差异化与长期价值。这种策略能否成功扭转技术口碑并增强投资者信心,仍有待时间验证。
OpenAI于2025年5月16日(星期五)宣布推出其迄今为止最强大的AI编码代理——Codex的研究预览版
该工具由codex-1模型驱动,这是基于OpenAI最新的o3人工智能推理模型,专为软件工程任务优化。根据OpenAI的说法,codex-1生成的代码比o3更加简洁清晰,遵循指令的准确性更高,并能够通过迭代方式不断测试代码直至通过所有测试。 Codex运行于一个隔离的云端虚拟计算机中。通过与GitHub连接,Codex的工作环境可预先加载用户的代码仓库。OpenAI表示,该AI编码代理可以在1到30分钟内完成编写简单功能、修复bug、回答有关代码库的问题以及运行测试等多项任务。 据OpenAI介绍,Codex具备同时处理多个软件工程任务的能力。在运行期间,用户仍可继续使用本地计算机和浏览器,Codex不会进行干预或限制。 Codex自当天起向ChatGPT Pro、企业版和团队版用户陆续开放。OpenAI表示,初期用户将享有“慷慨的使用额度”,但在未来数周内,该公司将对Codex设定速率限制,用户随后可选择购买额外额度以继续使用此工具。据OpenAI一位发言人透露,该公司还计划在不久后将Codex的使用权限扩展至ChatGPT Plus和Edu用户。 软件工程专用的AI工具——通常被称为“vibe coders”——近年来人气飙升。谷歌与微软的CEO曾表示,各自公司中大约有30%的代码已由AI生成。今年2月,Anthropic推出了名为Claude Code的代理式编码工具;而在4月,谷歌则升级了其AI助手Gemini Code Assist,增强了其代理能力。 随着AI编码市场热度持续上升,相关企业亦迅速成长。知名AI编码工具Cursor在2025年4月的年化营收已达到约3亿美元,目前正以90亿美元估值筹集新一轮资金。 OpenAI显然也希望在这一市场分得一杯羹。根据消息,该公司已达成协议,以30亿美元收购另一家热门AI编码平台Windsurf的开发商。同时,Codex的推出也标志着OpenAI正在全力构建其自身的AI编程工具矩阵。 获得Codex访问权限的用户可在ChatGPT的侧边栏中找到该工具,并通过输入提示词并点击“Code”按钮分配编码任务,亦可提出代码相关问题并点击“Ask”按钮进行咨询。提示栏下方将显示已指派的任务及其执行进度,便于用户跟踪管理。 在Codex发布前的一次简报会上,OpenAI代理研究部门负责人Josh Tobin向媒体表示,该公司最终希望AI编码代理能够成为“虚拟团队成员”,自主完成那些需人工工程师花费数小时乃至数天的任务。据透露,OpenAI已在内部使用Codex来处理重复性任务、搭建新功能框架以及起草文档。 OpenAI产品负责人Alexander Embiricos表示,公司为o3模型所做的大量安全性工作同样适用于Codex。根据OpenAI官方博客的介绍,Codex将坚决拒绝开发“恶意软件”的请求。此外,该工具在“空气隔离”环境中运行,无法访问互联网或外部API,从而在降低其潜在危险性的同时,也限制了其部分功能的广泛性。 需要注意的是,与其他生成式AI系统一样,AI编码代理目前仍容易出错。微软近期一项研究发现,即使是行业领先的模型,如Claude 3.7 Sonnet和o3-mini,在调试代码方面也表现不够稳定。然而,这种问题并未削弱投资者对该类工具的热情。 OpenAI还对其近期推出的开源终端工具Codex CLI进行了升级,默认集成了专为软件工程优化的o4-mini模型。该模型现已成为Codex CLI的默认模型,并通过OpenAI的API对外开放,定价为每100万个输入tokens收取1.5美元、每100万个输出tokens收取6美元(相当于大约75万字,超过整部《魔戒》三部曲的总字数)。 Codex的发布进一步表明,OpenAI正积极将ChatGPT拓展为一个包含多项产品的综合性平台,而不仅仅是一个聊天机器人。在过去一年中,该公司已陆续为订阅用户开放了AI视频平台Sora、研究助手Deep Research以及网页浏览代理Operator等优先使用权。 这一系列新产品的推出可能促使更多用户订阅ChatGPT服务,尤其是在Codex方面,也有望通过设定额度限制并提供额外购买选项,推动用户增加在OpenAI平台上的支出。
在浏览器中,二进制格式比JSON更优秀
一位开发者在其近期的性能基准测试回顾中指出,早前在对比 JSON.parse 与 binaryEncoding.parse 的过程中存在关键错误。他原本直接对比从字符串中解析JSON数据与从缓冲区中解析二进制数据的性能,然而这种对比方式忽略了多个影响因素,因此无法反映真实差距。 首先,缓冲区解码为字符串本身就非常昂贵。相比之下,JSON在此流程中直接跳过了该步骤,但事实上,无论如何,浏览器在接收字节数据时必须在某个阶段完成解码。 其次,JSON格式的消息比二进制格式要大得多。这意味着浏览器中涉及该消息的其他处理流程(例如网络传输代码)也将耗费更多资源,尤其是内存拷贝等操作。仅仅比较反序列化时间,并不能全面反映JSON带来的性能成本。 作者通过图表展示了在不同编码方案下的未压缩消息体积以及从服务器读取消息体的耗时情况,指出JSON在解码开始前就已处于巨大劣势。其原因不仅在于消息体本身更大,还在于需要先将其解码为字符串,之后才能反序列化。 为纠正这一偏差,作者采用了端到端的延迟衡量方式:从发送请求到客户端处理完成的整个过程,并从中扣除纯服务器端耗时,以提取出客户端的真实耗时数据。 关于压缩 虽然压缩确实在网络传输上基本消除了各类编码方案之间的大小差异,但浏览器在接收到压缩数据后仍需解压并处理完整字节流。因此,作者强调其测量方式可以更全面地捕捉这一额外的开销。 Schema与Schema-less编码 部分编码格式如Protobuf具备Schema机制,能在反序列化阶段自动进行数据验证。而JSON等无Schema格式则需手动实现这一功能。虽然在测试中,是否具备Schema对性能影响不大,但这类编码格式能“免费”提供更高的数据安全性,依旧值得强调。 惰性解码与类型支持差异 作者指出,Flatbuffers与Cap’n Proto等库采用了惰性解码策略,只有在真正访问属性时才会进行解码。与其将Flatbuffers的“deserialize”方法直接对比JSON.parse并不公平,因为后者会立即分配并构建实际的值。 另外,不同编码方案对数据类型的支持差异也影响了测试结果。例如,Bebop原生支持Date类型,而JSON则需先转为字符串或数字再手动还原。在本次测试中,作者特别设计了统一的输出对象——“Plain Old JavaScript Object”,其中强制将日期类型和惰性字段完全物化,以确保各编码方案在同等条件下对比。 浏览器端性能改进趋势 虽然支持快速二进制编码的浏览器API早在2020年前就已存在,但直到最近两年才得到更广泛应用。多个编码库也在此期间获得了重大性能提升: Bebop Bebop于2020年推出,与Protobuf类似,具备良好工具支持与性能表现,且原生支持Date类型,专为浏览器高性能场景而设计。然而,其社区影响力较小,官方网站目前已跳转至“text-os.com”,令人对其未来发展感到担忧。 Avro(通过avsc库) 截至2025年4月,avsc库在浏览器端仍使用性能极差的Buffer polyfill,导致反序列化极慢。但作者指出,其主分支最新版本已改用原生Uint8Array,显著提升了性能,使其成为本次测试中最具性能优势的选项之一。 Protobuf(protobuf.js) 默认配置下,protobuf.js在反序列化方面表现不佳,问题在于其字符串解码算法效率不高。作者对其源码进行了修改并提交了pull request。同时他也测试了其他Protobuf实现,如protobuf-es(性能差)与pbf(性能佳但缺乏灵活性)。 其他库测试 JSON的非性能问题 作者指出,即便不谈性能,JSON本身也存在诸多缺陷: 他分享了一段亲身经历:某次项目中,为避免BigInt精度问题,团队以字符串保存数字,他错误地将数字500与字符串”500″相加,最终导致广告系统向客户请求了第500,500条广告,而非预期的第1000条,造成了实际损失。 作者补充道,如今多数开发者已使用TypeScript以避免此类问题,但JSON并未提供任何结构性保护,反而加大了错误风险。开发者仍需借助zod等额外库实现验证。 服务端性能表现 在Rust服务器上的测试表明,JSON的序列化速度也落后于其他格式。 总结与未来计划 综上,作者认为Bebop、Avro和Protobuf在将服务器端消息发送至浏览器的场景下,都能在性能上优于JSON。目前Avro仍待新版本正式发布,而Protobuf也有待其PR被接受。