ZHangZHengEric/Sage 是什麼？

Sage 把 Plan、Simple、Fibre、Self-Check 等代理、視覺化 Workbench、四種 IM 通道與三種沙箱打包成一套可部署系統。判斷重點不在功能清單，而在 Minimal 與 Full 兩種堆疊、SAgents v2 的 Python 3.12 門檻，以及未做 Apple 公證的桌面版發佈流程。

ZHangZHengEric/Sage 可以商用嗎？

可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。

ZHangZHengEric/Sage 還在維護嗎？

有在維護。儲存庫最近一次提交在 1 天前。

ZHangZHengEric/Sage 是用什麼程式語言寫的？

主要是 Python（依據 GitHub 的語言統計）。

Sage 多代理系統框架評測：架構、部署與限制

秒懂

它是什麼？: Sage 把 Plan、Simple、Fibre、Self-Check 等代理、視覺化 Workbench、四種 IM 通道與三種沙箱打包成一套可部署系統。判斷重點不在功能清單，而在 Minimal 與 Full 兩種堆疊、SAgents v2 的 Python 3.12 門檻，以及未做 Apple 公證的桌面版發佈流程。
適合誰用？: 需要把多代理任務跑成可交付流程、且願意自行維護 Python 與 Node 環境的團隊，可以從 Minimal（SQLite）堆疊與 sage doctor 開始驗證；只要一個 CLI 或單一代理迴圈就能解決問題的場景，Sage 的產品層與 IM 通道反而是負擔。動手前先確認三件事：你的 Python 版本是否達到 SAgents v2 與 Desktop v2 要求的 3.12、macOS 上能否接受未公證安裝與 xattr 手動解除隔離、以及你打算接的 IM 通道（iLink、WeCom、Feishu、DingTalk）是否真的需要。
可以商用嗎？: 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
還在維護嗎？: 有在維護。儲存庫最近一次提交在 1 天前。
用什麼語言寫的？: 主要是 Python（依據 GitHub 的語言統計）。

以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。

開源專案深度解析

Hysen Labs 編輯部 · 2026年9月10日 · ZHangZHengEric/Sage

Sage 想解決的不是「叫 LLM 回答」，而是把複雜任務跑完

多數代理框架停在「給模型一個工具迴圈」這一層。Sage 的 README 把定位寫成「a production-ready agent platform for task execution, automation, browser workflows, IM delivery, and enterprise deployment」，關鍵字是 platform 而不是 library。它假設使用者要的是一條從規劃到交付的鏈路：內建 planning、execution、self-check、memory recall 與 tool suggestion 幾類代理，任務進來之後由這些角色分工，而不是單一 agent 反覆試錯。

目標讀者因此分成兩類。一類是已經在用 LangChain 或自寫迴圈、但發現長任務缺乏檢查點與交付物的工程團隊；另一類是需要把代理接進企業內部溝通管道（WeCom、Feishu、DingTalk）並要求檔案傳遞的整合方。文件另外提到問卷驅動的收集流程與排程任務，這說明它在意的是「反覆發生、有人要看進度」的工作，而不是一次性問答。

這裡有個取捨要先講明：功能面鋪得越廣，採用時要驗證的介面就越多。Sage 同時提供桌面、Web、CLI、Chrome extension 與 IM 五種入口，對維運是實打實的負擔，README 本身沒有提供任何跨入口一致性保證的說明。

AgentFlow 是骨幹：Session Runtime 如何把代理串起來

README 的架構圖把資料流畫得相當清楚。所有入口（Desktop、Web、CLI、Chrome extension、IM Channels）先收斂到 App Service Layer，再往上分岔成 Chat & Sessions、Agent Management、Tasks & Automations、Browser Bridge 與 Visual Workbench 五個產品模組。往下則進入 SAgents Core，由 Session Runtime 承接，再交給 AgentFlow 調度 Plan、Simple、Fibre、Self-Check 等代理。

這個分層的意義在於：產品層與核心層之間有明確邊界，入口的增減不應該改動 AgentFlow 的邏輯。對想替換前端或自建 IM 橋接的人來說，這是有用的切割。但要注意，架構圖是 README 提供的示意，並非模組介面的規格書；圖上沒有標示 Session Runtime 與 AgentFlow 之間的呼叫協定、狀態存放位置或失敗重試策略，這些得回到 docs/ 目錄與原始碼確認。

工具層則是另一條線。文件寫「Combine built-in tools, Skills, MCP servers, browser automation, search, and image generation in one execution stack」，也就是 MCP 伺服器與內建 Skills 共用同一個執行堆疊。好處是擴充路徑單一；代價是任何一個 MCP server 的行為異常，都會落在同一條執行鏈上，而 README 未描述工具層的隔離或逾時機制。

Minimal 與 Full 兩種堆疊，第一次啟動就要選邊

從原始碼啟動 Web 版的指令很短：

git clone https://github.com/ZHangZHengEric/Sage.git cd Sage ./scripts/dev-up.sh

啟動後開 http://localhost:5173，登入後先到 Model Source Management 加入模型供應商，再建立或設定 Agent。README 特別提醒首次執行會詢問 Minimal（SQLite）或 Full 堆疊，並建議 Minimal 最快。這個選擇不是純粹的安裝偏好，它決定了你之後要維運幾個服務元件。

dev-up.sh 接受兩個環境變數：PYTHON_BIN 與 USE_UV。前者讓你指定自訂的 Python 執行檔，後者切換到 uv 管理依賴。對於已經用 uv 或 pyenv 管理環境的團隊，這兩個旋鈕省掉改寫腳本的功夫。

CLI 路徑則是完全不同的安裝方式，走 pip install -e . 之後用環境變數設定模型：

export SAGE_DEFAULT_LLM_API_KEY="your-api-key" export SAGE_DEFAULT_LLM_API_BASE_URL="https://api.deepseek.com/v1" export SAGE_DEFAULT_LLM_MODEL_NAME="deepseek-chat" export SAGE_DB_TYPE="file" sage doctor sage run "Say hello briefly."

注意 SAGE_DB_TYPE 在 CLI 被設為 file，而 Web 首次執行問的是 SQLite 或 Full。兩條路徑的儲存後端敘述並不一致，README 沒有解釋 file 與 SQLite 選項之間的關係，這是採用前值得先跑 sage doctor 釐清的地方。TUI 沿用同一組 SAGE_DEFAULT_* 與 SAGE_DB_TYPE=file，再執行 sage-terminal。

桌面版的真實成本：未公證、隔離標記與 Python 3.12

桌面版從 GitHub Releases 下載 .dmg、.exe NSIS 安裝檔或 .deb。macOS 的流程揭露了一個常被忽略的維運現實：README 明確寫「The build is not currently Apple-notarized」。使用者第一次開啟要右鍵 Sage.app 選「打開」，若仍被封鎖，得到系統設定的隱私與安全性頁面點「仍要打開」。若系統回報應用程式已損毀，官方給的解法是：

xattr -dr com.apple.quarantine /Applications/Sage.app

這是每次重新安裝都可能重複發生的步驟，對要批次派發給非技術同仁的團隊來說，是必須寫進內部安裝說明的內容。Windows 端同樣有 SmartScreen 的未知發行者警告，需點「更多資訊」再「仍要執行」。

版本門檻也要注意。README 的徽章標示 Python 3.10+，但同一份文件在 Quick Start 段落寫明「SAgents v2 and Desktop v2 require Python 3.12+」。這不是細節差異：從原始碼建置 Desktop v2 或使用 SAgents v2 時，3.10 或 3.11 環境會直接卡住。文件沒有列出各版本對應的 Python 需求矩陣，升級前得自行核對 release notes。

Linux 端相對單純，sudo apt install ./Sage-<version>-<arch>.deb 即可，多數桌面環境也能直接雙擊安裝。

沙箱三選一，但 README 沒告訴你何時該選哪個

Sage 提供 local、passthrough 與 remote 三種沙箱選項，用於代理執行期的隔離。這是整個專案裡最需要自行判斷、而文件著墨最少的一塊。README 只列出三種模式存在，沒有說明各自的隔離強度、啟動成本、支援的平台，或哪一種適合搭配瀏覽器自動化。

從命名可以推測：passthrough 應該是不做隔離、直接在主機環境執行，適合開發期除錯；local 大概是本機層級的隔離；remote 則把執行搬到遠端環境。但這些都是從名稱推得的合理猜測，不是文件陳述。如果你的使用情境涉及讓代理執行產生的程式碼或操作瀏覽器，這個選擇直接關係到風險邊界，應該以原始碼與 docs 目錄的說明為準，而不是靠命名推斷。

同樣缺乏細節的還有 Chrome extension：README 只說從 app/chrome-extension/ 以開發者模式載入未封裝擴充功能，若後端埠號與預設不同要自行指向。沒有提到權限宣告、與 Browser Bridge 的關係，或擴充功能是否需要與桌面版同時運行。要接瀏覽器工作流的人，這部分得先讀 docs/en/applications/CHROME_EXTENSION.md。

和 LangGraph 的差別：流程圖框架還是產品外殼

把 Sage 和 LangGraph 放在一起比，差異不在功能多寡，而在抽象層的位置。LangGraph 是流程圖執行時，你定義節點與邊，狀態怎麼流、檢查點放哪裡、要不要人為中斷，全部由你決定。它不附帶 UI，也不管你的代理要從哪裡被觸發。

Sage 反過來：AgentFlow 與 Plan、Self-Check 等代理是既定的，你調整的是 Agent 設定、工具與 Skills，產品層已經備好 Chat、Workbench、Tasks 與 IM 通道。選擇成本因此不同。用 LangGraph，前期要自己搭觸發介面與狀態檢視，但流程完全透明；用 Sage，第一天就有可用的工作台與排程，但要接受它的代理分工方式，改動核心流程的成本比改一張圖高。

如果你的需求是「把一個既有 Python 服務加上代理能力」，LangGraph 這種可嵌入的執行時通常更貼合。如果你的需求是「給團隊一個能看進度、能從 Feishu 收指令、能排程跑問卷的介面」，Sage 省下的正是這層產品外殼的工。兩者不是替代關係，重疊區在代理調度，分岔點在你要不要自己養前端與通道整合。

維護節奏與 MIT 授權的實際含義

從 release 記錄看，desktop-v1.1.8、desktop-v1.1.7、desktop-v1.1.6 三個版本集中在 2026 年 5 月 26 日同一天發布，間隔分別約 13 分鐘與 33 分鐘。這說明桌面版的發佈流程偏向密集修補，而非按季度規劃的穩定節奏；實際升級時要有心理準備，版本號跳動可能對應的是小範圍修正。專案最後推送時間為 2026 年 9 月 9 日，預設分支 main，未封存。

授權是 MIT，這對商業採用相對寬鬆：可修改、可再散布、可閉源整合，條件是保留著作權與授權聲明。這裡不構成法律意見，實際條文以 LICENSE 檔案為準。要注意的是 Sage 會串接外部模型供應商（README 範例用 DeepSeek 端點）、MCP 伺服器與 IM 平台，這些第三方元件的授權與資料處理條款各自獨立，MIT 只涵蓋 Sage 本身。

升級成本主要落在兩處：一是 Python 版本門檻（SAgents v2 與 Desktop v2 要 3.12+），二是資料庫後端的切換（Minimal 的 SQLite 與 CLI 的 file 模式）。README 沒有提供遷移指南或版本相容性矩陣，這意味著跨版本升級前，得先確認你的 SAGE_DB_TYPE 設定與既有資料的相容性。

編輯結論

需要把多代理任務跑成可交付流程、且願意自行維護 Python 與 Node 環境的團隊，可以從 Minimal（SQLite）堆疊與 sage doctor 開始驗證；只要一個 CLI 或單一代理迴圈就能解決問題的場景，Sage 的產品層與 IM 通道反而是負擔。動手前先確認三件事：你的 Python 版本是否達到 SAgents v2 與 Desktop v2 要求的 3.12、macOS 上能否接受未公證安裝與 xattr 手動解除隔離、以及你打算接的 IM 通道（iLink、WeCom、Feishu、DingTalk）是否真的需要。這些條件對不上，就別急著 clone。

官方來源

社群筆記