拓冰网站定制 
1. 为什么我要认真写这篇 WorkBuddy 实战指南WorkBuddy 这个腾讯出的 AI 工作台我从它内测阶段就开始折腾到现在团队里十几个人的日常任务流基本都跑在上面。说实话第一次打开它的时候我是有点懵的——界面看着简洁但真正要让它下地干活中间踩的坑比我预想的多得多。网上那些三分钟上手的教程基本只告诉你点哪里不告诉你为什么这么点、点错了会怎样、遇到报错怎么救。这篇东西就是把我这段时间的实操经验完整倒出来。从安装、配置 models.json、写 Skill、调 Agent 规则到并发扛不住、缓存目录爆盘、Skill 冲突这些真实问题我都会讲清楚背后的逻辑。适合两类人看一类是刚接触 WorkBuddy、想把它用起来的普通用户另一类是想基于它搭 AI Agent 中台、做 Skill 开发的开发者。不管你是哪种看完至少能少走我走过的那些弯路。我尽量不写那种点击下一步即可的废话每个关键操作我都会说清楚为什么这么做、不这么做会出什么问题。毕竟工具是死的理解它怎么运转才是真的。2. WorkBuddy 到底是什么和 CodeBuddy 什么关系2.1 一句话讲清它的定位WorkBuddy 本质上是腾讯做的一个AI 工作台核心能力是把大模型、工具调用、任务编排这三件事捏在一起让你能用自然语言驱动它完成实际工作。你可以把它理解成一个能装 Skill 的 AI Agent 运行容器——模型是发动机Skill 是各种功能插件工作台是驾驶舱。它和 CodeBuddy 的关系经常被搞混。简单说CodeBuddy 更偏向编码场景是给开发者写代码用的助手WorkBuddy 的野心更大它想覆盖的是通用办公和任务自动化写代码只是它能干的其中一件事。两者底层可能共享一些模型调度和 Agent 框架的能力但面向的场景、Skill 生态、交互方式都不一样。我个人的判断是如果你只是想让 AI 帮你写代码CodeBuddy 够用如果你想让 AI 帮你处理表格、整理文档、跑定时任务、串联多个工具那 WorkBuddy 才是对的选择。2.2 核心概念Agent、Skill、models.json 三件套要玩转 WorkBuddy必须先把这三个概念吃透不然你连配置文件都看不懂。AI Agent是执行主体。你可以把它想象成一个虚拟员工它有自己的系统提示词人设和规则、能调用的工具集、以及记忆上下文。WorkBuddy 里你可以创建多个 Agent每个负责不同的事——一个专门做数据分析一个专门写文案一个专门处理邮件。Skill是 Agent 的能力插件。一个 Skill 通常包含一段描述告诉模型什么时候该用它、一套参数定义、以及具体的执行逻辑。比如查天气是一个 Skill读本地文件是一个 Skill调用某个 API也是一个 Skill。Skill 写得好不好直接决定 Agent 聪不聪明。models.json是模型配置文件。它定义了 WorkBuddy 能用哪些模型、每个模型的接入方式、参数默认值等。很多人装完 WorkBuddy 发现模型列表是空的或者调用报错八成就是 models.json 没配对。提示这三个概念的关系是——Agent 通过 models.json 拿到模型能力通过 Skill 拿到工具能力三者缺一不可。新手最容易忽略的是 models.json因为它藏在配置目录里不主动找根本看不到。2.3 它解决了什么真实问题我用它主要解决三类问题。第一类是重复性任务的自动化比如每天把某个文件夹里的报表汇总、格式化、发出去以前要写脚本现在用 Skill 串一下就行。第二类是多工具协同比如让 AI 先读一份文档、再查一下数据库、最后生成一份总结这种跨工具的流程用 Agent 编排很顺。第三类是降低 AI 使用门槛团队里不会写代码的同事也能通过配置好的 Agent 完成一些原本需要技术介入的事。3. 安装与初始配置别急着点下一步3.1 安装前的环境检查WorkBuddy 对运行环境有基本要求装之前先确认几件事能省掉后面一堆莫名其妙的报错。操作系统版本Windows 建议 Win10 1903 以上macOS 建议 12 以上。老系统上跑某些依赖库会缺报错信息还特别隐晦。磁盘空间至少留 5GB。WorkBuddy 本身不大但它的缓存目录、模型临时文件、Skill 运行产生的中间产物加起来很能吃空间。网络环境需要能正常访问模型服务。如果你用的是需要 API Key 的模型提前把 Key 准备好。权限安装目录不要放在需要管理员权限才能写的系统盘根目录否则 Skill 写文件时会失败。我见过最常见的安装失败是用户把 WorkBuddy 装在了C:\Program Files下面结果 Skill 想写个临时文件就被系统拦了。建议装在一个普通用户目录下比如D:\WorkBuddy或者用户主目录里省心。3.2 安装步骤与首次启动安装过程本身不复杂下载安装包、双击、选路径、等进度条。但有几个点要注意。安装完成后第一次启动WorkBuddy 会初始化配置目录。这个目录的位置很关键默认一般在用户主目录下的隐藏文件夹里。你要做的第一件事就是找到它并记住路径因为后面改 models.json、加 Skill、清缓存都要来这里。启动后如果界面是空的、模型列表没有内容别慌这是正常的——你还没配 models.json。接下来就是配置环节。3.3 models.json 配置最容易翻车的一步models.json 是 WorkBuddy 的模型接入配置格式是 JSON。它的结构大致是定义一个模型列表每个模型包含名称、类型、接入地址、API Key、默认参数等字段。配置的时候有几个坑我必须提醒第一JSON 格式极其严格。多一个逗号、少一个引号整个文件就废了而且 WorkBuddy 的报错往往只说配置加载失败不告诉你具体哪一行错了。我的习惯是改完先用在线 JSON 校验工具过一遍确认没问题再放回去。第二API Key 不要硬编码在会被同步的目录里。如果你把配置目录放在云同步文件夹下Key 可能泄露。建议放在本地非同步目录。第三模型名称要和实际服务对得上。有些人随便填个名字结果调用时找不到模型。名称字段最好用服务商官方给的标识。第四参数默认值要合理。比如 temperature 设太高Agent 输出会飘设太低又显得死板。做任务自动化建议 0.2 到 0.5 之间做创意类可以到 0.7 以上。下面是一个 models.json 的结构示例字段名以你实际版本为准这里只展示组织方式{ models: [ { name: your-model-name, provider: provider-type, endpoint: https://your-endpoint, apiKey: your-key-here, defaultParams: { temperature: 0.3, maxTokens: 4096 } } ] }注意改完 models.json 一定要重启 WorkBuddy热加载不一定生效。我吃过这个亏改了半天以为没生效其实是没重启。3.4 更改系统缓存目录的正确姿势缓存目录默认在系统盘用久了会越来越大尤其是你跑了很多 Skill、处理了大文件之后。改缓存目录是个好习惯但要改对地方。改之前先关闭 WorkBuddy然后找到配置文件里指向缓存路径的字段改成你想要的目录。改完把旧缓存目录里的内容手动迁移过去或者直接删掉让它重建。不要只改配置不迁移否则可能出现缓存索引对不上、Skill 找不到历史文件的问题。我一般会把缓存目录设在一个大容量数据盘上并且定期清理。清理的时候注意正在运行的 Agent 的临时文件不要删会中断任务。4. Skill 开发让 AI 真的下地干活4.1 Skill 的基本结构和工作原理Skill 是 WorkBuddy 的灵魂。一个 Skill 本质上是一份能力说明书 执行代码。说明书部分告诉模型我叫什么、我能干什么、什么时候该调用我、需要哪些参数。执行部分则是真正干活的逻辑。模型在决定要不要调用某个 Skill 时靠的是 Skill 的描述文本。所以描述写得清不清楚直接决定模型会不会在正确的时机用对 Skill。我见过太多人 Skill 功能写得没问题但描述写得太笼统结果模型要么不用要么乱用。一个 Skill 通常包含这几个部分名称唯一标识别用中文和特殊字符。描述自然语言说明用途和触发条件这是给模型看的。参数定义每个参数的类型、是否必填、含义。执行逻辑真正运行的代码或调用。4.2 写一个好 Skill 的关键描述比代码重要很多人写 Skill 把精力全花在代码上描述随便写两句。这是本末倒置。模型看不到你的代码它只能看到描述。描述写得好模型才知道用户说这句话的时候我该用这个 Skill。好的描述应该包含三要素做什么、什么时候用、输入输出是什么。举个例子一个汇总表格的 Skill描述不该只写汇总表格而应该写当用户需要把多个表格文件的数据合并统计时使用输入是文件路径列表输出是汇总后的结果。另外描述里要写清楚边界。比如这个 Skill 只处理 CSV 和 Excel不处理 PDF这样模型遇到 PDF 时就不会错误调用。4.3 Skill 编码的实操流程写一个 Skill 的完整流程我一般是这么走的。第一步明确能力边界。先想清楚这个 Skill 到底解决什么问题输入是什么输出是什么有没有副作用比如写文件、发请求。边界不清后面全是坑。第二步写描述和参数。描述按上面说的三要素写参数尽量少而精。参数太多模型容易填错参数太少功能又不够灵活。我一般控制在 3 到 5 个参数。第三步写执行逻辑。这部分就是正常编程但要注意几点错误处理要完善因为模型传进来的参数不一定符合预期执行时间不要太长超过一定时间模型会超时输出格式要结构化方便模型理解结果。第四步本地测试。别急着装到 WorkBuddy 里先在本地用几个典型输入跑一遍确认逻辑没问题。第五步装进 WorkBuddy 并观察。装进去之后用真实对话测试模型会不会在正确时机调用它。如果不会回去改描述。4.4 Skill 冲突与优先级处理当你装了很多 Skill难免遇到冲突——两个 Skill 描述很像模型不知道该用哪个。这时候有几个处理办法。一是合并如果两个 Skill 功能高度重叠干脆合成一个用参数区分。二是改描述把触发条件写得更精确让它们互不重叠。三是利用优先级机制如果 WorkBuddy 支持给 Skill 设优先级把更常用的设高一点。我个人的经验是Skill 数量控制在 20 个以内比较好管理超过之后模型选择困难会明显上升。与其堆数量不如把常用的几个打磨好。5. Agent 规则配置给它定几条能长期生效的规矩5.1 系统提示词怎么写才有效Agent 的系统提示词就是它的人设 工作守则。写得好Agent 稳定可靠写得差它就像个没头苍蝇。我的写法是分三段身份、规则、输出要求。身份告诉它你是谁、你擅长什么规则告诉它你必须怎么做、绝对不能怎么做输出要求告诉它结果用什么格式给我。规则部分最关键。比如你可以写所有涉及文件删除的操作必须先向我确认、回答必须基于我提供的资料不要编造。这些规则会长期生效比每次对话都提醒一遍高效得多。5.2 让规则长期生效的技巧很多人写了规则发现 Agent 聊几轮就忘了。这是因为上下文长度有限早期内容会被挤掉。解决办法有几个。一是把最重要的规则放在系统提示词最前面模型对开头和结尾的内容记得更牢。二是精简规则数量别写几十条抓最核心的 5 到 8 条。三是用 Skill 固化关键流程把必须做的事变成 Skill 调用而不是靠模型自觉。我试过一个办法挺有效把核心规则写成一段简短的宪法每次新任务开始时让 Agent 先复述一遍。虽然多花点 token但稳定性提升明显。5.3 多 Agent 协作的编排思路当任务复杂到单个 Agent 搞不定时就需要多 Agent 协作。常见模式有两种串行和并行。串行就是 A 做完交给 BB 做完交给 C适合有先后依赖的流程。并行是 A、B、C 同时做最后汇总适合互相独立的子任务。编排的时候要注意交接数据的格式。A 的输出要能被 B 直接理解最好约定一个统一的结构。我一般用 JSON 做中间格式字段名固定这样下游 Agent 解析起来不会出错。6. 并发与性能AI Agent 怎么扛住压力6.1 并发瓶颈通常出在哪WorkBuddy 跑单个任务很顺但一旦多个任务同时来问题就暴露了。瓶颈一般出在三个地方模型调用限流、本地资源竞争、Skill 执行阻塞。模型调用限流是最常见的。你用的模型服务通常有 QPS 限制超过就排队或报错。本地资源竞争是指多个 Agent 同时读写文件、抢 CPU 内存。Skill 执行阻塞是指某个 Skill 跑得慢把整个流程卡住。6.2 实用的并发优化手段针对上面三个瓶颈我总结了几个实用手段。第一给模型调用加队列和重试。不要一上来就并发几十个请求用队列控制速率遇到限流自动退避重试。第二把耗时 Skill 异步化。如果一个 Skill 要跑几分钟别让它阻塞主流程改成提交任务、轮询结果。第三资源隔离。不同 Agent 的缓存目录、临时文件分开避免互相干扰。第四设置合理的超时。每个 Skill 调用设超时超了就放弃或降级别让一个卡住的任务拖垮全局。下面这个表格是我整理的常见并发问题和对应处理方式问题现象可能原因处理方式请求大量报错模型限流加队列、退避重试任务越跑越慢缓存膨胀定期清理缓存目录部分任务卡死Skill 阻塞异步化、设超时结果错乱资源竞争隔离目录、加锁6.3 实测下来比较稳的配置经过反复调整我现在用的配置大概是这样的模型调用并发控制在服务商限制的 70% 左右留出余量每个 Skill 超时设 60 秒长任务走异步缓存目录每周清理一次Agent 数量按业务线划分不混用。这套配置跑下来日常十几个并发任务基本不会出问题。当然具体数值要按你的实际服务和硬件调整别照搬。7. 常见问题与排查技巧实录7.1 安装类问题速查安装阶段最常见的就是启动失败、模型列表为空、配置加载报错。下面这个表可以快速定位。现象排查方向解决启动闪退系统版本、依赖缺失升级系统、补依赖模型列表空models.json 未配检查配置文件和路径配置加载失败JSON 格式错误用校验工具检查Skill 写文件失败目录权限不足换到用户目录7.2 运行类问题排查思路运行时的报错往往更隐蔽。我的排查顺序是先看日志再看配置最后看代码。WorkBuddy 的日志一般在配置目录下的 logs 文件夹里报错信息比界面提示详细得多。如果日志里说是模型调用失败先确认网络和 Key如果说是 Skill 执行异常去看 Skill 自己的日志如果什么都没说那可能是超时检查任务耗时。7.3 几个我踩过的坑坑一缓存目录爆盘。有次跑了一晚上批量任务第二天发现系统盘满了WorkBuddy 直接起不来。后来把缓存目录挪到大盘并加了定期清理。坑二Skill 描述太像导致误调用。我写了两个处理文档的 Skill描述没区分清楚模型经常用错。后来把触发条件写精确问题解决。坑三规则写太多被遗忘。一开始我给 Agent 写了二十多条规则结果它只记得前几条。精简到八条之后稳定多了。坑四并发没控好把服务打限流。有次图快一次发了几十个请求直接被限流后面半小时都在等。加了队列之后就好了。8. 关于 Skill 生态和后续扩展的一些想法WorkBuddy 的 Skill 生态是它最有想象力的地方。现在社区里已经有不少现成的 Skill 可以用比如文档处理、数据查询、格式转换这些。我的建议是先用现成的再自己写。现成 Skill 经过别人验证稳定性有保障自己写虽然灵活但调试成本高。如果你打算长期用我建议建一个自己的 Skill 库把常用的能力沉淀下来。写的时候注意版本管理改坏了能回滚。另外Skill 之间可以组合一个复杂流程拆成几个小 Skill 再串起来比写一个大而全的 Skill 更好维护。至于 Agent 中台这种玩法适合团队规模大、任务类型多的场景。个人用户其实不用搞那么复杂把几个核心 Agent 配好日常够用就行。工具是拿来解决问题的不是拿来供着的。最后分享一个小习惯我每次改完配置或 Skill都会用一个固定的测试用例跑一遍确认没破坏原有功能。这个习惯帮我避免了好几次改 A 坏 B的事故。 WorkBuddy 实战指南：从 models.json 配置到 Skill 开发与 Agent 编排
1. 为什么我要认真写这篇 WorkBuddy 实战指南WorkBuddy 这个腾讯出的 AI 工作台我从它内测阶段就开始折腾到现在团队里十几个人的日常任务流基本都跑在上面。说实话第一次打开它的时候我是有点懵的——界面看着简洁但真正要让它下地干活中间踩的坑比我预想的多得多。网上那些三分钟上手的教程基本只告诉你点哪里不告诉你为什么这么点、点错了会怎样、遇到报错怎么救。这篇东西就是把我这段时间的实操经验完整倒出来。从安装、配置 models.json、写 Skill、调 Agent 规则到并发扛不住、缓存目录爆盘、Skill 冲突这些真实问题我都会讲清楚背后的逻辑。适合两类人看一类是刚接触 WorkBuddy、想把它用起来的普通用户另一类是想基于它搭 AI Agent 中台、做 Skill 开发的开发者。不管你是哪种看完至少能少走我走过的那些弯路。我尽量不写那种点击下一步即可的废话每个关键操作我都会说清楚为什么这么做、不这么做会出什么问题。毕竟工具是死的理解它怎么运转才是真的。2. WorkBuddy 到底是什么和 CodeBuddy 什么关系2.1 一句话讲清它的定位WorkBuddy 本质上是腾讯做的一个AI 工作台核心能力是把大模型、工具调用、任务编排这三件事捏在一起让你能用自然语言驱动它完成实际工作。你可以把它理解成一个能装 Skill 的 AI Agent 运行容器——模型是发动机Skill 是各种功能插件工作台是驾驶舱。它和 CodeBuddy 的关系经常被搞混。简单说CodeBuddy 更偏向编码场景是给开发者写代码用的助手WorkBuddy 的野心更大它想覆盖的是通用办公和任务自动化写代码只是它能干的其中一件事。两者底层可能共享一些模型调度和 Agent 框架的能力但面向的场景、Skill 生态、交互方式都不一样。我个人的判断是如果你只是想让 AI 帮你写代码CodeBuddy 够用如果你想让 AI 帮你处理表格、整理文档、跑定时任务、串联多个工具那 WorkBuddy 才是对的选择。2.2 核心概念Agent、Skill、models.json 三件套要玩转 WorkBuddy必须先把这三个概念吃透不然你连配置文件都看不懂。AI Agent是执行主体。你可以把它想象成一个虚拟员工它有自己的系统提示词人设和规则、能调用的工具集、以及记忆上下文。WorkBuddy 里你可以创建多个 Agent每个负责不同的事——一个专门做数据分析一个专门写文案一个专门处理邮件。Skill是 Agent 的能力插件。一个 Skill 通常包含一段描述告诉模型什么时候该用它、一套参数定义、以及具体的执行逻辑。比如查天气是一个 Skill读本地文件是一个 Skill调用某个 API也是一个 Skill。Skill 写得好不好直接决定 Agent 聪不聪明。models.json是模型配置文件。它定义了 WorkBuddy 能用哪些模型、每个模型的接入方式、参数默认值等。很多人装完 WorkBuddy 发现模型列表是空的或者调用报错八成就是 models.json 没配对。提示这三个概念的关系是——Agent 通过 models.json 拿到模型能力通过 Skill 拿到工具能力三者缺一不可。新手最容易忽略的是 models.json因为它藏在配置目录里不主动找根本看不到。2.3 它解决了什么真实问题我用它主要解决三类问题。第一类是重复性任务的自动化比如每天把某个文件夹里的报表汇总、格式化、发出去以前要写脚本现在用 Skill 串一下就行。第二类是多工具协同比如让 AI 先读一份文档、再查一下数据库、最后生成一份总结这种跨工具的流程用 Agent 编排很顺。第三类是降低 AI 使用门槛团队里不会写代码的同事也能通过配置好的 Agent 完成一些原本需要技术介入的事。3. 安装与初始配置别急着点下一步3.1 安装前的环境检查WorkBuddy 对运行环境有基本要求装之前先确认几件事能省掉后面一堆莫名其妙的报错。操作系统版本Windows 建议 Win10 1903 以上macOS 建议 12 以上。老系统上跑某些依赖库会缺报错信息还特别隐晦。磁盘空间至少留 5GB。WorkBuddy 本身不大但它的缓存目录、模型临时文件、Skill 运行产生的中间产物加起来很能吃空间。网络环境需要能正常访问模型服务。如果你用的是需要 API Key 的模型提前把 Key 准备好。权限安装目录不要放在需要管理员权限才能写的系统盘根目录否则 Skill 写文件时会失败。我见过最常见的安装失败是用户把 WorkBuddy 装在了C:\Program Files下面结果 Skill 想写个临时文件就被系统拦了。建议装在一个普通用户目录下比如D:\WorkBuddy或者用户主目录里省心。3.2 安装步骤与首次启动安装过程本身不复杂下载安装包、双击、选路径、等进度条。但有几个点要注意。安装完成后第一次启动WorkBuddy 会初始化配置目录。这个目录的位置很关键默认一般在用户主目录下的隐藏文件夹里。你要做的第一件事就是找到它并记住路径因为后面改 models.json、加 Skill、清缓存都要来这里。启动后如果界面是空的、模型列表没有内容别慌这是正常的——你还没配 models.json。接下来就是配置环节。3.3 models.json 配置最容易翻车的一步models.json 是 WorkBuddy 的模型接入配置格式是 JSON。它的结构大致是定义一个模型列表每个模型包含名称、类型、接入地址、API Key、默认参数等字段。配置的时候有几个坑我必须提醒第一JSON 格式极其严格。多一个逗号、少一个引号整个文件就废了而且 WorkBuddy 的报错往往只说配置加载失败不告诉你具体哪一行错了。我的习惯是改完先用在线 JSON 校验工具过一遍确认没问题再放回去。第二API Key 不要硬编码在会被同步的目录里。如果你把配置目录放在云同步文件夹下Key 可能泄露。建议放在本地非同步目录。第三模型名称要和实际服务对得上。有些人随便填个名字结果调用时找不到模型。名称字段最好用服务商官方给的标识。第四参数默认值要合理。比如 temperature 设太高Agent 输出会飘设太低又显得死板。做任务自动化建议 0.2 到 0.5 之间做创意类可以到 0.7 以上。下面是一个 models.json 的结构示例字段名以你实际版本为准这里只展示组织方式{ models: [ { name: your-model-name, provider: provider-type, endpoint: https://your-endpoint, apiKey: your-key-here, defaultParams: { temperature: 0.3, maxTokens: 4096 } } ] }注意改完 models.json 一定要重启 WorkBuddy热加载不一定生效。我吃过这个亏改了半天以为没生效其实是没重启。3.4 更改系统缓存目录的正确姿势缓存目录默认在系统盘用久了会越来越大尤其是你跑了很多 Skill、处理了大文件之后。改缓存目录是个好习惯但要改对地方。改之前先关闭 WorkBuddy然后找到配置文件里指向缓存路径的字段改成你想要的目录。改完把旧缓存目录里的内容手动迁移过去或者直接删掉让它重建。不要只改配置不迁移否则可能出现缓存索引对不上、Skill 找不到历史文件的问题。我一般会把缓存目录设在一个大容量数据盘上并且定期清理。清理的时候注意正在运行的 Agent 的临时文件不要删会中断任务。4. Skill 开发让 AI 真的下地干活4.1 Skill 的基本结构和工作原理Skill 是 WorkBuddy 的灵魂。一个 Skill 本质上是一份能力说明书 执行代码。说明书部分告诉模型我叫什么、我能干什么、什么时候该调用我、需要哪些参数。执行部分则是真正干活的逻辑。模型在决定要不要调用某个 Skill 时靠的是 Skill 的描述文本。所以描述写得清不清楚直接决定模型会不会在正确的时机用对 Skill。我见过太多人 Skill 功能写得没问题但描述写得太笼统结果模型要么不用要么乱用。一个 Skill 通常包含这几个部分名称唯一标识别用中文和特殊字符。描述自然语言说明用途和触发条件这是给模型看的。参数定义每个参数的类型、是否必填、含义。执行逻辑真正运行的代码或调用。4.2 写一个好 Skill 的关键描述比代码重要很多人写 Skill 把精力全花在代码上描述随便写两句。这是本末倒置。模型看不到你的代码它只能看到描述。描述写得好模型才知道用户说这句话的时候我该用这个 Skill。好的描述应该包含三要素做什么、什么时候用、输入输出是什么。举个例子一个汇总表格的 Skill描述不该只写汇总表格而应该写当用户需要把多个表格文件的数据合并统计时使用输入是文件路径列表输出是汇总后的结果。另外描述里要写清楚边界。比如这个 Skill 只处理 CSV 和 Excel不处理 PDF这样模型遇到 PDF 时就不会错误调用。4.3 Skill 编码的实操流程写一个 Skill 的完整流程我一般是这么走的。第一步明确能力边界。先想清楚这个 Skill 到底解决什么问题输入是什么输出是什么有没有副作用比如写文件、发请求。边界不清后面全是坑。第二步写描述和参数。描述按上面说的三要素写参数尽量少而精。参数太多模型容易填错参数太少功能又不够灵活。我一般控制在 3 到 5 个参数。第三步写执行逻辑。这部分就是正常编程但要注意几点错误处理要完善因为模型传进来的参数不一定符合预期执行时间不要太长超过一定时间模型会超时输出格式要结构化方便模型理解结果。第四步本地测试。别急着装到 WorkBuddy 里先在本地用几个典型输入跑一遍确认逻辑没问题。第五步装进 WorkBuddy 并观察。装进去之后用真实对话测试模型会不会在正确时机调用它。如果不会回去改描述。4.4 Skill 冲突与优先级处理当你装了很多 Skill难免遇到冲突——两个 Skill 描述很像模型不知道该用哪个。这时候有几个处理办法。一是合并如果两个 Skill 功能高度重叠干脆合成一个用参数区分。二是改描述把触发条件写得更精确让它们互不重叠。三是利用优先级机制如果 WorkBuddy 支持给 Skill 设优先级把更常用的设高一点。我个人的经验是Skill 数量控制在 20 个以内比较好管理超过之后模型选择困难会明显上升。与其堆数量不如把常用的几个打磨好。5. Agent 规则配置给它定几条能长期生效的规矩5.1 系统提示词怎么写才有效Agent 的系统提示词就是它的人设 工作守则。写得好Agent 稳定可靠写得差它就像个没头苍蝇。我的写法是分三段身份、规则、输出要求。身份告诉它你是谁、你擅长什么规则告诉它你必须怎么做、绝对不能怎么做输出要求告诉它结果用什么格式给我。规则部分最关键。比如你可以写所有涉及文件删除的操作必须先向我确认、回答必须基于我提供的资料不要编造。这些规则会长期生效比每次对话都提醒一遍高效得多。5.2 让规则长期生效的技巧很多人写了规则发现 Agent 聊几轮就忘了。这是因为上下文长度有限早期内容会被挤掉。解决办法有几个。一是把最重要的规则放在系统提示词最前面模型对开头和结尾的内容记得更牢。二是精简规则数量别写几十条抓最核心的 5 到 8 条。三是用 Skill 固化关键流程把必须做的事变成 Skill 调用而不是靠模型自觉。我试过一个办法挺有效把核心规则写成一段简短的宪法每次新任务开始时让 Agent 先复述一遍。虽然多花点 token但稳定性提升明显。5.3 多 Agent 协作的编排思路当任务复杂到单个 Agent 搞不定时就需要多 Agent 协作。常见模式有两种串行和并行。串行就是 A 做完交给 BB 做完交给 C适合有先后依赖的流程。并行是 A、B、C 同时做最后汇总适合互相独立的子任务。编排的时候要注意交接数据的格式。A 的输出要能被 B 直接理解最好约定一个统一的结构。我一般用 JSON 做中间格式字段名固定这样下游 Agent 解析起来不会出错。6. 并发与性能AI Agent 怎么扛住压力6.1 并发瓶颈通常出在哪WorkBuddy 跑单个任务很顺但一旦多个任务同时来问题就暴露了。瓶颈一般出在三个地方模型调用限流、本地资源竞争、Skill 执行阻塞。模型调用限流是最常见的。你用的模型服务通常有 QPS 限制超过就排队或报错。本地资源竞争是指多个 Agent 同时读写文件、抢 CPU 内存。Skill 执行阻塞是指某个 Skill 跑得慢把整个流程卡住。6.2 实用的并发优化手段针对上面三个瓶颈我总结了几个实用手段。第一给模型调用加队列和重试。不要一上来就并发几十个请求用队列控制速率遇到限流自动退避重试。第二把耗时 Skill 异步化。如果一个 Skill 要跑几分钟别让它阻塞主流程改成提交任务、轮询结果。第三资源隔离。不同 Agent 的缓存目录、临时文件分开避免互相干扰。第四设置合理的超时。每个 Skill 调用设超时超了就放弃或降级别让一个卡住的任务拖垮全局。下面这个表格是我整理的常见并发问题和对应处理方式问题现象可能原因处理方式请求大量报错模型限流加队列、退避重试任务越跑越慢缓存膨胀定期清理缓存目录部分任务卡死Skill 阻塞异步化、设超时结果错乱资源竞争隔离目录、加锁6.3 实测下来比较稳的配置经过反复调整我现在用的配置大概是这样的模型调用并发控制在服务商限制的 70% 左右留出余量每个 Skill 超时设 60 秒长任务走异步缓存目录每周清理一次Agent 数量按业务线划分不混用。这套配置跑下来日常十几个并发任务基本不会出问题。当然具体数值要按你的实际服务和硬件调整别照搬。7. 常见问题与排查技巧实录7.1 安装类问题速查安装阶段最常见的就是启动失败、模型列表为空、配置加载报错。下面这个表可以快速定位。现象排查方向解决启动闪退系统版本、依赖缺失升级系统、补依赖模型列表空models.json 未配检查配置文件和路径配置加载失败JSON 格式错误用校验工具检查Skill 写文件失败目录权限不足换到用户目录7.2 运行类问题排查思路运行时的报错往往更隐蔽。我的排查顺序是先看日志再看配置最后看代码。WorkBuddy 的日志一般在配置目录下的 logs 文件夹里报错信息比界面提示详细得多。如果日志里说是模型调用失败先确认网络和 Key如果说是 Skill 执行异常去看 Skill 自己的日志如果什么都没说那可能是超时检查任务耗时。7.3 几个我踩过的坑坑一缓存目录爆盘。有次跑了一晚上批量任务第二天发现系统盘满了WorkBuddy 直接起不来。后来把缓存目录挪到大盘并加了定期清理。坑二Skill 描述太像导致误调用。我写了两个处理文档的 Skill描述没区分清楚模型经常用错。后来把触发条件写精确问题解决。坑三规则写太多被遗忘。一开始我给 Agent 写了二十多条规则结果它只记得前几条。精简到八条之后稳定多了。坑四并发没控好把服务打限流。有次图快一次发了几十个请求直接被限流后面半小时都在等。加了队列之后就好了。8. 关于 Skill 生态和后续扩展的一些想法WorkBuddy 的 Skill 生态是它最有想象力的地方。现在社区里已经有不少现成的 Skill 可以用比如文档处理、数据查询、格式转换这些。我的建议是先用现成的再自己写。现成 Skill 经过别人验证稳定性有保障自己写虽然灵活但调试成本高。如果你打算长期用我建议建一个自己的 Skill 库把常用的能力沉淀下来。写的时候注意版本管理改坏了能回滚。另外Skill 之间可以组合一个复杂流程拆成几个小 Skill 再串起来比写一个大而全的 Skill 更好维护。至于 Agent 中台这种玩法适合团队规模大、任务类型多的场景。个人用户其实不用搞那么复杂把几个核心 Agent 配好日常够用就行。工具是拿来解决问题的不是拿来供着的。最后分享一个小习惯我每次改完配置或 Skill都会用一个固定的测试用例跑一遍确认没破坏原有功能。这个习惯帮我避免了好几次改 A 坏 B的事故。