letta-ai/letta 已轉為入口頁：想用 Letta 的人該裝哪一個套件
Platform for stateful agents: AI with advanced memory that can learn and self-improve over time.
秒懂
- 它是什麼？
- 這個倉庫現在只是 landing page，真正在維護的程式碼位於 letta-ai/letta-code；本文說明它的記憶機制、npm 安裝路徑、archive 分支的意義，以及什麼情況下你根本不該選它。
- 適合誰用？
- 如果你要的是跨工作階段保留記憶、可自架的 agent 執行環境，先確認你要裝的是 @letta-ai/letta-code，而不是把 letta-ai/letta 這個倉庫 clone 下來當伺服器跑。只想在 TypeScript 專案裡嵌入 agent 邏輯、不想維運伺服器的人，應該先評估 Letta Agent SDK 是否已足夠。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 5 天前。
- 用什麼語言寫的？
- GitHub 沒有提供這個儲存庫的主要語言。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
這個倉庫現在只是入口，不是你要 clone 的程式
打開 letta-ai/letta，第一件該注意的事不是功能，而是它已經不再是主體。README 寫得很直接：目前的原始碼位於 letta-ai/letta-code，內容包含 agent harness、互動式終端介面、App Server、channels，以及桌面與網頁應用所使用的 runtime。這個倉庫現在的角色是 landing page。
對要評估是否導入的人來說，這代表兩件事。第一，任何以 letta-ai/letta 為對象的安裝教學都可能過期，因為真正的安裝路徑已經寫在另一個倉庫。第二，如果你在搜尋引擎或套件索引裡看到這個倉庫，請把它當成路標，而不是程式來源。
它解決的問題本身沒有變：讓 agent 具備跨對話的狀態與記憶，而不是每次呼叫都從空白開始。README 的描述是 build stateful agents with memory that can learn and improve over time。誰需要它？需要 agent 記住使用者偏好、長期任務脈絡，或需要把同一個 agent 身分帶到不同前端（終端、桌面、瀏覽器、通訊軟體）的人。如果你只是要一次性問答，這個專案的複雜度對你是負擔。
記憶與身分是怎麼被撐起來的：harness、App Server、channels 三層
從 README 能確認的架構資訊有限，但足以畫出輪廓。letta-ai/letta-code 包含 agent harness、App Server、channels 與 runtime。這幾個名詞的分工，決定了它的資料流方向。
harness 是 agent 的執行外殼，負責把模型輸出轉成動作、把動作結果寫回狀態。runtime 是桌面與網頁應用共用的底層。App Server 則是本機或自架部署時的服務端，讓 agent 不綁在某一個前端上。channels 是對外接口，README 點名 Slack、Telegram、Discord 與自訂通道。
把這三層放在一起看，就能理解為什麼 Letta 強調 stateful：對話不是發生在某個應用裡，而是發生在伺服器端的 agent 上，前端只是接入點。Letta Cloud 的角色是讓 agent 的記憶、身分與對話在不同電腦之間保持可用，README 對它的描述就是這個意思。至於 harness 內部如何決定何時寫入記憶、記憶以什麼結構儲存，README 沒有交代，這部分必須看 letta-code 的文件才能確認，我不會在這裡替它補上。
安裝與啟動：三條指令，以及它們各自對應的場景
README 給的安裝方式是 npm：
npm install -g @letta-ai/letta-code
裝完之後，互動式終端介面用：
letta
要在本機或自架環境跑 agent，改用：
letta server
這兩條指令的差別值得講清楚。letta 是給人用的終端 UI，適合先摸清楚 agent 行為。letta server 才是你要放進部署流程的東西，因為它對應的是 App Server，前端可以換成桌面應用、瀏覽器或通訊通道。
README 另外列出幾種使用途徑：macOS、Windows、Linux 的桌面應用；瀏覽器上的 chat.letta.com，含行動裝置；Slack、Telegram、Discord 與自訂 channels；以及用於把 agent 建進 TypeScript 應用的 Letta Agent SDK。這些都是入口，不是替代的安裝方式。
要注意的是，這個倉庫本身沒有提供安裝指令。如果你照著舊教學在 letta-ai/letta 裡找安裝步驟，會找不到對應的內容。
archive 分支：可以重現，但不該上線
README 對 archive 分支的說明是整份文件裡語氣最強的一段。它保存的是已退役的 Letta V1 API server，在倉庫被歸檔時的樣子。既有 tag 與 release 仍然可用，用途是重現性。
接下來是關鍵句：那份原始碼不受支援，不會收到修正或安全性更新，且不應在生產環境使用。這不是模糊的免責聲明，而是明確的使用邊界。
對維運的人來說，這代表一條硬線。如果你的系統已經跑在 V1 server 上，你面對的不是升級選項，而是遷移問題。archive 分支能幫你的是把舊行為拉回來對照，不是讓你繼續跑下去。
授權方面，這個倉庫標示為 Apache-2.0。README 沒有提到 archive 分支或 letta-code 是否有不同的授權條款，這點在把它放進商業產品前應該自行確認，我不會替它推論。Apache-2.0 通常涉及專利授權與再散布條件，但那屬於法律判斷，請找專業意見。
版本節奏與升級成本：三個月一輪的維護負擔
從 release 記錄看，0.16.6 在 2026-03-04、0.16.7 在 2026-03-31、0.16.8 在 2026-05-14。三個版本集中在三個月內，節奏不算慢。最後一次 push 是 2026-09-08。
版本號停在 0.16.x，表示它還沒有進入 1.0。對採用者來說，這意味著 API 與行為在次要版本之間仍可能調整。README 沒有提供升級指南或破壞性變更清單，所以升級前該做的是讀 release notes，而不是假設相容。
這裡有一個容易混淆的點：這個倉庫的 release 與 letta-code 的 release 是兩套東西。如果你裝的是 @letta-ai/letta-code，你要追的是那個套件的版本，不是這裡列出的 0.16.x。把兩者混為一談，會讓你在排查問題時看錯地方。
維護成本的實際來源不是程式碼本身，而是 harness、App Server、channels 這三層的組合。你接的通道越多，升級時要回歸測試的面就越大。只跑終端 UI 的人，負擔遠低於同時接 Slack 與自訂 channel 的團隊。
什麼時候不該選它：與 LangGraph 的取捨
Letta 的定位是把狀態與記憶放在伺服器端的 agent 上，前端只是接入點。LangGraph 走的是另一條路：它把 agent 定義成圖，狀態在圖的節點之間流動，由你的應用程式持有。
差別在於誰負責記住。用 Letta，記憶與身分由執行環境管理，好處是同一個 agent 可以同時出現在終端、桌面與 Slack，不需要你為每個前端重寫狀態邏輯。代價是你多了一個要維運的服務，而且 agent 的行為有一部分不在你的程式碼裡。
用 LangGraph，狀態的邊界由你決定，除錯時可以沿著圖走。代價是跨前端的記憶、身分延續要自己實作，這正是 Letta 想幫你省掉的工作。
所以判斷點很簡單：如果你需要的是「一個 agent 在多個介面之間保持同一個身分」，Letta 的架構對得上。如果你需要的是「在既有應用裡精確控制每一步狀態轉移」，LangGraph 這類把控制權留在應用端的做法更合適。兩者不是同一層的替代品，硬要比高下沒有意義。
另外一種不該選的情況：你只需要單次問答，或你的 agent 不需要跨工作階段記憶。這種需求下，引入 App Server 與 channels 只是多一層要顧的東西。
編輯結論
如果你要的是跨工作階段保留記憶、可自架的 agent 執行環境，先確認你要裝的是 @letta-ai/letta-code，而不是把 letta-ai/letta 這個倉庫 clone 下來當伺服器跑。只想在 TypeScript 專案裡嵌入 agent 邏輯、不想維運伺服器的人，應該先評估 Letta Agent SDK 是否已足夠。無論走哪條路，動手前先確認三件事：npm 上的 @letta-ai/letta-code 版本與 README 描述是否一致；archive 分支是否真的只在你需要重現舊行為時才碰；以及你打算依賴的通道（Slack、Telegram、Discord 或自訂 channel）是否已經在你預期的部署環境裡被文件涵蓋。
社群筆記