★ FEATURED ARTICLE 1. 为什么我要认真写这篇 WorkBuddy 实战指南WorkBuddy 这个腾讯出的 AI 工作台我从它内测阶段就开始折腾到现在团队里十几个人的日常任务流基本都跑在上面。说实话第一次打开它的时候我是有点懵的——界面看着不复杂但真要让它下地干活中间踩的坑比我预想的多得多。网上那些三分钟上手的教程基本只告诉你点哪个按钮没人讲清楚 models.json 到底怎么配、Skill 的触发边界在哪里、缓存目录塞满 C 盘之后该怎么办。这篇东西就是把我这段时间的实操经验完整倒出来。从安装、模型配置、Skill 编写、工作台搭建到并发扛不住、Skill 不触发、缓存爆盘这些真实问题我都会给到具体的排查路径和解决方案。适合两类人看一类是刚接触 WorkBuddy、想把它当成日常生产力工具的个人用户另一类是打算在团队里落地 AI Agent 工作流、需要搞清楚 Skill 机制和中台思路的技术同学。不管你是想让 AI 帮你写周报、做备课、跑数据分析还是想搭一套能扛住多人并发的智能体中台下面的内容应该都能直接抄作业。我尽量不写那种官方文档翻译式的废话每个结论背后我都会说清楚为什么这么做、不这么做会出什么问题。有些地方我会给出具体的配置片段和参数计算过程你可以直接复制去改。2. WorkBuddy 到底是什么和 CodeBuddy 什么关系2.1 一句话讲清 WorkBuddy 的定位WorkBuddy 本质上是腾讯做的一个AI 工作台核心能力是把大模型、工具调用Tool Use、Skill 插件、任务编排这几样东西打包成一个可视化的工作环境。你可以把它理解成一个AI Agent 的操作系统——模型是发动机Skill 是各种功能模块工作台就是仪表盘和方向盘。它解决的问题很具体以前你想让 AI 帮你干一件稍微复杂的事比如读一份 PDF 报告提取关键数据生成图表再写一段分析发到群里你得自己写代码串 LangChain、调 API、处理各种异常。WorkBuddy 把这些编排能力做成了配置化的东西你定义好 Skill配好模型剩下的流程它帮你跑。和 CodeBuddy 的关系很多人搞混。简单说CodeBuddy 更偏向代码场景的 AI 助手聚焦在写代码、改 bug、代码审查这条线上WorkBuddy 则是通用工作场景面向的是文档处理、数据分析、任务自动化、多步骤 Agent 编排这些更宽的需求。两者底层可能共享一些模型调度和 Skill 框架的能力但定位不一样。你如果是纯写代码CodeBuddy 更顺手你要做的是让 AI 处理各种杂活WorkBuddy 更合适。当然实际用下来两者在 Skill 生态上有一些互通的地方这个后面讲 Skill 的时候会提到。2.2 为什么是工作台而不是聊天框这是我觉得 WorkBuddy 最值得讲的设计思路。市面上的 AI 产品大部分是聊天框形态——你问一句它答一句。但真实工作里很多事情不是一问一答能解决的它需要多步骤、有状态、能调用外部工具。举个例子你要做一份竞品分析。聊天框模式下你得手动把资料喂进去问一轮再追问一轮来回好几次。工作台模式下你可以定义一个 Skill输入竞品名称它自动去抓公开信息、整理成结构化表格、生成对比分析、最后输出一份带图表的文档。整个过程你只需要点一次。这个差异背后是AI Agent的思路——Agent 不是被动应答而是能自主规划步骤、调用工具、根据中间结果调整策略。WorkBuddy 的工作台形态就是把这个 Agent 能力产品化了。你不需要懂 LangGraph 怎么画状态图通过 Skill 配置就能实现类似的效果。2.3 谁适合用谁可以先观望我观察下来这几类人用 WorkBuddy 收益最明显内容工作者需要批量处理文档、做资料整理、生成初稿的人。Skill 可以把重复的写作流程固化下来。数据分析岗经常要跑重复的数据清洗和报表生成把流程做成 Skill 之后一键复用。团队管理者想把某些固定流程比如周报汇总、项目进度追踪自动化WorkBuddy 的中台能力可以支撑多人共用。技术爱好者想研究 AI Agent 怎么落地WorkBuddy 是个不错的实验场比从零搭 LangChain 快得多。如果你只是偶尔问 AI 几个问题没有重复性的工作流那聊天框产品可能更轻便。WorkBuddy 的价值在于流程固化和多步骤编排用不上这两点的话它的学习成本就不划算了。3. 安装与初始配置别一上来就踩缓存目录的坑3.1 安装前的环境准备WorkBuddy 目前有国内版和国际版两个分发渠道功能上有些差异国际版在部分模型接入上更灵活一些。安装包本身不大但安装路径和缓存目录的选择非常关键这是我踩过的第一个大坑。默认安装会往系统盘写缓存包括模型临时文件、Skill 运行日志、任务中间产物。如果你像我一样习惯把软件装 D 盘但没改缓存目录用不了几天 C 盘就会报警。我实测过一个中等强度的使用场景——每天跑二十来个任务一周下来缓存能涨到 8 到 12 GB。所以安装前先规划好目录。建议的目录规划目录类型建议位置说明程序安装目录非系统盘如 D:\Apps\WorkBuddy避免占用 C 盘空间缓存目录独立数据盘或大容量分区单独设置方便清理Skill 存放目录与缓存分开便于版本管理和备份日志目录可放缓存目录下排查问题时需要3.2 更改系统缓存目录的正确姿势很多人找不到改缓存目录的入口因为它在设置里藏得比较深。路径大致是设置 → 高级 → 存储 → 缓存位置。但光改这里还不够有几个地方要一起改否则缓存还是会往老地方写。我整理了一个完整的修改清单主缓存目录设置里的缓存位置改成你规划好的路径。模型缓存如果单独有模型下载缓存的设置项也要改。模型文件动辄几个 GB这个最占地方。临时文件目录部分版本会读取系统环境变量里的 TEMP如果你不想动系统变量就在 WorkBuddy 自己的设置里覆盖。Skill 运行沙箱目录Skill 执行时会产生临时文件确认它的工作目录也在你规划的分区里。改完之后一定要重启应用然后跑一个任务验证缓存是不是写到了新位置。我见过有人改完没重启以为生效了结果缓存还是往 C 盘塞。提示改缓存目录之前先把已有缓存迁移过去或者直接清空重来。直接改路径不迁移的话历史任务的中间产物会找不到某些依赖缓存的任务会报错。3.3 首次启动的必做配置第一次打开 WorkBuddy别急着建任务先把这几项配好模型接入这是核心。WorkBuddy 支持接入多种模型你需要配置 models.json下一节详细讲。默认工作区设置一个你常用的项目目录新建任务时默认在这里。快捷键工作台操作频繁把常用功能绑上快捷键效率提升明显。自动更新策略建议设为手动更新。自动更新有时候会在你跑长任务的时候触发重启很烦。4. models.json 配置详解模型接入的核心4.1 models.json 是什么为什么重要models.json 是 WorkBuddy 的模型配置文件决定了你的工作台能用哪些模型、每个模型的参数怎么设、调用优先级如何。这个文件配不好后面 Skill 跑起来各种报错而且报错信息往往很隐晦排查起来费劲。它的基本结构是一个 JSON 数组每个元素描述一个模型接入点。核心字段包括模型标识、接入方式、上下文长度、并发限制、适用场景标签等。我下面给一个我实际在用的配置模板你可以照着改。{ models: [ { id: primary-chat, provider: your-provider, model: your-model-name, contextWindow: 128000, maxOutputTokens: 8192, concurrency: 4, tags: [chat, reasoning], priority: 1 }, { id: fast-task, provider: your-provider, model: your-fast-model, contextWindow: 32000, maxOutputTokens: 4096, concurrency: 8, tags: [fast, extraction], priority: 2 } ] }4.2 关键字段的含义与设置逻辑contextWindow上下文窗口这个值必须和模型实际支持的一致填大了会报错填小了浪费能力。如果你不确定查模型官方文档别猜。我见过有人把 32K 的模型填成 128K结果长文档任务跑到一半直接崩。concurrency并发数这是最容易被忽视但影响最大的字段。它决定了这个模型接入点同时能处理多少个请求。设太小多任务排队等设太大触发上游限流反而更慢。我的经验值是先设一个保守值比如 2 到 4跑一段时间看日志里的限流报错再逐步往上调。tags场景标签这个字段是给 Skill 用的。Skill 在定义时可以指定我需要一个带 reasoning 标签的模型WorkBuddy 就会从匹配标签的模型里按 priority 选。合理打标签能让不同类型的任务自动路由到合适的模型省钱又提速。priority优先级数字越小优先级越高。同类标签下优先用高优先级的模型。4.3 多模型路由的实战策略我现在的配置是三层路由第一层快速模型处理简单的信息提取、格式转换、分类判断。这类任务量大但简单用便宜快的模型。第二层主力模型处理需要推理、写作、复杂分析的任务。这是日常用得最多的。第三层长上下文模型专门处理超长文档、大代码库分析。平时不用需要时才调。这样分层的好处是成本可控。如果所有任务都走最强模型账单会很难看。分层之后大概 60% 的任务走快速模型30% 走主力10% 走长上下文整体成本能降一半以上。注意改完 models.json 后WorkBuddy 需要重新加载配置。有些版本是自动热加载有些需要重启。改完先跑一个测试任务确认新配置生效别直接上生产任务。5. Skill 机制深度拆解让 AI 真的下地干活5.1 Skill 到底是什么Skill 是 WorkBuddy 里最核心的概念也是最能体现AI Agent思路的地方。简单说Skill 就是一段可复用的能力封装——它定义了当遇到某类任务时AI 应该按什么步骤、调用什么工具、产出什么结果。你可以把 Skill 理解成给 AI 写的操作手册。没有 Skill 的时候AI 每次都要从零理解你的需求有了 Skill它直接按预设的流程走稳定性和效率都高得多。Skill 的构成一般包括几个部分触发条件什么时候用这个 Skill、执行步骤具体做什么、工具依赖需要调用哪些外部能力、输出格式结果长什么样。有些高级 Skill 还会包含条件分支和错误处理逻辑。5.2 Skill 的触发机制与边界这是很多人搞不明白的地方——为什么我写了 SkillAI 有时候用有时候不用Skill 的触发靠的是语义匹配。WorkBuddy 会把你的输入和 Skill 的描述做匹配判断该不该触发。所以 Skill 的描述写得越清晰、触发条件定义得越明确命中率越高。我踩过的坑一开始我把 Skill 描述写得很宽泛比如处理文档相关任务结果它经常在不该触发的时候触发该触发的时候又没反应。后来改成具体的触发短语和场景描述命中率立刻上来了。提高触发准确率的几个技巧在描述里写清楚典型输入比如当用户提到生成周报汇总本周工作时触发。设置排除条件明确什么情况下不触发避免误伤。用标签辅助给 Skill 打上场景标签和模型的 tags 对应起来。测试用例写几个典型输入反复测试触发情况根据结果调整描述。5.3 从零写一个可用的 Skill我拿一个实际例子来讲——会议纪要整理 Skill。需求是输入一段会议录音转写文本输出结构化的纪要包含议题、结论、待办事项。第一步定义触发条件。描述写成当用户提供会议记录、录音转写文本或提到整理纪要会议总结时触发。第二步拆解执行步骤识别会议的基本信息时间、参与人、主题。按议题分段提取每个议题的讨论要点。识别结论性表述归纳成结论列表。提取待办事项标注负责人和时间节点如果有。按固定格式输出。第三步定义输出格式。我一般用 Markdown 模板这样结果直接能用## 会议纪要 **时间** **参与人** **主题** ### 议题一[议题名称] - 讨论要点 - 结论 ### 待办事项 | 事项 | 负责人 | 截止时间 | |------|--------|---------| | | | |第四步测试和迭代。拿几段真实的会议记录跑看输出质量哪里不对就调整步骤描述。我大概迭代了四五版才稳定下来。5.4 Skill 开发指南几个提升质量的关键点写多了 Skill 之后我总结出几条经验步骤要原子化。一个步骤只做一件事别把提取信息并生成报告揉成一步。拆得越细AI 执行越稳定出错也越好定位。给例子。在 Skill 描述里放一两个输入输出的示例AI 的模仿能力很强有例子比纯文字描述效果好得多。处理异常。想清楚如果输入格式不对怎么办如果某个字段缺失怎么办在 Skill 里写明兜底逻辑。控制输出长度。不限制的话AI 容易啰嗦。在 Skill 里明确输出格式和长度要求。版本管理。Skill 是要迭代的建议用 Git 管理 Skill 文件每次改动都有记录出问题能回滚。6. 工作台搭建实战从个人用到团队中台6.1 个人工作台的最小可用配置如果你是自己用不用搞太复杂。我的建议是先搭一个最小可用的工作台包含三五个高频 Skill跑顺了再扩展。我的个人工作台核心 Skill 清单Skill 名称用途触发频率文档摘要长文档快速提炼要点每天多次会议纪要整理会议记录每周几次数据清洗处理表格数据每周几次周报生成汇总本周任务产出每周一次资料检索整理按主题搜集整理信息按需这五个 Skill 覆盖了我 80% 的日常需求。先把这几个打磨好比铺一堆半成品 Skill 有用得多。6.2 团队中台的搭建思路团队用的话要考虑的东西就多了。核心问题是怎么让多个人共用一套 Skill 和模型资源又不互相干扰。我的做法是分层基础层统一的模型接入配置models.json由管理员维护所有人共用。公共 Skill 层团队通用的 Skill比如项目周报、代码审查、文档规范检查放在共享目录。个人 Skill 层每个人自己的私有 Skill放在各自的工作区。任务队列多人同时跑任务时需要一个调度机制避免资源抢占。这个结构的关键是权限隔离和资源配额。公共 Skill 只读个人 Skill 可写模型调用按人头分配配额防止一个人把资源占满。6.3 AI Agent 怎么扛并发实测有效的几个策略AI Agent 怎么扛并发是个高频问题我在团队落地时专门测过。结论是并发瓶颈通常不在模型本身而在任务编排层和工具调用层。几个实测有效的策略任务分级。把任务按紧急程度和资源消耗分级高优先级任务走独立队列低优先级的排队等。这样关键任务不会被批量任务堵住。结果缓存。很多任务是重复的比如查某个数据同样的输入没必要每次都调模型。加一层缓存命中直接返回能省掉大量并发压力。异步化。长任务不要同步等结果改成提交后异步执行完成后通知。这样前端不会卡住后端也能更灵活地调度。限流与退避。给每个模型接入点设并发上限超了就排队或退避重试。别硬扛硬扛的结果是上游限流所有任务一起变慢。批处理。能合并的请求合并。比如十个文档摘要任务可以合并成一次调用处理比十次单独调用省资源。我实测下来加了缓存和任务分级之后同样的硬件资源能支撑的并发量大概提升了三倍。7. 常见问题与排查技巧实录7.1 Skill 不触发怎么办这是最高频的问题。排查顺序检查 Skill 是否启用。有时候改配置后忘了启用或者被其他操作禁用了。检查触发描述。用你的实际输入去比对 Skill 描述看语义匹配度够不够。不够就改描述把典型输入写进去。检查标签冲突。如果多个 Skill 标签重叠可能互相抢触发。给它们加区分度。看日志。WorkBuddy 的日志里会记录 Skill 匹配过程能看到为什么没触发。7.2 缓存爆盘怎么处理前面讲过改缓存目录但如果已经爆了处理步骤是先停掉正在跑的任务。找到缓存目录看哪些子目录占空间最大。模型缓存一般可以安全清理下次用会重新下载。任务中间产物看情况已完成任务的可以清未完成的别动。清理完改缓存目录到新位置重启。我建议设个定期清理的任务每周自动清一次过期缓存省得手动处理。7.3 模型调用报错的常见原因报错类型常见原因解决方向上下文超限contextWindow 配置与实际不符核对模型文档改配置限流concurrency 设太大调低并发加退避认证失败接入凭证过期或错误检查凭证配置超时任务太复杂或网络问题拆分任务检查网络格式错误输出格式不符合 Skill 要求调整 Skill 的输出约束7.4 几个独家避坑技巧技巧一Skill 描述里加反例。除了写什么时候触发再写一句什么时候不触发能显著降低误触发。技巧二模型配置留一手。别把所有模型都配成最高优先级留一个备用接入点主接入点出问题时能快速切换。技巧三任务日志分级。把日志分成 debug、info、warn、error 四级平时只看 warn 以上排查问题时再开 debug。不然日志刷屏真正的问题反而被淹没。技巧四Skill 先小范围测。新写的 Skill 别直接上生产先拿几个测试用例跑确认稳定了再放开。技巧五定期备份配置。models.json 和 Skill 目录定期备份改坏了能快速恢复。我就吃过没备份的亏一次误操作把配置清了重建花了半天。8. 我个人的一些使用体会WorkBuddy 这类 AI 工作台用得好不好很大程度上取决于你愿不愿意花时间把流程固化下来。我见过很多人装完就用默认配置跑几个任务觉得也就那样然后就放着了。但真正把它用出价值的人都是愿意花时间打磨 Skill、调优配置的。我自己的转折点是给团队搭了一套周报自动汇总的 Skill。以前每周五下午要花一个多小时手动整理现在点一下五分钟出结果。就这一件事让我觉得前面折腾配置的时间全值回来了。另外提醒一句别追求一步到位。我一开始想搭一个全能工作台结果 Skill 写了一堆每个都不精。后来砍到五个核心 Skill反复打磨反而好用得多。工具是为人服务的够用就好别为了折腾而折腾。如果你也在用 WorkBuddy或者正在考虑搭 AI Agent 工作流欢迎交流踩坑经验。这东西迭代很快今天的最佳实践可能下个月就过时了保持折腾的心态最重要。
阅读完成 · 觉得有帮助？
