大语言模型驱动的智能体有一个绕不开的限制：上下文窗口容量固定。一旦对话历史超过窗口上限，最早的内容就会被丢弃。这相当于要求一个程序员在维护大型项目时，只能记住最近几分钟看过的代码——其他一切都要靠翻笔记。
问题是，笔记怎么记？记在哪里？怎么才能保证翻笔记的时候不翻错？
这不是一个“把窗口做大一点”就能彻底解决的问题。窗口再大，也赶不上项目历史的积累。真正的挑战在于：当短期记忆注定失效时，我们需要一套什么样的外部系统来充当长期记忆？
我整理了一个笔记仓库，里面有几个相关设想，不做具体实现方案，只讨论可能的方向。
假设一个社会里，每个人都患有严重健忘症，只能同时记住三到五件事。执行几个动作之后，之前的记忆全部清零。这样的社会还能不能完成复杂工程？
答案是能，但有前提：
当个体记忆小到只剩两个槽位时，单干连稍复杂一点的任务都处理不了，必须两人协作，通过共享便签来模拟更强的计算能力。但协作人数超过某个临界点后，沟通开销反而拖累效率。
Agent 的上下文窗口，就是那个健忘个体的记忆槽。我们需要为它设计一套好用的外部便签系统。
以下内容不是成熟方案，而是方向性的设计草图。大部分工程细节需要由 Agent 运行时的系统层处理，而非让模型在提示词里自己折腾。
Issue 树：给每条消息一个地址
像 Git 用 SHA-1 给每次提交一个唯一标识一样，我们能不能给对话历史里的每条消息一个路径式的地址？比如 /0/1/2。配合每条消息的类型标记（是提问、是陈述、还是无意义内容），Agent 就能像访问文件系统一样精确回溯任何一条历史消息，而不是靠语义搜索去猜。
平方根边界：一种自检指标
通过一个简单的类比推导，可以得到一个启发式边界：如果把 N 个 token 的上下文压缩成 k 个 token，当 (k \le \sqrt{N}) 时，信息损失几乎必然发生。同理，如果解决一个问题明明只需 k 个 token 的核心信息，实际却消耗了超过 (k^2) 个 token 的上下文，就说明对话中存在结构性冗余。
这两个数字不是精确定理，但可以作为 Agent 判断当前上下文是否健康的简单信号。
惰性工具调用：占位符代替输出
工具调用产生的输出常常冗长且充满噪音，直接塞回对话历史既浪费 token 又分散注意力。设想一种机制：工具执行后只返回一个占位符（如 @lazy{{...}}），系统后台维护占位符与真实输出的映射。Agent 知道有这么个结果，但不需要把整份结果背在身上，需要时再去取。
脚本库：让每次操作留下资产
Agent 经常执行相似的 Shell 命令序列，出错后重试，重试后再忘。与其每次动态拼命令，不如让 Agent 把稳定下来的操作固化成脚本文件，存放在按目标分类的目录里（比如 git/commit/auto-sign.exp.sh）。脚本文件名本身就是提示词。随着时间的推移，这些脚本积累成 Agent 的操作经验库。
工具、语言、文字，动物都有雏形。但动物没有“记录与读取”的外部循环。一只猩猩发明了更好的取食技巧，如果没来得及教给同伴就死了，这个技巧就从地球上永远消失。人类把知识刻在骨头、泥板、纸张和磁盘上，让任何个体的偶然发明都能变成整个种群的永久资产。每一次存储介质的成本骤降，都会带来一轮技术爆发。
对于上下文有限的 Agent，我们需要为它补上的，正是这一层外部记录与读取系统。
以上想法仍在设想阶段，没有实验数据支撑，仅作为一份公开的设计笔记。如果你对这类话题有兴趣，欢迎访问 GitHub 仓库 查看完整的文档。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。