从 Codex 到 Cindy：我如何用 Personal Agent 与 magpie 组织 AI 协作

最初，我只是想找个 AI 助手，帮我把项目里的事情做得快一点。

这样的助手可以自己读文件、改代码、运行命令，再根据结果继续工作，通常被称为 Agent。我先后用过 OpenAI 的 Codex 和 Anthropic 的 Claude Code，也借助开源桌面工具 CC Switch 切换模型和供应商。哪家用起来顺手，哪家在特定任务里更稳，都是我一点点试出来的。

窗口越开越多，我发现自己花了不少时间照顾工作本身以外的事情。同一个项目换个客户端，背景就得重新交代一遍；任务说明、规则、交接记录和验收标准，也常常散落在不同地方。于是我把它们整理到各自的项目里：博客一份，交易研究一份，SEO 站点一份。这样换一个客户端打开项目，也能找到同一套工作约定。后来我才知道，围绕 Agent 组织工具、规则和运行环境的这套做法，常被称为 Harness。

产出多了，新麻烦也来了：两个线程改同一份文件，合并时才发现撞车；某个线程还在按照我早已调整的优先级干活。我希望有个助手帮我照看这支越来越大的 AI 团队，而目标和重要取舍仍由我自己决定。这就是我开始用 Cindy 的原因。它有开源客户端（makecindy/cindy），可以连接不同的 Agent，帮助我延续背景、习惯和协作方式。我把这样一个围绕个人长期协作的助手，称作 Personal Agent。

再往前一步，我接上了 magpie，一个把各家模型接进同一个入口的开源项目。Cindy 的请求先过 magpie，用了哪个账号、占了多少上下文、缓存命中多少，都有地方可查。

我真正想要的，是一个长期围绕我成长的 AI 伙伴：像游戏里的 NPC，带着职责和记忆，长期托管、监督、参与我交给它的项目，在关键节点陪我判断。这条路也可以看成一次架构迭代。每一步都为了解决上一步暴露的瓶颈：

单窗口 → 规则文件（Harness）：解决背景反复交代。

规则文件 → Lead/Worker 团队：解决多个窗口互相撞车。

团队 → magpie 请求路由：解决额度和请求去向看不清。

团队 → Issue/PR 闭环：解决交付没有台账、没有验收。

单条闭环 → 多个研发组：解决一条流水线吞吐不够。

多组 → 服务化：解决流程卡点集中在一个节点。

服务化 → 团队管理 AI（分身）：解决人要挨个对齐、开会拍板，人成为最后一个瓶颈。

客户端自带 Harness → 基于 Pi 的自有轻量工作流：解决自带框架太重、不好定制，吞吐、可用性和并发都被它卡住。

下面沿着这条路写：协作怎么长成团队，请求怎么管，闭环工作流怎么跑，多组并行时架构怎么拆，组多了以后怎么从开会走向异步，最后回到伙伴。

一、从规则文件，到 Lead 和 Worker

我把规则写在项目根目录的 AGENTS.md 和 CLAUDE.md 里，这是不同客户端默认会读的文件名。项目管稳定背景，人管目标和验收，Agent 并行执行。代价是：两个窗口撞文件、方向不一致、上下文反复从零读起，靠人盯盯不过来。

我设想过七个长期角色线程围着任务板协作，结果每个线程都背上了协调责任：反复查任务板，文件互斥靠提示词，优先级在上下文里漂移。黑板能共享状态，长不出调度者。

后来我换了一种方式：让一个总调度者照看全局，执行者专心处理各自的任务，完成后再交回去。在这套分工里，Lead 负责组织，Worker 负责执行。这是我的使用判断，还没有做过两组 Agent 的对照测试。

Cindy 文档里还有一个区分：短平快的小活，主会话派一个用完即弃的 subagent 就够；真正费时、要并行、要持续跟进的事，才用团队模式，由 Lead 拆任务，多个 Worker 各领一块。文档也提醒：Worker 数量是产品容量上限，不是越多越好。

项目里的协作逐渐理顺后，我又开始想：这些项目都属于同一个人，谁来理解这个人的背景和习惯？

二、几层能力怎么摆

我把研究过的项目按主要关注点分成几层，方便自己理解它们各自解决什么问题：

任务编排：LangGraph、CrewAI。

Agent 运行底座：接通模型、工具、会话。我研究最多的是 earendil-works 团队开源的 Pi（Agent 工具箱）。

代码隔离：Stably 的开源项目 Orca ADE，为每个 Agent 开独立工作树（worktree）。

记忆组件：Letta、mem0。

个人助手：把记忆、工具、不同 Agent 收进一个协作入口，Cindy 在这一层。

Pi 把「搭一个能跑的 Agent」的门槛降下来；Cindy 在上面叠一层，围绕长期用户组织协作。Personal Agent 因此是几层的组合：底座让 Agent 跑起来，个人记忆延续背景，权限层划边界，工作流层记录状态和验收，交互层让人派活和纠正。底座有会话续接，但那不等于跨项目的个人记忆。

名字容易撞：Cindy 内置的 Orca 和 Orca ADE 是两回事。Cindy 的 Orca 是多 Agent 协作机制，Lead 会话拆任务、验收，Worker 是有自己模型和历史的完整会话。架构文档写明：Worker 默认共享 Lead 的目录或 worktree，所以「开了 worktree」不等于每个 Worker 自动拿到独立副本，冲突要靠任务切分和分支来避免。

三、我的判断，分三类看

用过的（只是使用印象，没做对照测试）：跨 Agent 延续习惯，换客户端不必从头解释；在一个客户端里选不同供应商的模型、同时开好几个任务；任务共享、供应商分享、SSH 远程开发用着顺手。

三种共享方式要分清，授权不同：

共享任务：受邀的人进入同一份历史和 Agent 会话，任务仍跑在房主设备上，发邀请等于交出这份任务的能力。规则

供应商分享：借出模型额度和 Agent 运行能力；对话和读到的文件会经过分享者的电脑。规则

SSH 远程工作区：Agent 在远程主机上工作，远程项目也能做 Lead。说明

我会先拿不含敏感资料的小任务试，讲清费用谁出、内容经过哪台机器，再扩大范围。具体能不能用，还要看装的版本和服务端。

读文档得来的：跨 Harness 共享记忆、MCP（Agent 调用外部工具的统一接口）、Skills（可复用的指令块）、Lead/Worker 编排。这些是产品方向，我没逐项验证。

还没验证的：跨项目记忆会不会串味；能不能分清临时偏好和长期习惯（误记比不记更危险）；长任务状态归拢到底有没有减少我手动追踪的时间。

四、Cindy 管协作，magpie 管请求

模型来自不同地方，各有额度。今天某个账号能用，明天可能进入等待窗口；任务变慢，也得知道是哪一端在回答。CC Switch 擅长改配置、一键切换，但请求去了哪里、缓存命中多少，它看得不细。我需要一处常驻、能对账的入口，于是用上 yetone/magpie：客户端把请求交给它，它按设置送往具体供应商。

magpie 已有专门的 Cindy 适配：通过 cindy://provider/import 链接在 Cindy 里确认添加，并分别给 Claude Code、Codex、Pi 配好协议入口，不会直接改 Cindy 的数据库。集成说明、适配源码我说的「结合」只是供应商接入和请求管理这一层，不是两个项目合并。

我截过一张路由图：Cindy 发起请求，经过本机 127.0.0.1:3425 的 magpie，由一个启用的 Codex 账号回答，页面能看到实际模型、上下文占用和缓存命中。好处是请求去了哪里可查，不用靠界面上的模型名猜。但这张图只开了一个账号，证明不了多账号路由省了钱。

用法	优势	代价
Cindy	背景、任务入口、共享与远程开发能接续	要管记忆、权限、执行设备和任务状态
magpie	多来源模型、额度、路由和用量集中可查	多一层网关的运行与配置维护
CC Switch	一键切换供应商，本地路由，集中管 MCP/Skills	以改配置为主，聚合模式无故障转移，用量不如请求级细
Cindy + magpie	协作与请求路由各有清楚的管理位置	链路更长，排障和版本匹配更复杂

CC Switch 是我从单工具走向多供应商的过渡方案，现在的分工是：CC Switch 快速试配置，Cindy 调度 Agent，magpie 把请求送到合适的模型和账号。CC Switch

magpie 的意图路由在用户每发一轮新消息时，由分类器按我写的规则选模型；分类器本身多一次调用，增加等待和费用，Agent 连续调用工具时不会每步重分流。规则没写清之前，我不开它。说明

两层之间的代价是排障：如果 Cindy、magpie、供应商各自重试，同一次异常会在几层里绕。所以我的分工是：路由和后备交给 magpie，协作状态和交付归 Cindy，重要任务同时记下任务上下文和实际用的模型。还有个细节：SSH 主机上的 Agent 访问 127.0.0.1，连到的是远程主机的 magpie，不是我笔记本的。Remote magpie

我会根据实际需要决定是否接入 magpie。Cindy 自带的供应商配置够用时，直接用也很方便；如果接入，我会拿同一组任务与原来的方式比较。要是维护和排障花的时间超过了省下的时间，我就把链路简化一些。

10 月 13 日：额度不再卡在一个账号上

订阅账号有 5 小时、7 天的用量窗口，以前用满就得停。现在我在 magpie 里把自己有权使用的账号和 API 编成「路由组」：顺序组先用第一个，不能响应再往下；「智能」组优先用有余量、快重置的账号。测试和复杂推理给强模型，简单问答给便宜模型。这只是把已有额度用得更充分，不会抬高任何一家的上限，账号全用尽任务照样停。

当天的用量面板：

5,250 次请求，约 1.25B tokens；缓存读取约 1.21B，新输入约 37M，输出约 3.2M，缓存命中率 96%。

47 次失败，其中 16 次重试后成功。

按标价估算约 162 美元以上（24 次调用无价格数据，所以只是下限）。

用量最大的来源是 OpenCode Go（约 740M tokens、3,114 次请求），其次是 Codex（约 219M tokens）。

我读出两点：绝大多数输入在复用上下文；请求确实分散到了多个来源。标价估算不是账单，一天的数据说明不了长期能省多少。

五、闭环 GitFlow：Issue 进来，PR 出去，QA 收口

工具接通后，真正让团队跑起来的是工作流。我正在逐步改用 GitHub 的闭环流程：Issue 提需求和 bug → Lead 协调拆分 → Worker 执行 → 提交 PR → 专门的审核合并 → QA 交付。 还在试，下面是我的做法，不是已经跑出的稳定数据。

Issue 是唯一台账。 需求和 bug 先开 Issue，正文放我的原话、可量化的验收条件和截图。改某个模块前，先搜它的历史 Issue 和 PR，避免和已登记的要求冲突。

Lead 接手，分诊并拆边界。 判断优先级，检查和在途任务撞不撞车，拆成一张「覆盖矩阵」：每行一项可验收的任务，写明谁负责、交什么。很小的活交给 subagent，不开团队。

Worker 在独立分支和工作树里执行。 分支从当前发布线切出，同一个工作树同一时间只许一个 Agent 写。不重叠的文件才并行，有依赖的等上游收敛。

Worker 提 PR，不自己合并，也不部署。 PR 写清关联的 Issue、改动、验证命令和结果、逐条对照验收的结论，以及没验证的部分。

专门的审核合并。 审核是独立角色，不是写代码的 Worker。它对照 Issue 里的原话检查，有问题在 PR 上写明并退回；通过后合并，并跑全量门禁（构建、类型检查、测试、lint）。

QA 独立验收并交付。 按覆盖矩阵逐项验收，失败带复现步骤退回；开发不能为变绿删改测试。支付、短信这类外部账号先用 mock 跑通流程，真实凭据没到位之前只能标「未验证」。QA 通过后，由 Lead 发 Release，逐条列出合入的 PR 和关闭的 Issue。

Bug 走同一条路；线上事故、数据或安全问题优先，Lead 暂停相关 Worker，记录暂停点和恢复条件，修复经 QA 验收后再恢复原任务。

要说清两点。「隔离」靠分支和工作树，是我在流程里设定的，不是 Cindy 自动给的。合并权限放在审核还是 Lead，我还在调，要看人数和风险。这套流程的代价是多了几道等待，小改动可能被拖慢，我会用等待时间、返工次数和验收失败数来判断值不值。

六、多个研发组并行：从单体到服务化

先借软件架构的老路来理解。入门读者可以这样看：单体是把所有功能放进一个程序，改一处就整体发版，简单，但越大越慢；微服务是把功能拆成几个独立服务，各自开发、各自部署，靠接口对接，灵活，但要付出协调和运维的成本。多数团队先做单体，流程卡住了才拆。

我的 AI 团队也走了同一条路：

单体：一个 Agent 包办需求、编码、测试和合并。窗口越多越乱。

单体拆出 Lead 和 Worker：一个 Lead 带多个 Worker 并行。Lead 成了所有任务的必经之路。

流程卡点：研发、审核、QA 都挤在同一个 Lead 上，审核排队，Lead 的上下文越来越长。

服务化：按职能拆成独立的研发组、审核组、QA 组，各自有边界和接口（Issue、PR、验收矩阵）。卡点变成可以单独扩容的服务。

这是我正在调试的方向：把 AI 资源做成微服务化的架构。具体来说：

研发组是一个服务，接收 Issue，产出 PR；

审核组是另一个服务，只消费 PR，输出合并或退回；

QA 组消费已合并的版本，输出验收结论；

Lead 不再亲手做所有事，只负责路由和划边界。

有经验的程序员可以直接对照着看：

Issue 和 PR 模板，相当于接口契约，约定输入和输出的形状。

分支和工作树，相当于服务隔离，改一个组不影响另一个组。

magpie 路由组和多账号，相当于负载均衡加熔断降级：某个来源用尽，流量切到另一个。

用量面板和请求记录，相当于链路追踪和监控。

AGENTS.md 和项目规则，相当于配置中心，所有组读同一份。

GitHub Release，相当于统一的部署和版本号。

这个类比有边界。Agent 的输出不确定，接口契约只能约束形状，约束不了内容，所以服务化之后仍要靠 QA 把关。服务越多，跨组的接口漂移、重复劳动和版本不一致也越多。

多组并行带来的扩容

流程闭环之后，Cindy 客户端可以同时启动多个研发组，每组都是一套完整的 Lead + Worker + 审核 + QA，各自领不同的 Issue、各自在自己的分支上跑。这给团队的技术支撑能力带来三个方向的扩容，这是我在设计的目标，还没有长期数据验证：

高并发。 并发靠研发组的数量扩，不靠一个 Lead 带更多 Worker。每组按模块或 Issue 划边界，互不改同一批文件。真正的上限是冲突率和审核吞吐，不是开了多少窗口。

高可用。 状态存在 Issue、PR 和分支里，不存在某个对话里。某一组的 Lead 卡死、Worker 失败或额度用尽，只影响它自己那组，其他组照常推进；换一组或新开一个会话，从 Issue 和 PR 的记录就能接着做。

容量弹性。 多组并发会同时放大模型请求，这正是 magpie 路由组和多账号的用处：请求分散到多个来源，一个账号碰到用量窗口，不会拖停所有研发组。

多组并行也有代价：Worker 数量有产品容量上限；组越多，审核和 QA 越容易成为瓶颈；多组的请求叠加，账号额度和费用要持续核对。所以我会从两三个组开始，按冲突、等待和审核排队的情况再加。判断标准很简单：每增加一组，单位时间合入的 PR 是否随之增加。如果没有，瓶颈在审核或边界划分上，该先补那里，而不是继续开组。

服务化之后：从开会到异步

组一多，我就不能再像原来那样，把研发、审核、发版的 Lead 拉到一起开会了。每个组都在跑，状态每小时都在变，逐个对齐既慢，又忙不过来。流程跑通之后，我遇到的卡点已经从执行变成了我自己。

所以我在试一个团队管理 AI。它不写代码，也不替代某个组的 Lead，只做三件事：

采集状态。 通过 Cindy 的协作接口，读取各组 Worker 的工作状态、排队消息和卡住的任务，汇总到一处。Issue 和 PR 的状态作为事实依据，它的汇总以此为准。

调度与拍板的前置。 把新需求和待决策事项分给合适的组。可逆、低风险的决策按我定好的默认先推进；涉及资金、外部系统或不可逆操作的，整理成一条问题交给我。

同步临时记忆。 各组之间的约定、已拍板的结论、当前优先级，由它写回共享台账，避免每个组各记一套背景。

分两个阶段走。第一阶段它是「汇总员」：每天把需求和待拍板事项集中给我，我拍一次，它记下来。第二阶段它成为「分身」：从我的拍板记录、纠正和理由里学习偏好与取舍，在我设定的边界内自动决策、自动调度，只把超出边界的事拉回给我。团队忙闲不均时，它调配任务量；某一步卡住时，它改派或调整顺序。走到这里，人从「开会的人」变成「定目标和边界的人」，整个团队可以异步运转。这就是我说的全自动 AI 公司的最后一步。

这一步目前只搭了前半段：汇总和拍板前置在跑，自动决策还没有上线。对我来说，更难的是让它理解判断背后的理由。它能参考的毕竟是我留下过记录的那部分取舍，所以我会把「可以自动决定的」和「必须本人拍板的」分开列清楚，并要求每一次自动决策都能追溯：谁决定、依据什么、能不能撤回。

写作当时的最新一步：放下自带 Harness，用 Pi 搭自己的

团队管理 AI 跑起来之后，我发现另一个拖后腿的东西：Codex、Claude Code 各自带的那套 Harness。它们为通用场景设计，会话、权限、记忆、工具的组织方式都绑在客户端里。我要的是几十个组并行、状态能被外面的管理 AI 读到，每多一层封装，就多一层改不动的地方。

所以我基本放弃了它们自带的 Harness，借助 Pi（前面说的 earendil-works 那个开源 Agent 工具箱）重新搭了一套只属于我的轻量协作工作流：只保留我真正用到的会话、工具和状态接口，规则、分支约定、验收口径放在项目里，由我自己定。Codex、Claude Code 退成可替换的模型和执行端之一。

就我的体感，项目吞吐量、可用性和并发量都大幅提升：框架轻了，启动一个组的成本低，一个组出问题只重启它自己，管理 AI 要读的状态也更统一。这是我的使用感受，我还没有长期数据；它的代价是维护全落到我自己身上，升级、兼容和排错没人兜底。判断标准同样简单：同样的项目，吞吐和故障恢复时间是否真的优于用自带 Harness 的时候。

七、Personal Agent：一个长期的伙伴

我想象中的伙伴像游戏里的 NPC：有稳定的身份、职责、记忆，和我共同经历的项目线索。它知道我在推进哪些项目，托管日常跟进，提醒风险和等待项，在授权范围内协调其他 Agent，但目标、优先级和关键取舍仍由我来定。聊天、纠正和复盘会补全它对我工作方式的理解，有效的路线沉淀下来，成为下次的起点。

分工大致是：我定目标和边界，伙伴承接长期背景，Lead 负责当前任务，Worker 干活，审核和 QA 把关。

团队管理 AI 是这个伙伴在工作里的一个落点：它代我在各组之间传话、排优先级、先做初筛，我只在边界之外出手。

最终我希望它能从长期协作中提炼我的判断框架和工作路线，必要时在授权范围内复现，也就是「把自己蒸馏给 AI」。这是方向，不是已经实现的复制：它需要持续校正、清楚的权限边界、可追溯的依据，以及我对重要结果的验收。

八、我可能错的地方，以及现在的判断

我给自己留的余地：影响代码和外部服务的动作，验证前由我或项目 Harness 触发；记忆先小后大；重要任务保留 Issue、PR 和 QA 记录；执行端至少留第二个客户端。下面这些情况出现，说明我错了（阈值是我自己定的）：

原生能力够用。 只靠 Claude Code 和 Codex 自带的多会话与记忆，跑一周同样的项目，如果「重复交代背景的次数」和「出错次数」与用 Cindy 时相当，助手这一层对我就没价值。

新鲜感。 用三到四周后，我打开它的次数掉到一半以下。

记忆串味。 串味带来的返工多于省下的重复说明。

流程拖慢交付。 Issue、PR、审核、QA 的等待时间超过直接改代码，流程就该简化。

多组没有增产。 开了更多研发组，单位时间合入的 PR 却没增加。

自建框架维护不动。 升级、兼容和排错的时间超过它省下的，就回到客户端自带 Harness，或只保留最薄的一层。

分身替我拍错。 自动决策的错误率超过我能接受的范围，或发现它用了我没认可的标准排优先级，就收回自动决策权，退回汇总模式。

服务化变成协调税。 组数多了，接口漂移、跨组返工和版本不一致的成本超过并行省下的时间，就该合并组、减少边界。

截至本文最初写作时（2026-10-03），我的主力工作流是 Cindy + magpie，加上 Issue → PR → 审核 → QA 的闭环，并逐步用多个研发组扩容。那时我把重复交代背景、搬任务、协调合作交给 Cindy；把模型选择、额度安排、路由和成本核对交给 magpie；只想快速换配置时，CC Switch 仍然轻便。只有一个项目、一个主力 Agent，也没遇到额度和协作问题，现有客户端可能就够了。

窗口和模型都会换。我想积累的是让它们协同的方法：清楚的目标、可复用的 Harness、闭环的流程、可检查的交付，以及一个在共同工作中持续学习、也持续接受我校正的伙伴。

后续更新（2026-11-02）：从 Cindy 到多工具组合，我开始按任务选择

Cindy 对我仍然有重要意义。它让我理解了长期伙伴、Lead/Worker、任务拆分、记忆和交接这些多 Agent 协作概念。对刚开始尝试多 Agent 的人来说，我觉得 Cindy 值得体验：角色化的协作方式很直观，也能帮助我把“让 AI 一起做事”变成具体工作习惯。但这不意味着跨设备接续或长期记忆是 Cindy 的独占价值，也不意味着它适合我所有阶段的工作。

后来，随着我手上的项目和并行任务变多，我开始遇到新的摩擦。在我自己的使用中，团队和任务的协调、背景与状态的维护逐渐占去不少精力；当我希望根据项目、工作区和执行会话来调整组织方式时，Cindy 的一些限制也让我觉得灵活性不够。这是我的阶段性使用体验，不是对 Cindy 做过系统测试后得出的普遍结论。

我现在会把选择拆成三类，而不是把它们排成一个总榜：

Codex、Claude 官方应用：当任务主要由一个 Agent 完成，或我需要某家厂商自己的桌面体验和专有功能时，我优先考虑对应的官方应用。

Paseo：它更像开发工作流与多 Agent 编排的控制台，适合我需要跨 Provider 协作、并行推进多个独立任务、使用 worktree 隔离，或统一查看文件、Diff 和测试结果时使用。

Cindy：它把跨设备 Agent 伙伴、远程操作、消息渠道和自动化放在一起，也提供代码工作区。对刚建立多 Agent 协作习惯的人，这套角色化入口仍有学习价值。

Paseo 提供桌面和移动界面，也能查看工作区、文件、改动、终端和内置浏览器。它通过各家 Provider 的命令行工具或接口启动 Agent：按官方接入文档，Codex 使用官方 codex CLI 与 app-server，Claude Code 使用 claude CLI 与 Claude Agent SDK（Codex 接入、Claude Code 接入）。Paseo 可以沿用 Provider 的配置、Skills 和 MCP；至于官方桌面应用中的专有功能或云端模式，我会逐项确认是否满足自己的需要。选择时，我会同时考虑底层 Agent 的能力和使用界面的体验。

移动端接续也不是 Cindy 单方面的优势。Paseo 移动客户端可以连接电脑上的 Daemon，查看并继续宿主电脑上运行的 Agent 与工作区；Cindy 也能从手机接续电脑上的工作。两者都不是把整个代码仓库复制到手机。Cindy 另外强调云端伙伴资料同步、Provider/模型共享和手机远程桌面；这些增量对我是否重要，要看具体使用场景，而不是直接当作胜负理由。

Cindy 的客户端开源，也不等于它的完整服务端和云服务都在客户端仓库里。按 Cindy 官方中文 README 的说明，云端伙伴对话、记忆、Skill 和共享附件经 Cindy 服务同步，项目文件仍留在对应电脑。我的长期记忆主要依赖本地文档规范，因此云端伙伴记忆不是我选择工具时的显著优势。

magpie 也不是这次选择里的必选项。我会根据具体需求决定是否使用它：确实需要集中管理模型请求、额度或路由时再接入；如果当前 Agent 的供应商配置已经够用，我就不额外增加这一层。

对比维度	Cindy	Paseo
定位	跨设备 Agent 伙伴、远程操作、消息渠道与自动化；也能组织团队协作	开发工作流/多 Agent 编排控制台，围绕项目和工作区组织编码 Agent
更适合的场景（我的看法）	入门理解长期伙伴和 Lead/Worker 协作，或实际需要它的跨设备与消息能力时	跨 Provider 协作、多任务并行、worktree 隔离或统一查看开发产物时
移动端接续	可从手机接续宿主电脑上的工作；伙伴资料同步、Provider 共享、手机远程桌面是否有增量取决于需求	可连接电脑上的 Daemon，查看并继续宿主机上的 Agent/工作区；不是把仓库复制到手机
并行与隔离	团队协作仍需明确任务和文件边界，必要时安排分支或 worktree	选择 worktree 才会建立独立工作树；local 共享目录要明确写入边界。两种方式都不会替我拆任务或验收结果
长期背景	有 Cindy 服务侧的伙伴记忆能力；但我的长期记忆依赖本地文档规范，这不是我的决定性优势	我主要用项目文档承接长期背景，用 workspace/session 组织当前工作；不把它视作个人云端记忆的同类替代
上手与维护	角色化协作易理解，但项目变多后仍要管理团队、任务和背景；云端能力也要理解数据流向	需要理解 Provider 接入、项目、workspace、会话和 local/worktree 取舍；需权衡原生桌面能力是否有损失

这张表是我按自己的关注点整理的个人判断，不是完整功能清单，也不是同条件的对照测试。对我而言，现有文档规范已经承担长期记忆，Paseo 也能满足移动端接续，所以这两点都不足以单独促使我全面迁移。

我的当前选择是：日常由单个 Agent 完成、又需要厂商原生体验的任务，以 Codex 或 Claude 官方应用为主；跨 Provider 协作、多个任务并行、隔离工作区或集中查看改动时，再看看 Paseo 能否帮我省时间。Cindy 仍值得新手尝试，也适合需要跨设备伙伴、远程操作、消息渠道或自动化能力的人。它们各有所长，我会按任务搭配使用。