姚顺雨自从加入腾讯之后，可算是拿出了一个模型产品了。
虽然说目前腾讯放出来的还只是个preview版本，但也能借此初看端倪。
Hy3 preview这个模型和市面上其他大模型最大的区别在于，它贯彻了姚顺雨对上下文独有的那种“执着”。
当其他厂商都在卷agent 能力、代码生成、多模态的时候，Hy3把“出色的上下文学习和指令遵循能力”单独拎出来，写进了核心能力清单的第一条。
别人模型宣传的第一张性能天梯图，放的都是什么SWE-Bench Pro或者Terminal-Bench 2.0这种，以表达模型在agent和代码上面多么出色。
Hy3 preview不一样，它一上来放的是AdvancedIF、AA-LCR，以及姚顺雨自己弄的CL-bench，这些都是看上下文推理、检索和指令遵循的榜单。
其实姚顺雨加入腾讯后发布的第一个研究成果就是CL-bench，这是一个专门用来测试模型能否从上下文中学习新知识并正确应用的基准。
在论文里，姚顺雨的观点是当前大模型的核心短板不是读不全、找不到，而是“学不会、用不对、执行不了”。
模型可以在上下文里找到一条规则，但它不会把这条规则真正内化成当前任务的执行逻辑。
Hy3 preview 的设计，就是要解决这个问题。
这是姚顺雨对上下文这套叙事在产品层面的第一次完整落地。
不过，让我们先从模型开始讲起。
01
Hy3 preview是一个怎样的模型？
Hy3 preview是一个295B总参数、21B激活参数的混合专家模型，支持256K上下文长度。
这个模型最核心的特性，是它在上下文学习和指令遵循上的表现。
姚顺雨此前为测试模型真实的上下文能力，提出了CL-bench和CL-bench-Life这两个评测基准，检查模型能否从上下文中学习新知识并正确应用。
Hy3 preview在CL-bench上的得分是26.7，相比Hy2的19.2提升了39%。在CL-bench-Life上得分22.8，相比Hy2的16.5提升了38%。
这个提升并不是通过给模型增加上下文窗口长度实现的，是靠模型真正学会了如何从杂乱的上下文里，提取出有用的规则，并把这些规则应用到了当前任务中，后面我会列举出一些例子，读到的时候你就懂了。
姚顺雨对Hy3 preview明确提出了三个原则。
第一条是能力体系化，不推崇偏科，因为即使是代码Agent这样的单一应用，背后也需要推理、长文、指令、对话、代码、工具等多种能力的深度协同。
第二条是评测真实性，主动跳出容易被刷榜的公开榜单，通过自建题目、最新考试、人工评测、产品众测等方式，去评估模型在真实场景里的战斗力。
第三条是性价比追求，深度协同模型架构和推理框架的设计，大幅降低任务成本，让智能用得起、用得好。
这三条原则，本质就是“让模型真正能在真实场景里工作”这件事的一体三面。
姚顺雨知道一个道理，2026年都快过一半了，大家早就清楚这些榜单刷分是没有意义的，所以模型一定要强调生产环境里稳定运行，在用户手里真正有用。
Hy3 preview的上下文学习能力、指令遵循能力、长文档处理能力，其实也都是为了这个目标服务的。
具体来说，Hy3 preview在处理真实场景任务时，展现出了三个关键能力。
第一是从冗长文本中准确定位关键信息。它不是简单地做关键词匹配，而是能够理解信息之间的逻辑关系，知道哪些信息是任务的前提条件，哪些信息是执行约束，哪些信息是优先级标记。
第二是从隐含规则中推导出执行逻辑。很多真实任务的规则不会明确写出来，而是散落在对话、纪要、文档的各个角落。Hy3 preview能够把这些碎片化的信息整合起来，形成一套完整的执行方案。
第三是在多轮交互中保持上下文的连贯性。它不会因为对话轮次增加，就丢失前面的关键信息，也不会因为中间插入了其他话题，就忘记当前任务的目标。
这三个能力，恰恰对应了姚顺雨在CL-bench论文里指出的问题。
他认为当前大模型的核心短板不是读不全、找不到，而是“学不会、用不对、执行不了”。
模型可以在上下文里找到一条规则，但它不会把这条规则真正内化成当前任务的执行逻辑。它更像是在做检索和拼接，但在实际任务中，模型应该是对上下文在做理解。
而Hy3 preview的设计，就是要解决这个问题。
腾讯混元团队在内部做了大量真实场景测试，来验证Hy3 preview的上下文学习能力。
一个典型场景是会议纪要提取待办事项。给模型一份几千字的会议纪要，里面散落着七八条隐藏前提：某个同事这周请假，某个项目的预算在讨论中被调整，某个任务的优先级在多轮讨论后被重新排序。模型需要从这些杂乱的信息里，准确提取出所有待办事项，不能漏掉任何一条，也不能瞎猜任何一条。
Hy3 preview在这类任务上的表现，明显好于之前的模型。它能够准确识别出哪些是已经确定的任务，哪些是还在讨论中的想法，哪些是被否决的方案。
另一个场景是旅行计划整理。
用户可能在多轮对话里，陆续提出各种需求，比如预算限制、时间安排、同行人员、偏好类型。这些信息不是一次性给出的，而是在对话过程中逐步补充和修正的。
Hy3 preview能够在每一轮对话后，更新自己对任务的理解，并根据最新的约束条件，调整输出方案。它不会因为前面说过“预算5000”，后面又说“最多4000”，就输出一个自相矛盾的计划。
这种上下文学习能力，在Hy3 preview的agent应用中发挥了关键作用。
腾讯在CodeBuddy和WorkBuddy的实际部署中，Hy3 preview已经能稳定驱动495步的复杂工作流。
在这长达495步的任务链之中，每一步都能正确理解当前的上下文状态，并根据这个状态做出合理决策。
这个任务的难点就在于，如果模型在第50步就理解错了上下文，那后面的445步就会全部偏离目标。
Hy3 preview之所以能做到这一点，靠的就是它在每一步都能从前面的执行结果里，学到新的约束条件，并把这些约束条件应用到后续行为中。
Hy3 preview的另一个特性，是它在指令遵循上的稳定性。
很多模型在面对复杂指令时，会出现理解偏差或执行偏离。用户要求输出JSON格式，它可能输出Markdown；用户要求只列出前三项，它可能列出五项；用户要求不要加任何解释，它可能在最后加一段总结。
这些问题看起来是细节，但在生产环境里，每一个细节偏差都可能导致下游系统出错。Hy3 preview在指令遵循上做了专门优化，它能够准确识别指令中的格式要求、数量限制、输出范围，并严格按照这些要求执行。
腾讯混元团队在元宝产品上的测试结果显示，Hy3 preview在意图理解精准度、文本创作质量、深度搜索等指标上，都有明显提升。
你在和模型对话时，它能够在第一次交互中，就准确理解用户想要什么，并给出符合预期的结果。
Hy3 preview在长上下文处理上的表现，也体现了姚顺雨对上下文的理解。
腾讯内部产品ima的测试结果显示，Hy3 preview在处理几万字文档时，无论是知识库问答还是通用问答，都能准确找到需要的信息，并且总结得全面。它不会因为文档太长，就只关注开头或结尾，也不会因为信息分散，就遗漏关键细节。
更重要的是，Hy3 preview在长上下文中的推理能力是稳定的。很多模型在处理长文本时，会出现“上下文税”问题。
简单来说就是，随着上下文长度增加，模型的推理质量会下降，输出的准确性会降低。
Hy3 preview的设计，就是要让模型具备这种“现场学习”的能力。它不是靠增加预训练数据量来覆盖更多场景，而是靠提升上下文学习能力，让模型能够在任何场景里，都能从眼前的材料里学会新东西。
这种能力一旦建立起来，模型的适应性就会大幅提升。它不再需要为每一个新场景都做一次微调，也不再需要为每一种新任务都准备一套专门的提示词。它只需要在上下文里给出足够的信息，模型就能自己学会如何执行。
这就是Hy3 preview和其他模型的本质区别。
02
姚顺雨为何执着于上下文？
姚顺雨对上下文的执着，其实也不是从CL-bench才开始的。
往前推几年，他在普林斯顿和谷歌联合研究时提出的ReAct框架，就已经在探索一个核心问题：如何让模型在推理和行动之间建立有效的反馈循环。
ReAct的全称是“Reasoning and Acting”，它的设计思路是让模型在执行任务时，不断地“思考-行动-观察”，每一步的观察结果都会成为下一步推理的输入。
这个框架在2022年提出时，就已经成为agent领域的经典范式。
姚顺雨认为，模型不能只会推理，也不能只会调用工具，它必须能够把推理能力和行动能力协同起来。
但这种协同的前提是什么？
是模型能够从每一步的执行结果里，提取出对下一步有用的信息，并且把这些信息正确地整合到当前的推理链条里。换句话说，模型必须能够从动态变化的上下文中持续学习。
这就是为什么姚顺雨加入腾讯后，第一件事就是推出CL-bench。
他不是在否定ReAct，他是在补足ReAct框架里一个更底层的能力缺口。
如果模型连静态上下文里的新知识都学不会，那它在动态的Agent工作流里，就更不可能根据执行反馈做出正确调整。
CL-bench测的就是这个最基础的能力，给你一份材料，里面有你从没见过的规则，你能不能现场学会并用对。
Hy3 preview的深层逻辑就是把这两个方向打通。
姚顺雨的“底层代码”是只有读懂了上下文，agent才能真正干活。
所以Hy3 preview才有了这种“context-first、agent-facing”的设计。
别的模型在agent任务上的提升，靠的是单独优化工具调用或任务规划。Hy3 preview在这些agent任务上的提升，是通过提升底层的推理、长文、指令、对话能力，让Agent的整体表现变强。
姚顺雨的这种把模型给体系化思路，和当前主流的agent存在本质区别。
很多团队在做Agent时，会专门针对某一类任务去优化，比如专门做代码生成，或者专门做信息检索。这样做的好处是能在特定榜单上快速拿到高分，但坏处是模型的能力会变得很窄，一旦任务稍微偏离训练场景，表现就会大幅下降。
姚顺雨是反过来，他不追求单项第一，他要让模型在多种能力上都达到可用的水平，然后让这些能力在实际任务里协同工作。
Hy3 preview在腾讯内部产品上的部署效果，就是这种思路的验证。
CodeBuddy和WorkBuddy的数据显示，Hy3 preview的首token延迟降低了54%，端到端时长缩短了47%，成功率提升到99.99% 以上。
这三个指标放在一起看，说明模型不只是变快了，它还在保持高成功率的前提下变快了。
姚顺雨的道路很清晰，模型的推理能力保证了任务规划的正确性，长文能力保证了上下文理解的准确性，指令遵循能力保证了执行的稳定性，代码能力保证了输出的可用性。
姚顺雨在去年提出的“AI下半场”判断里，提出了一个观点，他说真正决定模型能否走出demo的，是你到底有没有把系统放进真实世界的约束里，并用真实世界的方式去评估它。
现在看来，这个观点在Hy3 preview的开发过程中得到了彻底贯彻。
腾讯混元团队构建了50多套内部评测体系，覆盖了从基础能力到产品场景的各个层面。他们还专门去跑最新的考试，比如清华大学求真书院的数学博士资格考，全国中学生生物学联赛，用这些真实考场的成绩来验证模型的泛化能力。
这种评测思路和主流做法完全不同。大部分团队在做模型评测时，会优先选择那些已经被广泛使用的公开榜单，因为这些榜单的结果容易对外传播，也容易和竞品做对比。
但问题是，这些公开榜单往往已经被过度优化，模型可以通过各种技巧在榜单上刷出高分，但这些高分未必能转化成真实场景里的可用性。
从ReAct到CL-bench，再到Hy3 preview，姚顺雨的研究路线一直没变。
如何让模型在真实场景里，能够根据当前的上下文，做出正确的推理和行动。
这个问题看起来简单，但它触及了当前大模型的一个根本性短板。大部分模型在预训练阶段记住了大量知识，但它们不会在推理时从眼前的材料里学习新知识。这种能力的缺失，直接限制了模型在动态场景里的适应性。
Hy3 preview的价值，就是在这个方向上迈出了实质性的一步。
03
Hy3正式版是啥样的？
说到preview，我第一时间想到的就是谷歌的Gemini。
Gemini的preview和正式版之间，有一个清晰的演化路径。谷歌在2025年发布Gemini 2.5 Pro时，先推出了一个preview版本，这个版本在各项能力指标上都很激进，推理深度、上下文长度、多模态理解都做到了当时的顶级水平。
但preview版本有很多问题，比如成本高、延迟长、稳定性不够。到了正式版发布时，谷歌做了大量优化，把推理效率提升了一大截，token消耗降下来了，响应速度也快了很多。
谷歌告诉我们，preview版本是用来验证能力上限的，正式版是用来做生产部署的。preview可以不计成本地把各项能力推到极致，但正式版必须在能力和成本之间找到一个可以大规模商用的平衡点。
谷歌在Gemini 2.5 Pro的迭代过程中，就是在不断调整这个平衡点。他们在6月5日更新的preview版本里，LMArena的Elo评分提升了24分，WebDevArena的评分提升了35分，但同时也在优化推理框架，降低延迟，为正式版的发布做准备。
Hy3 preview的定位，和Gemini的preview版本有相似之处，但也有明显区别。
相似的地方在于，Hy3 preview也是腾讯混元重建后的第一个版本，它的主要任务是验证新的预训练框架、强化学习流程、能力体系是否能跑通，能达到什么样的上限。
腾讯混元团队明确表示，Hy3 preview是混元大模型重建的第一步，他们希望通过这次开源和发布，获得来自开源社区和用户的真实反馈，帮助提升Hy3正式版的实用性。
但Hy3 preview和Gemini preview的区别也很明显。
Gemini的preview更像是一个能力展示版本，它会把各项指标都推到很高，但不太考虑成本和部署的问题。Hy3 preview从一开始就把性价比作为核心设计目标之一。
从Hy3 preview的实际表现来看，它已经具备了在生产环境里大规模部署的条件。
腾讯内部的多个主线产品，包括元宝、ima、CodeBuddy、WorkBuddy、QQ、QQ浏览器、腾讯文档、腾讯乐享，都已经上线了Hy3 preview。
微信公众号、和平精英、腾讯新闻、腾讯自选股、腾讯客服、微信读书等产品也在陆续接入。这种大规模的产品部署，在preview阶段就完成，说明Hy3 preview的稳定性和成本控制已经达到了可以商用的水平。
那么Hy3正式版会是什么样？参考Gemini的演化路径，我感觉应该是如下几个方向。
第一是能力上限会进一步提升。
腾讯混元团队已经在持续扩大预训练和强化学习的规模，更大尺寸的模型也在训练中。
正式版可能会在推理深度、知识覆盖、多模态理解等方面，比preview版本有明显提升。
第二是稳定性会进一步增强。
preview版本在实际部署中收集到的反馈，会被用来优化正式版的对齐策略、指令遵循能力、边界情况处理能力。
第三是成本会进一步降低。
preview版本已经把推理效率提升了40%，正式版可能会通过更激进的模型压缩、更高效的缓存策略、更优化的推理框架，把成本再降一个台阶。
但Hy3正式版和Gemini正式版可能会有一个关键区别，那就是Hy3不会为了降低成本而牺牲能力的全面性。
Gemini在从preview到正式版的演化过程中，有时会做一些取舍，比如缩短推理链条、减少思考深度，用更少的token量给出一个差强人意的输出。这种做法可以大幅降低成本，但会导致模型在复杂任务上的表现下降。Hy3的路线更可能是保持能力的均衡性，通过架构优化和推理框架改进来降低成本，而不是通过削减能力来降低成本。
姚顺雨的理解是，实用性不应该只是成本低，更重要的是能力全面、稳定可靠、真实场景里能用。Hy3 preview已经在这个方向上做出了示范，正式版大概率会延续这个思路，在能力、成本、稳定性之间找到一个更优的平衡点。
当然，这些都是基于当前信息的推测。
Hy3正式版的实际能力，还要等腾讯混元团队完成更大规模的预训练和强化学习之后才能确定。
Hy3的正式版和preview版之间不会有太大的能力落差，用户在preview阶段体验到的能力，在正式版里基本都能保留。
坏处是，这种路线对团队的技术积累和工程能力要求更高，需要在架构设计、推理优化、系统集成等多个层面都做到位，才能真正实现能力和成本的双赢。