《Agent原理，架构与实践》
第4讲：长任务记忆
准备起一个新的系列《Agent原理，架构与实践》。目标不贪心：
1. 希望每篇文章有1-2个点能让大家有收获；
2. 希望不被骂；
本期第四讲，咱们开始。
上一篇，我们聊了上下文的稀缺性，那么问题来了：窗口塞满了，该怎么办？Agent架构要如何设计，来处理这种情况？
【1】写满了，可以把最早的对话扔掉吗？？
把前面的对话扔掉，只留最近的上下文，这是最容易想到的方法。
此时，之前对话里的关键信息就会遗失，那些已经被改掉的具体实现，项目的总体愿景，关键的技术约束和决策理由...
于是，模型开始“失忆”：忘了自己在做什么、为什么这么做，接下来的产出就会跑偏。
不要嘲笑这个方法，咱们的大脑就是这么运行的：短期记忆是正在想的事，长期记忆是存下来的经验，短期记忆记得牢，长期记忆容易被忘掉。
要如何优化呢？
自然而然能想到的办法，把之前的关键信息进行“压缩”，和短期记忆一起放进有限的上下文。
【2】压缩，用什么策略？
压缩，说白了就是总结，那要压什么内容进去？
1. 关键决策及其理由：选了方案B而不是方案A，因为...
2. 未完成事项及其当前状态：支付模块写了70%，卡在退款逻辑；
3. 中间结论：测试框架配好了，跑通了3个用例；
什么信息，可以被扔掉呢？
1. 工具原始输出：报错堆栈、终端刷屏，一次之后就没用了；
2. 琐碎的过程：改了多少版、错了多少次；
3. 客套话："好的""明白了""我来修改"；
如此一来，大几十轮轮对话，5万个token，可以压缩成500个token的关键摘要：上下文占用降低了99%。而且压缩后的信息质量更高：全是决策和结论，没有噪音。
这，是Agent架构设计中很重要的一步。
【3】抛开上下文，外部怎么建记忆？
上面两个方法都是在上下文窗口内部做文章：扔掉旧的，压缩剩下的。但如果任务特别长，信息特别多，光靠这两个方法还是不够。这时就需要第三个方法：在上下文的外部建立记忆。
具体的做法，让Agent在文件系统里维护结构化的笔记文件，记录重要的状态、决策和待办事项。举个栗子，一个编码Agent，可以维护了一个todo清单文件，每完成一项就勾掉一项，还可以记录当前正在处理哪个任务、接下来要做什么...
说到这，不得不提RAG。一提到Agent的记忆，很多人第一反应就是RAG。但其实吧，RAG只是"外部记忆+按需检索"的一种实现方式。
现在的Agent，已经不推荐用RAG解决长任务记忆了。
两个原因：
1. 检索质量决定一切：检错了、检漏了，上下文就不完整；
2. 就算检对了，检回来照样占上下文：检索回来一大段，窗口又塞满了；
更常见的方式，就是用md文件。
回到咱们的sdd-site-agent上来，我们的记忆结构可以这么设计：
1. 长期记忆：三个规范文件 + decision.md决策记录，存放在文件系统里；
2. 短期上下文：当前任务 + 当前规范，存放在上下文对话里；
3. 压缩策略：过程对话定期压缩（大头是对话过程中，工具输出的内容去掉）；
【4】简单总结
1. 窗口满了，扔掉，压缩、落盘，就是Agent管理记忆最常见的实践；
2. RAG是外部记忆的一种实现方式，现代Agent最常用md文件。
补充阅读：《AI agent高效上下文工程》
https://www.anthropic.com/research/effective-context-engineering-for-ai-agents
下一讲，咱们聊聊Agent的本质：一个程序，只有一个功能，每天定时帮你查天气，根据天气情况，主动提醒你防晒，带伞，or其他建议，是不是Agent呢？
画外音：是。
欢迎持续关注，让我们一起，一步一步，实现自己业务专属的mini-agent。
知其然，知其所以然。
思路比结论更重要。
===全文完==
PS：公众号只能贴静态图文，无法用js实时互动，在线版设计了课后习题与实操演练，欢迎阅读原文体验。
文章原文
