腾讯混元 Hy4 preview 开源实测笔记：770B 与 1M 上下文能干什么、怎么上手、怎么合规用

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

先给结论：Hy4 preview 是腾讯混元在 2026 年 8 月 28 日发布并开源的新一代旗舰模型，MoE 架构，总参数 770B、每个 token 激活 49B，原生上下文 1,048,576 tokens（约 1M），代码与权重按 Apache License 2.0 开放，可商用。它的能力重心不在闲聊，而在"长程干活"：跨文件代码修改、超长文档分析后直接产出交付物、三维与前端可视化原型。国内可以在 WorkBuddy、CodeBuddy、元宝、ima 里直接体验，也能走腾讯云 TokenHub 调 API。我自己连着跑了几天真实任务，最直观的感受是三句话：它在长任务里不容易跑偏，它比上一代更会"先归因再动手"，但它慢，而且慢得有点固执——官方自己都在仓库里写了"有过度自我验证的倾向"。

如果你只想拿一个决策：现阶段值得用真实任务去测，但不建议直接把它设成所有场景的默认模型。 需要快速吞吐、可自动校验的批量活儿，它的深度推理反而是成本；需要一次做对、失败代价高的复杂改动，它的谨慎才变成优势。

想看完整拆解，往下翻。下面我会把规格、原理、我的测试方法、三类任务的实际表现、短板、上手路径、自建部署要算的账、和其他国产旗舰的分工，以及境内发布内容时的合规要点，一条一条讲清楚。

一、先把这次发布的事实摆清楚

写测评最怕的事，是一上来就抒情。所以第一节我不谈体感，只摆事实——把能在官方渠道核对到的信息集中列一遍，后面所有判断都建立在这张表上。

1.1 一张规格表看完核心信息

这里要提醒一句：大模型的定价和限免政策变动非常快，上面是我写稿时查到的近似行情，实际请以腾讯云官方定价页面与产品公告的实时数据为准。

1.2 有几个数字容易被标题带跑偏

第一个是 770B。很多人看到这个数字的第一反应是"我本地肯定跑不动"，第二反应是"那它每次回答都要动用 7700 亿参数"。第二个反应是错的，第一个反应大体上没错，但理由和大家想的不一样，这个我放到第二节展开。

第二个是 参数总量的口径差异。开源平台的文件页面显示的体量会比官方口径大一点，原因是把内置的 MTP 投机解码层也算了进去（这一层本身总参数约 10B、激活约 0.7B），而官方说的 770B 指的是主干网络。知道这一点有个实际用处：你在不同渠道看到 770B 和 780B 两种写法时，不用怀疑自己看错了，它们只是把同一个模型的不同部分算进去了。

第三个是 preview。这不是一个营销后缀。腾讯在官方仓库里专门放了"已知限制"一栏，明确写了三件事：复杂任务上的推理时间有时会超过实际需要；模型有反复检查、过度验证自己工作的倾向；预训练与后训练都还有提升空间，所以先以 preview 形态收集真实反馈。一个厂商愿意把短板写进仓库首页，这件事本身就该被当成有效信息读，而不是当成谦辞跳过。

1.3 它被放在什么位置上

从今年 2 月混元重建基础设施算起，这条产品线大致保持着两个月一个大版本的迭代节奏，路径也很固定：preview 先行，收集反馈，正式版跟进。Hy4 preview 就是这条节奏上的最新一环。

同时你得知道它出现在一个什么样的窗口期。整个 8 月，国产开源旗舰扎堆：13 号 DeepSeek 把 V4-Pro 从预览版转正，14 号智谱发布 GLM-5.3（基座沿用上一代，全部提升来自后训练），再往前还有参数量更夸张的 Kimi K3。到 28 号腾讯交卷，几乎是把"每周都有新东西可测"这件事拉满了。

对我们这些天天用模型干活的人来说，这种密集发布有好有坏。好处是选择变多、价格被压下来；坏处是评测信息严重过载，各家都在放自己那张漂亮的柱状图。所以我这篇的重点不是复读跑分，而是回答一个更实际的问题：这玩意儿塞进我自己的工作流，到底顶不顶用。

二、读懂三个关键词，你才知道该拿它干什么

这一节稍微讲点原理。不是为了显得专业，而是因为——你要是不明白 MoE 和长上下文各自解决了什么问题，你就设计不出有意义的测试。 术语我都会用大白话先解释一遍，新手可以放心往下看。

2.1 MoE：把"全员上班"改成"按需点将"

先说什么是 MoE。混合专家（Mixture of Experts，简称 MoE）是一种模型结构，它把网络里负责"思考"的那一大块，拆成很多个小块，每块叫一个专家；每次处理一个词（token），只叫醒其中几个专家干活，其余的继续睡觉。

传统的稠密模型是另一个路子：不管你问什么，全部参数都要参与一次计算。这就像一家公司不管来什么活儿，全员到岗开会。

Hy4 preview 的结构大致是这样的：主干 78 层，第一层是普通的稠密前馈网络，剩下 77 层每层都带 256 个"路由专家"加 1 个"共享专家"；每处理一个 token，路由机制会挑出 8 个路由专家，再加上那个始终在岗的共享专家一起算。挑选的结果就是——总参数 770B，实际激活 49B。

一个 token 进来
      │
      ▼
┌─────────────────────────────┐
│ 路由（Router）：这个 token   │
│ 该交给哪几位专家？           │
└─────────────┬───────────────┘
              │ 选中 8 个
              ▼
  [专家 007] [专家 041] [专家 118] ... 
              +
      [共享专家（每次都在）]
              │
              ▼
        输出这一层的结果

用一句话概括这个设计的意义：总参数量决定这个模型"见过多少世面"，激活参数量决定它"算一个 token 花多少钱"。 MoE 让这两件事解耦了，于是模型规模可以继续往上堆，而单次推理成本不会跟着线性膨胀。

但这里有个特别容易踩的坑，我必须敲黑板："激活 49B"不等于"部署起来像个 49B 的模型"。 推理时你依然要把整套权重装进显存，还要留出 KV Cache 和并发资源。官方给的 vLLM 示例是 FP8 版本配 8 路张量并行——这就是实打实的多卡服务器起步。想私有化的朋友，请拿总参数算硬件，别拿激活参数算预算。这个坑我见过不止一个人踩，采购单都打出来了才发现机器不够。

2.2 注意力与长上下文：1M 到底难在哪

上下文长度，通俗说就是模型一次能"同时看住"的信息量。 1M tokens 大概是什么概念？一整套中型项目的代码仓库，一份几百页的研究报告，或者几十万字的资料合集——都能一次性喂进去，然后再让它开始动手。

问题在于，标准的注意力机制里，计算量会随着序列长度快速膨胀。序列拉到百万级，硬算是不现实的。所以做长上下文的模型，几乎都要在注意力上动刀子。

Hy4 preview 用的是一种带门控的稀疏注意力方案，核心思路是：不让每个位置都去看全部历史，而是通过索引先筛出"值得看的部分"，并且把这套稀疏索引在不同层之间复用，避免每一层都重新算一遍。 残差通路上则用了多路恒等连接的设计，让信息在深层网络里传得更稳。隐藏维度 6144，64 个注意力头，词表 120832——这些是官方配置里能查到的数字。

我知道这段对新手有点密。用一个比喻收一下：普通注意力像是每读一句话就把整本书重新翻一遍；稀疏注意力则是先做好索引卡片，读到哪一句就只翻相关的那几页，而且这套卡片全书通用，不用每章重做。

对使用者来说，你只需要记住一个实践结论：长上下文的价值不在"能塞进去多少字"，而在"塞进去之后还记不记得住"。 我测长文档任务时，从来不问它"这篇讲了什么"，而是专挑第 200 页的一个细节去问，看它会不会拿第 20 页的内容来糊弄我。这个方法后面还会再提。

2.3 两种推理模式：默认很能想，但你可以让它闭嘴直答

Hy4 preview 支持两种模式：默认的深度思考模式（high），以及直接回答模式（no_think）。走 API 的话，通过推理强度参数切换；官方推荐的采样参数是 temperature 0.9、top_p 1.0。

# 走 OpenAI 兼容接口的大致写法（示意，实际参数以官方文档为准）
resp = client.chat.completions.create(
    model="hy4-preview",
    messages=[{"role": "user", "content": "把这个函数的边界条件补全"}],
    extra_body={"reasoning_effort": "no_think"},  # 不想让它长考就传这个
    temperature=0.9,
    top_p=1.0,
)

这个开关比很多人以为的重要。 因为深度思考是有成本的，而且成本花在两个地方：一是时间，二是 token。对于"改一段有测试兜底的核心代码""排查一个跨模块的诡异缺陷"这类失败代价高的任务，多想几轮换来的成功率提升是划算的；但对于"把这两千条记录按规则分类""把这批文案统一改成一个格式"这种批量、可自动校验的活儿，长考只会变成延迟和账单。

我自己的做法是：同一批任务分两次跑，一次开长考一次不开，把结果和耗时都记下来，再决定这类任务以后走哪个档位。 这个习惯建议你也养成，比看任何榜单都管用。莫潇羽@源码七号站，这几天的测试记录我都是按这个格式存的。

三、我拿到一个新模型，是怎么设计测试的

看到这里你可能已经在想：说了半天原理，到底强不强？

别急。我先把方法讲清楚，因为测评这件事最大的坑，是拿别人的题目考自己的模型。 官方发布页那些基准图，能说明覆盖面，说明不了它在你的仓库里的成功率。所以每次有新模型出来，我都跑同一套自己的清单。

3.1 四笔账，比任何排行榜都接近真相

我评估一个模型能不能进工作流，只算四笔账：

这四项里最容易被忽略的是第三项。 很多人测模型只看最后结果对不对，不记中间被打断了几次。但真实工作里，一个需要你介入四次才能干完的任务，体验上等同于你自己干。

3.2 题目要脏，不要干净

我出题有三条自己的规矩：

第一，不给标准答案，也不给理想输入。 真实工作里的资料就是乱的：有错别字，有前后矛盾的需求，有失效的路径，有半截的日志。我会刻意把这些留在题面里，看模型是照单全收，还是会主动指出"这里两处口径对不上"。

第二，每类任务都要有一个"埋雷点"。 长文档任务里，我会在靠后的位置埋一个和前面结论矛盾的数据；代码任务里，我会留一个跨文件才能发现的根因。表面上都能答对，埋雷点才分得出高下。

第三，同一批题跨模型跑，跨版本存档。 我在本地建了一个很土的目录结构：

bench/
├── tasks/                 # 题目本体，一个任务一个文件夹
│   ├── longdoc-01/        # 长文档 + 交付物
│   ├── repo-fix-01/       # 老仓库缺陷修复
│   └── viz-01/            # 三维与前端可视化
├── runs/
│   ├── 2026-08-28_hy4preview_high/
│   ├── 2026-08-28_hy4preview_nothink/
│   └── 2026-08-14_other-model/
└── notes.md               # 四笔账的记录表

土是土了点，但它解决了一个真问题：半年后你还能回答"这一代到底比上一代强在哪"，而不是只剩一个模糊的印象。 我从去年开始存这个目录，现在回头翻，比任何评测文章都有说服力。

3.3 三类任务，对应三种能力边界

这次我给 Hy4 preview 安排的三类活儿，分别对着三种不同的能力：

• 超长文档读取后产出交付物：考的是长上下文的"记得住"，以及从一堆原始材料里重新组织表达结构的能力。
• 复杂代码仓库的集中缺陷修复：考的是跨文件的因果推理、改动的克制程度，以及会不会主动补验证。
• 三维与前端可视化原型：考的是它在没有视觉输入的情况下，能不能建立起一套自我检查画面的办法。

下面三节就按这三类展开。我尽量把过程写细，因为过程比结论有用——结论会随着版本失效，方法不会。

四、第一类任务：几百页的材料丢进去，能不能直接出成品

4.1 我出的题

我准备的是一份两百多页的英文学术材料，内容偏专业，结构松散，图表和正文交错。要求很直接：通读全文，先出一份中文的结构化梳理，再把它压成一套可以直接讲的演示文稿。

为什么用这道题？因为它同时踩中了三个难点。第一，材料超长，模型必须真的读完，而不是抓摘要糊弄；第二，读完之后要重新组织，不能照抄章节顺序；第三，从文字到演示是一次媒介转换，需要做减法。

在靠后的章节里，我埋了一个和引言部分结论略有出入的数据点。这是我的雷。

4.2 实际跑下来的观察

先说好的部分。

它确实是全文处理，不是只看开头。 我的判断依据不是它说自己读完了，而是那个埋雷点被主动提了出来——它在梳理里标注了两处口径不一致，并说明了自己采信哪一个、为什么。这一条如果没做到，后面所有表现我都不会认。

中间产物的质量也超出我预期。它没有直接跳到做演示，而是先出了一份万字量级的中文梳理，把材料重新拆成了几条主线。这个"先中间稿再成品"的顺序很关键——跳过中间稿直接做演示的模型，通常会做出一堆正确但没有重点的页面。

到了演示环节，它做了两件我比较认可的事：

一是做了减法。二十来页，每页只留一个明确的表达重点，不是把梳理稿切成片贴上去。

二是版式不套模板。它会根据这一页的内容性质换版式：时间推进的用时间线，对比的用表格，需要强调的用大字标题。整体视觉基调统一，但页与页之间不重复。

任务执行过程里，它自己拆出了十几个子任务并行处理，分别负责配图、编码、排版这些不同工种，中间没有出现断档或者上下文丢失。长程任务不断档，这是我这次最认可的一点。

4.3 也有必须泼的冷水

三个问题，我按严重程度排：

第一，数字要复核。 从长材料里搬运出来的具体数值，我抽查时发现过口径前后不一致的情况；更让人意外的是，简单的算术偶尔也会出错。这不是 Hy4 preview 独有的毛病，但一旦这些数字进了给别人看的演示稿，性质就变了。我的处理办法是：凡是交付物里的数字，一律要求它把出处页码一并标出来，我照着抽查。

第二，交付脚本里会出现写死的路径。 它生成的辅助脚本有时会把本机的绝对路径直接固化进去，换台机器就跑不了。发现之后我加了一句约束——"所有路径用相对路径或从配置读取"——就好多了。

第三，成品的最后一公里还是要人接。 版式、配色、结构它都能做到能用的水平，但涉及"这句话对外能不能这么说"的判断，还是得你自己过一遍。

4.4 这里有一条合规提醒，很多人会忽略

演示稿里那些配图，如果是模型生成的，你把它对外发布时是有标注义务的。

境内现行的《人工智能生成合成内容标识办法》与配套的强制性国家标准已于 2025 年 9 月 1 日起施行，明确要求 AI 生成合成内容要有显式标识和隐式标识：显式标识是用文字、声音、图形等方式呈现、用户能明显感知的；隐式标识是加在文件元数据里的。国内主流社交平台随后也上线了对应的声明入口和自动检测能力，创作者在发布时需要主动声明，并且不得删除、篡改、伪造或隐匿平台添加的标识。

落到实操上，我的习惯是三条：

• 用 AI 生成的图、音、视频，发布时老老实实在平台的声明入口勾上；
• 交付给客户的文件，在文档属性或者末页注明哪些部分由 AI 辅助生成；
• 涉及素材、字体、音乐、图片的商业使用，一律确认正版授权再用——AI 生成不等于自动获得商用授权，模板里预置的字体和素材更是重灾区。

这几条不难做，但漏了会很麻烦。莫潇羽写这段的时候特意去核了一遍现行文本，规则会动态调整，你发布前请以主管部门和平台的最新口径为准。

五、第二类任务：一个陈年老仓库，能不能集中修一批缺陷

这是我最看重的一类任务。原因很简单：写一个新项目，模型可以靠"生成能力"蒙混过关；修一个老项目，它必须真的理解已有代码之间的关系。

5.1 题面：一个积了灰的文件管理服务

我用的是一个维护了好几年的文件管理类服务端项目，规模不大不小——源码文件二十来个，另外附上了一批用户反馈汇总、一份已确认的缺陷清单，以及几个现有的回归测试。

缺陷清单里的问题是典型的"老项目综合征"：

• 有些已经删除的文件，通过旧的分享链接居然还能访问；
• 某些客户端上传的目录层级偶尔会错乱；
• 只读权限的用户竟然能改文件名；
• 文件删除或改名之后，用旧名称还能搜到。

这些问题单看都不复杂，但它们分散在权限、路径处理、搜索索引、目录树几个不同模块里，真正的难点是"归因"而不是"改代码"。

5.2 它的第一步动作，是我给高分的原因

我原本预期它会对着缺陷清单从上往下逐条改。它没有。

它先做了一次归因收敛，把十几条表面现象合并成了少数几个底层原因。 这个动作的价值，做过维护的人都懂：一条一条打补丁，最后代码里会长满互相打架的特判；找到共同根因，一处改动能连带解决好几个问题。

举两个我印象比较深的判断（细节我做了通用化处理）：

权限那条，它没去给"改文件名"这个接口单独加判断，而是回到统一的权限定义，发现只读角色被错误地归进了可写角色集合。把它从集合里摘出去之后，所有复用这套权限判断的写操作会一起受到约束。一处改动，覆盖一类问题——这是我判断模型有没有"工程感"的关键信号。

路径那条，根因是做路径分隔符替换时用了只替换第一处的写法，导致多层目录只规范化了第一段。它改成了全量规范化，并且在创建文件之前先做一次路径校验，遇到向上跳级的相对路径片段直接拒绝。

// 大致是这么个意思（示意代码，非原项目片段）

// 有问题的写法：replace 只换第一处
const bad = raw.replace('\\', '/');

// 修好之后：全量替换 + 规范化 + 越界拦截
function normalizePath(raw) {
  const unified = raw.split('\\').join('/');
  const parts = [];
  for (const seg of unified.split('/')) {
    if (seg === '' || seg === '.') continue;
    if (seg === '..') throw new Error('非法路径片段');
    parts.push(seg);
  }
  return parts.join('/');
}

顺手把越界片段一起拦掉，这一步不是缺陷清单要求的，但它做了。主动扩大安全边界，而不是只完成命题作文，这个我愿意加分。

5.3 跨模块问题：状态同步才是真考验

真正麻烦的是那几个跨模块的问题。

删除后还能搜到、改名后还能搜到旧名——这两条表面上是两个缺陷，根因是同一个：系统只更新了主数据的状态标记，没有同步维护搜索索引。 它的做法是把删除、恢复、改名三个动作都接进索引更新流程，同时在搜索服务侧额外过滤掉回收站里的条目，相当于加了第二道保险。

目录树那块，它补了祖先链检查，防止把一个文件夹拖进它自己的子目录里——这个操作会让整棵目录树变成无法访问的环，属于一旦出现就很难现场恢复的事故。

下面这张图是我理解它这次改动逻辑之后画的，方便你对着看：

graph TD
    A[十几条表面现象] --> B[归因收敛]
    B --> C1[权限定义:角色集合归类错误]
    B --> C2[路径处理:替换不完整]
    B --> C3[状态同步:主数据与索引脱节]
    B --> C4[目录结构:缺少环检测]
    C1 --> D[统一权限定义处修改]
    C2 --> D2[全量规范化 + 越界拦截]
    C3 --> D3[删除/恢复/改名接入索引更新]
    C3 --> D4[搜索侧二次过滤]
    C4 --> D5[写入前做祖先链检查]
    D --> E[补回归测试:逐条对应缺陷]
    D2 --> E
    D3 --> E
    D4 --> E
    D5 --> E

5.4 最后的分数与扣分项

整体改动落在不到十个生产代码文件里，另外新增了一份三百行量级的回归测试，缺陷清单上的每一条都有对应的验证用例。改动范围克制，没有为了修问题去推翻既有架构——这一点非常重要，很多模型一上手就想重构，那不是修 bug，那是制造新 bug。

我最终给了九十分出头。扣的那几分主要在这里：

• 失败回滚考虑得不够全面。 索引更新和主数据更新之间如果中途失败，会不会留下不一致的中间状态？它没有系统性地处理。
• 异常数据状态的兜底偏弱。 对于历史遗留的脏数据（比如早就存在的、路径本身就不规范的记录），它默认新逻辑生效即可，没有考虑迁移。
• 测试偏"证明修好了"，不够"证明没改坏"。 回归测试对着缺陷清单逐条验证很到位，但对既有功能的保护性测试偏少。

和上一代相比，最明显的进步是方向感。面对一个陌生的、分散在多个模块里的问题集合，它不容易跑偏，也不太会中途换思路。这在长任务里比单点能力重要得多。

六、第三类任务：没有眼睛的模型，怎么做出看得见的东西

这一类我一开始是抱着看热闹的心态测的，结果反而是让我最意外的。

6.1 题面：从一张平面示意图到可交互的三维页面

我给的输入很省：一张设备结构的平面示意图，一句话需求。 要求它复刻出一个可以在浏览器里直接操作的三维展示页面。

严格来说这不是一个"生成三维模型"的任务，而是一个"生成三维可视化产品"的任务。差别在哪？前者交出一个模型文件就完事；后者你得考虑视角控制、显示模式、结构剖切、构件管理这些交互问题。

它交出来的东西，包含十几个独立构件，三角面数量在三万级别，并且自动封装成了一个可交互页面：

• 旋转、平移、缩放，一键切换标准视图，可开启自动旋转展示；
• 沿三个坐标轴方向剖切，剖切位置可调，方向可翻转；
• 实体、线框、实体加边线三种显示模式切换，透明度可调，能直接看内部结构；
• 构件列表可以单独显示、隐藏、反选；
• 还做了爆炸视图，拖动滑杆把各组件沿装配方向分离开来看连接关系。

上面这些数字我按量级做了模糊化处理，因为同一句提示词跑两次，构件数和面数都会有出入，写死一个精确值反而误导人。你自己去测，量级对得上就说明能力在。

6.2 更值得说的是"翻车之后"

我还测了另一个偏设计的题目：一个特定复古风格的室内场景，外加一个可以增删和调整场景内物品的控制面板。

第一次直接翻车了。 它把那个风格理解成了单一色调铺满整个空间，出来的画面平得像一张色卡。

我没有直接告诉它答案，只补了一句约束：这个颜色应该是点缀而不是主色；如果你不确定这种风格具体长什么样，可以先去查参考资料再动手。

接下来发生的事情才是重点。它没有简单地把颜色调淡了事，而是先去检索了这类风格的视觉资料，重新理解了它的配色逻辑和材质构成，然后才重做。 第二版用深色基底托住高饱和的点缀色，加入了金属质感、几何图案和有年代特征的装饰元素，画面立刻有了层次。整个场景里塞了四十来件可操作物品，空间很满，但没有明显的悬浮和穿模，摆放时还带了缩放动画。

6.3 一个"没有眼睛"的模型，是怎么知道自己画歪了的

这才是这个案例里最有意思的部分。

它是纯文本模型，输入输出都是文本，它看不见自己生成的画面。 那它凭什么判断第一版不好看？

答案是：它自己造了一套观察手段。 它写了一个软件渲染器把场景光栅化成图，再借助工具去查看和判断，相当于给自己接了一副临时的眼睛。

我为什么反复强调这一点？因为"能力上限"和"会不会工作"是两码事。

• 第一次生成的质量，考的是能力上限；
• 翻车之后能不能建立起验证闭环，考的是它会不会工作。

后者才是 Agent 能不能被信任的分水岭。一个只有上限、没有自检回路的模型，你永远得盯着它；一个会自己找办法验证结果的模型，你才敢把任务丢过去然后去干别的。

6.4 顺带聊聊"它参与了自己的研发"

这次发布里有个说法传播得很广：Hy4 preview 参与了自身研发链路的优化——在训练方法、数据策略、评估体系和底层算子这些方向上，由模型提出方案、跑实验，再把代码、日志和结果带回下一轮迭代；官方还提到它会分析推理系统的瓶颈，在算子融合、通信优化等方向上做迭代，端到端吞吐相对基线有三成左右的提升。

这句话不要理解成"模型已经在自己训练自己了"。 准确的说法是：它进入了一个由人设计边界、可运行实验、有反馈回流的研发循环。目标定义、环境控制、评价标准，依然是研发团队搭好的。

但这个方向的价值我是认的，而且和上面那个"自己造眼睛"的案例是同一件事的两个尺度：它在把 Agent 从"写一次代码"推向"持续做实验并对结果负责"。 这个转变一旦稳定下来，比参数量从 700B 涨到 1000B 有意义得多。

七、必须讲清楚的短板：它慢，而且慢得有点固执

夸完了得说问题。这一节我写得会比较狠，因为测评文章里最没价值的就是"整体不错，期待正式版"这种和稀泥。

7.1 慢是结构性的，不是偶发的

复杂任务丢进去，往往要等上一阵才有完整结果。这个"慢"分成两部分，性质完全不同：

第一部分是模型自己在长考。 这是设计使然。默认的深度推理模式会让它反复推演、反复验证，官方在已知限制里写得很直白：复杂任务上的推理时间有时超过实际需要，并且有过度自我验证的倾向。

第二部分是排队。 这波上线太火了。据平台侧的说明，Hy4 preview 首发当天调用量大幅攀升，任务队列就出现了排队；随后项目团队紧急扩容了推理集群，并表示会持续动态调配资源，但也坦白提示——受限于高端算力总量和高峰时段的并发集中，个别时段仍可能继续排队。

把这两件事分开看很重要。扩容能解决第二部分，解决不了第一部分。 你以后哪怕在最空的时段用，它该想多久还是想多久。

7.2 "更会检查"什么时候是好事，什么时候是坏事

这句话我想单