Cursor客户端解剖（八）系列总结：真正的护城河
系列：Cursor客户端解剖系列学习笔记
上一篇：（七）一次请求怎么走完
先记住的 7 条精髓
来自对 Cursor 3.13.25 应用包的学习结论：
- 平台继承，能力增量 —— 底座 VS Code；差异堆在 Agent 运行时 + 检索 + MCP + Glass
- AI 是一等公民，但不当唯一进程 —— UI 在 Workbench；执行/索引/MCP/私有推理拆进程
- 按故障域拆扩展 —— Host ≠ Exec ≠ Worker ≠ Retrieval ≠ Local Runtime
- 协议优于硬编码工具表 —— MCP、remote authority、proposed API、强类型 ToolCall
- 隔离写代码 —— Shadow / Worktree，降低直接污染主仓库的风险
- 远程模型复用 Remote-SSH 心智 ——
background-composer是自定义 remote authority - UI 可换壳，服务尽量共用 —— Classic 与 Glass 双轨并存
护城河不太可能只是「哪个模型」
模型可切换、可路由。更难追的是组合：
| 层 | 包内证据 |
|---|---|
| 编辑器级入口 | Fork + Composer/Glass 一等公民 |
| 上下文产品化 | cursor-retrieval + ignore 契约 |
| 编排/执行分离 | agent-host / agent-exec |
| 工具协议 | MCP + protobuf ToolCall |
| 远程同构 | background-composer resolver/socket |
| 可观测 | tracing / ndjson-ingest / fault injection |
| 兼容迁移 | proposed API 白名单 + 扩展替换表 |
一句话：
把 Agent 当成 IDE 操作系统里的一等运行时：
有编排、有隔离执行、有检索边界、有工具协议、有远程管道、有可观测性，
并且尽量站在 VS Code 已经赢过的架构上生长。
可迁移的设计原则清单
做自己的 AI 工具 / IDE / Agent 时，可以逐条打勾：
- 故障域分离：编排 / 执行 / 索引 / 工具 / UI 不同命运
- 协议面优先：工具与传输可替换
- 激活策略显式：启动关键路径 vs 懒加载路径分开
- 权限与边界文件化：ignore、permissions、environment、rules
- 远程同构：后台任务按 remote authority 建模
- 可观测性内建：trace、ingest、fault injection
- UI 双轨可演进：壳可变，内核契约稳
- 兼容层：替换表/迁移路径照顾存量用户
勾不满的地方，就是架构债。
反编译学习的现实边界
| 目标 | 可行性 |
|---|---|
| 理解分层与设计理念 | 高 |
| 阅读小扩展逻辑（已美化） | 中 |
| 还原 Composer/Agent 完整 TS 源码 | 低（无 source map 的巨型 mangle bundle） |
| 绕过授权/破解 | 不做 |
本系列站在第一条：把设计肌肉练出来。
若继续「手搓」
迷你骨架验收标准可以很硬：
- UI 进程只编排展示
- 执行进程可杀死重启
- 检索模块可 mock
- 一种工具协议（可简化 MCP）
- 一种隔离写文件策略
- 一份 permissions 式契约
关掉执行进程，UI 仍在；换一个工具实现，编排代码几乎不用改——这就抄到了精髓。
结束语
写完这个系列，我更确信：
体感强，往往不是因为某一刻的模型更神，
而是客户端把「该看的代码、能做的动作、可崩的边界」安排对了。
模型是引擎；Cursor 客户端展示的是变速箱、底盘和仪表盘怎么配。
引擎可以换，底盘哲学更值得学。