软件开发领域的每一次重大进步，都改变了团队表达意图的方式。瀑布模型依赖厚重的文档，因为调整方向很缓慢。敏捷减少了文书工作，因为迭代成本低，团队可以在行动中学习。

智能体需要一套属于自己的规划方式。与其采用那种过早冻结意图的门控式流程，它们更适合一种既能在前期提供方向、又能保持鲜活并扎根于真实工作的规划方法。

#让 Agent 发挥效能所需的关键要素

当 Agent 能够用清晰的语言拆解问题时，就更容易保持在正确轨道上。它会提出问题、去除预设前提，并在动手写代码之前先勾勒出路径。训练过程会不断强化这种行为。

当计划既清晰又可调整时，Agent 就能在不跑偏的前提下，承担更长周期的工作。因此，为 Agent 做规划，更适合通过可反复迭代的工作界面来完成，而不是依赖一份固定的规范。规划本身会成为循环的一部分。

当 Agent 发现新的约束时，它会更新计划。随着用户不断细化意图，计划也会随之调整。这种节奏，比起早期时代那种分阶段、割裂式的规划流程，更符合基于 Agent 的开发方式的内在规律。

#Cursor 如何为智能体智能设计规划能力

我们基于对软件开发团队如何最高效使用智能体的理解构建了 Plan Mode。这是一种专门为智能体式开发设计的强大通用规划方法。

Plan Mode 为智能体提供了一个空间，用来提出问题、扫描代码库、提出实施路径，并与你一起反复打磨。它既可以以轻量形式完成快速任务，也可以演变为长期存在的标准化工件。整个流程包含五个步骤：

1. 澄清问题。智能体提出问题以消除歧义。敏捷团队通常通过快速的来回沟通处理这一步；Spec-driven development (SDD) 则将其作为正式的需求阶段。Plan Mode 同样以“减少歧义”为目标，但让智能体主动驱动提问，更契合智能体工作的节奏。

2. 调研。智能体扫描代码库，找出需要交互的代码位置。以往的工作流往往把这当作单独的设计阶段；Plan Mode 则直接把它纳入智能体的推理过程。

3. 拟定计划。智能体会编写一个可编辑的计划文件，说明要进行的更改以及实现这些更改的步骤。SDD 会把这一步冻结为固定的规格；敏捷实践中文档往往会逐渐偏离实际。Plan Mode 让计划始终保持“活着”，这样你和智能体就能随着新信息出现不断完善它。

4. 执行工作。智能体按步骤推进，并逐项勾选任务。传统方法会把规划和实现拆开处理；Plan Mode 则把它们视为一个整体过程，使计划可以随时自适应调整。

5. 修订计划。当事情偏离轨道时，计划本身也是“重置点”。团队无需通过一连串补充提示来“打补丁”，而是可以回滚工作、完善计划并重新执行。这样可以让意图保持清晰，比在执行中途“扭转方向”的方式得到更干净的结果。

计划会作为版本控制文件保存在你的工作区 .cursor/plans/ 中。它们与代码并列，像其他项目工件一样由 git 跟踪。你可以查看发生了哪些变更、发生在什么时候，并在需要时回滚。

#灵活的规划原语

团队用不同的方式来组织意图。有些依赖正式的需求文档，另一些采用不断演进的设计或分阶段的工作流。一个规划框架需要足够灵活，才能适应团队偏好的工作方式。

这一点在当下尤为重要，因为环境正快速变化。瀑布模型曾在几十年间定义了规划方式，随后又有二十年由敏捷塑造了团队。而 智能体 智能演进的节奏则要快得多，任何固定不变的流程都会很快老化。

这正是我们围绕一组简单原语来构建规划方式的原因，你可以按自己的需求自由塑形。你可以使用 智能体 Skills 来定义团队偏好的规划结构，智能体 会始终如一地遵循这套结构。

有些团队会把更正式、规格驱动的工作流编码成一个 智能体 Skill；另一些团队则定义能够生成更轻量计划的 Skills，使其能随工作推进而演变。由于计划是由 Skills 而不是固定流程来塑造的，这两种方法都能自然融入 Plan Mode。

重点不在于我们的规划方法具备向后兼容性——尽管确实如此——而在于它面向未来。一个基于少量共享原语构建的框架，能让团队在 智能体 承接那些旧式规划从未预见的工作时，有足够空间演进自己的方法。

#展望未来

代理能够处理的工作规模和复杂度正在迅速提升。由于我们在设计 Plan Mode 时基于面向代理的简单原语构建，它能够紧跟这些进展。

我们正在测试这样的代理：可以在同一项目中长时间持续运行（extended runs）、在会话之间保持上下文，并在任务适合并行处理时创建子代理。不久之后，多名开发者将能够加入同一会话，实时查看计划如何演进，并在项目推进过程中引导代理。我们的目标是在保持软件团队一直在规划中所追求的核心要素——清晰性、可见性和用户控制权——的前提下，进一步拓展代理可以完成的工作范围。