Paseo 深度解析：把编程 Agent 变成可以随时接管的工作系统

编程 Agent 越来越强以后，一个新的问题开始浮现：人不再只是和一个聊天框来回对话，而是同时盯着多个任务，等待权限确认，检查不同分支的改动，还要在电脑、服务器和手机之间切换。

Paseo 想解决的正是这一层问题。它不训练模型，也不试图替代 Claude Code、Codex 或 OpenCode，而是在这些工具上面增加一个本地运行的控制平面：负责启动 Agent、保存会话、隔离工作目录、连接不同设备、展示 diff，并把多个供应商的 Agent 编排到同一个工作流里。

截至 2026 年 8 月 24 日，Paseo 官网列出了 39 个受支持的编程 Agent，GitHub 仓库约有 1.48 万个 Star。项目仍在快速迭代，本文讨论的是当前版本和架构，而不是对未来兼容性的保证。

一句话理解 Paseo

如果把 Claude Code、Codex 和 OpenCode 看成真正干活的程序员，Paseo 更像办公室、门禁、调度台和监控屏幕的组合。

它主要负责四件事：

在你的电脑或服务器上启动已有的 Agent CLI；
通过桌面、Web、手机或 CLI 查看和控制这些进程；
用 Git worktree 隔离并行任务，集中审查和交付改动；
让一个 Agent 通过 MCP 调度其他模型和供应商的 Agent。

Paseo 不代理模型请求。底层 Agent 仍使用原来的订阅、账号、配置、Skill 和 MCP Server，模型调用也仍由各自的 CLI 完成。官方的 Provider 说明把这种关系称为 Provider contract：Paseo 只关心怎样启动一个 CLI、怎样读取输出、怎样继续发送输入，以及它支持哪些模式。

这个边界很重要。Paseo 的价值不在于让 Codex 变得更聪明，而在于让 Codex、Claude Code、Hermes 等工具更容易并行运行、远程接管和互相协作。

它有哪些功能

一个界面管理多种 Agent

Paseo 对 Claude Code、Codex、OpenCode 和 Pi 等主流工具提供原生适配器，同时通过 Agent Client Protocol 接入 Cursor、Gemini CLI、GitHub Copilot、Hermes、Kimi、Qwen Code 等更多 Agent。

底层仍是用户已经安装并登录的原生 CLI，因此原来的配置和扩展大多可以继续工作。对同时购买多个模型订阅、需要按任务选择工具的人来说，这比被一个模型供应商完全锁定更有吸引力。

跨桌面、Web、手机和终端

Paseo 的客户端包括 iOS、Android、桌面应用、Web 应用和 CLI。桌面应用把 daemon 和 UI 打包在一起；无界面的服务器则可以安装 @getpaseo/cli 单独运行 daemon。Docker 镜像也能同时提供 daemon 和 Web UI，不过镜像不自带各家 Agent CLI，仍需自行安装和配置。安装文档

手机客户端并不是简单的状态通知器。它可以查看会话、发送追问、处理交互、审查 diff，并在离开电脑后继续接管任务。语音输入默认可在设备本地处理，也可以选择配置云端语音服务。

Worktree 隔离与完整交付链路

并行 Agent 最容易踩的坑，是多个任务同时修改同一个工作目录。Paseo 可以为任务创建独立 Git worktree 和分支，让它们互不覆盖。

一个典型流程是：

创建 workspace
      ↓
创建 worktree 和分支
      ↓
运行 setup，启动一个或多个 Agent
      ↓
运行测试或独立的开发服务
      ↓
在 Paseo 中查看 diff 和页面预览
      ↓
提交、创建 PR、合并或归档

项目根目录可以放置 paseo.json，定义 worktree 的 setup、teardown、测试脚本和长时间运行的服务。不同 worktree 的开发服务器会获得不同端口，Paseo 再通过反向代理提供稳定地址，避免多个前端实例争抢同一个端口。Worktree 文档

浏览器闭环验证

启用浏览器工具后，Agent 可以操作 Paseo 桌面应用中真实可见的标签页：打开本地开发服务、点击页面、填写表单、读取控制台与网络日志并截图。

这补上了 AI 编程中经常缺失的一环。Agent 不再只能说“代码看起来没问题”，而是有机会亲自运行和检查页面。不过浏览器工具默认关闭，还需要同时启用 Paseo 的 MCP 工具集。浏览器自动化文档

定时任务、Heartbeat 与外部触发

Paseo 将周期性工作分为两类：

Schedule 按 cron 周期创建全新的 Agent，适合每日巡检、依赖更新或报告；
Heartbeat 定期向一个已有会话发送提示，让它重新检查进度，适合盯 CI、构建和发布流程。

此外还有一个独立的 Paseo Hub。Hub 接收 GitHub、Slack 和 Discord 的 webhook 或消息，根据 .paseo/hub.yml 和工作流配置，把任务下发给某一台 daemon。Hub 被单独拆出，是因为它需要面向互联网和团队，而单机 daemon 应尽量保持轻量、私有。Schedule 文档、Hub 架构

跨模型编排

Paseo daemon 可以提供 MCP 工具，使一个主 Agent 创建 workspace、启动其他 Agent、发送后续任务并收集结果。

与 Claude Code 或 Codex 自带的 subagent 相比，Paseo worker 是一个由 daemon 管理的完整会话，而且可以跨供应商。例如让 Claude 负责规划、Codex 负责实现，再让另一个模型审查。每个 worker 仍能在 Paseo UI 中单独查看和继续沟通。编排文档

这也是 Paseo 最有辨识度的能力：它不仅让人同时操控多个 Agent，也让 Agent 操控 Agent。

架构：本地 daemon 是核心

Paseo 采用类似 Docker 的 client-server 架构：

桌面 / Web / iOS / Android / CLI
              │
        WebSocket / RPC
              │
       direct 或 E2E relay
              │
        Paseo daemon
      ┌───────┼────────┐
  workspace  process   MCP/API
  /worktree  manager   schedules
      │        │
    Git     Agent CLI 子进程
             │
      各供应商模型 API

daemon 运行在真正拥有源码、凭据和开发环境的机器上，负责 Agent 生命周期、终端、Git、worktree、服务代理、定时任务、插件和 API。客户端通过 WebSocket 连接 daemon，主要承担交互与展示。

从源码仓库看，这是一个以 TypeScript 为主的 npm monorepo：

packages/server 是 daemon，使用 Express、WebSocket、node-pty、MCP SDK 和 ACP SDK；
packages/app 是基于 Expo 与 React Native 的 iOS、Android 和 Web 客户端；
packages/desktop 用 Electron 包装桌面体验；
packages/cli 提供命令行控制；
packages/protocol 和 packages/client 共享协议及客户端能力；
packages/relay 实现客户端与官方 relay 之间的传输和加密；
官方分布式 relay 是独立的 Elixir 项目。

这些结论来自官方仓库的 package map和各 package 的依赖声明。它们说明 Paseo 不是把多个终端窗口拼成 UI，而是试图建立一套可供 App、CLI、SDK、MCP 和 Hub 共用的协议层。

连接和安全模型

客户端连接 daemon 有两条主要路径。

直接连接

daemon 默认只监听 127.0.0.1:6767。如果要跨设备直连，可以通过局域网或 Tailscale 等 VPN 访问，并给 daemon 设置密码。Paseo 还提供 Host allowlist，缓解 DNS rebinding 风险。

把 daemon 直接绑定到 0.0.0.0 会显著扩大攻击面。它控制的是一台拥有代码、终端和开发凭据的机器，仅设置 CORS 并不足以保护它。官方文档也明确建议使用防火墙、VPN、密码和正确的 hostname 配置。

官方 Relay

daemon 可以主动连接官方 relay，手机再通过 relay 与它会合，因此不必开放入站端口。relay 默认不在新安装中自动启用，需要配对时明确选择。

配对二维码或链接携带 daemon 公钥。双方使用 Curve25519 ECDH 派生共享密钥，后续消息通过 XSalsa20-Poly1305 的 NaCl box 加密和认证。按照该协议设计，relay 能看到 IP、连接时间、消息大小和 session ID 等元数据，但无法读取代码和消息内容，也不能在没有客户端私钥的情况下伪造命令。安全文档

这是一种合理的“不信任 relay”设计，但端到端加密并不等于整个系统没有风险。真正需要信任的仍包括：运行 daemon 的机器、底层 Agent CLI、安装的 Paseo 插件，以及拿到配对链接的设备。尤其是 Paseo 插件目前属于实验功能，后端代码无沙箱运行，可以访问 daemon 所在机器，只应安装可信代码。插件文档

与其他工具相比

Paseo 的竞争对手并不只有一种。有些产品偏本地并行编排，有些偏官方 Agent 体验，还有些只解决手机远程接管。

工具	核心定位	Agent 范围	跨设备	并行隔离	开放性
Paseo	本地 Agent 控制平面与编排器	原生适配器加 ACP，多供应商	桌面、Web、原生移动端、CLI	Worktree、服务端口与预览	AGPL-3.0，可自托管
Codex App	OpenAI 官方 Codex 工作台	Codex	macOS、Windows、ChatGPT 移动端	内置 worktree 与云环境	与 ChatGPT/Codex 生态深度集成
Superset	高密度并行 Agent 工作台	多种 CLI Agent	桌面、CLI、MCP，支持远程 workspace	Worktree 是核心抽象	Elastic License 2.0，source-available
Conductor	面向本地与云 workspace 的商业工作台	多模型、可自带订阅和 Key	目前更偏 Mac，移动端仍在推进	本地和云 workspace	免费层加付费云与团队功能
OpenChamber	OpenCode 的可视化开发环境	当前以 OpenCode 为 Agent 引擎	桌面、Web/PWA、移动端 Beta、VS Code	Worktree session	开源、免费
Happy Coder	从手机接管现有会话	Claude Code、Codex	iOS、Android、Web	不是其主要重点	开源，E2E 远程会话

相比 Codex App

Codex App 在 Codex 自身体验、原生沙箱、ChatGPT 账号、Skills、Automation 和云端任务方面更完整。它不需要额外维护一层多供应商适配，官方能对模型与执行环境做更紧密的联动。

Paseo 的优势是供应商中立、自托管和既有 CLI 兼容性。它适合在同一台机器上混用 Codex、Claude Code、Hermes、OpenCode 和其他 ACP Agent。代价则是需要自己维护 daemon、Agent 安装、认证、网络和升级，整体一致性也不可能天然胜过单一供应商的垂直集成。

相比 Superset

Superset 与 Paseo 最接近：两者都强调本地优先、多 Agent、worktree、diff、终端、定时任务和可编程编排。

Superset 更突出“把大量 backlog 拆成许多隔离 workspace 并行推进”，桌面端信息密度和批量 Agent 工作流是中心。Paseo 则把跨设备接管、原生手机、E2E relay、跨供应商 subagent 和通用 daemon/client 架构放得更靠前。

另一个区别是许可证。Paseo 使用 AGPL-3.0；Superset 官方称其为 Elastic License 2.0 的 source-available 软件。对普通个人使用影响可能不大，但要修改后提供托管服务或嵌入商业产品时，应认真阅读各自许可证，而不是把“源码可见”都当成同一种开源。

相比 Conductor

Conductor 的吸引力是商业产品打磨和云 workspace：免费层可以在 Mac 上运行本地并行 Agent，Pro 层增加云端持续运行、团队协作和 API。

如果团队希望购买托管能力、减少自建组件，并需要商业支持，Conductor 路线更直接。Paseo 则更适合希望把执行环境和控制权留在自己机器上、需要 Linux/Windows/移动端以及多供应商可移植性的人。相应地，Paseo 的运维和安全责任也更多落在用户身上。

相比 OpenChamber

OpenChamber 同样提供桌面、浏览器、手机和远程连接，也有 diff、预览、定时任务、GitHub 流程以及多模型运行。它的产品界面完整，但当前底层统一建立在 OpenCode SDK 上。

这让 OpenChamber 能围绕一个 Agent 引擎做深度整合，而 Paseo 的原生适配器加 ACP 路线覆盖面更广。选择取决于你更看重一个统一 Agent 内核的连贯体验，还是保留各家原生 CLI 行为、配置和订阅。

相比 Happy Coder

Happy Coder 更聚焦一个清楚的问题：从手机或 Web 接管电脑上的 Claude Code 和 Codex 会话，并提供通知与端到端加密。它的概念更简单，适合只想解决“离开键盘后查看和批准”的用户。

Paseo 的范围大得多，加入 worktree、diff、服务预览、定时任务、浏览器、SDK、MCP 编排和 Hub。范围越大，能力越强，但安装、配置、认知负担和潜在故障面也随之增长。

Paseo 的主要优点

1. 不强迫用户重建 Agent 环境

现有 CLI、账号、Skill 和 MCP Server 可以继续使用。对已经投入大量时间配置多个 Agent 的用户，这是非常现实的优势。

2. 手机不是附属遥控器

原生移动端与桌面端共享主要能力，配合 E2E relay，长时间任务不再要求人一直坐在工作站前。

3. 把并行开发需要的周边设施一起纳入

只有多开 Agent 并不够。Worktree、setup、独立端口、服务代理、diff、浏览器验证、PR 和清理流程，才让并行任务有机会稳定落地。

4. 跨供应商编排很有想象力

一个 Agent 可以通过 MCP 启动不同供应商的完整 Agent 会话，而不是只能调用同一家模型的轻量 subagent。这为“规划、实现、审查使用不同模型”提供了统一基础设施。

5. 本地优先且可自托管

代码和凭据留在执行机器，relay 协议和服务也有开源实现。对于个人服务器、homelab 和有数据边界要求的环境，这比强制云端执行更可控。

它的缺点和风险

1. 这是另一层需要维护的基础设施

Agent CLI、Paseo daemon、客户端、relay 或 VPN、Git、工作区脚本和项目服务都可能出问题。Paseo 消除了部分操作摩擦，却也增加了新的系统层。

2. 多供应商兼容天然容易漂移

不同 CLI 的协议、权限、输出格式和会话语义持续变化。原生适配器与 ACP 可以缓解问题，但很难保证每个工具的新能力都立即、完整地映射到统一界面。

3. 更高并行度不等于更高产出

十个 Agent 同时运行会更快消耗配额，也会制造十份需要审查的结果。任务拆分不清、测试不足或共享外部资源时，worktree 只能隔离文件，无法自动解决数据库、部署环境和产品决策冲突。

4. daemon 权限很高

它可以启动进程、读写源码、操作 Git，还可能继承 Agent 使用的凭据。暴露端口、弱密码、泄漏配对链接或安装恶意插件，都可能带来严重后果。E2E relay 只保护传输路径，不会把本机高权限程序变成沙箱。

5. 项目仍然年轻且变化快

当前根 package 版本仍处于 0.x，插件 API 也明确标为实验性。快速增长带来新功能，也意味着配置、扩展接口和客户端行为可能继续变化。用于关键团队流程前，应先小范围验证并固定版本。

6. AGPL 对再分发和网络服务有约束

AGPL 对个人自用很友好，但企业若修改 Paseo 并通过网络向用户提供服务，需要评估源代码提供义务。这里只提示风险，不替代法律意见。

适合谁，不适合谁

Paseo 比较适合：

同时使用两种以上编程 Agent，希望保留各自原生配置的人；
在 Mac、Windows、Linux、VPS 或 homelab 上运行长任务，需要手机接管的人；
经常并行处理多个分支，已经感受到手工管理 worktree 和端口的负担；
想探索跨模型规划、实现、审查或自动巡检工作流的人；
愿意自己承担本地服务、网络和权限安全责任的技术用户。

它未必适合：

只使用一个 Agent、每天只跑一两个短任务的人；
更希望购买完全托管服务，不想维护本地 daemon 和远程连接的团队；
尚未建立测试、代码审查和分支规范，却想靠大量并行 Agent 直接提高产出的人；
需要成熟企业治理、SLA、集中审计和供应商支持的组织。

我的判断

Paseo 最值得关注的，不是“又一个 AI 编程界面”，而是它对编程 Agent 基础设施的判断：模型和 CLI 会不断更换，真正应该长期拥有的是执行机器、工作区、会话控制、审查流程和连接方式。

这个判断让它与单一供应商产品形成了清楚的差异。Codex App 可以把 Codex 做得更深，OpenChamber 可以围绕 OpenCode 做得更一致；Paseo 选择承担更难的横向工作，把许多原生 CLI 接到同一套本地控制平面。

它目前最有说服力的使用场景，不是让几十个 Agent 无人值守地疯狂写代码，而是更朴素的三个变化：离开电脑后仍能及时回答 Agent，多个任务不再争抢同一个工作目录，以及根据任务选择最合适的 Agent 而不必更换整套工作流。

如果你已经遇到这三个问题，Paseo 值得在非关键项目上试用。如果你还没有，终端、一个成熟的 Agent 和清晰的测试流程，可能仍是更简单可靠的组合。