企业官网建设流程全解析

你或许也有这样的困扰：平时办公电脑上的 Agent 已经被你调得很顺，Codex 知道该加载哪些 Skill、遵守哪些规则，常用的 MCP 工具也已经连好。可一回家换了台电脑，或者想改用 Claude Code、DeepSeek Harness（DSH）试试，原来顺手的那一套突然全没了。

于是你又得重新安装 Skill、复制规则、连接 MCP，再把每个 Agent 的设置逐项调一遍。有人会直接复制旧电脑上的整个配置目录，结果登录信息、聊天记录和只适用于旧电脑的路径也跟着过来了。同一份配置在 Codex、Claude Code 和 DSH 里的写法也不同：复制过去后，有些内容不会生效，还有些会盖掉新电脑上已经调好的设置。

其实你真正想带走的，是这套熟悉的 Agent 工作方式：让同一批 Skill 能被发现，让同一组规则继续生效，让同样的 MCP 工具可以重新连接。

这正是我做 SkillFerry 的原因：

复现你的 Agent 能力，让你长期积累的 Skill 与 MCP 连接能够跨平台、跨 Agent 复用。

标准开放了，安装这最后一公里没人管

Agent Skills 让一套做事方法可以按共同格式保存，MCP 则让不同 Agent 用相近的方式连接外部工具。基础已经有了，按理说，在 Codex、Claude Code、DSH 之间复用能力，或者把它们带到一台新电脑上，应该轻松很多。

共享格式解决了内容怎么保存，部署仍由各个 Agent 自己决定。Codex、Claude Code 和 DSH 放置 Skill、读取规则和连接 MCP 的方式各不相同。同一份 Skill 到了另一个 Agent，可能可以直接使用，也可能需要转换、损失一部分效果，甚至只能手工重做。macOS、Windows、Linux 的路径和命令差异又增加了一层工作。

公开讨论里已经能看到这类经历。MCP 社区把"客户端配置怎么存"单列为待解决的标准问题（MCP IG #2761）；Claude Code 和 Codex 的 issue 里，也有用户报告"换机器后 Skills 没跟过来"（Claude Code #36693、Codex #26691）。这些记录只能证明有人遇到过问题，无法说明需求规模或优先级排名。

要把这件事做稳，需要先回答四个问题：跨工具、跨机器，哪一份内容是事实源？哪些内容可以自动转换，转换时会不会丢失含义？哪些数据必须留在本机？应用变更时怎样保护本机已有的设置？

一份 workspace，所有 Agent 都只是渲染目标

SkillFerry 把 Skills、全局规则和不含秘密的 MCP 模板放进同一个 workspace，也就是一份可以审查并提交到 Git 的工作目录。你只在这里维护一次内容；执行计划时，SkillFerry 再按 Codex、Claude Code 或 DSH 各自需要的格式生成配置。因此三种 Agent 都是接收结果的“渲染目标”，workspace 保存那份共同的事实源。

举个例子。workspace 里有一个release-checklistSkill、一份全局发布规则、一个 GitHub MCP 模板。Token 不写进 workspace，模板里只有secret:env/GITHUB_PERSONAL_ACCESS_TOKEN这样的引用。跑一下plan，它逐项告诉你三个目标会得到什么：

SKILL release-checklist codex native claude native dsh native MCP github codex translated secret resolved from local env claude translated secret resolved from local env dsh translated inserted as dsh-mcp-client entries

这串等级说明转换后会发生什么。native会按目标原生格式安装，含义完整保留；translated会转换成目标格式，上面三个 MCP 就属于这一类；degraded可以使用，但存在已知损失；manual只提供操作步骤；unsupported表示目标端没有对应能力。每个等级都要有能力证据支撑，不能只标一句"兼容"。

换电脑和换工具，到这里其实是同一件事：Skill 只维护一份，换台新电脑，拉下来装好就行；想换个 Agent 试试，也还是这一份，只是按对方的格式装。

四条边界，决定了它敢承诺什么

让能力随你走，把状态留在本机。Skill、规则、MCP Server 定义描述了可复现的工作方式；Token、登录态、会话、缓存和自动记忆属于身份或运行时状态。SkillFerry 只管理前一类中被明确声明的内容，也不会把整个~/.codex或~/.claude当作同步单元。它的范围不包括 dotfiles 同步、Provider 切换和 Agent 编排。

文件放到位后，还要确认功能怎样加载。目标目录里出现一个文件，只能证明写入完成；目标 Agent 是否按相同含义读取它，还要看实际能力。当前版本能把 stdio MCP 生成三种目标所需的配置；HTTP/SSE MCP 会标为manual，插件和扩展则只记录期望状态，需要用户自行安装。plan会在写入前把这些人工步骤列出来。

同步能力时，把秘密留在本机。workspace 的数据规则会拒绝 MCP 环境中的字面秘密，只接受secret:env/...或secret:file/...引用。真实值到apply时才在本机解析，不会写进 JSON 报告，也不会被skillferry export <destination>展开到可分享副本中。操作系统仍负责保护本机文件；SkillFerry 负责避免把秘密误当成可分享的能力定义。

尊重你手工改过的内容。SkillFerry 用所有权账本记录自己上次写入的路径和哈希。目标文件后来发生变化，下次plan或apply会报告冲突（exit 3）并停止覆盖。你可以显式选择adopt、overwrite或keep-local；应用前会创建备份，一组多文件写入失败时则回滚已经完成的部分。

import → plan → apply → doctor

主流程四步，每一步都让你先看清楚再动手：

• import从现有的 Codex 或 Claude Code 环境提取可移植资产，敏感值自动转成引用；
• plan展示每个目标的路径、等级、来源和冲突，不写任何文件；
• apply只写自己声明管理的路径；
• doctor用退出码 0/1/2/3 区分"已同步 / 出错 / 可安全处理的漂移 / 需要人决策的冲突"。

跑完一轮，你就能说清楚：带走了什么，在哪个目标被转换，哪些值还留在本机，应用之后还有没有漂移。

想试试的话

SkillFerry 发布在 PyPI，要求 Python 3.11 或更高：

pipxinstallskillferry skillferry init my-workspacecdmy-workspace skillferry plan skillferry apply skillferry doctor

如果你已经有 Codex 环境，也可以从import --from codex开始，再审查生成的 workspace；从老项目 codex-profile-sync 迁移则有migrate --from codex-profile-sync。仓库还带了一个可直接运行的 starter workspace 和两个种子 Skill，可以先在隔离目录里看看三个目标的渲染结果，再决定要不要落地。

适合谁，以及它明确不做的事

如果只用一个 Agent、一台电脑，也还没攒下自己的 Skills 和规则，手工维护可能更简单。

SkillFerry 更适合这些场景：

• 你在 Codex、Claude Code、DSH 之间切换；
• 你想让同一套能力覆盖 macOS、Windows、Linux；
• 你已经把 Skills 和规则当成需要版本管理的工程资产；
• 你希望应用前能预览，语义有损失时必须明说；
• 你想用 Git 管理可分享的定义，但不想把凭据和运行时状态一起提交。

它不做 GUI、SSH 远程目标、团队层、会话或记忆同步、Provider 管理，也不承诺任意插件无损转换。macOS 和 Windows 各有独立的原生验收记录；Windows 那台机器上没有装 Claude Code，只验证了它生成的配置形状，没真正启动进程。CI 是另一道自动化门禁，不算原生验收。完整边界见可移植性契约、能力证据矩阵和文档与验收记录。

让工作方式跟着你走

开放格式让内容可以复用，真正部署时仍要处理目录、配置格式、操作系统、秘密引用和本机修改。SkillFerry 会在执行前列出这些差异，让你看到每个目标能得到什么、哪里有损失、哪些步骤还要手工完成。

如果你也在重复安装 Skills、重写规则、给同一个 MCP 维护好几份配置，可以先跑一次隔离的import → plan：看看哪些能力能原生带走，哪些需要转换，哪些本来就该留在本机。

项目地址：GreenLv/skillferry
最新发布：GitHub Releases
安装入口：PyPI