2026年7月24日 · 来源 aihot.virxact.com · 时间窗:过去 48 小时(24h 内 coding/agent 条目不足,放宽至 48h 补齐)
01

ChatGPT 桌面版上线 GPT-Live 语音模式:口述需求,同时调度 Chat/Work/Codex 三板块多智能体

IT之家 / X:OpenAI (@OpenAI) / Testing Catalog · 7月24日

OpenAI 升级 ChatGPT 桌面应用(已与 Codex 合体),引入全双工语音模型 GPT-Live 驱动的 ChatGPT Voice 模式。用户可在聊天、办公和编程三个板块中通过语音发起、检查或调整任务。GPT-Live 可同时聆听与说话,支持从单一对话中启动多个工作流——智能体在后台执行任务时,用户可以继续说话推进其他事情。

官方示例:规划商务旅行时,用户口述需求后 ChatGPT 自行检查日历冲突、梳理收件箱中的航班变更、准备会议记录。即日起面向 macOS 和 Windows 付费用户推送,部分用户更新客户端后尚未看到入口。

为什么值得关注
这不是"语音聊天"——是语音控制的多智能体编排。GPT-Live 全双工意味着你说话的同时 AI 在听也在执行,不用等你说完再响应。三板块(Chat/Work/Codex)并行意味着你可以一边让 Codex 写代码、一边让 Work 查邮件、一边继续用语音讨论下一步。对 coding agent 场景,语音交互的价值在于:开发者双手在键盘上写代码时,可以用语音并行指挥 agent 做其他事——查文档、跑测试、整理 PR 描述——不需要切窗口打字。但全双工语音的 token 消耗远高于文本,烧 token 速度是实打实的。
https://www.ithome.com/0/980/975.htm https://x.com/OpenAI/status/2080378182469857576
02

Claude 语音模式升级:支持 Opus/Sonnet/Haiku 三档模型切换,可连接 Gmail/Slack/Notion 执行操作

Claude:Blog / X:Testing Catalog · 7月23日

Anthropic 升级 Claude 语音模式,从仅支持 Haiku 扩展到 Opus、Sonnet、Haiku 三档模型,可在对话中切换且不丢失上下文。语音模式默认使用上次文本对话的模型,文本与语音无缝衔接。新增连接 Gmail、Google Calendar、Slack、Canva、Notion 等工具,用户可通过语音让 Claude 执行操作——如"把日历上的会议推迟 30 分钟"或"把刚才讨论的方案做成 Canva 一页纸"。

语言从英语扩展到 11 种(含日语、韩语、法语、德语、西班牙语等),可在对话中口述切换。Free 计划可用 Haiku + 1 个工具;付费计划解锁全部模型和所有已连接工具。Beta 阶段,移动端体验最佳。

为什么值得关注
和 ChatGPT 的 GPT-Live 同日竞争,但路线不同。OpenAI 强调全双工和三板块并行调度,Claude 强调模型分档切换和工具连接——你可以在讨论复杂问题时切到 Opus 深度推理,简单操作时切回 Haiku 省额度。关键差异:Claude 的语音模式可以调 Connectors 执行真实操作(推日历、发邮件、建文档),不只是对话。对用 Claude 做开发的团队,这意味着你可以在写代码时用语音让 Claude 同时处理非编码任务(如整理会议纪要、发 Slack 消息),把 Claude 从"编码工具"扩展到"全工作流助手"。但注意:Claude 不会自动检测语言,需要手动切换。
https://claude.com/blog/think-through-hard-problems-in-voice-mode https://x.com/testingcatalog/status/2080385285951521150
03

吴恩达发布 OpenWorker:MIT 开源桌面 AI 智能体,交付成品而非对话,内置四层权限引擎

MarkTechPost / X:Andrew Ng (@AndrewYNg) · 7月23日

Andrew Ng 发布 OpenWorker——MIT 许可的开源桌面 AI 智能体,核心理念是"交付成品而非对话"。用户描述一个结果(如"发一封包含实际数据的 Slack 回复"或"更新日历"),OpenWorker 自行拆解步骤、跨本地文件和已连接应用执行,在执行有副作用的操作前会请求授权。

架构四层:Tauri 2 + React 18 桌面壳、Python FastAPI 本地 agent 服务器(默认 127.0.0.1:8765)、能力与连接器层(文件/git/ripgrep/shell/MCP)、模型路由器(基于 aisuite)。代码量约 119 个 Python 文件(~32,400 行)+ 149 个 TS/TSX 文件。支持 30 个精选模型(GPT-5.6 Sol、Claude Fable 5、Gemini 3.6 Flash、DeepSeek V4、Kimi K2.6 等)+ Ollama 本地模型。

权限引擎是工程核心:每次工具调用分为 read / write_local / exec / external 四个风险等级,对应 discuss / plan / interactive / auto / custom 五种权限模式。Shell 命令永远需要确认。内置 prompt injection 防御——所有来自工具、日志、文件的内容被视为不可信数据而非指令。

为什么值得关注
OpenWorker 做了一件大多数桌面 agent 项目跳过的事:把权限管理当类型系统来设计。四风险等级 + 五权限模式不是 UI 层面的弹窗确认,而是写在 agent 架构里的约束层——shell 命令永远要人确认,external 操作永远走 Inbox 审批。对做 agent 架构的团队,这套权限模型可以直接参考。30 个精选模型 + aisuite 路由器意味着不绑死任何供应商,Ollama 支持意味着完全离线可用。MIT 许可 + 全部本地运行的隐私模型(密钥不进入模型上下文)对合规要求高的团队是硬需求。对比 Claude Cowork 的录屏转 Skill(门槛低但能力受限于录屏质量),OpenWorker 的代码级架构更适合有工程能力的团队做二次开发。
https://www.marktechpost.com/2026/07/23/andrew-ng-just-released-openworker... https://x.com/shao__meng/status/2080476918395330668
04

北京发布智能体新政:Harness Engineering、Token 经济、OPC 首次写入政府政策文件

微信公众号 · 7月23日

北京市发布智能体产业新政,首次将 Harness Engineering(智能体工程)、Token 经济和 OPC(开放智能体协议)等概念写入政策文件。这意味着智能体工程化从行业实践上升为政府认可的技术方向,后续可能在产业扶持、标准制定和项目申报中获得政策对接。

为什么值得关注
Harness Engineering 被写入政策本身就是信号——政府开始认可"模型之外的工程层"是独立的技术赛道。对在国内做 agent 基础设施或 coding agent 平台的团队,这可能直接影响后续的政策红利走向:如果智能体工程被纳入高新技术认定或专项扶持范围,相关企业的研发投入可能获得税收减免或补贴。Token 经济写入政策也值得关注——如果政府开始从经济模型角度理解 token 消耗,未来可能出台 token 效率相关的行业标准或披露要求。但政策文件到实际落地通常有滞后,短期看信号意义大于实操影响。
https://mp.weixin.qq.com/s/CYB7v1e5D4m-btgosjmLgA
05

Offloop 4 人团队多智能体超越 Claude Code 和 Codex:GDPval 84.9 分,单任务成本仅 1.65 美元

X:Rohan Paul (@rohanpaul_ai) / Offloop (@Offloop) · 7月23日

Offloop 的 4 人团队用多智能体 harness 在 GDPval 基准上取得 84.9 分,单任务成本 1.65 美元。对比:Claude Code(Opus 4.8)82.4 分,单任务 14.38 美元;Codex(GPT-5.6 Sol)83.3 分,单任务 5.20 美元。Offloop 的成本是 Claude Code 的 1/9、Codex 的 1/3。另在 GDP.pdf 得 44 分、JobBench 得 67.2 分,均领先于 Codex 和 Claude Code。

GDPval 衡量 AI 在 44 个职业、9 大行业中处理真实工作的能力,模型获得 shell 和浏览器访问权限后与人类专家进行盲评两两对比,对应美国约 2.4 万亿美元年薪资的知识工作岗位。

为什么值得关注
这个结果直接验证了一个判断:harness 正在成为真正的能力层。同一个模型(甚至更弱的模型),换个 harness 就能超越 Claude Code 和 Codex——差距不在模型权重,在编排架构。84.9 vs 82.4 的分数差距不算大,但 1.65 美元 vs 14.38 美元的成本差距是 9 倍。4 人团队的产出打平甚至超过 Anthropic 和 OpenAI 的旗舰 agent 产品,说明 agent 编排的工程门槛没有想象中那么高。对做 coding agent 的团队,Offloop 的结果意味着:如果你目前用 Claude Code 或 Codex 的成本太高,自己搭多智能体 harness 可能是更划算的路径——前提是你有能力做 agent 编排工程。GDPval 对标 2.4 万亿美元的知识工作市场,也说明 agent 的价值天花板远不止写代码。
https://x.com/rohanpaul_ai/status/2080347058939277821 https://x.com/Offloop/status/2080304786646433874
06

DeepSeek 投资人电话会泄露:2 万张卡做出 GPT 同级模型,推理毛利率 85%,硬件 10 个月回本

X:AYi (@AYi_AInotes) · 7月24日

DeepSeek 一段 4 小时投资人闭门会议录音泄露。截至今年 5 月,DeepSeek 仅用 2 万张 Hopper 等效 GPU 便做出与 GPT、Claude 同级的一线模型。推理毛利率约 85%(约 6 倍利润),硬件 10 个月回本。10 亿美元 API 营收即可现金流为正,覆盖研发和训练,实现自我造血迭代。

DeepSeek 已锁定 1.6 万张华为 950 卡,正在将基于 TileLang 的编译器和算子移植到华为生态。梁文锋在会中判断"CUDA 的护城河正在快速瓦解"——AI 自己会写算子,高层语言很快填平生态差距,最多一年国产卡的软件瓶颈基本消除。团队一半核心人员在做数据标注,不设 KPI,不鼓励加班。

为什么值得关注
这些数字把大模型行业的成本结构摊开了。2 万张卡 vs 行业普遍的 10 万张以上——DeepSeek 的效率不是"性价比",是结构性的成本优势。85% 推理毛利率意味着每收 1 美元 API 费用,毛利 85 美分;对比 OpenAI 据报约 55-75% 的毛利率,差距明显。10 个月硬件回本周期意味着 DeepSeek 的资本效率远高于烧钱扩卡的同行。对用 DeepSeek API 的开发者,85% 毛利意味着降价空间很大——如果竞争加剧,DeepSeek 有底气继续打价格战。华为 950 卡 + TileLang 编译器的组合如果跑通,意味着非 NVIDIA 硬件的软件生态瓶颈可能在一年内被突破——这对做硬件选型的团队是重要信号。但注意:这些数字来自泄露的投资人会议,未经审计,实际数据可能有所不同。
https://x.com/AYi_AInotes/status/2080462053903405388
07

Harness Handbook:用静态分析构建行为→源码映射,智能体规划成功率提升 10-19 个百分点

X:elvis (@omarsar0) / arXiv · 7月23日

论文提出 Harness Handbook——通过静态分析和 LLM 辅助结构化,构建从运行时行为到源码位置的三级映射(系统概览→相关阶段/函数→具体文件)。其 BGPD 工作流引导 coding agent 从系统概览出发,逐步定位到相关阶段、函数和文件,并在每一步用当前源码验证候选位置。

在 60 个修改请求上测试 Codex 和 Terminus-2 两个 agent:Codex 规划成功率从 28.3% 升至 38.3%,Terminus-2 从 26.7% 升至 45.6%。规划器 token 消耗分别下降 12.7% 和 8.6%。文件级和符号级 F1 在全部 24 项对比中均优于 GPT-5.5 和 Opus 4.8 的参考规划。完全定位失败率最多降低 25.9 个百分点。

为什么值得关注
这篇论文直接攻击了 agent harness 维护中最痛的点:改一个行为时,找到该改哪个文件比写改动本身更难。三级映射(行为→阶段→文件)的本质是把"agent 在代码库里盲目搜索"变成"agent 拿着地图定位"。数据说话:规划成功率提升 10-19 个百分点,同时 token 消耗还降了——说明 agent 不再需要在大量文件中试错。完全定位失败率降低 25.9 个百分点意味着之前有超过四分之一的修改请求 agent 根本找不到该改哪里。对维护大型 agent harness 的团队,这套方法可以直接复用——静态分析 + LLM 结构化的组合不需要额外训练,用现有工具链就能实现。论文在 arXiv 上公开,代码可复现。
https://x.com/omarsar0/status/2080296884187652381 https://arxiv.org/abs/2607.13285
08

腾讯发布 WorkBuddy Bench:多领域编码智能体评测套件,抗污染任务构造,覆盖代码/前端/办公/安全四域

arXiv · 7月23日

腾讯发布 WorkBuddy Bench——一个多领域编码智能体评测基准。核心特点:四个子集覆盖仓库级工程(Code)、前端开发(Web)、办公与业务流程(Office)、红蓝队安全(Security),每个子集使用不同的评分方式,不报告跨子集的总平均分。

抗污染设计:每个任务从真实的 commit、PR 或业务场景逆向构造,改写为口语化的角色扮演请求——任务的 prompt 无法通过搜索网络找到对应的原始 issue 或 PR。数据集完全开源:任务目录、环境镜像、评测 harness、测试用例和参考方案均公开。已在 CodeBuddy Code 和 Claude Code 两个 agent harness 上运行,报告了跨模型排行榜。

为什么值得关注
benchmark 污染是 coding agent 评测的核心难题——SWE-bench 等公开基准的任务描述可以从 GitHub 上搜到,模型可能在训练时已经见过。WorkBuddy Bench 的解法是把任务 prompt 改写成"口语化的角色扮演请求",让搜索引擎找不到原文——模型即使见过原始 PR,也无法直接匹配到这个任务。四个域的设计也值得关注:Code 和 Web 是常规编码,Office 测试 agent 在业务流程中的表现(如处理表格、生成报告),Security 测试红蓝队能力——这比纯代码 benchmark 更接近真实工作场景。在 CodeBuddy Code 和 Claude Code 上双跑意味着结果可直接对比两个 harness 的差异。对做 agent 评测的团队,这套基准的抗污染思路和开源数据集可以直接拿来用。
https://arxiv.org/abs/2607.20911 https://workbuddybench.com/
09

Codex 两项更新:跨多文件夹工作打破单目录限制,安装 Skill 可调用 Grok/Kimi 做模型交叉评估

X:OpenAI Developers (@OpenAIDevs) / vista8 · 7月23日

Codex 项目现支持跨多个本地文件夹读取和写入代码、文档及参考文件,主文件夹仍作为 Git 根目录。此前 Codex 只能在单一文件夹内工作,开发者需要将所有相关文件放在同一目录下——跨文件夹支持意味着 Codex 可以同时操作前端、后端和文档等分散在不同目录的代码。

同时,开发者可通过 npx skills add joeseesun/qiaomu-model-cli 安装 Skill,在 Codex 中调用 Grok 和 Kimi 模型来评估大模型输出的可信度。该 Skill 开源,支持扩展更多模型,实现多模型交叉验证。

为什么值得关注
跨文件夹工作解决的是 Codex 在真实项目中的结构性限制——大部分团队的代码库不是单目录 monorepo,前端后端文档分散在不同路径。之前开发者要么手动 symlink、要么把文件拷到同一目录,现在可以直接引用。Skill 调用 Grok/Kimi 做评估则是 skill 生态的一个新用例:不是让 skill 执行任务,而是让 skill 调用其他模型来审计当前模型的输出。这和前几天 codex-bridge(Claude Code 调 Codex 做交叉审计)是同一思路——多模型交叉验证正在成为 coding agent 的标配模式。区别在于 codex-bridge 是 agent-to-agent 深度审计,这个 Skill 是轻量级的模型输出可信度评估,安装成本更低。
https://x.com/OpenAIDevs/status/2080390328880951299 https://x.com/vista8/status/2080466870956880368
10

微软工程"可替换性":用更便宜自研 MAI 模型替代前沿模型,Copilot 性能不依赖任何单一模型

X:Rohan Paul (@rohanpaul_ai) / Satya Nadella (@satyanadella) · 7月23日

微软正将自家产品路由到更便宜的内部 MAI 模型——只要这些模型在特定任务上匹配前沿模型的质量。MAI 模型在多项任务上超越通用前沿模型,同时仅使用一小部分 token。Satya Nadella 发文称关键在于"优化成本与产出之间的前沿"。

核心设计理念是"可替换性而非能力":harness、记忆、上下文和 skills 被设计在模型权重之外,使模型成为可替换组件。微软的评估标准是——"即使移除任何给定模型,你的评估指标也应该继续攀升"。微软不希望 Copilot 的性能完全依赖 OpenAI、Anthropic 或任何单一 MAI 模型。

为什么值得关注
微软是 OpenAI 的最大投资方,但在工程上把 OpenAI 的模型当可替换零件——这比任何声明都更能说明行业方向。"可替换性而非能力"这个原则值得每个做 agent 平台的团队认真想:你的 agent 系统是否能在换掉底层模型后继续工作?如果你的 evals 在移除某个模型后就开始下降,说明你的系统对那个模型有隐性依赖——可能是 prompt 针对特定模型调优、可能是工具调用格式不兼容、可能是上下文窗口依赖。微软的实践给出了一个检验标准:把你的最强模型从 agent 系统中移除,看 evals 是否还能 hill climb。如果能,你的 harness 是健康的;如果不能,你的"能力"其实寄生在模型上而非工程上。结合前一天的 K3 接入评估和 Offloop 的多智能体结果,信号一致:模型在变便宜、变可替换,harness 才是长期价值。
https://x.com/rohanpaul_ai/status/2080391482088059304 https://x.com/satyanadella/status/2080329851127669104