文章核心摘要：

本文详细介绍了为AI智能体（Agent）交付工具OpenClaw所创建的一个“多Agent交付打包Skill”，其核心目标是解决从开发者本地环境到客户现场部署的标准化交付难题。

文章的主要内容和观点总结如下：

1. 问题背景与痛点

开发者（如作者）在本地调试OpenClaw的单个或多个Agent时很顺利，但在将Agent交付给客户时，会遇到一系列复杂问题：
- 客户机器的路径与开发者不同。
- Agent的workspace（工作区）无法直接复制。
- 飞书（Feishu）机器人迁移后配置正确但不回复。
- 迁移多个Agent时，配置合并容易损坏目标环境。
- 客户不可能每一步都询问开发者。

2. Skill的核心解决方案

这个打包Skill旨在将“开发机上的Agent”变成“客户可安装的交付包”，其核心功能包括：

支持场景：单Agent打包、多Agent打包。
核心功能：自动合并配置、生成安装脚本、提供配对指引、默认打包瘦身、可选携带Memory（记忆）。
交付目标：让客户通过解压、阅读README、运行检查脚本CHECK.ps1和安装脚本INSTALL.ps1，即可完成部署。

3. 四个关键设计原则

为确保方案的可靠性与可维护性，作者设定了四个核心原则：

原则1：默认瘦身：默认不打包运行时垃圾（如sessions、缓存、日志），只打包必要内容，以减小体积、降低风险和便于维护。
原则2：Memory可选：默认不打包Agent的“记忆”，仅当使用--include-memory参数时才打包，以适应不同场景需求。
原则3：只合并必要字段：不整体替换客户的openclaw.json配置文件，而是精确合并必要部分（如agents.list、bindings等），避免破坏客户现有环境。
原则4：单/多Agent统一模型：将单Agent打包视为多Agent打包的特例，使用同一套逻辑处理，提高代码可维护性。

4. 生成的交付包结构与文件作用

交付包具有标准化的文件结构，每个文件都有明确用途，例如：

README.md：给客户的说明书。
CHECK.ps1/ INSTALL.ps1：检查与自动安装脚本。
manifest.json：记录打包详情的清单。
configs/：包含配置片段。
workspaces/：包含Agent的工作区文件。

5. 实践中遇到的“坑”与对策

文章分享了宝贵的实战经验，指出了几个容易导致交付失败的关键点：

坑1：迁移成功 ≠ 机器人能回复：Agent配置加载成功后，若飞书机器人提示access not configured，通常是因为未完成用户授权（Pairing），而非安装失败。
坑2：客户不懂Pairing流程：必须在README.md和安装指引中明确告知客户如何进行Pairing授权。
坑3：配置中引用的workspace目录可能不存在：脚本会检测并记录警告，而非阻塞打包。
坑4：重启命令可能延迟返回：判断安装成功应结合配置写入和日志启动记录，而非仅看命令行是否立刻退出。

6. 开源动机与后续计划

作者认为这是一个普遍存在的交付问题，因此决定将Skill开源到GitHub，以方便他人直接使用、修改和共同完善。未来计划增强对非技术客户的指引、完善脱敏包模式等。

总结：这篇文章系统地分享了一个将OpenClaw Agent从开发环境标准化交付到客户生产环境的完整解决方案，其价值在于将繁琐、易出错的手动交付过程，封装成了一个自动化、可复用的Skill，并深刻总结了其中的设计原则与实践陷阱，对从事AI智能体交付的开发者具有很高的参考价值。

【GitHub Skill 】 OpenClaw多Agent交付给客户的流程Skill

正文开始

很多人把 agent 跑在自己的电脑上时，一切都很顺。但一旦要把一个或者多个 agent 交付给客户，问题马上就来了：

客户机器上的 OpenClaw 路径不一样
agent 的 workspace 在你本地，不能直接照搬
Feishu 机器人迁移过去后，可能配置对了但就是不回复
多个 agent 一起迁移时，配置合并很容易把目标环境搞坏
真正交付时，客户又不可能每一步都来问你

所以我这段时间，专门做了一件事：把 OpenClaw 的 agent 交付流程，收敛成一个可复用的打包 skill。

它现在已经支持：

单 agent 打包
多 agent 打包
默认瘦身
可选携带 memory
Windows 自动安装
目标 OpenClaw 自动合并配置
Feishu 迁移后的配对流程指引
适合内部迁移，也适合后续做外发脱敏包

GitHub 地址放这里，文末也会再放一次：

https://github.com/你的用户名/你的仓库名

一、我为什么要做这个 skill

最开始我不是想“做一个 skill”，而是被真实交付需求逼出来的。

场景非常典型：

C 盘是一套已经跑通的 OpenClaw
D 盘装了最新版本 OpenClaw
我希望把 C 盘上的一个或多个 agent，迁移到 D 盘测试
最终目标不是“自己能迁移”，而是“客户拿到安装包也能装”

这件事看上去简单，实际上有很多坑。

1. 不能直接复制整个 openclaw.json

如果把源环境的 openclaw.json 整个覆盖到目标环境，风险非常大：

可能把目标环境原本能用的配置覆盖坏
可能带入旧字段或不兼容字段
可能影响目标环境里已经存在的其他 agent
多 agent 场景下更容易互相污染

所以正确思路不是“整份替换”，而是精确合并。

我最后收敛成只迁移这些最关键的内容：

agents.list 中目标 agent 的条目
bindings
channels.*.accounts.<agentId>
每个 agent 的 workspace
每个 agent 的 models.json
每个 agent 的 auth-profiles.json（如果有）

这个边界非常重要。也是这个打包 skill 能稳定工作的核心。

二、这个打包 skill 到底解决什么问题

我把它理解成：把“开发机上的 agent”，变成“客户可安装的交付包”。

它做的不是简单压缩，而是完整交付准备：

它负责打包什么

指定 agent 的配置片段
指定 agent 的 workspace
运行所需的模型配置
可选 auth 配置
安装脚本
检查脚本
README
客户设置模板

它不会胡乱打包什么

默认会瘦身，不会把这些无关内容带进去：

sessions
.openclaw
node_modules
缓存
日志
大图片和大产物
其他运行时垃圾

它的交付目标是什么

不是让技术人员“研究一下再手动装”。

而是尽量做到：

客户解压
看 README
跑 CHECK.ps1
跑 INSTALL.ps1
如果 Feishu 首次提示 access not configured
再做一次 pairing 授权
完成

三、我最后定下来的打包原则

这个部分是我觉得最值得分享的，因为决定了整个方案是不是可长期维护。

原则 1：默认瘦身

默认只打包必要内容。不要为了“省事”把整个 workspace 全搬进去。

因为真正交付时，越胖越难维护：

客户拿到包更大
内容更杂
隐私泄漏风险更高
出问题时排查更慢

所以现在默认策略是：

memory 不默认带
只有显式加参数才带 memory

这就把“工作资料”和“记忆沉淀”分开了。

原则 2：memory 可选

有的 agent，记忆很重要。有的 agent，记忆反而是噪音。

所以最终我做成：

默认不打包 memory
想带再加 –include-memory

这样更适合交付。

原则 3：只合并必要字段

不碰未知顶层结构，不迁移老字段，不整份覆盖配置。

只迁移：

agents.list
bindings
channels.*.accounts.<agentId>

这一步极大降低了把目标环境搞坏的风险。

原则 4：单 agent 和多 agent 统一模型

不要做两套逻辑。单 agent 只是多 agent 的特例。

所以最终设计成：

–agents a
–agents a b c

都走同一套打包、安装、合并逻辑。

这让脚本可维护性高很多。

四、打包后到底是什么文件结构

这是客户最关心的部分之一。

一个典型安装包大概长这样：

openclaw-delivery-package/ ├─ README.md ├─ CHECK.ps1 ├─ INSTALL.ps1 ├─ manifest.json ├─ customer-settings.template.json ├─ configs/ │ ├─ openclaw.fragment.json │ ├─ models.sanitized.json │ └─ auth-profiles.sanitized.json └─ workspaces/ ├─ agent-a/ └─ agent-b/

各文件的作用

README.md

给客户看的说明书
告诉客户先做什么、再做什么
也告诉客户 pairing 怎么处理

CHECK.ps1

用来检查安装包结构是否完整
避免客户一开始就拿到损坏包

INSTALL.ps1

自动安装脚本
负责复制 workspace、合并配置、写入 agent 配置

manifest.json

给交付方看的记录文件
记录打包了哪些 agent
带不带 memory
workspace 实际打进了哪些文件
以及 warning

customer-settings.template.json

给客户或实施方改目标路径、模型 key 等
以后也可以扩展成外发脱敏包的核心入口

configs/openclaw.fragment.json

只包含目标 agent 相关的配置片段
不碰整个目标配置

workspaces/<agent-id>/

每个 agent 的工作区内容

五、单 Agent 和多 Agent 的差别，我是怎么处理的

这个 skill 现在既支持单 agent，也支持多 agent。

单 agent

适合：

单个机器人交付
单点迁移测试
先验证流程

例子：

python scripts/build_package.py `
  --source-openclaw "C:Usersme.openclaw" `
  --workspace-root "C:Usersmeclawd" `
  --agents sysmon `
  --output-dir "C:UsersmeDesktop" `
  --package-name "openclaw-delivery-sysmon" `
  --target-openclaw "D:openclawlatestdata.openclaw" `
  --zip

多 agent

适合：

一个客户环境要上多个机器人
多个 agent 一起协同交付
统一安装一次搞定

例子：

python scripts/build_package.py `
  --source-openclaw "C:Usersme.openclaw" `
  --workspace-root "C:Usersmeclawd" `
  --agents intel homework-analyzer `
  --output-dir "C:UsersmeDesktop" `
  --package-name "openclaw-delivery-suite" `
  --target-openclaw "D:openclawlatestdata.openclaw" `
  --zip

多 agent 为什么不能简单“多打几个 zip”

因为客户体验太差：

安装多次
容易乱
容易重复覆盖
合并逻辑更分散

所以我最后定的是：

多 agent 只出一个组合包
客户只装一次

六、真实测试里，我踩过哪些坑

这部分很重要，很多教程都不会讲。

坑 1：迁移成功，不代表机器人能回复

这是最容易误判的地方。

我最开始以为：

agent 写进配置了
Feishu account 也在
binding 也在
那应该就能用了

实际不是。

很多时候机器人不回复，不是迁移失败，而是还没 pairing。

日志里我已经看到：

starting feishu[…]
bot open_id resolved
WebSocket client started

这些都说明 agent 已经加载成功。如果这时飞书端还是提示：

OpenClaw: access not configured.

那通常不是安装失败，而是发消息的用户还没有授权。

坑 2：客户不可能懂 pairing

如果安装包不写清楚，客户会完全懵。

所以安装包里必须明确告诉他：

先给机器人发一条消息
如果返回 access not configured
复制里面的 Pairing code
发给交付方/管理员
由管理员执行：

openclaw pairing approve feishu <PAIRING_CODE>

这个提示必须写在：

README.md
安装完成后的终端输出

否则客户一定会卡住。

坑 3：源配置里有 workspace，但目录可能不存在

这个坑我在多 agent 测试里真实遇到了。

比如：

配置里有 homework-analyzer
但本地 C:Users…clawdhomework-analyzer 目录根本不存在

如果脚本不提示，你会以为“怎么打包丢文件了”。

所以我后来把这个逻辑补上了：

如果 workspace 不存在
不阻塞打包
但在 manifest.json 里写 warnings

这类 warning 对实施特别有价值。

坑 4：重启命令可能执行成功，但命令行会卡住很久

我在真实安装测试里遇到过：

配置已经写入成功
网关也已经开始重启
但安装命令没有及时返回，导致看起来像“超时失败”

所以判断是否成功，不能只看终端有没有立刻退出。还要结合看：

目标配置是否写入
日志里是否出现启动记录

七、我是怎么验证这个 skill 真能用的

我不是只做了代码层面的支持，而是做了真实迁移验证。

单 agent 验证

我实测过：

wechat-curator
content-curator
sysmon

验证内容包括：

包能不能生成
安装脚本能不能跑
目标配置能不能正确合并
日志里 agent 能不能启动
Feishu 能不能走到 pairing 环节
pairing 后能不能继续收发

多 agent 验证

我又做了一次双 agent 迁移：

intel
homework-analyzer

验证结果：

两个 agent 都成功写入 D 盘 OpenClaw
两个 agent 都成功加载
日志中都出现了：

    - starting feishu[...]
    - bot open_id resolved
    - WebSocket client started

这意味着现在它不只是“理论支持多 agent”，而是已经真实跑通过。

八、这个 skill 现在支持什么

目前它已经能做这些事：

单 agent 打包
多 agent 打包
默认瘦身
–include-memory 可选带记忆
自动生成安装包结构
自动生成 README.md
自动生成 CHECK.ps1
自动生成 INSTALL.ps1
自动生成 customer-settings.template.json
自动合并 OpenClaw 目标配置
支持内部迁移
支持后续扩展成外发脱敏包

九、我为什么准备把它开源到 GitHub

因为这不是只适合我自己用的脚本，而是一个很典型的交付问题。

很多人都会遇到：

我本地调好了 agent
怎么交付给别人？
怎么避免客户手工改半天？
怎么把多 agent 一起交付？
怎么处理 Feishu pairing？

这类问题一旦做成标准化方案，就很有复用价值。

所以我准备把这个 skill 放到 GitHub，方便：

直接使用
Fork 修改
提 issue
持续完善

十、如果你也在做 OpenClaw 交付，我建议你先做这三件事

1. 先明确你的交付边界

不要一上来就复制整个环境。先明确哪些是：

必须交付
可选交付
绝对不该交付

2. 先把单 agent 跑通，再扩到多 agent

单 agent 跑通之后，多 agent 本质上就是组合和合并问题。不要反过来。

3. 一定把 pairing 写进客户流程

这一步不是“附加说明”，而是核心流程的一部分。

如果不写，客户一定会把“access not configured”理解成安装失败。

十一、后面我还会继续补什么

接下来我会继续补强这些方向：

更适合外部客户的脱敏包模式
更清晰的 pairing 指引
更完整的 warning 体系
更标准化的 GitHub README
更适合非技术客户的安装手册

结语

如果你也在把 OpenClaw 的 agent 从“自己能跑”推进到“客户能装”，那我非常建议你尽早把交付流程标准化。

因为真正麻烦的，不是 agent 本身，而是：

配置怎么迁
workspace 怎么带
多 agent 怎么合并
Feishu pairing 怎么解释
客户怎么一步步安装

我做这个打包 skill，本质上就是在解决这些问题。

GitHub 地址：

https://github.com/kekohu426/openclaw-agent-packager/

{{userData.name}}已认证