日期：2026-05-18
事由：客户反馈使用 paseo 时"API 慢"，实测为工具层问题
结论：API 响应正常，体感慢的原因是工具层的权限阻塞和黑盒体验
一、现象
使用第三方工具 paseo 执行任务，等待 4 分 8 秒仍未完成，且全程无思考/执行过程可见，完全黑盒。
我方运维人员使用原生 Claude Code CLI 接入同一套 API，执行相同任务，速度明显更快，且有完整的思考和执行过程输出。
二、服务端日志实证
我方运维人员使用原生 Claude Code CLI 接入同一套 API，同一时段的调用记录（Vibe API 后台）：
| 时间 | 输入 tokens | TTFT（首字） | 总用时 | 输出 tokens |
|---|---|---|---|---|
| 02:00:15 | 40,636 | 3.4s | 11s | 326 |
| 02:00:04 | 39,923 | 7.1s | 24s | 740 |
| 01:59:40 | 39,302 | 4.5s | 10s | 614 |
| 01:59:30 | 38,042 | 3.6s | 18s | 1,319 |
| 01:59:02 | 37,795 | 3.6s | 10s | 270 |
| 01:58:49 | 34,967 | 4.0s | 44s | 3,089 |
| 01:57:59 | 34,960 | 5.2s | 6s | 510 |
| 01:57:53 | 32,148 | 5.3s | 26s | 1,142 |
关键数据：
- TTFT（首 token 响应）：3.4 - 7.1 秒
- 输入上下文：32K - 40K tokens
- 模型：claude-opus-4-7（CC 官方满血版渠道）
对于 3-4 万 token 的输入上下文，TTFT 3-7 秒属于正常范围。API 本身没有问题。
三、Paseo 架构分析（基于源码）
Paseo 是一个移动端 AI 编程助手，通过本地 daemon 管理 Claude Code 进程：
Cloudflare
源码关键发现
- Paseo 使用
@anthropic-ai/claude-agent-sdk，通过spawnClaudeCodeProcess启动 Claude Code 作为子进程 - 会话是持久的 —
ensureQuery()方法会复用已有的 Claude Code 进程，不是每次都冷启动 - Skill 执行会触发权限弹窗 — 截图中可见 "How would you like to proceed? Deny / ✓" 的权限确认
- Relay 中继部署在 Cloudflare — 默认连接
relay.paseo.sh:443（Cloudflare Durable Objects），国内用户每条 WebSocket 消息都要经过 Cloudflare 中转，延迟显著增加
4 分 8 秒的真正原因
从客户截图分析时间线：
| 时间 | 事件 |
|---|---|
| 01:46 | 上一个任务完成（Write chicken_rabbit.md，耗时 32s） |
| 01:48 | 用户发送新指令"做成网页版的，UI是Claude官网的风格" |
| 01:48 | 触发 Skill frontend-design |
| 01:50 | 截图显示已等待 1m 45s，出现权限弹窗 |
| 01:52 | 截图显示已等待 4m 8s，仍卡在权限弹窗 |
主要原因：Relay 中继连接不畅（大概率连不上）
Paseo 的手机 App 通过 Cloudflare 部署的 Relay（relay.paseo.sh）与本地 Daemon 通信。国内网络环境下，Cloudflare 节点连接极不稳定甚至完全不可达。一旦 Relay 连接中断或超时，整个交互链路就断了 — App 发不出指令、收不到响应，用户只能看着黑屏干等。
这不是"慢"的问题，而是根本连不上的问题。
次要原因：权限弹窗阻塞 + 黑盒体验
即使 Relay 连通，Skill 执行触发了权限确认（Permission Request），用户可能未及时注意或响应，导致流程阻塞在等待用户操作上。加上没有中间过程输出，用户完全无法判断当前状态。
四、体感慢的三个层面
| 层面 | 原生 CLI | Paseo | 影响 |
|---|---|---|---|
| Relay 连通性 | 无中继，本地直接运行 | 必须经 Cloudflare 中转（relay.paseo.sh） | 国内大概率连不上或极慢，整个链路断裂 |
| 过程可见性 | 实时显示思考、代码编写、文件操作 | 黑盒，只显示最终结果 | 同样等 30 秒，CLI 感觉在工作，paseo 感觉在卡 |
| 权限交互 | 终端内直接 y/n 确认，显眼 | 弹窗可能被忽略，阻塞整个流程 | 用户不知道在等自己操作 |
| 版本未知 | 我方运维使用最新 v2.1.143 | 客户使用的 paseo 版本及其内置 CC 版本未知 | 旧版本可能有性能问题或 bug |
核心结论
不是 API 慢。主因是 Paseo 的 Relay 中继在国内网络环境下连通性极差（Cloudflare 节点），叠加黑盒体验和权限阻塞，让用户误判为"API 慢"。且客户使用的 paseo 版本未知，无法排除旧版本自身的问题。
五、对比验证
同一任务、同一 API（Vibe API + Opus 4.7 1M）：
| 工具 | 使用者 | 体验 | 耗时 | 过程可见性 |
|---|---|---|---|---|
| paseo（第三方） | 客户 | 黑盒等待，卡在权限弹窗 | 4m 8s+（未完成就退出了） | 无 |
| Claude Code CLI（原生） | 我方运维 | 完整思考+执行过程 | 正常完成 | 全程可见 |
客户自己的结论：
"不论用哪家的模型都一样，用第三方工具接入 API，一定要用原生的 Claude Code 工具对比验证测试。否则，都是靠感觉判断模型的速度和质量。"
六、结论
- API 响应速度正常 — 日志证明 TTFT 3-7 秒（3-4 万 token 输入），属于正常范围
- Relay 连不上是主因 — Paseo 强制通过 Cloudflare Relay（
relay.paseo.sh）中转所有通信，国内网络环境下 Cloudflare 节点连通性极差甚至不可达，整个链路直接断裂。这不是"慢"，是"连不上" - Paseo 并非每次冷启动（源码证实会复用进程），但权限弹窗阻塞和黑盒体验进一步恶化了体感
- 客户 paseo 版本未知 — 无法排除旧版本自身的 bug 或性能问题
- 用户无法区分 — 看不到中间过程，不知道是网络断了、等 API、还是等自己操作，直接归因为"API 慢"
- 建议用原生 CLI 对比 — 任何速度/质量判断都应在原生 Claude Code 中验证，排除工具和网络变量
七、Paseo 优势与致命缺陷
优势
| 优势 | 说明 |
|---|---|
| 多 Agent 统一管理 | Claude Code、Codex、OpenCode 一个界面切换 |
| 手机远程监控 | 出门也能看 Agent 进度、批准权限 |
| 多设备协同 | 手机看进度、电脑写代码、CLI 做自动化 |
| 断线恢复 | App 重连自动恢复状态，不丢上下文 |
| 开源可审计 | AGPL-3.0，代码透明 |
| BYOK | 用自己的 API Key，零加价 |
致命缺陷（对国内用户）
| 缺陷 | 说明 | 严重程度 |
|---|---|---|
| Relay 依赖 Cloudflare | 没公网 IP 时必须走 relay.paseo.sh（Cloudflare Workers），国内基本连不上 | 致命 |
| 无法自建 Relay 到国内 | Relay 只能部署在 Cloudflare，不支持部署到国内服务器 | 致命 |
| 黑盒体验 | 看不到思考过程和执行细节，只有最终结果 | 严重 |
| 权限弹窗易忽略 | Skill/工具调用触发权限确认，用户不注意就一直卡着 | 严重 |
| 额外封装层 | App → Relay/WebSocket → Daemon → Agent SDK → Claude Code，链路长 | 中等 |
| 版本碎片化 | 内置的 Claude Code 版本可能落后，用户无感知 | 中等 |
适用场景
| 场景 | 是否适合 | 推荐方案 |
|---|---|---|
| 有公网 IP 的云服务器 + 手机监控 | 适合 | Paseo 直连模式（不走 Relay） |
| 多台机器统一管理 | 适合 | Paseo 多 Daemon |
| 需要手机批准权限、出门看进度 | 适合 | Paseo |
| 国内家用电脑（无公网 IP） | 不适合 | Relay 连不上，体验极差 |
| 日常本地编码开发 | 没必要 | 直接用 Claude Desktop 或 Claude Code CLI |
| 对速度/质量敏感的评测 | 不适合 | 必须用原生 CLI 排除工具变量 |
八、客户端选型建议
对于接入 Vibe API 的用户，推荐方案：
| 场景 | 推荐工具 | 理由 |
|---|---|---|
| 本地日常开发 | Claude Desktop（桌面客户端） | 官方客户端，直接配置 inferenceGatewayBaseUrl 接入 Vibe API，无中间层，体验最佳 |
| 终端/命令行开发 | Claude Code CLI | 原生体验，完整思考过程可见，速度最快 |
| 远程服务器开发 | Claude Code CLI（SSH） | 直接在服务器上跑，无网络中转 |
| 需要手机监控 | Paseo 直连模式 | 前提是服务器有公网 IP，不走 Relay |
| 第三方 IDE 集成 | VSCode、Cursor、Antigravity 等 | 可以用，但速度/质量评判请用原生工具对比 |
手机端开发：以远程桌面回归原生环境
如果一定要在手机上推进开发，更稳妥的做法不是寻找一款"手机原生 IDE"，而是把手机作为远程入口，把真正的开发环境留在桌面。
iOS / Android
Windows / macOS
原生体验、零中转
手机上看到的是完整的桌面操作系统，可以通过语音输入下达指令，并保留电脑端全部工具链与文件 —— 速度、质量、可观测性与桌面侧完全一致，不需要为手机场景做任何取舍。
桌面端：统一使用官方原生工具
在桌面端，请按模型平台选用官方原生工具；选择 CLI 还是桌面客户端按个人偏好即可。
| 模型 | 命令行 | 桌面客户端 |
|---|---|---|
| Claude 系列 | Claude Code | Claude Code 桌面端 |
| GPT 系列 | Codex | Codex 桌面端 |
不推荐任何第三方封装客户端。此前反馈的"上下文频繁被压缩"等问题，对比测试后均可定位为第三方工具引入的中间层所致，与底层模型、API 平台无关。多一层封装，便多一层问题。
核心建议
本地开发直接用官方的 Claude Code CLI、Claude Desktop，官方 IDE 插件就足够。它们都能直接接入 Vibe API（配置 gateway 地址即可），不需要任何第三方工具做中间层。第三方工具本质上都是对 Claude Code 的封装，多一层封装就多一层问题。
自研配置工具 · 替代 CCSwitch
VibeAPI 团队为 Claude Desktop 封装了开箱即用的 API Key 与模型参数配置 —— 无需手动编辑配置文件、无需了解配置语法，点击即可完成接入，常见疑难杂症已预置处理。
打开 VibeAPI Claude 配置工具