Devin、Cursor与Codex Cloud云端Agent架构解析

云端Agent正在重塑开发者的工作方式。Devin、Cursor Cloud、Codex Cloud这些平台让你在浏览器里就能指挥一个AI工程师完成编码任务，但你有没有想过，它们底层是怎么运转的？一位YouTube技术创作者用一张完整的架构图拆解了这类系统的设计逻辑，从GitHub授权到沙箱隔离，再到Agent与沙箱的通信机制。

云端Agent到底是什么

据该视频的分析，云端Agent本质上是Lovable的进阶形态。Lovable提供的是React模板和有限的前端部署能力，而Devin、Cursor Cloud、Codex Cloud则面向任意仓库、任意技术栈，甚至能处理后端项目。

它们共同的特征是：用户不需要管理任何VM或后端基础设施，平台帮你搞定Agent运行环境，你只需要通过UI交互。视频作者将此定义为"Cloud Agent"——你既可以在本地CLI运行Agent，也可以把它丢到云端的VM上跑。

GitHub接入：为什么必须用GitHub App而非PAT

搭建云端Agent平台的第一步是解决GitHub授权问题。用户需要给Agent访问仓库的权限，这样Agent才能clone代码、提交commit、发起PR。

视频中详细对比了两种方案：Personal Access Token（PAT）和GitHub App。PAT的问题在于它绑定个人账户——如果创建Token的员工离职，整个组织的Agent连接都会失效，需要重新配置。这在多人协作场景下是致命的。

GitHub App则是组织级别的方案。整个组织安装App并选择授权仓库，不依赖任何个人账户。创建GitHub App时，平台会提供一个callback URL，所有事件都会推送到这个URL，后端据此存储仓库访问信息。

这个选择不是可选项，而是生产环境的基本要求。

PAT（Personal Access Token） 是GitHub提供的一种个人访问凭证，用户可以在设置中手动生成，赋予其对特定仓库或整个账户的读写权限。PAT与创建它的个人账户强绑定，有效期可自定义，但本质上代表了该用户的身份。在云端Agent场景中，如果平台要求用户提供PAT来访问仓库，那么一旦该用户离职、账户被禁用或Token被意外撤销，所有依赖此Token的自动化流程都会中断。更严重的是，PAT通常拥有过宽的权限范围（如repo全权限），难以精细化控制到单个仓库，且缺乏组织级别的审计和撤销机制，这在多成员、多仓库的企业环境中是不可接受的风险。

GitHub App 则是GitHub为组织级集成设计的官方方案。它不隶属于任何个人账户，而是以独立实体的形式存在，可以由组织所有者安装并选择授权哪些仓库。GitHub App通过私钥签发JWT，再换取短期的installation token来执行操作，权限粒度可以精确到单个仓库和特定API。当员工离职时，组织的GitHub App安装不受影响，Agent服务持续可用。此外，GitHub App支持webhook事件推送，平台可以实时感知仓库的安装、变更等事件，便于自动化管理。因此，对于面向团队和企业的云端Agent平台，GitHub App是唯一符合生产环境安全与稳定性要求的授权方式。

安装流程与Token管理

用户的安装路径很直接：点击"Connect GitHub"按钮，选择仓库，授权，完成。后端通过callback URL接收GitHub App的创建事件，将相关信息写入数据库，获得仓库访问权限。

接下来是一个容易被忽视但至关重要的细节：沙箱里用什么Token来clone仓库？

答案是installation token，而非GitHub App的私钥。私钥永远不会进入沙箱环境——因为任何登录沙箱的用户都可以通过终端读取环境变量。如果私钥泄露，离职员工仍能保持对仓库的访问。

具体做法是：后端持有GitHub App生成的私钥，用它签发JWT，再换取installation token。这个token有效期仅一小时，且只对指定仓库生效。沙箱使用这个临时token完成clone和其他Git操作，一小时后自动刷新。这是当前的最佳实践。

JWT（JSON Web Token） 是一种开放标准（RFC 7519）的令牌格式，用于在各方之间安全地传输声明。在GitHub App的认证流程中，后端使用App的私钥对JWT进行签名，JWT中包含了签发者（App ID）、签发时间和过期时间等信息。GitHub收到JWT后验证签名，确认请求来自合法的App。JWT的有效期通常很短（不超过10分钟），仅用于换取installation token这一步骤，不会直接用于仓库操作。

Installation Token 是GitHub App在特定组织或用户账户上安装后，通过JWT换取的临时访问令牌。它的核心特点是：有效期严格限制为1小时，权限范围仅限于该次安装所授权的仓库，且可以进一步缩小到特定的API权限（如只读或写入）。在云端Agent架构中，后端负责管理私钥和JWT签发，沙箱环境只接收installation token。即便沙箱被恶意用户攻破，泄露的Token也仅能访问有限仓库，且一小时后自动失效。这种分层令牌设计实现了权限的最小化暴露，是当前业界公认的最佳实践。

任务执行：一个会话一个沙箱

当你给Agent分配任务后，平台会为该会话启动一个全新的沙箱环境。大多数平台使用Docker容器，也有平台分配完整VM。

据视频作者的演示，在Codex Cloud中每个chat thread对应一个独立的Docker容器。这个容器负责clone仓库、注入token、运行Agent。环境是全新的，与之前的会话完全隔离。

Agent运行时，你能在UI上看到它的操作过程，但实际执行发生在云端VM上，不在你的本地电脑。

核心架构：Agent在沙箱外运行

这是整个系统设计中最反直觉的一点：Agent Loop并不运行在沙箱内部。

整体架构包含四个关键组件：前端、后端、Agent、沙箱。前端通过WebSocket连接后端，用户提交任务后，后端同时做两件事——创建沙箱、将任务发送给Agent。Agent和沙箱是分离的。

Agent本质上是LLM加工具集。它通过工具调用来操作沙箱，而不是直接运行在沙箱里。这种分离设计让Agent的生命周期和沙箱的生命周期解耦。

沙箱内部运行的内容包括：代码和依赖（npm install、pip install等）、开发服务器、浏览器（通过WebSocket以视频流形式传输到前端）、Code Server（浏览器中的VS Code）、LSP（语言服务协议，提供类型定义和跳转功能）。

LSP（Language Server Protocol） 是由微软主导的一项开放协议，用于在代码编辑器和语言服务器之间标准化通信。语言服务器提供代码补全、类型定义跳转、错误诊断、重构等智能功能，而编辑器只需实现LSP客户端即可接入任意语言的支持。在云端Agent的沙箱中，LSP服务运行在容器内部，为Code Server（浏览器中的VS Code）提供实时的代码智能提示。当Agent通过工具修改文件时，LSP会重新分析代码并更新诊断信息，确保Agent和用户看到的代码状态一致。将LSP纳入沙箱工具集，意味着Agent不仅能执行命令，还能获得与本地开发几乎相同的代码理解能力，从而在复杂重构、类型检查等任务中表现更可靠。

Pub/Sub通信：Agent与沙箱的桥梁

Agent在沙箱外，工具在沙箱内，两者如何通信？

视频给出的方案是工具队列加结果队列的Pub/Sub机制。Agent将工具调用请求发布到队列中，沙箱订阅这个队列并逐条执行，执行结果再推回结果队列，Agent从结果队列获取反馈。

这个Pub/Sub有三个订阅者：沙箱（执行工具调用）、后端（向前端展示Agent操作）、数据库（持久化操作记录）。

前端除了通过后端获取Agent状态外，还通过WebSocket直连沙箱。这条直连通道用于两个目的：查看Code Server中的代码编辑界面，以及观看沙箱内浏览器运行时的实时画面。

Pub/Sub（发布/订阅） 是一种消息传递模式，发送者（发布者）将消息发送到主题或队列，而接收者（订阅者）通过订阅来异步接收消息，双方无需知道对方的存在。在云端Agent架构中，工具调用队列和结果队列构成了一个双向的Pub/Sub通道。Agent作为发布者将工具调用请求（如“执行bash命令ls -la”）写入工具队列，沙箱作为订阅者消费这些请求并执行，然后将执行结果写入结果队列，Agent再作为订阅者读取结果。这种异步解耦带来了多重好处：Agent和沙箱可以独立伸缩和容错，消息队列天然提供了缓冲和重试能力，同时多个订阅者（后端、数据库）可以并行处理同一条消息，用于前端展示和历史记录，而不会干扰主执行流程。

工具生态：从bash到浏览器

Agent可调用的工具远不止bash shell。视频中列出的工具集包括：

• Bash工具：执行shell命令，创建、删除、编辑、读取文件
• 代码编辑器：独立于bash的文件编辑工具
• Code Server：浏览器中的完整VS Code体验
• LSP：提供代码类型提示和定义跳转
• 浏览器：运行在沙箱中，画面流式传输到前端
• GitHub连接：执行Git操作
• Ask User：Agent不确定时向用户提问
• 部署工具：将应用部署到fly.io等平台
• MCP Server：可选的扩展工具

对于想要构建V1版本的开发者，视频建议优先实现bash工具、代码编辑器/Code Server、GitHub连接和ask user工具。浏览器和部署功能可以后续迭代——在Docker容器中集成浏览器的复杂度较高。

与Lovable的本质差异

Lovable和云端Agent共享相似的基础模式，但复杂度差距明显。Lovable局限于React前端模板，部署到静态CDN，没有完整的文件系统和IDE体验。用户只能在左侧聊天、右侧看预览。

云端Agent面向任意仓库和技术栈，支持后端项目部署，提供真正的VS Code体验（而非自研UI），集成LSP、浏览器等大量工具。这不是数量上的差异，而是能力边界的质变。

视频作者也提到，CrockBot、OpenAI Dots、Muse Agent等"always alive"类型的Agent架构与此不同——它们具有持久化人格和持续运行特征，值得单独讨论。

构建与扩展的难度分野

视频的结论很务实：按照这套架构构建一个V1版本的云端Agent平台，难度并不高，甚至可以当作面试项目或练手挑战。真正的挑战在于规模扩展——当并发会话数、仓库数量、工具调用频率上升时，沙箱调度、队列吞吐、Token刷新、成本控制都会成为瓶颈。

这套架构的核心思路可以浓缩为一句话：Agent在沙箱外，工具在沙箱内，两者通过消息队列解耦，前端通过WebSocket直连沙箱获取实时视图。理解了这一点，云端Agent的黑盒就打开了。