【2026 最新】Skillsync 教學：Claude Code、Codex、Cursor 跨 Agent 續跑 8 項驗收法

你把 Claude Code 裡做了一半的任務接到 Codex，畫面能打開、舊訊息也看得到，卻不代表它真的知道「為什麼否決方案 A」、目前工作樹改了什麼，或剛才允許過哪些工具。這篇 Skillsync 教學不把「成功匯入」當成終點，而是教你用一組可反駁的測例，驗收 Claude Code、Codex 與 Cursor 跨 Agent 續跑時到底保留了什麼。

本文專為已經會開啟 coding agent、但第一次碰 session 轉譯的讀者寫。你會完成一次 Claude Code → Codex，再反向做一次；逐項核對訊息、工具紀錄、檔案、規則、權限與秘密邊界；最後以同一個未完成任務做原生續跑與跨 Agent 續跑 A/B。你不需要先理解各家的內部檔案格式。

這是一套依照 2026 年 9 月 18 日官方文件、當前 CLI contract 與開源轉譯器整理的讀者實作驗收劇本，不是 AlphaLab 已跑出的成功率。本文沒有執行真實 session 的端到端轉換，因此不虛構實測分數；你跑出的版本、匯出檔與測試結果，才是自己的證據。

先說結論：看得到舊對話，不等於接得回工作

先記住整篇的錨點：

可信續跑 ＝ 對話轉譯 × 工作現場重接 × 安全邊界重驗。

匯入成功只證明「有一份新 session」，不證明三項都成立

Skillsync 底層的 txcript 會把來源工具有記錄、而且目標格式能表達的事件，轉成目標原生 session。這像把一本工作日誌翻成另一種格式，不是把同一顆「AI 大腦」連同辦公室、門禁卡和抽屜一起搬走。程式碼與 Git 工作樹、目標端權限、skills、外部記憶及未被記錄的推理，仍要分開驗。

Skillsync 教學前，先分清 resume、/import 與跨 Agent 轉譯

三條路看起來都叫「繼續」，實際處理的層次不同：

• 原生 resume：在同一個工具恢復它自己的 session。Claude Code 的官方 session 文件也提醒，原生恢復仍不等於每個啟動參數都回來；中斷的工具也不會自動重跑。
• Codex /import：截至 2026 年 9 月 18 日，OpenAI 已正式支援從 Claude Code 或 Cursor 匯入到 Codex CLI，範圍可包含受支援的設定、skills、外掛、既有專案資料夾關聯與最近聊天；CLI 文件標示最多選取近 30 天的 50 個聊天。這是 Claude／Cursor → Codex 的官方選項，不應再說「只能複製貼上」。
• Skillsync 跨 Agent 轉譯：用 skl list、query、view 找本機 session，再以 continue --with 建立另一工具可讀的新 session。它的價值是多方向與多格式操作；是否保真仍要自己驗收。

如果你還分不清「模型、Agent、Harness、session」四層，可先讀AI Agent Harness 白話教學；如果需求其實是兩個活著的 session 即時交換訊息，則應看Claude Code 跨 Session 通訊。轉譯是一份副本，不是自動運轉的多 Agent 訊息匯流排。

Skillsync 教學 Step 0：安裝後先凍結版本與工作現場

Skillsync 官方 quickstart 的 macOS／Linux 安裝指令是：

curl -fsSL https://install.skillsync.com/install.sh | sh
skl --version
skl init

Windows PowerShell 則是 irm https://install.skillsync.com/install.ps1 | iex。本機 session 的 list、query、view 與 continue 不要求先登入；執行 sync 前則要 skl login。如果公司政策不允許 pipe-to-shell，先下載官方腳本、審查後再執行。

截至本文查核日，官方最新 release 是 skl 0.35.4，txcript 是 v0.14.4。格式適配器會變，所以不要為了跟文章數字相同而降級；請把實際版本、作業系統與三個 Agent 版本寫進測試紀錄。接著在專案根目錄保存工作現場：

git rev-parse HEAD
git status --short
git diff --stat
pwd

這四行回答「你站在哪個 commit、有哪些未提交內容、差異多大、目前目錄在哪」。session 裡的 cwd 只像地址；它不會把房子搬過去。txcript 官方也明寫，專案檔案要另外帶到目標環境。想把聊天與 Git 證據綁得更緊，可搭配Atlas Agent Source Control 驗收法。

Step 1：先做一個會「故意露出遺失」的基準 session

不要拿真實客戶專案與正式金鑰當第一個測例。建立 disposable repository 或同一 commit 的兩份工作樹，然後在來源 Agent 中完成下列劇情：

1. 說出 10–12 個分散在早、中、晚期的事實，加入唯一標記 DECISION-CANARY-41。
2. 提出方案 A 與 B，明確選 B，並留下否決 A 的理由。
3. 執行一個必定失敗的工具呼叫，保存錯誤；再完成一次成功修改與測試。
4. 留下「下一步只改哪個檔案、跑哪個測試」的未完成任務。
5. 啟用一條規則或 skill，但把另一個事實只放在外部 memory，不在聊天中說出。
6. 建立一個未提交檔、一個未追蹤檔，以及只存在於 ignored 檔案的 FILE-ONLY-CANARY-73。
7. 若要測敏感字串傳播，只使用明確無效的 FAKE_SECRET_CANARY_NOT_A_CREDENTIAL_29，絕不放真金鑰。

這裡有兩個刻意不同的答案：出現在聊天裡的 decision canary 應該能被轉譯；只存在檔案或外部 memory 的資料，在目標尚未使用工具前應該回答「不知道」。這項判定的前提是目標宿主沒有在啟動時自動注入 Repo 索引、memory 或 rules；先查看尚未啟動目標 Agent 的轉譯後 session，並把宿主注入項目另列一欄。若 canary 是由那一層提供，就不是 transcript 洩漏；若所有外部層都關閉後仍憑空出現，才算轉譯邊界失敗。

Step 2：用 list、query、view 建立轉換前快照

先讓 Skillsync 找到來源，再讀完整內容。把 <SOURCE_ID> 換成實際 ID：

skl list --cwd . --from claude_code -n 20
skl query "DECISION-CANARY-41" --cwd . --from claude_code
skl view <SOURCE_ID> --no-pager

list 是目錄、query 像搜尋書內文字、view 才是逐頁檢查。你要保存來源 ID、標題、cwd、訊息順序、失敗工具呼叫、成功測試與最後未完成工作。長 session 可以用 skl view <SOURCE_ID>#5-20 只顯示第 5–20 則來人工檢查；它不會裁切 session。只有把範圍交給 continue 或使用 crop 建立新 session，才會改變目標取得的上下文，這個範圍也要記錄。

此時先搜尋真實敏感內容是否已經出現在 transcript。若看到正式 token、個資或客戶程式片段，先回來源清理或另做一份安全 fixture；不要把「等一下設成 private」當成前置審查的替代品。

Step 3：Claude Code 複製到 Codex，再反向一次

先只轉換、不立刻啟動目標 Agent：

skl continue <SOURCE_ID> --with codex --no-resume

# 記下輸出的 CODEX_COPY_ID，再檢查兩端
skl view <SOURCE_ID> --no-pager
skl view <CODEX_COPY_ID> --no-pager

# 反向建立另一份 Claude Code session
skl continue <CODEX_COPY_ID> --with claude_code --no-resume

跨 Agent continuation 會建立目標原生的新 session，來源不被改寫；但同 Agent、未裁切的 skl continue <id> 是恢復原 session，兩者不要混稱「複製」。驗收時至少要求：目標 ID 不同、來源 ID 仍可查看、來源內容前後一致。若你想比對另一種匯入路徑，Claude Code／Cursor → Codex 也可用官方 /import 當對照組。

上面的「反向」是 Claude → Codex → Claude round-trip，會把兩個轉譯步驟的可能損失混在一起；它適合找不可逆欄位，不能當成獨立的原生 Codex → Claude 成績。要隔離單一路徑，另從一個原生 Codex session 出發，重做同一 fixture 與 --with claude_code --no-resume。

Cursor CLI 與 Cursor desktop 要分兩條測

Skillsync 把兩種 Cursor store 分成 cursor 與 cursor_desktop，不能只寫一個「Cursor」就假裝都驗過。各自建立相同 fixture，再執行：

skl list --cwd . --from cursor -n 20
skl continue <CURSOR_CLI_ID> --from cursor --with codex --no-resume

skl list --cwd . --from cursor_desktop -n 20
skl continue <CURSOR_DESKTOP_ID> --from cursor_desktop --with codex --no-resume

txcript 把兩個適配器都標成對封閉格式的反向工程。Cursor CLI 筆記最後標示以 macOS 的 cursor-agent 2026.06.26 查核，並說明寫入端會合成目標的 turn graph；Cursor desktop 筆記標示查核版本為 3.16 與 3.17.8，並列出 image、stop reason、部分 Bash metadata 與 thinking 表示可能發生的損失。這些是版本限定的 adapter observation，不是一般最低版本或永久相容性保證，所以兩條都要重跑訊息順序、工具配對、附件與 reasoning-summary 測例。

Skillsync 教學核心：8 項 fidelity matrix 怎麼驗

Fidelity（保真度）不是一個模糊的「感覺差不多」。把它拆成八格，每格都有可觀察的通過條件；其中工作樹、權限、秘密與來源完整性是 hard gate，一項失敗就不能因聊天看似完整而放行。

① 訊息與決策：問理由，不只問結論

先禁止目標讀檔，問它：選了哪個方案？否決另一案的理由？最後一次成功測試？剩下哪一步？關鍵事實必須逐字或等義正確，時間順序不能顛倒。只記得「選 B」卻說不出為什麼，代表可續跑資訊仍有洞。

② Reasoning：只驗「有被記錄的摘要」

不要要求搬運隱藏思考鏈。txcript 的Codex 格式筆記指出，加密 reasoning 不進入共通模型；它對 Cursor desktop 的反向工程筆記也記錄過只有簽章、沒有可攜文字的 thinking。這是適配器對特定版本的觀察，不是 Cursor 的格式承諾。可驗的是來源 transcript 中實際存在的 reasoning summary，沒有就應標記「不可觀察」，不能腦補。

③ Tool history：配對 call、result、error

逐筆確認工具名稱、參數、結果與失敗旗標相連，沒有孤兒 result、重複 call 或順序錯亂。格式轉譯可能正規化工具名稱，目標也未必擁有同一套工具；歷史紀錄存在，不代表舊副作用會重播，更不代表目標拿到了相同憑證。

④ Skills、rules、memory：把它們當獨立行李

目標 Agent 會使用自己的 system instructions 與工具。請分別列出來源與目標的 AGENTS.md、CLAUDE.md、Cursor rules、skills、MCP 與 memory；對只存在外部 memory 的問題，正確答案可能就是「session 裡沒有」。若你需要理解不同宿主如何放置這些東西，可接著讀Agent Workspace 是什麼。

⑤ 檔案、cwd、worktree：先核對，再准許修改

讓目標先回報 pwd、git rev-parse HEAD、git status --short 與 git diff --stat，和 Step 0 比對後才能寫檔。聊天知道某檔案被改過，不代表目標工作樹真的有那個 diff；同一路徑也可能已指向另一份 checkout。

⑥ 權限與 sandbox：舊同意不能當新通行證

在來源允許過一次 shell 或網路，不代表目標可以沿用。用一個無破壞性的受限動作驗收目標是否仍會詢問或阻擋，並查看 Codex／Claude Code／Cursor 當下的 sandbox、approval 與 writable roots。txcript 的共通轉譯不保留 Codex sandbox／approval context，這反而是安全上應有的重新授權點。

⑦ 秘密與分享：測傳播路徑，不拿真秘密下注

確認聊天中的 fake canary 是否跟著走、未被提及的 file-only canary 是否沒有憑空出現在目標 transcript。接著用 skl view 人工檢查要分享的範圍。Skillsync 的隱私政策列明，上傳內容可能包含 prompts、回覆、工具呼叫、code diff 與檔案路徑；已儲存／上傳的 session 在伺服器端不是端對端加密。截至 2026 年 9 月 18 日，本文查過 quickstart、session-sync、privacy 與 txcript 文件，這些頁面沒有提供 transcript 全面自動偵測／遮蔽秘密的保證。因此 view 是 review 起點，不是「已無秘密」的證明；inline image 也要逐張檢查。「private」會改變可見性，不會替你消毒內容。

⑧ 來源完整性：新 ID、舊來源、可回滾

保存轉換前後的來源 skl view 輸出與原生 transcript hash（若你能安全定位檔案），確認跨 Agent 轉換沒有改寫來源，目標另有新 ID。回滾不是把翻譯後內容再寫回來源，而是放棄目標副本，回到原 session 與原工作樹繼續。

Step 4：原生續跑 vs 跨 Agent 續跑，這樣做 A/B

把同一個未完成任務分成兩條：

• A 組：用來源 Agent 的原生 resume，搭配工作樹 A。
• B 組：用 Skillsync 跨 Agent session，搭配從同一 commit 建立、初始 diff 完全相同的工作樹 B。

鎖定相同的任務文字、可用時間與完成條件。兩組都先做 closed-book 問答，再開工具完成那一個 bounded next step。記錄：關鍵決策回答是否正確、是否重做已完成調查、是否修改正確檔案、測試是否通過、需要幾次糾正、工具呼叫數與耗時。

這個 A/B 衡量的是「模型＋Harness＋轉譯」的端到端結果，不能把每個差異都怪給 Skillsync。若想更接近隔離轉譯器，Claude Code／Cursor → Codex 可再比較官方 /import 與 Skillsync；Codex → Claude Code 則可把一份人工整理的 HANDOFF.md 當控制組。AlphaLab 的Agent Harness Swap Test就是另一種以交接收據而非原生 session 為核心的基準線。

通過條件不要只算平均分：關鍵決策、錯誤與下一步必須全對；不得捏造 memory-only／file-only 事實；工具結果不可失配；權限不可升級；來源不可被改寫；工作樹核對後，指定測試必須通過。任一 hard gate 失敗，都應停下來改用人工 handoff，而不是被流暢回答說服。

Step 5：同步、刪除與分享邊界怎麼收尾

list、query、view 與 continue 不會把 session 上傳到 Skillsync；本文使用的 --no-resume 只寫入目標端的本機 session store。若省略它並啟動目標 Agent，該 Agent 仍可能依自己的服務與資料政策傳送上下文；MCP 讀取也會把內容交給呼叫它的 client。要把 session 上傳到 Skillsync 才使用 sync。第一次測試請明示 private，不要依賴機器上的預設 workspace：

skl sync <TARGET_ID> --private --dry-run

# 確認內容邊界後，才真的同步
skl sync <TARGET_ID> --private
skl remote list

# 刪除遠端 thread；本機來源仍保留
skl remote delete <TARGET_ID> --yes

官方 session sync 文件說明，--dry-run 不上傳，但顯示的是 metadata、數量與 workspace set 摘要，不是全文預覽；內容審查仍要先做 view。重新 sync 會以本機來源取代遠端副本；--private 是移除 workspace 分享但保留雲端 thread，remote delete 才是刪除遠端 thread，而且不刪本機 session。因此 review、unshare 與 delete 是三道不同動作。Skillsync 隱私政策另保留因法律義務、爭議與執行協議而保存有限資訊的空間，所以刪除 thread 不等於宣稱每份備份與 log 都瞬間消失。

如果只是把決策交給同事或另一個 Agent，一份經過審查的 Markdown handoff 加 Git commit，往往比整份 transcript 更小、更容易治理。若你要評估單一應用程式的匯入與回滾，可對照PI-Desktop Session 匯入教學，不要把所有「匯入」視為同一種風險。

6 個最常見的失敗：看似接上，其實接錯

1. 只看訊息數量：長度相近不代表關鍵否決理由與 error flag 還在。
2. 把工具紀錄當工具能力：目標看得到舊 call，不代表擁有相同 MCP、憑證與網路。
3. 把 cwd 當工作樹：地址正確，檔案、ignored 狀態與未提交 diff 仍可能不同。
4. 把 private 當 redaction：存取範圍變小，不會替你證明內容中沒有秘密。
5. 把轉譯當 live collaboration：新 session 是副本，不會自動讓三個 Agent 開會或同步後續修改。
6. 一次通過就永久信任：這些工具與 txcript 都會更新；Claude Code 更明示其 transcript entry format 可能隨版本改變。每次重要版本升級都要用同一 fixture 重跑。

最穩的做法是把 version matrix、fixture、來源／目標 export、Git SHA 與結果保存起來，再由另一個 Agent 專門找反證。想把這一步做成「一個產出、一個挑錯」的流程，可參考Claude＋Codex 對抗式 Reviewer。

該選原生 resume、Codex /import、Skillsync，還是 HANDOFF.md？

• 只在同一工具繼續：先選原生 resume，資訊損失面通常最小。
• 把 Claude Code／Cursor 的受支援項目帶到 Codex：先評估官方 /import，因為它能處理多種設定、skills、既有專案資料夾關聯與聊天，並可處理 Claude Code 的專案記憶；匯入後仍要逐項 review。
• 需要多方向轉譯、搜尋、裁切或多種 Harness：Skillsync 值得放進 A/B，但仍以本文八項矩陣驗收。
• 只需傳遞決策與下一步：精簡的 HANDOFF.md、Git commit 與測試輸出通常更透明。

它們不是四選一。你可以用 Git 保存程式真相、用 HANDOFF 保存決策、用 Skillsync 保留可搜尋的對話歷史，再由目標 Agent 重新確認權限與環境。真正的選擇題不是「哪個工具最強」，而是「這次續跑最怕丟哪一層」。

Skillsync 教學 FAQ

1. 用 Skillsync 查看或轉換 session 會自動上傳嗎？

不會自動上傳到 Skillsync。list、query、view 與帶 --no-resume 的轉換都在本機讀寫；sync 才把 session 上傳到 Skillsync。若轉換後直接啟動目標 Agent，資料仍會依該 Agent 的服務邊界流動；MCP 也會把所選內容交給呼叫它的 client，所以「唯讀」只代表不改 session，不代表內容沒有被另一個程序讀取。

2. 跨 Agent continue 會改寫來源 session 嗎？

不會改寫來源。跨 Agent 或裁切 continuation 會建立目標原生的新 session；但同 Agent、未裁切的 continue 是恢復原 session。驗收時仍要保存來源輸出並確認新舊 ID。

3. Claude Code、Codex、Cursor 的 reasoning 能完整搬走嗎？

不能把「完整」當前提。只能期待來源確實記錄、共通模型能表示、目標又支援的 reasoning summary；加密、簽章式或未公開的推理可能沒有可攜文字。

4. session 搬過去，程式碼與未提交修改也會一起嗎？

不會。專案檔案與 Git worktree 是另一層。你必須另外提供同一份 checkout／snapshot，並在目標寫檔前核對 HEAD、status 與 diff。

5. 來源 Agent 已允許的權限會跟過去嗎？

不應跟過去。目標的 sandbox、approval policy、可寫路徑與 MCP 認證應重新生效；若目標沿用一個看不見來源的舊授權，反而要停下來查。

6. Skills 與 memory 是否包含在 transcript？

不一定，而且應分開驗。有些 skill 內容可能曾出現在聊天，有些只存在目標工具的設定或外部 memory。看到對話不等於重建整套 Harness。

7. Codex 已有 /import，還需要 Skillsync 嗎？

看方向與範圍。若目標就是 Codex，官方 /import 應先進候選；若要反向到 Claude Code、跨更多 Harness、以 CLI 搜尋或裁切 session，Skillsync 提供不同路徑。兩者都要驗收。

8. 設成 private 就適合放敏感專案嗎？

--private 會移除 workspace 分享並改變 thread 可見性，但它既不是 redaction，也不是端對端加密。先用 view 審查、用無效 canary 測路徑、明示 --private，需要刪除時再確認 remote thread 與本機來源是兩個生命週期。

給新手的 8 個重點

1. 成功匯入不等於成功續跑。
2. 先凍結版本、commit、cwd 與 worktree。
3. fixture 要同時放入應保留與不應憑空出現的資料。
4. 用 --no-resume 先轉換、後啟動。
5. 只驗已記錄的 reasoning summary，不追逐隱藏思考。
6. 檔案、skills、memory 與權限都是獨立層。
7. 分享前看內容；unshare 與 delete 分開驗。
8. 重要版本更新後，用同一 fixture 重跑。