把 Cursor 云代理的第一份任务限制在一个可验证的修复

把一个可复现的小缺陷交给 Cursor，等它交回供人审查的 PR，是后台代理值得先尝试的用法。适合交出去的任务应当同时满足三项条件：预期行为已经明确，远端环境能够验证，改动范围能由一位负责人读懂。缺少其中一项，先补条件比继续扩写提示更有用。

Cursor 目前把这类产品称为 Cloud Agents，过去叫 Background Agents。它在云端隔离虚拟机里工作，而不是接管你当前的本地工作目录；针对仓库任务，它在独立分支上修改并交接代码。以下以官方文档为依据分析任务选择，示例没有实际运行。

假设项目有一个列表接口：合法的空查询应该返回空数组，却触发异常。团队已经确认正确行为，也有相关测试。这比“把搜索做得更好”适合委派，因为代理可以围绕一个可观察结果查找原因、修改实现并补回归测试，审查者也能判断是否修对。

相同标准适用于补充已知边界条件的测试、修正与现有接口不一致的文档示例，以及范围明确的重复代码整理。但重构还需要已有测试保护外部行为；测试缺失时，先要求梳理调用方和补测试，不要同时要求大规模改结构。

可以把上述修复写成这样的委派要求：

• 复现列表接口处理合法空查询时的异常，先新增一条能在旧实现上失败的回归测试。
• 将该输入的结果修为成功响应和空数组；保留现有错误输入的处理，不改变接口参数或响应结构。
• 只修改相关实现和测试。不升级依赖，不改鉴权、数据库结构或部署配置；如必须越界，先说明原因并停下。
• 运行相关测试及项目已有检查，记录命令、结果和未能执行的项目。交回草稿 PR，说明根因、改动文件、验证证据和剩余风险，不合并。

这是一份分析用任务示例，不是声称存在这些文件或命令的可直接运行脚本。真正委派时，还要补上仓库、基线提交、实际复现输入及项目测试命令。验收时确认新测试确实覆盖原缺陷，不能只看“测试通过”：若代理把断言删了，或者改了测试让错误行为变成预期，绿灯仍然没有意义。

Cursor 的环境文档说明，托管云代理运行在 Ubuntu 上，可以由代理引导配置，也可以使用 Dockerfile 配置。你本地已经装好的工具、未提交文件或私有服务连接，不能因此被当作远端已经具备。先验证依赖能安装、测试能启动、必要服务能连接，再把修复排进去。

仓库及依赖仓库、子模块需要相应读写权限。若任务依赖只在开发者电脑上可用的组件，或测试必须访问尚未授权的内网服务，应先处理环境与权限；不要把安装失败、网络超时写成代码已验证。可以缩小任务，只交付原因分析和建议改动，或者改用能访问所需环境的本地交互式工作方式。

对第一次任务，最好选择不需要生产数据和生产凭据的修复，并使用脱敏样例或测试替身。若无法建立可信的验证环境，这个任务尚不适合无人值守地推进到可合并状态。

Cursor 的文档说明，Cloud Agents 默认有互联网访问能力，并会自动执行终端命令。它能持续运行测试，也可能在读取恶意内容后受提示注入影响。独立分支可以隔开代码改动，却不能收回已经发送到外部的数据；把“最终有人审 PR”当成运行安全边界并不充分。

启动前应限制允许访问的外部目标，并只提供任务所需权限与凭据。官方提供 Runtime Secrets，对工具输出、聊天记录和提交中的值进行遮蔽；但它们仍作为环境变量供程序使用，通过终端与环境交互的用户仍可看到。输出遮蔽不等于凭据没有使用权限，也不能替代对凭据权限范围的限制。

因此，生产数据库迁移、支付或鉴权规则调整、依赖未确定产品决策的大改动，不宜作为第一个无人值守任务。这是按影响范围作出的任务选择建议，并非声称产品无法修改这些代码。先让人确定业务约束与风险，再拆出可以独立验证的小改动。

官方描述的交接流程是推送分支并打开供人审查的 PR，也可以要求草稿。团队应据此明确责任：代理提供改动和证据，负责人决定需求是否满足、风险是否可接受，以及是否合并。不要把代理的完成消息当成合并授权。

审查时，先核对差异是否仍在原范围内，再重跑关键回归与必要的集成检查；检查错误分支、调用方、依赖变更和日志是否暴露数据。无法执行的检查应留在 PR 中，明确由谁补做。若改动不断扩散、反复绕过失败测试，或需要新的业务判断，就退回交互式讨论，重新拆任务。

后台代理的收益取决于交接质量。先选一个不靠生产权限也能复现、结果明确、能够完整审查的小修复；只有环境和审查过程都经得住这一轮，再扩大委派范围。