它们都让你从桌面或手机管理多个 coding agent，但源码里的系统中心完全不同：Paseo 以开发者本机为中心；Omnigent 以可共享、可治理的会话控制面为中心。
两者有相同的用户可见表面，却在不同评价函数上优化。
| 如果问题是…… | 更强的一方 | 源码层原因 |
|---|---|---|
| 一个人在自己的电脑上高频并行跑 agent | Paseo | 单 daemon、路径短、provider session 直接持有、终端专门优化 |
| 团队跨机器、跨 harness、带权限和策略运行 agent | Omnigent | Server/Host/Runner/Harness 分层，SQL 会话、身份、共享、Policy 与 sandbox 都是一等能力 |
| provider adapter 边界是否清楚 | Paseo | AgentClient / AgentSession 是窄而语义化的核心接口 |
| 不同 harness 能否组合为真正的 agent 树 | Omnigent | YAML spec、sub-agent runtime、inbox/autowake、树级成本与跨 harness fork |
| 弱网和断线恢复协议是否可推理 | Paseo | timeline 原生带 epoch + seq、gap、stale cursor 和分页 catch-up |
| 安全治理边界是否完整 | Omnigent | ALLOW/DENY/ASK policy、bwrap/Seatbelt、L7 egress、credential proxy |
| 总体架构是否“小而美” | Paseo | 单事实源、单主协议、本地文件；概念与运维面少 |
| 能力上限是否覆盖团队和受管执行 | Omnigent | 会话控制面与执行面解耦，能承载多用户和异构算力 |
最重要的差别不是 UI，也不是 provider 数量，而是事实源与执行所有权放在哪里。
Paseo 的 relay 只是传输层；Omnigent 的 Server、Host、Runner、Harness 是四个独立责任域。后者路径更长，但每一层都能插入权限、调度、隔离或恢复逻辑。
客户端 WebSocket → server/session.ts → AgentManager / AgentSession → provider adapter → timeline 分配 epoch / seq → WebSocket 广播
Web POST / session input → Server 鉴权 / ACL / 持久化 → Policy enforcement → Runner WebSocket tunnel → per-conversation Harness → item 持久化 + ephemeral SSE → snapshot / item-id 对账
两边都做 adapter，但统一到的层次不同。
AgentClient / AgentSessionAgentClient 负责能力发现、catalog、创建和恢复。AgentSession 负责 turn、结构化事件、历史、模式、权限、持久化 handle、中断和关闭。这是两套系统哲学差异最清楚的一段代码。
daemon 端 timeline 为 source event 分配 epoch 与单调递增 seq。客户端按 cursor 分页追赶，显式处理 epoch reset、stale cursor、保留窗口 gap，以及投影折叠后的 source sequence ranges。
session_stream.py 明确写着：没有 buffer、没有 replay、没有 sequence；无订阅者时事件会丢。恢复依赖 SQL snapshot、持久化 item ID 与 Web store 合并。
inflight_text 保存尚未落成 item 的当前回答。| 维度 | Paseo | Omnigent |
|---|---|---|
| live stream | 带序列的权威 timeline 增量 | 无重放 SSE 尾流 |
| 恢复 | epoch/seq cursor + 分页 catch-up | GET snapshot + item ID + inflight merge |
| 复杂度位置 | 服务端协议更强，客户端规则直接 | broker 简化，客户端 store 合并更复杂 |
| 结论 | 协议连续性更漂亮 | 数据库应用模型可用且竞态处理认真 |
Paseo 更接近“启动本地子任务”；Omnigent 把关系做成持久会话树。
resumeSession(handle) 让 adapter 恢复厂商原生会话。agent.fork_context 可生成上下文附件。feat/provider-native-fork 是实验贡献分支，本报告未计入正式能力。create_agent + paseo.parent-agent-id label，支持同 workspace、独立 worktree、subagent/detached 与级联归档。非常适合在本机另开一个 agent 做异步任务。
parent_conversation_id、root_conversation_id、sub_agent_name 是关系模型本身。系统工具覆盖 create/send/list/history/info/close 与 inbox；实现 autowake、blocked/approval 上送、树级成本、并发上限、history 传递、presence 和多 worktree 编排。
“支持 Claude Code / Codex”背后的技术路线并不相同。
node-pty 位于 forked worker，隔离 native PTY 故障。@xterm/headless 在 daemon 保存快照与 resize/reflow 语义。边界很诚实：raw terminal 可粗略投影 running / idle / needs-input，但不会自动伪装成结构化 agent transcript。
延迟、快照、二进制流与输入回显是专门优化目标。
把人类 TUI 尽可能提升为可治理的平台 transcript。
厂商 TUI 不是稳定 API，forwarder 必须持续追版本行为。
两边的威胁模型不同，不能把“没有同一功能”简单理解为遗漏。
127.0.0.1，可选 bcrypt shared-secret。连接成功的客户端基本是可信 operator。Paseo 没有自建跨 provider policy engine 或进程级文件/网络沙箱。
ALLOW / DENY / ASK，可用 label、session state、usage；支持成本、PII、GitHub、风险、工作目录等内置策略。Windows 只能退化到较弱 Job Object；Seatbelt 也不等价于 Linux namespace。源码明确记录了这些差异。
这些差异不是外围包装，而是从核心数据模型自然长出来的。
| 维度 | Paseo | Omnigent | 结构性影响 |
|---|---|---|---|
| 权威存储 | $PASEO_HOME 每 agent 一个 JSON，另有 config/projects/chat/schedules | SQLAlchemy + Alembic；conversation/items/users/tokens/ACL/policy/host/cost 等表 + artifact store | 前者可读、可搬、低运维；后者可查询、可共享，但有数据库生命周期 |
| 执行位置 | daemon 所在开发机；可整体容器化 | Server、Host、Runner 分离；笔记本、VM、K8s、多种 managed sandbox | Omnigent 的分布式能力是架构，不是部署脚本附加物 |
| 身份与共享 | 可选 daemon 密码；连接者为可信 operator | accounts、invite、OIDC/header auth；read/edit/manage/owner；公开或定向分享 | 团队协作不在同一量级 |
| 协作交互 | 多客户端观察同一 daemon | presence、live co-drive、文件锚定 review comment、分享后 fork 到自己机器 | Omnigent 更像协作产品和控制面 |
| UI 技术 | Expo React Native；移动原生渲染，web 走 RN Web，Electron 包 web | Vite React DOM；浏览器/PWA/Electron 共用；手机是 WKWebView/WebView 薄壳 | Paseo 移动更原生；Omnigent 真正一份 DOM UI 到处跑 |
| 协议 | 单 WebSocket envelope + terminal binary frame | REST/SSE + Host WS + Runner WS + per-harness HTTP/UDS | Paseo 概念少；Omnigent 分层多、可控点也多 |
| 版本偏差 | Zod append-only schema + client capability flags | Host/Runner hello 严格 major frame protocol；另有 Server 版本兼容测试 | 都认真处理；Omnigent 的组合矩阵更大 |
LOC 不能判胜负，但能暴露系统正在承受的演化压力。
| 指标 | Paseo | Omnigent |
|---|---|---|
| 主语言粗略规模 | TS/TSX 约 61.9 万行 | Python 约 84.1 万行；Web TS/TSX 约 15.5 万行 |
| 测试粗略规模 | TS test/e2e 约 25.7 万行 | Python tests 约 49.4 万行；Web tests 约 7.4 万行 |
| 最大核心文件 | Codex adapter ~6.2k；session.ts ~5.6k；Claude adapter ~5.3k | sessions.py ~21.5k；runner/app.py ~19.1k；cli.py ~13.1k |
| 公开历史 | 2025-10 起，4,281 commits；核心作者高度集中 | 2026-06 起，1,327 commits；迭代极快，README 仍标 alpha |
统计基于固定提交的 tracked files 与扩展名，包含测试，不用于计算质量分。Omnigent 的 public history 起点不等于项目真实诞生时间。
monorepo 边界清楚；agent SDK 是稳定架构中心；timeline、terminal、wire compatibility 有低层文档与测试；单进程路径容易追踪。
session.ts 与 adapter 仍偏大；daemon 职责持续膨胀；作者集中导致 bus factor 低；JSON 模型若协作化会触顶。
tunnel、重连、process manager、policy、sandbox、权限与 native bridge 测试密集；四层故障域明确；store 与 deployment 后端覆盖广。
21k/19k/13k 巨型核心文件；native harness 硬编码扩散；REST/SSE/多 tunnel/per-harness HTTP 版本组合多；生产成熟度仍待时间证明。
避免把不同目标压成没有解释力的星级评分。
| 维度 | Paseo | Omnigent | 判断 |
|---|---|---|---|
| 本地个人开发体验 | 原生目标 | 兼容但不是唯一中心 | Paseo |
| provider 语义 adapter | 窄接口、直接持有 session | headless 清晰，native 路径分散 | Paseo 小胜 |
| harness 覆盖与组合 | ACP + 重点 direct adapters | SDK/native/ACP，多 harness 可混用 | Omnigent |
| 原生 CLI | 高质量 raw terminal | transcript-aware native harness | 目标不同 |
| 多 Agent runtime | create_agent + label + worktree | 声明式子树、inbox、autowake、树级成本 | Omnigent |
| Resume | provider-native handle | conversation + runner/harness rebind | Omnigent 更宽 |
| 跨 provider fork | 官方主干尚不完整 | transcript 复制、native rebuild 或文本降级 | Omnigent |
| 弱网恢复 | epoch/seq/gap/catch-up | snapshot/item ID/inflight merge | Paseo |
| 身份与多用户 | daemon shared secret | 完整 ACL、auth、sharing、presence | Omnigent |
| Policy | 依赖 provider 原生权限 | 跨 harness ALLOW/DENY/ASK | Omnigent |
| OS sandbox / egress | 外部容器或 provider 能力 | bwrap/Seatbelt、L7 egress、credential proxy | Omnigent |
| 移动体验 | React Native 原生渲染 | WebView 共用 DOM UI | Paseo |
| 运维简单度 | 单 daemon、本地文件 | Server/DB/Host/Runner 多层 | Paseo |
| 中央部署 / 受管算力 | 非核心模型 | 一等架构能力 | Omnigent |
| 代码局部可理解性 | 较高，仍有大文件 | 抽象丰富，核心巨型文件明显 | Paseo |
| 测试防御深度 | 协议和终端扎实 | policy/sandbox/tunnel/native 矩阵更大 | Omnigent 小胜 |
选 Paseo：更少组件、更清楚的失败边界、更强的原生移动与终端体验。Omnigent 的数据库、Host/Runner、Policy 和 sharing 在此有不少是未被利用的复杂度。
选 Omnigent：local JSON + shared secret 不是 session ACL、OIDC、presence、review comment 与树级预算的基础。
学习 adapter 设计看 Paseo；若核心目标是会话跨 provider/harness 迁移并受治理，看 Omnigent。
“远程终端就是原终端”选 Paseo；“TUI 也必须进入共享 transcript、Policy、fork 与 agent tree”选 Omnigent。
选 Omnigent：Server/execution host 分离、Runner tunnel、sandbox、egress 与 credential proxy 构成 Paseo 当前没有的边界。
| 最漂亮的设计 | 最危险的设计压力 | |
|---|---|---|
| Paseo | epoch + seq timeline；AgentClient/AgentSession；terminal leading+trailing pipeline | daemon 持续吸收职责；JSON 协作化上限；核心作者集中 |
| Omnigent | Server/Host/Runner/Harness；conversation tree；统一 policy + sandbox + credential boundary | session/runner/CLI 巨型文件；native harness 扩散；多协议多部署组合爆炸 |
把“读到的设计”与“本机复现的行为”分开。
uv >= 0.11.8 + Python 3.12.13 dev 环境安装成功。npm ci --legacy-peer-deps 安装，工作树 clean。npm run type-check：通过。GET /health → 200；SIGINT 干净退出。upstream/main 提交运行，未使用 checkout 上的 UI 改动。两边测试数量不能横向当分数：Omnigent 选跨层集成切片，Paseo 选报告关注的低层协议切片。