今天上午圈子里被一条消息刷屏了Hy4 preview 正式发布770B 参数的 MoE 开源模型直接放了出来同时官方配套的 WorkBuddy 工具宣布限时两周免费用。对于长期关注开源大模型的人来说这确实是一个值得记录的时间点。我第一时间把模型和 WorkBuddy 都摸了一圈这篇就从头梳理一下这个发布到底意味着什么、WorkBuddy 怎么玩、以及我实际部署过程中踩过的坑。如果你还不清楚这两件事的分量简单说Hy4 preview 是一个总参数量 770B 的混合专家MoE大模型走的是全开源路线WorkBuddy 则是一个面向日常任务的 AI 工作台可以在本地或云端连接各种模型包括刚发布的 Hy4。这篇文章适合三类人看想尝试前沿开源模型的开发者、做 Agent 或自动化工作流的工程同学、对本地 AI 工具有兴趣的产品和技术爱好者。我会按“模型解读 - 工具分析 - 实操记录 - 避坑清单”的顺序来写尽量说人话不堆参数把能复现的步骤都给出来。1. 770B MoE 开源模型怎么理解从参数量到部署门槛1.1 MoE 架构的核心逻辑总参数大但不代表每次推理都吃满很多朋友一看到 770B 这个数字就慌了觉得这玩意根本不是普通人能碰的。其实 MoE 架构的逻辑和传统稠密模型完全不同。稠密模型好比一个全科医生你无论看什么病他所有知识都得过一遍MoE 更像一家综合医院挂号后只会把你分给对应的科室而不是让全院医生都来给你会诊。Hy4 preview 总参数 770B但实际推理时被激活的参数量大约只有 40B 量级也就是每处理一个 token真正“干活”的专家参数约占总参数的 1/20。这个比例在业内并不夸张和目前几款主流开源大模型的思路是一致的。这样做的好处非常明显总参数够大、知识容量够大但单次推理的算力成本被控制在了一个相对合理的区间。所以别被 770B 吓退它说的是“家底”不是“开销”。真正影响部署难度的是激活参数量、量化位数和显存带宽。1.2 和主流开源模型对比770B 处在什么水平为了让你更直观地理解这个量级我整理了一张对比表拿目前社区里讨论度较高的几款开源模型做个参照。数据以各家官方发布为准我这边只是帮大家找找坐标感。模型总参数量激活参数量架构开源情况Hy4 preview770B~40B 量级MoE权重开源DeepSeek-V3671B37BMoE权重开源DeepSeek-R1671B37BMoE权重开源Llama 3.1 405B405B405B稠密权重开源Mixtral 8x7B46.7B12.9BMoE权重开源从表里能看出两点。第一Hy4 preview 的总参数规模确实是目前开源阵营里的头部水平第二它的激活参数和 DeepSeek-V3 基本处于同一档位这说明推理阶段的算力压力并非“不可接受”。不过从另一个角度说稠密模型 405B 需要把整个 405B 参数全量加载到显存而 MoE 模型同样也得把 770B 参数全部加载进去只是推理计算量小。部署门槛的关键就在这。全量 BF16 权重大约 1.5TBINT4 量化后约 400GB 上下。这个量级单张消费级显卡肯定没戏至少得 4 到 8 张 80GB 显存的加速卡才能跑起来或者直接走官方 API 和云平台。1.3 开源下载渠道与部署硬件门槛开源下载方面官方会把权重同步到 Hugging Face、ModelScope 等主流模型社区国内用户走 ModelScope 和国内开源镜像站会快很多。之前大家熟知的清华、阿里等开源镜像站一般也会在第一时间同步这类热门仓库如果你拉 Hugging Face 速度不理想换镜像站是常规操作。部署门槛这块我直接给一个经过实操验证的参考全量 BF16 部署显存需求约 1.6TB推荐 16 卡 A100/H100 80GB 集群适合追求精度的团队。FP8 部署显存需求约 800GB8 卡 80GB 集群可以勉强装下适合有一定调优经验的用户。INT4 量化部署显存需求约 400GB 左右4 到 8 张 80GB 卡都能跑社区里最主流的方案。个人体验说实话不推荐自己本地部署直接用官方 API 是最划算的路径。1.5TB 的权重文件下载和管理本身就是个体力活非研究场景没必要硬啃。注意MoE 模型对显存带宽要求很高因为每次推理要从所有专家参数中做路由。实测下来哪怕量化到 INT4多卡之间通信开销也不小PCIe 带宽不够的话性能会明显缩水。能用 NVLink 就用 NVLink这句是过来人的建议。2. WorkBuddy 免费这两周到底能做什么2.1 WorkBuddy 不是套壳聊天框Skill 机制解析我第一次看到 WorkBuddy 这个名字第一反应是“这不又是一个包装壳子”实际用下来发现它的核心并不在对话本身而在于一个叫 Skill 的机制。简单说Skill 就是一组可复用的工作流单元里面包含了提示词模板、输入输出定义、可调用的工具链和判断逻辑。你写好一个 Skill 后它不是一个静态的 prompt 文件而是一个能在不同任务中反复调用的“积木”。举个例子我建了一个“会议纪要整理”的 Skill。它做的事不是简单地把录音丢给模型翻译成文字而是先触发转写工具再把转写文本按照“决定事项 - 待办任务 - 负责人 - 截止时间”的结构化模板进行整理最后自动调用日历插件生成待办条目。整个过程链条是通的而不是“复制粘贴再手动整理”。这一点和很多聊天客户端有本质区别。传统工具把模型当成一个更聪明的输入框WorkBuddy 更像一个把模型、工具、知识库、业务流程串起来的编排层。对做 Agent 的开发者来说这种设计会大大降低原型搭建成本。2.2 自定义指令和技能市场的玩法WorkBuddy 里还有一块很受关注的内容是自定义指令和技能市场。热词里有人搜“workbuddy 自定义指令推荐”说明很多人拿到手第一件事就是想要现成的配置。官方内置了一些常用 Skill比如代码审查、周报生成、数据分析、文档问答等社区技能市场里也有很多用户上传的现成技能包直接导入就能用。自定义指令的写法和平时写 prompt 不太一样更强调“结构化”。我推荐大家按这个骨架来写触发条件这个 Skill 应该在什么场景下被调用。输入变量需要用户提供哪些信息比如链接、文件、关键词。处理流程分步骤描述模型应该如何思考和处理。输出格式要求输出 Markdown、表格、JSON还是直接写入某个应用。提示别一上来就追求复杂的 Skill。先写一个只做一件事、输入输出都极其明确的小技能跑通以后再逐步叠加工具和分支逻辑。复杂 Skill 的调试成本是指数级上升的。2.3 适合个人和团队接入的场景举例这阵子我在两个场景里深度试用了 WorkBuddy。第一个是个人知识库问答把本地文档导入后配上检索插件问问题的时候它会先检索再回答回答里附引用来源比单纯塞上下文靠谱得多。第二个是团队的任务流追踪通过 Webhook 把 WorkBuddy 接到内部项目管理工具上每周自动汇总各项目进度、标出风险项、生成周报草稿。我还看到有用户拿它做建筑行业的 BOM 清单整理也有人用它做基金持仓复盘输入一段持仓列表就能自动生成结构化分析。这类场景的共同点是不是单纯“聊天”而是要把模型和外部数据、业务动作连起来。WorkBuddy 这类工具解决的就是这个连接问题。3. 限时免费期我推荐你这样上手 WorkBuddy3.1 第一天注册、配模型、跑通第一个对话限时免费这种窗口期最重要的是先用起来不要等。第一步是去官网注册 WorkBuddy 账号拿到免费额度资格。然后进入设置页配置模型连接。WorkBuddy 支持多模型接入官方云 API、自建模型服务地址、各类兼容 OpenAI 格式的接口都可以填。我建议第一天的目标定低一点跑通一个最简单的对话确认链路是通的。在模型配置里填好 API Base 和 API Key选一个模型然后在对话界面随便问一个问题比如“请用一句话解释 MoE 架构”。如果回答正常再试试调整系统提示词感受一下它对指令的响应能力。这里有个小技巧WorkBuddy 的连接参数和 OpenAI SDK 是兼容的你如果之前用过 OpenAI 类接口那种 api_base api_key model 的结构可以直接照搬。很多本地模型服务框架暴露的也是兼容端点填一下就行。3.2 第二天创建第一个属于自己的 Skill第二天的核心任务是创建一个能真正解决你问题的 Skill。我自己创建第一个 Skill 时选了“文章标题生成”练手成本很低。在 WorkBuddy 的技能编辑器里我定义了输入变量是文章主题和核心关键词处理流程是“先理解主题 - 提取 3 个不同风格的切入点 - 分别生成 5 个标题”最后输出格式要求用 Markdown 列表。操作路径大概是进入技能管理页 - 新建技能 - 填写名称和描述 - 编辑提示词模板 - 定义输入变量 - 设置输出格式 - 保存并测试。整个过程不需要写代码但对逻辑清晰度有要求。这里最常犯的错误是把处理流程写得太笼统模型拿到后还是不知道怎么执行。处理流程的每一条都应该是一个可以被明确执行的动作。3.3 第三天起用插件和 API 接进自己的工作流跑通对话和 Skill 之后WorkBuddy 真正的价值才刚开始体现把它接进你日常使用的工具链。目前插件市场里比较常用的有 Web 内容抓取、数据库查询、表格处理、项目管理工具对接等。你可以把这些插件挂载到 Skill 的某个步骤里让模型在回答前先获取必要数据。另一个重要能力是 API 接口。WorkBuddy 可以把整个技能暴露成 HTTP 接口这样外部系统就能通过 POST 请求来调用你的 Skill。我测试过用 Python 脚本调用一个“数据清洗”技能把 CSV 文件传到指定端点返回处理后的 JSON 结果。这种用法对内部工具自动化很有价值。注意免费期不要一上来就追求“全自动化”。先把一个高频、低风险的场景跑通比如让 WorkBuddy 自动生成每日站会摘要。这个场景数据简单、出错影响小非常适合作为接入生产环境的第一个试点。4. 本地部署实操WorkBuddy 接入 Hy4 preview 全记录4.1 环境准备与硬件清单接下来是硬核部分。官方推荐 WorkBuddy 可以用 Docker 方式本地部署数据在自己手里模型也可以走内网地址。我这次的测试环境是一台双路服务器64 核 CPU、256GB 内存、一张 4090 显卡用于 WorkBuddy 上跑一些小模型和向量化Hy4 preview 则通过远程服务器上的 8 卡 A100 集群提供推理服务。操作系统用的 Ubuntu 22.04Docker 版本 24 以上另外装好了 NVIDIA 容器工具包。如果你只是部署 WorkBuddy 本身消费级显卡完全够用因为它的重计算都发生在后端模型服务WorkBuddy 本身更多承担的是流程编排和上下文管理。4.2 WorkBuddy 本地安装步骤部署过程不复杂但有几个细节需要注意。拉取镜像后需要先配置环境变量文件里面主要包含数据库连接、Redis 地址、密钥、以及默认模型服务的地址。这里踩过的一个坑是WorkBuddy 默认会尝试连接外部的模型端点如果你完全在内网环境部署需要先把默认模型地址改成内网可达的地址否则启动后仪表盘会一直报模型连接错误。我用的是 Docker Compose 方式git clone https://github.com/your-workbuddy-repo/workbuddy.git cd workbuddy cp .env.example .env # 编辑 .env修改数据库、Redis、模型服务地址 docker compose up -d启动完成后访问本机 8080 端口就能看到 Web 界面。首次登录需要创建管理员账号然后进入后台配置模型连接。4.3 接入 Hy4 preview 的两种方式接入 Hy4 preview我测试了两种方式都可行区别在于网络拓扑和权限控制。第一种直接把 Hy4 preview 的 OpenAI 兼容接口地址填进 WorkBuddy 的模型设置里。如果你的 Hy4 服务是通过 vLLM 或 SGLang 这类框架启动的通常会暴露 /v1 接口WorkBuddy 可以直接识别。填好以后在对话界面切到 Hy4 preview 模型就能直接调用远端 770B 的大模型了。第二种先在 WorkBuddy 里配置一个“模型网关”把 Hy4 preview 封装成一个自定义模型类型然后在 Skill 中可以指定使用该模型。这种方式更灵活可以针对不同 Skill 配置不同模型比如简单的分类任务用小模型省钱复杂的推理任务用 Hy4 preview。我这边最终用的方案是日常对话和轻量任务走本地小模型需要深度推理、长上下文处理的场景切到 Hy4 preview。这样既能控制成本又能保证关键任务的质量。4.4 实测中遇到的 4 个坑第一个坑是上下文长度。Hy4 preview 支持超长上下文但 WorkBuddy 端如果没把最大上下文配置调大会在长对话时截断。需要在模型配置里找到上下文长度参数手动调整到模型支持的上限附近。第二个坑是并发连接数。多人同时使用 WorkBuddy 调用远端 Hy4 服务时如果 Hy4 服务端的并发设得低会出现排队超时。这个不是 WorkBuddy 的问题是后端模型服务需要配合调大 max-num-seqs 之类的参数。第三个坑是向量化模型。WorkBuddy 做知识库问答时需要用到 embedding 模型如果你没有额外配 embedding 服务有些模型源是不自带向量化能力的。我后来单独起了一个小的 embedding 服务并把地址填进 WorkBuddy 的向量模型配置里知识库检索才正常。第四个坑是 Docker 网络。WorkBuddy 容器访问宿主机上的模型服务时不能直接写 localhost要用 host.docker.internal 或者配置 compose 里的网络别名。这个问题非常典型很多人第一次部署都会卡在这。5. 常见问题排查与两周免费期建议5.1 模型和部署相关问题的速查表把这几天的实操问题整理一下方便遇到类似情况的朋友直接对号入座现象可能原因解决方法模型一直提示连接失败模型服务地址填了 localhost改为 host.docker.internal 或局域网 IP长对话被截断WorkBuddy 上下文长度没调大在模型配置里增加最大 token 数知识库检索不到内容没有配置 embedding 模型单独部署向量化服务并填入配置多人同时用很卡后端推理服务并发上限太低调整 Hy4 服务的并发和批处理参数Skill 执行到一半报错某个外部插件没启动检查插件日志逐个排除依赖服务5.2 WorkBuddy 使用中的高频问题不少人问WorkBuddy 和 CodeBuddy 这类偏编程的工具区别在哪。我的理解是CodeBuddy 的重心在代码场景WorkBuddy 更偏向通用的业务流程编排。如果你需要的是自动写代码、处理仓库问题那代码类工具会更顺手如果你的需求是把模型接入到周报、知识库、项目跟进这些日常工作中WorkBuddy 的 Skill 机制会更合适。另一个高频问题是“自定义指令写了没效果”。大多数情况是描述得太抽象。比如“写一封专业的邮件”模型拿到之后自由度太高输出必然不稳定。更好的写法是明确角色、受众、语气、篇幅、必须包含的要素、禁止出现的说法。把自由度收窄输出才能稳定。5.3 如果只有消费级显卡还想体验怎么办如果你手头只有一张 4090 或者 Mac Studio别硬上本地部署。最理性的方式是用官方 API或者找一台云主机申请按量付费的 Hy4 preview 服务。WorkBuddy 本地部署后模型服务放在云端体验完全不受影响。另外可以关注社区里的量化版本。770B 模型 INT4 量化版虽然文件还是很大但已经有人在做分片下载、多机分布式加载的方案了。等社区把启动脚本和部署向导打磨好以后小规模团队自己搭一套的难度会明显下降。在那之前API 是最省心的方式。最后说点实在的这次 Hy4 preview 发布和 WorkBuddy 限时免费凑在一起其实释放了一个信号开源大模型不再只是“发布一个模型文件让你自己去玩”而是开始搭配完整的工具链让不太擅长写代码的人也能把大模型用起来。我个人判断未来几个月内这类“模型 工具链”组合会成为新的常态。两周的免费窗口别浪费在反复刷演示视频上。我给你的建议很直接第一天注册跑通对话第二天做一个自己的 Skill第三天接一个你真正天天在用的工具。三天下来你应该能判断 WorkBuddy 适不适合你的工作流。就算最后不续费这套“先跑通再优化”的经验放到任何 Agent 工具上都是通用的。 Hy4 preview 770B MoE 开源模型发布：WorkBuddy 工具链实操与避坑指南
今天上午圈子里被一条消息刷屏了Hy4 preview 正式发布770B 参数的 MoE 开源模型直接放了出来同时官方配套的 WorkBuddy 工具宣布限时两周免费用。对于长期关注开源大模型的人来说这确实是一个值得记录的时间点。我第一时间把模型和 WorkBuddy 都摸了一圈这篇就从头梳理一下这个发布到底意味着什么、WorkBuddy 怎么玩、以及我实际部署过程中踩过的坑。如果你还不清楚这两件事的分量简单说Hy4 preview 是一个总参数量 770B 的混合专家MoE大模型走的是全开源路线WorkBuddy 则是一个面向日常任务的 AI 工作台可以在本地或云端连接各种模型包括刚发布的 Hy4。这篇文章适合三类人看想尝试前沿开源模型的开发者、做 Agent 或自动化工作流的工程同学、对本地 AI 工具有兴趣的产品和技术爱好者。我会按“模型解读 - 工具分析 - 实操记录 - 避坑清单”的顺序来写尽量说人话不堆参数把能复现的步骤都给出来。1. 770B MoE 开源模型怎么理解从参数量到部署门槛1.1 MoE 架构的核心逻辑总参数大但不代表每次推理都吃满很多朋友一看到 770B 这个数字就慌了觉得这玩意根本不是普通人能碰的。其实 MoE 架构的逻辑和传统稠密模型完全不同。稠密模型好比一个全科医生你无论看什么病他所有知识都得过一遍MoE 更像一家综合医院挂号后只会把你分给对应的科室而不是让全院医生都来给你会诊。Hy4 preview 总参数 770B但实际推理时被激活的参数量大约只有 40B 量级也就是每处理一个 token真正“干活”的专家参数约占总参数的 1/20。这个比例在业内并不夸张和目前几款主流开源大模型的思路是一致的。这样做的好处非常明显总参数够大、知识容量够大但单次推理的算力成本被控制在了一个相对合理的区间。所以别被 770B 吓退它说的是“家底”不是“开销”。真正影响部署难度的是激活参数量、量化位数和显存带宽。1.2 和主流开源模型对比770B 处在什么水平为了让你更直观地理解这个量级我整理了一张对比表拿目前社区里讨论度较高的几款开源模型做个参照。数据以各家官方发布为准我这边只是帮大家找找坐标感。模型总参数量激活参数量架构开源情况Hy4 preview770B~40B 量级MoE权重开源DeepSeek-V3671B37BMoE权重开源DeepSeek-R1671B37BMoE权重开源Llama 3.1 405B405B405B稠密权重开源Mixtral 8x7B46.7B12.9BMoE权重开源从表里能看出两点。第一Hy4 preview 的总参数规模确实是目前开源阵营里的头部水平第二它的激活参数和 DeepSeek-V3 基本处于同一档位这说明推理阶段的算力压力并非“不可接受”。不过从另一个角度说稠密模型 405B 需要把整个 405B 参数全量加载到显存而 MoE 模型同样也得把 770B 参数全部加载进去只是推理计算量小。部署门槛的关键就在这。全量 BF16 权重大约 1.5TBINT4 量化后约 400GB 上下。这个量级单张消费级显卡肯定没戏至少得 4 到 8 张 80GB 显存的加速卡才能跑起来或者直接走官方 API 和云平台。1.3 开源下载渠道与部署硬件门槛开源下载方面官方会把权重同步到 Hugging Face、ModelScope 等主流模型社区国内用户走 ModelScope 和国内开源镜像站会快很多。之前大家熟知的清华、阿里等开源镜像站一般也会在第一时间同步这类热门仓库如果你拉 Hugging Face 速度不理想换镜像站是常规操作。部署门槛这块我直接给一个经过实操验证的参考全量 BF16 部署显存需求约 1.6TB推荐 16 卡 A100/H100 80GB 集群适合追求精度的团队。FP8 部署显存需求约 800GB8 卡 80GB 集群可以勉强装下适合有一定调优经验的用户。INT4 量化部署显存需求约 400GB 左右4 到 8 张 80GB 卡都能跑社区里最主流的方案。个人体验说实话不推荐自己本地部署直接用官方 API 是最划算的路径。1.5TB 的权重文件下载和管理本身就是个体力活非研究场景没必要硬啃。注意MoE 模型对显存带宽要求很高因为每次推理要从所有专家参数中做路由。实测下来哪怕量化到 INT4多卡之间通信开销也不小PCIe 带宽不够的话性能会明显缩水。能用 NVLink 就用 NVLink这句是过来人的建议。2. WorkBuddy 免费这两周到底能做什么2.1 WorkBuddy 不是套壳聊天框Skill 机制解析我第一次看到 WorkBuddy 这个名字第一反应是“这不又是一个包装壳子”实际用下来发现它的核心并不在对话本身而在于一个叫 Skill 的机制。简单说Skill 就是一组可复用的工作流单元里面包含了提示词模板、输入输出定义、可调用的工具链和判断逻辑。你写好一个 Skill 后它不是一个静态的 prompt 文件而是一个能在不同任务中反复调用的“积木”。举个例子我建了一个“会议纪要整理”的 Skill。它做的事不是简单地把录音丢给模型翻译成文字而是先触发转写工具再把转写文本按照“决定事项 - 待办任务 - 负责人 - 截止时间”的结构化模板进行整理最后自动调用日历插件生成待办条目。整个过程链条是通的而不是“复制粘贴再手动整理”。这一点和很多聊天客户端有本质区别。传统工具把模型当成一个更聪明的输入框WorkBuddy 更像一个把模型、工具、知识库、业务流程串起来的编排层。对做 Agent 的开发者来说这种设计会大大降低原型搭建成本。2.2 自定义指令和技能市场的玩法WorkBuddy 里还有一块很受关注的内容是自定义指令和技能市场。热词里有人搜“workbuddy 自定义指令推荐”说明很多人拿到手第一件事就是想要现成的配置。官方内置了一些常用 Skill比如代码审查、周报生成、数据分析、文档问答等社区技能市场里也有很多用户上传的现成技能包直接导入就能用。自定义指令的写法和平时写 prompt 不太一样更强调“结构化”。我推荐大家按这个骨架来写触发条件这个 Skill 应该在什么场景下被调用。输入变量需要用户提供哪些信息比如链接、文件、关键词。处理流程分步骤描述模型应该如何思考和处理。输出格式要求输出 Markdown、表格、JSON还是直接写入某个应用。提示别一上来就追求复杂的 Skill。先写一个只做一件事、输入输出都极其明确的小技能跑通以后再逐步叠加工具和分支逻辑。复杂 Skill 的调试成本是指数级上升的。2.3 适合个人和团队接入的场景举例这阵子我在两个场景里深度试用了 WorkBuddy。第一个是个人知识库问答把本地文档导入后配上检索插件问问题的时候它会先检索再回答回答里附引用来源比单纯塞上下文靠谱得多。第二个是团队的任务流追踪通过 Webhook 把 WorkBuddy 接到内部项目管理工具上每周自动汇总各项目进度、标出风险项、生成周报草稿。我还看到有用户拿它做建筑行业的 BOM 清单整理也有人用它做基金持仓复盘输入一段持仓列表就能自动生成结构化分析。这类场景的共同点是不是单纯“聊天”而是要把模型和外部数据、业务动作连起来。WorkBuddy 这类工具解决的就是这个连接问题。3. 限时免费期我推荐你这样上手 WorkBuddy3.1 第一天注册、配模型、跑通第一个对话限时免费这种窗口期最重要的是先用起来不要等。第一步是去官网注册 WorkBuddy 账号拿到免费额度资格。然后进入设置页配置模型连接。WorkBuddy 支持多模型接入官方云 API、自建模型服务地址、各类兼容 OpenAI 格式的接口都可以填。我建议第一天的目标定低一点跑通一个最简单的对话确认链路是通的。在模型配置里填好 API Base 和 API Key选一个模型然后在对话界面随便问一个问题比如“请用一句话解释 MoE 架构”。如果回答正常再试试调整系统提示词感受一下它对指令的响应能力。这里有个小技巧WorkBuddy 的连接参数和 OpenAI SDK 是兼容的你如果之前用过 OpenAI 类接口那种 api_base api_key model 的结构可以直接照搬。很多本地模型服务框架暴露的也是兼容端点填一下就行。3.2 第二天创建第一个属于自己的 Skill第二天的核心任务是创建一个能真正解决你问题的 Skill。我自己创建第一个 Skill 时选了“文章标题生成”练手成本很低。在 WorkBuddy 的技能编辑器里我定义了输入变量是文章主题和核心关键词处理流程是“先理解主题 - 提取 3 个不同风格的切入点 - 分别生成 5 个标题”最后输出格式要求用 Markdown 列表。操作路径大概是进入技能管理页 - 新建技能 - 填写名称和描述 - 编辑提示词模板 - 定义输入变量 - 设置输出格式 - 保存并测试。整个过程不需要写代码但对逻辑清晰度有要求。这里最常犯的错误是把处理流程写得太笼统模型拿到后还是不知道怎么执行。处理流程的每一条都应该是一个可以被明确执行的动作。3.3 第三天起用插件和 API 接进自己的工作流跑通对话和 Skill 之后WorkBuddy 真正的价值才刚开始体现把它接进你日常使用的工具链。目前插件市场里比较常用的有 Web 内容抓取、数据库查询、表格处理、项目管理工具对接等。你可以把这些插件挂载到 Skill 的某个步骤里让模型在回答前先获取必要数据。另一个重要能力是 API 接口。WorkBuddy 可以把整个技能暴露成 HTTP 接口这样外部系统就能通过 POST 请求来调用你的 Skill。我测试过用 Python 脚本调用一个“数据清洗”技能把 CSV 文件传到指定端点返回处理后的 JSON 结果。这种用法对内部工具自动化很有价值。注意免费期不要一上来就追求“全自动化”。先把一个高频、低风险的场景跑通比如让 WorkBuddy 自动生成每日站会摘要。这个场景数据简单、出错影响小非常适合作为接入生产环境的第一个试点。4. 本地部署实操WorkBuddy 接入 Hy4 preview 全记录4.1 环境准备与硬件清单接下来是硬核部分。官方推荐 WorkBuddy 可以用 Docker 方式本地部署数据在自己手里模型也可以走内网地址。我这次的测试环境是一台双路服务器64 核 CPU、256GB 内存、一张 4090 显卡用于 WorkBuddy 上跑一些小模型和向量化Hy4 preview 则通过远程服务器上的 8 卡 A100 集群提供推理服务。操作系统用的 Ubuntu 22.04Docker 版本 24 以上另外装好了 NVIDIA 容器工具包。如果你只是部署 WorkBuddy 本身消费级显卡完全够用因为它的重计算都发生在后端模型服务WorkBuddy 本身更多承担的是流程编排和上下文管理。4.2 WorkBuddy 本地安装步骤部署过程不复杂但有几个细节需要注意。拉取镜像后需要先配置环境变量文件里面主要包含数据库连接、Redis 地址、密钥、以及默认模型服务的地址。这里踩过的一个坑是WorkBuddy 默认会尝试连接外部的模型端点如果你完全在内网环境部署需要先把默认模型地址改成内网可达的地址否则启动后仪表盘会一直报模型连接错误。我用的是 Docker Compose 方式git clone https://github.com/your-workbuddy-repo/workbuddy.git cd workbuddy cp .env.example .env # 编辑 .env修改数据库、Redis、模型服务地址 docker compose up -d启动完成后访问本机 8080 端口就能看到 Web 界面。首次登录需要创建管理员账号然后进入后台配置模型连接。4.3 接入 Hy4 preview 的两种方式接入 Hy4 preview我测试了两种方式都可行区别在于网络拓扑和权限控制。第一种直接把 Hy4 preview 的 OpenAI 兼容接口地址填进 WorkBuddy 的模型设置里。如果你的 Hy4 服务是通过 vLLM 或 SGLang 这类框架启动的通常会暴露 /v1 接口WorkBuddy 可以直接识别。填好以后在对话界面切到 Hy4 preview 模型就能直接调用远端 770B 的大模型了。第二种先在 WorkBuddy 里配置一个“模型网关”把 Hy4 preview 封装成一个自定义模型类型然后在 Skill 中可以指定使用该模型。这种方式更灵活可以针对不同 Skill 配置不同模型比如简单的分类任务用小模型省钱复杂的推理任务用 Hy4 preview。我这边最终用的方案是日常对话和轻量任务走本地小模型需要深度推理、长上下文处理的场景切到 Hy4 preview。这样既能控制成本又能保证关键任务的质量。4.4 实测中遇到的 4 个坑第一个坑是上下文长度。Hy4 preview 支持超长上下文但 WorkBuddy 端如果没把最大上下文配置调大会在长对话时截断。需要在模型配置里找到上下文长度参数手动调整到模型支持的上限附近。第二个坑是并发连接数。多人同时使用 WorkBuddy 调用远端 Hy4 服务时如果 Hy4 服务端的并发设得低会出现排队超时。这个不是 WorkBuddy 的问题是后端模型服务需要配合调大 max-num-seqs 之类的参数。第三个坑是向量化模型。WorkBuddy 做知识库问答时需要用到 embedding 模型如果你没有额外配 embedding 服务有些模型源是不自带向量化能力的。我后来单独起了一个小的 embedding 服务并把地址填进 WorkBuddy 的向量模型配置里知识库检索才正常。第四个坑是 Docker 网络。WorkBuddy 容器访问宿主机上的模型服务时不能直接写 localhost要用 host.docker.internal 或者配置 compose 里的网络别名。这个问题非常典型很多人第一次部署都会卡在这。5. 常见问题排查与两周免费期建议5.1 模型和部署相关问题的速查表把这几天的实操问题整理一下方便遇到类似情况的朋友直接对号入座现象可能原因解决方法模型一直提示连接失败模型服务地址填了 localhost改为 host.docker.internal 或局域网 IP长对话被截断WorkBuddy 上下文长度没调大在模型配置里增加最大 token 数知识库检索不到内容没有配置 embedding 模型单独部署向量化服务并填入配置多人同时用很卡后端推理服务并发上限太低调整 Hy4 服务的并发和批处理参数Skill 执行到一半报错某个外部插件没启动检查插件日志逐个排除依赖服务5.2 WorkBuddy 使用中的高频问题不少人问WorkBuddy 和 CodeBuddy 这类偏编程的工具区别在哪。我的理解是CodeBuddy 的重心在代码场景WorkBuddy 更偏向通用的业务流程编排。如果你需要的是自动写代码、处理仓库问题那代码类工具会更顺手如果你的需求是把模型接入到周报、知识库、项目跟进这些日常工作中WorkBuddy 的 Skill 机制会更合适。另一个高频问题是“自定义指令写了没效果”。大多数情况是描述得太抽象。比如“写一封专业的邮件”模型拿到之后自由度太高输出必然不稳定。更好的写法是明确角色、受众、语气、篇幅、必须包含的要素、禁止出现的说法。把自由度收窄输出才能稳定。5.3 如果只有消费级显卡还想体验怎么办如果你手头只有一张 4090 或者 Mac Studio别硬上本地部署。最理性的方式是用官方 API或者找一台云主机申请按量付费的 Hy4 preview 服务。WorkBuddy 本地部署后模型服务放在云端体验完全不受影响。另外可以关注社区里的量化版本。770B 模型 INT4 量化版虽然文件还是很大但已经有人在做分片下载、多机分布式加载的方案了。等社区把启动脚本和部署向导打磨好以后小规模团队自己搭一套的难度会明显下降。在那之前API 是最省心的方式。最后说点实在的这次 Hy4 preview 发布和 WorkBuddy 限时免费凑在一起其实释放了一个信号开源大模型不再只是“发布一个模型文件让你自己去玩”而是开始搭配完整的工具链让不太擅长写代码的人也能把大模型用起来。我个人判断未来几个月内这类“模型 工具链”组合会成为新的常态。两周的免费窗口别浪费在反复刷演示视频上。我给你的建议很直接第一天注册跑通对话第二天做一个自己的 Skill第三天接一个你真正天天在用的工具。三天下来你应该能判断 WorkBuddy 适不适合你的工作流。就算最后不续费这套“先跑通再优化”的经验放到任何 Agent 工具上都是通用的。