在构建长周期运行的编码代理时，上下文窗口的 Token 预算始终是核心瓶颈。当代理需要处理跨越数百次交互的任务时，完整保留历史记录的成本会迅速超出可接受范围；而简单地丢弃历史又会导致代理丧失对任务依赖关系和上下文连续性的感知。外部记忆层架构正是为解决这一矛盾而设计 —— 将长期记忆外部化，仅将任务相关的关键切片加载到模型的上下文窗口中，从而在保持代理记忆能力的同时实现 Token 成本的可控。
外部记忆层的设计哲学
外部记忆层的核心设计理念是将「记忆」与「推理」解耦。传统方案中，代理将所有历史对话、工具调用结果和中间状态堆积在上下文窗口内，这种方式的弊端显而易见：每一次新的交互都在消耗稀缺的 Token 预算，而真正与当前任务相关的核心信息往往被稀释在大量噪声之中。外部记忆层则采用了一种分层架构 —— 工作内存负责当前任务的即时推理，外部持久化存储负责历史信息的结构化保留，而检索层则负责在两者之间按需拉取相关片段。
Beads 是这一设计理念的具体实现之一。它以 Dolt（一种版本控制的 SQL 数据库）作为底层存储，为编码代理提供了一张依赖感知的任务图。与传统的 Markdown 计划文档不同，Beads 通过图结构显式建模任务之间的阻塞关系、父子层级和语义关联。当代理需要判断某项任务是否可以推进时，它可以直接查询图中哪些前置任务已经完成，而无需在上下文中翻阅冗长的历史记录。这种结构化存储使得记忆的精确检索成为可能，而非依赖向量相似度进行模糊匹配。
Beads 还提供了语义「记忆衰减」机制 —— 当任务关闭并经过一定时间后，系统会自动对其进行摘要压缩，将完整的任务描述、评论和状态变更日志压缩为精简的摘要形式。压缩后的摘要保留了关键信息（任务目标、关键决策、关联的代码变更），但大幅降低了占用的 Token 空间。这一机制与生物层面的遗忘曲线有本质区别：它是有计划的、结构化的信息凝练，而非随时间的随机丢失。
Token 预算分配模型
在外部记忆层的架构下，Token 预算需要被明确划分为若干区域，每个区域承担不同的功能角色。以一个典型的编码代理场景为例，假设使用 GPT-4 Turbo（上下文窗口 128K Token），可以将预算做如下划分：
系统提示区通常占用 2K 至 4K Token，用于描述代理的角色定义、工具可用性和输出格式规范。这一区域在任务生命周期内相对稳定，不频繁变动。任务上下文区是预算的核心消耗地带，建议占用 60K 至 80K Token，用于容纳当前任务的描述、相关的外部记忆检索结果、以及最近几轮的关键交互历史。工具输出区应预留 20K 至 30K Token，用于捕获工具调用返回的代码片段、错误信息和文件状态。生成预留区至少保留 15K Token，确保模型有足够的空间完成响应输出，避免因窗口占满而导致截断。
在实际运行中，当任务上下文区超过 70% 容量时，系统应当触发外部记忆检索，将当前任务相关的历史切片从 Beads 图中拉取到窗口内，同时对窗口中较早的非关键信息进行压缩或剔除。当容量接近 90% 时，应执行强制压缩 —— 将窗口内的历史交互摘要后存入外部记忆，并清空窗口以接纳新的任务相关片段。
上下文窗口成本对比
不同模型层级和上下文窗口大小导致的 Token 成本差异显著。以 2025 年主流 API 定价为参照基准，Claude 3 Haiku 的输入 Token 成本约为每百万 Token 0.25 美元，输出成本约为 1.25 美元，上下文窗口可达 200K；Claude 3 Sonnet 的输入成本约为 3 美元、输出 15 美元，而 Claude 3 Opus 的输入成本则高达 15 美元、输出 75 美元。GPT-4 Turbo 的输入成本为每百万 Token 10 美元，输出 30 美元，上下文窗口为 128K。
对于一个持续运行多天的编码代理项目，假设每天需要处理约 500K 输入 Token 和 100K 输出 Token，采用外部记忆层架构与不采用时的成本差异如下：不使用外部记忆时，代理每天都需要将完整的任务历史堆入上下文，假设历史累积为 400K Token，则每日输入成本约为 5 美元（GPT-4 Turbo 基准）。采用外部记忆后，仅加载当前任务切片（约 80K Token）和必要的检索结果（约 50K Token），输入成本降至约 1.3 美元，降幅约为 74%。对于更大规模的团队协作场景（多个代理并行操作同一项目），这一成本优势会更加显著 ——Beads 的图结构支持多代理并发写入，通过哈希 ID（格式如 bd-a1b2）避免合并冲突，这意味着多个代理可以共享同一个外部记忆库，而无需为每个代理维护独立的历史副本。
实施要点与监控参数
在生产环境中部署外部记忆层时，以下参数和监控点值得关注。检索阈值建议设置在上下文窗口容量的 60% 至 70% 之间，当占用率触及这一区间时主动触发检索，避免等到窗口逼近上限时被动压缩。压缩触发点建议设置在 85% 至 90%，保留足够的缓冲空间以应对突发的大量工具输出。摘要粒度应根据任务复杂度调整 —— 简单任务可仅保留任务标题和最终状态，复杂任务则需保留关键决策点、代码变更关联和阻塞关系。
Beads 提供了两种存储模式以适应不同的部署需求：嵌入式模式（默认）适合单代理场景，数据存储在项目本地的 .beads/embeddeddolt/ 目录下，无需额外部署；服务器模式则面向多代理协作场景，通过连接外部 Dolt SQL 服务器实现并发写入，端口默认为 3307。对于追求完全离线操作的场景，Beads 还支持 Git 无关模式（--stealth），只需指定 BEADS_DIR 环境变量即可在任意目录下创建记忆库。
从监控视角看，应当追踪三个核心指标：上下文窗口平均占用率（反映检索策略的有效性）、外部记忆压缩频率（过高则说明切片粒度或检索策略需要调整）、以及 Token 成本环比变化（用于评估架构优化的实际收益）。当压缩频率超过每日多次时，通常意味着任务切片的选取逻辑过于宽泛，或者任务之间的依赖关系没有被充分利用 —— 这种情况下应当收紧检索条件，优先加载与当前任务存在直接依赖关系的节点。
外部记忆层架构为编码代理提供了一种在上下文窗口限制下维持长期任务记忆的可行路径。通过将结构化的任务图（Beads）与精细化的 Token 预算分区相结合，代理能够在控制成本的前提下处理复杂的多阶段项目，而不必在「完整记忆」与「可承受成本」之间做出非此即彼的取舍。
资料来源：Beads 官方仓库（https://github.com/gastownhall/beads）；Token 预算管理实践参考（https://dev.to/akshaygupta1996/context-engineering-giving-ai-agents-memory-without-breaking-the-token-budget-1ho5）。