腾讯开源混元 Hy4 preview：1M 上下文瞄准 Agent 与复杂生产力任务

2026 年 8 月 28 日，腾讯发布并开源混元 Hy4 preview。这是 Hy4 系列的早期预览版本，采用混合专家（MoE）架构，骨干模型总参数 770B、每个 Token 激活 49B 参数，上下文长度达到 1M Tokens。模型重点面向 Agent、Coding 和生产力场景，已经进入 WorkBuddy、CodeBuddy、元宝和 ima，也可通过腾讯云 TokenHub 与 OpenRouter 调用。

这次更新最值得关注的地方，是腾讯把模型能力与真实工作交付绑得更紧。软件开发、跨文件办公分析、游戏原型和科研任务都被列为重点方向，模型还参与了自身训练方法、数据策略、评估体系和底层算子的优化。不过，preview 仍是关键词：官方明确承认它在复杂任务中可能思考过久，也有过度验证的倾向。

770B/49B MoE 与 1M 上下文带来了什么

Hy4 preview 的骨干网络共有 78 层。第一层使用标准稠密 FFN，其余 77 层采用 MoE；每层包含 256 个路由专家和 1 个共享专家，每个 Token 选择 8 个路由专家并激活共享专家。模型还内置一层 MTP，用于投机解码；官方的 770B/49B 规格不包含这一层。

1M 上下文适合容纳大型代码库、成组业务文件和长期 Agent 轨迹，但“能放进去”不代表模型一定能稳定利用全部信息。实际效果仍取决于检索方式、提示结构、工具调用记录和最终校验。对小团队来说，长上下文更直接的价值是减少手工切分材料和频繁重建任务背景，而不是取消知识检索与数据清洗。

从回答问题转向交付工作成果

腾讯给 Hy4 preview 设定的生产力范围很具体：

• 软件工程：加强长程开发任务中的理解、规划、调试和验证，并改善前端视觉与交互质量。
• 办公与分析：处理散落在多个文件中的上下文，完成数据分析、公式和金融模型，并输出文档、表格或演示文稿。
• 游戏开发：根据自然语言需求生成可玩的原型，调用游戏引擎，再通过多轮交互持续完善项目。
• 科学研究：面向 AI 研发、分子动力学、凝聚态物理和基础数学等复杂问题强化理解与推理。

腾讯还组织了 163 名内部专家，对 203 个工程任务进行盲测。Hy4 preview 的平均评分为 2.99/4.00；在腾讯公布的同一套内部评测中，GLM-5.3 为 2.92，Kimi K3 为 2.94。这个结果说明模型在腾讯设计的工程任务上有竞争力，但评测由腾讯内部组织，任务分布、运行环境和评分细则也会影响结果，不能直接等同于所有业务场景中的稳定领先。

第三方在 WorkBuddy 中进行的长链路测试也呈现了类似边界：模型能够完成多端产品原型和复杂经营复盘，但开放网络调研中的价格口径、简单计算，以及交付包能否在另一台机器直接运行，仍需要人工复核。当前更稳妥的定位，是让它承担资料整理、实现和初步验证，把事实、数字与最终交付检查留给人。

“参与训练自己”是工程闭环，不是自动无限进化

Hy4 preview 首次参与了自身研发的多项环节，包括训练方法、数据策略、评估体系和底层算子的自动优化。模型可以提出方案、运行实验，再根据代码、日志和反馈进入下一轮探索。腾讯将其描述为初步的递归式自我改进闭环。

在推理基础设施上，模型还分析系统瓶颈，并围绕算子融合和通信优化开展多轮尝试。腾讯称，这些优化使端到端吞吐相较基线提升 31.8%，不同上下文长度和并发度下都获得了收益。

这仍然是受目标、实验环境和工程流程约束的自动化研发。模型参与提出与验证改进方案，最终是否采用仍依赖团队设定的评估标准与审核机制。对于开发者，实际启发在于把 Agent 放进可测量的闭环：先定义指标，让模型修改代码和运行实验，再由自动测试及人工审核决定是否保留结果。

开源、API 与两周限免降低了试用门槛

Hy4 preview 已开放原始权重和 FP8 量化权重，采用 Apache 2.0 协议。官方提供 vLLM 与 SGLang 部署方案，并可通过兼容 OpenAI 格式的接口调用。模型默认使用较高强度的推理模式，简单任务可切换为 no_think，减少不必要的长时间思考。

云端 API 发布价格为普通输入 6 元/百万 Tokens、输出 18 元/百万 Tokens、缓存命中输入 0.3 元/百万 Tokens。WorkBuddy 与 CodeBuddy 在模型发布后提供两周限时免费体验。活动范围和计费可能调整，正式接入前仍需在产品端确认。

对个人开发者而言，770B 模型即使采用 FP8 权重，也远超常见单机部署的舒适区。更现实的测试路径是先使用产品端或 API；只有在数据边界、稳定吞吐或深度定制确实要求自托管时，再评估多卡部署成本。

小团队可以先测三类任务

现阶段不必用泛化问答判断 Hy4 preview 的价值，可以直接选择带明确交付物的任务：

1. 跨文件工程修改：提供真实仓库、问题描述和测试命令，观察模型能否完成修改、运行测试并解释失败原因。
2. 多文档业务分析：输入合同、报表或访谈记录，要求生成带数据核对表的结论，重点检查引用位置、口径和计算。
3. 从需求到可运行原型：让 Agent 交付网页、工具或游戏原型，并在干净环境中重新安装和启动，检查是否存在绝对路径、缺失依赖和假按钮。

测试时应记录总 Token 消耗、人工干预次数、交付成功率与复核耗时。长上下文和更强推理只有转化为更少返工、更高一次通过率，才会形成实际生产力优势。

现在最需要观察的限制

腾讯明确把 Hy4 preview 定义为早期版本，并列出复杂任务思考时间偏长、过度自我验证等已知问题。外部实测还暴露出另一类常见风险：模型能完成大部分长链路步骤，却可能在价格口径、简单算术或交付环境上留下小错误，而这些小错误恰好会改变业务结论。

Hy4 preview 已经给开发者提供了低成本试错窗口，也展示了腾讯把模型、产品与内部工程数据协同训练的路线。下一阶段更值得关注的不是参数继续扩大，而是正式版能否降低长思考开销、提高最终校验可靠性，并把内部评测优势稳定复现到公开、可重复的真实任务中。