为什么 Zed 的 Agent 会遗忘
每个线程都从自己的上下文开始
Agent Panel 支持多个并发的 Agent 线程，以及用于 CLI 和 TUI工作的 Terminal Threads，每个线程都拥有独立的上下文和历史记录。这种独立性正是让并行 Agent 变得可用的原因——但也意味着你在一个线程中建立的任何内容在下一个线程中都是不可见的。你可以显式地 @ 提及之前的线程，而 "New From Summary"（从摘要新建）可以用当前对话的摘要来初始化一个新线程，但这两者都是你必须主动记住去执行的手动操作。
压缩（Compaction）管理的是空间，而不是知识
当长 Agent 线程接近配置的 Token 阈值时，Zed 会自动对其进行压缩，总结较早的消息并留下一个可供查看的 "Context Compacted"（上下文已压缩）条目；/compact 可以按需执行此操作，而 agent.auto_compact 控制该行为。对于长会话来说，这是很好的工程设计，但很容易被误认为是记忆功能。压缩只是缩短了线程中已有的内容。它不会将任何内容移出线程，而且摘要会随着线程的结束而消失。
.rules 是指令，而不是积累
Zed 会从工作区根目录读取项目规则文件，并自动将其包含在每次 Agent Panel 交互中。它会检查一个优先文件名列表——.rules、.cursorrules、.windsurfrules、.clinerules、.github/copilot-instructions.md、AGENT.md、AGENTS.md、CLAUDE.md、GEMINI.md——并使用第一个匹配项。这确实非常有用，也是你的规范能在新线程中得以保留的原因。
但规则文件是你编写的内容，而不是 Agent 填充的内容。Agent 在下午 4 点发现的任何事情，都不会在下午 5 点自动出现在那里。如果不去管它，它就会过时；如果勤勉地维护，它就会变成一堵“文字墙”，在每次交互中消耗 Token，并掩盖了真正重要的那十个事实。
Zed 中的记忆是需要你来组合的
Zed 支持在 context_servers 下配置 MCP 服务器，这些服务器可以作为扩展安装，也可以直接配置为带有命令参数或 URL 以及可选认证标头的本地或远程服务器，向 Agent 暴露 MCP Tools 和 Prompts，其权限由 agent.tool_permissions.default 管理。这是官方认可的持久化途径：连接一个记忆服务器，Agent 就可以读取和写入比线程生命周期更长的知识。没有任何东西是预先配置好的。
Zed 用户首先尝试的方法
@ 提及以前的线程
当你记得哪个线程有答案时，这既精准又实用。但一旦你有了 30 个线程，并且不知道哪一个包含关于重试机制的决定时，它就无法再扩展了。
New From Summary（从摘要新建）
这比冷启动要好，但本质上是一种有损的交接：摘要保留了对话的大致轮廓，却丢掉了那些最终证明很重要的细节——例如某个临时解决方案存在的确切原因，或者行为发生改变的具体版本。
更大的 .rules 文件
这是最常见的答案，但也是一个有着硬性上限的方案。每次交互都要为它的完整长度付费，更新依赖于人工维护的自觉性，而且它无法表达任何有时效性的内容。它是一个假装成知识库的简报文件——这与为什么 Claude Code 会遗忘项目上下文中所描述的上限相同。
仓库中的草稿 Markdown 文件
团队会保留一个 notes.md 并用 @ 提及它。这在一段时间内效果出奇地好，但随后就会变成一个无人修剪、只能追加的日志，其中充斥着相互矛盾的条目，且无法分辨哪一个是当前最新的。
解决方案：将持久化记忆服务器接入 Zed
既然 Zed 期望通过 MCP 获取记忆，那么干净的解决方案是给它一个专为此任务构建的记忆层，而不是一个假装是记忆的文件。MemoryLake 只需一次性存储你的架构、决策和规范；每个线程——以及你使用的每个其他 Agent——都会从同一个源读取数据。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。
步骤 2：上传你的第一批记忆
放入保存项目真实上下文的文档、图像和文件：架构说明、ADR（架构决策记录）、运行手册、API 规范、事件总结，以及你的线程不断重复推导的决策。
步骤 3：连接你的 AI 和 Agent
让 Claude、Codex、OpenClaw 以及你的其他 Agent 通过 MCP 或 API 访问该记忆——在 Zed 的情况下，将其作为上下文服务器与你的其他 MCP 条目并列，并按照你团队喜欢的方式设置工具权限。这样，每个新的 Agent 线程在打开时就已经了解项目，而不是一片空白。如果你也在终端中工作，为 Claude Code 添加记忆和使用 MCP 设置跨 AI 记忆介绍了如何从其他客户端接入相同的记忆层。
这在实践中带来了什么改变
并行 Agent 会使遗忘的成本成倍增加。重建上下文每次大约需要消耗 1,500 个 Token 和 2 分钟的时间；每天运行 6 个线程，那就是每天有 9,000 个 Token 和 12 分钟花在开场白上——在任何人开始写代码之前，每月大约就要消耗 270,000 个 Token。一个庞大的 .rules 文件并不能消除这一成本，反而会让它变成无条件的：你在每个线程中都要为整个文件付费，即使是那些只需要其中两行内容的线程。
行为上的差异则更为显著。当线程共享记忆时，线程二就会知道线程一发现的迁移顺序约束，而不会“热心”地去“修复”它。这与多 Agent 记忆属于同一类问题，只是发生在一个编辑器内部——这也是为什么运行并发 Agent 的团队会比其他人更早感受到这一点。
Zed Agent 记忆的最佳实践
将指令与知识分离
将 .rules 用于规定 Agent 应该如何表现——代码风格、审查预期、禁止的路径——并将关于系统的客观事实保留在记忆中。规则保持足够简短，以证明每次加载都是合理的；知识不断增长，却不会给每次交互带来负担。
在线程结束时写入记忆，而不是开始时
一个长线程的有价值输出通常只有一两句话：决定了什么以及为什么。养成在关闭线程时存储这些内容的习惯，否则下一个线程就必须付出代价来重新发现它。压缩不会帮你做到这一点——它只在线程内部进行总结，并随线程一同消失。
修剪条目并标注日期
记录做出决定的时间，并替换掉被取代的事实，而不是在它们旁边堆叠新的事实。Agent 信任它们所读到的内容，因此一个过时的条目比缺失的条目危害更大——这与防止草稿纸变成矛盾日志所需的纪律是一样的。
结论
Zed 的 Agent 会遗忘你的项目上下文，是因为线程在设计上是隔离的，压缩是在线程内部而非跨线程运行的，.rules 是一个静态指令文件，而记忆明确是需要你通过 MCP 接入的东西，而不是开箱即用的功能。对于一个拥有并行 Agent 的快速编辑器来说，这些都不是缺陷，而是一种分工。
只有当你做好你那部分工作时，这种分工才能发挥作用。将架构、决策和规范放入记忆层，并将其连接为上下文服务器，这样你选择 Zed 所追求的高速度，就不会再浪费在重新解释上一个线程已经知道的事情上。