技术媒体 MarkTechPost 近期发布了一份基于 Letta 构建工程副驾的实践教程，通过展示核心内存块、跨智能体状态共享、向量归档检索以及环境导出，描绘了一个能够长期记住项目进展、规约与事故复盘的智能伙伴。然而，这场面向企业开发者的技术布道掩盖了一个关键断层：教程所依赖的核心组件在官方演进路线中已被归入退役区间，开发者若照单全收，不仅无法获得稳定的持久化副驾，反而在第一步就背上了过时的技术债务。

教程里的理想副驾，跑在官方已退役的旧架构上

加州大学伯克利分校提出 MemGPT 之初，将大语言模型的上下文窗口类比为操作系统的内存分层，这一直是自主状态管理最具吸引力的叙事。教程展示的核心能力看似完备：智能体拥有自主读写的核心内存，可以通过共享块与代码审查员协同，甚至能打包成一个 .af 文件在不同环境中无缝迁移。

但在 Letta 官方的实际演化路径中，这套基于内存块（Core Memory Blocks）与归档内存的体系，已被官方文档明确标记为 V1 SDK (legacy)。更关键的底层变化在于，开源社区所熟悉的 letta-ai/letta 代码仓库已被标记退役，官方主推的架构已全面转向具备版本控制能力的内存文件系统 MemFS。

Code
<svg viewBox='0 0 760 330' width='100%' height='330'>
  <rect x='0' y='0' width='760' height='330' fill='#fbf9f4' stroke='#e2dccf' rx='8'/>
  <text x='32' y='42' fill='#b25a3a' font-size='18' font-weight='bold'>Letta 架构断层：教程预期与生产现实对照</text>
  <line x1='32' y1='58' x2='728' y2='58' stroke='#e2dccf' stroke-width='1'/>
  
  <rect x='32' y='80' width='330' height='215' fill='#ffffff' stroke='#e2dccf' rx='6'/>
  <text x='52' y='112' fill='#2c2822' font-size='15' font-weight='bold'>教程演示模式（V1 Legacy）</text>
  <text x='52' y='145' fill='#7a7266' font-size='13'>状态抽象：固定字符上限的内存块</text>
  <text x='52' y='177' fill='#7a7266' font-size='13'>多协同：无锁覆盖写入（LWW）</text>
  <text x='52' y='209' fill='#7a7266' font-size='13'>灾备便携：依赖 .af AgentFile 导出</text>
  <rect x='52' y='235' width='290' height='36' fill='#fdf2f2' rx='4'/>
  <text x='64' y='258' fill='#c0392b' font-size='12' font-weight='bold'>现状：官方已标记退役，接口强切</text>
  
  <rect x='398' y='80' width='330' height='215' fill='#ffffff' stroke='#b25a3a' stroke-width='1.5' rx='6'/>
  <text x='418' y='112' fill='#b25a3a' font-size='15' font-weight='bold'>官方生产路线（MemFS）</text>
  <text x='418' y='145' fill='#2c2822' font-size='13'>状态抽象：Git 语义的文件系统挂载</text>
  <text x='418' y='177' fill='#2c2822' font-size='13'>多协同：分支检出与版本合并</text>
  <text x='418' y='209' fill='#2c2822' font-size='13'>灾备便携：Repositories 代码库管理</text>
  <rect x='418' y='235' width='290' height='36' fill='#f5ebe6' rx='4'/>
  <text x='430' y='258' fill='#b25a3a' font-size='12' font-weight='bold'>演进：下线 Folder，转向 Agent-SDK</text>
</svg>

官方生态已经按下了向新版切换的快进键。Letta Cloud 已经在 2026年7月17日前 停用了旧版的 Folder 接口并直接返回 HTTP 400，强制要求所有环境迁移至 @letta-ai/letta-agent-sdk 的代码仓库接口。把教程中过时的脚本直接套入商业化基础设施，迎面撞上的不是高效运行的系统，而是弃用报错。

共享状态下的并发踩踏与被击穿的灾备预期

除接口废弃外，教程所依托的 V1 状态机制本身在生产并发场景下极为脆弱。教程中展示的两个智能体通过共享块协同写需求与评审意见，但在底层逻辑中，内存块严格按字符上限计算，多智能体写入时默认遵循最后写入者胜出的粗暴策略。这种全量替换机制缺乏并发控制与差分合并，一旦多个副驾或自动化流程在毫秒级内同时向项目状态写入数据，前一个智能体提炼的决策依据就会瞬间丢失。

无锁覆盖的内存管理不是副驾协同，而是高频写入时的竞态踩踏。

更为棘手的是教程作为卖点介绍的 AgentFile 格式。将副驾状态打包导出的设想看似完善，但在工程实现上存在严重的断裂。

  • 风险..af 文件在导出时会自动将密钥字段置为 null，并且完全不包含归档向量内存中的分块数据，最新的 Letta Code 产品甚至已经彻底废弃了这一格式，导致依赖文件导出的容灾方案根本无法实现完整还原。

企业开发团队以为导出配置就能完成跨集群迁移，最终却只能得到一副丢失了所有历史向量知识的空壳。

Code
<svg viewBox='0 0 760 270' width='100%' height='270'>
  <rect x='0' y='0' width='760' height='270' fill='#fbf9f4' stroke='#e2dccf' rx='8'/>
  <text x='32' y='42' fill='#b25a3a' font-size='18' font-weight='bold'>持久化记忆方案：行业基准分歧与资源代价</text>
  <line x1='32' y1='58' x2='728' y2='58' stroke='#e2dccf' stroke-width='1'/>

  <rect x='32' y='80' width='216' height='155' fill='#ffffff' stroke='#e2dccf' rx='6'/>
  <text x='48' y='110' fill='#7a7266' font-size='13'>Mem0 基准跑分</text>
  <text x='48' y='152' fill='#2c2822' font-size='32' font-weight='bold'>66.88%</text>
  <text x='48' y='182' fill='#7a7266' font-size='12'>p95 延迟 0.200s</text>
  <text x='48' y='204' fill='#7a7266' font-size='12'>上下文消耗 1,764 tokens</text>

  <rect x='272' y='80' width='216' height='155' fill='#ffffff' stroke='#b25a3a' stroke-width='1.5' rx='6'/>
  <text x='288' y='110' fill='#b25a3a' font-size='13'>Letta MemFS 跑分</text>
  <text x='288' y='152' fill='#b25a3a' font-size='32' font-weight='bold'>74.0%</text>
  <text x='288' y='182' fill='#2c2822' font-size='12'>GPT-4o-mini 环境宣称</text>
  <text x='288' y='204' fill='#7a7266' font-size='12'>双方对评测口径公开存议</text>

  <rect x='512' y='80' width='216' height='155' fill='#ffffff' stroke='#e2dccf' rx='6'/>
  <text x='528' y='110' fill='#7a7266' font-size='13'>Letta 生产准入门槛</text>
  <text x='528' y='152' fill='#2c2822' font-size='32' font-weight='bold'>$20<tspan font-size='16'>/月</tspan></text>
  <text x='528' y='182' fill='#7a7266' font-size='12'>Pro 版上限 50 MiB 存储</text>
  <text x='528' y='204' fill='#7a7266' font-size='12'>工具调用另收 $0.00015/秒</text>
</svg>

三大技术流派对撞下的真实选型算盘

企业在构建长生命周期应用时，状态持久化已成为核心分水岭。行业目前分化为三大阵营：以 Letta 为代表的自主状态运行时、以 LangGraph Store 为代表的图状态存储原语，以及以 Mem0 为代表的解耦外置记忆服务。

在长周期记忆基准 LoCoMo 的较量中，派系分歧愈发明显。Mem0 团队在 2025 年 4 月公布的论文中交出 66.88% 的得分，并强调其具备 0.200s 的超低 p95 检索延迟与 1,764 tokens 的极低单次上下文消耗。而在 2025 年 8 月，Letta 发布基于 MemFS 的评估报告，宣布在 GPT-4o-mini 下取得 74.0% 的得分，双方随后围绕测试环境公平性与评测口径爆发争论。这场数据拉锯战揭示了核心分歧：外置记忆层追求低延迟与轻量化，而文件系统流派则坚持让模型自己翻看目录执行状态检索。

评估维度Letta (MemFS)LangGraph StoreMem0
状态架构文件系统与 Git 语义图执行上下文节点外置解耦记忆检索服务
并发策略分支合并（新版演进中）应用层控制与原子事务数据库层级锁机制
生态侵入极高（需完整运行时）中等（需绑定编排框架）极低（API 独立调用）

这种深层架构差异直接决定了团队的维护成本。在商业化定价上，Letta 免费版仅支持 3 个状态智能体与单 Repo 5 MiB 空间；转入每月 $20 的 Pro 版，配额提升至 20 个智能体与 50 MiB 文件存储；若是走 API 计费，除了每月 $20 的底价，还需按每个活跃智能体每月额外支付 $0.10，以及每秒 $0.00015 的工具执行费。

  • 建议.对于只需记录用户偏好和片段知识的场景，引入外置记忆层往往足以交付；唯有面对依赖复杂工程目录、需要严格分支追踪的长效开发任务时，转向新版 MemFS 体系才具有合理性。在此之前，切忌照搬教程去搭建生产系统。