Cursor Max 模式什么时候值得开：它改变的是上下文这一段
会话跑到一半，agent 开始把前面已经确认过的事又问一遍，或者把刚读过的文件重新读一次。这个时候大多数人的第一反应是换个更能干的模型，第二反应是把 Max Mode 打开。
但这两件事解决的不是同一个问题。Cursor 官方文档 cursor.com/help/ai-features/max-mode 对 Max Mode 的定义只有一句话：它把模型的上下文窗口扩到默认上限之外。文档没有写它会换模型、改工具集或者改变 agent 的工作方式——这些是文档没提的部分，不是我们替它否认。所以「什么时候值得开」这个问题，其实要先回答「我现在的问题是不是出在上下文这一段」。
第一道门：你可能根本开不了
这一条得放在最前面，因为它会直接筛掉一批读者。官方文档写明，Max Mode 只在 legacy request-based 计划上可用。文档在标题里就把这个限定写死了，正文第一句又重复了一遍。
也就是说，决策路径的第一步不是「值不值得开」，而是「我这个账号有没有这个开关」。不在那类计划上的话，后面关于开关的部分对你没有意义，但本文后半段讲的上下文观测与其它形态的窗口处理方式仍然成立。
关于怎么打开，官方文档写明：在 chat 或 agent 面板的 model selector 里切换 Max Mode。有两处细节容易被忽略：
- 这个设置会跨会话保持。文档原话是设置在多次对话之间保持开启。你为一次大范围重构打开它，之后所有会话都还是开着的状态，除非你回去关掉。
- 有些模型在被选中时会自动启用它。官方文档的模型表里，有一批条目带着「在 legacy request-based 计划下需要 Max Mode」这样的标注。这类模型你一选就等于开了，不存在「我没点那个开关所以没开」的情况。
至于计费口径，官方文档写明在这类计划下 Max Mode 的计费与常规请求不同，并且更大的上下文窗口会让一次请求用掉更多 token。具体数值随行情变动，本文不写，请以官方定价与用量说明页为准。
它改的到底是哪一段
要理解「扩窗口」为什么有用，得先看默认状态下窗口满了会发生什么。官方文档 cursor.com/docs/agent/prompting 的 Context usage 一节写得很直接：每个 chat 与模型共享一个固定大小的上下文窗口，随着你添加文件、运行工具、来回对话，这些 token 会被填满；当窗口接近满的时候，Cursor 会把较早的对话压缩成摘要，腾出空间给后续对话。
所以窗口大小真正决定的是压缩线什么时候到。开 Max Mode 不会让模型变聪明，它让那条线往后挪。你在会话后半段感到的「它忘了前面说过什么」，如果确实来自摘要压缩，那扩窗口是对症的；如果来自别的原因，扩窗口只是让你多烧一段 token。
怎么判断是不是这个原因？同一页文档写明，输入框旁边有一个 context ring 显示窗口的占用程度，文档写明点击这个 ring 会打开一个明细面板，里面按类别拆分了已用 token。文档列出的类别一共八项：
| 类别 | 文档给的说明 |
|---|---|
| System prompt | Cursor 内置的模型指令 |
| Tools | agent 可用的每个工具的定义 |
| Rules | 被纳入 prompt 的项目规则与用户规则 |
| Skills | 注入到系统上下文里的 skill 描述 |
| MCP | 已连接的 MCP 服务器的说明与目录 |
| Subagents | agent 可以启动的 subagent 类型的文档 |
| Summarized conversation | 早先轮次被压缩后的摘要 |
| Conversation | 你的消息、agent 的回复与工具结果 |
这张表本身就说明了一件事：窗口里被占掉的部分，有相当一块跟你这次对话的内容无关。工具定义、规则、skill 描述、MCP 目录，会话一开始就存在，每开一个新会话都要重付一遍。如果明细里是这几项占了大头，那问题不在窗口不够大，而在固定开销太重。
可执行的判定动作
除了看明细，官方文档里还有两个更硬的抓手。
CLI 侧：cursor.com/docs/cli/reference/slash-commands 列出了 /summarize，语义是「摘要当前对话以减少上下文占用」，/compress 是它的别名；cursor.com/docs/cli/using 在讲选择上下文时也说用 /summarize 腾出窗口空间。官方文档的 slash 命令表没有按平台区分，Windows 与 macOS/Linux 用的是同一张表。
hooks 侧：cursor.com/docs/hooks 定义了一个 preCompact 钩子，在上下文窗口发生压缩／摘要之前触发。文档写明它是观察型的，不能阻止也不能修改压缩行为——这一点别记错，它不是给你留的干预口子，是给你留的观测口子。它的输入字段一共七个：
| 字段 | 文档给的语义 |
|---|---|
trigger | 触发来源，auto 或 manual |
context_usage_percent | 当前窗口占用百分比 |
context_tokens | 当前上下文 token 数 |
context_window_size | 上下文窗口的最大值 |
message_count | 对话中的消息条数 |
messages_to_compact | 将被摘要的消息条数 |
is_first_compaction | 是否为本次对话的首次压缩 |
对本文这个问题来说最有用的是 trigger 和 is_first_compaction：会话里 auto 压缩频繁触发、而且很早就不是首次压缩，「窗口不够」这个判断才算有依据；整个会话根本没触发过压缩，那多半是别的问题，开 Max Mode 不会有帮助。preCompact 的具体接入写法属于 hooks 那一块，本文不展开，以官方文档最新内容为准。
同一个产品内，窗口这件事有四种处理方式
Max Mode 只是 Cursor 处理上下文窗口的其中一种形态。把官方文档里写明的几处放在一起看，差异挺明显：
| 形态 | 官方文档写明的窗口处理方式 |
|---|---|
| 编辑器内的 Agent | 在 legacy request-based 计划上可以用 Max Mode 把窗口扩到默认上限之外，在 model selector 里切换，设置跨会话保持 |
| Cloud Agent | 文档写明「可以为支持的模型选择上下文窗口大小」；计费一节写明更大的窗口会增加 token 用量与成本，并且首次使用时会要求你设置支出上限 |
| Automations | 文档写明它们以 cloud agent 运行，因此使用模型支持的最大上下文窗口，没有上下文窗口的切换项 |
| 移动端 | 文档写明每次运行都使用模型支持的最大上下文窗口 |
这个差异什么时候会咬到你？两个方向：
一是把本地调好的流程搬上 Automations 的时候。你在编辑器里养成的「平时不开、需要时才开」的节奏，在 Automations 上不成立——官方文档明说那里没有这个切换项，跑的就是模型支持的最大窗口。你能调的只剩提示词本身和任务的切分粒度。
二是估算开销的时候。Cloud Agent 那边文档把「窗口更大 → token 用量与成本更高」和「首次使用要设支出上限」写在同一段里，编辑器这边的 Max Mode 文档也写了同样的因果关系。两处口径一致：扩窗口在这个产品里始终是一个有代价的动作。
还得补一行 CLI：cursor.com/docs/cli/reference/slash-commands 的命令表里列出了 /max-mode，文档给的语义是「在 legacy request-based 计划上切换 Max Mode」，也就是说这个开关在 CLI 上是有对应入口的。cursor.com/docs/sdk/typescript 另写明，在这类计划下所选模型需要 Max Mode 时，Cursor 会自动启用它——和帮助页里「有些模型选中即启用」是同一条口径。
Cloud Agent 那边不一样：我们在落盘文档里没有找到 Max Mode 这个名字，那边的表述始终是「选择上下文窗口大小」。这两套说法背后是不是同一个机制，官方文档没有说明这一点，我们不推断，也不比。
还有一条容易被忽略的连带影响，值得单独拎出来：cursor.com/docs/subagents 写明，在 legacy request-based 计划上、所选模型需要 Max Mode 而你没开的时候，subagent 会一律用 Composer 运行，不管你在 subagent 配置里的 model 字段写了什么；只有开了 Max Mode（以及在 usage-based 计划上），subagent 才默认跟随父 agent 的模型。同一页还写明，如果团队管理员把 Composer 也禁了，那么 subagent 只有在 Max Mode 启用时才能跑。所以这个开关的影响面不止主对话的窗口——它还决定了你的 subagent 实际用哪个模型、甚至能不能跑起来。模型的可用性与这类限制随版本和计划变动，以官方文档最新内容为准。
在开窗口之前，还有几个更靠前的选项
同样是「上下文不够用」，官方文档里给出的解法不止扩窗口一条，而且有几条明显排在更前面。
subagents。cursor.com/docs/subagents 写明每个 subagent 在自己的上下文窗口里运行，长时间的调研与探索不占用主对话的空间，父 agent 只拿到最终结果。这一页还有一句文档自述值得注意：内置的三个 subagent（Explore、Bash、Browser）之所以被设计成 subagent，依据是对 agent 会话的分析——那些会话打满了上下文窗口限制。这是官方文档自己给出的理由，不是我们的推断。 换句话说，当窗口被打满时，这个产品自己的第一反应是把噪声隔离出去，而不是把窗口撑大。
side chats。cursor.com/help/ai-features/side-chats 写明它是挂在父 agent 上的持久子对话，父对话的历史作为隐藏的参考上下文交给模型，但不渲染在 side chat 的记录里，适合把岔开的问题问完而不弄脏主线。两条边界要照实说：文档明说不支持嵌套，side chat 里不能再开 side chat；side chats 目前是本地限定，文档写明尚不支持 Cloud Agents，只写了后续会支持。打开方式文档也写明了：输入 /side，或选中文本后从选择菜单选 Ask in Side Chat，也可以用快捷键把选中内容带进去——Windows/Linux 是 Shift+Ctrl+S，Mac 是 Shift+Cmd+S。
@ mentions。文档的建议比很多人以为的保守：知道哪些文件相关时才用 @ 精确投喂，不确定就跳过，交给 agent 自己搜。硬塞一堆文件夹进上下文，是把窗口提前填满的常见做法。
.cursorignore。cursor.com/help/customization/ignore-files 写明它控制哪些文件被索引以及被纳入 AI 上下文，.gitignore 的规则也会被自动遵守。这里有一条必须照实转述的边界：文档明确写了，terminal 命令与 MCP 工具运行在 Cursor 的文件访问控制之外，仍然可能读到被忽略的文件。所以别把它当成把敏感文件挡在模型之外的保证。
Plan Mode。cursor.com/docs/agent/plan-mode 写明用 Shift+Tab 从输入框轮换到 Plan Mode，先出一份可审阅、可编辑的实现计划再动代码；文档还建议，当 agent 建出来的东西不对时，回到计划改精确再重跑，比在半成品上追加提示更快。这条对窗口的意义在于，它把「反复纠偏」这种最耗上下文的循环挪到了写代码之前。
收束成一条决策路径
把上面的东西按顺序串起来，实际要走的是这么几步：
- 先确认是不是真的窗口不够——看用量明细的分类，看
preCompact是不是频繁以auto触发。没触发过压缩就不是这个问题。 - 如果固定开销占大头（Tools、Rules、Skills、MCP 这几类），先去删没在用的 MCP 服务器、收敛规则、用
.cursorignore把生成物挡在索引外。 - 如果是一次性的大范围探索把窗口撑爆的，让它落到 subagent 或 side chat 里去，主线只接结果。
- 如果确实是「这一段就得同时看这么多东西」，而且你在 legacy request-based 计划上，那才轮到 Max Mode。官方文档自己的建议是：默认窗口对大多数编码任务够用，需要超出默认窗口的上下文时才用它。
- 用完记得回头看一眼开关，因为文档写明这个设置跨会话保持。
Cursor 迭代很快，上面涉及的设置项、命令与字段都可能随版本变动，以官方文档最新内容为准。
本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。
该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现；
我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。
该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。
本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。
本文对照的是同一产品内的两种形态，依据均为上述官方文档，不对两种形态做优劣排名， 选型结论只在官方文档写明的能力边界内成立。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。