WorkBuddy Skills、MCP 和定时自动化教程
WorkBuddy 的基础任务解决“这次把文件处理好”，Skill、MCP 和自动化解决“以后按同一套规则重复处理”。三者经常被放在一起搜索，但作用不同：Skill 是方法和模板的封装，MCP 是连接外部工具或数据，自动化是触发和重复执行的机制。先把一次任务跑通，再把稳定部分抽出来，通常比直接搭建一整套无人值守流程更容易维护。
官方文档将 Skill、助理接入和实践案例分别列出；不同版本的名称、入口和可用范围可能变化。本文写的是能力设计和验收方法，具体菜单以当前 WorkBuddy 客户端为准。涉及外部服务时，还应遵守组织的安全、隐私和审批要求。
Skill、MCP、自动化分别是什么
Skill 适合保存一套可复用的工作方法。例如“从会议记录生成周报”可以固定输入目录、输出模板、日期格式、引用方式和检查清单。Skill 不等于模型本身，它只是把任务说明、模板和步骤组织起来，让每次执行更接近同一标准。
MCP 让 WorkBuddy 连接外部工具或数据源。它可能读取知识库、查询项目系统、访问文档服务或调用团队内部工具。MCP 服务器决定提供哪些工具，账户权限决定能读写哪些对象。连接成功不代表每个工具都可用，也不代表所有返回内容都可信。
自动化负责触发。它可以按时间、手动按钮或某个事件启动任务，然后调用 Skill、读取输入和产出结果。自动化的关键不是“每天自动跑”，而是定义输入是否完整、失败时是否停止、什么结果需要人工审核、重复执行会不会产生副作用。
| 能力 | 解决的问题 | 主要风险 |
|---|---|---|
| Skill | 怎样按固定方法完成任务 | 规则过时、输入不完整 |
| MCP | 怎样取得外部数据或调用工具 | 权限、数据范围、写入副作用 |
| 自动化 | 什么时候重复执行任务 | 重复运行、失败传播、无人审核 |
先把手动任务写成标准流程
在创建 Skill 前，先手动完成三次相同类型任务，记录每次需要的输入、判断和输出。比如周报任务需要读取哪些文件、如何区分完成和进行中、没有来源的内容如何处理、文件保存到哪个目录。三次执行的差异能帮你发现哪些步骤适合固定，哪些仍需要人工决定。
一个可复用流程应包含触发条件、输入清单、处理步骤、输出格式、验证方法和停止条件。停止条件非常重要：输入目录为空、关键字段缺失、来源日期超出范围、写入权限不足时，流程应该停止并报告，而不是生成一份看起来完整的结果。
不要把所有经验都写进一段超长提示词。把长期规则、模板、示例和一次任务的具体数据分开。Skill 负责方法，任务负责当次范围，MCP 负责数据连接，自动化负责触发。分层后，任何一层变化都更容易排查。
Skill 的输入和输出怎么设计
输入尽量使用明确的目录、文件类型和字段。若 Skill 处理表格，说明日期列、金额单位、空值规则和重复行判断；若处理文档，说明标题层级、引用格式和语言。不要只写“整理得专业一点”，这种要求无法稳定验收。
输出应该有固定文件名或目录规则，同时保留一份执行摘要。摘要可以列出读取的文件、跳过的文件、异常项、生成物和未完成原因。这样你不必打开每个文件才能知道任务是否完整，也能在失败后继续处理剩余部分。
示例 Skill 说明可以这样写：
任务：从 input/meeting/ 读取指定日期的会议记录，生成 output/weekly-report.md。
规则：只使用输入文件；没有来源的数字标记为待确认；按日期和主题排序；不修改 input/。
检查：输出必须包含完成、风险、待确认三节，并列出来源文件。
停止：输入目录为空、文件无法读取或日期范围不明确时停止。上线前用几组不同输入测试，包括空目录、缺字段、重复文件和超长文本。测试目的不是让所有情况都生成结果，而是确认异常时会停在合适的位置。
MCP 接入前先做只读测试
连接 MCP 前，确认服务器来源、传输方式、认证方式和工具列表。先使用只读查询，选择一条你能独立核对的记录。让 WorkBuddy 说明它准备调用哪个工具、传入什么对象、返回内容的来源是什么。不要第一次就连接生产数据库、批量修改项目或发送通知。
MCP 工具描述不等于服务端权限。即使 Skill 中写了“只读”，如果服务端 Token 拥有写权限，仍需在服务端限制。工具返回的数据也可能包含用户信息、内部链接和过时记录，传入模型前应按组织数据规则筛选。
调用成功后记录服务器名称、工具名称、输入概要、返回状态和是否产生副作用。连接失败时区分进程没启动、网络不通、认证失败、权限不足和业务参数错误。不要通过反复登录或给所有工具开放权限来掩盖具体原因。
自动化任务的最小闭环
自动化最好从一个手动可重复的任务开始。先运行一次，确认输入、输出和审核；再设置每天或每周触发；最后观察两到三次运行记录。每次运行都应有唯一的时间或任务标识，输出目录不能因为重试而互相覆盖。
自动化说明应包含触发时间、时区、输入范围、输出位置、失败通知、重试上限和人工审核步骤。时间表使用哪一个时区要写清楚，尤其是团队成员跨地区工作时。输入目录为空时，是跳过、通知还是生成空报告，也需要提前决定。
如果自动化要发送邮件、更新在线表格或发布内容，先生成草稿并暂停在审核节点。只有在业务明确授权、对象和内容都能检查时，才考虑自动发布。模型输出不是发布批准，自动化完成也不代表业务结果正确。
自动化的失败处理
失败分为输入失败、工具失败、模型失败、写入失败和审核失败。输入为空时不应继续调用昂贵模型；MCP 超时时可以有限重试；写入失败时要检查是否已经创建部分文件；审核未通过时应保留草稿而不是删除。
重试必须考虑幂等性。读取和计算通常可以重试，发送通知、创建订单或追加表格行可能会重复副作用。对有写入动作的流程，先查询结果是否已经存在，再决定是否重试。记录请求标识和输出路径，方便恢复。
自动化日志不要保存完整 Key、整份客户资料或不必要的提示词。保留时间、任务 ID、输入数量、输出文件、错误类型和审核状态即可。日志本身也是一类数据，应该有保留期限和访问权限。
用 ClawSocket 统一模型入口
WorkBuddy 的 Skill、MCP 和自动化都可能触发模型请求。若使用自定义 Provider，可以前往 ClawSocket 控制台，创建自动化专用 Key，按当前版本填写 https://api.clawsocket.com/v1 和控制台中的精确模型 ID。自动化使用的 Key 不要与个人测试混用，以便按项目和任务核算费用。
先用短文本和少量测试文件跑通 Skill，再加入 MCP 和定时触发。普通文本正常不代表工具调用和长上下文正常，因此需要单独验收。模型切换后重新检查输出格式、工具选择和失败处理，不要把一个模型的特殊参数复制给所有模型。
成本控制可以从三处入手：固定系统说明以提高缓存命中，限制输入目录和历史上下文，给自动化设置单次输出上限和每日额度。遇到 429 或 5xx 时使用有上限的退避，不要让定时任务无限重试。可参考WorkBuddy 中转站配置指南。
表格：自动化上线前检查
| 项目 | 检查问题 | 通过标准 |
|---|---|---|
| 触发 | 时间和时区是否明确 | 在测试环境按预期触发 |
| 输入 | 文件、字段和日期范围是否完整 | 缺失时能停止并通知 |
| Skill | 规则和模板是否稳定 | 多组样例输出结构一致 |
| MCP | 工具、账号和权限是否匹配 | 只读测试可独立核对 |
| 输出 | 文件名、路径和格式是否固定 | 可打开且不会覆盖旧结果 |
| 审核 | 哪些动作需要人确认 | 没有批准不会发布 |
| 失败 | 重试和恢复是否定义 | 不重复产生外部副作用 |
| 费用 | Key、模型和额度是否独立 | 可在控制台查到用量 |
FAQ：Skill、MCP 和自动化
Skill 和提示词有什么区别？
提示词通常描述一次任务，Skill 适合保存长期复用的方法、模板、输入输出和检查规则。Skill 仍需要当次任务提供具体范围和资料。
MCP 接入成功就能使用所有工具吗？
不一定。连接成功只说明客户端发现服务器，具体工具还受认证、对象权限、参数和后端状态影响。先做一条只读查询。
WorkBuddy 自动化可以直接发邮件吗？
是否支持取决于当前版本和连接工具。建议先生成草稿并保留人工审核，确认对象、内容和授权后再执行有外部影响的动作。
自动化失败后要不要无限重试？
不要。根据错误类型设置有限重试和总超时，对写入、通知和发布动作先查询是否已经成功，避免重复副作用。
为什么 Skill 第一次运行正常，第二次结果不同？
检查输入文件、日期范围、模型、上下文和外部工具返回是否变化。固定输出格式和验收清单，才能判断差异来自资料还是规则。
可以把同一把 ClawSocket Key 给所有自动化用吗？
不建议。按项目或用途分开创建 Key，设置额度和轮换策略，出现异常用量时更容易定位和撤销。
从一次任务走向可靠流程
当一个手动任务连续几次都能稳定完成，才适合抽成 Skill；当需要外部数据时，再添加 MCP；当触发条件和审核方式明确后，再设置自动化。每一步都保留测试资料和运行记录，出问题时可以回到上一层。
如果你还没有完成第一次 WorkBuddy 任务，先看WorkBuddy 使用教程总入口和安装与第一个任务。如果模型请求本身失败，查看WorkBuddy API 接入和流式输出与错误重试。
失败记录和版本维护
Skill、MCP 和自动化都应记录版本或更新时间。模型、工具参数和数据源变化后，先在测试资料上复跑，比较输出结构和异常处理。若规则已经不适用，更新 Skill 或服务器配置，再恢复定时任务。不要让自动化继续使用一份没人负责维护的旧流程。
维护记录可以很短：最近一次测试日期、输入样例、通过的能力、已知限制和负责人。遇到失败时把新错误追加到排查文档，而不是把所有错误都写进提示词。这样团队能区分产品行为变化、数据变化和任务描述问题。