近日為了方便管理多個 AI Agent（Claude/Codex）的 Skills 共用機制，原本是想乾脆自己來開發一個，但秉持著盡量不要重新造輪子，所以先從 GitHub 上查找（關鍵字：Skill Manager），還真找到許多同類型的專案。
然後又再關聯到先前我也下載過對岸一個 Claude Code 多帳號／多供應商切換的開源工具專案 - cc-switch，我發現這些專案執行後的管理設置界面並非是採透過瀏覽器開啟的 Web 頁面，也不是傳統原生桌面應用程式。而是看起來綜合了兩者的特性，卻又可以跨平台的 "類桌面應用的 Web 界面"，還挺有意思的。
再進而查看他們程式碼所使用的應用框架，都不約而同使用了 tauri 2.0 框架，我直覺以為這應該算是前端框架吧？，但卻又不是；那麼該歸屬為後端框架吧？但又不盡然。透過 AI 調研，結果給我一堆技術行話，卻仍是定位不清。
乾脆自己也來動手寫一個相關練手用的專案吧，就近了解近期這些相關的應用技術吧（React/Typescript + Tauri + Rust Core）。我想就以跨平台的桌面寵物來作為應用案例，順便把我的小狗堡貝放進 Windows 桌面上，時不時讓牠走動、餵食、安撫等，也是挺有趣的。
我在使用任何程式語言、任何技術框架開發專案前，首先要決定的就是分層架構的設計議題。Ract/TypeScript 是前端，這沒有問題，Rust Core 是後端這也沒問題，就是 Tauri 應該定位在哪一層呢？查看相關文件以及透過 AI 討論，還真的都說不出所以然！
與 AI 對話討論，可以看成它是一位技術實作能力超群的「技術宅」，但較為抽象的概念層次，往往會夾雜著底層的實作機制來說明。所以我就禁止讓它從技術的角度（例如它會用 IPC, command handler 來解釋 tauri）解釋，而是只從巨觀的角度來說明。總算比較明確定位了 tauri 的分層關係。最基本的巨觀分層概念：
Frontend <-> Bridge <-> Backend
Frontend 可以是 React / TypeScript，負責使用者看見與操作的介面；
Backend 則是 Rust Core，負責核心邏輯、資料處理與本機作業系統能力整合。
至於 Tauri 2 ，它其實就是中間那層 Bridge，它不是傳統 Web 架構裡的 API Controller 或 Gateway 角色，而是 WebView Frontend 與 Rust Backend 之間的本機連接與能力邊界。
把 Tauri 2 的概念分層簡化為：
- 前端：使用者看見與操作
- 橋接層：通訊、邊界與控制
- 後端：邏輯、系統存取與資料處理
一句話來說：
- What：Tauri 2 是一個以 WebView 承載前端介面、以 Rust Core 整合本機能力，並透過 Bridge 連接兩者的跨平台桌面應用框架。
- Why：Tauri 2 讓 Web 前端能以輕量、安全、受控的方式，橋接至本機桌面能力。
可參考官網文件： https://v2.tauri.app/start/
確實釐清並界定好了分層框架後，程式碼的組織相對就會井然有序且簡潔很多了。若以概念目錄樹來表達，大致可以看成：
tauri-app/
├─ frontend/ # Frontend：WebView 介面層
│ └─ React / TypeScript
│
├─ bridge/ # Bridge：Tauri 2 橋接層
│ └─ IPC / Commands / Events / Capabilities
│
└─ backend/ # Backend：Rust Core 後端層
│ └─ Logic / System Access / Data除了桌寵這個小案例，後續這樣的架構也可以延伸應用在如跨平台系統管理介面、AI 工具控制台，甚至 Trading Dashboard 這類需要整合本機能力的桌面應用。也就是說，Tauri 2 真正值得理解的，不只是它能把 Web UI 包成桌面程式，而是它提供了一個清楚的 Bridge，讓前端介面與本機系統能力之間維持可控、可測試、可擴充的分層邊界。