腾讯混元Hy4 preview开源，WorkBuddy实测：有了小型团队交付实力，但还得有人盯

Hy4 preview核心能力与开源部署

今天，腾讯发布了混元Hy4 preview，总参数770B、激活参数49B，上下文长度突破1M，重点面向Agent、Coding与生产力场景优化，增强在真实业务场景中完成复杂任务的能力。

相比上一代，Hy4 preview在多步骤Agent、代码开发和生产力任务上进一步提升，尤其是在更好的任务拆解、上下文承接、指令遵循和长链路执行能力上。

在Coding场景中，进一步增强代码理解、生成、修改和复杂工程任务处理能力；在生产力场景中，重点提升文档处理、信息分析、办公自动化、游戏开发、网页生成及跨工具协作等能力；在游戏开发场景中，增强了一句需求直接生成可玩原型能力，并能熟练使用游戏引擎，开发者可以通过多轮交互持续完善复杂游戏项目；在科学研究场景下，提升复杂科研问题的理解、推理与求解能力。

Hy4 preview在自身研发的全链路过程中发挥了积极价值，首次参与训练方法、数据策略、评估体系和底层算子的自动优化。模型提出方案、运行实验并根据结果继续迭代，实验产生的代码、日志和反馈进入下一轮探索，形成初步的递归自我改进闭环。

Hy4 preview还通过自主分析推理系统瓶颈，并围绕算子融合、通信优化等方向开展多轮优化，端到端吞吐相较基线提升31.8%，在不同上下文长度和并发度下均取得稳定收益，初步展现了自主开展推理基础设施优化的能力。

Hy4 preview已经开源，并在WorkBuddy/CodeBuddy国内版及国际版、元宝、ima等腾讯产品同步首发，也可通过腾讯云Tokenhub和OpenRouter接入API使用。

定价方面，Hy4 preview继续走普惠高性价比路线，输入6元/百万tokens，输出18元/百万tokens，缓存命中0.3元/百万tokens。为进一步收集用户反馈以进一步提升模型性能，腾讯表示，WorkBuddy/CodeBuddy将面向用户开展为期2周的限时免费活动。

WorkBuddy实测一：AI编程工具采购报告——搜索能力强但差临门一脚

我们在WorkBuddy中测试了Hy4 preview，最直接的感受是Agent已经开始具备“把一件事情做完”的能力，但人还是需要作为最后一道防线，Agent还需要解决“最后一公里”问题。

我们首先给的任务是：公司准备为30人开发团队统一采购AI编程工具。请调研以下四类方案的当前团队/企业选择：Cursor；GitHub Copilot；Claude Code / Claude for Work；OpenAI Codex / ChatGPT Business 或 Enterprise 中的Codex。（给的提示词会更详细一些）

先直接说结论：最后的报告很漂亮，结果非常接近通过，但因几处关键事实和成本计算错误被卡在及格线下。

这份报告有不少做得不错的地方，比如能调用十来个网页，把复杂政策调查得非常深入，时效性信息也抓得很好，像GitHub 2026年4月22日暂停Copilot Business新自助注册，这是真实且很容易漏掉的动态政策，报告抓到了。

但仍然有遗漏，而这也带来了严重后果：由于Cursor年付价格漏查，造成整个成本横向比较口径不一致。

报告按照40美元/席/月算出Cursor Teams Standard 30人一年14,400美元，Premium算成43,200美元；但Cursor 2026年6月官方已经明确，Teams年付分别是Standard 32美元/席/月、Premium 96美元/席/月。

因此，如果报告对Claude、ChatGPT都采用年付最低价格，Cursor也应该同口径使用年付价格。正确应为：

• Cursor Teams Standard：30 × 32 × 12 = 11,520美元/年，不是14,400美元；
• Cursor Teams Premium：30 × 96 × 12 = 34,560美元/年，不是43,200美元；
• 20 Standard + 10 Premium：20×32×12 + 10×96×12 = 19,200美元/年，不是24,000美元。

这个错误直接导致了错误的结论：“即使Copilot Business额度超支100%，年成本13,680美元仍低于Cursor Teams Standard的起步价14,400美元。”

还有OpenAI Business的SSO不是“未确认”，而是已经有明确官方文档这样的错误。

此外，在系列调研后，最终却在一个简单乘法或者复制数字上翻车。比如15席Claude Team时总成本写为10,800美元，实际上是6,840 + 15×20×12 =10,440美元。

可以看出，目前Hy4 preview在WorkBuddy后，其信息密度、官方资料覆盖、动态政策捕捉都明显高于普通搜索型回答，调研能力很强，但没有完成最后一道交叉校验和数字自检，导致少量错误进入了核心采购结论。

因此，当前人力核验是必不可少的环节。它已经像一个相当能干的采购研究员，但还不是可以不复核就签字的采购负责人。对于后续研发来说，在长链路工具调用结束后，Agent需要加强对自己的事实和计算进行二次审计。

WorkBuddy实测二：四端网页制作——小型产品团队式交付能力

第二个任务，是做一个四端产品实现。

还是直接说结论：明确通过，而且属于目前相当强的一档表现。

这次给的任务提示词是：

公司准备开发一套内部“项目作战中心”，用于同时管理多个产品项目。系统至少包含：项目名称、项目负责人、当前阶段、完成进度、截止日期、风险等级、待办任务。请基于同目录中的projects.json，分别实现Web端、移动端、桌面端和一个3D项目作战室。要求四个版本使用一致的数据结构，但针对不同终端设计适合的交互方式，不能只是简单缩放同一个页面。必须支持查看项目列表、查看项目详情、按负责人和风险等级筛选、创建任务、修改任务状态、查看整体项目进度、对已逾期或高风险项目给出清晰的视觉提示。3D版本要求：不同项目表现为可进入或可点击的独立区域，可以移动或旋转视角，点击项目区域能够看到项目状态，至少提供一种对任务或项目状态的交互操作，场景应有基本灯光、空间层次与可辨识的项目区域，而不是仅把平面卡片贴到3D画布。最终请交付可以实际运行的版本，说明每一端的运行方式，并在交付前自行检查主要功能是否正常。

• 3D项目作战室展示：

“它真的把3D交互和真实业务状态接起来了。”8个项目在环形空间中仍然能够区分，左右HUD没有把中心操作区域完全挤没。测试期间隐藏检查点几乎全部被主动识别并处理了。比如特意埋进去的“P003已经逾期且进度只有42%”“P006已经完成91%但仍然是高风险”等，它不但处理了，还专门为这些场景写了测试。

• Web端展示：

能够正常渲染8个项目、4个KPI，1920×1080下没有横向溢出；点击“张晨”负责人筛选后，项目从8个正确变成P001/P007两个。直接新增任务后，Store中任务总数从17→18，页面也同步出现新任务。这证明它不是做的假按钮，而是业务状态真实发生了变化。

产品完成度也比较高。它已经接近一个可以实际使用的内部Dashboard。P003的“逾期9天”、P006的“高风险但已经完成91%”都进行了显著提示，说明模型不仅执行了页面需求，还理解了业务信息层级。

• 移动端展示：

“移动端不能只是把Web缩窄。”这个做得很好。设计了项目/任务/概览/我的四个Bottom Tab，加全屏详情、Bottom Sheet、移动端筛选和任务状态面板。没有出现页面级横向溢出，各项点击正常。而在代码层面，其甚至处理了safe-area-inset-*、44px触控目标、iOS输入框以及左边缘滑动返回等细节。明显的问题是任务的四个状态变成了空白。

• 桌面端展示：

总的来说，它已经不只是会写代码，而是具备了小型产品团队式的交付能力。四端并非简单套壳：移动端重新设计了触控信息架构，桌面端使用了原生菜单、磁盘和系统通知，3D场景甚至将任务状态与空间物体实时联动。更重要的是，Agent主动建立了共享数据层和大量自动测试，连高风险91%、超长任务名等隐藏边界都考虑到了。

不过在最终交付时出现了一些问题：一键测试脚本存在目录错误，两份浏览器测试又写死了生成机器的绝对路径。另外，Agent很会写测试，但最后没有检查“这些测试离开自己的机器还能不能跑”。比如，README宣称可以一键执行147项测试，但实际执行的第一步就失败了，问题在没有最终检查交付包本身。

可以看出，它能够完成一个相当复杂的软件项目，中长程生产能力已经非常强，但最后一公里的交付审计却是薄弱环节，仍然需要人在最后审核，确认交到别人手里的东西真的能从零运行。

这个测试无疑是耗时最长的，期间出现了三次无法进行下去的情况，但没有做任何设置、检查等情况下，仅简单对话后，它可以自己继续运行下去。比较意外的是，它在运行期间，会有“定期回看消耗高的任务，看看哪里可以优化”的思考，如果真的能帮我们省下token消耗的话，就很值得称赞了。不过，由于后台没有找到相关统计，我们没办法更进一步查看细节。

一个有意思的“小思考”：

WorkBuddy实测三：季度运营复盘——长链路分析表现亮眼

第三个任务，我们给了10个附件，包含公司最近12个月业务数据、产品指标、客户反馈、销售笔记、管理层会议纪要以及上一季度经营复盘模板，让其完成2026 Q3季度经营复盘。

依然直接说结论：表现亮眼，不但完成了长链路分析，而且最终的数字校验、异常发现和多源冲突处理基本没有掉链子。

感兴趣的读者可以点击查看最后输出的复盘文档：

https://docs.qq.com/doc/DYm5zUEpRWHBZTERU

具体来说，我们给的是一份故意做脏的数据包，比如有错误汇总表、缺失月份、重复订单和前后观点改变的会议纪要等，但其没有被带偏。比如发现两个来源不一致后，它会继续往下追，直到确认哪个才是可信口径。

从“执行闭环”看，其完整走完了文件盘点 → 数据校验 → 去重 → 发现缺失 → 发现公式异常 → 重算 → 同比/环比 → 产品指标 → 客户信号 → 回查销售纪要 → 回查管理层纪要 → 处理冲突 → 经营归因 → 风险 → Q4优先事项 → 数据质量附录 → 管理层摘要。

这次运行过程中确实是0次人工干预，但出问题的地方依然是“最后一公里”，第一版Word文档出现了下面问题，修改对话了两次才改好，最后我们也同步到了腾讯文档一份。

它可以像一个分析师一样追溯数据，也能像项目负责人一样跑完整个复盘流程。但是，偶尔其推导因果结论会比较勉强。

如果结合第一个AI编程工具采购的测试来看，任务越长，并不一定越容易失败。模型的能力短板不一定随着任务变长而线性放大，在有明确数据和封闭任务空间的长任务中，它反而可能比开放互联网调研更稳定。

被算力拖慢的腾讯发力

“混元大模型经历了不同阶段，多次重构，混元Hy3架构化繁为简，更注重训练数据的质量，在同等参数的大模型中效果突出。但由于公司整体的算力严重不足，拖慢了模型训练与产品发展，产生了比较大的影响。”腾讯集团高级执行副总裁、云与智慧产业事业群（CSIG）CEO汤道生在腾讯内刊发表的署名文章上说道。

汤道生近日回应“腾讯做AI慢了”的质疑时坦言，混元经历了多个阶段和多次重构，但“公司整体算力严重不足”，拖慢了模型训练和产品发展，对腾讯AI进度产生了较大影响。

这种算力焦虑其实早有迹象。今年6月，汤道生就表示腾讯算力“一直处于不太够的状态”，Token调用出现爆发式增长，有限资源甚至需要优先满足内部需求。

“我们非常期待下半年有更多国产算力可以支持到我们的云业务，可以把一些推理场景服务得更好。”在6月底的采访中，汤道生直言自己做芯片设计并不解决产能问题，因此腾讯选择开放生态的，“跟更多芯片厂商合作，也让国产算力芯片厂商愿意拥抱腾讯，作为它们算力应用的一个展现标杆。”

但这不会立刻解决算力短缺问题。7月，Hy3正式版发布，而在Hy3接入WorkBuddy后迅速遭遇算力挤兑，7月9日下午排队率一度超过50%，腾讯不得不紧急扩容。

从8月初的财报看，2026年二季度腾讯资本开支达到527.8亿元，同比大增176%，环比也比一季度的约319亿元增加约65%，主要投向AI基础设施和算力采购。仅上半年资本开支就达到约847亿元，已经超过2025年全年792亿元的水平。二季度大规模AI基础设施投入和相关预付款甚至让腾讯自由现金流转为-138亿元。公司表示，若剔除AI算力采购预付款项，自由现金流为376亿元。

另一方面，腾讯也在明显整合、加速。

自2月重建基础设施以来，混元大模型平均每两个月迭代一次大版本。在4月，重构后的首个模型Hy3 Preview推出；7月6日，Hy3正式发布，总参数2950亿、激活参数210亿，支持256K上下文，并把重点放到代码、复杂任务和Agent能力，而不是继续单纯放大参数。腾讯称，从Preview上线到正式版发布，其日均Token消耗增长20倍，WorkBuddy中主动选择Hy3 Preview的用户数增长6倍。

通过preview先行、正式版跟进的方式，把真实世界的反馈持续引入研发之中。按照这一节奏，Hy4的下一版模型也将在近期陆续上线。

与此同时，腾讯也在收拢过去相对分散的模型体系。46款混元旧模型已在6月集中下线，Hy3 Preview将在8月底下线，并迁移至Hy3。原混元大模型平台的新模型销售入口也逐步迁向TokenHub。后者不仅提供腾讯自研模型，还接入DeepSeek、Kimi、MiniMax、GLM等第三方模型。

另外，腾讯开始把模型和产品绑得更紧。Hy3已经进入WorkBuddy/CodeBuddy、元宝、ima、Marvis等产品，8月又进一步向全球开放。在腾讯内部办公场景中，接入Hy3后WorkBuddy任务成功率超过90%，平均完成时间较上一代模型缩短34%。

这也体现了腾讯现在对AI竞争的态度。汤道生认为，AI应用不止模型，还有算法和工程。“场景，是腾讯做AI最厚的底牌。场景中的数据，不管是用户生成的，还是专业机构提供的，都为大模型提供了上下文；场景中的历史互动，也能被提炼成个人记忆，或打造成可复用的技能。”

Hy4仍在继续追赶基础模型，但腾讯显然不准备只靠模型翻身。

JOTO 企业落地观察

• Hy4 preview在四端交付、季度复盘等封闭数据域长链路任务中稳定性高，表明企业若构建自有知识库与结构化业务数据资产，可显著降低智能体幻觉风险，提升端到端任务成功率。
• 采购报告中暴露的事实核查与数字自检缺陷，揭示当前Agent工程必须嵌入“交付审计层”：包括外部数据源交叉验证、计算过程回溯、交付物可移植性检查等刚性环节，不能仅依赖模型单次输出。
• Hy4参与自身训练优化与推理基建调优，印证“模型即基础设施”的演进趋势；对企业而言，这意味着智能体系统需预留可观测、可干预、可回滚的工程接口，而非黑盒调用。
• 腾讯将Hy3/Hy4深度绑定WorkBuddy等产品，并推动TokenHub聚合第三方模型，反映企业AI平台正从“模型中心”转向“场景-工具-模型”协同架构；企业部署需同步规划工具链集成、权限治理与技能沉淀机制。