Cursor客户端解剖（四）Agent三件套：Host、Exec、Worker

系列：Cursor客户端解剖系列学习笔记
上一篇：（三）上下文引擎

为什么不是「一个 Agent 扩展」

如果把编排、跑命令、改文件、常驻工人塞进同一个扩展进程：

• 一处卡住，整条 Agent 链一起死
• 权限模型难做细：编排逻辑和危险执行同命运
• 远程/精简宿主场景更难裁剪依赖

Cursor 的答案是拆成三件套（外加私有推理运行时）：

扩展	激活	一句话
cursor-agent-host	*	编排宿主（控制面）
cursor-agent-exec	*	真正跑工具/命令/文件（执行面）
cursor-agent-worker	onStartupFinished	启动时安装并拉起 worker（工人面）
cursor-local-agent-runtime	*，extensionKind: ui	Private Inference，放在普通 workspace extension host 之外

Host / Exec 的描述原文大意：

• Host：在 AgentExec extension host 里做 orchestration
• Exec：让 Agent run commands、interact with files、use tools，并强调 permissions and approvals

Proposed API：合法要宿主开洞

Host / Exec 都启用了例如：

• cursorAgentHost
• cursorPseudoterminal
• cursorTracing
• cursor

这不是「偷偷调 private API」，而是走 VS Code proposed API 白名单：宿主明确允许这些扩展使用实验能力。cursorPseudoterminal 和终端类工具执行直接相关；cursorTracing 则说明可观测性从第一天就焊在链路上。

Worker 还出现 cursorNoDeps：某些扩展要能在少依赖环境跑（远程/精简宿主）。这是进程放置与裁剪依赖的信号。

控制面 ≠ 执行面

结合任务流（第七篇会展开）：

服务端模型输出 ToolCall
        │
        ▼
agent-host 编排会话 / 协调
        │
        ▼
agent-exec 真正执行（可审批、可 sandbox）
        │
        ▼
结果回传 → 模型继续

Exec 侧能看到 Shell 参数里的 sandbox_policy、skip_approval、timeout_behavior 一类字段——本地执行默认走权限与沙箱策略，不是模型一说就裸跑。

这就是故障域分离的实感：

编排可以重试、可以换模型；执行必须可杀、可审、可限权。

Local Runtime：敏感推理再隔离一层

cursor-local-agent-runtime 的描述非常明确：

Hosts Cursor Private Inference outside workspace extension hosts

extensionKind: ["ui"]，却又不塞进普通 workspace host。含义是：

• 私有推理和项目扩展隔离
• 跟 UI 机绑定（模型跑在你这边时）
• 即使走本地推理，Tool 执行面仍在 Agent Exec

「想」的位置可以云或本地；「做」的位置仍是受控执行环境。

和 Tab 的关系（顺手一提）

内置 cursor-* 目录里没有单独的 Tab 扩展。Tab 这类低延迟补全，更可能沉在 workbench core bundle（services/ai 一带），和 Agent 扩展集群不是同一条激活/隔离故事。

产品上 Tab 与 Agent 目标函数不同；包结构上也是不同落点。本系列后续仍以 Agent 执行链为主——那是 cursor-* 扩展集群最密集的证据区。

小结

Agent 三件套教你的不是类名，而是决策表：

决策问题	Cursor 的常见答案
必须一启动就在？	Host/Exec：*
可以稍晚？	Worker：onStartupFinished
编排与执行是否同进程同命运？	否，拆开
私有推理能否和项目扩展混住？	否，独立 runtime

下一篇回到意图入口：Chat / Composer / Glass / 模式门闩，看「任务从哪进系统」。