腾讯 Hy4 preview：一个能做完项目却不会自己验收的 Agent

有趣的是，腾讯自己在 Hugging Face 上的 model card 里，把 "Tendency to over-verify its own work"（有过度验证自己工作的倾向） 明确列为 Hy4 preview 已知局限之一，与之并列的还有"Spending longer than necessary reasoning through complex tasks"（在复杂任务里推理时间超出必要）（来源：Hugging Face 上 tencent/Hy4-preview 模型卡的 Known Limitations 章节）。这两条与 InfoQ 三次实测放在一起看，反差很值得琢磨——官方以为它"过度验证"，实测里它在推理链条内的确会反复自我校对，但那种自我校对是「让链条本身自洽」，不是「让最终交付物在别人的电脑、Excel、Word 里打开也能用」。前一个动作在训练分布里高度奖励，后一个动作几乎没有奖励信号。所以你会同时看到：模型在链条内啰嗦得让人想打断，模型在交付面却干脆没有回头看的动作。

顺带一提，model card 里公开的架构细节也解释了为什么这种"链条自洽"能做得这么深——注意力用的是 Gated DeepSeek Sparse Attention 配合 IndexCache（跨层稀疏索引复用）、内建 MTP 层做投机解码（10B/0.7B）、iHC 4 条残差流扩展层间信息流；GPQA Diamond 92.3、SWE-Bench Pro 65.7、SWE-Bench Multilingual 82.9（来源：tencent/Hy4-preview 模型卡）。这些是把中长程能力做到「接近可交付」的架构基础，但架构本身没有回答一个问题：谁来把交付物拿到干净环境里再跑一遍。

InfoQ 那位评测者的原话可以直接抄进任何一家中国企业的 AI 落地手册：Hy4 preview 已经像「一个相当能干的采购研究员」，但还不是「可以不复核就签字的采购负责人」（来源：InfoQ）。

对企业采购者，这决定了 Hy4 preview 到底该怎么用。免费两周的窗口值得抓——尤其是它的缓存命中价 0.042 美元 / 百万 tokens，跟 0.834 美元 / 百万输入之间有近 20 倍的价差，天然适合放在 RAG、跨文档协作、长上下文重复调用这类「同一堆资料反复喂进去」的工作流里，成本模型确实好看。但流程设计里必须显式留一个「人力交叉校验」节点——落到岗位上讲：金融、法律、审计行业的 RFP 与合同定稿环节，让业务负责人在签字前做一次「数字重算」（本文开头那份 Cursor 报价，就是死在没做这一步——一份三十席位、金额万美元级的采购决策，签字前那三十秒的复算才是最后一道闸）；工程团队则要求 SRE / 运维在 Agent 交付的 repo 合入主干前，先在干净 CI 环境里 clone 一遍跑通全套测试（Dashboard 案例的 147 项测试就会在这一关被拦下）；跨境合同、招投标文件、季度经营复盘这类正式文档，编辑或秘书要做一遍格式回验再对外发出。这不是不信任 Hy4——是所有 Agent 现在都不该被直接授予未复核的签字权。

另一条线：递归自我改进的中国"第二例"

这次发布还有一条线，很少被摘录，但值得单说。腾讯官方明确写道：Hy4 preview 首次参与了自己的训练——训练方法、数据策略、评估体系、底层算子的自动优化，「模型提出方案、运行实验并根据结果继续迭代」，形成初步的递归自我改进闭环（来源：腾讯官网、InfoQ）。另一件事是推理侧：Hy4 preview 自主分析推理系统瓶颈，围绕算子融合、通信优化开展多轮改造，端到端吞吐比基线提升 31.8%，在不同上下文长度和并发度下稳定收益（来源：腾讯官网）。

有必要立刻降温：这不是「AI 训练 AI」或者奇点转折。它更接近 AlphaCode / AlphaDev 那条路线——把训练管线里最枯燥、最可参数化的环节（评估集调度、算子搜索空间、数据配比）交给模型去搜索。它不改变「人写目标函数、人定安全边界」这件事，只是把「人写调优脚本」那一层自动化。它是一个工程步骤的自动化，不是一次范式转移。

也不能算「首例」——早在 7 月 Kimi K3 就公开写过「K3 写 K3 的 kernel，K3 设计跑 K3 的芯片，边训练、边用自己干活、边迭代」（来源：月之暗面 Kimi K3 发布材料）；DeepSeek 侧 V3/R1 技术报告则更早展示了 RL 阶段模型对推理链条的自我修正与"aha moment"，但那更偏向推理层而非训练管线（来源：DeepSeek-V3 technical report, arXiv 2412.19437）。相比之下，腾讯这次的表述比同期大多数中国大模型都更聚焦在训练管线本身（评估集、算子、数据配比、推理系统），Kimi K3 侧重工具链闭环，路径不同但方向一致——把"人写调优脚本"这一层交给模型，正在成为一线中国大模型团队的公开共识。

把这一点和前面的「交付审计缺口」放到一起看，会得到一个更有意思的判断：Hy4 preview 的能力增长曲线，越是靠近训练管线内部的自动化（评估、算子、推理优化）越顺，越是靠近面向人类交付的外部审计（数字复核、脚本可移植、格式回验）越弱。这跟一个数学系博士生的成长曲线很像：先学会自证明的自洽，再学会替读者思考。Hy4 preview 已经跨过了第一步。

「算力严重不足」下的两月一版

最后一条背景，来自腾讯集团高级执行副总裁、CSIG CEO 汤道生近日在内刊上的署名文章。他罕见地承认：「混元大模型经历了不同阶段，多次重构，混元 Hy3 架构化繁为简，更注重训练数据的质量，在同等参数的大模型中效果突出。但由于公司整体的算力严重不足，拖慢了模型训练与产品发展，产生了比较大的影响。」6 月他曾在采访中说腾讯算力「一直处于不太够的状态」，Token 调用出现爆发式增长，有限资源甚至要优先满足内部需求（来源：InfoQ）。

数字这样支撑：2026 年 Q2 腾讯资本开支 527.8 亿元，同比 +176%、环比 +65%，主要投向 AI 基础设施；上半年合计 847 亿元，一举超过 2025 年全年的 792 亿。二季度大规模 AI 基础设施投入和相关预付款甚至让腾讯自由现金流转为 -138 亿元（剔除算力采购预付款后仍为 +376 亿）（来源：InfoQ）。而节奏上，自 2 月重建基础设施以来，混元大模型平均每两个月迭代一版：4 月 Hy3 Preview、7 月 6 日 Hy3 正式版（2950 亿总参 / 210 亿激活 / 256K）、8 月 28 日 Hy4 preview——是硬扛出来的加速。

汤道生自己在同一篇文章里也提醒过「眼睛也不能只盯着模型这一层」。可这次 Hy4 preview 发布上最抢眼的进度条依然全都写在模型层：770B 参数、1M 上下文、递归自我改进、缓存 20 倍价差；真正决定企业能不能拿到价值的那一层——交付审计——仍然被留给了用户自己。模型层的进展会继续用两月一次的节奏发生，但企业能不能真的从中拿到价值，取决于流程里有没有为「最后一公里」留出人力节点——采购单的最终数字校验、交付包的可移植验证、复盘文档的排版审校，这些活 Hy4 preview 还接不下来，也不必勉强它接。等到明年这个时候，Hy5 或者 Hy4 正式版可能会把这些盲区补上一大半；在那之前，「能干的研究员，但不是能签字的负责人」是这个模型最准确的坐标。