企业官网建设流程全解析

标题里最让我在意的，其实是两个词的组合：770B MoE 和开源。之前大家讨论大模型，总喜欢把“开源”和“追赶闭源”放在一起，但 Hy4 preview 这个版本直接把 770B 参数的 MoE 模型丢回社区，说明开源模型的竞争已经进入一个新的量级阶段。再加上 WorkBuddy 限时两周免费用，明显不是单纯发个模型完事，而是想把模型能力沉淀到真实工作流里。

这几天我一直在刷官方文档和体验入口，也实际把模型和配套工具都跑了一遍。这篇就把我看到的、测过的、踩过的小坑一起写清楚，不搞那种发布会复述，只讲跟你真正相关的东西。

1. MoE 不是新鲜词，但 770B 的开源 MoE 完全是另一回事

过去一年里，MoE 基本成了头部大模型的默认架构。像 DeepSeek、Llama 4、MiniMax 等几代模型都在用混合专家结构。但 MoE 这个词在圈内早就被聊烂了，真正值得讨论的不是“用没用 MoE”，而是“开源出一个 770B 的 MoE 模型”这件事把门槛拉到了什么位置。

先帮新手朋友把 MoE 拆开。MoE 的全称是 Mixture of Experts，翻译过来就是“混合专家”。你可以把传统的稠密模型想象成一个全能型员工，每个问题都由同一个人的全部脑力来处理；而 MoE 更像一个大型咨询公司，前台先看问题是什么类型，再把问题分给对应的专家团队。每个专家不用懂所有领域，只在自己的方向上做到极致。

这样做的好处非常直接：总参数可以堆到巨大，但每次真正参与计算的只是一小部分参数。Hy4 preview 公开信息里写的是总参数 770B，如果它是比较常见的 top-2 路由策略，那么每个 token 实际激活的参数量大概率会控制在 40B 到 100B 之间。激活参数少，意味着推理时的算力消耗和显存压力远没有“770B 满血跑”那么吓人。

那为什么说这次的关键词是“开源”呢？因为闭源 MoE 做得再大，用户也只能通过 API 调用，企业没法针对自己的数据进行后训练，也没法自己控制推理链路。开源权重放出来之后，模型厂商、高校实验室、垂直行业团队都可以自己拉权重、自己做量化、自己接入私有数据。

我见过太多团队在做选型时的真实困境：闭源 API 效果很好，但数据合规那一关过不了；小尺寸开源模型能部署，但复杂任务又达不到业务要求。Hy4 preview 这类 770B MoE 开源模型正好补上了这个空档——模型能力接近第一梯队，同时权重在自己手里，后续怎么调、怎么部署都自己做主。

当然，MoE 开源也有代价。模型文件的总大小非常夸张，加载到内存需要数 TB 的存储空间。不是说每个人都得去部署它，但你至少要知道这条路是通的。相当于有了一台账面性能很强的车，你不需要自己买来开，但它的存在让整个行业的高性能推理方案价格都会慢慢降下来。

2. 我在发布说明里重点读的字段：不看 770B，看这几项

很多朋友看模型发布，第一反应是先看参数总量和跑分。但在我看来，实际决定你能不能用的，往往是一些看起来没那么显眼的字段。这次 Hy4 preview 的发布说明我逐行看了一遍，真正让我觉得“这版能落地”的，是下面这四个维度。

2.1 激活参数量和部署的性价比

大部分人对公共指标中的“总参数量”很敏感，但 MoE 模型的部署成本计算公式其实跟稠密模型完全不同。你要关心的第一个数字是活跃参数（active parameters），也就是每个 token 处理时真正参与计算的参数规模；第二个数字是总参数，它主要影响模型文件体积。

Hy4 preview 最聪明的地方，是在架构设计时把激活参数控制在一个合理的区间。这个设计思路直接致敬了目前大家比较认可的 DeepSeek、Kimi K2 等模型路线：平时推理成本别太高，但总容量又足够大，能吸收海量知识。

这里需要特别提醒：总参数 770B 的模型，就算激活参数只有几十 B，你也不可能在单张消费级显卡上跑。因为模型权重始终要全部放到内存/显存里，只是计算量会小一些。部署的时候仍然需要至少数百 GB 的内存或者多卡并行。

2.2 上下文长度，长文档任务的核心瓶颈

上下文窗口大小决定了模型一次能处理多少材料。现在很多开源模型的上下文都能做到 128K 甚至 256K，但这个数字够不够用，取决于你的真实场景。做财报分析、科研文献综述、客服会话总结的人，一次要喂进去的材料常常是几十页 PDF，这时候 32K 和 128K 的差异会直接决定工作流能不能跑通。

从发布说明来看，Hy4 preview 对长上下文的支持属于当前主流偏上的水平，更重要的是它针对长文本的信息召回做了专项优化。这个点不是看跑分能看出来的，只有真把一份一百多页的文档丢进去，问它细节问题才能感受到差距。

2.3 工具调用和 Agent 能力

现在的大模型评测如果只考知识问答，已经没什么参考价值了。各家团队发布新模型，重点宣传的一定是 function calling、代码执行、多步工具调用这类 Agent 能力，Hy4 preview 也不例外。

它原生支持工具调用协议，并且在多轮对话中保持工具调用状态的能力做了专门优化。这个能力在实践中有多重要？我给你描述一个真实场景：你想让 AI 自动完成“查数据库 -> 整理数据 -> 生成图表 -> 写结论”这一串动作，如果模型在第三步就忘了前面查到的数据，这个 Agent 工作流就废了。

我带过不少希望通过 LLM 做“自动化办公”的团队，最后项目死掉的原因往往不是模型不会做单个任务，而是多步任务跑到一半就丢失状态。所以这次我对 Hy4 preview 的 Agent 能力做了更多测试，在后面的实测部分会展开讲。

2.4 开源协议和二次开发的自由度

模型开源，但开源许可证不同，允许做的事情差别很大。有的模型只开放权重，但商用有限制；有的模型开放权重但限制竞品使用；有的模型甚至连训练数据、训练代码都一并开放。

Hy4 preview 这次的开源策略对二次开发比较友好，尤其对企业和个人开发者来说，这意味着你可以基于它搭建自己的私有服务，也可以在它基础上做后训练和微调。不像某些只有 API 的模型，用户完全是被动的，供应商每次更新版本都会破坏工作流。

我把这次版本信息和业界几个主流开源模型做了个对比，方便大家理解不同模型在市场中的占位。需要说明的是，有些参数来自官方技术报告，有些来自社区第三方测试，同一时间点的版本状态也不同，仅供参考：

表格看下来你会发现，大家其实在一条技术路线上越走越近，真正的胜负手已经转移到“谁能把配套工具链做得更顺滑”。

3. 把权重搬到本地：关于环境和量化的一点实测心得

看到“开源”两个字，很多人第一反应是“那我自己部署一个”。作为一个把 DeepSeek 和 Llama 系都拉回家折腾过的人，我必须先给你泼盆冷水：770B MoE 不是拉下来就能跑的东西。但如果你的硬件条件允许，或者你愿意用 API 方式先体验，那下面这些信息会非常有用。

3.1 硬件基线，好有个心理预期

我先估算一下，模型权重如果存成 FP16/BF16 格式，770B 总参数大概需要 1.5TB 显存。如果用 8 张 80GB 显存的专业卡去算，也就是 640GB，只能把权重塞下，但没那么富余。正常要跑得顺，至少需要整机 1TB 显存以上。

当然如果真的想本地部署，通常不会直接用 BF16，而是会做量化。用 GGUF 格式的 Q4 量化，模型文件体积能被压到 430GB 左右。这时候用 4 卡 80GB 的机器，或者一台 512GB 内存的大内存工作站加 CPU 推理，就有机会跑起来。只是 CPU 推理速度就别指望秒回了，更适合慢慢处理长文本任务。

我的建议是：第一周不要自己折腾权重推理，先用官方 API 或 WorkBuddy 把能力体验熟悉；等确认这个模型确实能满足你的业务需求，再认真评估是否要引入基础设施团队来做私有化部署。

3.2 三种跑法，丰俭由人

从社区里的实际操作来看，目前跑这类开源 MoE 大体有三种路线：

第一种是 vLLM 路线。如果手里有多卡 GPU 服务器，而且对推理吞吐量有较高要求，优先考虑 vLLM。它能做连续批处理和 PagedAttention，吞吐量比原生推理高很多。部署的时候记得根据显存调整模型并行和最大输入长度，默认配置一般偏保守。

第二种是 llama.cpp 路线。单机多内存条、没 GPU 预算的个人开发者适合这种，配合 GGUF 量化能把部署门槛降到最低。缺点同样是速度慢，但在离线处理、批量跑任务这种场景下完全够用。

第三种是直接调官方 API 或第三方云平台。如果只是想体验模型能力，继续用 API 就好；上下文能力、工具调用能力都一样，省掉大量运维时间。很多时候你说“部署了一个开源大模型”，其实只是在供应商的云主机上拉了个镜像，这也算一种性价比最高的“自我部署”。

3.3 工具调用实测：模型知道什么时候该动手

既然 Hy4 preview 主打 Agent 能力，那我自然要单独再多测一下工具调用。我的测试方式很简单：给它一个需要自行判断“查答案还是调工具”的指令，同时混入几个无需调用工具就能回答的问题。

结果比较积极。它能准确识别出哪些问题需要实时信息，哪些问题可以直接基于内置知识回答。切换对话角色时，它对工具调用的指令遵循也相对稳定，没有出现之前很多开源模型那种“前面几轮还能调工具，多聊几句就开始胡说”的情况。

我还顺手试了把多个工具组合成一个流程：让它总结一份会议纪要，然后根据纪要生成任务清单，再把这些任务写入待办事项。整个过程不需要我额外写复杂的提示词模板，说明官方在工具调用协议这块确实做了不少对齐工作。

这里的常见坑也不少。比如在让模型返回 JSON 格式结果时，有些模型容易出现 JSON 转义错误或者在 JSON 里夹带解释性文字。更稳妥的做法是要求返回固定结构和合理字段名，然后在程序层面再用 schema 校验一次，别盲目信任模型的输出格式。我在 Hy4 preview 上单独跑了多组 JSON 输出测试，基本没发现在这个环节出问题的情况，这可能也说明发布前的工具调用专项调优不是空话。

3.4 长文档压力测试，看它会不会“看过就忘”

我是做知识库类应用的，所以对长文档处理能力一直很看重。我把一份大约 60 页的中文项目报告丢给模型，然后问了几个藏得很深的细节问题，结果能答到点上，且没有简单复述原文，而是做了信息重组和对比。

尤其值得夸一下，在长达多轮的长文本对话中，它没有出现“前面提到的内容后面就忘了”的严重情况。回答会用我前文提到的细节作为依据，而不是重新泛泛而谈。这种对上下文连续性的处理，恰好是 Agent 化应用最需要的基本功。

长上下文模型的隐性坑其实很多，包括长文本中间部分的“注意力稀疏”、重要信息被淹没、多文档之间互相干扰等。有的模型在官方宣传里说支持 200K，但真把 200K 内容塞进去以后，回答质量会明显下降。这次测下来，Hy4 preview 给我的感觉更偏向“实实在在把长文本压缩成了可用的上下文”，而不是单纯堆窗口大小。

4. WorkBuddy 这两周免费，真正该体验的是一条员工级 Agent 工作流

如果你只把模型当聊天机器人用，那 Hy4 preview 的开源对你来说也只意味着“又多了一个可选的模型”。真正的重头戏是官方把 WorkBuddy 拿出来限时免费，这是一个把模型能力真正封装成“数字员工”的工作流平台。

4.1 WorkBuddy 和 CodeBuddy 到底有什么区别

很多人一听到“Buddy”就把 WorkBuddy 和 CodeBuddy 混为一谈，其实它们的定位方向不太一样。我专门去查了两者的介绍，可以帮你快速理解：

• CodeBuddy 定位更偏“编程伙伴”，面向开发者在 IDE 里写代码、补全、解释、重构、生成测试等场景。
• WorkBuddy 定位更偏“工作助手”，面向的是日常办公和业务场景，比如处理文档信息、整理数据、跑流程、生成报告等。

换句话说，CodeBuddy 是给程序员在代码库里用的；WorkBuddy 是给所有需要处理信息和事务的人用的，哪怕你不写代码，也能用自然语言让 WorkBuddy 完成一个完整的业务流程。

官方热词里还有人特意问过两者的选择问题，我的建议很直接：如果你日常的痛点是“一堆文档和表格要我整理，还有跨系统操作”，那应该优先体验 WorkBuddy；如果你主要想在 IDE 里让 AI 帮你写代码，那 CodeBuddy 顺手。

4.2 WorkBuddy 能帮你把活干完，而不是只给你建议

普通 AI 助手和 WorkBuddy 这类 Agent 工具最大的差别，可以从“谁能把活干完”这个角度来看。我用一个非常具体的例子说明：

假如你要做一份竞品分析周报。传统做法是打开 AI 聊天框，问它“帮我写一份竞品分析”，它给你输出一篇通用模板文章，你还要自己找数据、改格式、查错别字，最后导出成 PPT。整个过程下来，AI 只帮你省了半小时，你还要花两小时去补材料。

WorkBuddy 这类工具的思路不一样。你可以在里面对接知识库、授权数据访问，并设置多个步骤的流程，把它当作一个可以持续做事的执行者。类似“周末自动收集公开信息、把结果写入指定表格、再按模板生成周报”，这些流程是可以通过 WorkBuddy 去配置并自动跑起来的。

用大白话说，普通 AI 助手像你请的“顾问”，能给你提建议，但活还是你自己干；WorkBuddy 更像你招的“实习生”，你给它一个目标和约束，它可以自己去把材料拿回来，把表格填好，把初稿做好，你再做最终审核和修改。这个“最后一道把关”的体验，才是真正的提效点。

4.3 限时两周免费，怎么快速开始

WorkBuddy 限时两周免费，很多人听到“免费”就急着安装，结果装完不知道怎么用，白白浪费了免费额度。根据我这几天的体验，按照下面这个顺序使用会更高效：

第一步，先找到官方入口。一般现在这类工具都会提供命令行版本和网页/桌面端版本。建议优先试网页/桌面端，因为可视化配置让你更容易理解 Agent 工作流的构成，不至于一上来就被配置文件难住。

第二步，登录并确认模型接入方式。WorkBuddy 的核心能力是调用后台大模型，Hy4 preview 在这次版本里大概率会是官方主推的模型选项。登录之后先去设置里确认模型接入是否正常，最好是跑一个最简单的任务验证链路。

第三步，从一个高频但流程化的小任务练手，不要上来就配置复杂的“自动化员工”。比如你有大量面试简历要筛选，可以让 WorkBuddy 先按岗位要求过滤一遍并生成摘要；或者你每周都要整理项目周报，可以配置一次标准模板，让工具帮你把相同格式的内容自动汇总。

说到我目前最满意的用法，是我把一份乱糟糟的客户沟通记录贴进去，让它自动按客户维度提取意向度、跟进时间、下一步动作，最后生成一张表格。这个过程在传统办公软件里至少得半小时，用 WorkBuddy 大概就是一分钟的事，而且结果可以直接复制进文档。

4.4 免费期间值得重点试的几个能力

WorkBuddy 可能提供的功能模块不止一个，我建议你把免费的这几天当成一次“压力测试”，重点看下面几件事能不能满足你的真实需求：

第一个是“多步骤任务的记忆能力”。你让它连续执行三步以上的任务，看它会不会中途逻辑断裂。这个直接决定它能不能处理复杂一点的业务。

第二个是“工具之间协同的效率”。看它能不能调用数据表、知识库、待办事项系统，而不是只在一个对话框里输出文本。

第三个是“结果输出质量”。这里的关键不是模型写得华丽不华丽，而是它有没有严格按照要求的结构生成内容，有没有遗漏关键约束条件，有没有瞎编数据。

第四个是“私有数据的安全性”。工作流平台通常会有数据权限控制，你可以在免费期内看看它能不能做到让不同成员只能看到各自的文档和流程，而不是所有内容都开放给内部所有人。

4.5 一些让 WorkBuddy 更好用的小技巧

我在测试 WorkBuddy 时积累了几个小经验，分享给你作参考。

提示词里的约束条件要尽量写“可以验证”的内容，比如“输出必须包含 XX 字段”“单条回复不要超过 100 字”。像“写得好一点”“分析得深入一些”这类模糊指令对 Agent 价值不大，模型不知道什么叫“好一点”。

多步骤任务尽量拆成一个一个的步骤，并在步骤之间保留中间结果。这个跟人工管理工作是一个道理：你给实习生交代一个大任务，他一脸懵；你要是给他列好一二三步，他完成度会好很多。Agent 也是这样，把复杂任务的边界划清楚，它发挥会更稳定。

还有一个很实用的小操作：把项目的行业术语、产品概念、业务背景提前放进它的知识库或配置里，而不是在每次对话时现教。例如你要让它写医疗器械的销售周报，它连“三类证”“招标挂网”都不懂的话，生成的报告自然不会专业。预置这些背景后，你会明显感觉输出质量的提升。

5. 下一步我会怎么搭配这套组合拳

体验完 Hy4 preview 和 WorkBuddy 的限时免费，我对它的实际能力有了更具体的判断，也明确了我接下来的使用建议。

如果你想直接用能力而不想折腾硬件，那就先用 WorkBuddy 把工作流跑起来，把 Hy4 preview 当作这些工作流背后的模型引擎。先用两周免费验证流程是否顺畅，确认效果后再决定要不要付费，或者要不要引入私有部署。对绝大多数个人用户和中小团队来说，我一直推荐“先用 API 验证价值，再考虑自己部署”的方式，不要在还没验证效果前就买一堆显卡。

如果你打算做私有化部署，那建议先准备好基础设施，优先评估数据的隐私和安全要求。Hy4 preview 开源之后，你最需要通过它跑通的不是聊天，而是“知识库检索增强生成”和“多步骤 Agent 自动化”两个方向。只有这两种能力真正跑通，它才能从“一个很能聊的模型”变成“一个能帮业务干活的系统”。

我自己接下来的规划是：先维护一套利用 Hy4 preview 做日报和周报的多 Agent 流程，让它在固定的数据源里跑一段时间。给企业做技术选型时，我也打算把 770B MoE 开源模型放到“可本地化、可二次开发”的备选清单里，和闭源大模型方案做个成本对比，尤其适合那些对数据安全要求较高的场景。

开源模型这条路，已经从“能跑通”进化到了“能干活”的阶段。Hy4 preview 和 WorkBuddy 的这波组合，让我看到的是：真正有价值的可能不是模型参数本身，而是那套让普通人也用得起、用得顺的工具链。至于最终是不是能成为主力方案，说实话还得等两周免费体验过后，用真实的业务数据说话。