Agent 跑代码时总得盯屏？Cursor 让你边走边问进度

你把一个改动丢给 Agent，然后去回消息、看日志、开另一个 PR。五分钟后还是会忍不住切回 IDE：它跑到哪了？是不是又把范围越改越大了？

Cursor 这次加的实时语音聊天，补的不是“打字不够快”这个小问题。它更像是给正在干活的 Agent 接了一根对讲机：你可以直接说要改什么，也可以在它运行时问 diff 改了哪儿、某次运行有没有卡住；它会给出短的语音进度，而不是等全部结束才回一大段文字。官方更新写得很直白：这套能力能在 Agents Window、IDE、网页和 iOS 上使用。

这听着像一个语音功能，实际改变的是人和 Agent 的站位。以前你把任务发出去，基本只有两种姿势：盯着它，或者离开它。现在多了第三种：不守在屏幕前，但仍然保持监督。

它解决的是“等待时丢上下文”

很多长一点的编码任务，真正耗人的不是输入需求，而是中间那段不确定的等待。你不知道它是在下载依赖、跑测试、理解错需求，还是已经改完但停在某个要你拍板的地方。

Cursor 的语音聊天把这段等待拆开了。按官方说明，语音 Agent 会把编程任务交给同一聊天里的 coding agent；工作继续时，你可以问它某个 diff 改了什么、某次运行进展如何，也能搜索历史消息或在多个 worker 之间切换。语音聊天文档还特别说明，这不是早期的听写模式：听写只是把语音塞回输入框，语音聊天则是双向对话。

语音不是替代代码审查，而是把“下指令—看进度—回到 diff”这条链路接得更顺。

这很适合一个具体场景：任务已经拆清楚，只是执行时间稍长。比如你让 Agent 补一组回归测试，或者把一个组件迁到新的接口；你不需要持续盯着每一行输出，但确实想在它走偏时早点发现。

把它想成“后台任务的语音状态页”会比“用嘴写代码”更准确。说一句“把刚才这个改动的范围复述一下”，得到的价值不是少敲了十几个字，而是你还握着任务的方向盘。

还有个细小但重要的变化：过去的 Agent 通知大多是“任务完成，请回来看看”。它把注意力的调度交给人，人得先看见通知、想起上下文、再重新打开对话。语音进度更接近一个可以被打断的事件：你在做别的事，听到“测试失败在某个分支”，就能决定现在切回去，还是让它继续排查。

这不该被理解成要求 Agent 更会聊天。好的播报反而应该短，最好只在状态改变、碰到阻塞或需要选择时出现。否则一个会不停朗读思考过程的工具，只是把终端滚屏搬到了耳机里，照样消耗注意力。Cursor 的更新提到它会给出简短进度和完成后的简要回答，这个取舍是对的。

语音里最该先说清的，不是实现方式

语音很容易让需求变得随口。随口一旦进了 Agent 的上下文，就会变成一串待解释的歧义：改哪个入口？哪些文件不能碰？完成到底长什么样？

所以我更愿意把语音用在已经有边界的任务上。开口前，先把这一小段 brief 说完整：

这次只处理「<功能或文件范围>」。
完成的样子是「<可观察的结果>」。
不要改「<明确禁止的模块或行为>」。
先告诉我准备动哪些文件，再开始执行。
跑完后只汇报：改了什么、测试结果、还剩什么不确定项。

它不是什么万能提示词，只是把人类平时脑内默认、省略掉的验收条件说出来。尤其是第一句的“只处理”，很有用。Agent 的热情通常并不缺，缺的是一条能让它停在正确范围里的线。

接下来不用一直追问。挑三个真正影响决定的问题就够了：

• 现在在做哪一步，和最初范围还一致吗？
• 哪个改动需要我选方案，别替我默默拍板？
• 测试或运行结果是什么，有没有没覆盖到的部分？

这三问比“做完了吗”更有信息量。前者是在管过程，后者往往只能等一个已经很难回头的结果。

第一次用，拿一个可回滚的任务

别把第一次通话交给最复杂的重构。Cursor 的入口也很明确：当 Agent 空闲、聊天输入框为空时，点原本发送按钮位置的波形按钮即可开始；iOS 上还支持用 Siri 发起一段新对话。先挑一个“改错文案、补一个小测试、调整一处交互”之类的任务，最适合判断这条新交互到底会不会让你更省心。

可以把一次通话按三个瞬间来用。开头的十秒，只说目标、范围和完成条件；Agent 开始工作后，不必把语音变成连续直播，等它跑到一个需要确认的点，再问“你准备怎么改？”；收尾时让它按“改了什么、怎么验证、哪些地方没动”复述一次。这样留下的仍是可检查的交接，而不是一段听完就消失的对话。

假设你让它给一个接口补错误分支。中途听到它说正在改调用方，就可以立刻追问：“这会不会改到公开返回字段？如果会，停在 diff 上等我确认。”这不是在给 Agent 添麻烦，恰好是在最便宜的时候把风险拦下来。等它把一堆文件改完再发现范围不对，才是真的麻烦。

这类用法对并行跑多个 worker 的人尤其有价值。Cursor 官方说明支持在不同 worker 之间切换、搜索之前的消息和通话；语音让你少做一次“我刚才把任务交给谁了”的上下文恢复。不过，多 worker 不等于多一份判断力。每个 worker 还是要有自己的目标、禁止项和交付物，别让一段口头补充被所有任务各自理解一遍。

它不会替你完成验收

这里要泼一点冷水。Agent 能用声音播报进度，不等于工作就更可靠；它说“已经完成”，也不等于改动可以合并。语音的优势是降低监督成本，不是把判断权外包。

真正的交接仍要回到可见的 diff、可复现的测试结果，以及人对范围的确认。

有几类事我不会只靠语音交代：涉及删数据、改权限、迁移数据库、碰生产配置，或者需求里有一堆专有名词和精确字段。它们值得坐回屏幕前，把文件、参数和成功条件写下来。Cursor 提供的隐私模式与零数据保留选项也只能覆盖它声明的语音数据处理方式；能否把项目材料说进麦克风，仍要看团队自身的权限和数据规则。

另一个容易被忽略的点是：进度播报只能告诉你它“觉得自己在做什么”。真正能让你放心的，还是 diff、测试输出、预览结果和可回滚的提交。语音适合把你带到该看的位置，不能替你看完。

要不要打开它？先看任务是不是处在“可监督区”

如果你常在多个任务之间切换，或者 Agent 跑一次测试就要几分钟，值得试试。尤其在走路、做简单整理、等 CI 的间隙，能口头问一句进展，比反复把注意力切回 IDE 轻松得多。

但如果你现在的问题是需求没讲清、任务没拆开、Agent 经常越权改东西，先别急着加语音。把任务边界、暂停点和验收命令补上，收益会更大。对讲机能让协作更顺，不能替一个混乱的任务计划收拾残局。

Cursor 这次更新最有意思的地方，也在这里：当 Agent 的执行时间越来越长，交互入口不该只剩一个聊天框。人不必一直坐在屏幕前，但该问的、该停的、该验的，还是要自己做。

你会把语音先用在“催进度”，还是“临时补充任务边界”上？