1. 先搞清楚 WorkBuddy 到底是个什么东西很多人第一次听到 WorkBuddy 这个名字会下意识把它归类成又一个套壳聊天窗口。我一开始也这么想直到真正把它接进日常工作流跑了两周才发现它和普通对话式 AI 的定位完全不是一回事。WorkBuddy 是腾讯推出的 AI 工作台核心形态是AI Agent 中台——它不是一个让你问问题、它答问题的工具而是一个能挂载技能、调用工具、按规则自主完成任务的执行体。你给它一个目标它自己拆步骤、自己调技能、自己交付结果。这个区别非常关键。普通 AI 是你问我答WorkBuddy 是你派活它干活。举个我实际用过的场景我让它把这份会议纪要整理成周报按项目分组输出 Markdown 并生成一个可访问的网页。它会先解析纪要内容再按项目维度归类然后调用文档处理技能生成结构化文本最后调用网页生成技能把结果发布出去。整个过程我只说了一句话中间没有来回确认。这就是 Agent 和 Chatbot 的本质分水岭。那它适合谁用我梳理了三类人。第一类是日常有大量重复性文档、表格、信息整理工作的人比如运营、行政、项目助理WorkBuddy 能把这类活儿压缩到原来的零头。第二类是想入门 AI Agent 但不知道从哪下手的技术爱好者WorkBuddy 的 Skill 机制是一个非常好的练手载体比从零搭框架友好太多。第三类是需要把 AI 能力嵌进团队流程的小团队负责人它的规则系统和技能复用机制天然适合做标准化。关键词里反复出现的Skill、models.json、AI Agent其实就是理解 WorkBuddy 的三把钥匙。Skill 是它的能力单元models.json 是它的模型配置入口AI Agent 是它的整体形态。把这三个概念吃透后面所有的安装、配置、避坑都会顺理成章。接下来我按真实上手顺序从安装一路讲到那些官方文档不会告诉你的坑。2. 安装这件事坑比你想的多2.1 版本选择国内版和国际版不是简单换个语言WorkBuddy 有国内版和国际版两条线热词里workbuddy 国际版被搜了很多次说明不少人在纠结选哪个。我的建议很直接如果你的主要工作内容、协作对象、数据来源都在国内生态里就用国内版。国际版在模型接入、技能市场上和国内版有差异不是简单的界面语言切换。我见过有人图新鲜装了国际版结果发现自己常用的几个技能在那边找不到对应实现又折腾回来重装。选版本之前先想清楚三件事你的数据主要在哪、你要用的技能在哪个版本更全、你的团队协作在哪个版本更顺。这三个问题想明白了版本选择就是水到渠成的事不用反复横跳。2.2 安装路径与缓存目录C 盘爆了别怪我没提醒这是被问得最多的问题之一——workbuddy 系统缓存目录能改到 D 盘吗。答案是能但要在首次启动之前改装完再改会麻烦很多。WorkBuddy 运行过程中会产生大量缓存包括技能执行日志、模型调用记录、临时文件。如果你默认装在 C 盘用不了多久就会发现系统盘告急。我的做法是安装时就把主程序和缓存目录都指到非系统盘。具体操作上安装向导里通常有自定义路径的选项别一路点下一步。如果安装向导没给缓存目录的选项那就装完后第一时间去配置文件里改趁缓存还没堆起来。这里有个经验缓存目录的路径里不要有中文和空格我踩过这个坑某些技能在读取路径时会对特殊字符处理不当导致执行失败但报错信息很含糊排查半天才发现是路径问题。2.3 首次启动的初始化别急着跳过首次启动会有一个初始化过程包括环境检测、依赖拉取、默认技能加载。这个过程可能比较慢尤其是网络状况一般的时候。我的建议是让它跑完不要中途关掉。我见过有人嫌慢直接强退结果技能库加载了一半后面调用技能时各种莫名其妙的报错最后只能卸载重装。初始化完成后先别急着上任务。花五分钟做一件事打开设置确认模型配置、缓存路径、默认工作目录这三项。模型配置决定了你后面能用哪些能力缓存路径决定了你的磁盘会不会爆默认工作目录决定了你生成的文件会落在哪里。这三项确认好后面能省掉大量返工。3. models.json整个工作台的命门所在3.1 这个文件为什么这么重要热词里models.json单独被列出来说明它是很多人的痛点。简单说models.json 是 WorkBuddy 的模型配置文件它决定了工作台能调用哪些模型、每个模型怎么连、参数怎么设。你可以把它理解成工作台的通讯录——里面记着它能找谁干活、怎么找到、找的时候说什么。这个文件出问题表现往往很迷惑。比如技能明明装了却调不动、任务跑到一半卡住、返回结果格式不对很多时候根子都在 models.json 上。我遇到过最典型的一次某个技能一直报模型不可用我以为是技能本身的问题重装了三遍最后发现是 models.json 里那个模型的配置项少了一个字段。3.2 配置时的几个关键点配置 models.json 有几个地方必须注意。第一是字段完整性不同模型需要的字段不完全一样缺一个就可能导致整个条目失效。第二是参数格式比如温度值、最大 token 数这类写错类型该写数字写成字符串不会立刻报错但会在实际调用时出问题。第三是条目顺序有些版本会按顺序尝试模型把常用的放前面能减少等待。我自己的习惯是改 models.json 之前先备份一份改完用一个最简单的任务测一下确认没问题再继续。这个习惯帮我省过好几次事。因为 models.json 一旦改坏可能整个工作台都用不了有个备份能让你快速回滚。提示models.json 的修改建议在 WorkBuddy 完全退出后进行改完再启动。运行中改文件有些版本不会热加载你以为改了其实没生效白折腾。3.3 多模型配置的取舍逻辑如果你要配多个模型得想清楚分工。我的经验是按任务类型分需要强推理的复杂任务配一个能力强的模型日常轻量任务配一个响应快的模型需要处理长文档的配一个上下文窗口大的模型。这样配置的好处是技能在调用时可以根据任务性质选合适的模型既保证效果又控制成本。别贪多。我见过有人一口气配了七八个模型结果自己都记不清哪个是干嘛的技能调用时经常选错。两到三个精心配置的模型比一堆随便加的模型有用得多。配置完在 models.json 里给每个模型写个注释如果格式支持的话或者自己单独记一份说明后面维护会轻松很多。4. Skill 机制WorkBuddy 真正的战斗力来源4.1 Skill 到底是什么和插件有什么区别热词里skill、skill 插件、skill 脚本、agent skill出现频率极高但很多人对 Skill 的理解是模糊的。我的定义是Skill 是封装好的、可被 Agent 调用的能力单元。它和普通插件的区别在于插件通常是给人点的按钮Skill 是给 Agent 调的函数。你装一个 Skill等于给工作台加了一项它能自主使用的能力。这个区别决定了 Skill 的设计思路。一个好的 Skill 不是功能越多越好而是边界清晰、输入输出明确、能被 Agent 准确理解什么时候该用它。我见过一些 Skill 功能堆得很全但 Agent 根本不知道该在什么场景调用它最后成了摆设。4.2 从 book to skill 看 Skill 的典型形态热词里有个很有意思的词叫book to skill这其实揭示了 Skill 的一种典型用法把一份文档、一套流程、一类知识封装成一个可调用的技能。比如你把公司的报销规范整理成 Skill以后 Agent 处理报销相关任务时就能自动按规范来。这种知识固化是 Skill 最有价值的应用之一。我实际做过一个类似的把我们团队的周报模板和写作规范做成 Skill。以前每次让 AI 写周报都要把规范贴一遍现在直接调用 SkillAgent 自己就知道格式要求、语气要求、必填字段。这个 Skill 我用了大半年省下的重复沟通时间非常可观。4.3 Skill 开发的基本思路如果你想自己写 Skill热词里的skill 开发指南、skill 编码可以参考但我更想讲思路而不是语法。写 Skill 的第一步不是写代码是想清楚这个能力的输入是什么、输出是什么、什么情况下该被触发。这三个问题答不清楚代码写得再漂亮也没用。第二步是把边界划死。Skill 最怕的是什么都能干一点因为 Agent 判断是否调用它时会犹豫。一个只干一件事、干得很好的 Skill比一个什么都能干的 Skill 有用得多。第三步是写好描述Skill 的描述是给 Agent 看的不是给人看的要写清楚什么时候用我而不是我有多厉害。注意Skill 的命名和描述直接影响 Agent 的调用准确率。我踩过的坑是描述写得太抽象结果 Agent 该调用的时候不调用不该调用的时候乱调用。后来把描述改成具体的场景化语言准确率明显提升。4.4 Skill 的复用与管理Skill 装多了会乱这是必然的。我的管理方法是按使用频率分层高频 Skill 放在显眼位置低频的归档一次性的用完就删。另外同类 Skill 尽量只留一个别装三个功能重叠的否则 Agent 调用时会随机选结果不稳定。还有一点定期清理失效 Skill。有些 Skill 依赖的外部服务变了、接口改了会静默失效。失效的 Skill 留在那里Agent 偶尔调用到会报错影响体验。我一般每个月过一遍 Skill 列表把不用的、失效的清掉。5. 给 WorkBuddy 定规则让 Agent 真正听话5.1 规则系统解决的是什么问题热词里有一条很具体给 workbuddy 定几条规则后续对所有任务都生效。这戳中了很多人的需求——不想每次都重复交代同样的要求。规则系统就是干这个的你把长期有效的要求写进规则Agent 在执行任何任务时都会遵守。这个功能的价值在于一致性。没有规则的时候你每次派活都要把偏好说一遍说漏了 Agent 就按默认来结果时好时坏。有了规则相当于给 Agent 装了一套工作习惯它每次都会按这个习惯来输出质量就稳定了。5.2 什么样的规则值得写不是所有要求都值得写成规则。我的判断标准是这条要求是不是跨任务、长期、稳定有效的。如果是写进规则如果只针对某一次任务当场说就行。我自己的规则清单里有这么几条输出默认用 Markdown、涉及数据必须标注来源、生成文件默认放在指定目录、不确定的信息必须明确标注而不是编造。这几条覆盖了我日常大部分任务写进去之后我派活时基本不用再重复这些要求。5.3 规则的写法与常见误区规则要写得具体、可执行、无歧义。输出要专业这种规则等于没写因为 Agent 不知道什么叫专业。输出使用 Markdown 格式标题用二级标题代码块标注语言类型——这才叫可执行的规则。常见误区有三个。一是规则太多太杂几十条规则堆在一起Agent 反而抓不住重点还可能互相冲突。二是规则太抽象说了等于没说。三是规则和技能描述打架比如规则说输出简洁某个技能描述说输出详尽Agent 就懵了。写规则的时候要通盘考虑别只顾着加。提示规则改完之后用一个典型任务验证一下效果。规则的影响是全局的改坏了影响面很大验证这一步不能省。6. 实战从零跑通一个完整任务6.1 任务拆解的正确姿势前面讲的都是零件这一节讲怎么组装。我拿一个真实任务举例把一批散乱的客户反馈整理成分析报告并生成一个可分享的网页。这个任务涉及信息整理、分析、文档生成、网页发布四个环节正好能体现 WorkBuddy 的完整能力。派活的时候我不会把四个环节都写死。我只会说清楚目标和交付物中间的步骤让 Agent 自己拆。这是用 Agent 和用普通工具最大的思维差异——你要学会给目标不给步骤。当然如果某个环节有特殊要求比如报告必须包含某个维度那就在目标里点明。6.2 技能调用的观察与干预任务跑起来之后我会观察它调用了哪些技能、顺序对不对。如果发现它用了不合适的技能或者顺序有问题我会中途干预。但干预要克制不要每一步都插手否则就失去了用 Agent 的意义。我的原则是只要大方向对中间的小偏差让它自己调整。这里有个经验第一次跑新类型任务时全程盯着。因为新任务可能触发你没想到的技能组合出问题的概率高。跑顺了之后同类任务就可以放手让它自己跑。我现在大部分常规任务都是派完就不管过一会儿看结果。6.3 结果验收与迭代结果出来之后别急着用。先检查几个点格式对不对、数据准不准、有没有编造的内容。Agent 有时候会为了完成任务而编造信息这是必须防的。我一般会抽查关键数据确认来源可靠。如果结果不理想不要直接重跑而是分析问题出在哪。是规则没覆盖到是技能选错了还是任务描述有歧义找到原因针对性调整比盲目重跑有效得多。我见过有人结果不好就反复重跑跑了十遍还是那样因为根因没解决。7. 那些官方不会告诉你的坑7.1 缓存与性能的隐形关系WorkBuddy 用久了会变慢很多人以为是电脑问题其实是缓存堆积。缓存目录里的文件会越来越多影响读写效率。我的做法是定期清理缓存频率大概两周一次。清理前确认没有正在跑的任务清理后第一次启动会慢一点之后就恢复正常。另外缓存目录和程序目录最好分开。放一起的话清理缓存时容易误删程序文件。这个坑我踩过一次清理完发现程序起不来了只能重装。7.2 技能冲突与静默失败装了两个功能重叠的技能可能出现静默失败——任务看起来跑完了但结果是错的而且没有任何报错。这种问题最难排查因为表面上一切正常。我的应对方法是同类技能只留一个从源头上避免冲突。如果确实需要多个就在规则里明确指定用哪个。还有一种静默失败是技能依赖的外部服务不可用。技能本身没坏但它依赖的东西坏了结果就是任务跑不通。这种情况要看日志日志里通常有线索。养成看日志的习惯能帮你快速定位大部分问题。7.3 模型配置与任务失败的关联前面讲过 models.json这里补充一个实战经验任务失败时先怀疑模型配置。我遇到过好几次任务跑到一半失败排查半天发现是某个模型的配置有问题导致调用超时。把模型配置检查一遍往往能解决大部分莫名其妙的失败。具体检查什么模型是否可用、参数是否正确、是否有多个模型配置冲突。如果实在找不到原因把 models.json 恢复到一个已知可用的版本再逐个加回配置用排除法定位问题。7.4 规则与技能的优先级陷阱规则和技能都可能对输出有要求当两者冲突时谁优先这个问题的答案在不同版本里可能不一样而且官方文档往往不写。我的经验是不要制造冲突。写规则的时候避开技能已经定义好的部分只补充技能没覆盖的。这样就不会有优先级问题。如果实在需要覆盖技能的默认行为就在任务描述里明确说而不是靠规则去压。任务描述的优先级通常高于规则这是更可靠的做法。8. 进阶把 WorkBuddy 用出中台的感觉8.1 从个人工具到团队能力WorkBuddy 一个人用是工具一个团队用就是中台。区别在于能力是否被沉淀和复用。个人用的时候技能和规则都是自己攒的团队用的时候需要把这些沉淀成共享资产。我的做法是把团队通用的规则和技能整理成一套标准配置新成员进来直接导入省去从零摸索的时间。这个过程中文档化很关键。每个技能是干什么的、每条规则为什么这么定都要写清楚。不然新人看到一堆技能和规则根本不知道从哪下手。我们团队有一份内部说明记录了我们沉淀的所有技能和规则这份说明的价值随着时间越来越高。8.2 和其他工具的配合WorkBuddy 不是孤岛它需要和其他工具配合。热词里提到的codebuddy、cursor这些都是可以配合的对象。我的用法是WorkBuddy 负责流程编排和任务执行专业工具负责专业环节。比如代码相关的任务WorkBuddy 负责拆解和调度具体编码交给更专业的工具。这种配合的关键是接口清晰。WorkBuddy 要知道什么时候该把任务交给外部工具外部工具的结果要能顺畅回到 WorkBuddy。这需要在技能层面做好封装把外部工具包装成 WorkBuddy 能调用的技能。8.3 持续迭代的心态AI Agent 这个领域变化很快今天好用的配置明天可能就有更好的方案。我的心态是保持迭代但不盲目追新。新功能出来先小范围试确认有价值再全面铺开。不要因为出了新东西就把现有的稳定配置全推翻那样只会让自己一直在折腾。我自己的节奏是每个月花一点时间看看有没有值得升级的地方有就小步试没有就继续用现有的。这样既不会落后也不会被新东西牵着走。用 Agent 的最终目的是省事如果为了追新反而更累那就本末倒置了。9. 我踩过的几个具体坑和修复过程9.1 技能装了但调不动第一次遇到这个问题时我以为是技能本身有 bug重装了三次都没用。后来静下心来看日志发现是技能依赖的一个模型在 models.json 里配置不完整。补上缺失的字段后技能立刻就能用了。这个坑教会我技能调不动先查模型配置再查技能本身。9.2 任务跑一半卡住有一次任务跑到一半就不动了等了很久也没反应。排查发现是某个技能在等一个永远不会返回的外部调用。这种情况没有好的自动恢复机制只能手动终止任务然后检查那个技能依赖的外部服务。我的应对是给关键技能设置超时避免无限等待。9.3 输出格式总是不对有段时间 Agent 输出的格式总是不符合要求我以为是规则没写清楚反复改规则都没用。最后发现是某个技能的默认输出格式覆盖了我的规则。解决办法是在任务描述里明确指定格式而不是靠规则。这个坑让我明白规则不是万能的关键要求要在任务描述里说。9.4 缓存目录迁移失败想把缓存目录从 C 盘迁到 D 盘直接改了配置结果工作台起不来。原因是旧缓存还在原位置新配置指向了空目录程序找不到需要的文件。正确做法是先停程序迁移缓存文件再改配置。顺序错了就会出问题。10. 关于学习路径的一点个人建议热词里有workbuddy 从入门到精通 pdf 下载、workbuddy 教程这类搜索说明很多人想要一份系统的学习材料。我的建议是别指望一份文档就能精通这东西必须上手。看十篇教程不如自己跑通一个任务。我的学习路径是先跑通最简单的任务建立信心然后逐步加复杂度遇到问题就查、就问、就试最后尝试自己写技能、定规则把工作台改造成适合自己的样子。这个过程里记录很重要。我有个习惯每次踩坑和解决都记一笔时间长了就攒出一份自己的避坑清单。这份清单比任何通用教程都有用因为它是针对我的使用场景的。你也可以这么做用着用着你就成了别人眼里的WorkBuddy 老手。最后分享一个我自己的体会WorkBuddy 这类工具的价值不在于它有多强而在于你愿不愿意花时间把它调教成适合你的样子。默认配置能用但用不出彩。真正拉开差距的是那些愿意花时间定规则、写技能、调配置的人。这个投入是值得的因为一旦调好它每天帮你省下的时间会持续累积。