最近在做一件很有意思的事情，把原本跑在 AWS 雲端電腦上的 OpenClaw，整個搬到本地端的 Jetson Orin Nano 上。一開始以為這只是個工程問題，後來才發現，其實更像是一個「組織交接」的問題，而且過程真的很像人在換工作。

目前 OpenClaw 已經變成我日常系統裡很核心的一個角色，它負責控管 LINE Business 帳號、管理 Google Calendar、操作 Google Sheets、協助租客報修流程、與師傅約時間，以及每天整理待辦事項。基本上，它已經是我租屋管理流程中的一個成員。一直放在 AWS 上其實沒有問題，但長期下來還是有幾個考量：成本會累積、網路依賴比較高，以及我自己也很想測試「本地 AI 長期運作」的穩定性。所以就決定，把整個系統搬到 Jetson Orin Nano 上。某種程度上，這也象徵一件事：AI 不再只是工具，而是開始變成一種常駐型基礎設施。

一開始我走的是最直覺的方式，就是整個系統 image 打包，然後在新的機器上還原。理論上很合理，舊機器有什麼，新機器就複製過去。但現實很快就打臉，問題非常多。主要原因其實也很單純，AWS 上跑的是 x86 架構，而 Jetson 是 ARM 架構。這就像你把一個人的大腦，直接塞進另一個身體，理論上是同一個人，但實際上很多地方會出錯。遇到的狀況包括部分套件無法執行、驅動不相容、系統服務無法正常啟動，還有一堆看似正常但其實壞掉的小細節。整體來說，能跑的部分不少，但不能跑的部分更麻煩，而且很難完全排查。

中間我也試過另一條路，透過 Nvidia 的 sandbox 思路，先建立一個比較受控的環境，再嘗試把原系統還原進去。這條路其實很有企業感，安全性很高，很多通道都是預設鎖住的。從架構上來說其實很漂亮，也很適合大型團隊使用。不過對我現在這種快速迭代、個人實驗型系統來說，有一個很現實的問題，就是設定成本太高。每一條通道都要開、每一個權限都要設定，如果是在企業內部這是很合理的，但在個人環境裡，時間成本會變得非常大，所以這條路也暫時先放下。

真正讓事情順利完成的，其實是一個很簡單的想法：不要搬整個系統，而是搬「知識」。這個念頭其實來自一個很直覺的觀察，每台機器其實就像每個人，每個人背景不同、能力不同、環境不同，你不可能直接複製一個人到另一個人身上。真正可行的方式，其實是寫交接文件。

我後來做的事情，其實很像公司交接流程。首先請原本在 AWS 上的 Agent，生成一份完整的交接文件，把系統架構、服務啟動順序、依賴關係、API 設定、憑證與權限說明、日常運作流程，以及已知問題和注意事項全部整理出來。這一步其實非常關鍵，因為你是在把原本存在系統裡的隱性知識，轉成可以理解與傳遞的顯性知識。

接著，在 Jetson 上建立一個全新的 Agent，而不是複製舊的。環境乾淨，結構清楚，也沒有歷史包袱。然後讓新的 Agent 依照交接文件，一步一步把系統重新建立起來。這個過程非常像新人接手工作，不是直接繼承，而是逐步理解，再逐步建立能力。當整個流程最後順利跑起來的時候，其實有一個很強烈的感覺，這不像是在搬一台機器，比較像是兩個人完成了一次完整的交接。舊的 Agent 負責整理經驗與文件，新 Agent 依照文件建立能力並完成接手，那一刻真的很像把一個角色成功交給另一個人。

這次最大的體悟，其實不是技術本身，而是觀念的轉變。以前在做系統時，我們很習慣用「複製」的方式來解決問題，Clone、Restore、Backup，但在 AI Agent 時代，我開始覺得更重要的不是複製，而是培養。你培養一個 Agent，讓它學會做事情，當環境改變時，不是把它整個搬過去，而是讓另一個 Agent 透過交接，學會同樣的能力。這其實非常接近人類組織運作的方式。

這次成功之後，我也開始在想，能不能把這整套流程標準化。未來如果有多台 Jetson、多個 Agent、多個任務角色，是不是可以像公司一樣，有交接模板、有知識文件、有角色說明，讓 Agent 可以快速上線、快速接手、快速替換。如果這件事成熟，那未來系統擴展的方式，可能會完全改變。

整個移機過程，最大的感受不是技術突破，而是一個觀念上的轉變：AI 開始不像工具，而比較像組織成員。它有角色、有責任、有交接、有流程。當你用這種方式看待 AI，很多事情會變得更自然，而整個系統也會變得越來越穩定。

一起看看我的AI Agent 架設的網頁和電子報
DL AGENT | 生活系統設計室