A 托管 agent运行在服务商的云端。你把代码仓库的副本和一组凭据交给它，它就在云端开展工作。本地优先 agent则运行在你自己的机器上，运行环境、订阅、文件和密钥都留在本地，离开机器的只有对话内容。
两者都是合理的设计方案。它们将你的代码、身份凭据和账单放在了不同的地方，而一旦你开始与他人共享 agent，这些差异就会变得更加关键。
托管方案的优势与代价
2026 年的具体例子包括 Claude Code on the web 和 OpenAI’s Codex cloud tasks。两者都在服务商的沙箱中针对你代码仓库的克隆运行 agent，并通过 GitHub 的 OAuth 集成向服务商签发 token 来完成 git 认证，因此 agent 永远接触不到你本地的凭据、SSH 密钥或环境变量。这是一项切实的安全特性：开发者笔记本电脑即使被攻破，也不会波及 agent 的环境；而权限范围不当的任务也无法触碰沙箱之外的文件。
托管 agent 始终在线。无需保持笔记本电脑处于唤醒状态，也不需要安装任何东西。对于全天候无人值守的集群来说，这是决定性的优势。
但其代价是结构性的，无法轻易弥合。
- 所有东西都要复制一份。 服务商保存着你的代码仓库，通常还包括你的环境，agent 才能正常工作。这份副本有着独立的访问控制、保留策略和安全泄露受攻击面。
- 第二套凭据。 GitHub、云账户和内部 API 的 token 都要签发给服务商。轮换凭据时，也必须在服务商处同步轮换。
- 第二份账单。 除了现有的订阅，你还要为托管运行环境额外付费，或者甚至完全取代现有订阅。
- 模型选择受制于人。 托管方决定提供哪些模型，以及何时调整它们。
本地优先方案的优势与代价
本地优先 agent 直接使用你机器上已有的东西：你付费订阅的 Claude Code 或 Codex、本地已检出的代码仓库，以及钥匙串中存有的密钥。任何内容都不会被复制到外部。当你共享 agent 时，其他人可以提问；具体工作仍由你的机器完成。
其代价在于可用性。如果机器处于休眠状态，agent 也会沉睡。
缓解措施是工程实操层面的，而非架构性的：将 daemon 注册为系统服务，以便在登录时自动启动并在崩溃后重启；在工作时间内保持机器唤醒；在收件箱中对请求进行排队，确保机器离线时不会遗漏任何内容。机器重新上线后，请求会按顺序执行。
两种设定信任边界的方式：围绕服务商的沙箱，或是围绕自己的机器并将房间置于其外。
云端层可以有多轻薄
muti 是本地优先的，一个关键的设计问题在于：云端被允许保留什么？答案是：房间，以及任何绝不可能让房间冒充机器的数据。
三大机制确保了这一设计的成立。
仅限出站连接。 你机器上的 daemon 通过出站连接轮询工作。无需开放端口，没有隧道，也没有任何入站路径。即便 muti 的云端遭遇入侵，攻击者最多也只能提交排队请求，而这些请求依然受你的权限规则与审批机制管辖；他们根本无法触及你的文件。
传输事件，而非文件。 daemon 仅发出描述发生了什么的时间线事件。它不会上传工作区目录树，也绝不会读取环境变量或密钥文件并将其发送到任何地方。
关键操作人工审批。 因为机器归你所有，针对他人发来的每一项请求，四类危险操作都会暂停并等待你的确认。而持有你凭据的托管 agent 则无人可问。
选型对照表
为什么 muti 不托管运行环境
添加一个“在我们的云端运行”按钮轻而易举。但我们没有这么做，这是一个深思熟虑后明确排除的目标。一旦运行环境发生迁移，凭据和代码仓库也会随之转移，主人将不再是那个把关审批的人。执行前始终需要确认的四类操作中的每一项安全保障，都建立在机器归主人所有的基础之上。
muti 托管房间。你的 agent 始终留在原地。
常见问题
“本地优先”等同于“离线”吗？ 不等同。agent 需要网络连接才能访问其模型服务商，muti 也需要网络来传递消息。本地优先描述的是工作执行和机密凭据保存在何处，而不是机器是否联网。
我可以自己私有化部署 muti 的云端吗？ 房间层的自托管已在路线图规划中，将作为支持离线运行的单人模式提供。daemon 与云端之间目前已经通过标准 API 进行通信。
如果我有多台机器怎么办？ 逐一连接即可。agent 绑定在具体的机器和工作目录上，你可以通过 daemon 上报的地址区分不同的机器。
如果你已经为优秀的 agent 付费并希望将其保留在本地，不妨为它建一个房间。
发布于 · 更新于