乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > 你在OpenClaw上搭的工作流,能直接搬进WorkBuddy吗?

你在OpenClaw上搭的工作流,能直接搬进WorkBuddy吗?

当前时间： 2026-07-14 21:51:42 更新时间： 2026-07-14 分类：软件教程 评论(0)

你在OpenClaw上搭的工作流,能直接搬进WorkBuddy吗?

我在 OpenClaw 上跑了半年自动化，攒了两十几个 Skills，搭了一套三 Agent 协作系统，还接了五六个 MCP 服务器。

后来看到 WorkBuddy 说”兼容 OpenClaw Skills”，第一反应是：能一键迁移吗？

花了一周研究，答案是：能迁，但不是一键的事。

Skill 文件能直接迁，MCP 工具链能部分迁，多 Agent 配置迁不了。以及——有很多你以为能迁其实不能的东西。

这篇把每一个细节全部讲清楚。

先搞清楚这俩到底是什么关系

WorkBuddy 是腾讯基于 OpenClaw 架构做的商业化产品。两者有血缘，但不是同一个东西。

  • OpenClaw 是开源框架：你在服务器上部署，自己维护，多 Agent、多渠道接入、完整的 MCP 工具链都支持。灵活，但需要技术能力。

  • WorkBuddy 是桌面端产品：装完就能用，腾讯托管了底层，但它和 OpenClaw 的 Skill 系统兼容，SKILL.md 文件格式通用。

所以你 OpenClaw 上的 Skill 积累，理论上能迁移。但你搭的那套复杂架构——多 Agent 配置、MCP 服务器连接、后台部署环境——迁移不了。WorkBuddy 替你托管了这些，你交出控制权换来零配置。

Skill 文件怎么迁：一步一步来

Skill 是 OpenClaw 扩展能力的核心。一个 Skill 就是一个文件夹，里面有且只有一个 SKILL.md 文件，外加可选的辅助脚本和参考文档。

迁移步骤

第一步：找到你的 Skills

OpenClaw 的 Skills 按优先级从高到低加载：

优先级
来源
路径
******
******
******
1（最高）
Workspace skills
`/skills`
2
Project agent skills
`/.agents/skills`
3
Personal agent skills
`~/.agents/skills`
4
Shared managed skills
`~/.openclaw/skills`
5
Bundled skills
随安装包自带
6（最低）
Extra directories
`skills.load.extraDirs` + 插件自带

同名 Skill，高优先级覆盖低优先级。你需要把 /skills 和 ~/.openclaw/skills 里的东西都过一遍。

第二步：复制到 WorkBuddy

WorkBuddy 设置里有个”Skill 管理”页面，显示它的加载目录。把 SKILL.md 及其所在文件夹复制进去。

第三步：处理环境变量依赖

这是最容易踩坑的地方。OpenClaw 的 Skill 在 frontmatter 里声明 requires.env，比如 STRIPE_API_KEY。这些变量在 OpenClaw 环境里可能已经配置好了，但 WorkBuddy 读不到。

需要在 WorkBuddy 的”配置”页面重新填一遍这些密钥。

第四步：处理 install 声明

如果 Skill 的 frontmatter 里有 install 字段声明了 brew/node/go/uv 安装依赖，这套机制在 WorkBuddy 里完全不支持。WorkBuddy 没有包管理器，install 字段会被忽略。

第五步：验证加载状态

在 WorkBuddy 的 Skill 市场里刷新，看状态是”已加载”还是”加载失败”。失败的原因一般有两种：

1. 这个 Skill 调用了 OpenClaw 特有的工具（WorkBuddy 没有等效能力）

2. 依赖的环境变量没填，或者 install 依赖没满足

哪些 Skill 能直接迁

能直接迁的：

  • 纯 prompt 类 Skill（只靠 LLM 输出，不调用特殊工具）

  • 文件读写类 Skill（WorkBuddy 有内置的本地文件访问能力）

  • Web 搜索类 Skill（WorkBuddy 内置联网能力）

  • 调用 curl 等常见 CLI 工具的 Skill（假设那些工具在你电脑上存在）

迁不了的：

  • 依赖 install 字段的 Skill（WorkBuddy 没有包管理器）

  • 依赖 requires.bins 里特定工具的 Skill（如果那个工具 WorkBuddy 环境里没有）

  • 依赖 requires.config 配置文件的 Skill（路径映射不一样）

  • 调用了 OpenClaw 特有工具的 Skill（比如 sessions_spawn、clawhub CLI 等）

  • 依赖 always: true 常驻加载机制的 Skill（WorkBuddy 没有这个概念）

SKILL.md 字段对照：哪些 WorkBuddy 支持

字段
OpenClaw
WorkBuddy
备注
******
*********-
*********–
******
name
✅
✅
description
✅
✅
version
✅
❌
不读取
requires.env
✅
⚠️
需手动填入
requires.bins
✅
❌
无等效机制
requires.anyBins
✅
❌
requires.config
✅
❌
primaryEnv
✅
⚠️
需手动设置
envVars
✅
⚠️
需手动映射
always
✅
❌
无常驻机制
skillKey
✅
❌
emoji
✅
❌
homepage
✅
❌
os
✅
⚠️
部分支持
install
✅
❌
不支持任何包管理器
nix
✅
❌
config
✅
❌

MCP 工具链怎么迁

MCP（Model Context Protocol）是让 AI Agent 连接外部工具的标准协议。OpenClaw 跑生产级工作流的时候，很多人接了 MCP 服务器——接 Stripe 做支付、接 GitHub 管代码、接 Postgres 查数据。

OpenClaw 的 MCP 配置方式

在 ~/.openclaw/mcp/ 目录下放配置文件，定义每个 MCP 服务器的地址和权限。OpenClaw 启动时加载，Skill 可以直接调用这些 MCP 工具。

WorkBuddy 的 MCP 配置方式

在 WorkBuddy 设置的”MCP 服务器”页面，手动填入 MCP 服务器地址和 API Key。格式和 OpenClaw 不完全一样，需要对照翻译。

核心问题：你那些 MCP 服务器能不能连上

OpenClaw 跑在服务器上，服务器在企业内网里，接内网 MCP 很自然。

WorkBuddy 跑在你电脑上，你电脑可能不在公司内网——很多企业的 MCP 服务器只有内网 IP，没有公网地址。

解决方案有两个：

1. 把 MCP 服务器暴露到公网（安全风险，一般不推荐）

2. 用 WorkBuddy 内置的等效工具替代（文件处理、网页访问、Office 操作，WorkBuddy 都有内置支持）

大部分办公场景 WorkBuddy 内置工具就够了。你不需要迁每一个 MCP，评估一下哪些环节真的依赖特定 MCP，再决定怎么处理。

Skill 里的 MCP 依赖怎么迁

有一种 Skill 本身不直接调用 MCP，而是通过 OpenClaw 的工具间接使用。比如某个 Skill 的 SKILL.md 里写了”用 GitHub MCP 查看 issue”，这种 Skill 迁过去之后，GitHub MCP 的调用路径就断了。

你需要找到 Skill 文档里所有 MCP 相关的描述，对照 WorkBuddy 的能力看哪些能替代、哪些必须放弃。

多 Agent 配置：这两根本不是一回事

这是最容易被混淆的地方。

OpenClaw 的多 Agent 是架构设计

每个 Agent 有独立的 SOUL.md（人格）、TOOLS.md（工具权限）、MEMORY.md（记忆）、独立的 session store。它们通过 sessions_send 互相通信，通过 sessions_spawn 派生子 Agent。

这是架构层面的设计——你在设计一个多 Agent 系统。

OpenClaw 还支持 Agent Allowlist——你可以精确控制每个 Agent 能看到哪些 Skills：

{   agents: {     defaults: {       skills: ["github", "weather"]     },     list: [       { id: "writer" },       { id: "docs", skills: ["docs-search"] },       { id: "locked-down", skills: [] }     ]   } } 

WorkBuddy 的多 Agent 是任务分解

你给一个复杂任务，WorkBuddy 自动把它拆成多个子任务，分配给不同的执行单元跑，最后合并结果。你不需要设计 Agent 架构，只需要描述清楚任务。

这两件事不是同一个维度。

如果你在 OpenClaw 上配了复杂的多 Agent 团队，迁移到 WorkBuddy 之后，这套架构逻辑不存在了。

你需要重新用 WorkBuddy 的方式描述你的需求——把原来架构层面的设计，变成描述层面的指令。

沙盒安全模型：容易忽略的差异

OpenClaw 的安全边界是 workspace——每个 Agent 的 workspace 是它的主目录，但绝对路径可以突破这个边界（除非显式启用沙盒）。

WorkBuddy 是保守的沙盒设计：

  • 只能访问用户授权的文件夹

  • 危险操作（格式化磁盘等）自动阻断

  • Docker/Podman 本地容器或 E2B 云端隔离

这意味着有些在 OpenClaw 上能跑的操作，在 WorkBuddy 里会被沙盒拦截。如果你的 Skill 里有需要更高系统权限的操作，迁过去之后可能会失败。

反过来，这也意味着 WorkBuddy 比你自己部署的 OpenClaw 更安全——你不需要自己配置沙盒规则，WorkBuddy 默认就是隔离的。

值不值得迁移：判断标准

值得迁的场景：

  • 主要跑的是办公类 Skill（文件处理、文档生成、数据整理）

  • Skill 依赖环境变量少，或者那些变量 WorkBuddy 配置里能填

  • 不想维护服务器，想要桌面端零配置使用体验

  • 用腾讯办公套件（企业微信、腾讯文档、腾讯会议），WorkBuddy 集成更顺

不值得迁的场景：

  • 工作流重度依赖特定 MCP（ERP、内部数据库，没有公网地址）

  • Skill 使用了 install 字段安装依赖（迁过去工具链就断了）

  • 需要 24 小时运行（WorkBuddy 是桌面应用，关机就停）

  • 多 Agent 架构复杂，迁移成 WorkBuddy 的任务描述成本高

  • 依赖 OpenClaw 的 channel 集成（微信、Telegram 等多渠道消息接入）

还有一种思路：两个都留着。

WorkBuddy 处理日常快速任务，它的 Skill 市场有 100 多个现成 Skills，可以直接用。OpenClaw 跑需要后台运行、长期待机、复杂多 Agent 架构的工作流。

我现在就是这么分工的。

AI先见 | AI时代，智者先见

深度AI洞察 · 实践案例分享

我是元宝AI产品，ask me everything