Proma 開源版：桌面 Agent 的專案分區、子會話與記憶機制
Proma brings a seamless general-purpose Agent experience to your workflow. Built for 100× professionals and the proactive Agent era
秒懂
- 它是什麼？
- Proma 是一個以 TypeScript 撰寫的桌面端 Agent 產品，開源版採 AGPL-3.0，主打專案分區、子會話、探索模式與 AGENTS.md 記憶體系。它的核心主張是把上下文組織好，但 README 也明說開源版的迭代節奏已被刻意放慢。
- 適合誰用？
- 如果你本來就是重度 Agent 使用者，而且願意自己管理供應商 API Key、自己維護 AGENTS.md 與專案記憶，Proma 開源版值得下載來試；如果你需要官方託管的模型鏈路、團隊額度分配或組織級 Skills 下發，README 的對照表已經把這些劃給商業版，開源版不會給你。動手前先確認三件事：你的平台是否在 macOS Apple Silicon、macOS Intel、Windows、Ubuntu/Debian x86_64 這份清單內；你能否接受 AGPL-3.0 對網路服務與衍生作品的傳染性；以及你是否讀得懂 docs/linux.md 對 Linux 安全邊界的說明。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Proma 想解決的是上下文被弄髒，不是模型不夠聰明
README 開頭把定位寫得很直白：Proma 是為專業使用者打造的通用的桌面端 Agent 產品。它列出的能力清單很長，Chat 模式、Agent 模式、計劃模式、專案分區、記憶能力、內嵌瀏覽器、內嵌終端、定時任務、Agent 平行探索、子會話與主會話、Skills / MCP / CLI、遠端連結支援微信與飛書與釘釘與 Slack、各種檔案預覽與編輯。
真正決定這個專案性格的不是這份清單，而是它對問題的定義。README 寫道：「對於今天的 Agent 和大語言模型來說，更智能的前提是更好的上下文，我們的核心工作就是帮助你组织更好的上下文。」這句話解釋了為什麼它同時做了專案分區、記憶、子會話、探索模式這幾件看起來不相干的事。它們其實是同一件事的不同切面：把不相關的資訊擋在當前對話之外。
目標使用者因此相當明確。它不是給偶爾問一句就關掉的人用的。README 自己點名的是「Agent 重度使用者」，以及需要處理知識管理、研究、程式開發這類長流程的專業場景。如果你只是想要一個聊天框，Proma 的右側輔助區、專案資料夾、AGENTS.md 這些結構會變成負擔。
專案、會話、會話檔案：三層資料夾就是它的架構
Proma 的資料組織方式可以直接從檔案系統看出來。README 把層級講成三層：專案、專案檔案與會話、會話檔案。專案對應一類工作，專案資料夾放這類工作會反覆用到的檔案，你也可以直接在既有資料夾上建立專案。會話是你每次新建的對話框，一個會話只處理一個具體的小任務，拖進輸入框的東西都會落到會話資料夾下。
這個設計的實際後果是：上下文不是靠對話歷史累積出來的，而是靠你把東西放對位置。README 對此毫不含糊，它說任務本身的分割「仍然是幾天 Agent 使用者的核心工作」。換句話說，Proma 沒有幫你自動切分任務，它只是提供了容器。
記憶也走同一套邏輯。每個專案有自己的 AGENTS.md，用來約束整個專案下 Agent 的行為，涵蓋專案檔案分佈、互動規則、必備資訊與約定。更細的記憶放在 MEMORY.md 作為索引，下面再分出具體類目。Skills 與 MCP 同樣是分專案的。README 給的理由值得注意：過多的 Skills 和 MCP 會導致 Agent 能力下降，按專案區分可以精簡這類上下文，代價是「需要人本身的關注更多」。這是一個誠實的取捨陳述，不是行銷話術。
子會話與探索模式：兩種不同的上下文隔離
子會話與主會話是 Proma 最接近 SubAgent 的機制，但 README 強調差異在上下文乾淨度與可迭代性。它描述的使用方式是：多 Agent 並行處理、深度研究、對抗性分析，以及一種連續模式，主會話負責修復、子會話持續審核。子會話可以有獨立的模型選擇。
探索模式解決的是另一個問題。你在 Agent 輸出結束後點探索，它會利用前序上下文建立多個分叉，你可以並行使用這些分叉。關鍵在收尾：探索右上角有一個帶回主會話的按鈕，讓探索結果回到主線。README 對此的說明是，這樣你就不必擔心「自己拿捏不定的判斷或邊緣的問題影響到主會話的上下文」。
這裡的設計判斷很清楚：分叉本身不稀奇，控制回流才是重點。多數工具讓你分支，然後你得自己決定要不要合併、怎麼合併。Proma 把它做成一個明確的動作，你只在確定要帶回時才帶回。這個機制能不能真的維持主會話乾淨，取決於你會不會克制地使用那個按鈕，README 沒有提供自動判斷。
值得注意的是，這些機制全部依賴模型供應商。開源版的模型渠道要你自己新增與管理 API Key，README 在對照表裡也提醒，使用第三方中轉站時需要自行判斷額外的信任與資料處理風險。子會話與探索模式意味著同時發出多個請求，你的供應商配額與計費方式會直接反映這件事。
安裝：從 Releases 下載，Linux 要先讀 docs/linux.md
README 給的安裝路徑是從 GitHub Releases 下載開源版。它列出的平台與格式為 macOS Apple Silicon、macOS Intel、Windows、Ubuntu/Debian x86_64 的 .deb 安裝包，以及 Linux x86_64 的 AppImage。Linux 的安裝方式、安全邊界與支援範圍，README 指向 docs/linux.md，這是動手前該先讀的一份文件。
開源版與商業版之間有一個 README 明確保證的相容性：開源版使用者可以直接下載商業版覆蓋安裝，資料會被保留和繼承。對照表最後一列也重述了這點，切換後可繼續使用已有的本地 Proma 資料。這表示本地資料的儲存格式在兩版之間是一致的，你不需要先匯出再匯入。
README 沒有提供命令列安裝指令，也沒有列出設定檔的完整鍵值清單。可從文件中確認的具體設定名稱只有幾個：專案層級的 AGENTS.md、作為記憶索引的 MEMORY.md，以及會話資料夾這個概念。其餘的設定項在 README 中沒有展開，需要看應用內實際介面。
輸入框的操作有幾個具體寫法：把左側的上個會話拖進輸入框可以引用，輸入 & 可以引用，輸入 @ 也可以引用檔案。如果檔案已經在當前專案或會話資料夾下，可以從右側直接拖過來。這些是 README 唯一給出的操作細節。
開源版被刻意放慢，這是它最大的限制
README 裡最該被認真對待的一段是關於開源版與商業版的取捨。原文寫道，由於能力和時間有限，「被迫只能選擇降低開源版的功能更新和迭代節奏，更專注開發商業版本」。這不是模糊的措辭，而是對開源版維護投入的直接說明。對照表也把「更新和修復」這一列明確區分成：開源版是必要的更新和修復，商業版是更快的更新節奏。
從 release 記錄看，v0.19.52 於 2026-09-09 發布，前一版 v0.19.37 在 2026-09-08，再前一版 v0.19.31 在 2026-09-05。版號密集，但這只反映發布行為，README 已經聲明開源版的功能迭代節奏被降低，兩者不矛盾：修補與版本號推進可以持續，而新功能優先給商業版。
功能落差集中在幾處。模型渠道方面，開源版要自行新增與管理供應商渠道與 API Key，商業版登入後可用官方內建渠道。聯網與內嵌 AI 能力方面，開源版要自行配置搜尋、生圖服務及對應 API Key，商業版提供 Proma Cloud 的 WebSearch 與 GPT Image 2 生圖與編輯。團隊額度管理、對外 API 與服務、Skills 的組織級分發與協作，這三項在對照表中都只列在商業版。
這裡有一個容易誤讀的地方：Skills 本身開源版有支援，README 也說內嵌了一些必要的 Skills 並支援常見 MCP 與 CLI 的一鍵安裝。但「團隊內分發與共享需自行組織」，組織級的下發、版本統一管理、免安裝直接使用，這些屬於企業版。個人用與團隊用，在這一項上是兩條路。
AGPL-3.0 對桌面 Agent 意味著什麼
Proma 開源版採 AGPL-3.0。這是所有 GNU 授權中對網路服務最嚴格的一種，它的核心條款是：如果你修改了程式並以網路服務的形式讓他人使用，你必須向這些使用者提供對應的完整原始碼。
對個人使用者與內部自用團隊來說，這條款通常不構成障礙，你執行未修改的軟體，義務極少。真正需要停下來想的是兩種情況。第一種是你把 Proma 包進自己的產品或服務對外提供，這會牽動衍生作品與網路服務條款的判斷。第二種是你想基於 Proma 的程式碼做閉源商業化。兩者都需要看完整授權文本並諮詢律師，這裡不做法律建議。
README 提到商業版可直接覆蓋安裝開源版且保留資料，但沒有說明商業版的授權條款是什麼。如果你打算從開源版切到商業版，授權條件會改變，這是切換前該自己確認的事項，不能從 README 推斷。
另外要注意，Proma 是桌面應用而非伺服器軟體，AGPL 的網路服務條款在桌面情境下如何適用，取決於你怎麼部署與分發。這不是一個可以靠直覺回答的問題。
對照替代方案：Chat 客戶端與 CLI Agent 的取捨
Proma 的位置可以跟兩類工具對照。第一類是桌面 Chat 客戶端，例如各家模型廠商自己的桌面應用。這類工具通常只提供對話，沒有專案資料夾、沒有 AGENTS.md、沒有內嵌終端與瀏覽器。Proma 的差異在於它把檔案系統當成上下文的一部分，Agent 可以操作專案檔案，改動會以輪次顯示，程式場景會展示 Diff。
第二類是終端裡的 CLI Agent。CLI Agent 的優勢是可組合、可腳本化、容易進 CI，它天生貼近 shell。Proma 走的是相反方向：它把終端和瀏覽器內嵌進圖形介面，讓 Agent 直接登入並使用一個可見的終端與瀏覽器。README 舉的用途是瀏覽器自動化、補充聯網搜尋的不足，以及在自動化敏感的網站上做研究與資訊對照。
差異的實際後果是：CLI Agent 的除錯靠日誌與重跑，Proma 的除錯靠看。你能看到 Agent 在瀏覽器裡做了什麼、在終端裡敲了什麼。代價是它綁在桌面環境與圖形介面上，README 也沒有提到任何無頭或伺服器端執行模式。
還有一個 Proma 特有的東西是 CLI Agent 沒有的：worktree 工作流。README 說在當前會話右側，Agent 會主動選擇對應的 worktree，直接查看基於 main 的 diff，點一次就能進入 Proma 可見終端。這是把 git worktree 與 Agent 會話綁在一起的設計，CLI 工具要靠你自己接。
誰該用、誰不該用，以及先驗證什麼
Proma 開源版適合的對象是：已經在用 Agent 處理長流程工作、願意自己配置模型供應商與 API Key、並且接受要親手維護 AGENTS.md 與專案記憶的人。如果你做的是研究、知識管理或程式開發，而且痛點在於對話越長越亂，它提供的專案分區與子會話機制正好對應這個問題。
不適合的對象同樣清楚。想要開箱即用模型、不想碰 API Key 的人，README 把這條路劃給商業版。需要在團隊內統一分發 Skills、需要管理成員額度的人，對照表列的是企業版。只想偶爾問答的人，專案與會話的分層會變成純粹的摩擦。
動手前該驗證的具體事項有三個。第一，你的平台在不在 README 列出的清單內，Linux 使用者請先讀 docs/linux.md 對安全邊界與支援範圍的說明，這份文件的存在本身就暗示 Linux 的支援有前提。第二，AGPL-3.0 是否與你的使用方式相容，尤其是對外提供服務或做閉源衍生的情況。第三，開源版的更新節奏已被官方聲明放慢，如果你需要的是持續跟進的新功能，先看 release 記錄的實際內容再決定，不要只看版號密度。
最後一點關於維護成本：Proma 的上下文品質取決於你投入多少整理工作。AGENTS.md 要自己寫，記憶要自己沉澱，Skills 與 MCP 要按專案切分。README 建議的做法是帶著 Agent 走一次你真實的處理流程，讓它沉澱成 Skill，再透過實際使用迭代。這是一條需要時間的路，不是下載完就結束的事。
編輯結論
如果你本來就是重度 Agent 使用者，而且願意自己管理供應商 API Key、自己維護 AGENTS.md 與專案記憶，Proma 開源版值得下載來試；如果你需要官方託管的模型鏈路、團隊額度分配或組織級 Skills 下發，README 的對照表已經把這些劃給商業版，開源版不會給你。動手前先確認三件事：你的平台是否在 macOS Apple Silicon、macOS Intel、Windows、Ubuntu/Debian x86_64 這份清單內；你能否接受 AGPL-3.0 對網路服務與衍生作品的傳染性；以及你是否讀得懂 docs/linux.md 對 Linux 安全邊界的說明。
社群筆記