1. 为什么我要认真写一份 WorkBuddy 实战笔记WorkBuddy 这个腾讯 AI 工作台刚出来的时候我其实没太当回事。市面上挂着“AI 工作台”“AI Agent”名头的产品太多了大多数用两天就吃灰。真正让我改变看法的是有一次需要批量处理几十份格式混乱的文档手动搞至少要一个下午我抱着试试的心态在 WorkBuddy 里配了个 Skill结果十几分钟就跑完了而且结果比我预期的还规整。从那之后我开始认真研究它的安装、配置、Skill 机制和缓存管理也踩了不少坑。这篇东西不是官方文档的复述是我自己从安装到日常使用、从 models.json 配置到 Skill 编写、从缓存目录迁移到并发调优的一整套实战记录。如果你刚接触 WorkBuddy或者已经装了但一直没跑顺又或者你在纠结它和 CodeBuddy 到底什么关系、Skill 到底怎么写才好用那这篇应该能帮你省下不少试错时间。我会把每一步的“为什么这么做”讲清楚而不是只丢一堆命令让你抄。需要先说明一点WorkBuddy 迭代很快界面和配置项可能和我写的时候有出入但底层的逻辑——模型接入、Skill 组织、缓存策略、Agent 调度——这些核心机制是相对稳定的理解了这些界面怎么变你都能自己摸过去。2. WorkBuddy 到底是什么和 CodeBuddy 什么关系2.1 一句话说清它的定位WorkBuddy 是腾讯推出的一款 AI 工作台产品核心思路是把大模型能力包装成一个个可复用的“Skill”再通过 Agent 调度把这些 Skill 串起来完成实际任务。你可以把它理解成一个“AI 员工的操作台”模型是大脑Skill 是技能包Agent 是那个决定先干什么后干什么的调度员。它和单纯的对话式 AI 最大的区别在于对话式 AI 你问一句它答一句任务一复杂就散架WorkBuddy 强调的是“把活干完”你给它一个目标它自己拆步骤、调 Skill、出结果。这也是为什么热词里反复出现“让 AI 真的下地干活”这种说法——大家苦于 AI 只会聊天久矣。2.2 和 CodeBuddy 的区别别再搞混了很多人搜“workbuddy和codebuddy”这俩确实容易混。简单说CodeBuddy 更偏向编码场景是给开发者写代码、改代码、做代码审查用的WorkBuddy 的覆盖面更宽文档处理、数据分析、流程自动化、内容生成都能干编码只是它能力的一部分。你可以理解为 CodeBuddy 是专精某一项技能的专家WorkBuddy 是能调度多种技能的工作台。实际使用中如果你主要就是写代码CodeBuddy 的针对性更强、上下文更聚焦但如果你需要的是“帮我把这批文件整理好顺便生成一份汇总报告”这种跨技能任务WorkBuddy 更合适。两者不是替代关系是场景分工。2.3 谁适合用谁可以先观望我个人的判断是这几类人收益最明显一是日常有大量重复性文档、表格、信息处理工作的人二是想把 AI 能力接进自己工作流、需要一定定制空间的人三是已经在用其他 AI 工具但觉得“不够自动化”的人。如果你只是偶尔问 AI 几个问题那用普通对话产品就够了WorkBuddy 的配置成本对你来说不划算。它的价值在于“重复使用”和“流程化”用一次就丢的场景体现不出优势。3. 安装与初始配置把地基打牢3.1 安装前的环境确认安装本身不复杂但有几个前置条件建议先确认不然装到一半卡住很烦。首先是系统版本Windows 建议 Win10 及以上macOS 建议较新的版本老系统可能在依赖库上出问题。其次是磁盘空间WorkBuddy 本体不大但缓存和模型相关文件会持续增长建议预留至少 10GB 以上的可用空间后面讲缓存目录迁移时会细说。网络环境这块我不展开只说一点首次安装和登录需要能正常访问服务端如果你所在网络有特殊限制可能会卡在登录环节这个自己判断。3.2 安装步骤与关键选择安装流程按引导走就行但有两个地方值得注意。第一是安装路径默认路径通常在系统盘如果你系统盘空间紧张安装时就可以改到其他盘省得后面再迁移。第二是是否勾选“开机自启”我的建议是如果你不是每天都用先别勾等确认要长期用了再开不然它会常驻后台占资源。装完之后第一次启动会引导你登录和做基础配置。这里有个小细节初始配置里会让你选一些偏好比如默认语言、常用场景这些选项会影响它给你推荐的 Skill 类型认真选一下后面省事。3.3 首次登录后的必做检查登录进去别急着用先做三件事。第一进设置里看一眼版本号确认是最新版老版本可能有已知问题。第二检查模型接入状态也就是 models.json 相关的配置是否正常这个后面单独讲。第三跑一个最简单的任务测试一下比如让它总结一段文字确认整条链路是通的。我见过不少人装完直接上复杂任务结果出问题分不清是配置问题还是任务本身的问题先用简单任务验证链路是排查问题的基本盘。4. models.json 配置模型接入的核心4.1 models.json 是干什么的models.json 是 WorkBuddy 用来管理模型接入的配置文件。你可以把它理解成一张“模型通讯录”里面记录了你要用哪些模型、每个模型的接入方式、参数怎么设。WorkBuddy 本身不绑定某一个模型它通过这个配置文件去调用你指定的模型服务。这个设计的好处是灵活你可以根据任务类型切换不同模型——简单的整理任务用轻量模型省钱省时间复杂的推理任务用更强的模型保证质量。坏处是配置有门槛写错了就连不上而且报错信息有时候不够直观。4.2 配置文件的基本结构一个典型的 models.json 结构大致包含模型标识、接入地址、认证信息、默认参数这几块。我不贴具体字段值因为不同版本字段名可能有差异你以官方最新说明为准。但结构逻辑是通用的每个模型是一个对象对象里有唯一标识你给它起的名字、调用所需的连接信息、以及温度、最大输出长度这类参数。配置的时候有个原则先配一个能跑通的再扩展。别一上来配五六个模型出了错你都不知道是哪个的问题。配好一个测试通过再复制结构改第二个。4.3 参数怎么设才合理温度这个参数最容易被忽视。做文档整理、信息提取这类需要稳定输出的任务温度调低让它别乱发挥做创意生成、头脑风暴这类任务温度可以适当调高。最大输出长度要根据任务预估设太小会被截断设太大浪费资源。我踩过的坑是一开始所有任务都用同一套参数结果整理类任务偶尔会“自作主张”改内容后来把温度降下来就稳了。参数不是设一次就完事要按任务类型分别调。提示改完 models.json 后一定要重启或重新加载配置很多“改了没生效”的问题都是忘了这一步。5. Skill 机制WorkBuddy 的真正杀手锏5.1 Skill 到底是什么Skill 是 WorkBuddy 里最核心的概念。简单说一个 Skill 就是一套封装好的能力它定义了“输入什么、怎么处理、输出什么”。你可以把 Skill 想成一个函数给它规定的参数它返回规定的结果。Agent 的工作就是决定在什么时机调用哪个 Skill、把上一个 Skill 的输出传给下一个。热词里“skill编码247”“book to skill”“去ai味的skill”这些说的都是不同场景下怎么设计和编写 Skill。Skill 写得好不好直接决定 WorkBuddy 好不好用。5.2 Skill 的几种来源Skill 大致有三个来源。一是官方或社区提供的现成 Skill装上就能用适合常见需求。二是你自己根据特定任务编写的自定义 Skill这是发挥 WorkBuddy 价值的关键。三是把外部能力包装成 Skill 接进来比如你有一套自己的处理脚本可以封装成 Skill 让 Agent 调用。新手建议先从现成 Skill 用起熟悉了机制再自己写。直接上手写自定义 Skill容易因为不理解调度逻辑而写出跑不通的东西。5.3 一个好 Skill 的判断标准我总结了几条输入输出定义清晰不模棱两可职责单一一个 Skill 只干一件事对异常输入有处理不会一遇到意外格式就崩有明确的失败反馈出问题能知道卡在哪。反面例子是一个 Skill 想干太多事既解析文档又生成报告还发邮件这种一旦中间某步出错排查起来非常痛苦。拆成三个 Skill 让 Agent 串起来反而更稳。6. 手把手写一个能用的 Skill6.1 从需求到 Skill 设计的转化假设我有个需求把一堆格式不统一的文本统一整理成固定结构的条目。第一步不是写代码是想清楚输入是什么、输出是什么、中间要做哪些判断。输入可能是各种格式的文本输出是结构化条目中间要处理的是格式识别和字段提取。把这个想清楚Skill 的骨架就有了。很多人写 Skill 卡壳不是技术问题是需求没拆清楚。6.2 编写过程中的关键决策写的时候有几个决策点。第一格式识别用规则还是用模型判断规则快但覆盖不全模型灵活但慢且可能不稳定。我的做法是常见格式用规则兜底用模型。第二字段缺失怎么办是报错还是留空还是猜这取决于你的下游怎么用如果下游能处理空值就留空不能就报错。第三输出格式用什么JSON 最通用但如果下游是人看可能 Markdown 更合适。这些决策没有标准答案取决于你的具体场景但一定要有意识地做决策而不是随手写。6.3 测试与迭代Skill 写完必须测而且要拿真实数据测不能只用你构造的理想输入。我一般会准备三类测试数据标准格式的、边界情况的比如字段特别多或特别少、异常格式的比如完全不符合预期的输入。三类都过了才算基本可用。迭代的时候记录每次改了什么、为什么改不然改多了自己都忘了当初为什么那么设计。7. 缓存目录迁移别让系统盘爆掉7.1 为什么要改缓存目录WorkBuddy 运行过程中会产生大量缓存包括临时文件、中间结果、日志等。默认这些都在系统盘的用户目录下用久了系统盘空间会被吃掉一大块。热词里“workbuddy怎么更改系统缓存目录”被反复搜说明这是普遍痛点。我的建议是只要你打算长期用装完就把缓存目录改到空间充裕的盘。别等系统盘红了再改那时候迁移数据更麻烦。7.2 迁移的正确步骤迁移的核心是两步改配置指向新目录把旧数据搬过去。改配置一般在设置里能找到缓存路径选项改成新路径。然后关闭 WorkBuddy把旧缓存目录的内容整体复制到新目录确认复制完整后再删旧的。这里有个坑一定要先关程序再操作程序运行中迁移会导致文件占用和状态不一致。另外复制而不是剪切确认新目录能用之后再删旧的给自己留后路。7.3 迁移后的验证迁移完重启跑个任务看是否正常然后去新目录确认有新的缓存文件生成。如果任务正常但新目录没文件说明配置没生效可能改错了地方或者没重启。8. 并发与性能Agent 扛并发的那些事8.1 并发问题的来源热词里“ai agent 怎么扛并发”是个真问题。WorkBuddy 跑单个任务时很顺但当你同时丢给它多个任务或者一个任务里 Agent 要并行调用多个 Skill 时问题就来了模型接口有速率限制、本地资源有上限、任务之间可能互相干扰。并发问题的本质是资源竞争。模型调用次数、内存、CPU、磁盘 IO任何一项到瓶颈整体就会变慢甚至失败。8.2 实用的并发控制思路第一控制同时运行的任务数别一次性丢几十个。第二对模型调用做排队或限流避免触发服务端的速率限制。第三把耗资源的 Skill 和轻量 Skill 错开调度。第四给任务设置合理的超时避免一个卡住的任务拖垮整体。这些不是 WorkBuddy 独有的是任何 Agent 系统都要面对的。理解了这个你调优就有方向。8.3 性能观测的基本方法想知道瓶颈在哪得会看。关注几个指标单个任务耗时、模型调用次数和耗时占比、内存占用峰值、失败率。WorkBuddy 的日志里通常有这些信息养成看日志的习惯比瞎猜强。9. 常见问题与排查速查9.1 安装与登录类问题现象可能原因处理思路安装卡住网络或磁盘空间不足检查网络清理磁盘登录失败网络限制或账号问题确认网络环境核对账号启动闪退依赖缺失或版本冲突重装确认系统版本9.2 配置与模型类问题现象可能原因处理思路模型连不上models.json 配置错误核对字段先测单个模型改了配置没生效没重启或没重载重启程序输出被截断最大输出长度设太小调大该参数9.3 Skill 与任务类问题现象可能原因处理思路Skill 跑不通输入输出定义不清检查接口定义用简单输入测任务结果不稳定温度过高或 Skill 职责太杂降温度拆 Skill任务卡住不结束缺超时或死循环设超时检查 Skill 逻辑9.4 我踩过的几个典型坑第一个坑是配置文件里一个标点写错找了半天才发现。第二个坑是缓存目录迁移时没关程序导致状态混乱重装了一次。第三个坑是 Skill 里没处理空输入遇到空数据直接崩。这些坑的共同点是都不是大问题但都因为没按规范操作而放大成了大问题。提示遇到问题先看日志日志里 90% 的情况已经告诉你原因了别急着上网搜。10. 一些让 WorkBuddy 更好用的个人经验用到现在我最大的体会是WorkBuddy 的价值不在于它自带多少能力而在于你能把多少自己的流程沉淀成 Skill。现成 Skill 解决通用问题自定义 Skill 解决你的专属问题后者才是拉开效率差距的地方。另外别追求一次配到完美。我一开始想把所有参数、所有 Skill 都调到最优结果花了很多时间在配置上实际用起来发现很多优化根本用不上。先用起来遇到问题再针对性优化这个节奏更合理。还有一点定期清理缓存和日志。用久了这些文件会积累很多占空间也影响排查。我一般一个月清一次保持环境干净。最后分享一个小技巧给常用的任务组合建一个“模板”把常用的 Skill 顺序和参数存下来下次直接调用省得每次重新配。这个习惯帮我省了大量重复配置的时间。