当 Agent 开进企业内网：Cursor Self-Hosted Machines 改变了什么？
企业不把整套开发环境搬走，也可以让云端 Agent 进入自己的机器工作。
这听起来像是“远程连接”又多了一种实现。但对本地 Agent 产品而言，更值得注意的变化是：执行地点可以交还企业，组织这次工作的入口和控制循环，却仍然留在平台手里。
2026 年 9 月 2 日，Cursor 发布 Self-Hosted Machines 更新。Cursor 是 Anysphere 的 AI 编程产品；这次变化涉及其 Cloud Agents，而不只是编辑器里的代码补全。更新把个人机器、团队 worker 池、动态容量与休眠恢复放进同一产品方向，并支持 Linux、Mac 上的 computer use。官方发布记录
它没有证明数字员工的未来已经定型，却足以让我们重新审视一个判断：当主流 Agent 平台也能在企业自己的机器上执行，“本地运行”还能单独构成多少差异化？
1. 这不是把整套 Agent 装进企业机房
先看清产品到底移动了哪一部分。
Cursor 的官方说明很直接：Agent 循环、推理与规划仍由 Cursor 云端承担；企业 worker 负责文件编辑、终端命令、computer-use 工具和本地 MCP 服务。MCP 在这里是 Agent 接入工具与数据源的一种接口方式，不代表业务系统已经被正确理解。Self-Hosted Machines 总览
于是，企业机器不再只是开发者手边的一台电脑，也可以成为平台调用的执行位置。平台未必需要拥有那台机器，就能把工具调用送进去，并根据执行结果决定下一步。
理解这个变化，需要把常被统称为“私有化”的几个问题拆开：
| 要问的问题 | 它真正决定什么 |
|---|---|
| 工具在哪里执行？ | 命令、文件操作和内网访问发生在哪个环境 |
| 工作信息流向哪里？ | 哪些代码片段、输出、截图会进入外部推理或存储 |
| 谁控制执行循环？ | 谁接收任务、安排下一步、组织后续交互 |
| 谁认可交付结果？ | 谁拥有授权、验收与业务责任的最终决定 |
一台机器在企业机房里，只回答了第一问，不能自动替后三问作答。
官方文档也没有宣称所有信息都留在内网：完整检出目录、构建缓存和机器本地凭证留在 worker，但 Agent 所需的文件内容、终端输出、差异、截图及 MCP 结果可以回传；部分运行产物还会上传。Privacy Mode 的“不用于训练”，也不能被解释成“不发生传输”。数据流向说明
图 1｜依据官方文档绘制的职责与数据流示意。连接由 worker 主动发起；调用与结果在连接上双向传递。底部列出的是作者的产品问题，不代表已经完成部署、评测或 CodeFlowMu 适配。点击查看高清原图。
这不是贬低方案。它对“工具必须接近内部环境，但允许受控内容参与云端推理”的需求有实际意义。只是另一类要求——例如推理也必须在内网、内容不得外传——不能因为名称里有 Self-Hosted 就被默认满足。
对未来 Agent 产品的判断，也应从部署标签转向这四份具体答案。
2. 真正值得关注的是：机器变成了可分配的工作资源
连接自己的电脑，仍然接近个人工具。团队机器池则开始改变工作组织方式。
在 Cursor 的 Team Pools 中，请求进入指定池，由可用 worker 承接。一次 follow-up 遇到原机器离线时，可以在配置的重连窗口内等待它恢复；但保留工作区需要快照、相同 worker 身份和部署方控制器配合。默认重连窗口为零，不能把“支持休眠恢复”写成“任何机器断开后都无条件接着干”。Team Pools 生命周期与休眠说明
产品意义在于，用户开始选择一类执行条件，而不必永远选择某一台固定机器。
例如，一个团队可能需要带内部构建环境的 worker，另一个任务可能需要 Mac 环境。这是部署场景的举例，不是我们已测得的客户使用数据。关键不在于机器数量，而在于执行资源开始可以按工作需要组织。
从这个结构向前看，使用 Agent 有机会从“在自己电脑里叫一个助手”，发展成“向企业工作系统提交任务，由它分配执行能力”。人提出任务，系统找到合适的环境，执行者暂时占用资源，等待后续时再决定保留还是回收。
但这个方向也带来一个不能省略的区分：可替换机器，不等于可随意替换正在承担责任的执行者。
排队中的新任务可以寻找可用容量；已经运行过一轮的任务，还携带工作区状态、历史动作和当前权限。资源调度解决“哪里可以跑”，不天然解决“换一个执行者以后哪些动作还可以再做”。
这不是在指控 Cursor 已存在重复执行漏洞。本文没有做这样的实验。它是机器池成为常态以后，所有长期运行 Agent 系统都必须解释的产品边界。
3. computer use 的意义，不只是多了一个工具
Cursor 的自托管 worker 可以在受支持的 Linux 或 Mac 桌面上执行点击、输入、截图等操作，人也可以观看并接管桌面。Computer use 与桌面共享
对企业而言，这让 Agent 的可达范围不再完全受限于“有没有现成 API”。一个只有图形界面的工具，也可能成为工作流程的一部分。
但操作界面的覆盖范围，与工作的可信交付能力，并不是同步增长的。
能打开表单，不等于知道应该选哪个组织；能按下提交，不等于拥有提交权限；看到成功页面，也不一定意味着后续业务核对已经完成。这里不是列举 Cursor 的缺陷，而是说明为什么“数字员工”不能只按工具种类计数。
我更看重人能接管这一点。它意味着一个可行的发展方向不必是“尽可能消灭人工介入”，而可以是把介入设计成正常工作环节：机器负责可重复操作，人处理歧义、责任和高影响决定，然后把可继续执行的边界明确交还系统。
这种产品的价值，不只在自动完成了多少步骤，还在于需要人介入时，能否把前因后果交代清楚，而不是只留下一个停住的桌面。
4. 对 CodeFlowMu，不能再只问“它是不是我们的执行工具”
CodeFlowMu 是我们开发的一个本地多 Agent 协作系统。FCoP 是其中组织 TASK、REPORT、REVIEW、EVAL 等工作文件和角色责任的协作约定；它关注的不只是启动一次模型调用，还包括任务如何交接、结果由谁检查、决定凭什么成立。
过去，评价 Cursor 这类平台，很容易只从 Host 角度出发：SDK 能不能接、CLI 是否稳定、模型是否可用。这仍然重要，但已经不完整。
当同一个平台也提供企业执行位置、机器池和人的操作入口时，它就可能进入原本由外围系统承担的工作组织空间。**它既可能是 CodeFlowMu 使用的执行能力，也可能与 CodeFlowMu 在部分用户需求上竞争。**这是基于产品职责的判断，不是市场份额或收入预测。
因此，“我们也能在本地运行”“我们能从手机看任务”“我们有独立工作区”，都需要重新检查其竞争价值。能力依然有用，但有用不等于稀缺，更不等于用户必须为另一套系统承担成本。
我认为 CodeFlowMu 值得验证的方向，不是照着新增菜单再做一遍机器池，而是回答平台外的工作责任能否保持清楚：
第一，执行平台可以换，任务身份能否不跟着碎裂？
一个 TASK 由不同 Agent 或 Host 参与时，交付物、检查记录和责任关系能否继续对齐？这里追求的是工作记录的连续，不是保证把任意平台的会话内部状态无损搬走。后者需要平台支持，不能靠一个统一界面承诺。
第二，Agent 的完成反馈，能否与独立验收分开？
执行者说完成、工具返回成功、检查者认可结果，分别承担什么证明责任？如果 CodeFlowMu 只能把平台的成功提示换一种样式再展示，就没有增加多少交付价值。
第三，企业能否掌握可审计的决定链？
谁授权了动作、适用于哪一版任务、后来为什么暂停或恢复、旁观证据与正式决定如何区分——这些关系应能被复核，而不是只能回到某次聊天里猜测。
这些不是全部已经实现的竞争壁垒。本轮对 V2.2.6 的源码和实验检查确认了部分既有能力，也暴露了 Host 验证完整性及执行 owner 判断的局部缺口。相关两篇文章分别提供受控证据；它们没有证明多 Host 工作迁移已经成熟，更没有证明 CodeFlowMu 天然比平台可靠。本批研究与证据边界
把差异化写成方向容易，把它变成用户可检查的收益才难。
5. 也要承认：不少企业可能不需要再加一层
如果一个团队的主要需求就是在受控环境中完成代码任务，单一平台已经满足权限、审查和交付要求，那么再增加一个跨平台治理系统，可能只会多一套配置、一组状态和一个需要排障的边界。
这是 CodeFlowMu 必须接受的反方，而不是用“企业都需要治理”回避的问题。
Cursor 自己也没有把自托管推荐给所有团队。官方建议在托管方案能满足条件时优先使用托管；选择自托管意味着客户还要承担机器及运维责任。部署选择与成本职责
因此，不宜把发展方向写成“Agent 最终都会搬回企业机房”。更合理的展望是：执行位置会成为可配置条件，企业按网络、环境、责任和成本组合选择；产品竞争则围绕谁能把这种组合变得可用、可信、可持续。
对小团队，减少维护可能比拥有机器更重要；对特殊环境的团队，执行地点可能是硬约束；对跨部门、跨 Agent 平台的工作，长期任务身份和独立验收可能更重要。这是需求划分，不是我们已经取得的市场调研结论。
同样，开放与集成也不是免费优势。多个平台带来不同的会话语义、权限边界和结果格式。如果兼容成本高于替换收益，“支持更多 Host”可能反而让用户更难维护。
所以，是否值得建设某种适配或治理能力，仍应回到真实工作：它减少了什么人工核对？保留了哪段原本会丢失的责任链？发生中断时，是否真的减少误执行或等待？没有这些证据，不应因竞品更新就启动一轮对称开发。
6. 更长远的竞争：谁来组织并认可 Agent 的工作？
这次更新让我更倾向于三个判断。它们是发展展望，不是官方路线承诺。
其一，**执行基础设施可能逐步成为平台标配，而不再是独立 Agent 产品最牢固的卖点。**谁拥有任务入口，就有动力让任务抵达更多客户环境。机器由谁购买，未必决定工作由谁组织。
其二，**长期工作能力会比一次性演示更重要。**一次点击成功容易展示；跨等待、休眠、人工接管和环境变化之后，任务还能否被正确理解和处理，才接近真实岗位的要求。机器池与工作区恢复把这个问题推到了产品前台，但并不意味着所有责任边界已经自动闭合。
其三，**企业保留控制权的重点，可能从“服务器归谁”转向“工作事实与决定能否脱离单个平台被解释”。**如果换一个执行提供商就无法说明旧任务为什么获准、产物谁检查过，企业虽然持有机器，也未必掌握完整的工作连续性。
这些判断是否成立，要继续观察，而不是提前宣布胜负。后续最值得收集的不是又增加了多少工具，而是实际工作负载下的交付成本、人工介入负担、恢复行为，以及任务证据是否能被平台外的人读懂。
本文没有部署 Cursor worker，没有测量机器池成本或恢复成功率，也没有比较双方市场表现。它依据截至 2026 年 9 月 3 日核验的官方发布与文档，提出一个需要认真面对的产品判断：
Cursor 不只是让 Agent 更容易到达企业的机器，也在让企业的机器更容易成为平台的执行资源。
对 CodeFlowMu，值得争取的位置因此不应只是“还能在哪里跑”。而应是：当执行者、机器甚至平台发生变化，企业是否仍能清楚地知道——这是谁的任务，凭什么执行，结果由谁认可。