最近我把自己每天早上那套重复操作全部交给 WorkBuddy 了生成日报、推送企业微信、把记录写进 Obsidian全程不用我点一下鼠标。这不是什么遥远的设想就是我目前在用的 AI 智能体自动化工作流。这篇文章想讲清楚一个完整的落地过程WorkBuddy 是什么、怎么装、怎么把“每日工作自动化”拆成一个智能体任务以及我踩过的一些坑。适合正在研究 AI 智能体怎么落地、想把手头重复劳动自动化掉的朋友参考。先说结论WorkBuddy 这类工具真正解决的问题不是“多一个能聊天的机器人”而是把大模型接进你每天反复做的流程里让它在固定时间、用固定规则、干固定的事。10 分钟跑通第一个任务完全可行。1. WorkBuddy 到底是什么先把它跟普通聊天机器人分清楚1.1 它解决的是“大模型没有手脚”的问题很多人第一次接触 AI 智能体第一反应是这不就是 ChatGPT 套壳吗我问他问题他回答我仅此而已。但 WorkBuddy 的思路完全不一样它把大模型当成一个“会思考的调度中心”真正干活的是任务、Skill、触发器这些外围组件。你可以这样理解普通聊天机器人只有大脑能说不能动而 WorkBuddy 给这个大脑装上了眼睛和手。眼睛是数据输入比如读取本地文件、调用 API、监听 webhook手是输出动作比如往 Obsidian 写笔记、给企业微信发消息、更新表格、执行脚本。中间的大脑负责理解指令、组织内容、决定怎么干。所以它适合的场景很明确一件事如果每天或每周都要重复做并且中间有一环需要“理解文本、整理信息、决定下一步”那这件事就可以交给 AI 智能体自动化。反过来如果只是偶尔问一个知识性问题那确实不需要 WorkBuddy直接开一个对话窗口就够了。我实际用下来的感受是WorkBuddy 最有价值的地方在于“可编排”。它不是让你写一大段复杂的代码而是通过任务配置把不同的小能力串起来。哪怕你不太会编程只要能看懂 YAML 结构也能搭出可用的自动化流程。1.2 三个最典型的自动化场景我见过最多人用 WorkBuddy 跑的场景基本可以归成三类。第一类是定时生成日报并推送到工作群。早上 9 点自动读取日历、待办清单、昨天的聊天记录摘要让智能体整理成“今日完成、明日计划、需要协调”三段式日报然后推到钉钉或企业微信。这个场景几乎每个上班族都需要配置一次之后每天省下的不是几分钟而是“早上进入状态”的那段时间。第二类是跨境电商多平台订单抓取和汇总。这个我在电商团队里见过很实用的案例把 Shopify、Amazon、eBay 的订单 API 分别接进来每天早上自动拉取前一天的订单汇总成一份包含订单数、销售额、异常订单的表格再写入 Google Sheets 或本地数据库。以前运营每天早上要开三个后台逐个对账现在全自动。第三类是笔记和知识库的自动归档。比如每天阅读的网页、随手记的碎片定时让 WorkBuddy 整理成结构化笔记放进 Obsidian 的 vault 里。我自己的使用方式就是每天晚上把当天的零散记录丢进一个文件夹WorkBuddy 自动按主题重新组织第二天打开 Obsidian 就能看到清晰的笔记。这三个场景覆盖了绝大多数“每日工作自动化”的需求信息收集、内容整理、消息分发。理解了这三个方向后面配置任务的时候心里就有谱了。2. 环境准备十分钟把 WorkBuddy 跑起来2.1 安装桌面客户端和命令行版二选一WorkBuddy 的安装方式主要分两种。如果你主要用 Windows 或 macOS图省事直接去官网下载对应系统的桌面客户端双击安装就行。桌面客户端自带图形界面任务列表、日志、Skill 管理都能用鼠标完成适合不习惯敲命令的朋友。第一次启动会让你登录账号然后进入主界面基本没有学习成本。如果你像我一样想把自动化跑在 Linux 服务器上或者不想每天开着电脑才能触发任务那就用命令行版本。安装命令很简单pip install workbuddy-cli装完之后验证一下workbuddy --version如果能看到版本号说明安装成功。命令行版依赖 Python 3.10 以上建议用一个干净的虚拟环境装避免和系统里其他 Python 包冲突。我踩过的一个小坑是直接用系统 Python 装结果和已有的包版本冲突后来改用 venv 就再没出过问题。我的建议是如果你只是想体验一下用桌面客户端最快如果你打算把每日自动化真正长期跑起来直接上命令行版放在一台长期开机的机器上这样才能实现“无人值守”。笔记本每天关机定时任务自然也跑不了。2.2 首次初始化接入大模型和设置全局指令安装完成后第一次使用需要初始化配置。命令行里执行workbuddy init这个命令会引导你完成三件事选择模型服务商、填写 API 密钥、确认全局配置目录。WorkBuddy 支持 OpenAI 兼容接口也支持 Ollama 这类本地模型服务。我建议根据自己的实际网络环境和成本选如果只是处理日常文字整理用云端 API 就好如果数据敏感或者完全离线用 Ollama 跑一个 7B 左右的小模型也能完成大部分任务。关键是“能调用通”模型本身不用特别大。API 密钥不要直接写在命令行历史里我习惯用环境变量注入。在 shell 配置文件里加上export WORKBUDDY_API_KEYsk-你的密钥 export MODEL_BASE_URLhttps://你的模型服务地址/v1然后workbuddy init的时候它会自动读取这些环境变量配置文件里只保存变量名引用不落明文密钥。初始化完成之后运行workbuddy doctor它会检查模型是否能连通、配置目录是否有写权限、Skill 是否加载正常。这一步很重要很多后续问题都能在这里提前发现。2.3 目录结构任务、Skill、日志都放在哪理解 WorkBuddy 的目录结构对排查问题非常有帮助。默认情况下所有内容都在~/.workbuddy/下结构大概是这样的~/.workbuddy/ ├── config.yaml ├── skills/ │ ├── report/ │ │ └── SKILL.md │ └── webhook_push/ │ └── SKILL.md ├── tasks/ │ └── daily_report.yaml ├── logs/ │ └── daily_report/ └── data/tasks/目录放每个自动化任务的配置skills/目录放可复用的能力模块logs/按任务名分目录存放运行日志data/存任务产生的中间数据。搞清楚这些目录后面遇到“任务没跑”“输出不对”的时候第一反应就知道去 logs 里翻记录。桌面客户端的目录结构是一样的只是通过界面操作。我实际用下来命令行版配合文本编辑器改配置比在图形界面里一个个点更高效尤其是批量修改多个任务的时候。3. 核心概念Skill、自定义指令和触发器怎么配合3.1 Skill把“能做的事”封装成可复用模块WorkBuddy 里最核心的概念是 Skill。你可以把它理解成一个“带说明书的小工具”它告诉智能体自己能干什么、需要什么输入、会产生什么输出。一个 Skill 通常就是一个目录里面有一个SKILL.md文件描述功能和提示词也可以附带脚本。我自己写的一个日报 Skill 长这样--- name: report description: 把一堆零散输入整理成日报格式 inputs: - raw outputs: - content prompt: | 你是一名运营助理。根据以下原始信息生成日报分三部分 今日完成、明日计划、需要协调。没有的信息写未获取。 原始信息 {{ raw }}这个 Skill 被任务引用后智能体就会按照这个提示词的规则来处理raw输入。好处是日报格式可以反复用今天接日历数据、明天接订单数据只要最终都变成raw文本输入这个 Skill 就不用改。你可以在~/.workbuddy/skills/下建自己的 Skill 目录也可以用workbuddy skill create命令初始化一个模板。自己写 Skill 的时候我建议描述写得清楚一点尤其是“输入”和“输出”字段这会直接影响智能体在复杂任务中能不能正确选择这个 Skill。3.2 自定义指令给智能体定行为规范如果说 Skill 解决的是“能干什么”自定义指令解决的就是“按什么规矩干”。WorkBuddy 的自定义指令分全局和任务级两层。全局指令写在配置里会对所有任务生效。我自己设的全局指令是这样的你是一名运营助理。所有输出必须 1. 使用简体中文 2. 使用 Markdown 的列表和标题 3. 不编造数据缺失信息一律标记为未获取 4. 结尾不要写祝好之类的客套话任务级指令写在这个任务自己的 YAML 配置里只对这个任务生效。比如日报任务里我会额外加一句“今天是周五时在计划部分增加周末值班说明”。这样既保证整体风格一致又能针对每个任务做细化。很多人在用 AI 智能体的时候觉得结果不可控其实大部分问题出在指令定得太模糊。把输出格式、语言、缺失信息怎么处理、内容边界这些写清楚结果的可控性会明显提升。这和带新人一样你把规则讲清楚他才能把活干对。3.3 触发器定时、事件和手动触发一个自动化任务不能被触发那它只能算个脚本。WorkBuddy 支持三种触发方式定时触发、事件触发、手动触发。定时触发用 cron 表达式配置最常用。比如每天早上 9 点跑日报trigger: type: cron schedule: 0 9 * * * timezone: Asia/Shanghai注意一定要显式配置timezone不然服务器时区不同任务可能会在错误的时间点运行。这个坑我踩过后面排查部分会细说。事件触发是通过 webhook某个外部系统发来请求时触发任务。比如订单平台的推送服务有新订单就调用 WorkBuddy 的 webhook 地址。手动触发就是在命令行执行workbuddy run 任务名 --now或者桌面端点运行按钮。我调试任务的时候基本都是手动触发确认没问题了再开定时。三种触发方式可以同时存在一个任务既可以被定时触发也可以被手动重跑。灵活度非常高。4. 完整实战搭建“每日工作自动化”智能体4.1 先把要自动化的事情拆成一二三步这里我拿一个完整的例子来讲场景是跨境电商运营人员每天早上要整理各个平台的新订单生成日报推送到钉钉群并把内容写进 Obsidian 笔记。在动手配置之前我会先把这个流程画成几个步骤从订单平台获取前一天订单数据比如 Shopify、Amazon 分别返回一份 JSON。让智能体识别关键指标订单数、销售额、异常单数并生成简单摘要。把摘要格式化成日报推到钉钉群 webhook。把同一份日报追加写入 Obsidian 的每日笔记文件。为什么要这样拆因为每一步的输入输出都是清晰的智能体不容易乱。如果你只写一句“每天帮我汇总订单”它会不知道去哪拉数据、按什么格式汇总、汇总完放哪。明确每个步骤的数据来源和去向任务就成功了一半。4.2 创建任务并配置参数先在命令行创建一个任务workbuddy task create daily_order_report执行后会在~/.workbuddy/tasks/daily_order_report.yaml生成一个模板文件。打开它改成下面这样name: daily_order_report trigger: type: cron schedule: 0 9 * * * timezone: Asia/Shanghai inputs: platform_apis: - name: shopify url: https://你的店铺.myshopify.com/admin/api/2024-01/orders.json token_env: SHOPIFY_TOKEN - name: amazon url: https://sellingpartnerapi.amazon.com/orders token_env: AMAZON_TOKEN model: provider: openai-compatible base_url: ${MODEL_BASE_URL} api_key: ${WORKBUDDY_API_KEY} model_name: deepseek-chat temperature: 0.3 max_tokens: 2000 steps: - skill: fetch_orders params: apis: {{inputs.platform_apis}} - skill: summarize_orders - skill: webhook_push params: webhook_env: DINGTALK_WEBHOOK - skill: file_append params: file: ~/ObsidianVault/Daily/{{now | date(%Y-%m-%d)}}.md这里有几个参数值得说一下。temperature我设成 0.3。日报是事实汇总不是创意写作温度越低输出越保守越不容易自己发挥出不存在的数据。max_tokens设成 2000是考虑到 4 个平台的订单摘要加上 Markdown 标记留足余量但又不会因为超长而白白消耗 token。fetch_orders这个 Skill 是通用的“拉取 API 并解析 JSON”模块summarize_orders是“把多段数据总结成日报”的模块这两个 Skill 可以复用。webhook_push负责把文本 POST 到钉钉群机器人地址file_append负责把内容追加到指定文件。环境变量SHOPIFY_TOKEN、AMAZON_TOKEN、DINGTALK_WEBHOOK都在启动 WorkBuddy 之前注入不在配置文件里出现明文密钥。这是我一直坚持的安全习惯。4.3 验证运行和结果检查配置完成后先不要等定时触发手动跑一次workbuddy run daily_order_report --now执行过程中WorkBuddy 会打印每个步骤的运行状态。跑完之后检查结果分三步第一步看推送是否成功。钉钉群里如果收到了日报说明 webhook 这一步通了。第二步看文件是否写入。打开 Obsidian 对应当天的笔记确认内容格式正确。这里要注意file_append用的是绝对路径如果写成相对路径可能跑到 WorkBuddy 自己的目录里去了。第三步看日志。命令行执行workbuddy log daily_order_report --tail 50日志会告诉你每一步的耗时、token 消耗、有没有报错。第一次跑的时候我在这里发现fetch_orders的请求超时后来在 Skill 里加了超时重试参数第二次就正常了。跑通之后再把定时触发器打开。你会发现真正花时间的不是配置本身而是把每一步的输入输出理清楚。只要这一步做扎实了后面的配置只是填空。5. 常见问题与排查技巧实录5.1 写入权限报错502 write EACCES这个报错我一开始真被它唬住了错误信息长得吓人但实际原因很简单WorkBuddy 没有权限写入它默认的缓存或日志目录。常见于 Linux 服务器上比如用普通用户跑但默认目录指向了需要 root 权限的位置。排查方法很简单先看日志workbuddy log 任务名 --tail 50如果里面有PermissionError: [Errno 13] Permission denied基本就是权限问题。解决办法是手动指定一个有权限的目录workbuddy config set cache_dir ~/.cache/workbuddy mkdir -p ~/.cache/workbuddy然后把原来的缓存目录清一下重新跑任务就好了。这个问题在桌面客户端上很少见主要发生在自己部署到服务器上的场景。5.2 输出格式不稳定怎么办AI 智能体最常见的问题就是“这次对下次错”。日报偶尔冒出来一段没要求的客套话或者把 JSON 输出成了带解释的文字。我应对这个问题的方案有三层。第一层在模型参数里把温度降下来temperature直接设 0。特别注意像日报这种任务完全没必要让模型自由发挥。第二层在自定义指令里给出明确的输出模板。不是写一句“用 Markdown 输出”而是把结构直接写进去标题用什么、列表用什么、每部分放什么内容、没有数据的地方写什么。模型看到的是规范而不是要求效果会好很多。第三层也是最厉害的让智能体自检。我加过一个小 Skill专门检查自己的输出是不是符合模板要求不符合就重新生成一遍。虽然多消耗一点 token但对关键输出任务来说值。格式问题不是玄学大部分时候是你没把规则定死或者是温度太高给了模型发挥空间。5.3 Linux 服务器上跑要注意什么如果你准备把 WorkBuddy 部署在 Linux 服务器上常驻运行有几个点需要提前想清楚。第一是进程管理。直接用workbuddy run 任务名跑ssh 断开进程就没了。我建议用 systemd 服务来管写一个简单的 service 文件开机自启还能自动重启比放后台 nohup 靠谱得多。第二是时区。服务器默认时区不一定是北京时间而定时任务用的是本地时区。最稳妥的做法是在每个任务的 YAML 里都显式写timezone: Asia/Shanghai不要依赖服务器全局设置。第三是资源占用。如果你用的是云端 API本机资源占用不大但如果用本地 Ollama 模型7B 模型跑起来内存和 CPU 压力不小别把它和处理业务的服务器放在一起。我自己的做法是把自动化任务放在独立的一台小机器上专门干这活。5.4 其他高频问题速查表我把实际使用中遇到过的其他问题整理成了一个表方便你对照排查现象可能原因解决思路定时任务没触发没设置 timezone或 daemon 没在运行任务里显式写timezone执行workbuddy daemon status确认进程状态webhook 推送失败地址失效或签名不对用curl手动 POST 同一地址测试确认不是 WorkBuddy 的问题Obsidian 文件没生成路径写错或 vault 目录不存在检查file_append的路径换成绝对路径并确认目录存在模型调用提示限流请求太频繁或并发太高降低任务频率在 Skill 里加重试和指数退避Windows 下中文乱码终端或文件编码不是 UTF-8环境里设置PYTHONUTF81文件统一用 UTF-8 编码任务能跑但内容质量差指令不够具体数据源太乱给模型更多示例减少“开玩笑”“自由发挥”的余地多个任务写同一个文件并发写入导致内容覆盖文件名加时间戳或拆成独立文件后再合并排查问题的时候记住一个原则先看日志再改配置不要凭感觉乱试。WorkBuddy 的日志写得已经比较清楚了大多数问题都能在里面找到直接原因。最后分享一个我自己的使用习惯我从来不在 WorkBuddy 里堆太多同时跑的任务而是每天只保留三四个真正高频的动作每周花十分钟翻一遍日志把效果不好的 prompt 顺手改掉。这套东西不需要一次做得多大贵在持续迭代。等你的第一个自动化任务跑顺了你会发现自己对“重复劳动”这件事的忍耐度会越来越低。