摘要： Cursor 动态 Worker Pool 可以把等待中的 Cloud Agent 请求路由到企业自管的短命 Worker，并借助 E2B Sandbox 或 Vercel Sandbox 实现“一次任务一个隔离环境、按需启动、空闲暂停或销毁、容量归零”。但 E2B 和 Vercel 只承载 Self-hosted Machines 的工具执行：Cursor 仍负责 Agent loop、推理、规划与产品交互。本文基于 Cursor、E2B 和 Vercel 官方资料，拆解 Pool、Controller、Claim、短期 Worker Token、Sandbox、幂等清理和成本模型，并给出企业部署、安全治理、选型与排错方案。
核心结论
Cursor 动态 Worker Pool 的核心价值不是“把 Agent 模型搬到 E2B 或 Vercel”，而是把 Cloud Agent 的终端、文件、测试和工具执行变成可弹性调度的企业计算任务。请求进入持久 Pool 后，Controller 发现并原子认领请求，为它创建一台隔离 Sandbox，启动 Cursor Worker；任务结束后暂停或销毁计算资源。
- E2B 更像开箱即用的 Sandbox 调度方案： 官方
cursor-agents模板包含 Dispatcher，能够监听一个 Cursor Pool，并为每个请求创建独立cursor-agents-workerSandbox。 - Vercel 更像可编程控制面： Vercel Functions、Workflow 与 Sandbox MicroVM 组合成 Controller、耐久工作流和任务级计算平面，适合希望把幂等、重试和清理逻辑写进 TypeScript 项目的团队。
- 两者都要求 Cursor Enterprise： Pool Worker 必须使用 Cursor Service Account API Key；普通用户 Key、团队管理员 Key或组织 Key不能启动Pool Worker。
- Scale-to-zero成立的前提是Pool持久存在： 即使没有在线Worker，Pool仍可注册和被选择；Controller发现待处理请求后再启动容量。
- 安全重点在控制面： Service Account Key应只留在Dispatcher或Workflow控制面；Sandbox只接收短期、用户范围或任务范围的Worker Token，并在任务结束后清理。
先理解：动态Worker Pool不是完整私有化Agent
上一篇 Cursor Self-hosted Machines部署教程 已经说明，Self-hosted Machines 采用混合架构：Cursor 云端运行 Agent loop、模型推理和规划；客户管理的 Worker 负责终端命令、文件编辑、浏览器操作和本地工具调用。动态 Worker Pool 只是把“固定 Worker”进一步改造成“按请求创建的 Worker”。
Cursor 官方把 Team Pool 定义为命名路由目标。请求会在 Pool 中等待，直到可用 Worker Claim。池适合按硬件、团队、仓库或信任边界拆分，例如 gpu、ios、frontend-test 和 restricted-infra。Cursor Team Pools 文档明确指出，Pool 是基础设施所有权选择，不会把 Agent loop 移出 Cursor 云端。
| 组件 | Cursor负责 | 企业/E2B/Vercel负责 |
|---|---|---|
| Agent loop与推理 | 是 | 否 |
| 请求队列与Pool路由 | 是 | Controller轮询或监听 |
| Claim原子分配 | Cursor API | Controller发起调用 |
| Worker创建 | 否 | E2B或Vercel创建Sandbox |
| 代码、终端和测试执行 | 协调工具调用 | 在Sandbox内执行 |
| Service Account Key | 验证控制面 | 必须安全保管 |
| 短期Worker Token | Cursor签发 | 控制面写入Sandbox |
| 资源上限与清理 | 不代管第三方算力 | 企业必须实现 |
| 模型费与平台计算费 | Cursor模型费用 | E2B/Vercel Sandbox费用 |
因此，标题中的“企业 Agent 运行时”应理解为 Agent 的执行运行时，而不是企业自行托管 Cursor 大模型。若合规要求推理、Prompt、代码片段与工具结果全部不离开企业网络，这两种合作方方案也不等于完全本地部署。
动态Pool的完整生命周期
一条可靠的动态 Worker 流水线通常包含七个状态：
- 用户从 Cursor、Slack、GitHub、Linear 或 API 选择目标 Pool 并提交任务。
- 请求进入 Cursor 的待处理队列；Pool 即使零 Worker 仍保持可选。
- Controller列出或监听待处理请求，并为请求计算稳定的
workerId。 - Controller调用 Claim Endpoint，原子认领该请求，避免多个控制器重复执行。
- 控制面创建 E2B Sandbox 或 Vercel MicroVM，写入短期 Worker Token并启动Cursor CLI Worker。
- Worker连接Cursor，克隆或挂载仓库，执行文件、命令、测试与工具调用。
- Agent进入Idle或Archived后，控制面释放Claim，暂停或销毁Sandbox，并记录成本和审计数据。
关键不是能否创建 Sandbox，而是所有步骤都可重试而不产生重复副作用。Vercel 官方指南使用原子 Claim、确定性 Workflow Hook 和确定性 Sandbox 名称，使重试指向同一请求与同一 MicroVM。E2B 的 Dispatcher 则限制最大并发，超出容量的请求继续留在 Cursor 队列。
Cursor Pool的基础配置
部署 E2B 或 Vercel 前，先满足 Cursor 共同要求：
- Cursor Enterprise 计划。
- 团队管理员在 Cloud Agents Dashboard 开启 Self-hosted Machines。
- Cursor Agent-scoped Service Account API Key。
- Worker镜像内安装 Cursor CLI、Git及构建工具。
- 出站HTTPS访问
api2.cursor.sh、api2direct.cursor.sh，如需Artifact还要访问指定S3 Host。 - Pool名称、仓库标签和路由规则保持一致。
Pool Worker不能使用个人用户 Key、Team Admin Key或Organization Key。Service Account Key应进入控制面Secret Store，不得写入镜像、Git、构建日志或Agent可读取的工作目录。
先手动验证一个Pool Worker
在自动扩缩容之前，先用一台受控机器验证账号、网络、Pool和仓库路由：
export CURSOR_API_KEY="YOUR_SERVICE_ACCOUNT_API_KEY"
agent worker \
--pool enterprise-sandbox \
--idle-release-timeout 600 \
debug --json
agent worker \
--pool enterprise-sandbox \
--idle-release-timeout 600 \
start --verbose--idle-release-timeout 600 表示会话结束后保留十分钟空闲窗口，以承接后续消息；Cursor文档给出的默认值为3600秒。动态平台是否应保留十分钟，需要结合Sandbox冷启动、计费粒度和交互模式实测。
注册可缩容到零的Pool
Pool是持久对象，最后一个Worker断开后仍可注册与选择。可以预先通过 API 注册：
curl --request POST \
--url https://api.cursor.com/v0/private-workers/pools \
--header "Authorization: Bearer $CURSOR_SERVICE_ACCOUNT_API_KEY" \
--header "Content-Type: application/json" \
--data '{
"scope": "team",
"poolName": "enterprise-sandbox",
"workerReadyTimeoutSeconds": 0
}'这是 Any-repo Pool 示例。若需要绑定特定仓库，应按官方 API 加入 repoOwner、repoName 和 repoUrl，并让Service Account的仓库范围与过滤条件一致。不要在不理解路由的情况下把敏感仓库交给Any-repo Pool。
E2B方案：Dispatcher＋每请求一个Sandbox
E2B 官方文档提供公共 cursor-agents 模板。它不是普通Worker镜像，而是Dispatcher：监听一个 Cursor Pool，收到请求后创建专用 cursor-agents-worker Sandbox。Cursor在云端运行Agent loop，工具调用在E2B Sandbox执行。E2B Cursor集成文档
E2B前置条件
- E2B API Key。
- 开启Self-hosted Machines的Cursor Enterprise。
- Cursor Service Account API Key。
- 仓库范围的Service Account需要准确Repo URL。
- 私有仓库通常还需要最小范围Git Token。
创建Dispatcher的官方入口为：
e2b sbx create cursor-agents模板启动后会输出一次性Setup UI URL。官方说明该URL十分钟过期，不能分享或留在日志。配置流程为：验证Cursor Service Account、选择或创建Pool、填写E2B Key与区域、设置Worker模板和最大并发，然后配置私有仓库访问并启动Dispatcher。
也可以从E2B SDK创建Dispatcher Sandbox：
import { Sandbox } from "e2b";
const dispatcher = await Sandbox.create("cursor-agents", {
timeoutMs: 60 * 60_000,
domain: process.env.E2B_DOMAIN,
lifecycle: {
onTimeout: "pause",
autoResume: true,
},
});
const { stdout } = await dispatcher.commands.run(
'node /opt/cursor-agents/create-launch-url.mjs "$E2B_DOMAIN"',
{ envs: { E2B_DOMAIN: process.env.E2B_DOMAIN ?? "e2b.app" } },
);
console.log(stdout.trim());这段代码来自E2B集成思路，真正部署时不要把返回的Setup URL写入集中日志。E2B文档列出的域包括默认/美国 e2b.app、欧盟 e2b-juliett.dev 和亚太 e2b-tango.dev；区域选择应结合E2B当前账号能力、Cursor数据流和企业合规统一评估，不能只看Sandbox物理区域。
E2B任务如何运行
- Dispatcher Claim请求并创建
cursor-agents-workerSandbox。 - Worker在
/workspace克隆请求对应仓库并连接Cursor。 - 用户在Cursor查看会话，运维人员可在Dispatcher Dashboard观察Sandbox状态。
- Worker Idle后默认Hibernate，后续消息到来时恢复；关闭休眠时则删除Worker。
官方模板默认最大并发为20，可在Advanced中调整。这个数字不是企业通用推荐值。应该根据账户配额、平均任务时长、并发预算、队列SLO和Git/Registry承载能力设置。如果并发达到上限，新的请求留在Cursor队列，不应通过无限扩容冲击内部服务。
E2B私有仓库安全
E2B Dispatcher通过Egress Proxy提供Git凭据，而不是把Token写进Worker。仍应将Token限制到Pool需要的仓库，GitHub使用 x-access-token 用户名，GitLab使用 oauth2。不要给一个跨组织、长期有效、可管理Webhook和Secrets的PAT。
E2B适合希望快速获得隔离、休眠恢复和现成Dispatcher的团队，但企业仍负责Token范围、Worker模板、允许访问的内网目标、任务输出脱敏及成本上限。
Vercel方案：Functions＋Workflow＋Sandbox MicroVM
Vercel 官方方案将系统拆成两个平面：
- 控制面： Vercel Functions暴露Controller Endpoint，Vercel Workflow使用自适应退避发现Cursor Pool请求，并为每个Claim启动独立子工作流。
- 计算面： Vercel Sandbox从预制Snapshot启动隔离Linux MicroVM，运行任务级Cursor Worker；Worker在空闲宽限期后退出，Sandbox受固定最大时长约束。
Vercel官方教程强调Cursor仍托管Agent Harness与Inference Loop，Vercel Sandbox只提供克隆代码、执行命令、修改文件和运行测试的计算机。
Vercel前置条件与项目初始化
- 有Vercel Sandbox访问权限的Vercel账号。
- 开启Self-hosted Machines的Cursor Enterprise账号。
- Cursor团队管理员创建的Agent-scoped Service Account Key。
- Node.js 22或更高版本。
- Vercel CLI。
pnpm create next-app cursor-sandbox-workers
cd cursor-sandbox-workers
pnpm add @vercel/sandbox workflow
pnpm add -D tsx
mkdir -p lib scripts workflows app/api/cursor-workers/controller随后将Workflow集成到 next.config.ts：
import type { NextConfig } from "next";
import { withWorkflow } from "workflow/next";
const nextConfig: NextConfig = {};
export default withWorkflow(nextConfig);本地开发可通过 vercel link 和 vercel env pull .env.local 获取OIDC环境。生产Secret应在Vercel项目中配置：
CURSOR_SERVICE_ACCOUNT_API_KEY=YOUR_AGENT_SCOPED_SERVICE_ACCOUNT_KEY
CURSOR_POOL_NAME=vercel-sandbox
CURSOR_WORKER_SNAPSHOT_ID=YOUR_SNAPSHOT_ID官方架构把Service Account Key保留在Functions和Workflow控制面，仅向每个MicroVM写入Cursor签发的一小时Worker Token。这个分离非常重要：即使Worker被恶意代码读取，也不应获得能够认领整个队列的长期Service Account Key。
构建带Cursor CLI的Snapshot
每次启动再安装CLI会增加冷启动。Vercel方案先创建Sandbox、安装Cursor CLI，然后保存Snapshot：
import { Sandbox } from "@vercel/sandbox";
async function main() {
const sandbox = await Sandbox.create({
image: "vercel/sandbox/universal:latest",
timeout: 10 * 60 * 1000,
});
const install = await sandbox.runCommand({
cmd: "bash",
args: [
"-lc",
"curl https://cursor.com/install -fsS | bash && " +
"mkdir -p /vercel/sandbox/workspace",
],
});
if (install.exitCode !== 0) throw new Error("Cursor install failed");
const snapshot = await sandbox.snapshot({ expiration: 0 });
console.log(`CURSOR_WORKER_SNAPSHOT_ID=${snapshot.snapshotId}`);
}
main();企业供应链不应长期依赖未固定版本的 latest 和 curl | bash。建议在验证官方流程后，将基础镜像、Cursor CLI与依赖固定版本并记录摘要，定期重建Snapshot、扫描漏洞并保留回滚版本。
Claim、幂等与Worker Token
动态运行时最怕重复创建。推荐用请求ID计算确定性Worker ID和Sandbox Name：
const normalize = (id: string) =>
id.toLowerCase().replace(/[^a-z0-9-]/g, "-");
const workerIdFor = (requestId: string) =>
`pw_${normalize(requestId)}`.slice(0, 63);
const sandboxNameFor = (requestId: string) =>
`cursor-${normalize(requestId)}`.slice(0, 63);Controller先调用Cursor Claim Endpoint。Claim成功才创建Sandbox；如果请求已被另一个Controller Claim，就停止当前分支。Vercel指南进一步使用 Sandbox.getOrCreate 和文件锁，避免重试在同一MicroVM中启动两个Worker进程。
短期Token写入权限为 0600 的文件，再通过 --auth-token-file 传给Worker，比放在命令行参数中更安全。任务结束后要删除Token文件并销毁非持久Sandbox。
E2B与Vercel怎么选
两种方案都使用Cursor Self-hosted Pool，真正差异在控制面抽象、生命周期与团队技术栈，而不是模型质量。
| 对比项 | E2B cursor-agents | Vercel Sandbox方案 |
|---|---|---|
| 上手方式 | 公共模板＋Setup UI＋Dispatcher | Next.js＋Functions＋Workflow＋Sandbox SDK |
| 隔离单位 | 每请求独立E2B Sandbox | 每请求独立Linux MicroVM |
| 控制面 | 模板内Dispatcher | 自建Vercel Function和耐久Workflow |
| 空闲策略 | 默认Hibernate并可自动恢复 | Worker空闲退出，Sandbox有最大时长 |
| 并发控制 | Dispatcher Max concurrent workers，默认20 | Controller每Tick上限及Workflow并发策略 |
| 幂等方式 | 模板负责Dispatcher与Worker生命周期 | Claim＋确定性Workflow＋确定性Sandbox名称 |
| 定制难度 | 较低，适合快速试点 | 较高，适合TypeScript平台团队深度定制 |
| 私有Git凭据 | Egress Proxy提供，不写入Worker | 控制面签发/注入短期凭据，需自行设计 |
| 区域选项 | E2B文档列出US/EU/APAC Domain | 以Vercel Sandbox当前区域能力为准 |
| 适合团队 | 想快速获得Agent Sandbox运行时 | 已使用Vercel并重视Workflow编排的团队 |
如果企业已有 Kubernetes、AWS Lambda MicroVM 或 Cloudflare Containers，也不必为了标题中的两家平台迁移。Cursor同时列出了多种合作方与参考模板，应基于现有云合同、网络、数据边界、冷启动、镜像治理和团队技能选择。Cursor Self-hosted Integrations
企业安全与权限设计
动态Sandbox提升隔离，但不会自动解决所有安全问题。Agent可能读取恶意仓库内容、执行依赖脚本、访问过宽的云凭据，或把敏感终端输出发送给Cursor。因此要同时保护控制面、计算面和数据面。
控制面
- Service Account Key只存在于Dispatcher、Function或Workflow Secret Store。
- Key按团队或仓库范围拆分，禁止所有Pool共享一个超级Key。
- Claim、Mint Token、Release和Delete Sandbox写入审计日志。
- Controller设置最大并发、队列阈值、创建速率和日预算。
- Setup URL、Bearer Token和一次性凭据必须从日志中过滤。
计算面
- 每请求一台短命Sandbox，不在多个不信任任务之间复用工作区。
- Worker使用非Root账号、最小文件权限和精确出站Allowlist。
- 禁止挂载宿主机Docker Socket、生产Kubeconfig和共享Home目录。
- 仓库、缓存、临时凭据与Artifact分开管理。
- 执行超时后先撤销Token，再终止进程和销毁Sandbox。
数据面
- Cursor仍在云端推理，任务所需文件、命令输出、Diff与工具结果可能传输给Cursor。
- E2B/Vercel区域选择不能替代对Cursor模型与数据路径的合规审核。
- Privacy Mode、数据处理协议、子处理者、日志保留和删除机制需要分别核验。
- 生产密钥、个人信息、数据库Dump和未脱敏客户数据不进入Prompt、终端输出或Artifact。
进一步的Agent权限治理可参考 AI Stack Nav 的 企业AI Agent安全教程。
可靠性：Claim只是第一步
Cursor的原子Claim避免两个Controller同时取得同一待处理请求，但它不自动保证后续每一步恰好执行一次。创建Sandbox、克隆仓库、写Token、启动Worker、上传Artifact、释放Claim和销毁资源都可能在中间失败。
建议建立以下状态机：
| 状态 | 可重试操作 | 不可直接重复的操作 |
|---|---|---|
DISCOVERED | 重新列出请求 | 不创建Sandbox |
CLAIMED | 以确定性名称GetOrCreate | 不再次认领成新Worker ID |
PROVISIONING | 检查已有Sandbox和进程锁 | 不无条件再创建第二台 |
CONNECTED | 监控Worker与Agent状态 | 不重复写长期凭据 |
IDLE | 在宽限期内等待Follow-up | 不立即删除仍可能复用的环境 |
CLEANING | 幂等释放Claim和删除Sandbox | 不重复产生账单资源 |
DONE | 只保留审计记录 | 不重启任务 |
清理逻辑要把“404表示Claim已经不存在”视为成功终态，而不是无限重试。Vercel官方指南明确指出，Release Endpoint返回404可能表示Claim已释放、过期或被接管，清理不应继续重试该响应。
监控指标至少包括：
- Pool排队长度与最长等待时间。
- Claim成功率和冲突率。
- Sandbox创建P50/P95时间。
- Worker连接成功率与首次工具调用延迟。
- 平均任务时长、Idle宽限期和恢复次数。
- 每任务CPU、内存、网络、存储和模型费用。
- 超时、取消、清理失败与孤儿Sandbox数量。
- Git Clone、依赖安装、测试和Artifact上传失败率。
成本模型与扩缩容策略
动态Pool能够Scale-to-zero，但不一定天然更便宜。成本由Cursor模型用量、Sandbox运行时长、控制面、快照存储、网络、Git与Registry流量、休眠资源、日志以及平台工程维护共同组成。
单任务真实成本
= Cursor模型与Cloud Agent用量
+ Dispatcher / Function / Workflow控制面成本
+ Sandbox冷启动与实际运行成本
+ Snapshot、缓存、日志与Artifact存储
+ 网络出口和私有连接
+ Idle或Hibernate保留成本
+ 失败重试与孤儿资源成本
+ 人工审核和平台运维成本建议以队列SLO而不是“机器越多越好”制定策略：
- 设
max_concurrency，防止一次突发创建无上限Sandbox。 - 设每次Discovery最大Claim数，给Git和Registry留出容量。
- 对常见任务保留少量Warm Worker，对低频Pool缩容到零。
- 按仓库、团队或风险级别设置独立预算和并发。
- 任务超过最大时长时先请求安全停止，再强制销毁。
- 连续创建失败触发熔断，保留请求在Cursor队列而不是重试风暴。
文章不写死E2B或Vercel价格，因为平台套餐、区域和计费维度可能变化。上线前应根据官方价格页和自己的任务样本实测：冷启动时间、平均运行分钟数、暂停恢复成本、并发峰值和每个成功PR成本。
故障排查
请求一直停在Cursor队列
检查Dispatcher或Controller是否运行、任务Pool名称是否完全一致、Service Account是否有正确范围，以及并发上限是否已满。E2B官方还提示，暂停的Dispatcher不会被Cursor队列自动唤醒，必须保持Dispatcher运行或由外部机制恢复。
E2B无法验证Cursor账号
确认使用的是Enterprise Service Account API Key，而不是个人、Team Admin或Organization Key。若Key绑定仓库，Setup时必须填写完全一致的仓库URL。
私有仓库Clone失败
核对Git Token仓库范围、Provider用户名规则、HTTPS Remote和网络出口。不要通过换成组织级全权限PAT解决；应修复最小范围Token或短期凭据签发。
Vercel重复启动MicroVM
检查Request ID到Worker ID、Workflow ID和Sandbox Name的映射是否确定性；Claim冲突是否停止当前分支；Sandbox启动是否使用GetOrCreate和进程锁。
Worker启动但Agent没有开始执行
检查短期Token是否仍有效、Token文件权限和路径、Pool名、Worker ID、Cursor必要Host出站，以及Worker日志。不要把Token打印到Debug日志。
任务结束后Sandbox没有清理
检查Agent状态轮询、Idle/Archived判定、Workflow超时、Release API和平台Delete调用。对孤儿资源建立定时Reconciler，但只能删除带有本系统标签且超过安全TTL的Sandbox。
Follow-up消息无法恢复旧环境
E2B需确认Hibernate和Auto Resume配置；Vercel需确认Idle宽限期和Sandbox上限是否仍允许复用。对必须保留长状态的任务，应把必要Checkpoint写入受控持久存储，而不是依赖无限延长Sandbox生命周期。
企业上线验收清单
- 已确认Cursor云端仍负责Agent loop、推理和规划。
- Cursor Enterprise、Self-hosted开关和Service Account范围已验证。
- Pool名称、Repo标签和Any-repo/Repo-backed模式已书面定义。
- Service Account Key只存在于控制面，不进入Worker。
- Worker只使用短期Token，文件权限、TTL和撤销流程可验证。
- 每请求使用独立Sandbox，任务结束后能可靠暂停或销毁。
- Claim、创建、启动、Release和清理均具备幂等策略。
- 最大并发、每次Claim数、队列SLO和日预算已配置。
- Git Token、Registry Token和内网权限遵循最小权限。
- 生产数据库、发布、删除和权限修改必须人工审批。
- Worker镜像和Snapshot固定版本、扫描漏洞并可回滚。
- 日志与Artifact不包含密钥、客户数据和完整敏感源码。
- 已测试断网、Token过期、Clone失败、创建超时和清理失败。
- 已监控队列、启动延迟、失败率、孤儿Sandbox和每PR成本。
- 已用非生产仓库灰度，再按Pool逐步扩展。
通过这些验收后，动态Worker Pool才算企业运行时；仅能自动创建Sandbox，还不足以承担持续的Agent生产任务。
事实依据与来源
- Cursor官方事实： Team Pool是持久命名路由目标，请求等待Worker Claim；Pool不把推理移出Cursor云端。
- Cursor官方事实： 合作方指南包括E2B与Vercel；所有接入都需要Enterprise、Service Account Key、必要出站HTTPS和Pool/Label路由。
- E2B官方事实：
cursor-agentsDispatcher监听一个Pool，为每个请求创建独立Worker Sandbox；默认最大并发20，Idle Worker默认可Hibernate和恢复。 - Vercel官方事实： Functions与Workflow构成控制面，Sandbox MicroVM构成计算面；Pool可零Worker保留，Claim、确定性Workflow和Sandbox命名用于幂等。
- Vercel官方事实： Service Account Key保留在控制面，只向MicroVM发送Cursor签发的一小时Worker Token。
- 实施建议： 状态机、Pool信任分级、熔断、监控指标、镜像加固与上线清单属于本文工程建议，不代表Cursor、E2B或Vercel默认配置。
- 尚待实测： 冷启动、并发吞吐、暂停恢复体验、每成功PR成本及企业内网兼容性必须使用真实任务测量，本文未虚构Benchmark。
FAQ
Cursor动态Worker Pool是什么？
它是Cursor Team Pool与企业控制器组合的弹性执行架构。请求进入持久Pool，Controller按需Claim请求并创建Worker Sandbox，任务结束后暂停或销毁计算资源。Cursor仍负责模型推理和Agent编排。
E2B或Vercel会托管Cursor模型吗？
不会。两者托管的是运行Cursor Worker的Sandbox或MicroVM，用于代码、终端、测试和工具执行；Agent Harness、Inference Loop和规划仍由Cursor云端负责。
使用E2B或Vercel需要什么Cursor套餐？
官方指南要求Cursor Enterprise并开启Self-hosted Machines。Pool Worker必须使用Agent-scoped Service Account API Key，个人或管理员类型Key不能替代。
动态Pool可以真正缩容到零吗？
可以。Cursor Pool在没有在线Worker时仍保持注册和可选，Controller发现请求后再启动Sandbox。但Controller本身、Dispatcher或发现Workflow仍需要可运行，E2B暂停的Dispatcher不会被Cursor队列自动唤醒。
E2B和Vercel哪个更适合快速上线？
通常E2B公共模板更适合快速试点，因为Dispatcher和Worker模板已经封装；Vercel适合已有Next.js、Functions和Workflow经验，希望深度控制Claim、幂等、生命周期与观测的团队。
Service Account Key可以放进Worker吗？
不建议。它能访问Pool控制API，泄露影响大。正确模式是只保留在控制面，用它签发短期Worker Token，并把短期Token以受限文件形式交给单个Sandbox。
如何避免重复创建Sandbox？
先原子Claim请求，再用Request ID生成确定性Worker ID、Workflow ID和Sandbox Name，使用GetOrCreate与进程锁，并让Release和Delete操作具备幂等语义。
动态Sandbox一定比固定Worker便宜吗？
不一定。低利用率场景可能受益于Scale-to-zero，高频任务则可能被冷启动、依赖下载、控制面和重复缓存抵消。应按成功任务或成功PR统计模型、Sandbox、网络、存储和运维总成本。
参考来源
- Cursor Docs：Self-hosted Integrations
- Cursor Docs：Team Pools
- Cursor Docs：Self-hosted Machines
- Cursor Docs：Cloud Agents API
- E2B Docs：Run Cursor Self-hosted Machines in E2B
- Vercel：Run Cursor Cloud Agents on Vercel Sandbox
环境配置与 Docker 工作流
适合阅读安装部署、本地配置、服务器搭建和自动化流程类文章后继续转化。
