AI 的辦公桌可以折起來帶走：Pi-Work 想把 Agent 的工作環境變成可搬運的包裹

11月5日，獨立開發者 pphboy 在 V2EX 分享了自己side project Pi-Work。他過去主要做 NAS 與 Linux 基礎設施開發，這次想解決的問題很具體：AI 已經能寫程式、執行命令、呼叫工具，但這些能力大多綁在宿主機的環境上。換一臺電腦，就得重裝依賴、重配工具。Pi-Work 的做法是用 QEMU MicroVM 給 AI 一個獨立的工作環境，而且可以把整個環境匯出成 .work 檔案，帶到別臺機器繼續用。

它實際做了什麼

用一個日常比喻：現在多數 AI Agent 像是住在你家客廳的訪客，用你的桌子和你的抽屜，客人一換地方就兩手空空。Pi-Work 想給 AI 一間自己的小套房，裡面的工具、檔案、做一半的工作都留在原地，而且這間房可以整間打包，搬到別棟大樓原樣復原。

技術底層是 QEMU MicroVM，圍繞 KVM / WHPX 等虛擬化能力構建。作者選 MicroVM 的理由，是在環境隔離、執行效率和可遷移性之間取平衡。目前主要面向 x86-64 環境，之後考慮支援 macOS 與 Apple Silicon。產品提供 GUI 與一鍵安裝，目標是讓不懂 Docker 和 Linux 的使用者也能用自然語言驅動 AI 完成實際工作。

網友的第一個質疑：跟 Docker 打包差在哪

分享帖下面最早出現的提問，正好打在定位的關鍵上。網友 hadesy 直問：這跟把開發環境打包成 Docker 鏡像加 skill 的分發方式有什麼區別？Docker 不同鏡像還能複用檔案層，Pi-Work 是否在重造輪子。

作者的回覆提供了一個分辨角度：Docker 鏡像像是「食譜的分發」，拿到鏡像的人得到的是一套初始狀態；Pi-Work 強調的是「可持續迭代的工作空間」。他的設想是，使用者先在裡面搭好一套 AI Native 工作流，一鍵匯出，另一個使用者匯入後不需要任何設定，就能在這個已經運轉過的環境上繼續客製化。差別在於分發的單位：一個是環境的藍圖，一個是環境連同其工作狀態本身。

這個區分是否足以支撐一個獨立產品，仍待真實使用情境驗證。目前專案只完成核心 MVP，作者自己也說 UI、相容性和體驗都還有許多要補的地方，選擇公開構建、讓使用者回饋推動迭代。

放進既有的工具版圖看

Pi-Work 並非孤立現象。遠端存取與環境可攜這幾個月持續有開發者投入，例如開源專案微子 Neutrino 就把遠端 AI 會話、VS Code 與終端整進一套中樞，想解決「到處都要重灌環境」的痛點。兩者取的路徑不同：Neutrino 偏向把分散的遠端工作收攏，Pi-Work 則把力氣放在環境的隔離與搬運。但指向同一個訊號：當 AI Agent 的產出不再是幾行文字，而是一整個跑起來的工作現場，「環境本身」開始變成需要被管理的資產。

這也呼應 Agent 落地後反覆出現的教訓：問題往往不在模型多聰明，而在它拿到的權限與環境邊界怎麼設計。MicroVM 的隔離性在這裡多了一層安全意涵，AI 執行命令的破壞半徑被框在虛擬機裡。

所以呢

對一般使用者，Pi-Work 目前還在早期，值得觀察而非立刻押注。對獨立開發者與小團隊，它提出的問題值得先想清楚：如果 AI 的工作環境可以像檔案一樣寄給別人，你會寄什麼？是搭好的資料處理流程、爬蟲任務，還是某個客戶專屬的自動化現場？作者在文末徵求的正是這類使用情境回饋。

至於 Docker 重造輪子的質疑，答案不在技術辯論裡，而在有沒有人真的用 .work 檔案交換過一次工作流，而且對方開箱就能用。這一步發生了，Pi-Work 的定位才算站住。

（事件日期：2026年11月5日，V2EX 分享創造板）