核心事件：混元 Hy4 preview 正式发布

8 月 28 日，腾讯发布并开源混元新一代大模型 Hy4 preview。这是继 Hy3 正式版之后的迭代产品，重点强化在软件工程、办公分析、游戏开发和科学研究等生产力场景中的长程执行能力。

关键硬信息如下：

• 发布时间：8 月 28 日
• 新版本名称：Hy4 preview
• 参数规模：总参数 770B，激活参数 49B
• 上下文长度：扩展至 1M tokens
• 可用渠道：WorkBuddy、CodeBuddy、元宝、ima、腾讯云 TokenHub、OpenRouter
• 定价策略：输入 6 元/百万 tokens，输出 18 元/百万 tokens，缓存命中 0.3 元/百万 tokens

相比 Hy3，Hy4 preview 的总参数从 295B 增至 770B，激活参数从 21B 增至 49B，上下文长度也从 256K 扩展到 1M。腾讯还称，Hy4 preview 首次参与了自身训练方法、数据策略、评估体系和底层算子的优化，并通过多轮实验将推理吞吐相较基线提升 31.8%。

腾讯内部组织了 163 名专家 对 203 个工程任务 进行盲测。按照腾讯公布的数据，Hy4 preview 平均得分为 2.99/4，略高于 Kimi K3 的 2.94 和 GLM 5.3 的 2.92。

能力验证：长程 Agent 在真实任务中的表现

为验证 Hy4 preview 的实际能力，测试团队设置了三项复杂任务：多源材料费用审核、原生 Canvas 制作网页小游戏、Three.js 3D 竞速游戏开发。

在费用审核任务中，模型耗时 3 分 27 秒，处理 12 份分散材料后生成结构化审核报告，完成 6 笔申请的交叉核验、制度匹配与金额计算。6 笔申请总额 5364 元，模型最终核准 4294 元，核减 230 元，另有 840 元退回补件。

它不仅识别了 RB-003 中邮件与行程记录组成的证据链，也发现 RB-004 中所谓“审批”邮件实为暂缓批准，最终将该笔软件订阅申请退回补件。细微失误在于将 8 月 12 日申请误归入 8 月 15 日生效后的制度 v2，但因相关规则未变，未影响最终金额和结论。

在 Canvas 游戏项目《深海进化论》开发中，模型用 32 分 1 秒交付了可玩版本，包括 30.5KB 的 game.ts、index.html，以及可双击运行的单文件版本。游戏支持惯性移动、三种体型鱼群、吞食成长、碰撞判定、开始与结算界面，并额外加入连击、暂停、静音、本地最高分等功能。

交付前，Hy4 preview 跑了 15 项 Node 逻辑测试和 14 项 Chromium 浏览器端到端测试，覆盖开局、键鼠操作、吞食成长、死亡结算、重开、暂停和静音等路径。它还主动修复了鱼群进场动画不自然、追击时始终差 20 到 30 像素追不上等手感问题。

Three.js 项目《午夜港口》则暴露了更典型的工程现实：首次开发耗时 1 小时 39 分钟，进行了 27 次文件修改，生成了包含 14 个顺序检查点、164 个碰撞盒、三架 AI 无人机、雨夜港口场景和实时 HUD 的游戏框架。但第一次交付依赖本地服务器，任务结束后直接双击 index.html 会因浏览器限制加载失败，用户拿到的是白屏。

收到反馈后，Hy4 preview 没有重写游戏，而是重新处理依赖和打包方式，用 20 分 8 秒生成了一个 0.57MB 的单文件版本，可直接双击启动。调试过程中，它还定位并修复了 AI 撞障碍、完赛后继续累计圈数、雨夜场景过曝等问题。其中，过曝问题被定位到 UnrealBloom 参数，阈值从 0.55 提高到 0.78 后，画面恢复正常夜景观感。

关键参数对比与性价比策略

Hy4 preview 虽为 preview 版本，但延续了腾讯“普惠高性价比”的路线，并与 Hy3 形成明确参数跃升：

原文披露的定价显示，Hy4 preview 输入为 6 元/百万 tokens，输出为 18 元/百万 tokens，缓存命中为 0.3 元/百万 tokens。结合其同步进入 WorkBuddy、CodeBuddy、元宝和 ima，并可通过腾讯云 TokenHub 及 OpenRouter 调用，腾讯显然希望降低使用门槛，扩大模型在实际任务中的调用量。

腾讯还披露，二季度混元、元宝、CodeBuddy、WorkBuddy 和小微等新 AI 业务，合计对 Non-IFRS 经营利润产生了约 105 亿元的净影响。腾讯同时明确算力分配顺序：优先用于自研模型训练，其次支撑 WorkBuddy 等产品的推理需求，剩余部分再通过腾讯云对外提供。

落地建议：谁该尝试，谁该观望

建议优先尝试的用户：

• 腾讯云 API 调用方，尤其是需要长上下文或多轮工程任务建模的团队
• 办公自动化、代码审查、材料交叉核验等结构化任务场景的建设者
• 资源受限但希望快速验证前端或游戏原型的开发者

建议保持谨慎的用户：

• 对制度版本、事实前提和关键证据要求极高的场景，仍应保留人工复核
• 需要一次性交付稳定成品的复杂工程任务，应把模型输出纳入测试、验收和回滚流程

写在最后

Hy4 preview 的看点不只在参数和榜单分数，而在“发现问题—运行实验—修复迭代”的完整执行链能否承接真实工作任务。它仍会犯错，但相比只给出一次性答案的模型，更重要的变化是能够在错误出现后继续定位问题并迭代。

混元能否在持续迭代中站上第一梯队，最终还要看这些能力能否转化为稳定的产品使用和商业回报。