Cursor 的 Self-Hosted Machines 乍听上去像给企业发了一台虚拟机，实际上是把智能体的手伸回你自己的机房，而大脑继续留在云端。这家 AI 编程公司没有选择把整个 Agent 塞进企业内网，而是做一个干净利落的切割：循环、推理、规划在云上跑，真正碰代码、碰命令、碰环境的动作，全部交给一台由企业自行部署的 worker。这个设计远比“能不能自托管”更有嚼头，它悄悄回答了一个所有用过 AI 编程工具的企业都会问的问题——我凭什么让你直接碰我的生产环境？
云上思考，本地动手
要理解 Self-Hosted Machines，先忘了“远程服务器”这个概念。它不是一个让你租来跑 CI 的云盒子，而是你在自己的网络里替 Cursor 养的“机器人手臂”。Cursor 的云端智能体负责做决策，但决策落地的那一下动作，不是由 Cursor 的服务器发起连接来执行，而是反过来——企业网络里的 worker 主动向外发出 HTTPS 连接，把自己能干活的状态告诉 Cursor 云端。
控制平面与数据平面拆开看
智能体的思考过程需要频繁调用模型、搜索代码库、做多步推理，这部分留在云端意味着 Cursor 可以不断迭代模型而不必要求企业升级任何硬件。但真正的工具执行——读写文件、跑测试、执行构建命令——这些动作会触碰到源码、密钥、内部服务。如果坚持让云端直接连进内网，等于在企业防火墙凿开一个口子。Self-Hosted Machines 把这两个平面彻底拆开了：思考留在控制平面，执行被放回数据平面。
出站连接意味着什么
网络方向上的设计很微妙。worker 发起的连接是出站 HTTPS，而不是让 Cursor 主动连入企业网络。这意味着企业不需要为 Cursor 开放任何入站端口，不需要配置 VPN 反向穿透，更不需要把内网服务暴露给第三方。worker 像是一个只在固定时间段向外打电话的守门人，外面的人永远拨不进来。对网安团队来说，这从一个“被扫描的靶子”变成了“主动订阅服务的端点”，威胁面完全不一样。
哪些环节留在云端
智能体的主循环、上下文压缩、Long Context 管理、工具调用的编排决策仍然放在 Cursor 的云端。也就是说，Agent 的“大脑”没有被空运到企业机房，它只是通过 worker 这个“神经末梢”去感知和改变企业环境。如果 worker 在执行过程中需要更多指令，它会把执行结果通过那条出站连接传回云端，云端再把下一步动作送回 worker。这套机制保证了智能体的连贯性不会因为自托管而被切割成孤岛。
合规审计的压力，逼出了这种半云半本地的姿势
过去一年，AI 编程工具在企业落地的最大障碍不是代码质量，而是安全团队的质问：智能体跑到了哪里？日志存在谁手里？每一步操作是否留痕？Self-Hosted Machines 给的答案很务实：工具执行产生的痕迹可以完整留在企业自己的机器上，Cursor 云只能看到推理所需的那部分上下文。这不是出于对客户的不信任，而是合规审计的逻辑本来就不允许第三方任意进出。
敏感代码不再离域
很多金融、医疗、政府项目的代码库本身就带各种合规标签。即使 Cursor 承诺数据不用于训练，合规部门依然会盯着“代码在传输过程中是否经过外部节点”这类问题。现在，worker 直接在企业内网里拉取代码、执行构建，代码文件不需要上传到 Cursor 的服务器才能被处理。敏感代码的物理位置被锁死在自有边界内，审计时可以理直气壮地写“代码未离开公司网络”。
日志粒度由企业掌握
在云端模式下，智能体执行了什么命令、改动过哪个文件，这些日志默认归服务商管理。自托管之后，worker 产生的执行日志、文件系统变更、命令输出从一开始就落在企业运维手里。你可以选择只把必要的摘要回传云端，也可以把全部操作记录接入自己的 SIEM。这个控制权的转移带来的不只是心理安慰，而是实实在在的监管合规筹码。
按需扩容不再受制于云端队列
另一个被忽略的好处是，自托管 worker 可以像普通计算资源一样被纳入企业的扩缩容体系。Cursor 云端不需要为每个企业任务另外准备沙箱环境，企业自己可以根据项目紧急程度拉起更多 worker。大促前的发布窗口、月末的批量代码重构，这些波峰波谷不再需要跟云端排队时抢资源。机器就是你的，想多用就多开几台。
部署自托管机器，不是照着文档敲命令那么回事
网上很多产品博客会把自托管写成“三步搞定”，但真正落地的团队都知道，难点从来不在安装，而在想清楚工作负载与网络策略的匹配关系。Self-Hosted Machines 听起来很灵活，但部署方式决定了它到底是一个增强协作的工具，还是仅仅给合规部门做样子的花瓶。
单机模式跑通流程，再考虑集群化
最理性切入方式是在一台专用的 Linux 机器或虚拟机里部署第一个 worker，这台机器最好能访问到目标代码仓库，但暂时不接入核心生产网络。先让智能体在一两个非关键项目上跑通全流程，看它到底会发起哪些类型的工具调用，出站的 TLS 连接去向哪些端点。这一步走完，你才真正拥有判断是否扩大规模的依据。别一开始就搞全自动流水线，智能体不是人，它不会给你写事故复盘报告。
网络策略比安装指令更重要
出站 HTTPS 确实避免了入站攻击面，但它不是万能免死金牌。worker 既然有权执行命令，那就等于一个能访问内网资源的半自动化账号。你需要在防火墙上为它划定白名单：能访问哪些代码仓库、能不能连数据库、是否允许通过跳板机触及生产环境。最安全的模型是给 worker 一个最小特权身份——它只拥有执行构建和运行测试所需的权限，而不是让它在整个开发网里裸奔。具体到实际运维中，这种 worker 的运维账号最好跟人类开发者的账号体系隔离，并配上更短周期的密钥轮换。
从团队规模判断启动阈值
并不是所有团队都需要 Self-Hosted Machines。如果你只有五个人做内部工具，代码全部托管在 GitHub，那直接使用 Cursor 的云端沙箱毫无问题。但一旦你的团队突破二十人，代码库开始接到数据服务、内部依赖、遗留系统的构建任务，你就会发现把每个 Agent 任务都放在公共云端沙箱里是一种双重浪费——既浪费下载代码的带宽，又浪费等待上下文上传的时间。通常当智能体需要频繁处理大型仓库、跨模块重构或安全敏感型项目时，自托管的收益才真正显现。
架构启示：控制平面和数据平面分离正在成为 Agent 产品的默认姿势
把 Self-Hosted Machines 视为一个孤立的产品更新，视野就窄了。它背后藏着一个当前业界已经初现端倪的趋势：AI 智能体正在从“集成式 App”走向“分布式基础架构”。像数据库一样，智能体运行也开始区分计算和存储的边界，区分大脑与肢体的部署位置。Cursor 这次更新更像是给行业提供了一个新的参考架构。
不只是将服务器设在客户附近
有人可能觉得，这不就是类似在客户侧放一个边缘节点，减少网络延迟吗？但 Self-Hosted Machines 的定位比边缘计算更重。它不只是让代码靠近数据，而是让工具的执行环境完全归属客户。Cursor 的角色切换成了“远程大脑”，它输出决策，不直接伸手。这个思路如果走通，将来任何云端 Agent 服务都可以设计成一套控制协议加一套可插拔执行器：执行器放在企业本地也好，放在公有云也好，甚至放在一台树莓派上都行。只要 API 协议不变，Agent 就能驱动任何去处。
数据回传策略会成为新的竞争力
一旦执行发生在企业机器上，回传什么数据、回传多少，就成了产品必须精细设计的问题。Cursor 的回传数据需要让云端足够了解任务上下文，以便完成下一步推理，同时又不能承担过多企业敏感信息。这是一种新的数据引力平衡。优秀的 Agent 产品不再比拼谁拿到更多执行日志，而是比拼谁能用最少的数据完成最高质量的推理。这种能力会逐渐取代单纯的模型参数竞赛，成为企业客户看得见摸得着的差异化体验。
回头看 Self-Hosted Machines，它真正打开的不是一个功能开关，而是一扇基础设施后门。当企业开始在自己机器上运行云端智能体的执行层，整个企业软件供应链的信任边界都跟着变了。Coder 们得到的是对 AI 工作过程的掌控感，安全团队得到的是可审计的物理边界，而 Cursor 自己，则悄悄把产品的纵深延展到了每一个企业的网络机房。如果这波迁移真的发生，今后谈论 AI 编程工具时，不再只是比谁有几亿参数，而是比谁的 Agent 更能安全地渗透到企业的真实工作流里，在那里做出不可替代的实际贡献。
