Cursor 3 实战解析：云端 Agent、安全边界与评测

Cursor 3 的直接结论

Anysphere 在 2026 年 4 月 2 日发布 Cursor 3，它把 IDE 从"以文件为中心、叠加 AI 助手"的形态，改造成一个编码 Agent 控制面。新的工作空间可以协调多个本地与云端会话、跨仓库工作、在本地与远程执行之间交接会话，并把结果带回为 diff、commit 或 PR。编辑器仍然保留，因为调查、调试和精确修正依旧需要开发者直接操作。

这就是"Cursor 3 是什么"最有用的答案。它不能证明自治 Agent 会让每位开发者在每种任务上都更快，也不能证明生成的改动已经可合并，更不能证明隔离虚拟机消除了模型自主选择命令所带来的安全风险。这些结论必须在你的仓库、控制措施和审查流程中实测。

因此，本文不做功能清单，而把 Cursor 3 当作一套工程系统来分析。你将掌握：

• 工作空间、Agent Runtime、仓库与审查者的边界分别在哪里；
• 本地到云端的交接和并行执行在运维层面改变了什么；
• Rules、代码智能、浏览器、插件、MCP 与 Hooks 如何组成上下文；
• Cursor 当前文档对数据、Secret、保留期限和网络访问有哪些说明；
• 如何跑两周试点，并以"可合并成果"作为扩大使用范围的门禁。

如果你还不熟悉 Agent 的执行机制，可以先读 Agent Loop：架构、恢复与生产评测。

控制面、执行面与证据面

"Agent-first"只有落实到架构边界才有意义。团队实际上在操作三个平面：

控制面是开发者启动、观察和纠正会话的工作空间；执行面是实际运行命令与工具的开发者电脑或隔离云端 VM；证据面则是用于判断工作能否验收的 diff、提交历史、测试输出、产物、远程桌面和 PR。

这个区分能避免一种常见误判：流畅的 Agent 对话属于控制面输出，并不是仓库正确性的证据。批准改动应依赖证据面与常规工程控制。

统一工作空间改变了什么

工作空间把本地与云端 Agent 放在同一处，并支持跨多个仓库工作。当任务横跨 API、客户端和公共 Schema，或开发者想把耗时迁移派发到远端、同时继续本地开发时，这种统一视图很实用。

瓶颈也随之转移：敲代码可能更便宜，但任务定义、冲突治理、审查与恢复更重要。无法陈述验收标准、无法复现环境的团队，放大的会是歧义，而不是交付能力。

本地与云端 Agent 属于不同信任区

本地会话继承开发者电脑上的文件、网络路由、凭证和已安装工具；Cloud Agent 获得的是为该次远程运行选择的环境与凭证。会话可以在两者之间交接，但两边的权限不应被默认视为等价。

应使用显式交接契约：

云端交接不能悄悄放大权限。如果本地会话能查询生产环境，不要为了方便就把同一凭证复制到远程环境；应创建受限测试身份，或从任务中移除该能力。

Cursor Cloud Agent 如何运行

Cursor 已将 Background Agents 更名为 Cloud Agents。根据当前官方文档，每次运行使用隔离虚拟机，可以操作一个或多个仓库、执行终端命令、使用支持的 MCP Server 与 Hooks，并通过 Artifacts 或远程桌面提供检查证据。

典型生命周期如下：

1. 开发者选择仓库、基线版本与任务。
2. Cursor 创建或恢复一个隔离环境。
3. Agent 获得仓库上下文和已配置能力。
4. Agent 修改文件并调用命令或工具。
5. Agent 通过会话与 Git 工作流报告证据。
6. 人工与 CI 决定结果是否可以继续流转。

VM 是执行隔离边界，不是正确性边界。它可以避免一个任务直接改坏另一个任务的文件系统，却无法阻止 VM 内代码对外请求、泄漏已注入的 Secret、修改错误文件，或执行来自仓库内容的恶意指令。

三种环境搭建策略

Cursor 文档提供三种 Cloud Agent 环境准备方式：

可以先用 Agent 自主搭建发现前置条件，再把稳定步骤固化；只有明确快照刷新负责人和失效条件后才使用 Snapshot。不要照抄第三方文章中自创的配置 Schema，必须以 Cursor 当前环境文档校验文件。

并行 Agent 必须划分冲突域

只有当任务足够独立、结果容易集成时，并行 Agent 才能缩短墙钟时间。十个 Agent 同时修改一个包、锁文件、数据库迁移序列或生成客户端，带来的协调成本可能高于并行收益。

派发前定义冲突域：

• 仓库与基线 SHA；
• 各自拥有的目录或接口；
• Schema 与生成代码的所有权；
• 禁止修改的文件；
• 依赖与迁移的协调方式；
• 预期集成顺序。

优先并行只读调查、独立测试、文档、隔离适配器和边界清晰的模块。共享 Schema、鉴权中间件、依赖清单、构建系统和迁移应串行处理，除非其中一个任务被明确指定为集成负责人。

吞吐量要在合并结果层面计算：

有效吞吐量 =
  已验收任务数
  /（Agent 运行 + 人工审查 + 冲突解决 + 故障恢复时间）

统计并发会话数或生成代码行数，只是在奖励活动量，不是交付。

上下文是一条供应链

Cursor Agent 并不只依赖 Prompt 推理。它的上下文还可能包含仓库文件、语言服务器信息、历史会话状态、浏览器页面、插件能力、MCP 返回、Hook 输出、终端结果与项目规则。每种来源有不同的所有者和信任等级。

应把上下文当作供应链管理：

一个符合 JSON Schema 的 MCP 返回仍可能包含恶意指令或错误数据。Schema 校验只能证明形状合法，不能证明内容可信。协议层边界可继续阅读 MCP：架构与安全边界。

Cursor Rules 提升一致性，但不提供权限

Cursor 支持 .cursor/rules/*.mdc 项目规则，也可以读取 AGENTS.md。这类文件适合承载长期约定：构建命令、架构边界、测试要求、审查清单，以及需要特殊处理的路径。

有用的规则应短而且可验证：

---
description: API change contract
globs: services/api/**/*.go
alwaysApply: false
---

- Preserve backward compatibility for public JSON fields.
- Run `go test ./services/api/...`.
- Do not modify generated clients directly.
- Report changed endpoints and migration requirements in the final summary.

规则应指向可执行检查，不要重复整本手册。"运行这个测试并报告证据"强于"写高质量代码"。

但规则仍然只是 Prompt 上下文，无法强制租户隔离、限制网络出口、保护分支或阻止 Secret 泄漏。不可妥协的控制应放在 IAM、仓库权限、CI、网络策略和应用自身。这个区别也是上下文工程的核心。

安全与数据边界

Cloud Agent 会在云端执行终端命令，而且设计目标就是减少同步监督，因此 Cursor 的安全文档不是采购附件，而是产品能力的一部分。

截至 2026 年 10 月 1 日，官方文档所描述的边界可概括为：

云端控制与保留条款会演进，采购或上线前必须再次核对。最终依据是 Cursor 当前安全文档和已签署合同。

Prompt Injection 攻击路径

一条现实的故障链是：

不可信 Issue、依赖、网页或仓库文件
  -> 指令进入 Agent 上下文
  -> Agent 选择终端或 MCP 动作
  -> 环境存在宽权限 Secret 或网络访问
  -> 数据或权限越过预期边界

逐段削弱这条链：

1. 标记不可信输入，禁止其重新定义任务。
2. 从常规环境移除生产凭证。
3. 分离构建期与运行期 Secret。
4. 在支持时使用 OIDC 等短期身份。
5. 只允许访问必要域名。
6. 高影响工具必须经人工批准。
7. 对暴露凭证进行轮换，并保留事件证据。

完整威胁模型可参考 Prompt Injection：威胁模型与防御。

审查改动，不要审查表演

Cursor 可以提供 diff、commit、PR、Artifacts、日志和远程桌面。这些只是证据载体，只有与待证明结论绑定后才有价值：

不要接受没有命令、版本和范围的"测试通过"；不要把截图当作数据完整性证据；也不要因为 diff 很干净，就认定未修改文件一定不需要调整。

保留正常的分支保护和 CI 路径。Agent 可以准备 commit 或 PR，但不能自己给自己授予例外、批准自己的高风险改动，或削弱评判它的检查。

独立证据说明了什么，又没有说明什么

编码 Agent 的效率结论高度依赖工具代际、任务选择、仓库熟悉度，以及统计时是否包含审查与返工。

METR 在 2025 年完成了一项随机对照试验，覆盖 16 位熟悉目标仓库的开源开发者和 246 个任务，使用的是 2025 年早期工具。参与者预期 AI 会加快工作，但实测结果约为慢 19%。METR 现在明确提示：这只说明当时工具与实验条件，不能直接当作当前 Agent 的永久效率估计。

METR 在 2026 年 2 月的更新中解释，后续观察实验存在严重选择偏差：开发者可以自行决定什么时候使用 AI，导致使用与不使用 AI 的任务不再可比，无法可靠估计当前提升。这个案例说明，仪表盘里"用了 AI 的任务更快"不等于因果关系。

2026 年 3 月，METR 让维护者复核 296 个 Agent PR，关联三个仓库中的 95 个 Issue。自动 Grader 对这些改动的平均评分，比维护者实际合并决策高约 24.2 个百分点。样本只覆盖三个仓库，而且 Agent 没有获得人类贡献者通常能得到的迭代反馈，因此不能外推为普遍拒绝率；但它足以证明，Benchmark 通过与可合并是两种不同结果。

站得住的结论既不是"Agent 一定让开发者变慢"，也不是"现在的 Agent 肯定更快"，而是：用代表性任务评测当前工具，把审查和返工计入，并保留任务选择信息。

两周 Cursor 3 试点方案

把试点当作边界明确的工程实验，而不是一次全员 License 推广。

1. 建立任务集

在分配工具前，选择最近 24 至 40 个任务：

• 30% 为低风险、规格清楚的维护；
• 40% 为普通功能或测试工作；
• 20% 为跨模块或有歧义的调试；
• 10% 为安全、迁移或其他高后果任务，初期只观察、不授权执行。

记录预估难度、仓库、任务类型和开发者熟悉度。除非团队平时交付的就是玩具任务，否则不要用玩具项目替代真实工作。

2. 冻结验收契约

每个任务提前定义：

• 可观察的预期行为；
• 测试与静态检查；
• 允许范围与禁止改动；
• 必须提交的证据；
• 回滚或失败处理；
• 谁做最终验收决策。

必须在 Agent 运行前完成。看到结果后再移动标准，会让评测失去解释力。

3. 比较工作流结果

可以使用近期同类任务建立基线，或把符合条件的任务随机分配到现有工作流与 Cursor 辅助工作流。开发者主动拒绝使用 Agent 的任务也要保留，因为选择信号本身就是结果的一部分。

跟踪以下指标：

按任务类别报告中位数和尾部值。单一平均数会隐藏昂贵失败。

4. 从窄权限开始

使用测试数据、只读外部系统、短期身份、域名 Allowlist、受保护分支和人工合并。只有任务集证明某项能力确实必要后，才逐项增加。

5. 扩大前先做决策

试验前约定阈值。例如：零策略违规、回归率不升高、无需大改验收率至少 75%、P95 周期低于团队目标，而且目标任务类别的每个验收任务总成本下降。

可运行的 Go 评测门禁

下面的程序读取经过独立审查的任务记录；只要试点未达到阈值，就让门禁失败。它刻意评测被验收的工作，而不是 Agent 的自我汇报。

package main

import (
	"encoding/json"
	"fmt"
	"os"
	"sort"
)

type Record struct {
	TaskID           string  `json:"task_id"`
	Accepted         bool    `json:"accepted"`
	DurationMS       int64   `json:"duration_ms"`
	CostUSD          float64 `json:"cost_usd"`
	PolicyViolations int     `json:"policy_violations"`
	ReviewerMinutes  float64 `json:"reviewer_minutes"`
}

type Report struct {
	Tasks                      int     `json:"tasks"`
	AcceptanceRate             float64 `json:"acceptance_rate"`
	P95DurationMS              int64   `json:"p95_duration_ms"`
	CostPerAcceptedTaskUSD     float64 `json:"cost_per_accepted_task_usd"`
	ReviewerMinutesPerAccepted float64 `json:"reviewer_minutes_per_accepted"`
	PolicyViolations           int     `json:"policy_violations"`
	Passed                     bool    `json:"passed"`
}

func main() {
	if len(os.Args) != 2 {
		fail("usage: go run gate.go records.json")
	}

	file, err := os.Open(os.Args[1])
	if err != nil {
		fail(err.Error())
	}
	defer file.Close()

	var records []Record
	if err := json.NewDecoder(file).Decode(&records); err != nil {
		fail(err.Error())
	}
	if len(records) == 0 {
		fail("records must not be empty")
	}

	latencies := make([]int64, 0, len(records))
	accepted := 0
	violations := 0
	totalCost := 0.0
	totalReviewMinutes := 0.0

	for _, record := range records {
		if record.DurationMS < 0 || record.CostUSD < 0 || record.ReviewerMinutes < 0 {
			fail("duration, cost, and reviewer minutes must be non-negative")
		}
		latencies = append(latencies, record.DurationMS)
		totalCost += record.CostUSD
		totalReviewMinutes += record.ReviewerMinutes
		violations += record.PolicyViolations
		if record.Accepted {
			accepted++
		}
	}

	sort.Slice(latencies, func(i, j int) bool {
		return latencies[i] < latencies[j]
	})
	p95Index := (95*len(latencies)+99)/100 - 1

	report := Report{
		Tasks:            len(records),
		AcceptanceRate:   float64(accepted) / float64(len(records)),
		P95DurationMS:    latencies[p95Index],
		PolicyViolations: violations,
	}
	if accepted > 0 {
		report.CostPerAcceptedTaskUSD = totalCost / float64(accepted)
		report.ReviewerMinutesPerAccepted = totalReviewMinutes / float64(accepted)
	}

	report.Passed = accepted > 0 &&
		report.AcceptanceRate >= 0.75 &&
		report.P95DurationMS <= 900_000 &&
		report.CostPerAcceptedTaskUSD <= 3.00 &&
		report.ReviewerMinutesPerAccepted <= 20 &&
		report.PolicyViolations == 0

	output, err := json.MarshalIndent(report, "", "  ")
	if err != nil {
		fail(err.Error())
	}
	fmt.Println(string(output))
	if !report.Passed {
		os.Exit(1)
	}
}

func fail(message string) {
	fmt.Fprintln(os.Stderr, message)
	os.Exit(2)
}

实际阈值应匹配你的服务等级与风险。保留原始记录、抽样规则、基线、评测人身份、Cursor 版本、模型策略和环境版本，结果才可复现。若使用模型辅助判断主观输出，应按 LLM-as-a-Judge 方法用人工标签校准，并为确定性需求保留确定性检查。

生产推广门禁

从试点到日常使用应逐级扩大：

每个阶段都保持六条不变量：

1. 任务有具名人类负责人。
2. 环境能从已知版本复现。
3. Secret 按范围授权、尽量短期有效，且不存入 Rules 或仓库配置。
4. Agent 无法绕过评判其输出的检查。
5. 失败运行可以停止、检查并在状态明确的前提下恢复。
6. 会话与 Snapshot 的删除计划有负责人。

常见失败模式

优化生成量

更多 Token、文件或并发 Agent 可能只会增加审查负担。应优化验收结果和端到端交付时间。

把 VM 当作 Secret 沙箱

VM 间隔离不能阻止命令沿允许的网络路径发送 Secret。凭证权限和出网范围必须分别约束。

把本地权限原样复制到云端

开发者完整凭证通常远超单个任务所需。应签发任务身份，而不是复刻笔记本权限。

只在 Rules 里写策略

规则可能被忽略、被其他上下文挤出，或被错误解释。关键策略必须由确定性系统执行。

并行任务共享隐式状态

共享迁移、生成文件与依赖锁会把并行执行变成合并冲突和语义冲突。派发前先声明所有权。

把 Benchmark 通过率当作合并率

测试 Harness 无法覆盖全部可维护性、产品和运维问题。指标必须包含审查决策与返工。

永久保留所有会话

默认保留不等于记录管理策略。敏感使用前必须明确删除、Legal Hold 与审计要求。

Cursor 3 适合什么团队

当团队具备以下条件时，Cursor 3 值得进入候选：

• 已习惯以 IDE 为中心的工作流；
• 构建可复现，而且自动化检查有实际判别力；
• 能划分任务，并通过 Git 审查改动；
• 能从远程执行或多仓库协调中受益；
• 能建立受限云端身份与数据控制。

如果构建依赖未记录的本地状态、开发者日常持有生产权限、大多数任务依赖隐性领域判断，或审查者本就过载，则应谨慎。Agent 工作空间会放大开发操作系统，但不会替团队补出一个不存在的系统。

与终端优先或平台集成型工具对比时，应使用同一任务集、控制条件和成本定义。我们的 AI 编程工具对比方法说明了如何避开功能数量竞赛。

最终判断

Cursor 3 的长期价值，不在于宣称编辑器已经消失，而在于更明确地区分了分配工作、执行工作与验收工作。本地和云端 Agent 扩大执行方式；文件、LSP、浏览器、插件、MCP、Hooks 和 Rules 扩大上下文；diff、测试、Artifacts 与 PR 则让审查成为可能。

只有当这些界面缩短了"从任务到验收改动"的时间，同时没有削弱安全、也没有把隐藏劳动转嫁给审查者时，系统才真正有价值。用代表性试点、最小权限环境、独立证据和显式发布门禁证明它，比任何演示、模型标签或 Benchmark 标题都更可靠。

来源与延伸阅读

• Cursor 3 官方发布说明：发布日期与 Agent 工作空间范围
• Cursor Cloud Agent 文档：Runtime、环境、集成、Artifacts 与交接
• Cursor Cloud Agent 安全与网络文档：计算、数据、Secret、保留期限与出网边界
• Cursor Rules 文档：.cursor/rules/*.mdc 与 AGENTS.md
• METR：AI 编码效率的更新分析：随机试验范围与后续选择偏差
• METR：许多通过 SWE-bench 的 PR 不会被维护者合并：自动 Grader 与维护者决策差异