Cursor SDK 新功能：实时操控运行中的 AI 代理

Cursor SDK 推出了一项新能力：开发者可以在代理（agent）运行过程中实时介入，通过 run.steer() 方法将消息注入下一轮对话。这意味着 AI 编程代理不再是一个“黑盒”——你可以随时调整它的方向，而不用等它跑完再重来。

从“提交后等待”到“边跑边调”

传统的代理调用模式是线性的：传入任务，等待结果。如果中途发现问题，只能中断或等它结束。run.steer() 改变了这个流程——它把一条新消息插入代理的下一个 turn（轮次），让代理在继续执行时自然吸收你的指令。从官方描述看，这不是简单的暂停加编辑，而是对代理执行流的轻量干预。

这种设计对需要长时间运行的编码任务尤其有意义。比如让代理重构一个模块，跑到一半你发现它选错了文件，过去只能终止，现在可以在下一轮直接告诉它“换到另一个路径”。

代理（agent）的“轮次（turn）” 是理解 run.steer() 的关键概念。在基于大语言模型的代理系统中，一次任务通常被拆解为多个轮次：每一轮代理会接收当前上下文（包括用户指令、历史消息、工具调用结果等），由模型生成下一步动作（如调用工具、输出文本），然后执行该动作并将结果反馈回上下文，进入下一轮。run.steer() 插入消息的位置正是这个轮次边界——它不会打断正在执行的那一轮（例如一次正在进行的文件读写或代码搜索），而是在代理完成当前轮、准备生成下一轮动作之前，把新消息追加到上下文中。这种机制类似于在对话中“插话”，代理在下一轮决策时会同时看到原有计划和你的新指令。由于插入发生在边界而非执行中途，代理的核心循环逻辑无需修改，这也是该 API 保持低侵入性的技术原因。

子代理自动后台化

另一个值得关注的细节是子代理（subagent）的处理方式。当你在主流程中执行 steer 操作时，如果某个子代理正处在任务中，它会被自动移到后台继续工作，而不是被强制打断。

这个行为背后是一个实用的权衡：子代理往往承担独立的子任务（比如搜索代码、生成测试），强行终止会浪费已经完成的部分。让它在后台跑完，既保住了进度，也让主流程的 steer 指令不被阻塞。

子代理（subagent） 是代理系统中常见的分层设计：主代理负责规划与协调，遇到可独立完成的子任务时，会派生一个子代理去执行，例如搜索代码库、运行测试、生成文档等。子代理拥有自己的上下文和执行轮次，完成后将结果返回给主代理。这种模式的好处是隔离复杂度、并行处理，但也带来生命周期管理问题——当主流程需要改变方向时，正在运行的子代理该如何处理？强制终止会丢失其已完成的中间成果，放任不管则可能阻塞主流程。Cursor SDK 选择将子代理“后台化”：主流程继续接收 steer 指令并推进，子代理在后台跑完后结果仍可被采纳或忽略。这实际上是一种乐观并发策略，把“是否浪费”的判断推迟到子代理完成之后，而不是在 steer 发生的瞬间武断地杀掉它。

对 AI 编程工作流的影响

实时 steer 能力让“人机协作”更接近结对编程的节奏。你不需要在任务开始前把需求想得完美无缺，而是在过程中逐步校准。

从 API 设计角度看，run.steer() 是一个低侵入的接口——不改变代理的核心执行逻辑，只在轮次边界插入消息。这种设计降低了使用门槛，也保留了代理自主决策的空间。至于 steer 消息与代理原有计划的冲突如何解决，官方描述没有展开，实际效果需要开发者自行验证。

小结

Cursor SDK 的 run.steer() 把“运行时干预”变成了一个 API 调用。配合子代理后台化策略，它试图解决代理编程中一个真实痛点：任务越长，一次性交付的风险越高。对于构建 AI 编程工具的团队来说，这是一个值得关注的交互范式。