1. 先搞清楚 WorkBuddy 到底是个什么东西很多人第一次听到 WorkBuddy 这个名字会下意识把它归类成又一个套壳聊天窗口。我一开始也这么想直到真正把它装到工作机上、配好 models.json、跑通第一个 Skill 之后才发现它和普通对话式工具完全不是一回事。WorkBuddy 是腾讯推出的 AI 工作台核心定位是把大模型能力、本地文件系统、可复用的 Skill 脚本、以及多模型接入配置整合到一个桌面端环境里让你不是跟 AI 聊天而是让 AI 在你的机器上干活。这个区别非常关键。聊天窗口里的 AI 只能给你建议WorkBuddy 里的 AI Agent 能读你的文件、改你的配置、按你定义的 Skill 流程一步步执行任务。它更像是一个可编程的助手运行时而不是一个问答机器人。关键词里反复出现的 AI Agent、Skill、models.json其实就是这个工作台的三根支柱Agent 负责决策和调度Skill 负责把重复劳动固化成可调用单元models.json 负责告诉它用哪个模型、走哪条通道。适合谁来用我观察下来大致分三类。第一类是每天要处理大量重复文本、表格、代码的职场人比如运营、产品、研发他们最需要的是把一件事描述一次以后自动跑。第二类是想入门 AI Agent 开发但不想一上来就啃框架文档的开发者WorkBuddy 的 Skill 机制是一个很好的过渡你写的是接近自然语言加少量结构化配置的东西但背后跑的是真正的 Agent 调度逻辑。第三类是把 WorkBuddy 当个人工作台来搭的人比如用它管理笔记、整理资料、批量处理文件甚至有人研究能不能接行情数据做辅助分析——这类需求能不能成后面我会专门讲边界。需要先泼一盆冷水WorkBuddy 不是装上就自动变聪明的魔法盒。它的能力上限取决于三件事——你接的模型够不够强、你写的 Skill 够不够清晰、你给的上下文够不够准。我见过太多人装完之后随便问两句觉得也就那样然后卸载。问题不在工具在于他们没跨过配置和Skill 编写这两道门槛。这篇就把这两道门槛连同中间所有的坑一次讲透。2. 安装与首次配置那些文档不会告诉你的细节2.1 安装前的环境自查清单安装本身不复杂但装之前的准备工作决定了你后面会不会反复重装。我踩过的第一个坑就是没检查磁盘和权限装到一半失败残留文件又没清干净第二次装直接报冲突。先确认三件事。第一系统盘剩余空间。WorkBuddy 本体加上模型缓存、日志、Skill 运行产生的临时文件实际占用会比你预期的大不少建议至少留出 20GB 以上。第二当前账户是否有对安装目录和目标工作目录的读写权限。如果你在公司电脑上、账户是受限权限安装到系统目录大概率会失败这种情况直接装到用户目录下。第三网络环境是否稳定。首次启动往往需要拉取一些基础资源网络抖动会导致初始化不完整表现就是界面能打开但功能报错。提示安装路径尽量不要带中文和空格。这不是 WorkBuddy 独有的问题但它在处理本地文件路径时对特殊字符比较敏感带中文路径出现过 Skill 读取文件失败的情况。2.2 首次启动后的三件事装完第一次打开别急着聊天。按顺序做这三件事能省掉后面 80% 的困惑。第一件找到并理解 models.json。这个文件是 WorkBuddy 的模型接入配置中心它决定了你的 Agent 用哪个模型、走什么接口、带什么参数。文件结构通常是 JSON 格式里面会有模型名称、接口地址、密钥字段、以及一些可选参数比如温度、最大输出长度。你要做的是把可用的模型信息填进去保存后重启或重新加载配置。很多人卡在这一步是因为不知道字段含义随便填导致调用失败。第二件确认默认工作目录。WorkBuddy 的 Agent 读写文件是相对于某个工作目录的这个目录如果没设对你会遇到AI 说它改了文件但你在别处找不到的诡异现象。建议单独建一个干净的目录作为工作区不要直接指向整个用户目录或桌面避免 Agent 误操作波及重要文件。第三件跑一个最小验证。新建一个文本文件写一句话然后让 Agent 读取并总结。这一步能同时验证模型接入是否正常、文件权限是否正常、Agent 调度是否正常。三个都通过说明基础环境没问题可以进入下一步。2.3 models.json 的字段逻辑与常见填错models.json 是新手最容易翻车的地方我把它拆开讲。一个典型的配置里每个模型条目大致包含这几类信息标识名你给这个模型起的内部名字、接口地址请求发到哪里、认证信息密钥或令牌、模型标识对方服务认识的模型 ID、以及可选的生成参数。填错的高频点有三个。一是把你起的名字和对方认识的模型 ID搞混前者随便起后者必须和服务商文档一致填错就是 404 或模型不存在。二是认证信息格式有的要求带特定前缀有的直接填原始密钥多一个空格都会失败。三是接口地址结尾的斜杠有的服务对结尾斜杠敏感多一个少一个行为不同。我的建议是第一次配置只填一个模型跑通之后再加第二个。一次填五个然后全部报错你根本不知道是哪个的问题。跑通一个之后复制它的结构改字段出错概率大幅下降。2.4 更改系统缓存目录的正确姿势热搜里有人问WorkBuddy 怎么更改系统缓存目录这确实是个真实痛点因为默认缓存目录往往在系统盘用久了会把 C 盘吃满。正确做法不是直接剪切文件夹那样会导致索引失效。稳妥的流程是先在设置或配置文件里找到缓存路径配置项把它改成你想要的目录保存。然后重启 WorkBuddy让它在新位置重建缓存结构。最后再手动清理旧目录里的残留。顺序反了就会出现改了路径但程序还在读旧缓存或者新旧缓存打架的情况。改完之后建议观察一两天确认新目录确实在增长、旧目录不再变化再彻底删除旧的。3. Skill 机制WorkBuddy 真正的生产力所在3.1 Skill 到底是什么为什么它比提示词重要如果说 Agent 是大脑Skill 就是肌肉记忆。提示词是你每次都要重新说一遍的话Skill 是你把这段话固化下来、起个名字、以后一句话就能调用。这是 WorkBuddy 区别于普通对话工具的核心。举个具体例子。你每天都要把一批会议记录整理成固定格式的纪要提取参会人、列出决议、标注待办。如果每次都用提示词你得把格式要求重复粘贴一遍还容易漏。写成 Skill 之后你只需要说用纪要 Skill 处理这个文件Agent 就会按你预设的流程走读文件、按规则提取、按模板输出。省的不只是打字时间更是每次都要重新交代一遍的心智负担。Skill 的本质是一段结构化的指令加可选的脚本逻辑。它可以是纯提示词封装也可以带实际执行的脚本比如调用某个命令、处理某类文件。关键词里出现的 skill 脚本、skill 开发指南、skill 插件说的都是这个体系的不同侧面。3.2 一个 Skill 的解剖结构虽然不同版本的 WorkBuddy 在 Skill 的具体写法上可能有差异但一个完整 Skill 通常包含这几个部分理解了它们你就能自己写。名称与描述名称是调用时的标识描述是给 Agent 判断什么时候该用这个 Skill的依据。描述写得越清楚Agent 越不容易用错或用漏。触发条件什么情况下启用。可以是关键词触发也可以是 Agent 根据任务语义自主判断。执行步骤核心部分一步步说明要做什么。这里要写得像给一个新同事交代任务具体、无歧义。输入输出约定输入是什么格式输出是什么格式。这一步很多人偷懒不写结果 Skill 跑出来的东西格式飘忽没法直接用。异常处理文件不存在怎么办、格式不对怎么办。写上这一条Skill 的健壮性会明显提升。我个人的经验是写 Skill 最忌讳我以为它懂。你觉得整理一下这三个字很清楚但 Agent 不知道你要整理成什么。把整理拆成删除空行、统一标点、按时间排序、输出为 Markdown 表格效果立刻不一样。3.3 从零写第一个 Skill 的完整过程假设我们要做一个日报汇总 Skill把一天里散落在多个文件里的工作记录合并成一份日报。步骤如下。第一步明确输入。假设输入是工作目录下若干以日期命名的 txt 文件。第二步明确输出。输出是一份 Markdown 格式的日报包含日期标题、按类别分组的条目、以及一个总结段落。第三步写执行步骤扫描目录、筛选当天文件、逐个读取、按预设类别归类、合并去重、生成总结、写入输出文件。第四步写异常处理如果没有当天文件输出提示而不是报错如果文件编码异常跳过并记录。写完之后一定要测试而且要用边界情况测试空目录、只有一个文件、文件内容超长、文件里有特殊字符。我第一版 Skill 就是没测空目录结果某天没记录时它直接报错中断体验很差。3.4 哪些 Skill 最值得先做热搜里问WorkBuddy 哪些 Skill 最好用这个问题没有标准答案但有一个判断原则优先做你每周都要重复三次以上、且步骤固定的事。按这个原则我推荐几个通用性强的方向。文本处理类比如格式统一、批量替换、提取关键信息。文件管理类比如按规则重命名、分类归档、批量转换格式。信息汇总类比如把多个来源的内容合并成一份结构化文档。代码辅助类比如按规范生成注释、检查命名、生成提交说明。不建议一上来就做特别复杂的 Skill比如涉及多步外部调用、复杂条件分支的。先把简单的做顺建立对 Skill 运行逻辑的直觉再往上叠复杂度。我见过有人第一个 Skill 就想做全自动工作流结果调试到崩溃最后放弃。循序渐进不是保守是效率。4. 把 WorkBuddy 用成真正的工作台Agent 调度与规则设定4.1 给 WorkBuddy 定规则让后续任务自动生效热搜里有一条给 workbuddy 定几条规则后续对所有任务都生效这其实点到了 Agent 使用的一个高级技巧全局规则。你可以在配置里设定一些长期有效的约束比如输出一律用中文涉及文件修改前先备份不确定时先询问而不是直接执行。这些规则一旦设定后续所有任务都会遵守不用每次重复交代。这个功能的价值在于一致性。人交代任务会累、会漏规则不会。我给自己定的几条规则里最有用的是修改任何文件前先在旁边生成一个 .bak 备份。就这一条帮我挽回了好几次误操作。另一条是输出结构化内容时优先用表格因为我后续要拿这些内容做二次处理表格比散文好解析。设定规则要注意别过度。规则太多太细Agent 每次都要花精力去满足反而影响主任务。我的建议是控制在五条以内只放那些违反了会很麻烦的硬约束。4.2 Agent 怎么扛并发一个被问烂但很重要的问题AI Agent 怎么扛并发是热搜里的高频问题。放到 WorkBuddy 的场景下这个问题要分两层看。第一层是模型接口层面的并发。如果你接的模型服务对并发请求有限制同时发起太多任务会被限流或排队。WorkBuddy 作为客户端能做的是控制同时运行的任务数量。实操上如果你要批量处理几十个文件不要一次性全丢进去分批处理每批控制在合理数量观察是否有失败。第二层是任务编排层面的并发。多个 Skill 同时读写同一批文件会出现竞争。比如两个任务同时改一个文件后写的覆盖先写的。解决办法是让任务之间尽量不共享文件或者串行执行有依赖关系的任务。我的实际做法是批量任务先小规模试跑确认稳定再放大有文件依赖的任务一律串行纯读取、无副作用的任务可以并行。这套原则不复杂但能避开绝大多数并发问题。4.3 多模型接入的取舍逻辑WorkBuddy 支持接入多个模型这带来一个现实问题什么任务用什么模型。我的取舍逻辑是这样的。需要强推理、复杂规划的任务用能力最强的模型哪怕慢一点、贵一点。这类任务数量少但价值高值得投入。格式转换、简单提取、批量处理这类任务用快而便宜的模型因为量大成本敏感。涉及代码的任务优先选代码能力强的模型。涉及长文档理解的任务优先选上下文窗口大的模型。配置上你可以在 models.json 里把多个模型都配好然后在具体任务或 Skill 里指定用哪个。不要所有任务都用同一个模型那是浪费。也不要频繁切换切换本身有认知成本。找到两三个主力模型覆盖大部分场景就够了。4.4 国际版与国内版的差异认知热搜里workbuddy 国际版出现多次说明有人关心版本差异。从使用角度看不同版本在可接入的模型、界面语言、部分功能可用性上可能有区别。我的建议是以你实际能稳定访问、能正常配置模型的那个版本为准不要为了追求某个版本而折腾到无法使用。工具的价值在于用起来不在于版本号。如果你在两个版本之间犹豫判断标准很简单哪个版本能让你顺利跑通 models.json 配置、能正常调用 Skill就用哪个。配置跑不通的版本功能再多也和你无关。5. 避坑实录我踩过的那些坑和排查链路5.1 配置改了不生效缓存与重启的坑这是最高频的坑。你改了 models.json保存然后发现行为没变。原因通常是配置被缓存了程序还在用旧配置。排查链路是这样的先确认你改的是程序实际读取的那个文件有时候存在多个同名文件在不同目录你改的不是生效的那个。确认文件位置后检查保存是否成功、格式是否合法JSON 多一个逗号都会导致解析失败而有些程序解析失败时会静默回退到默认配置表现就是改了没用。最后改完配置要重启或触发重新加载很多配置不是热生效的。我的习惯是改配置前先备份改完用工具校验 JSON 格式然后完整重启一次再验证行为。这套流程走下来基本不会再遇到改了不生效。5.2 Skill 调用错乱描述不清导致的误触发有一段时间我发现 Agent 老是调用错误的 Skill。排查后发现根因是 Skill 的描述写得太模糊两个 Skill 的描述有重叠Agent 分不清该用哪个。解决办法是让每个 Skill 的描述具备排他性。不要写处理文档要写把多个 txt 文件合并成一份 Markdown 日报。描述里带上具体的输入类型和输出类型Agent 判断时就有明确依据。如果两个 Skill 确实功能相近就在描述里写清楚各自的适用场景比如一个用于短文本快速处理一个用于长文档深度整理。这个问题给我的教训是Skill 的描述不是写给人看的备注是写给 Agent 看的判断依据。你怎么写它就怎么理解。5.3 文件操作翻车路径与权限的连环坑Agent 操作文件时翻车通常不是 Agent 笨是路径和权限没理清。常见表现有三种找不到文件、改了但找不到改在哪、没权限改。排查顺序先确认工作目录设置是否正确Agent 的相对路径是相对于工作目录的。再确认文件是否真的存在、文件名是否完全匹配大小写、扩展名。然后确认权限受限账户对某些目录没有写权限。最后确认是否有其他程序占用文件。预防措施比排查更重要。我现在的做法是所有 Agent 操作都在专门的工作目录里进行不碰系统目录和个人重要目录重要文件操作前自动备份批量操作前先用一两个文件试跑。这三条让我后来几乎没再因为文件操作丢过东西。5.4 输出格式飘忽输入输出约定缺失的后果Skill 跑出来的结果格式不稳定今天这样明天那样根因几乎都是没写清楚输入输出约定。Agent 每次都在自由发挥结果自然不一致。修复方法是在 Skill 里明确写死输出格式。不要写输出一份报告要写输出 Markdown一级标题是日期下面用无序列表列出条目每条不超过 50 字。越具体越稳定。如果输出要用于后续处理最好给出一个示例Agent 照着示例的格式走一致性会好很多。我现在的习惯是凡是输出要进入下一步流程的 Skill一律附一个格式示例。这个习惯让我的自动化流程稳定了不止一个档次。6. 进阶玩法与边界认知6.1 把 Skill 组合成工作流单个 Skill 解决单点问题多个 Skill 串起来就是工作流。比如收集素材 Skill加整理 Skill加生成初稿 Skill三步串起来你丢进去一堆原始材料出来一份初稿。这才是 WorkBuddy 作为工作台的完整形态。组合的关键是接口对齐。前一个 Skill 的输出格式必须正好是后一个 Skill 能接受的输入格式。所以前面强调的输入输出约定在组合场景下更重要。我建议组合之前先把每个 Skill 单独跑稳确认输出格式符合预期再串起来。串起来之后先跑一次完整流程观察每一步的中间产物有问题好定位。6.2 关于用 AI Agent 做交易这类需求的边界热搜里有个问题问个人使用 AI Agent 可以做期货交易吗。我必须明确说这类涉及真实资金、高风险决策的场景不适合交给 AI Agent 自动执行。原因很直接Agent 会出错而这类场景出错的代价是真金白银且往往不可逆。模型可能产生看似合理实则错误的判断接口可能延迟逻辑可能有边界漏洞。Agent 在这类场景里能扮演的合理角色是辅助信息整理和资料汇总比如把公开信息归类、把历史数据整理成表格供人自己做判断。决策和执行必须由人来做。这不是技术能力问题是风险控制问题。任何声称能让 Agent 自动交易还稳赚的说法都要保持警惕。6.3 学习路线的建议如果你想系统掌握 WorkBuddy 和 AI Agent我的建议路线是这样的。先用起来把基础配置跑通用现成 Skill 处理真实任务建立手感。然后开始改 Skill在别人的基础上调整理解每一处改动的影响。接着从零写 Skill从最简单的开始逐步加复杂度。最后学组合和规则设定把单点能力串成工作流。整个过程不要脱离真实任务。为了学而学很快就没动力。带着一个你真正想解决的问题去学每一步都有反馈进步最快。我见过学得最快的人都是有一堆重复劳动等着被自动化的人。6.4 一些长期使用的心得用了一段时间之后我最大的体会是WorkBuddy 的价值不在于它多聪明而在于它把重复劳动这件事变得可管理。你把一件事想清楚、写成 Skill、跑通它就永远替你做了。这个过程本身也在逼你把工作流程想清楚很多以前模糊的环节写 Skill 的时候被迫明确下来反而提升了工作质量。另一个体会是不要追求一步到位。我最早的几个 Skill 都很粗糙但能用。用着用着发现哪里不顺再改。迭代出来的 Skill 比一次性设计出来的更贴合实际。工具是长出来的不是设计出来的。最后分享一个小技巧定期回顾你的 Skill 库把不再用的删掉把常用的优化一下。Skill 多了之后管理本身也是成本。保持精简每个 Skill 都有明确用途用起来才顺手。