letta-ai/letta 仓库已转型为项目入口，V1 服务器源码进入归档分支
Platform for stateful agents: AI with advanced memory that can learn and self-improve over time.
秒懂
- 它是什么？
- letta-ai/letta 不再承载主要代码，当前源码迁移至 letta-ai/letta-code。本文梳理仓库现状、安装路径与历史包袱，帮助工程师判断该从哪里获取真正的状态型 agent 运行时。
- 适合谁用？
- 如果你正在评估 Letta 作为状态型 agent 平台，应当直接转向 letta-ai/letta-code 仓库，而不是在本仓库中寻找可运行的服务器代码。本仓库只提供入口链接和归档历史，适合需要复现 V1 行为的旧用户，但归档分支明确标注为不受支持、无安全更新，不应部署到生产。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- GitHub 没有给出这个仓库的主要语言。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个仓库，两种身份：从 MemGPT 到 Letta 的入口页
letta-ai/letta 的 README 第一句话就点明了它的现状：这个仓库现在只是 Letta 项目的 landing page。真正的源码已经搬到 letta-ai/letta-code，包括 agent harness、交互式终端 UI、App Server、渠道适配层，以及桌面和 Web 应用共用的运行时。仓库本身保留了 Apache-2.0 许可证，默认分支是 main，但最近一次推送是 2026 年 9 月，说明它仍在维护，只是维护内容变成了文档和链接。对工程师来说，最直接的教训是：不要从这个仓库克隆代码来跑服务，它已经不具备完整的运行时结构。
V1 服务器的归档分支：能看不能用
README 明确警告，archive 分支保存的是已退役的 Letta V1 API 服务器源码，仅作历史参考。该分支不受支持，不接收任何修复或安全更新，也不应被用于生产环境。这个分支的价值在于可复现性：如果你曾经依赖 V1 的某个行为，可以通过既有 tags 和 releases 找回当时的代码。但如果你是新用户，看到 archive 分支里的 Python 服务端代码可能会误以为这是当前架构，实际上 letta-code 已经用 TypeScript 重写了运行时。这种仓库拆分方式在活跃项目中不少见，但 letta 的处理相对清晰，至少把警告写在了 README 的开头。
安装路径：npm 包与终端 UI
当前推荐的安装方式是通过 npm 全局安装 @letta-ai/letta-code。命令是 npm install -g @letta-ai/letta-code，然后直接运行 letta 启动交互式终端 UI。如果要跑本地或自托管的 agent 服务，执行 letta server。这两个命令覆盖了两种典型用法：个人调试和本地服务部署。注意，npm 包名带了 @letta-ai 作用域，与仓库名 letta-ai/letta 并不一致，搜索时容易混淆。文档还提到桌面应用支持 macOS、Windows 和 Linux，浏览器端可以通过 chat.letta.com 使用，包括移动端。这些入口共享同一个运行时，意味着记忆和 agent 状态可以在不同设备间同步，但前提是你使用 Letta Cloud 或自建服务器。
渠道与 SDK：不止是聊天框
Letta 不只是终端工具，它提供了 Slack、Telegram、Discord 以及自定义渠道的接入方式。这意味着你可以把同一个带记忆的 agent 挂到多个消息平台上，而不必为每个平台单独写状态管理。Letta Agent SDK 则面向 TypeScript 应用，允许你把 agent 嵌入到自己的产品逻辑中。这里有一个权衡：渠道适配层增加了部署复杂度，你需要为每个渠道配置 token 和回调地址，但换来的是统一的内存模型。如果你只需要一个内部工具，终端 UI 可能已经足够；如果你要做跨平台客服机器人，渠道支持就是核心卖点。
记忆机制在哪里？本仓库没有答案
Letta 的核心卖点是 stateful agents，即 agent 拥有可以跨会话保留的记忆，并能随时间学习。但本仓库的 README 只给了概念描述，没有深入机制。要理解记忆是如何写入、检索和更新的，必须去 letta-code 仓库或文档查看。从项目历史看，Letta 前身是 MemGPT，这个名称暗示了其设计思路：像操作系统管理内存一样管理大模型的上下文。但具体实现是采用分层存储、向量检索还是摘要压缩，本仓库没有提供任何代码或架构图。如果你要评估记忆机制的可靠性，只能去 letta-code 的源码中寻找答案。这是本仓库作为 landing page 的天然局限，它无法替代技术文档。
许可证与维护成本：Apache-2.0 下的双仓库风险
整个项目采用 Apache-2.0 许可证，这对商业使用相对友好，不要求开源衍生作品。但维护成本体现在仓库分裂上：letta-ai/letta 负责导航，letta-ai/letta-code 负责代码，而 letta-ai/letta 的 releases 仍然挂在旧仓库上，最新版本是 0.16.8，发布于 2026 年 5 月。如果你依赖这些 release 标签来追踪版本，需要意识到这些标签对应的是归档前的 V1 代码，而不是 letta-code 的版本号。升级时你可能会混淆两个版本线。实际维护动作应该围绕 letta-code 进行，本仓库的 issue 和 PR 可能已经不再处理代码问题。建议在采用前确认 letta-code 的活跃度和发布节奏。
替代方案与适用边界
如果你要的是带记忆的 agent 平台，直接使用 chat.letta.com 或桌面应用是最省事的路径，不需要自己管理服务器。如果你需要完全掌控数据，可以自托管 letta server，但要准备好处理 Node.js 环境和渠道配置。另一个方向是放弃 Lettra 的托管记忆层，改用 LangChain 或 LlamaIndex 这类框架自行实现记忆，这样你能控制记忆的存储方式和检索逻辑，但需要自己写更多胶水代码。Letta 的差异在于它把记忆作为一等公民，而不是事后添加的工具。对于原型验证，npm 包足够；对于生产环境，你需要评估 letta-code 的稳定性和社区支持，本仓库的 README 没有提供这些数据。
编辑结论
如果你正在评估 Letta 作为状态型 agent 平台，应当直接转向 letta-ai/letta-code 仓库，而不是在本仓库中寻找可运行的服务器代码。本仓库只提供入口链接和归档历史，适合需要复现 V1 行为的旧用户，但归档分支明确标注为不受支持、无安全更新，不应部署到生产。在采用前，先核对 letta-code 的 README 与文档，确认当前版本 0.16.x 的 API 是否与你的集成方式兼容，并验证 Slack、Telegram 等渠道的配置是否满足你的消息路由需求。若你只是需要一个带记忆的对话 agent，Letta 的桌面应用或 chat.letta.com 可能比自建服务器更省事；若你需要深度定制记忆机制，则要评估 letta-code 的 Agent SDK 是否暴露了足够的控制点。最终判断：letta-ai/letta 是一个指向真实项目的路标，而不是项目本身。
社区笔记