选择多 Agent 编程工具，需要同时考虑代码在哪个目录修改、谁能执行命令、任务如何交接，以及离开电脑后怎样审查结果。一个工作台可以同时打开很多会话，却未必自动隔离它们的文件；能够从手机接入，也未必能在服务重启后继续执行原来的命令。
Orca、Herdr、Paseo、T3 Code 和 Codeg 都覆盖了多 Agent 开发的一部分流程。本文比较五个产品系列，其中 Herdr 分别考察 TUI 与 App 两条产品线，共六个运行选项。它们的能力已经相互重叠，选型时更有用的比较是：哪种组织方式适合现有工作习惯，哪些操作有明确的权限和生命周期规则，哪些环节仍需要自行组合工具。
先按工作方式缩小候选范围
| 主要需要 | 优先考察 | 能直接利用的能力 | 需要接受或验证的代价 |
| 保留终端、编辑器和 SSH 工作习惯，集中观察多个 Agent | Herdr TUI | 真实终端、后台 server、多机器状态、CLI/socket 控制 | Git 审查、浏览器和任务验收主要依赖已有工具组合；状态识别有集成边界 |
| 保留真实终端，同时需要可定制 GUI、文件与改动面板和手机接手 | Herdr App | 独立 core、Files/Changes、worktree UI、Mods、官方移动端 | 不与 TUI 共用 Agent；Files 默认只读，Mods 有用户权限，usage telemetry 默认开启 |
| 在一个桌面窗口完成派工、编辑、页面验证和代码交付 | Orca | worktree、Chat/terminal、编辑器、Chromium、diff 与 Git/PR | 新装权限与遥测默认值要先核对；结构化编排和部分云环境能力标为 Experimental |
| 围绕 workspace 管理多个 Agent、开发服务和可编程流程 | Paseo | CLI、TypeScript SDK、插件、service 端口与 URL 管理、多客户端 | 需要维护 daemon 和项目脚本；远程浏览器自动化仍依赖桌面 browser host |
| 以 thread 和代码审阅为中心，在电脑、手机和远程主机间切换 | T3 Code | 多 Provider、turn/branch/commit diff、PR、host 侧浏览器、MCP/CLI | 初始 Full access、遥测与连接诊断需要分别配置；部分跨机能力为 beta |
| 用画布组织任务，让不同品牌 Agent 委派协作并连接 Todo、Git 和 PR | Codeg | ACP、跨 Agent delegation、无限画布、Todo worktree 与交付流程 | adapter 能力不齐；普通委派默认共目录；Codeg 代办文件和命令有独立的权限边界 |
这些是基于能力与实现的候选建议。大仓库响应、长对话流畅度、内存占用、手机操作和故障恢复成功率，都需要在实际项目中测量。
评测范围与版本基线
核验日期为 2026 年 11 月 10 日。比较依据是官方文档、发布记录和对应分发版本源码；没有把宣传页的功能清单当作实际性能结果，也没有进行这些运行选项的统一上机速度与稳定性横测。
| 工具 | 本次主要核验版本 | 发布或分发信息（日期为 UTC） | 核心源码许可 |
| Orca | v1.4.255 | 2026-11-09 | MIT |
| Herdr TUI | v0.9.5 | GitHub Release：2026-10-14（UTC） | Apache-2.0 |
| Herdr App | App 0.1.14 / core 0.1.19 | 官方分发清单；未提供统一发布日期 | App 与 core 均为 Apache-2.0 |
| Paseo | v0.15.3 | 2026-11-06 | Apache-2.0，第三方组件保留各自许可 |
| T3 Code | v0.1.8 | 2026-11-09 | MIT |
| Codeg | v0.42.1 | 2026-11-06 | Apache-2.0 |
五个产品系列都有 macOS、Windows 和 Linux 的安装产物或二进制，但具体架构要分开看：Herdr TUI 提供 Intel Mac 二进制；本次 Herdr App 分发仅有 Apple Silicon Mac 成品，Intel Mac 需要源码构建。Herdr App 的 Linux 桌面还要求图形会话与可用 Vulkan driver。操作系统有安装包，不能证明每种 Agent、浏览器、Computer Use 和远程接入路径在该平台都经过同等验证。手机端、实验功能和新接入的 Provider 还要看各自限制。
下文将证据分为三类：官方文档明确描述的能力、源码可确认的默认行为，以及仍需上机验证的体验。没有找到某项功能的明确资料时，记为「未确认」，不据此断言产品不支持。Herdr TUI 与其他四款的版本以官方 GitHub Release 为基线；Herdr App/core 的官方分发使用 latest manifest，以对应 tag 锁定源码版本。App 与 core 的版本独立更新，core API 仍标为 preview/generation 1。发布或分发版本本身不构成生产稳定性保证。
Herdr TUI 与 App：先分清两套运行体系
Herdr TUI 是原有的终端应用，自带自己的 server。Herdr App 是另一个桌面程序，使用独立的 herdr-core 运行终端；两者可以在同一台机器上并存，但不会共享 Agent。原来在 TUI 启动的任务，不会因为打开 App 就出现在它的侧栏里。
| 比较项 | Herdr TUI v0.9.5 | Herdr App 0.1.14 / core 0.1.19 |
| 交互中心 | terminal pane、TUI sidebar、键盘与鼠标 | 原生桌面窗口、spaces/tabs/panes、随包和自定义 Mods |
| 运行层 | TUI 自己的 server | 独立 herdr-core；App 负责窗口，core 负责程序 |
| Agent 状态 | 屏幕检测规则与 integration/主动报告结合 | OSC 7501 程序主动报告，core 不猜屏幕文本；未报告就没有 Agent status |
| 文件与代码改动 | 沿用终端 Git、编辑器与插件组合 | 默认 Files 只读预览、Changes 的 Git status/diff 与 Commit |
| worktree | TUI UI/CLI 管理 | 随包 worktree mod 管理，并创建对应 space |
| 程序协调接口 | herdr agent start/prompt/wait/read 等 | hc run/send/wait/read 等；herdr-app 另管窗口命令 |
| 机器重启后的恢复 | 满足引用和设置条件时恢复支持的 Agent 会话 | kept pane 恢复原目录的新 shell，不自动重跑任务或 resume Agent |
| 手机入口 | SSH terminal 客户端 | 官方 iPhone/iPad/Android App 经 SSH 连接 core，不支持 TUI |
| 产品遥测 | 本轮未发现同类 usage telemetry 实现；有版本/manifest 检查 | release 默认发送可关闭的 usage telemetry；更新与 Mod 请求另算 |
如果现有 TUI 任务与 integration 已经稳定，应把迁移作为一项独立成本评估。需要 GUI、可改布局和官方手机入口时，可以试 App，但不能直接沿用 TUI 的状态与恢复假设。两套布局和会话的迁移能力仍需在实际环境中验证。
「支持 Agent」需要拆成几层
把 Claude Code、Codex 等 Coding Agent 接到工作台，可以有不同方式：直接运行 CLI、通过 SDK 或 app-server 取得结构化事件，或者通过 ACP 等协议适配。接入方式会影响权限提示、工具调用展示、历史恢复和状态识别。
| 层次 | 实际含义 | 选型时应检查 |
| 终端可运行 | 能启动原来的 CLI，并显示终端画面 | 登录、环境变量、快捷键、输入法和长输出是否正常 |
| 状态可识别 | 工作台能判断运行、等待输入和完成等状态 | 状态来自 hook、协议还是屏幕识别；权限对话变化后是否仍准确 |
| 结构化聊天 | 能按消息、工具调用、批准请求等对象展示会话 | 是否覆盖常用工具，能否恢复历史，是否与原生 CLI 行为一致 |
| 环境工具可调用 | Agent 可以创建 worktree、控制浏览器或启动其他 Agent | 注入是否默认开启，哪些 Agent 能使用，权限由谁执行 |
| 跨 Agent 委派 | 父任务能创建、跟踪和收取子任务结果 | 子任务目录、上下文、权限、取消与完成规则是否明确 |
五款工具的接入差异
Orca 同时保留终端与结构化 Chat。 任意 CLI 能在终端中运行，不代表都拥有同等深度的 Chat、状态 hook、账号用量或恢复支持。正式版有 Claude/Codex 等结构化适配及 ACP 相关接入；新装默认会话方式仍是 Terminal。需要在常用 Agent 上分别确认终端和 Chat 两条路径。
Herdr TUI 以真实 terminal pane 为中心。 CLI 仍在原来的终端环境里运行；受支持的 Agent 才能获得 working、blocked、idle 等状态。部分状态来自屏幕检测规则，部分来自 integration 或 Agent 主动报告。某个新 Agent 能正常运行，与它能被准确识别，是两件需要分别验收的事。
Herdr App 也运行真实终端，但状态链路与 TUI 不同。 herdr-core 记录程序通过 OSC 7501 主动报告的状态，不通过屏幕文本猜测 Agent 是否工作或等待。App 随包的程序菜单可以启动多种已安装 CLI，但品牌图标、命令可启动和完整状态兼容仍是不同层次。评估时需要检查自己的 Agent 是否发送状态，以及 helpers 是否出现在侧栏和 peek 视图。
Paseo 按 Provider 使用不同接口。 Claude 使用 Agent SDK，Codex 使用 app-server，Pi 使用 RPC，其他 Provider 有各自 adapter 或 ACP 接入。它能够统一展示会话和管理生命周期，但不同 Provider 的权限、工具注入和恢复能力仍有差别。例如，本次核验的 Antigravity 路径只提供 Full access，不能用 Claude/Codex 的模式推断它的行为。
T3 Code 已经覆盖多 Provider。 正式版安装文档列出 Claude、Codex、Cursor、Grok Build、Kiro、OpenCode、Antigravity、Pi、Muse Code、fx，并有 ACP Registry 接入。Claude 与 Codex 也分别使用 SDK 和 app-server。评估时应查看安装版的 Provider 文档，不能只按 README 的简短列表判断边界。
Codeg 通过 ACP 聚合多品牌 Agent。 官方清单列出 20 个内置 Agent，还能注册 custom agent。Claude/Codex 使用的 ACP adapter 可以复用部分既有登录与配置，但 adapter 自身的 SDK、版本和执行方式，不必然等同终端里 PATH 指向的 CLI。现有命令行能工作之后，还要验证 adapter 与账号、代理网关和所需模型的兼容性。
对多品牌工作流，建议先验证「常用两个 Agent 的完整任务路径」，再比较总支持数量。例如，能否用一个 Agent 实现、另一个审查，批准信息是否完整，子任务是否可追踪，结果能否回到父会话。
工作区隔离与开发环境
Git worktree 为同一个仓库建立独立工作目录，可以分别检出不同分支。它有助于分开代码改动，但仍共享一部分仓库状态和配置；不能直接当作容器、不同操作系统用户或独立数据库。
并行开发至少有四项要分别安排：工作文件、依赖与配置、应用监听端口，以及数据库等外部状态。三个 worktree 都运行写死的 localhost:3000，仍然需要处理端口冲突。
新任务是否自动获得独立目录
| 工具 | 已确认的隔离机制 | 容易误判的默认行为 |
| Orca | workspace 围绕 worktree/branch 组织，可选择起点与配置初始化 | 同一个 workspace 里的多个 Agent 仍需明确写入分工；共享路径会影响隔离范围 |
| Herdr TUI | UI/CLI 可创建、打开和移除 worktree | 启动一个新 pane 或 Agent，不等于已经创建新 worktree |
| Herdr App | 随包 worktree mod 提供 New/Open/Remove，在目标机器创建 Git worktree 和 space | space、pane 与独立 checkout 需分别确认；默认创建链未承诺自动安装依赖或分配端口 |
| Paseo | workspace 可以使用独立 worktree，同 workspace 可有多个 Agent | 同 workspace 默认共享工作目录；需要先决定任务是否应该拆成独立 workspace |
| T3 Code | thread 可选择 New worktree；可配置项目默认方式 | 内置新 thread 环境默认是 local；delegate_task 默认也为 shared，隔离需要显式选择 |
| Codeg | Todo 自动建立任务分支与 worktree，可复用任务目录 | 普通 delegation 默认在 lead 的同一目录运行；跨品牌委派本身不自动隔离文件 |
只读审查 Agent 可以有意读取实现 Agent 的同一目录。需要隔离的是并行写入的任务，而不是机械地为每个观察者复制一套目录。是否真的只读，还要由实际权限配置保证。
依赖、初始化和端口如何管理
Orca 提供多种共享与复制机制。 Worktree Shared Paths 可以使用 APFS clone 或 symlink，orca.yaml 的 shared directories 是链接，.worktreeinclude 则用于复制指定文件。把 node_modules 共享给多个任务，会改变依赖隔离的含义，不能同时假定各目录互不影响。
Orca 的 setup 与 Agent 启动也有先后选择。默认 start-immediately 允许 Agent 在初始化未结束时启动；依赖必须先就绪的项目，应设置 wait-for-setup。SSH Ports 面板的转发能力，与为多个本地服务分配不同端口，是不同用途。
Herdr TUI 提供 worktree 原语，环境准备主要沿用 shell 与插件。 可以用脚本和 worktree.created 等事件接入 bootstrap。它更适合已有初始化约定的仓库；评估重点是这些脚本能否可靠执行，以及失败能否被看见，而不是寻找一个与桌面 IDE 完全相同的 setup 表单。
Herdr App 的 worktree 则由随包 Mod 提供。 默认在目标机器的 ~/.herdr/worktrees/<repo>/<branch> 创建目录，再打开新 space；也可处理远端机器。默认链路是 Git worktree 加 space，依赖初始化、配置复制和服务端口仍需项目脚本或自定义 Mod 组织。TUI 插件事件与 App 的 Mod API 属于不同接口，迁移时需重新核对。
Paseo 对开发服务提供了更明确的项目抽象。 paseo.json 支持 setup、teardown 与 service。Service 可使用 $PASEO_PORT 自动分配端口，配置端口范围或外部分配器，并获得确定性的 .localhost 反向代理地址；同 workspace 的服务还能取得其他服务的端口与 URL。
这套机制适合同时运行多份前端、API 或联调环境，但项目必须使用提供的端口变量和脚本。普通终端里写死端口的服务不会因此自动改写。归档最后一个使用 managed worktree 的 workspace 还会触发清理，应先用测试项目确认归档语义。
T3 Code 使用项目 actions 管理生命周期。 t3.json 可声明 worktree 创建、settle、停止子进程和预览等动作。Setup 默认异步；如果实现任务依赖安装完成，应为 setup action 设置 async:false，等待脚本退出后再启动 Agent。它能发现 thread 相关的服务与端口，并打开预览；本次资料没有确认与 Paseo 相同的通用端口分配模型，适合将「多服务同时启动」列为试用项。
Codeg 的 Todo 负责任务目录和交付阶段。 Worktree init command 可安装依赖，失败时阻止 Agent 启动；review preflight command 可运行验证。两类命令默认都未配置，不能把自动创建 worktree 理解为环境与验收已经自动准备好。
多 Agent 编排与完成确认
多会话并行、通过 CLI 调度其他会话，以及产品原生的任务委派，提供的控制信息不同。对复杂任务，至少要能回答：子任务属于谁、在哪个目录运行、收到哪些上下文、何时算完成，以及取消父任务时会发生什么。
下面是一个供试用的任务结构：为 Web 项目加入 CSV 导出，分别安排实现、审查和验证。审查反馈返回实现任务，验证完成后再决定是否接受变更。
这是一份试用结构，不是已经执行并通过的实验结果。
| 工具 | 已确认的编排入口 | 需要单独处理的边界 |
| Orca | Experimental Run、Task、Dispatch、worker、mail、依赖与 decision gate | Run 是持久命名空间与 inbox，不会自动替代调度者；完成回执仍需对应任务与 dispatch |
| Herdr TUI | CLI/socket 的 start、prompt、wait、read 和布局控制 | 依赖、任务归属和验收协议主要由上层脚本或 Agent 定义；wait 返回不等于任务验收成功 |
| Herdr App | core 的 hc CLI、JSON-RPC/OpenRPC API、parent/children 和结果 notes；App 另有窗口命令 | hc wait 仍可能因 blocked/error/idle 返回；角色说明和状态不等于强制权限或项目验收 |
| Paseo | Paseo tools、CLI、TypeScript SDK、跨 Provider 消息与工作区管理 | 工具注入默认关闭；同 workspace 共享 cwd；跨 Provider 权限不能无条件按同名字符串继承 |
| T3 Code | MCP delegate_task、status/cancel、CLI、外部 Agent 接入 | 子任务默认 shared、只取得任务文本；直接向子 thread 发消息有边界；跨机 linked environments 为 beta |
| Codeg | companion MCP 的 delegation、assistant 配置、结果查询与 Todo | delegation 默认关闭、深度默认 1；worker 冷启动且普通委派共目录；并非全部 Agent 都能充当 lead |
状态、回执与实际成功
Herdr TUI 的 wait 可以因为 Agent 进入 blocked 而返回；idle 也可能只是屏幕检测的回退状态。一个任务已经等待人工输入，与它已完成测试，应该分别记录。自动化读取状态后还需要检查真实终端输出和验收结果。
Herdr App/core 的 hc 提供程序运行、消息、等待、读取与父子终端管理。子任务可以向父任务报告，父端也会收到需要注意或结束的 notes；hc wait 的返回仍不构成测试通过。状态来自程序报告，不应套用 TUI 的屏幕检测回退解释。需要读取真实输出并核对验收条件。
Orca 的结构化编排提供 task/dispatch 对应的 worker_done 与 outcome，适合区分不同任务和重试。它仍然是 worker 的结果报告；接受代码前，还需要审查和实际测试。
T3 Code 的子任务默认只收到 task，不复制父历史；选择 worktree 时从父 commit 建立 checkout，父目录未提交的修改不会自动进入。父任务停止也会停止委派的子任务。跨 Provider 委派时还存在权限上限，不能把子任务当成绕过父权限的入口。
Codeg 的 worker 同样是冷启动。已完成 worker 的后续工作通常需要新委派，resume_delegation 用于取消或意外中断的恢复。官方 20 个内置 Agent 中，17 个能发起这套 delegation；Pi、OpenClaw、Cline 在该接入方式下只能作为 worker。这个限制涉及 Codeg companion 的 MCP 接入，不应扩大为这些 Agent 本身完全没有 MCP 或协作能力。
代码审查、Git 与实际验收
用于代码交付时，需要比较 diff 的基准、反馈粒度、暂存与提交操作，以及 PR/MR 的上下文。
| 工具 | 审查与交付能力 | 实际试用重点 |
| Orca | diff、行级反馈、文件编辑、stage/commit/push、PR/MR 与检查结果 | 能否从具体改动向 Agent 反馈，未提交与已提交改动是否容易区分 |
| Herdr TUI | 在真实终端运行 Git、gh、编辑器或其他 review 工具，插件可扩展 | 现有终端工具组合是否足够；从状态跳到文件、测试和浏览器需要多少操作 |
| Herdr App | 默认 Files 只读语法预览、Changes 的 Git status/diff/Commit，UI 可用 Mods 改造 | 随包 Commit 使用 git add -A 后提交，需确认全部暂存范围；只读 Files 不等于完整编辑器 |
| Paseo | Changes、文件编辑、分屏与 PR/workspace 流程 | 同 workspace 多 Agent 的改动如何归属，review 反馈如何进入正确会话 |
| T3 Code | turn、branch、commit 等 diff；PR 创建、审阅、评论与合并 | 不同 diff 基准是否符合审查需要，所用 forge 的动作和手机界面是否完整 |
| Codeg | inline/side-by-side diff、Git history、分支、stash、三栏冲突编辑、Todo/PR 交付 | 普通 diff 是只读展示，不能当逐行接受器；冲突编辑与最终合并要分别验收 |
Codeg 的 Repository 面板明确支持 GitHub、GitLab、Gitea/Forgejo，并可把 issue/PR 转成 Todo。T3 Code 的 source control 文档列出更多 forge，但部分操作存在主机差异。选型时应使用团队真实的 Git 服务，分别试评论、PR 更新、检查状态和合并，不只看支持名称。
自动合并也要看启用条件。Codeg 的 Todo 自动处理和自动合并默认关闭，并提供 review preflight；来自外部 issue/PR 的任务不能无人自动合并。对于其他工具，同样需要明确由谁执行检查、哪份结果允许进入交付，而不能把 Agent 的「完成」回复当作 merge 条件。
前端验证：浏览器运行在哪里
远端 Agent 能否在桌面离线后继续操作页面，取决于浏览器实际运行的位置。
| 工具 | 已确认的浏览器路径 | 远程使用含义 |
| Orca | 内置 Chromium、设计上下文与 browser CLI | 与运行方式和 host 配对有关；需要在目标 SSH/paired server 组合上验证 |
| Herdr TUI | 沿用外部浏览器和现有自动化；终端链接可在 client 所在机器打开 | client 的 localhost 与远端服务地址要区分，必要时配置端口转发 |
| Herdr App | release 已确认的 URL/file link 交系统 handler 打开，其他能力可由 Mods 扩展 | 本次未确认默认内嵌网页调试或浏览器自动化；社区 Mod 不能直接当作随包能力 |
| Paseo | 已连接的桌面应用充当 browser host，daemon 自己不运行浏览器 | 只有 headless daemon 在线，不能直接假定同样具备浏览器自动化 |
| T3 Code | browser tab 属于 environment，远端 host 可运行 headless Chrome | 客户端断开后 Agent 仍有 host 侧浏览器路径；资源、Chrome 安装与 sandbox 要验收 |
| Codeg | 本地桌面使用原生 WebView；Web 客户端可通过 port bridge 预览页面 | 远端 Agent 不自动获得本机桌面原生 tab 工具；iframe 预览与 Agent 操作浏览器是不同能力 |
Codeg 在 macOS、Windows、Linux 使用的 WebView 引擎不同。能够截图或点击页面，可以帮助开发反馈，但不能直接替代项目已有的多浏览器测试。T3 Code 能在服务器运行浏览器，也不代表已经证明低内存主机能承载大量并行页面。
权限默认值与 sandbox 边界
工作台访问权限、Agent 工具批准模式、操作系统 sandbox 是三层不同的控制。能够登录某个远程工作台，可能已经获得读取文件和发起命令的广泛能力；界面显示「批准」，则要进一步确认谁执行了操作、批准覆盖哪些内容。
首次使用时应核对的默认值
| 工具 | 本次核验的初始行为 | 调整与限制 |
| Orca | 新装 agentPermissionDefault 为 full-access；Claude/Codex 终端启动映射到相应 bypass 参数 | 可以改权限选择或跟随 Agent 自身配置；已有 profile 不一定等于新装值 |
| Herdr TUI | agent start 默认额外参数为空，不主动追加 bypass | Agent 自己的配置或用户参数仍可能允许宽权限 |
| Herdr App | 默认启动项为 claude、codex --no-daemon 等，没有额外追加 bypass；App 0.1.14 的 Codex 独立会话处理要求 Codex 0.156+ | 实际 Agent 配置仍有效；core 不是 permission broker，Mods 没有逐次程序/网络请求批准 |
| Paseo | 优先 draft/保存偏好，其次 Provider 默认；Codex 默认 auto，Claude 一般默认 auto | Codex 的内置映射为 on-request + workspace-write；Provider 有例外，Antigravity 路径仅 Full access |
| T3 Code | 新 thread 内置默认 Full access，使用新 thread 设置而非直接继承刚查看的会话 | environment/project 可以覆盖，managed policy 可以限制；底层 Provider 仍有差异 |
| Codeg | v0.42.1 Claude 新会话默认 Auto；Codex adapter 文档默认 Auto review | 既有配置与 composer 可覆盖；文件/命令还需检查由 Codeg 还是 Agent 处理 |
这些值适合成为首次运行检查项，最终执行边界还取决于实际 Provider、配置、凭据、运行用户和部署环境。
Herdr App 的 Mods 是可信 JavaScript，可运行程序、读取文件、发网络请求，并在连接的机器上执行操作，没有每次程序或请求的权限提示。Core API 也以当前用户权限执行，不提供逐客户端 sandbox；把 template 描述为「只读 reviewer」不构成强制隔离。这里需要分别审视 Agent 自身批准模式，以及 App/core 客户端和 Mods 的信任范围。
Codeg 的文件与命令代办需要额外理解
Codeg 默认通过自身进程向 ACP Agent 提供文件与 terminal channel，官方明确说明自身不新增 sandbox。即使某个 Agent 进程有 sandbox，也不能自动认为 Codeg 代它完成的操作落在同一个边界内。
每个 Agent 可以开启「Let the agent handle files and commands」，把这些操作交回 Agent 自身。这个选项默认关闭；开启后，Codeg 同时移除该 Agent 的 delegation group，避免再经另一个 Agent 代办操作。
因此，在这条接入路径上，依赖 Agent 自身执行边界与担任 Codeg 跨品牌委派 lead 存在具体取舍。需要严格限制文件和命令访问的项目，应先验证这组设置，再决定如何组织主从协作。相关实现
浏览器权限也不能从总开关推断全部行为。Codeg 的 browser tools 默认关闭，但启用后的默认分享级别为 Read and act；需要逐次选择时，应检查 Share nothing 等设置。Computer Use 默认关闭，启用后还要显式分享窗口，两套规则并不相同。
远程接手、后台运行与恢复
手机和网页主要是控制端。Agent、文件、开发服务和凭据通常仍在电脑或服务器上，运行主机需要保持在线。
如何接回不同机器
| 工具 | 跨设备与多机方式 | 连接与部署上的取舍 |
| Orca | SSH host、paired Remote Orca Server、手机 companion beta、direct 或 Relay | Relay 有登录与配对流程；BYO VM 的机器与云费用由使用者承担 |
| Herdr TUI | 多机器 SSH 聚合、每机后台 server、手机 SSH terminal | 复用 OpenSSH 和终端客户端；需要在每台远端配置环境与 Agent |
| Herdr App | core 多机 SSH、共享 spaces/终端、官方 iPhone/iPad/Android App | 手机连接 core，不接 TUI server；远端 core、Agent 和网络可达性需配置 |
| Paseo | desktop/mobile/Web/CLI 接 daemon；可选 E2EE relay 或 TCP/Tailscale/VPN/SSH | SSH 转发路径要求远端 daemon 已经运行；不自动代装并启动远端环境 |
| T3 Code | desktop/mobile/Web、T3 Connect、Tailscale、LAN、managed SSH、多 environment | Connect 是托管身份与连接路径；linked environments 跨机委派为 beta |
| Codeg | desktop Web Service、standalone server、Docker、remote workspace、原生手机客户端 | 手机端仍为测试版本；自行处理 URL、token、HTTPS/VPN 与主机运维 |
Codeg 的远程 token 面向同一个工作区，不能当成具有分用户隔离和项目级只读权限的团队系统。把个人工作机供自己手机访问，与把一个 server 提供给多个互不信任的用户，是不同部署需求。
四种恢复情况应分开测试
| 情况 | 可以确认什么 | 不能直接推断什么 |
| 关闭页面或客户端 | 如果任务由仍在运行的 host/server 持有，可以与 UI 生命周期分开 | 关闭本地应用也会保留它启动的所有进程 |
| 网络断开再连接 | 可以恢复控制连接，重新读取 host 状态 | 断网期间每条消息、批准与通知都已准确执行一次 |
| daemon、server 或 Provider 重启 | 可能恢复历史并创建新进程；有独立 holder 的更新路径也可能保留原程序 | 所有服务重启都等价，或某种架构的恢复保证适用于其他工具 |
| 操作系统重启 | 可以重新启动服务，并按产品规则恢复支持的会话 | 内存、进程和所有进行中的外部操作原地继续 |
Herdr TUI 明确把后台 server 与 client 分开：detach 或 SSH 断开时，server 可以继续持有终端。Server 或机器重启后可恢复布局；启用会话恢复且保存了有效 session reference 或 resume command 的 Agent，可在客户端重新接入后恢复会话。原进程不会保留，普通测试进程与服务仍要重新启动。
Herdr App 关闭窗口时，由 core 继续持有终端；关闭 pane/tab 才结束相应终端。Core 通过独立 holder 支持特定更新和 restart 路径保留运行程序；机器重启或 holder 丢失后的 kept pane 恢复，则只启动原目录的新 shell，不自动重跑任务或 resume Agent。Unix 上刻意 detached 的服务还可能在关闭 terminal 后继续运行，端口清理需要另外确认。
Paseo 的 restart recovery 默认关闭。启用后会重开符合条件的 Provider 会话，并发送继续工作的提示；这是 best-effort 恢复，文档明确可能丢失或重复 continuation。完成通知也采用 at-least-once 语义。
T3 Code 的后台 service 重启会中断 turn、terminal 和 remote client。其持久事件与会话恢复能力有助于重连，但不能把已丢失的 Provider 外部操作简单重放。平台也有差异：本次版本的 Windows 路径没有与 Linux/macOS 相同的后台 service 安装能力。Linux 可通过 systemd lingering 在退出登录后继续运行；macOS 服务随登录运行，退出登录会停止，长期在线时还要保持主机唤醒。
Orca 的远程 runtime 与 terminal host 有分进程设计，支持 SSH 重连和部分会话 resume/hibernation；这仍不构成所有 cold reboot、terminal host crash 的统一恢复保证。Codeg 的会话记录和部分中断委派可恢复，关闭 pane 与退出整个应用的进程语义也不同，不能统称为任务永远常驻。
如果使用场景是「出门后手机处理等待」，先测客户端断开即可；如果使用场景是「无人值守运行一整夜」，还要测试 host 服务、浏览器、子任务和外部操作在重启后的行为。
隐私：分别检查模型、遥测与远程服务
本地运行描述的是计算位置；产品遥测、Agent 模型请求、更新检查、远程控制和托管服务，是不同的数据流。自托管不会自动关闭底层 Agent 的联网行为。
| 工具 | 官方声明与静态实现 | 需要主动核对的设置 |
| Orca | 新装产品 telemetry 默认开启；官方文档排除代码、prompt、终端输出等内容，使用 PostHog Cloud US | Settings、DO_NOT_TRACK 或 ORCA_TELEMETRY_DISABLED；Relay 登录与控制流另看 |
| Herdr TUI | 本次未发现同类产品使用遥测实现；已确认版本与 Agent detection manifest 检查默认外联 | update/manifest 检查；如启用 pane history，还要管理包含输出的本地记录 |
| Herdr App | release 默认开启每日 usage telemetry；官方声明不含终端文本、prompt、文件内容和路径 | Settings → Privacy 可查看/关闭；App/core 更新、Mods 请求与本地未加密状态另看 |
| Paseo | 官方声明本地软件无 analytics/telemetry/crash reports；Provider、更新、relay 与 Hub 另有数据边界 | 是否启用 relay/Hub、远端访问密码与网络、Provider 自身策略 |
| T3 Code | 产品事件默认开启；配置了 tracing 的客户端构建还发送连接诊断，通知 activity 与移动端诊断另有规则 | server、browser/mobile、crash report、activity 等开关不能视为同一个总开关 |
| Codeg | 官方声明无自身 analytics/telemetry；存在模型、Git、更新、价格目录与可选同步请求 | Web Service token、远程访问范围、WebDAV snapshot 加密、秘密的存储与备份 |
Herdr App 的每日 usage report 包括随机 install ID、App/core 版本、OS/架构、分桶用量与数量、已知 Agent 和内置布局名、Mod 数量及命令名；官方声明排除终端文本、prompt、文件内容、路径和自由文本名称。关闭遥测可删除本地 ID 和未发送队列，但不关闭更新或 Mod 请求。其官方手机页的无 analytics 声明，不能扩展成桌面 App 无 telemetry。
产品遥测开关不一定覆盖所有客户端
T3 Code 的产品事件文档列出 Provider、model、mode、结果、耗时和 token 等字段，声明不包含 prompt、response、文件内容或 auth token。T3CODE_TELEMETRY_ENABLED=false 可以关闭 server 的相关产品事件与 tracing，但独立 Web/mobile 不读取该 server 环境变量。Web/mobile 目前没有独立的 relay tracing 开关，移动端「Send crash reports」也不控制 tracing。
移动端 crash reports、relay tracing，以及 Publish agent activity 也有各自语义。用于通知的 activity 可包含 project/thread title、model、status 与标识符，telemetry opt-out 不会自动关闭这条发布路径。需要降低外联数据范围时，应分别确认各项是否有可用控制，以及所选客户端是否符合要求。
Orca 的新装 telemetry 默认值与旧 profile 的待确认状态不同；关闭某个 banner 也不能直接视为拒绝采集。Paseo 与 Codeg 的「无自身 telemetry」是官方声明，本次未对发布二进制做全链路抓包，不将其扩展为所有依赖与模型请求都不外联。
Relay 的信任模型并不相同
Paseo 的可选 relay 使用应用层端到端加密，relay 仍能观察 IP、时间、大小等连接 metadata。Orca 的手机连接实现也有 E2EE 通道，但本次没有对协议进行独立密码学审计。
T3 Connect 使用身份服务、受信任 broker 与 host 的 Cloudflare tunnel；不能因为同样叫 relay，就把它画成与 Paseo 完全相同的信任模型。T3 还提供 Tailscale、SSH 和私有网络等访问路径，是否使用 Connect 可以单独决定。
Codeg 主要连接使用者自己的 host，不要求 Codeg 托管中转账号；这也意味着地址可达、TLS/VPN、token 和更新由使用者负责。官方文档还明确，部分 API keys、Agent 环境变量和远程 token 在 SQLite 中未加密；系统钥匙串并未涵盖所有秘密。需要备份或迁移数据目录时，应把这部分一并纳入管理。
各个运行选项适合怎样的项目
Orca：完整桌面开发工作台
Orca 值得优先试用的项目，是同时需要代码修改、浏览器验证、行级 review 反馈和 Git/PR 交付的应用开发。终端与 Chat、浏览器和 diff 能围绕同一个 workspace 摆放，比较适合不希望把任务状态、页面和改动分散在不同应用里的开发者。
它还提供 setup、共享路径、多机器与手机 companion。已有成熟 shell 工作流的人也可以保留终端使用方式，而不必一次迁到 Chat。
需要投入的成本主要在配置与概念：workspace 与 host 的归属、依赖共享方式、初始化时序、权限模式，以及哪些编排能力仍属 Experimental。首次试用应先检查 full-access 和 telemetry，再让自己的实际任务经过创建工作区、审批、浏览器、review 与提交准备的完整路径。
Herdr TUI：保留终端自由度的运行与状态层
Herdr TUI 适合已经有编辑器、终端 Git、SSH 和脚本体系，希望集中管理 Agent 状态与后台进程的开发者。它让每个 Agent 继续待在真实终端中，通过 CLI/socket 与其他工具组合；跨机器也沿用 SSH 模型。
选择它可以少迁移一层结构化 Chat 操作，但需要自己拥有审查、浏览器验证和任务协议。对不熟悉终端的成员，项目也需要提供可重复的入口和命令，不能只交付一堆 pane。
值得优先测试的是常用 Agent 的状态识别、等待批准时的提示、integration 对现有配置的修改，以及 detach 与 server restart 的差别。终端技术栈本身不提供内存占用或响应速度的比较结果。
Herdr App：可定制 GUI 与独立终端运行层
Herdr App 适合希望保留真实 CLI 操作，同时需要图形侧栏、文件与改动面板、可调整布局，以及官方手机接手的开发者。Spaces/tabs/panes 由 core 保存，多个已连接屏幕共享结构与实时终端，但各自保留焦点和缩放。
它的默认 UI 本来就由随包 Mods 实现，不能把「通过 Mod 提供」理解为都要自行安装社区插件。Files 提供只读预览，Changes 提供 Git diff 和 Commit，worktree Mod 管理新分支和工作目录。这已经与 TUI 主要组合终端工具的路径不同；但 Commit 会暂存全部改动，使用前要核对未跟踪文件和不应提交的内容。
官网展示的 Chat/Code 外观也需要看具体实现。本次核验的 layout examples 中，Chat feed 主要展示状态，不是完整对话历史，输入框并不等于真实发送接口；Code 示例也不能当作完整代码编辑器。它们说明布局可以怎样改造，不证明随包已经具备与 SDK 工作台相同的结构化聊天和编辑流程。
选型代价主要是另一套 core、配置与 Mod 信任模型，以及与 TUI 不共享现有 Agent 的迁移边界。需要重点试状态上报、默认 Files/Changes 是否足够、hc 父子任务消息、关闭窗口与重启机器的差别，以及手机直连 core 的网络条件。Core API 仍处于 preview/generation 1，也要纳入脚本兼容性维护。
Paseo：可编程 workspace 与开发服务管理
Paseo 适合把多个 Agent、终端、应用服务和跨设备控制统一到 workspace 的项目。CLI、TypeScript SDK、插件、schedule/heartbeat 等入口，使它适合进一步连接已有工程流程。
它的 service 端口分配、可预测 URL 和同 workspace 服务发现，能用于组织多份开发环境。多分支 Web 项目、前后端联调，以及需要同时运行多份应用的团队，可以先用这些能力检验是否减少了手工配置。
代价包括 daemon 与 Provider 的版本配合、脚本配置、归档清理和插件信任。纯服务器场景还要注意 browser host 对桌面客户端的依赖。需要手机接手时，既测试连接，也测试批准画面、错误恢复和主机休眠后的行为。
T3 Code：围绕 thread、review 与远程环境工作
T3 Code 适合希望围绕 thread 查看 Agent 工作、比较 turn/branch/commit 改动，并在桌面或手机完成 PR 操作的项目。当前版本已经有多 Provider、CLI、MCP 与委派，不能再用「只有聊天」来描述它。
远程 environment 自己持有 headless browser，是与依赖桌面 browser host 的路径不同的实现选择。如果主要使用长期在线的 Linux 主机，这项能力值得直接放进试用任务。
配置成本主要是新 thread 的 local/worktree 与 Full access 默认、异步 setup、不同环境路由，以及分散的 telemetry/diagnostics/activity 规则。Linked environments、部分高性能 worktree 路径等 beta 能力，要与基础 thread 工作流分开判断。
Codeg：跨品牌协作、画布与任务交付
Codeg 适合同时使用不同品牌 Agent，希望把历史、根会话、文件、终端和任务交付集中组织的开发者。无限画布可以按项目、Agent 或自定义集合摆放 conversation、文件、terminal 与便签；会话卡还能展开成真实对话。
画布也有具体限制：主要承载 root conversation，委派的 child session 归在父会话下；不能把它当成所有子 Agent 都可任意拖动的依赖调度图。画布上的文件卡只读，编辑仍在 file pane 完成。
Todo 提供 worktree、初始化、review preflight 和合并流程，Repository 面板则连接 issue/PR。准备从「手动开会话」迁到「任务进入、实现、验收、PR 交付」时，可以把这一整条路径作为候选理由。
需要接受的是较多功能开关和 adapter 差异。首先确认常用 Agent 能否担任 lead，再决定普通委派是否可以共享目录，最后确定文件和命令由谁执行。手机端仍测试、Computer Use 为 Preview，release 也列出部分 Hermes 兼容限制；这些都应与核心聊天和 Todo 能力分别验收。
许可、价格与维护成本
五款核心项目均提供开源代码与公开发行物，模型推理仍由接入的 Agent、订阅或 API 提供。开源许可、桌面免费下载、托管服务配额和自备机器成本，需要分别计算。
| 工具 | 本体与许可 | 附加服务或成本边界 |
| Orca | 官网 FAQ 确认桌面免费、MIT | Enterprise support 可选；Agent 订阅、BYO VM 与云基础设施另计，未核实所有远程附加服务的长期收费承诺 |
| Herdr TUI | Apache-2.0，公开二进制 | 自备 Agent、机器、SSH 与运维；没有根据源码许可推断未来服务价格 |
| Herdr App | App 与 core 分别采用 Apache-2.0，官网当前确认免费 | Agent、远端机器与网络另计；App/core 分开维护，手机商店地区版本与 IAP 未独立核验 |
| Paseo | 核心 Apache-2.0，可自行运行 | 可选托管 Hub 有 Free/Pro；开源本地工作流不强制购买 Hub，relay 有自身服务条款 |
| T3 Code | 核心 MIT，官方说明本体免费 | Connect 文档当前列免费 3 台 host；相关 T3 Chat Pro/Premier 权益可扩至 10/100 台，额度和政策可能调整 |
| Codeg | Apache-2.0，官方提供桌面和自托管 | 模型、服务器、网络和维护自备；官网未列必须购买的 Codeg seat/subscription |
上述附加服务信息以核验日期为准，不包含移动商店不同地区的价格或 IAP 核验。
实际维护成本还包括：
多个 worktree 的依赖与磁盘占用、配置复制和清理。
Agent、SDK/adapter 与工作台版本之间的兼容验证。
远程主机、端口、TLS/VPN、凭据与备份。
插件、MCP、自动化和 issue 输入增加的执行权限与管理范围。
新成员理解工作区、权限、会话恢复和 review 流程的时间。
如果现有终端流程已经覆盖了大部分需求，Herdr TUI 的组合方式值得先试；如果维护这些零散工具本身已经耗时，集成工作台才有更明确的替代价值。Herdr App 则提供保留终端、同时增加 GUI 与 Mods 的另一种组合。选择应落到实际减少的操作与维护项目，而不只是功能数量。
按约束组合试用顺序
| 已有条件或硬需求 | 建议先比较 | 决定胜负的验收问题 |
| Neovim/终端 Git/SSH 已成熟 | Herdr TUI、Herdr App、Orca 的 Terminal 路径 | 是否保留现有操作，状态与远程管理是否减少切换 |
| 前端开发，需要页面上下文回到实现 Agent | Orca、Codeg、Paseo、T3 Code | 浏览器在哪台机器，截图、console 与反馈是否进入正确会话 |
| 多分支、多服务同时运行 | Paseo，再与 Orca/T3/Codeg 的项目配置比较 | 环境何时就绪，端口与 URL 如何分配，结束后如何清理 |
| 以手机连接常开主机为主要入口 | Herdr App/core、Paseo、T3 Code、Orca、Codeg | 批准信息、diff、断线恢复与 host 在线要求是否满足需求 |
| 希望不同品牌 Agent 委派实现与审查 | Codeg、Paseo、T3 Code、Orca | 常用 Provider 是否真能发起委派，子目录、权限和结果如何管理 |
| 需要 task/attempt 级归属与结果回执 | Orca 的 Experimental 编排；其他工具的任务/API 方案 | 重试与旧回执如何区分，父任务何时确认结果，失败如何接管 |
| 任务主要来自 issue/PR，期望连接 review 与交付 | Codeg、T3 Code，再核对其他工作台与现有流程 | forge 是否匹配，外部任务权限、验证和合并规则是否清楚 |
| 不希望依赖官方托管中转 | Herdr TUI SSH、Herdr App/core，其他工具的直接/自托管路径 | 是否能使用自己的网络，哪些功能仍需第三方身份或连接服务 |
| 保留真实 CLI，希望用 GUI 看文件和 diff，或按需改造窗口 | Herdr App，与 TUI + 现有工具组合比较 | Files 的只读边界、Commit 范围、Mods 信任、状态兼容与旧任务迁移成本 |
| 需要互不信任用户的隔离环境 | 先确定独立用户、容器/VM与身份方案，再比较工作台 | 能否隔离文件、凭据、进程与网络，而不仅是增加登录入口 |
无需把全部能力都放到同一个工具里。可以用终端运行层维持任务，用已有编辑器审查；也可以统一到一个完整工作台。需要保证的是任务归属、写入目录、权限和验收入口清楚，避免两个控制面同时修改同一套状态。
用同一个项目完成最后一轮试用
选型前可以准备一个临时 Web 项目，给列表加入 CSV 导出。固定字段、权限要求、空数据行为和测试命令，再使用相同 Agent、模型、上下文与权限模式执行。下面是试用协议，结果应在实际运行后填写。
| 阶段 | 操作 | 应保留的证据 |
| 开工 | 从干净基线创建实现任务与审查任务，选择是否使用 worktree | App/Agent 版本、branch、cwd、模型、权限、初始化完成状态与人工步骤 |
| 并行环境 | 同时运行两份应用或前后端服务 | 实际端口、URL、配置来源，以及是否影响另一个目录 |
| 批准 | 触发一项需要批准的命令，先阅读再处理 | 实际命令与工作目录是否可见，批准作用范围，手机与桌面的差异 |
| 委派 | 让实现 Agent 交出一个独立审查任务 | worker 是否启动、目录与上下文、权限、结果如何返回、是否可接管 |
| 审查 | 检查未提交文件、已提交改动和一项不应进入变更的文件 | diff 基准、文件覆盖范围、行级反馈与修改回流 |
| 验证 | 运行项目测试并操作页面 | 真实命令输出、页面行为、console、截图与实际运行主机 |
| 跨设备 | 离开桌面，在另一客户端读取状态并回复问题 | 是否是同一任务，批准上下文、重连后状态与通知 |
| 恢复 | 在试验环境分别测试断网、关闭客户端、服务重启 | process/session 标识、未完成任务、重复或丢失的消息与外部操作 |
| 交付准备 | 审查最终改动、处理一次冲突或 PR 反馈 | 验证依据、目标分支、未跟踪文件、人工确认步骤 |
| 清理 | 归档试验任务，检查 worktree、进程和数据是否保留 | 归档与删除的差别、清理范围、需要保留的历史和配置 |
对最重要的两三项任务重复试用，再记录操作次数、响应、错误恢复和资源占用。性能比较还需要固定机器、缓存、并发与网络条件。最终保留能覆盖真实工作流、配置成本可接受，并且失败时容易查明状态的候选。