WorkBuddy连接实战:从Skill到MCP,打通智能体工作台
第一步，创建目录和 skill.yaml
name: daily_order_summary
description: 查询昨天的新订单生成摘要并推送
version: 1.0.0
inputs:
- name: db_connection
description: 数据库连接标识
required: true
- name: group_name
description: 目标群聊名称
required: false
default: "运营群"
trigger:
type: cron
expression: "0 9 * * *"
注意到这里 trigger.type 我写的是 cron，也就是说这个 Skill 不止能手动触发，还能做成定时任务。WorkBuddy 的定时表达式基本遵循标准 cron 语法，如果你对 cron 不熟悉，那记住"分 时 日 月 周"的顺序即可。
第二步，写 main.md
这一步不需要你懂太多编程，但你必须说清楚调用逻辑：
## 每日订单摘要
使用连接器 mysql_order_db 执行以下 SQL：
SELECT order_id, customer_name, amount FROM orders
WHERE create_time >= CURDATE() - INTERVAL 1 DAY;
将以上查询结果按金额降序排列。
生成摘要文本，格式如下：
「昨日新增订单 N 单，总金额 M 元，其中最高金额订单来自 {customer_name}，金额 {amount}。」
将摘要发送到 {group_name} 对应的群聊。
我说的"必须"，是因为 WorkBuddy 的 Skill 在运行时会让大模型读这份 Markdown，由模型自己编排下一步调用哪个连接器。如果你的描述含糊，它就可能选错表、算错时间范围。
第三步，在 WorkBuddy 界面里绑定连接器
这一步通常不需要写代码，在"连接"配置页里选择你已配置的数据库连接、群聊应用，然后一次"试运行"。
整体来看，一个 Skill 真正跑通的难点不在 Skill 文件本身，而在于你对外部服务的了解程度。你需要知道： - 这个服务有哪些接口？ - 接口的入参和出参是什么？ - 有哪些必填字段和可选字段？ - 错误码有哪些？分别代表什么含义？
这些知识，通常要从官方文档里一点点读出来。
常见坑点与解决方案
坑点一：连接器配置后仍报错
现象：Skill 运行时报"连接器未找到"或"认证失败"。
排查步骤： 1. 确认连接器已在 WorkBuddy 连接页面成功配置； 2. 检查连接器的认证信息是否过期（如 Access Token 刷新）； 3. 查看连接器的测试按钮是否能正常连通。
坑点二：定时任务不触发
现象：cron 表达式配置正确，但任务始终不运行。
排查步骤： 1. 确认 WorkBuddy 客户端处于运行状态（后台任务需要客户端在线）； 2. 检查 cron 表达式语法是否正确（可用在线 cron 验证工具）； 3. 查看运行日志，确认任务是否被触发但执行失败。
坑点三：参数传递丢失
现象：Skill 运行时，某些输入参数为空。
排查步骤：
1. 检查 skill.yaml 中 inputs 的定义是否与 main.md 中的引用一致；
2. 确认 WorkBuddy 界面中是否已填写所有必填参数；
3. 在 main.md 中使用默认值兜底（default: "默认值"）。
进阶：跨 Skill 协作
当单一 Skill 无法满足需求时，可以组合多个 Skill：
场景：每天生成销售日报后，自动发送邮件给主管。
方案： 1. Skill A（daily_sales_report）：查询数据库，生成日报； 2. Skill B（send_email）：接收日报内容，发送邮件。
两个 Skill 之间通过文件传递数据：Skill A 输出日报到指定路径，Skill B 读取该路径文件并发送邮件。
总结
WorkBuddy 的 Skill 和 MCP 机制，本质上是把"AI 能做什么"的边界交还给用户。你不需要成为程序员，只需要搞清楚你的业务场景需要什么数据、需要经过什么逻辑、最终要输出到哪里。把这些信息用 natural language 写进 Skill，剩下的交给 AI。
当你拥有了第一套自己的 Skill 后，你会发现：那些曾经每天重复的"搬砖"工作，其实都可以交给 AI 去跑。