为什么存在该限制，以及为什么更多条目并不是目标
限制的是条目数，而非字节数
Manus 计算的是条目数量。100 个长条目和 100 个单行条目会触及相同的限制，这使其成为一个内容整理限制，而非容量限制。这也意味着最省力的优化通常是合并：描述相同规范的三个条目应该合并为一个。
官方给出的原因是回答质量
这就是它与你遇到的大多数限制的不同之处。Manus 官方的解释是“条目过多可能会影响系统的回答质量”。这与存储成本无关，也与 Pro/Free 之外的会员等级无关。
从其自身的逻辑来看，这是一个合理的说法——任何作为常驻上下文加载的内容都会与同样作为常驻上下文加载的其他内容竞争注意力。一个包含 100 个各种杂乱事实的存储库，其检索效果要差于一个包含 30 个相关事实的存储库。其他地方也是同样的模式。Claude Code 仅加载“MEMORY.md 的前 200 行，或前 25KB，以先到者为准”，并建议每个指令文件控制在“200 行以下”，因为“较长的文件会消耗更多上下文并降低遵循度”。Kiro's Crew 记忆对每一层分别限制字符数——偏好设置为 4,250 字符，项目设置为 6,400 字符——而不是让其中任何一个无限增长。Perplexity 将项目指令限制在 8,000 个字符。
Manus 的独特之处仅在于它以条目数来表示上限，这使其变得显而易见。但其背后的逻辑在任何地方都是一样的。
全局存储库正在承担它不适合的工作
用户知识库是一个被广泛应用的单一存储库。如果你将 Manus 用于四种不相关的工作，那么你教给它的关于其中一项工作的知识，都会作为另外三项工作的上下文存在。
这就是人们触及上限的真正原因。并不是因为他们有 100 个真正的全局事实，而是因为他们在一个没有“项目”概念的存储库中，放了 20 个全局事实和 80 个特定于项目的事实。
这很奇怪，因为 Manus 确实有这个概念
Manus Projects（项目）被描述为“具有共享指令和文件的持久工作区，因此每个新任务都从正确的上下文开始”。一个项目包含两样东西：一个主指令（master instruction）和它自己的知识库（包含文件和文档），这两者“都会自动应用于该项目内创建的每个新任务”。
两个特性使这成为了真正的解决方案。项目“对所有订阅层级的所有用户开放”，因此这不需要付费升级。而且 Manus 没有记录项目知识库的条目上限——它保存的是文件和文档，而不是计数的条目。
Manus 官方文档中的一句话值得牢记：“工作本身可能是可重复的，但环境搭建往往不可重复。”这恰恰是全局知识库所不擅长、而项目所擅长的。
人们尝试过的方法
删除最旧的条目。 官方文档建议——“根据您最重要和最近的需求筛选知识库中的条目，并删除一些不必要的条目”——这确实有效。但时间并不是衡量价值的好标准。你 18 个月前设定且从未修改过的规范，往往是你最不想丢失的。
将多个事实塞进一个条目中。 这可以让你把数量控制在限制之内，但却违背了限制存在的初衷。一个包含 9 条不相关规则的单一条目比 9 个独立的条目更难应用，而且现在你无法单独删除这 9 条规则中的某一条。
升级到 Pro 以获得更多空间。 将上限从 50 翻倍至 100，出于其他原因这确实是个合理的选择。但它并没有改变质量动态，而且 Manus 建议精简的忠告同样适用于 Pro 用户。
保留一份主文档并将其粘贴到任务中。 这是一个常见的临时解决方案，它确实能让 Manus 看到这些内容。代价是这是针对每个任务的手动工作，而这恰恰是 Projects 旨在消除的环境搭建负担。
等待限制被提高。 Manus 确实表示“未来，我们将继续根据用户需求和反馈优化知识库功能”，因此这很可能会改变。但这并不是本周的计划，而且即使上限提高，关于质量的论点依然成立。
将其视为搜索问题。 添加更多文档以便能检索到正确的文档，这是文档检索培养出的人类直觉，但它不适用于一个常驻且总是应用的微型存储库——这一区别在为什么 RAG 不是记忆中有所讨论。
解决方案：为每种工作提供专属上下文，并在底层保留一个持久层
这个步骤是一个分类整理过程，大约需要 20 分钟。
将每个条目分类到三个桶中。 真正的全局条目——适用于你和你的所有工作，例如你的写作规范或你的角色。特定于项目的条目——适用于某个循环往复的工作流。过期的条目——曾经适用，但现在不再适用。
删除第三个桶。将第二个桶移至项目知识库中。全局存储库中剩下的内容应该很少，而“少”正是关键所在。
然后正确设置项目。Manus 关于主指令的指南是最具杠杆效应的部分：“编写详细的主指令。您的指令越具体，您在每个新任务中需要提供的上下文就越少。”你也可以在事后将现有任务移入项目中——文档中描述项目的运作方式类似于文件夹。
在依赖它之前，需要了解两条不符合直觉的传播规则。“指令更新：在您当前任务中下一次发送消息时生效。”但是“文件更新：仅在更新后创建的新任务中生效。”更广泛地说：“所有先前创建的任务均不受影响，并将继续使用创建时存在的配置。”任务会绑定到它诞生时的配置，因此修复文件并不能修复正在运行的任务——请启动一个新任务。
关于共享项目的一点协作说明：“当您邀请同事加入项目时，他们可以访问共享的主指令和知识库。但是，他们只能看到自己在该项目中创建的任务。”知识是共享的，但工作不是。
这解决了拆分问题。但它没有解决的是，这两个存储库都是 Manus 的，受 Manus 规则的限制，并且只能在 Manus 内部读取。这就是底层持久层发挥作用的地方——这也是 MemoryLake 所保存的内容：将你的项目知识保存在一个你的工具可以查询的层中，这样条目上限只限制了 Manus 保持加载的内容，而不是你被允许知道的内容。设置只需三个步骤。
步骤 1：创建 API 密钥
登录并创建 API 密钥。一个凭据即可连接你的所有工具。
步骤 2：上传你的第一批记忆
简短的条目，每个条目只包含一个主张。上面的分类整理刚刚生成了理想的输入列表，因此请以此为基础：
“过期”堆中让你犹豫不决的所有内容。 那些你不确定的条目，最值得保存在没有上限的地方。将它们从 Manus 中删除，保存在这里。
附带原因的决策。 “我们以 4 周为周期进行报告，而不是按月，因为财务结算时间会变动。”条目陈述了规则，但只有附带原因才能防止它再次受到质疑。
不适合主指令的特定于项目的细节。 主指令应该简短且具有指导性。其背后的背景不属于那里，也不需要被丢弃。
跨项目的事实。 任何适用于两个工作流但非全部工作流的内容，在任何一个存储库中都没有好的归宿。
步骤 3：连接你的 AI 和智能体
MemoryLake 可以通过 MCP 和 API 访问，并且 Manus 支持 MCP 连接器和自定义 MCP 服务器——因此 Manus 可以查询你的其他助手读取的相同记忆，而像 Claude、Codex 和 OpenClaw 这样原生支持 MCP 的智能体可以通过指向 MCP 服务器进行连接。这意味着“我们对此做出了什么决定”的答案，不再取决于你的 100 个条目中哪一个在上次清理中幸存下来。
三个真实的限制。MemoryLake 无法读取、写入或计算你的 Manus 知识库——该上限在 Manus 内部强制执行，管理这些条目的唯一工具是 Manus 自己的工具。它只保存你或你的智能体放入其中的内容，因此步骤 2 是手动的。而且它不会提高任何限制：Manus 仍然加载 Manus 加载的内容，一个更小、更精心整理的知识库仍然是我们的目标。
这在实践中改变了什么
删除条目不再让人觉得冒险。 你是在移动它，而不是丢失它。
全局存储库变小并保持实用。 20 个相关事实胜过 100 个杂乱事实，这也是官方自己的论点。
项目设置不再重复。 主指令加上项目知识库会自动应用于每个新任务。
“这是针对哪个条目的？”有了答案。 项目范围的上下文属于项目。
达到上限不再是一件大事。 它变成了进行分类整理的提示，而你本来就会从中受益。
知识的寿命比工具更长。 如果你以后迁移，这会很有用——具体形式在如何从 Manus 迁移到 Cursor中有所讨论。
Manus 知识库的最佳实践
在删除之前先合并。 将分布在三个条目中的重复规范合并，是减少数量最简单的方法。
将全局存储库留给真正的全局内容。 你的角色、你的规范、你的长期偏好。不要包含任何指代单一项目的内容。
将项目上下文放入项目中。 它在所有订阅方案中均可用，且没有记录任何条目上限。
编写具体的主指令。 Manus 的指南指出，主指令越具体，你每个任务需要提供的内容就越少。
更改项目文件后启动新任务。 文件更新仅适用于更改后创建的任务。
定期审查，而不是等到达到上限。 Manus 自己的建议是“保持您的知识库最新”。每季度进行一次审查胜过紧急清理。
不要在一个条目中堆叠不相关的规则。 这违背了上限存在的初衷，并使得选择性删除变得不可能。
保留你删除的任何内容的副本。 上限是一个加载决策。它不应该是一个遗忘决策。
结论
Manus 知识库对 Pro 用户限制为 100 条，对免费用户限制为 50 条，官方给出的原因是为了回答质量而非存储——“条目过多可能会影响系统的回答质量”。从这个角度来看，该限制是关于内容整理的建议，而推荐的操作确实是精简而不是扩展。
实际的解决方法是，Manus 有两个知识库，而大多数人只使用其中一个。项目（Projects）带有自己的主指令和自己的文件知识库，自动应用于其中创建的每个新任务，并且在所有订阅层级中均可用。将你的全局条目分类为全局、特定于项目和过期——然后将中间的一组移入项目中——通常可以解决上限问题，而无需删除你想要的任何内容。
只需了解传播规则：指令更新在你的下一条消息中生效，文件更新仅影响新创建的任务，而现有任务保留其创建时的配置。并将持久的部分——决策、原因、你犹豫要不要删除的内容——保存在一个没有条目限制的层中，这样整理 Manus 加载的内容就永远不会意味着丢失你所知道的知识。