先交代一下背景我手里这台 Nex N2.5 Pro 一直被我当成“7x24 小时值班小工”在用平时挂脚本、盯定时任务都靠它。这不最近想在上面部署 WorkBuddy把日常那些重复的写报告、整理资料、定时抓取公开信息之类的活全丢给 AI 去干结果又撞上了老问题——积分不够。平台积分这玩意儿说多不多说少不少真要天天跑自动化任务烧起来跟喝水一样。后来我干脆换了个思路WorkBuddy 本身是能独立部署的那我不充积分自己带模型 API Key 进去不就等于“自带原料进饭店炒菜”吗折腾了两天完整跑通了整套流程一分钱没花。这篇保姆教程就是把整个接入过程、中间踩过的坑、以及最后怎么把 WorkBuddy 变成 Nex N2.5 Pro 上的常驻服务全部摊开讲清楚。适合手里有 Nex 这类 Linux 小主机或开发板、想用 WorkBuddy 跑自动化任务、又不想给 AI 平台贡献积分的朋友照着抄作业就行。1. 接入前先把账算明白0费用到底是怎么实现的1.1 WorkBuddy 是什么和 CodeBuddy 有什么区别很多朋友第一次听到 WorkBuddy会下意识把它和 CodeBuddy、Claude Code 这类工具混在一起其实定位不太一样。CodeBuddy 也好Claude Code 也好核心场景是“结对编程”你给它一个编程任务它在终端里帮你写代码、改代码、跑测试本质上是个带 AI 能力的程序员助手。WorkBuddy 更像个“任务管家”。它关心的是你交给它的目标能不能被拆解、被调度、被闭环执行。你定好规则它调用大模型做规划然后通过内置的 Skill 去执行具体动作比如写文件、发 HTTP 请求、整理目录、生成摘要、定时巡检。举个生活化的例子CodeBuddy 是“你让程序员改 bug他马上动手改”WorkBuddy 是“你把一整个月报流程丢给它它自己排计划、调模型、生成表格、放到指定目录” 。所以如果你需要的是一个能长期挂机、按规矩办事的自动化工作台WorkBuddy 比单纯用命令行接 Claude 或别的模型更省心。它把“任务定义、模型调用、工具执行、定时触发”这几层都收拢到了一起配置一次后面就能反复用。1.2 平台积分消耗在哪儿BYOK 为什么能省先说结论商业 AI 平台的积分本质上买的不是“AI 本身”而是“托管服务”。你充了积分平台帮你做了三件事第一帮你维护算力集群你不用自己买显卡第二帮你烧模型调用费你每问一句背后都是实打实的 token 计费第三帮你封装了很多开箱即用的功能这些功能开发和维护也有成本。积分不够通常不是因为你用得少而是因为自动化任务往往要高频调用模型一天几百次对话跑下来积分消耗速度远超你的预期。WorkBuddy 不一样。它本身是免费分发的你把它装到自己的 Nex N2.5 Pro 上等于把“平台服务”这一层变成了“本地服务”。模型调用这块用自己的 API Key 直连云端的模型服务商或者干脆接入本地模型费用逻辑就完全变了方案费用来源实际成本适合场景平台积分方式托管费 模型费按积分计费高频跑任务消耗快临时用用不想折腾环境WorkBuddy 云模型 API Key仅模型 token 费用极低新用户常有免费额度长期挂机、任务量中等WorkBuddy 本地模型电费接近 0隐私要求高、设备性能足够我这次选的就是“WorkBuddy 云模型 API Key”因为 Nex N2.5 Pro 这台设备本身内存和算力有限跑本地大模型比较吃力但用云模型就无所谓设备只负责调度和写结果。再加上我申请的那个模型服务商账号本身就送了免费额度这一通操作下来凭证填进去的那一刻起一分钱没掏。2. 准备工作先把 Nex N2.5 Pro 和 WorkBuddy 都备齐2.1 检查设备底子别装到一半才发现跑不动既然是保姆教程我尽量把每一步都讲到。第一步不是急着下载安装包而是先搞清楚手里的 Nex N2.5 Pro 是什么状态。不同批次、不同用途的设备系统环境可能天差地别。我自己这台装的是 Linux 发行版用下面几条命令做基础体检uname -a free -h df -h / python3 --version node -v我建议你重点看几项系统架构和内核版本用来确定该下哪个版本的 WorkBuddy、内存剩余量至少留出 1GB 给 WorkBuddy 运行、根分区磁盘空间安装包加运行缓存建议预留 5GB 以上、Python 和 Node 环境。这里有个容易忽略的点很多小主机初始系统是精简版可能没有预装 Python 或 Node 的某些基础库。如果后面启动 WorkBuddy 时报缺少模块别急着怀疑人家软件有问题先用系统的包管理器把常用运行时补齐。我个人习惯是装系统后就统一装一遍构建工具链省得后面反复折腾。2.2 下载 WorkBuddy Linux 版本并安装WorkBuddy 的官方渠道提供了 Linux 版本的压缩包。Nex N2.5 Pro 不是那种主流 x86 台式机所以下载前先确认架构别下错包。我这里直接下了对应架构的版本然后解压到了 /opt 下sudo mkdir -p /opt/workbuddy sudo tar -zxvf workbuddy-linux-xxx.tar.gz -C /opt/workbuddy --strip-components1 sudo chmod x /opt/workbuddy/workbuddy关于目录位置有人喜欢放 /usr/local/bin有人喜欢放用户目录。我的建议是放 /opt 或 /home 下某个固定位置因为后面要配置 systemd 常驻服务路径固定了服务文件里就不容易写错。如果官方下载页面访问慢可以试试先在你的主力电脑上下载好再通过局域网传到 Nex N2.5 Pro 上小主机下载这种事稳定优先。安装完成之后先在终端里不带任何参数运行一次让它生成默认配置目录。我刚装完时手动运行了一次看到它自动创建了 ~/.workbuddy 目录里面是配置模板和日志目录。这一步很重要很多第一次接触的人一上来就改配置结果对不上版本报错后一脸懵。2.3 模型服务商怎么挑免费额度、成本与效果的平衡WorkBuddy 安装好只算完成了三分之一真正决定“0费用”能不能落地的是你选哪家模型服务。我的经验是分三条路线走。第一种用云厂商的模型 API。像 DeepSeek 这种新用户注册时一般有赠送额度API 价格本身也低属于典型的高性价比选择。只需要在服务商平台上创建一个 API Key填到 WorkBuddy 的配置里就行。适合不想折腾、追求效果稳定的朋友。第二种用国内聚合平台。有些平台会不定期开放免费模型额度注册后能领到一定量的免费 token用来跑轻量级任务完全够用。好处是一次接入可以切换多个模型坏处是免费额度和有效期变化快要留意公告。第三种本地模型。用 Ollama 之类工具在 Nex N2.5 Pro 上跑参数量小一点的模型比如 7B 级别的量化版。优势是零 token 费用、完全离线、隐私无泄漏劣势是设备性能一般时响应慢任务复杂度一高模型能力可能不够用。我这次选第一种。理由很直白Nex N2.5 Pro 本地跑模型有点吃力云模型又快又稳而且免费额度已经覆盖了我现阶段每天几十次调用的量。如果你的需求只是每天生成几段摘要、整理一下日志这个方案是真真正正的 0 费用。3. 正式接入实操从 API Key 到第一条自动化任务3.1 申请 API Key 并验证连通性接入流程的第一步是拿到一个有效的 API Key。去模型服务商官网注册账号在控制台里找到“API Key”管理创建一个新的密钥。注意创建之后平台通常只会完整显示一次一定要第一时间复制保存好。拿到 Key 之后建议先在终端里手动调一次接口确认 Key 可用再往下走。不同服务商的接口格式略有差异但大致思路是一样的用 curl 发一个最简单的对话请求curl https://api.example.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的_API_Key \ -d {model:your-model-name,messages:[{role:user,content:ping}]}如果返回了正常的 JSON 响应说明 Key 没问题。接着把 Key 写进 WorkBuddy 能读取的环境变量文件里。这里我必须多说一句千万不要把 Key 硬编码到 WorkBuddy 的主配置文件里因为配置文件可能会被同步、备份甚至别人临时用你设备时一眼看到。我习惯的做法是这样的mkdir -p ~/.workbuddy echo WORKBUDDY_MODEL_API_KEY你的_API_Key ~/.workbuddy/env chmod 600 ~/.workbuddy/envchmod 600 意思很明确只有当前用户能读能写其他人都没有权限。这个习惯帮我避免过很多次尴尬。3.2 启动 WorkBuddy顺手修掉第一个权限坑配置好环境变量后就可以真正启动 WorkBuddy 了。我在 /opt/workbuddy 目录下执行了启动命令cd /opt/workbuddy ./workbuddy --config /home/你的用户名/.workbuddy/config.toml首次启动时它会读取配置模板、加载模型服务商信息、检查 Skill 目录。如果能观察到加载日志正常滚动说明已经跑起来了。但很多人在这一步会遇到一个经典报错错误信息里带着502 write EACCES。这个报错说白了就是权限不足。WorkBuddy 在运行时要往 ~/.workbuddy 目录写入日志、缓存和任务数据如果目录属主不对或者之前你用 sudo 运行过一次导致目录被 root 占用普通用户就写不进去了。我当时遇到的时候也愣了一下后来排查思路其实很简单确认当前用的是哪个用户再看看目录的属主是谁。whoami ls -la ~/.workbuddy发现目录属主不是当前用户之后直接改回来sudo chown -R 你的用户名:你的用户名 ~/.workbuddy改完再重新启动报错就消失了。这个坑极其典型我后面会再单独列到速查表里。3.3 自定义指令落库让 WorkBuddy 按你的规矩办事WorkBuddy 真正好用的地方在于可以把日常重复任务固化成“自定义指令”和“Skill”。它的设计思路很像给员工写岗位手册你告诉它什么情况下做什么事达到什么标准算完成。我这里用一个真实例子演示。我每天都要看几个技术博客有没有更新然后生成一份摘要丢到本地笔记目录里。以前我都是手动打开网页翻现在写成自定义指令让 WorkBuddy 跑。先建 Skill 的目录mkdir -p ~/.workbuddy/skills/blog-daily-digest然后在这个目录下写 skill 的定义文件。以我用的这个版本为例文件内容是这样的思路--- name: blog-daily-digest description: 读取指定 RSS 列表抓取当天更新文章生成中文摘要写入输出目录 --- - 输入读取 ~/.workbuddy/inputs/rss-feeds.txt 中的 RSS 链接 - 动作逐个访问解析文章标题、链接、发布时间过滤出当天的更新 - 输出按 日期-博客摘要.md 的命名规则写入 ~/Documents/digest/ - 要求摘要不超过 200 字必须包含原文链接结尾标注来源站点名把规则用自然语言写清楚WorkBuddy 在调用模型时会把这些指令当作任务规范。写完 Skill 后在 WorkBuddy 的交互终端里输入任务目标比如“运行 blog-daily-digest”它就会开始执行流程。这里有个心得指令写得越具体执行结果越稳。模糊的词比如“整理一下”“差不多就行”模型的发挥空间就大输出格式容易飘。最好把输入路径、输出路径、格式要求、判断标准全写上规则就是“傻瓜相机”定得越死跑得越准。3.4 systemd 常驻让 WorkBuddy 开机就跑Nex N2.5 Pro 这种小主机最大的价值就是低功耗、能 7x24 挂着。如果 WorkBuddy 每次重启设备后都得手动开就对不起“值班小工”这个角色了。我把 WorkBuddy 配成了 systemd 服务开机自启崩溃自动拉起。在 /etc/systemd/system/workbuddy.service 下创建服务文件[Unit] DescriptionWorkBuddy Agent Service Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple User你的用户名 WorkingDirectory/opt/workbuddy EnvironmentFile/home/你的用户名/.workbuddy/env ExecStart/opt/workbuddy/workbuddy --config /home/你的用户名/.workbuddy/config.toml Restarton-failure RestartSec5 [Install] WantedBymulti-user.target然后依次执行sudo systemctl daemon-reload sudo systemctl enable --now workbuddy sudo systemctl status workbuddy看到 status 显示 active (running) 就说明服务起来了。这里有两个关键设计第一EnvironmentFile 指向独立 env 文件避免 Key 写在服务文件里第二Restarton-failure 配合 RestartSec5即使任务执行崩了也会在 5 秒内自动拉起非常适合无人值守的设备。4. 实操路上的坑和速查表4.1 502 write EACCES权限错误的完整解法这个报错我必须放在第一个讲因为它属于“高危高频”问题而且报错信息很迷惑人。一开始我以为是网络问题因为 502 一般让人联想到网关错误但实际上 WorkBuddy 里这个报错基本都指向文件写入权限。排查步骤我再整理一遍第一步确认当前用户和目录属主whoami和ls -la ~/.workbuddy第二步如果发现目录属于 root或者有 root 生成的缓存文件用chown -R一次性改回来第三步确认 ~/.workbuddy 里有写入权限的临时目录如果没有就手动建一个tmp目录第四步重启服务sudo systemctl restart workbuddy改完之后再看日志基本不会再出现这个报错。4.2 内容输出慢到没法用问题出在哪另一个高频体验问题就是“内容输出慢”。我遇到过两种情况。第一种模型服务本身响应慢。高峰期云模型服务可能排队尤其免费额度的优先级一般低于付费用户这没什么太好的解决办法建议错峰运行或者干脆把定时任务设到凌晨。第二种设备性能不足。Nex N2.5 Pro 毕竟不是高配服务器如果 WorkBuddy 同时还跑了好几个 Skill、生成了大量日志CPU 和内存占用会明显变高整体响应就会拖慢。我的排查方式是在 WorkBuddy 跑任务的时候另开一个终端用 htop 看系统负载。如果发现 Load 一直很高就可以考虑简化任务、减少并发或者把模型换成速度快一点的小模型。对于摘要、提取这类轻量任务小模型的响应速度优势很明显质量差距也没那么夸张。4.3 临时文件目录修改与自动签到等场景提醒还有朋友问过临时文件目录怎么改。WorkBuddy 默认会把运行时的临时文件放到系统临时目录里有些系统清理策略比较激进或者在容器环境下临时目录不可写就导致任务跑着跑着中断。解决办法是通过环境变量 overrideecho TMPDIR/home/你的用户名/.workbuddy/tmp ~/.workbuddy/env mkdir -p /home/你的用户名/.workbuddy/tmp sudo systemctl restart workbuddy有朋友会用 WorkBuddy 做定时签到、定时打卡类任务。这类任务本质上是把“打开网页、登录、点击、记录结果”这一串动作自动化属于 HTTP 请求加状态判断的组合。我的建议是把执行结果统一写入日志文件这样每天签到成功没成功扫一眼文件就清楚了。4.4 常见问题速查总表现象可能原因解决办法启动报 502 write EACCES配置目录属主不对chown 改成当前用户并将目录权限设为 700任务跑到一半中断临时目录不可写设置 TMPDIR 指向用户目录并重建临时目录内容输出很慢模型服务排队或设备负载高错峰运行换轻量模型用 htop 看设备负载自定义指令不生效指令文件格式错误或缩进不对检查文件头元信息确认路径重启 WorkBuddy服务启动后又退出环境变量没加载确认 EnvironmentFile 路径正确手动运行看输出日志文件无限增长没有配置日志轮转用 logrotate 或定期清理日志目录5. 进阶玩法把 Nex N2.5 Pro 变成你的个人自动化中心5.1 和 cron 结合做定时自动化WorkBuddy 自己有能力处理定时触发但如果你想让它和系统里其他脚本统一调度完全可以交给 cron 管。比如我每天早上八点要跑一次博客摘要就在 crontab 里加一行0 8 * * * /opt/workbuddy/workbuddy --config /home/你的用户名/.workbuddy/config.toml --task blog-daily-digest这样时间维度由系统掌控WorkBuddy 只负责执行互不干扰。而且 cron 的日志归 systemd 管出问题也好查。5.2 与 Obsidian 笔记库联动如果你在用 Obsidian 做知识管理WorkBuddy 生成的摘要完全可以直接输出到 Obsidian 的仓库目录。把 Skill 里的输出路径指定到 Obsidian vault 的某个文件夹WorkBuddy 每次生成的摘要就自动出现在笔记库里连同步都省了。我现在的每日博客摘要、工作周报、项目复盘全部走的这条链路打开 Obsidian 就能看到最新的自动化产出。这可以说是把“自动化”和“知识管理”打通了价值远超单纯跑个脚本。5.3 在 SkillHub 里积累自己的 Skill用得越久你会发现可固化的任务越多。WorkBuddy 的 Skill 目录结构很清晰建议每个任务一个文件夹命名规范统一内部描述文件写清楚用途和输入输出。积累多了之后换新设备、重装系统只要把这个目录打包拷过去整套自动化能力就迁移了不需要重新教一遍。我目前的目录大概是这样的~/.workbuddy/skills/ ├── blog-daily-digest ├── weekly-report-generator ├── log-cleaner └── meeting-notes-formatter每个 Skill 都是独立的互不依赖出了问题单独修一个就行不会牵连整个系统。5.4 把“0费用”的边界守住讲到最后我想提醒一句所谓的 0 费用靠的是免费额度加轻量调用。如果你的任务量暴增免费额度用完后自然会产生 token 费用。但这个费用依然远低于平台积分模式因为中间没有“托管服务”这道抽成。我这段时间实际跑下来每天几十次调用额度方向一直没超出过免费范围。所以“0费用”不是玄学也不是卡 bug就是换了一种更合理的付费模型——把成本从“积分预付费”变成“用量按需付费”省掉的是平台服务的溢价。写在最后我自己的体会是很多人放着免费工具不用不是不知道而是被“要充积分”“要买会员”这种默认路径困住了。花一个下午动手试一次把 API Key 接进去、把第一个 Skill 跑通那种“积分一分没花任务全自动跑完”的感觉确实挺爽的。最后再分享一个小细节我习惯每次改完 WorkBuddy 配置后都先跑一个最简任务验证再回 systemd 里重启服务宁可多花十秒测试也别让一个错误配置黑灯瞎火跑一整天。希望这篇保姆教程能让你手里那台 Nex N2.5 Pro真正变成一个不用积分也能干活的自动化中心。
