文 | AI大模型工场，作者｜琪琪，编辑｜星奈

是不是好用就一定意味着贵？你想选效果还是选成本？今天，我不做选择，我两个都要。

7月6日，腾讯混元Hy3正式版发布。参数只有旗舰的几分之一，却在内部盲测里跑赢了GLM5.1。

它把快慢思考融进MoE架构，总参数295B，激活参数21B，支持256K上下文。每次推理只激活21B，但知识储备是295B的量级，推理成本底，能力却不低。

这次的关键升级在三个方面。

第一，模型智能。从preview到正式版，腾讯老老实实提升后训练的算力规模，同时把数据质量和多样性拉上去。270位专家盲测，Hy3均分2.67，优于GLM5.1的2.51。以不到对方四分之一的激活参数，拿到了更高的综合评分。

第二，Agent能力。Workbuddy任务成功率从72%升到90%，平均耗时缩短34%。元宝幻觉率降了一半以上，常识错误率降了一半。ima系统稳定性95.1%，Mavis六Agent协作正确率92%。这些背后是Hy3在多步任务、工具编排、幻觉控制上的实质提升。

第三，性价比。输入1元、百万tokens，输出4元、百万tokens，缓存命中0.25元。中小团队日均50万输入+10万输出的API调用，一天不到一块钱。preview上线以来日均token消耗涨了20倍。

目前，腾讯元宝和WorkBuddy都已经全面接入Hy3。元宝基于Hy3上线了Agent功能。输入需求，直接交付PPT、Word、Excel、PDF、HTML文件，而且全部免费。

Hy3在WorkBuddy也迎来了一波用户高峰。7月8日，算力资源一度打满，下午排队率超过50%，项目团队随后紧急扩容。而这也恰恰证明了Hy3的实用价值——好的东西，大家自然会用脚投票。

实测Hy3：代码、Agent、长文

我给Hy3的第一个任务，是一个带业务逻辑的后端需求：用Python写一个异步任务队列，支持优先级调度、超时重试、死信队列，还要能接Redis做持久化。这种需求在我们团队内部，初级工程师至少要写大半天。

Hy3的输出让我有点意外。它给出了一个AsyncTaskQueue主类，里面把优先级调度、超时检查、重试逻辑、死信队列全部串了起来，类之间的调用关系很清晰。

Task做数据承载，TaskPriority和TaskStatus用枚举管状态，AsyncTaskQueue统一调度。没有给你一个空骨架让你自己填，整个链路从入队、处理、超时检测、重试到落死信队列，全跑通了。

我注意到了几个细节：优先级调度用的是Redis Sorted Set，score把优先级和时间戳组合在一起，保证同优先级下先进先出。这个设计我在生产环境见过不少，Hy3直接给到位了；任务从pending移到processing用了Lua脚本保证原子性，防并发竞争；超时任务单独用ZSET追踪，worker循环里定期检查。这几个点我没有在prompt里提，但做过生产系统的人都知道，线上不处理这些就会出事。

代码跑了一下，逻辑通，没有语法错误。重试机制目前是固定延迟，注释里也老实写了"示例中为固定延迟"，算是一个可以优化的点。生产环境一般会加指数退避。Redis连接池的配置也是默认值，没有针对高并发场景的调优建议。不过瑕不掩瑜，整体完成度已经很高了。

这让我觉得，Hy3是真的带着真实开发经验的痕迹在写。

单个任务的代码生成，很多模型都能做到。我更想测的是Agent场景——连续多步、需要工具调用、中间不能跑飞。

于是，我设计了这样一个测试：让Hy3扮演一个数据处理Agent，任务是"从一份销售CSV中提取本月TOP10客户，生成柱状图，然后写一份简短的月度销售总结邮件，收件人从公司通讯录API获取"。

这涉及三步：数据提取与排序→可视化生成→调用API+文案输出。任何一步出错，后面全白搭。

Hy3先正确地读取了CSV，并主动做了数据校验。金额字段均为正数、无空值，数据质量良好。这个步骤我没提，它自己补上了。然后进行TOP10客户汇总。它按客户名称聚合求和，给出了完整的计算明细。同时生成了柱状对比图。

最后，关键的来了。我给了它一个模拟的通讯录API地址，它先进行GET请求拿到通讯录全员列表，返回200 OK。然后做了响应校验，解析嵌套JSON结构，再筛选销售部成员。最后把图表和数据分析整合成一封邮件。

它还有自己的执行日志，知道打勾自检。这些我没要求，是它自己加的。这说明Hy3在多步任务里不只是在执行，还在自我验证。ima评测说系统稳定性95.1%、无效操作大幅减少，体验下来确实如此。

最后一个测试，我让Hy3写一篇2000字的行业分析，主题是"2026年国内大模型Agent落地趋势"。

Hy3交出来的东西，让我刮目相看。全文六部分，从范式跃迁、市场数据、技术底座、场景分层、商业模式到隐忧展望，层层递进，不是平铺的list，而是有主线的叙事。它给的数据也不是胡编的。我抽了几个交叉验证，都有出处。案例也很具体，不是泛泛的"某企业提升了效率"，而是有名字、有数字、有对比。

更让我意外的是它对市场结构的判断。它提出了中科院计算所白硕的"Harness工程"概念，点出模型-工程-场景"三件套"缺一不可。还敏锐地捕捉到商业模式从MaaS向Agent-as-a-Service的演进，以及资本流向。

当然它也有谨慎的一面。在技术隐忧部分，它老老实实写了三道坎：幻觉控制、组织治理、数据壁垒，没有因为自己是模型就回避行业痛点。

整篇读下来，结构完整、数据扎实、观点有纵深，没有排比，没有感叹号，没有纵观全局那种公文腔。不过，如果能再加一点一手访谈或独家观点，这篇就真能当行业报告用了。但作为一篇模型自动生成的分析，这个完成度已经远超我的预期。

不仅够用、够稳，还够便宜

从1月底基础设施重建，到4月Hy3 preview，再到7月Hy3正式版，不到半年，混元跑通了底层重构到产品反哺的完整链路。加上腾讯多元的产品矩阵，为模型优化提供了海量真实反馈，而模型能力的提升又反哺到所有产品。

这不是简单的"模型升级"，而是"模型-产品-数据"的飞轮开始转起来了。对话场景中意图理解的优化赋能Agent，Agent工具调用能力的提升反哺搜索——可迁移、可泛化、可复利。

也是它让我看到模型的"好用"不一定和"贵"绑定。它从来没有要去争"最强模型"的虚名，而是想要让21B激活参数的模型，在绝大多数真实场景下够用，同时让开发者用得起。

就像MoE架构总参数295B但只激活21B，这个设计本身就说明混元的态度——靠效率，不靠蛮力。256K上下文长度、快慢思考融合，它在架构层面就在为"实用"做选择。

技术改变的不只是能力的边界，更是人敢不敢迈出第一步。当21B激活参数的模型能在Agent实战中稳定交付，我们的想法也有了变成现实的可能。