WorkBuddy 是一个以智能体为核心的工作台产品它解决的不是某一个具体功能问题而是把大模型、工具调用、知识材料和业务流程组装到一起。对于每天要和大量文本、表格、消息、文档打交道的开发者和运营人员来说它更像一个可以按照自己的习惯搭建的个人工作台。本文按照从入门到进阶的顺序围绕安装、核心概念、第一个自动化案例、模型接入、本地部署、常见错误排查和最佳实践展开。读完以后你可以照着搭建一个属于自己的 WorkBuddy 工作台也能在遇到 3002 这类报错时自己定位问题。在职场上很多事务性任务并不需要完全靠人来完成比如把聊天记录里的待办整理成清单、把每天的工作消息汇总成日报、定期把多维表格的数据同步到某个业务系统。这些任务单独看都很简单但一件件手动做非常消耗时间。WorkBuddy 的思路是让用户用自然语言定义流程由智能体拆解任务、调用模型理解内容、再通过 Skill 和连接器执行操作。这意味着学习它的关键不是背界面而是理解它组织能力的方式。下面按一条完整的学习路径展开。1. 先理解 WorkBuddy 是什么再决定从哪开始学1.1 智能体工作台解决的核心问题传统软件的使用方式是用户打开应用、找到按钮、填写表单、点击提交每一步都需要人主动操作。智能体工作台的使用方式则变成了用户说出目标智能体负责拆解步骤、选择工具、执行动作、汇总结果。WorkBuddy 就属于这类产品。它解决的核心问题可以归纳为三点把重复操作交给自动化减少人工搬运数据的工作量。让非技术人员也能用自然语言编排业务流程而不是依赖开发者写脚本。把模型能力、工具能力和数据源集中到一个统一入口避免在多个系统之间来回切换。这里说的智能体不是一个模糊概念。在 WorkBuddy 这类产品中可以把 Agent 理解成一个有系统提示词、可选工具、可被触发的自动化单元。它不再是单纯的问答机器人而是能调用外部能力完成任务的工作节点。例如一个日报生成 Agent可以读取指定目录下的聊天记录调用模型生成摘要再通过连接器把结果写入表格。这个链路里既有理解能力也有执行能力。1.2 WorkBuddy 和 CodeBuddy 的定位区别WorkBuddy 经常和 CodeBuddy 放在一起讨论因为两者名称相似部分底层能力也相通但它们解决的问题方向并不一样。对比项WorkBuddyCodeBuddy主要场景工作流、业务自动化、个人工作台代码开发、调试、代码解释输出形式结构化结果、自动化流程、文件处理代码补全、代码修改、命令行工具面向用户开发和业务人员都可以使用以开发者为主核心能力Skill、连接器、自定义指令、定时任务代码理解、文件编辑、终端操作使用方式对话式配合搭建工作台对话式配合 IDE 或命令行定位区别并不说明哪个更高级而是说明选型要看任务类型。如果任务是每天从聊天记录里提取待办并写入表格WorkBuddy 更合适如果任务是帮我写一个 Python 脚本来处理这些文件CodeBuddy 更顺手。实际项目中两者可以配合使用WorkBuddy 负责流程编排CodeBuddy 负责编写和维护流程中的代码。1.3 WorkBuddy 的四层结构为了不被界面上的功能按钮带偏建议先建立四层结构的认知对话层用户输入自然语言指令例如把这段聊天记录整理成待办清单。模型层WorkBuddy 调用大模型理解意图、拆分步骤、生成输出。模型可以是内置的也可以切换成用户配置的外部模型。工具层Skill 提供能力包连接器负责与外部系统通信例如读取本地文件、调用网页接口、写入多维表格。执行层把模型的输出变成实际动作例如生成文件、发送消息、修改数据。后面所有操作都可以归到这四层里。出问题时也按这个顺序排查先看指令是否表达清楚再看模型返回是否正确然后看 Skill 是否被调用最后看连接器是否执行成功。2. 安装与初始化先把工作台跑起来2.1 运行环境和版本选择不同版本的 WorkBuddy安装方式和使用体验有差异。常见形态包括桌面客户端适合个人日常使用Windows、macOS、Linux 都有对应安装包。网页版无需安装适合临时使用或权限受限的办公电脑。麒麟版 / 国产化环境用于需要在国产操作系统运行的场景安装包通常单独分发。这里特别提一下 Linux 和麒麟环境。很多用户下载完安装包后第一反应是双击运行但 Linux 下经常需要先赋予可执行权限或依赖若干运行库。原始材料没有给出固定版本因此落地前先确认三件事操作系统的位数、安装包的类型、官方文档对应的版本说明。2.2 安装步骤以 Linux 环境为例常见安装流程如下# 下载安装包后先确认文件完整性和权限 ls -l WorkBuddy*.AppImage chmod x WorkBuddy*.AppImage # 启动客户端 ./WorkBuddy*.AppImage如果安装包是 deb 或 rpm 格式可以使用系统包管理器安装# Debian/Ubuntu 系列 sudo dpkg -i workbuddy_xxx.deb # RedHat/CentOS/麒麟 系列 sudo rpm -ivh workbuddy_xxx.rpm安装完成后的检查点有三个应用能否正常打开。登录页是否能正常加载。创建第一个工作区是否成功。只要其中一个环节失败就先不要继续配置 Skill先把基础链路打通。很多人一上来就装十几个插件结果连登录都报错最后很难判断问题出在哪一层。2.3 登录、首次初始化和工作区首次启动后WorkBuddy 一般会引导用户完成登录、阅读权限说明、创建默认工作区。工作区是 WorkBuddy 组织任务和资源的基本单位建议按用途划分而不是所有内容都堆在同一个默认工作区里。可以按照以下规则创建个人工作区放日常指令、个人 Skill、临时任务。项目工作区放某个项目的连接器、定时任务和共享资源。测试工作区专门用来验证新指令和新 Skill避免改动影响正式流程。在搭建个人工作台时最容易忽略的就是工作区规划。前期不建分区后期 Skill、指令和任务全部混在一起排查问题会非常痛苦。如果你只是个人使用也至少把正式流程和实验功能分开。2.4 网页版与本地客户端的取舍网页版适合轻量使用但处理本地文件、访问本地目录、运行定时任务这些能力通常依赖客户端。如果你需要 WorkBuddy 读取电脑上的文件、定期执行任务优先使用本地客户端如果只是偶尔整理一段文字、生成一个文档网页版足够。需要注意部分功能在不同端上的入口不同。比如访问文件夹范围这类本地权限设置只会在客户端中出现。网页版没有本地文件访问权限也就不会显示对应选项。提示安装阶段的目标是跑通最小链路不用一次装完所有插件。先把客户端装好、登录成功、建一个测试工作区即可。3. 四个核心概念指令、Skill、连接器和 Agent3.1 自定义指令用自然语言固定流程自定义指令是 WorkBuddy 中最容易上手的能力。它的本质是一段长期生效的系统提示词让模型在每次对话时都按照定义的规则执行任务。一个简单的自定义指令示例# 角色 你是我的日报生成助手。 # 任务 根据我发送的聊天记录和工作消息提取当天完成的事项。 # 输出格式 - 完成事项按条列出 - 待跟进事项按条列出 - 风险问题没有则写无 # 注意 只提取有明确含义的内容不要编造。在 WorkBuddy 中新建指令后每次对话都能携带这段规则。相比每次临时输入一大段要求自定义指令解决了重复描述规则的问题。基础格式并不复杂关键是输出格式要写具体。很多人的指令不生效不是因为模型不理解中文而是因为规则太模糊模型不知道应该返回什么结构。3.2 Skill把能力封装成包Skill 可以理解为 WorkBuddy 里的能力包。一个 Skill 通常包含描述文件说明这个 Skill 能做什么、触发条件是什么。指令模板定义 Skill 内部的处理步骤。配套脚本或资源例如读取 Excel 的脚本、联网搜索的接口配置。Skill 的目录结构可以这样理解my-skill/ ├── SKILL.md # 描述文件 ├── instructions.md # 处理步骤 ├── scripts/ # 脚本或工具 └── resources/ # 模板、示例数据Skill 使得一段能力可以被复用。例如你写了一个整理聊天记录的 Skill之后在任何对话里都可以引用它不用重复粘贴规则。多个 Skill 组合起来就能形成更复杂的业务能力。从使用反馈来看很多用户都在找 WorkBuddy Skill 教程这也说明 Skill 是拉开使用水平差距的关键。安装第三方 Skill 时建议先查看它的描述文件确认它访问了哪些目录、调用了哪些接口避免盲目启用来源不明的能力。3.3 连接器让 WorkBuddy 能操作外部系统连接器解决的是 WorkBuddy 与外部系统的通信问题。没有连接器时智能体只能生成文本有了连接器它才能读文件、写表格、调用接口。常见连接器类型包括本地文件连接器读取或写入指定目录。多维表格连接器例如同步到钉钉多维表格。消息连接器例如向企业微信群机器人发送通知。HTTP 连接器调用任意需要鉴权的接口。配置连接器时最核心的是权限范围和密钥管理。不要给一个 Skill 授权整个磁盘只给它访问实际需要的目录或数据源即可。密钥类信息也不应该直接写在指令文本里应该放到工作台的密钥管理中由连接器在调用时读取。3.4 Agent 与自动化任务当指令、Skill、连接器组合起来就构成了一个 Agent。Agent 可以手动触发也可以定时触发。定时任务适合以下场景每个工作日早上九点抓取昨日消息、生成日报、发送到指定机器人每周五统计多维表格数据并生成周报。一个定时任务在配置上通常包含三个要素触发条件例如 cron 表达式。执行内容调用哪个 Skill、使用哪个模型。输出去向写入文件、发送消息、更新表格。理解这个概念后再看 WorkBuddy 的界面就不会迷茫创建指令、引用 Skill、配置连接器、设置触发条件组件之间是清晰的依赖关系。4. 第一个完整例子用自定义指令整理聊天记录4.1 场景和目标第一个例子选整理聊天记录而不是开发一个复杂流程原因是它闭环短、验证快、覆盖了指令、模型、文件读取和输出四个环节。场景设定你有一段会议后的聊天记录希望 WorkBuddy 把它整理成结构化待办清单并输出为 Markdown 文件。输入材料是一段原始文本关于上线的事小明说周五晚上发布但是测试还没完全跑完。 小红反馈首页轮播图在低版本浏览器上有兼容问题。 后端接口周三要联调但还没有定负责人。 数据库迁移脚本已准备好需要安排人再 review 一次。目标输出是一份 Markdown 文件分开列出待办事项、负责人、风险、优先级。4.2 编写自定义指令在 WorkBuddy 中新建一个指令命名为会议记录整理助手指令内容如下# 角色 你是会议纪要整理助手。 # 输入 用户会粘贴一段原始聊天记录或会议记录。 # 处理步骤 1. 提取所有提到任务的句子。 2. 判断每个任务的时间、负责人、状态。 3. 标注风险和待确认项。 # 输出格式 ## 待办事项 | 事项 | 负责人 | 时间 | 状态 | ## 风险 - 风险描述 ## 待确认 - 问题列表关键点是明确输出格式。模型对模糊要求的输出往往不稳定表格列名、字段取值范围写得越具体结果越可控。4.3 给指令挂上 Skill 和连接器为了让 WorkBuddy 读取原始文本并写出文件需要准备一个本地文件连接器授权访问保存聊天记录的目录。一个输出 Skill 或基础文件操作能力用于生成 Markdown 文件。在配置本地文件连接器时授权范围要尽量小。例如只授权/data/meeting-notes目录而不是整个家目录。示例配置如下{ name: local-notes, type: file, allowedPaths: [ /data/meeting-notes ], permissions: [read, write] }这里把读写权限明确列出来是为了避免无意中让智能体修改不该动的文件。权限设置是生产环境最容易忽视的一个环节。4.4 运行与验证结果完成配置后在对话中发送原始聊天记录并明确要求使用会议记录整理助手把结果输出到/data/meeting-notes/todo-20240115.md。正常结果是对话框返回整理后的待办清单目标目录下出现对应文件。验证文件内容时重点检查两点信息是否准确负责人、时间是否来自原始文本有没有编造。格式是否完整表格是否生成、风险是否有遗漏。如果文件和预期不一致按照这个顺序排查先看模型输出是否合理再看文件连接器是否有权限最后确认 Skill 是否被调用。注意不要只验证文件存在还要打开文件核对内容。很多自动化流程的错误不是没执行而是执行了错误的输出。5. 进阶接入自己的模型和本地部署5.1 OpenAI 兼容接口配置WorkBuddy 默认自带模型服务但不少用户需要接入自己的模型。原因一般有三个团队已有模型账号、需要在私有环境控制数据、某些任务需要特定模型效果。如果目标模型提供 OpenAI 兼容接口WorkBuddy 中通常可以填写 base URL、API Key、model 名称来完成接入。示例配置model: provider: openai-compatible base_url: https://your-model-service.example.com/v1 api_key: sk-your-key model: your-model-name temperature: 0.3这里要注意几点base URL 结尾是否需要/v1不同服务要求不同。model 名称必须与模型服务返回的名称一致。temperature 影响输出随机性整理类任务建议用低值创意类任务可以适当调高。5.2 本地模型服务接入本地部署模型时WorkBuddy 只负责作为客户端调用模型服务模型由本地或内网中的推理服务提供。常见推理服务包括 Ollama、vLLM 等它们一般都提供 OpenAI 兼容接口。以 Ollama 为例启动一个本地模型服务ollama serve ollama run qwen2.5:7b然后在 WorkBuddy 中把模型接口指向本地地址model: provider: openai-compatible base_url: http://127.0.0.1:11434/v1 api_key: ollama model: qwen2.5:7b接入后要验证三个指标能否生成回复、生成速度能否接受、上下文长度是否足够。本地模型的显存和内存有限模型参数量越大速度越慢占用的资源也越多。至于本地部署后效果到底如何取决于硬件规格、量化方式、上下文长度以及 WorkBuddy 版本对模型的兼容程度不能只看模型名。5.3 本地部署的关键检查点如果 WorkBuddy 本身需要部署到本地服务器那么需要区分客户端安装和服务端部署两个概念。客户端安装只是把软件装到本机服务端部署则包含模型服务、文件存储、定时任务调度等环节。从工程经验看本地部署至少要检查这些点检查项说明常见问题依赖版本运行时、数据库、消息组件的版本是否匹配版本不匹配导致服务起不来数据目录文件、索引、日志是否分目录存放全部写在同一目录磁盘占满模型服务模型服务地址能否从 WorkBuddy 所在机器访问本机可访问但容器内不可达定时任务时区设置是否正确cron 时间与预期相差几小时日志是否有集中日志输出报错后没有线索可查文档中没有给出具体版本时先拿到部署环境确认再动手不要照抄博客命令。命令中的包名、版本号、路径都要按实际环境替换。5.4 学习环境与生产环境的差异学习环境只追求跑通本地启动 WorkBuddy、调用一个模型、输出一个文件。生产环境必须考虑稳定性、权限、可回滚、可监控。两者的差异可以做一张速查表维度学习环境生产环境模型默认模型即可明确模型来源、限流、成本权限全部放开最小权限授权定时任务手动执行监控执行状态和失败重试日志不关注必须有留存和告警数据测试数据备份和访问审计回滚重装即可需要保留前一版本配置这个对照关系适用于几乎所有智能体工作台项目不只是 WorkBuddy。6. 常见问题排查从现象定位到根因6.1 网络连接失败 3002WorkBuddy 网络连接失败 3002是出现频率很高的问题。这类错误码通常表示客户端无法访问服务端。排查顺序如下检查本机网络是否正常可以访问普通网页。检查 WorkBuddy 服务域名或接口地址是否能连通。检查是否填写了错误的模型接口地址或 API Key。检查系统时间是否正确TLS 握手对时间偏差敏感。查看客户端日志中 3002 附近的详细错误。可能原因和处理建议整理成表格错误现象可能原因检查方式处理建议登录时报 3002登录服务不可达用浏览器访问登录地址确认网络和域名解析发送消息时报 3002模型接口配置错误查看模型配置和日志检查 base URL、Key、model 名称定时任务报 3002任务执行环境网络受限在任务机器上单独测试接口调整网络策略或改用内网地址遇到错误码时不要只搜错误码本身要同时记录操作步骤、时间点、完整日志。3002 只是一个入口根因往往在更底层。6.2 界面里看不到 Claw 入口有用户提出WorkBuddy 没有看到 Claw怎么让它显示。这里要先把 Claw 的指向确认清楚不同版本中它可能指定时任务执行器、系统工具面板或某个扩展能力模块。通常按以下步骤处理升级客户端到最新版本部分入口只在新版开放。检查当前登录账号的权限普通用户可能看不到管理类入口。检查工作区类型个人工作区和团队工作区可见项不同。在设置或扩展中心里搜索 Claw确认是否为手动启用项。如果以上都没有效果直接查看该版本的更新日志确认 Claw 是否被移到了其他位置。不要在没有确认版本的情况下反复重装。6.3 Skill 或指令没有生效症状是指令已经写好Skill 已经启用但对话中模型仍然按照默认方式回答。优先检查以下四点指令是否在正确的对话中启用。模型是否支持该指令内容。Skill 依赖的连接器是否已经授权。启用了多个 Skill 时是否出现规则冲突。自定义指令不生效最常见的不是语法问题而是模型没有看到这段指令或者被其他更高优先级的指令覆盖。排查时先看对话配置再看 Skill 顺序最后检查连接器。6.4 定时任务不执行定时任务不执行的原因通常出在时间、权限、运行环境三个层面。例如配置了一个每个工作日九点执行日报生成的任务实际到时间没有执行可以按顺序检查时区是否为本地时区。客户端是否处于关闭或休眠状态。任务依赖的连接器和模型是否可用。历史运行记录里是否有失败日志。输出文件是否因为目录权限没有写入。定时任务的排查原则是从任务触发点开始逐步往下游追先确认任务有没有启动再确认每一步是否成功不要一上来就怀疑代码或模型问题。7. 最佳实践与学习路径7.1 自定义指令的几类常见套路从实际使用场景看WorkBuddy 自定义指令有几类高价值套路角色限定型规定智能体扮演的角色和沟通语气适用于固定岗位助手。流程固定型把多步处理过程写成固定步骤适用于数据处理和内容整理。格式约束型强调输出结构适用于生成日报、周报、会议纪要。规则拦截型明确哪些内容不能处理避免模型编造或越权操作。学习阶段建议从格式约束型入手因为它最容易看到效果也最容易验证。7.2 从模仿到自建推荐的学习顺序对于刚接触 WorkBuddy 的用户建议按以下路线学习第一天完成安装、登录、建工作区。第二天用自定义指令整理一段文字理解对话层和模型层。第三天接入一个第三方 Skill理解工具层。第四天配置一个连接器完成一次文件读写。第五天把指令、Skill、连接器组合成一个定时任务。之后尝试接入自己的模型并处理实际业务场景。不要一上来就安装大量 Skill。一方面来源不明的 Skill 有数据风险另一方面安装太多会掩盖基础配置问题反而不利于学习。7.3 发布前检查清单无论搭建的是个人工作台还是团队流程在正式使用前建议过一遍以下清单每个 Skill 是否只授权了必要的目录和接口。密钥和 API Key 是否保存在安全位置避免硬编码在指令中。模型输出是否有异常分支和失败提示。定时任务是否配置了正确的时区和重试策略。关键操作是否有日志记录出错后能从日志还原链路。是否保留上一版本的配置方便回滚。涉及外部数据源时是否确认了读写权限和数据备份策略。这张清单可以直接用于新流程的验收。真正拉开使用效果差距的往往不是模型本身而是对权限、输出结构、异常处理和验证方式的重视程度。如果要把 WorkBuddy 用出长期价值把日常工作拆成输入、处理、输出三段是最有效的切入点。先找一个自己每周都要重复做的事用自定义指令跑通再逐步加入 Skill 和连接器最后交给定时任务。这样学到的不是零散功能而是一套可以复制到其他场景的搭建方法。