最近后台收到好多朋友在问同一个问题WorkBuddy 里的 Hy3 和 Hy4 到底差在哪普通用户是不是无脑选新版本就行了怎么切换。我自己的机器人工作台从 Hy3 切到 Hy4 也跑了两周多期间踩了不少坑这里统一聊一聊把差异、选择逻辑和切换步骤一次说清楚。如果你还没装过 WorkBuddy或者刚装了不知道 Hy 是什么先别急着划走。我尽量用大白话把这套东西讲明白它是目前效率圈里口碑不错的一款个人 AI 工作台工具主打通过本地部署、Skill 技能编排、各类连接器把 AI 能力接进日常繁琐任务里。至于 Hy3 和 Hy4可以理解成 WorkBuddy 内部两代 Agent 执行内核直接决定了你的任务是怎么被拆解、调度和执行的。1. 先搞清楚一件事Hy3 和 Hy4 到底是什么1.1 Hy3 和 Hy4 不是“版本号升级”而是两套执行内核很多人一看到 Hy3、Hy4第一反应是 WorkBuddy 又发新版本了我得赶紧升级。这个理解其实不准确。Hy 的全称在官方文档里写作 Hybrid Agent Kernel也就是混合智能体内核。Hy3 和 Hy4 是两套并存的执行内核你随时可以在同一个 WorkBuddy 里切换不需要重装软件也不会动你已有的技能和连接器配置。用做饭来打比方Hy3 更像一本写得很详细的菜谱每一步都告诉你先放什么后放什么火候多少分钟Hy4 则更像一位有经验的厨师你告诉他“今天想吃一顿省事的晚餐”他会自己判断做什么、用什么食材、按什么顺序来。两者最终都能把饭做出来但过程、灵活度、对复杂场景的适应能力完全不同。我自己的理解是Hy3 是在 WorkBuddy 早期大量真实用户反馈基础上固化下来的“确定性优先”内核它追求的是每一步都可解释、可复现。你给它什么指令它就按预设的流程去执行哪怕中间某个环节出了问题它也会按既定规则停下来或者报错不会自作主张。这个特点让 Hy3 非常适合那些每天都在重复、流程固定、绝对不能出错的自动化任务。Hy4 则换了思路它把任务拆解、工具调用的决策权更多地交给了模型本身。举个例子我用 Hy4 跑一个“整理今天群聊里的待办事项并发到钉钉多维表”的任务时它不再像 Hy3 那样傻乎乎地等我把每个步骤都想好而是会自动判断哪些消息算待办、哪些只是闲聊然后自己决定调用哪个连接器、按什么格式写入表格。这种体验在任务稍微复杂一点的时候差距特别明显。1.2 两者的核心差异从“规则驱动”到“意图驱动”理解 Hy3 和 Hy4 差异最核心的一句话就是Hy3 是规则驱动Hy4 是意图驱动。规则驱动的意思是你的指令本质上是“如果什么情况就做什么动作”WorkBuddy 把整个流程切成一个个动作节点每个节点由预设规则触发。你让 Hy3 每天上午九点抓取某个网页的行情数据它就只会做这一件事而且每次抓取都会严格按同一个模板去解析即使网页结构变了它也不会主动调整只会报错。这样的好处是稳定坏处是需要你随时盯着外部的变化网页改版了、接口字段变了你就得自己去改指令。意图驱动则不同。Hy4 内置了更强的语义理解和动态规划能力它拿到你的指令后会先拆解成“目标”再自己去想“要达到这个目标需要做哪几步”。如果外部环境变了比如网页结构改了它会尝试从新的结构里找到相似的信息实在找不到才会向你报告。这种能力在面对真实世界里不规则、多变的输入时体验会好很多。不过要注意意图驱动不代表它能完全替你思考。它仍然需要你有清晰的表达只是它对“我这个意思没说明白”的容错率更高了。我自己实测下来同一个任务描述在 Hy3 下可能需要写四五行非常明确的步骤在 Hy4 下只要写清楚目标和约束条件它就能给你跑出一个差不多的流程。这背后是模型 token 消耗和响应时长在换不是凭空变聪明了。1.3 一张表看明白 Hy3/Hy4 的主要差异对比维度Hy3Hy4核心逻辑规则驱动按预设步骤执行意图驱动动态规划任务路径上手难度低指令写得多但直白中等需要学会表达目标而非步骤适合任务固定流程、重复性高、零容错场景复杂编排、长上下文、需要临场决策的任务模型消耗相对省 token因为流程固定消耗更高因为每个任务都要重新推理稳定性高但遇到环境变化易“死板”中高环境适应性好但偶尔会“自由发挥”排错难度低每一步都能看到执行记录中高需要结合意图判断它为什么这么选切换成本无需迁移直接用需要检查 Skill 和连接器兼容性这张表算是我用了两周多以后最直接的感受。不是说 Hy4 全面优于 Hy3而是两者适用场景确实不一样。老话说得好工具没有绝对的好坏只有合不合适。2. 普通用户怎么选先看场景再看设备最后看预算2.1 选 Hy3 的情况稳定、轻量、日常自动化如果你平时的工作流比较固定属于“每天重复同样动作”的类型那 Hy3 大概率是更省心的选择。我举几个实际场景第一个是定时同步类任务。比如你现在每天早上要把某个销售群的聊天记录整理成表格同步到钉钉多维表里。这种任务流程非常固定拉取聊天记录、识别关键字段、按模板写入。中间几乎不需要什么智能判断你甚至希望它“一点都不要创新”这时候 Hy3 的“死板”反而是极大的优点。它不会哪一天突然觉得某个字段不重要就给你跳过了。第二个是外部接口对接。如果你用 WorkBuddy 接了公司内部系统、第三方 API而这些接口的返回结构是稳定的Hy3 也足够胜任。你可能需要手工写一些解析规则但写完以后几乎不用管。第三个是设备性能一般的情况。Hy3 在执行任务时的内存占用和模型调用频率明显低于 Hy4因为它不需要为每个任务做额外的意图推理。我试过在一台只有 16G 内存的老笔记本上同时跑 WorkBuddy 本地部署和浏览器切到 Hy3 以后明显感觉顺畅不少。说白了Hy3 适合“你已经完全知道要怎么干只是缺一个不眠不休的执行者”的场景。这时候让一个讲究规矩的老实人去干活比让一个聪明但想法很多的家伙去干活更让你安心。2.2 选 Hy4 的情况复杂编排、长上下文、多 Agent 协同反过来如果你的任务经常变化、环节多、需要模型自己拿主意那 Hy4 的优势就非常突出了。我自己印象最深的是一次处理“整理一个月的工作周报”。用 Hy3 的话我得先告诉它读取哪些周报文件、按什么格式提炼关键信息、最终输出成什么结构每一步都要交代得明明白白。而 Hy4 只需要我给它一句“帮我看看这个文件夹里所有周报提取出和项目进度相关的内容按负责人分组提炼成摘要然后生成一份对比表”。它会自己去读文件、判断哪些内容相关、决定用什么粒度汇总。整个过程我不需要干预跑完的结果也符合预期。Hy4 另一个明显的优势在长上下文处理。如果你经常让 WorkBuddy 读文档、读网页、处理几十页的 PDFHy4 对长文本的理解能力比 Hy3 强很多。我实测过一个二十多页的项目方案Hy3 在分析到后半段时已经开始丢细节而 Hy4 能把前后文串起来总结的时候甚至会提醒我“这个方案里前期的预算和后期的报价存在不一致”。这种“跨上下文找问题”的能力在 Hy3 下几乎不可能实现。再一个就是多 Agent 协同。WorkBuddy 可以同时挂多个技能Skill和连接器Hy4 能更好地在多个技能之间做调度。比如我让它在“搜集行业资讯”的同时“更新我的 Obsidian 笔记库”再“给团队群发一份摘要”。这种多目标并行任务Hy4 会自己拆分优先级而不是像 Hy3 那样一条一条排队执行。对追求效率的人来说这种体验上的差距是实打实的。2.3 一个偷懒的选择原则能跑 Hy4 就用 Hy4跑不动再退回 Hy3我知道很多普通用户看到上面的对比反而更纠结了那我到底选哪个我给自己定了一个偷懒原则用下来感觉挺靠谱分享给你。核心逻辑很简单优先尝试 Hy4因为它代表了 WorkBuddy 目前完整的能力方向但如果你发现 Hy4 在你的设备上跑得吃力或者你的任务总是出现“它想太多、反而做错”的情况那就果断退回 Hy3。切换本身成本很低不需要重装或迁移数据所以完全不用怕选错。有个判断标准可以参考如果你运行 Hy4 时任务完成时间比 Hy3 慢了一半以上而且结果并没有明显变好那就说明这个任务压根不需要那么强的意图推理留在 Hy3 更合理。反之如果你在 Hy3 下总是需要花大量时间写指令、调规则、处理报错那哪怕 Hy4 慢一点、费一点总体时间算下来也是省钱的。说白了别把 Hy3 和 Hy4 当成“老版”和“新版”要把它们当成“老实执行者”和“聪明协作人”。你需要谁就叫谁出来干活。3. 切换步骤从 Hy3 切到 Hy4以及回滚3.1 切换前的准备工作备份、版本确认、Skill 依赖检查先说最重要的切换前一定要备份。虽然 Hy3 和 Hy4 可以在同一个 WorkBuddy 里共存但你自己的自定义指令、Skill 配置、连接器授权信息都可能在切换后被 Hy4 重新编排时产生意想不到的读写操作。我不想吓唬你但如果你手上有跑得正好的自动化任务先花两分钟备份绝对是值得的。备份分两层。第一层是 WorkBuddy 应用内的配置导出在设置里可以找到“导出配置”的按钮会生成一个 JSON 文件里面包含你的工作区布局、已安装的 Skill、自定义指令、连接器配置等。这一层备份恢复起来最省事。第二层是任务数据层面的备份比如你让 WorkBuddy 定时写钉钉多维表、发微信消息那你最好确认一下你的数据源是正常的、能取到的别切换完了才发现原来的权限过期了那时候你会分不清是切换导致的问题还是权限问题。接下来确认你当前用的版本。在 WorkBuddy 主界面左下角的设置里能看到当前内核版本号。注意WorkBuddy 软件本身的版本号是另一回事和 Hy 内核版本无关。你就算升级到最新版 WorkBuddy也不代表默认就切到了 Hy4这两个是独立的维度。然后是检查 Skill 依赖。这一步很多人会忽略但它恰恰是切换后最大概率出问题的环节。在 WorkBuddy 的“技能”页面里每个 Skill 会标注它支持的内核版本。你可能会发现有些 Skill 明确写着“Hy3 Only”有些写着“Hy4”。我的习惯是整理一张清单把我在用的所有 Skill 和连接器跟内核兼容性逐项过一遍确认没有一个会因为切换而完全跑不起来。3.2 正式切换步骤在 WorkBuddy 界面内操作确认完准备工作后切换本身其实很快。整个流程大概三分钟我按实际操作的顺序给你列一下。第一步打开 WorkBuddy 主界面点击左下角的“设置”图标进入“高级设置”面板。第二步在面板里找到“执行内核”选项这里会列出当前可用的 Hy3 和 Hy4点击 Hy4然后点“应用”。第三步WorkBuddy 会提示你需要重启服务才能生效点确认等待主进程自动重启。第四步重启完成后回到“执行内核”确认状态已经变成 Hy4。这里我提醒一个细节如果你的 WorkBuddy 是本地部署模式也就是你自己有服务端进程重启之后最好去终端看一下日志确认内核已经加载成功。日志里一般会有一行类似“Agent kernel switched to Hy4”的记录。如果看不到这些字样说明可能还在旧内核上跑检查一下服务有没有真的重启成功。界面操作就这么简单。但真正容易出问题的是切换之后你已有的那些自动化任务到底怎么跑。WorkBuddy 不会自动把你的任务在新内核下重写一遍而是会按新内核的逻辑重新解释一遍。解释得好任务直接就能跑解释得不好可能就会出现各种奇怪的行为。这就要用到下面要说的配置调整了。3.3 配置示例自定义指令与内核的绑定如果你的 WorkBuddy 里有一些自定义指令切到 Hy4 之后我强烈建议你把指令里的“步骤式描述”改成“目标式描述”。举个例子我之前在 Hy3 下有一个“同步群聊待办”的自定义指令是这样写的name: 同步群聊待办 version: 1.0 trigger: type: schedule cron: 0 9 * * * steps: - action: read_chat source: 销售部群 time_range: last_24h - action: filter_message keyword: [待办, 跟进, 别忘了] - action: write_row target: 钉钉多维表 table: 销售跟进这段指令在 Hy3 下跑得很稳因为每一步都是明确的。但切到 Hy4 后我发现它会按照自己的理解去重组这些步骤偶尔会把keyword里没有提到的消息也当成待办因为它在语义上判断“这句话也是任务”。所以我把它改成了下面这种写法name: 同步群聊待办 version: 1.0 trigger: type: schedule cron: 0 9 * * * goal: 把销售部群过去24小时里包含任务含义的消息提取出来写入钉钉多维表“销售跟进”表 constraints: - 只提取明确提到待办、跟进、别忘了的消息 - 不要写入纯闲聊内容 - 如果某条消息不确定保留原始文本供人工复核改完之后Hy4 的表现反而好了很多。它不会拘泥于我那三个关键词而是理解了“我真正要的是任务类消息”遇到“麻烦老张今天下班前把报价发我”这种没有关键词但明显是任务的消息它也能正确识别并写入表格。这就是两种内核在自定义指令上的本质区别。3.4 如何回滚到 Hy3并保留 Hy4 的部分配置如果你用了几天 Hy4 觉得不太舒服想退回 Hy3整个过程跟切换上去一样简单。设置里“执行内核”重新选回 Hy3重启即可。但这里有两个点需要注意第一你在 Hy4 下新建的那些任务、修改过的自定义指令切回 Hy3 后不一定会兼容。因为 Hy3 不承认“目标式描述”这种写法它需要明确的步骤。如果你在 Hy4 下改了不少指令建议先批量导出等回滚后再按 Hy3 的规则调整。第二不要频繁来回切。我试验过短时间内反复切换内核会导致 WorkBuddy 的本地缓存出现一些奇怪问题比如 Skill 列表刷新不出来、连接器授权状态异常。如果你确实要比较两者给每个内核至少留出三天的观察期不要一天切好几个来回。4. 切换后必做的三件事验证、调参、备份4.1 用日常任务做冒烟测试切到新内核之后不要直接拿那些重要的、跑了好几个月的任务去试水。我见过太多朋友切完内核马上跑生产任务结果出了问题都不知道是内核问题还是任务本身的问题。正确做法是先拿一个低频的、不重要的日常任务做冒烟测试。我自己的冒烟测试清单是这样的先跑一个“简单的定时提醒”任务确认基础调度正常再跑一个“读网页并总结”的任务确认联网和模型调用正常接着跑一个“写记录到本地文件”的任务确认文件操作权限正常最后跑一个涉及外部连接器的任务比如写钉钉多维表确认授权链路正常。这一套跑下来基本能覆盖 WorkBuddy 的核心链路调度、读取、模型推理、执行、外部接口。如果这些都没问题再把手头重要的任务逐渐切过来。每个任务跑通以后记录一下完成时间和结果是否符合预期。这些记录在后续排查问题时非常有用。4.2 调整关键参数上下文长度、模型轮次、技能调用权限Hy4 跑起来之后你会发现它在“上下文长度”“模型轮次”“技能调用权限”几个参数上的默认值跟 Hy3 不太一样。这几个参数藏得比较深在设置里的“模型配置”和“执行参数”面板中。我用实际数据说说我的调整过程。上下文长度默认从 8k 提升到了 32k。这当然是好事但也意味着更多的 token 消耗。如果你的模型是走 API 按量付费的我建议先把上下文长度设为 16k而不是直接用默认值 32k。很多任务根本用不到 32k 的上下文设太高只是白白烧钱。模型轮次默认从 3 提升到了 8。这里的轮次是指 WorkBuddy 在完成一个任务时最多能调用模型几次。Hy3 下 3 次足够因为流程固定。Hy4 下有时候它会在中间多问自己几轮“下一步该做什么”所以 8 次能减少任务中断的概率。但如果你的任务非常简单也可以手动降回 4 或 5响应速度会快不少。技能调用权限这个是 Hy4 新引入的。因为 Hy4 会自己判断要不要调用某个技能所以你需要明确哪些技能允许它自动调用、哪些必须经过确认。我会把涉及写操作、发消息、删数据的技能设为“需确认”读取类的技能设为“允许自动”。这个配置看起来麻烦但能避免它一个“聪明”的决策把消息发错群。4.3 把切换过程固化成文档/脚本最后一件事听起来有点“多此一举”但关键时刻能救你把你这次从 Hy3 切到 Hy4 的过程完整记录下来包括改了哪些指令、调整了哪些参数、遇到哪些坑整理成一份自己的切换手册。很多人觉得切换内核是小事没必要记。但 WorkBuddy 这种工具真正复杂的是围绕它搭建的那套工作流。等过几个月你升级了模型、换了连接器、改了指令再回头看现在这个切换记录你会发现它的价值不亚于官方文档。如果条件允许可以把关键的配置变更写成 Markdown 文件放进你的笔记系统或者存成一个 JSON 快照放网盘。我自己的习惯是每切换一次内核就写一份“切换报告”里面包含切换时间、新旧版本、遇到的问题、解决方案。长此以往你的排错会越来越快。5. 常见问题与排查技巧实录5.1 切到 Hy4 后原来自定义的“工作流”不生效了这是我被问得最多的一个问题。现象是你在 Hy3 下跑得好好的自定义任务切到 Hy4 后直接静默失败或者执行了但没有结果。排查思路其实很清楚。第一先看任务日志。WorkBuddy 每个任务都有运行日志里面会记录每一步的耗时、调用结果。90% 的情况在日志里都能找到明确的报错原因。第二确认是不是指令格式的问题。就像前面说的Hy3 的步骤式指令在 Hy4 下会被重新解释如果你的指令写得太“死”Hy4 可能直接放弃执行。第三检查技能权限。Hy4 默认对部分技能是“需确认”状态如果你的任务没有配置好权限它会在调用技能时卡住。这件事最常见的原因是第二种也就是指令格式不兼容。解决办法就是参照前面 3.3 节的写法把步骤式描述改成目标式描述。改完之后重启一次任务大概率就能跑了。5.2 Hy4 调用外部工具连接器超时切换到 Hy4 之后你可能会发现一些外部连接器比如钉钉、微信、Obsidian偶尔会出现超时。原因是 Hy4 在调用连接器之前会先“思考”一下怎么调这个思考过程增加了请求链路的时间如果连接器本身的响应速度也一般很容易在网关层超时。我的解决办法有三个。一是排查网络链路这是最容易被忽略的确认本机到连接器服务器之间没有丢包二是调整 WorkBuddy 的“连接器响应超时时间”从默认的 10 秒提高到 30 秒三是如果某个连接器确实很慢可以考虑单独给那个连接器设置一个“高频免思考”模式。在连接器配置里把这个连接器的调用方式设为“直接调用”跳过 Hy4 的意图编排层速度能快不少。5.3 本地模型在 Hy4 下输出变“碎”很多做本地部署的朋友会遇到这个问题同一台机器同一个模型切到 Hy4 之后输出的内容反而变短了、变碎了。这不是模型变笨了而是 Hy4 在跟模型交互时用了新的提示词模板把复杂的任务拆成了多次短对话。理论上这样能提高正确率但体现在观感上就是“好像什么都没写”。解决方法是调整“输出偏好”配置。在模型配置里把“回复长度偏好”从“简洁”改为“详细”再把“允许模型分步输出”关掉。这样 Hy4 在处理简单任务时就不会频繁打断模型输出的连贯性会好很多。不过说句公道话这个问题其实不算 bug更多是配置取向的差异。如果模型本身是 7B 以下的轻量级模型处理复杂意图推理确实吃力这种情况回到 Hy3 反而是更明智的选择。5.4 速查表Hy3/Hy4 常见问题对照现象Hy3 下处理思路Hy4 下处理思路任务静默失败查日志看是否有明确的规则错误查日志看意图解析阶段是否出现异常指令不生效检查是否缺少明确步骤检查是否用了“步骤描述”而非“目标描述”连接器超时检查网络和授权检查连接器是否需要设置“直接调用”模式输出内容变碎检查提示词模板是否冲突调整输出偏好为“详细”关闭分步输出资源占用过高检查是否有多个任务并发检查意图推理是否频繁触发结果与预期不符检查规则条件是否写错检查约束条件是否表达清楚这张表我建议你截图保存遇到问题先对着看一遍能省不少折腾时间。大部分问题不是玄学都是规则差异导致的按图索骥就能定位。我个人这两周用下来最大的体会是Hy4 确实比 Hy3 聪明但“聪明”不总是好事。对我那些跑得好好的固定流程来说Hy3 的确定性让我安心而对那些需要随机应变的总结、调研类任务Hy4 又能给我惊喜。所以别纠结哪个更高级把它们当成工具箱里的两把扳手合适的场合用合适的型号比什么都重要。