Conductor Cloud 关停：11 月 20 日前导出数据

出于谨慎，请在 2026 年 11 月 13 日之前完成并验证 Conductor Cloud 工作区迁移，以及依赖 Cloud 终端访问的备份。另行在 2026 年 11 月 20 日之前下载并检查账户数据归档。工作区使用 Transfer to local，账户数据归档使用 Settings → Account → Export data。

Conductor 在加入 Meta 的公告中确认，只读期间仍可查看旧聊天并导出数据。不过，公告没有确认届时是否仍能迁移工作区，以及是否仍能使用 Cloud 终端。Cloud 将于 11 月 20 日关闭，并从当天开始删除 Cloud 用户数据。

对现有用户而言，本地版 Conductor 可以提供一段时间，让你完成正在进行的工作。应把它当作过渡工具，而不是唯一的备份或永久替代方案。

Conductor 关停有哪些关键日期？

在进入只读模式之前，完成工作区迁移和依赖 Cloud 终端的备份。这项预防措施与官方公布的账户数据导出窗口需要分开看。截至 2026-11-10，Conductor 的官方时间表如下：

日期	变化	应对措施
2026 年 11 月 4 日	新用户不能再注册 Conductor 或下载应用。现有 Pro 用户可以继续免费使用 Pro 功能。	围绕已安装的应用和现有账户安排迁移。
2026 年 11 月 13 日	Cloud 工作区进入只读模式。仍可查看旧聊天和导出数据，但不能发送新消息。	提前完成需要交互的工作。出于谨慎，也应在此日期之前完成并验证工作区迁移及依赖 Cloud 终端的备份。
2026 年 11 月 20 日	Cloud 关闭，并开始删除 Cloud 用户数据。	在此日期之前完成并验证单独的账户数据导出。
2027 年初	本地版 Conductor 承诺提供新模型和关键缺陷修复的期限结束，开始逐步停止运营。	在逐步停止运营前，解除对应用的剩余依赖。

公告还承诺向仍有有效订阅的用户退款。请单独核查账单记录；退款承诺并不能证明款项已经到账。

团队迁移可以把 11 月 12 日设为内部完成目标。这是为预留缓冲时间而提出的建议，不是官方规定的迁移截止日期。不要按“11 月 20 日当天结束前仍能导出账户数据归档”的假设制定计划。

如何导出 Conductor Cloud，避免丢失未完成的工作

同时使用两条导出路径，并趁 Cloud 工作区仍可访问，独立保存尚未提交的文件内容。每份副本都应先验证，再作为恢复依据。不要假设账户数据归档能够恢复工作区中已修改、未跟踪或被 Git 忽略的文件。

先记录各工作区状态并保存文件

在迁移任何内容之前，先建立一份简要清单。记录工作区名称、仓库、分支、最新提交、尚未关闭的 Pull Request，以及负责核验结果的人。

记录快照期间，暂停代理的编辑和提交操作。趁 Cloud 终端仍可访问，在每个工作区的仓库根目录执行以下检查。请在 11 月 13 日之前完成这项工作。以下使用 Bash：

git rev-parse --verify HEAD
git status --short --branch --untracked-files=all
git diff HEAD --stat

第一条命令显示当前提交的 ID，供你记录。第二条显示分支信息，以及已修改或未跟踪的文件。第三条汇总已跟踪文件相对于该提交的差异。Git 的版本解析、状态和差异文档说明了这些行为。

在仓库内创建备份文件夹之前，将第二条命令的完整输出保存为独立备份中的 pre-transfer-status.txt。同时保存完整提交 ID 和分支名。对于删除和重命名操作，还要记录最终工作树快照中哪些路径已不存在。

这些命令只检查状态，不会保存文件内容。将已审核的提交推送到经批准的远程仓库，并在那里确认分支和提交。把该远程仓库的 URL 记入清单，URL 中不要嵌入密钥等敏感信息。对于无法推送的提交，先完成下文的 bundle 备份和恢复验证，再迁移工作区。不要为了让状态显示为干净，就把密钥等敏感信息或私人配置一并加入 Git。

检查 .conductor/settings.toml、.conductor/settings.local.toml 和 .context 是否存在，并查看其内容。Conductor 文档分别说明了这些位置中的项目脚本、本地项目配置和未提交的交接笔记。

记录环境设置命令、所需运行时版本、外部服务和环境变量名。密钥等敏感值应通过经批准的凭据存储恢复，不要通过迁移工单或代理提示词传递。

尝试迁移工作区之前，先为所需的未提交文件建立独立副本。官方文档提供的一条路径是 Sync to a local directory，它会将 Cloud 工作区同步到本地文件夹。所需文件出现后，再从该文件夹复制到另一个经批准的独立备份位置。

保留相对路径，并将清单与备份放在一起。备份应包含所需的已修改文件和未跟踪文件；需要保留的 Git 忽略文件应单独检查。敏感配置只能存放在获准保存此类数据的位置。

打开复制后的文件，与仍可访问的源文件逐一比较内容。将文件列表与清单核对，包括已记录的删除和重命名。不要编辑同步文件夹，也不要把它作为唯一备份。

如果缺少一份较小的文本文件，将源文件的完整内容保存到本地相同的相对路径。重新打开副本并进行比较。如果任何必需文件仍没有经过验证的本地副本，就停止迁移工作区。这也包括同步遗漏的二进制文件，例如 repository.bundle。趁 Cloud 工作区仍可访问，通过公告中的联系方式联系 Conductor。

备份验证完成之前，应持续暂停编辑。如果又有修改，就在最后一次更改后更新状态记录和文件副本。任何依赖 Cloud 终端的复制操作，都应在 11 月 13 日之前完成并验证。

为无法推送的提交备份 Git 历史

如果分支中有无法推送的提交，迁移前先把 Git 历史备份到本地。Git 的 bundle 命令可以将仓库引用及其提交历史打包，供断网时恢复。上文保存的未提交文件副本仍需单独保留。

创建这份快照时，暂停新增提交和分支更新。在 Cloud 仓库根目录运行以下 Bash 示例。确保 conductor-history-backup 目录尚不存在：

mkdir conductor-history-backup &&
git for-each-ref --format='%(objectname) %(refname)' refs/heads > conductor-history-backup/branches.txt &&
git bundle create conductor-history-backup/repository.bundle --all

确认 branches.txt 包含每个必需分支，以及清单中记录的完整提交 ID。通过前述文件复制路径，将整个文件夹复制到经批准的本地存储。把这份副本放在同步目录之外，并确认 repository.bundle 文件本身也已复制到 Mac。将 pre-transfer-status.txt、清单和保存的文件与这份备份一同保管。

迁移工作区前，先测试能否从这份本地副本恢复。在复制好的 conductor-history-backup 文件夹中打开 Bash。恢复目标 restored.git 目录必须尚不存在：

git clone --mirror repository.bundle restored.git &&
git --git-dir=restored.git for-each-ref --format='%(objectname) %(refname)' refs/heads > restored-branches.txt &&
git diff --no-index --exit-code -- branches.txt restored-branches.txt &&
git --git-dir=restored.git fsck

镜像克隆会将引用恢复到独立的裸仓库，不会检出工作树中的文件。原始分支清单与恢复后的清单必须没有差异。git fsck不得报告 Git 对象缺失或损坏。

迁移前，在 restored-branches.txt 中确认预期分支名和提交 ID。如果任何命令失败，或缺少必需分支，就停止操作。趁 Cloud 仓库仍可访问，先解决备份问题。

将 bundle、分支清单和未提交文件副本作为仓库私有数据保护。对每个包含未推送工作的仓库重复此流程。后续又产生提交时，应更新备份。

逐个迁移工作区，验证后再继续

出于谨慎，应在 11 月 13 日之前完成并验证每个工作区的迁移。在 Mac 上右键点击 Cloud 工作区，选择 Transfer to local。Conductor 的 0.93.0 版本说明介绍了如何将工作区及其聊天记录移到 Mac。

迁移完成后，打开本地工作区，重新运行记录状态时使用的命令。将分支、提交、未提交更改和文件内容，与迁移前验证过的清单及独立副本比较。分别打开一段旧聊天和最近的对话进行检查。

单独检查未跟踪文件和项目配置。仓库能够显示，并不代表所有文件和环境依赖都已保留。

按照项目文档中的设置流程恢复依赖。随后运行一项有实际检验价值的最小测试或构建检查。如果发现不一致，以验证过的远程仓库或 bundle 中的 Git 历史，以及独立文件副本为依据排查。只有原 Cloud 工作区仍可访问时，才将其作为额外的比较来源。

对每个需要保留的工作区重复此流程，包括未完成的实验和包含重要决策记录的旧任务。为每项核验指定负责人，不要假设其他成员已经导出了共享工作。

下载并检查账户数据归档

即使工作区已经出现在本地，也应另行生成账户数据归档。打开 Settings → Account → Export data，将下载文件保存到 Conductor 工作区目录之外。请在 11 月 20 日之前完成导出并检查结果。

在团队批准的备份位置再存一份副本。使用合适的查看工具，在本地打开保存的归档，抽查有代表性的项目记录和对话。记录导出日期，以及缺失的内容。

把这份归档视为需要检查的备份，不要假设它能直接导入另一款编程工具。可用的工作环境需要根据验证过的代码、单独保存的文件、配置、依赖和凭据重新构建。

如果找不到 Transfer to local，或迁移失败，请从下文选择对应的恢复路径。若已把提交推送到经批准的远程仓库，就从该仓库恢复；若使用 bundle 备份，则从验证过的镜像仓库恢复。只有原 Cloud 工作区仍可访问时，才能从中补回缺失内容。账户数据归档仍要单独导出，但不能以此证明未完成的代码可以恢复。

记录应用版本、受影响的工作区和完整错误信息。在截止日期前，通过 Conductor 公告中的支持联系方式寻求帮助。不要发送凭据或敏感的对话内容。

公告明确，只读期间仍可查看旧聊天和导出数据。但不要把 11 月 13 日之后的恢复操作，建立在还能发送新代理消息、迁移工作区或使用 Cloud 终端的假设上。

从备份恢复可用的工作副本

已推送的提交历史应从经批准的远程仓库恢复；通过 bundle 备份的历史则从 restored.git 恢复。选择其中一条路径，再按后面的共用步骤恢复文件，并重现记录中的删除操作。

对于已推送的提交，在经批准的本地恢复目录中打开 Bash。输入获准使用的远程仓库 URL，且不要在其中嵌入敏感信息。从保存的清单中取得分支名和完整提交 ID，输入分支名时去掉开头的 refs/heads/。使用平时的 Git 认证方式，并确保 recovered-worktree 目录尚不存在：

read -r -p "Approved remote URL (no embedded secrets): " RECOVERY_REMOTE &&
read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
mkdir recovered-worktree &&
(
  cd recovered-worktree &&
  git init &&
  git remote add origin "$RECOVERY_REMOTE" &&
  git fetch origin &&
  git switch --create "$RECOVERY_BRANCH" "$RECOVERY_COMMIT" &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

fetch 步骤会取得远程历史。git switch --create会在记录的提交处创建目标本地分支，而不是使用远程分支的最新提交。如果认证失败、记录的提交不可用，或任一比较未通过，就停止操作。从已验证的 bundle 或仍可访问的 Cloud 工作区取得缺失的提交，不要用其他提交替代。

对于 bundle 备份，在本地 conductor-history-backup 目录中打开 Bash。从保存的清单中取得分支名和完整提交 ID，输入分支名时去掉开头的 refs/heads/。同样使用尚不存在的 recovered-worktree 目录：

read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
git clone --branch "$RECOVERY_BRANCH" restored.git recovered-worktree &&
(
  cd recovered-worktree &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

git clone --branch选择工作副本要检出的分支。git branch --show-current检查分支名，git rev-parse --verify HEAD 检查提交。只有两项比较都成功，才会显示最后的状态报告。遇到错误或不一致时应停止。

任一恢复路径成功后，都在新建的 recovered-worktree 工作副本中继续操作。将保存的已修改、新增和未跟踪文件复制回原来的相对路径。所需的 Git 忽略文件应单独恢复。不要改动原始备份副本。

根据 pre-transfer-status.txt 和最终状态中不存在的路径记录，重现删除和重命名。只处理明确记录为已删除的路径，并先确认它在保存的最终快照中确实不存在。删除操作只能在新建的恢复工作副本中进行。对于重命名，将保存的文件恢复到新路径；仅当最终快照中已不存在旧路径时，才删除旧路径。

在恢复工作副本的根目录重新运行状态检查命令。逐一将变更路径与保存的状态记录核对，并将文件内容与独立副本比较。此流程恢复的是工作树内容，不是原来的暂存区状态。在暂存更改或恢复代理工作之前，先审核差异。不要向备份镜像仓库推送提交。

将本地版 Conductor 作为临时过渡

在解除对工作区界面的依赖期间，可以保留本地版 Conductor，以便继续当前工作。公告承诺提供新模型和关键缺陷修复至 2027 年初，随后开始逐步停止运营。这不会延长 Cloud 在 11 月 20 日关闭的期限。

迁移工作区后，应验证执行环境。Conductor 的 Cloud 工作区文档说明，工作区运行在与 Mac 连接的 Linux 沙箱中。因此，Cloud 环境中构建成功，不能证明相同依赖和命令也能在本地运行。

本地执行也不等于离线模型推理。Conductor 的隐私文档说明，本地工作区的模型请求会发往配置的模型提供商。

还要考虑进程何时结束。Cloud 常见问题指出，关闭 Conductor 或关闭 Mac 后，本地工作区会话就会结束。因此，迁移后的工作区不能替代持续运行的 Cloud 工作进程。

利用过渡期，让仓库在不依赖 Conductor 的情况下也能使用。将环境设置说明、测试命令和任务交接信息写入经过审核的项目文件。模型提供商的使用额度或 API 账单，应与 Conductor 的 Pro 功能免费政策分开核查。

用 Claude Code、Codex 或 OpenCode 重建并行工作流

先使用你已经熟悉的编程代理，再通过独立的 Git 工作树恢复并行工作。工作树是同一仓库的另一份工作副本，通常使用不同的分支。

这种方式适合能在本地运行项目，并通过 Git 审核更改的开发者。它重建的是彼此独立的工作目录，并非 Conductor 的共享 Cloud 服务或完整界面。

选择代理并验证认证

迁移任务前，先在 Conductor 之外安装所选 CLI，并完成认证配置。下面的混合代理示例需要同时安装 Claude Code 和 Codex，并分别完成认证。只使用一种代理时，在两个工作树中运行同一个 CLI 即可。

要保留现有的 Claude Code 工作方式，可使用 Claude Code。在项目目录运行 claude，按首次使用时的提示完成认证。

要保留现有的 Codex 工作方式，可使用 Codex CLI。在项目目录运行 codex。首次启动时，可选择通过 ChatGPT 登录或使用其他可用的认证方式。

如果已经在 OpenCode 中配置模型提供商，或希望能在不同提供商之间选择，可使用 OpenCode。运行 opencode，再按提供商配置文档使用 /connect 和 /models。

不要假设只在 Conductor 内配置的凭据，也能供独立 CLI 使用。允许代理访问真实任务之前，先核对当前账户、提供商和模型。

若选择单独按用量付费的 API 接入方式，BetterToken 提供针对 Claude Code 和 Codex 的设置指南。模型接入配置与工作区恢复应分开处理。迁移生产任务前，可按 Claude Code 与 Codex API 首次测试清单检查接入情况。

创建两个工作树并验证完整流程

从已验证的本地仓库根目录开始，以一个已知的提交作为起点。以下 Bash 示例会从当前 HEAD 创建两个分支：

git worktree add -b migration/docs ../migration-docs HEAD &&
git worktree add -b migration/tests ../migration-tests HEAD &&
git worktree list

Git 的工作树文档说明了如何用 -b 创建分支，以及用 list 列出工作树。确认输出中包含两个新目录及其对应分支。

这些工作副本从已提交状态重新检出，不会复制未提交文件或 Conductor 聊天状态。运行此示例前，先单独保存恢复出的未提交更改。

使用尚未占用的分支名和目录名。如果创建失败，先检查现有状态，再决定如何重试。不要仅为绕过错误就添加 --force。

接下来的两条启动命令要求 Claude Code 和 Codex 均已安装，且各自的认证配置已经完成。打开两个终端标签页，起始位置都设为原仓库的根目录。在第一个标签页启动 Claude Code：

(cd ../migration-docs && claude)

在第二个标签页启动 Codex：

(cd ../migration-tests && codex)

如果只用一种代理，就在两个目录中使用同一个已安装的 CLI 命令：claude、codex 或 opencode。避免让两个会编辑文件的代理同时操作同一工作目录。

每个会话先使用以下验证提示词。它要求只读检查仓库，报告目录、分支和有文件依据的设置及测试命令，不修改文件、安装软件包、提交或推送。

Use read-only tools to inspect this repository.
Report the current directory and Git branch.
Identify the documented setup command and one existing test command.
Cite the repository files that define those commands.
If a command is not documented, say so.
Do not edit files, install packages, commit, or push.

预期结果是两份分别对应不同目录和分支的报告。每份报告都应引用仓库中定义设置命令和测试命令的真实文件，不能编造通用测试命令。保持常规审批控制开启；提示词不是安全边界。

这些检查通过后，再批准所需的环境设置，并在每个工作树中运行一个小型现有测试。随后分配独立任务，例如一项文档修正和另一项测试改进。提交或合并前，逐份审核生成的差异。

根据导出的对话，为每项任务写一份简短交接说明，记录目标、约束、已完成更改、剩余工作和最后一次测试结果。复用导入的指令与钩子之前，应先审查其内容；代理配置审计指南提供了可参考的检查清单。

不要把启动新的 CLI 会话等同于恢复对话历史。OpenAI 的导入文档将 Claude Code 和 Cursor 列为 Codex CLI 的导入来源。这并不能证明 Conductor 的账户数据归档可以直接导入。

独立工作树也不会自动提供独立的数据库、服务账户或开发端口。运行并行构建之前，应明确分配这些资源。Conductor 自身也区分了工作区隔离与安全边界。

跟踪每个活跃会话消耗的提供商使用额度或 API 费用。例如，OpenAI 的认证文档区分了 API 密钥计费与 ChatGPT 套餐内含的额度。增加终端标签页，不会增加订阅包含的使用额度。

只有归档能打开、所需文件和提交都已核对齐全，且本地任务通过检查后，才将迁移标记为完成。未解决的工作区应继续保留在迁移清单中，直到负责人完成验证，或明确记录无法恢复的内容。