T3 Code 多 Agent 并行：新线程、Fork 和 Worktree 怎么选

在 T3 Code 里开两个对话，让一个 Agent 修问题、另一个试不同方案，看起来已经分开工作了。但如果两边用的是同一个目录，文件、暂存区和未提交改动仍然混在一起。一个线程里点恢复，也可能影响另一个线程正在做的事。

需要同时修改代码时，先给任务选择 New worktree，再核对两个线程的实际目录、分支和起点。Fork 复制出来的对话，在本文核对的正式版里仍会沿用原工作目录。 Side chat 也共享父线程的目录。

本文依据 2026 年 11 月 8 日查阅的 T3 Code v0.1.7 正式版文档与源码，按选择工作区、分配任务、核对目录和合并验收的顺序说明。

T3 Code 负责把哪些东西放到一起

T3 Code 官方 FAQ将它定位为已有 Agent 运行工具的控制界面：把 Claude Code、Codex、OpenCode 等接到同一套桌面、网页和移动端界面里。模型调用仍由实际提供方执行，费用或订阅额度也跟着所用连接走。

对日常开发有用的是：你可以在一个地方查看多个任务、检查差异、处理审批和接回结果。不过，对话数量、工作目录数量和模型请求数量分别要看。多开一个对话，并不能告诉你它用了哪份代码。

如果还在决定主力开发工具，可以先读几种 AI 编程客户端的工作方式比较。这里讨论已经选用 T3 Code 后，怎样让并行任务有清楚的边界。

新线程、Fork 和 Side chat 会在哪改文件

T3 Code 的线程说明把“新对话”和“新 Worktree”分成两个选择。按 v0.1.7 的行为，可以这样判断：

入口	对话怎样处理	代码目录怎样处理
New thread	新建独立任务对话	跟随所选工作区与默认设置，发送前检查
New worktree	在独立任务对话里工作	为任务准备单独的 Git 分支和目录
New thread in this worktree	同一份代码上另开对话	继续使用当前 Worktree
Fork	从原对话的某个位置继续探索	继承原线程的工作目录
Side chat	旁边问问题，保留主对话的进度	与父线程共享目录

Fork 的区别尤其容易漏掉。Issue #27065的作者在 v0.1.3、Linux、Claude 提供方下报告：从 Worktree 线程 Fork 后，两边仍在同一份代码上修改。我们另外核对了 v0.1.7 的 Fork 实现，该版本创建 Fork 时保留了原线程的工作区信息。

截至查阅日，为 Fork 增加工作区选项的 PR #31835仍未合并。不要照着 PR 截图去找正式版还没有的设置。要另试实现，可以新开 New worktree 线程，把目标、已作决定和相关文件位置带过去，再确认它是否需要原分支尚未合并的提交。

Side chat 适合问“这一段为什么这样写”“这个方案还有什么风险”。如果要让它修改同一文件，就把两个对话当作共用一张工作台来安排，先停下另一边的写入。

哪些任务适合一起做

可以先从两个彼此独立的小任务开始。例如，一个修 CSV 导出编码，另一个补 SDK 使用示例；它们有各自的验收方式，改动也容易分别审查。

如果一个任务要改 API 返回字段，另一个要接入这个新字段，两者有先后依赖。先确定字段和行为，再让依赖方继续；需要未合并代码时，从包含这些提交的分支开始。否则，Agent 可能各自补一套适配，合并后还得返工。

在一篇 10 月 29 日的 V2EX 实践讨论中，作者也建议多 Agent 使用各自的 Worktree，只提交自己的改动，并在合并后重新测试。这是作者的工作经验；本文采用其中可检查的做法，不把它当成并行一定提速的实验结论。

给每个任务的说明至少交代清楚：

• 要解决的具体问题，以及怎样算完成。
• 可以改哪些部分，公共接口由谁决定。
• 从哪个分支或提交开始，是否依赖另一个任务。
• 要执行哪些验证，最后交回哪些改动和结果。

例如，可以把下面这段补上项目中的真实信息后交给 Agent：

任务：修复本次报告的 CSV 导出编码问题。
工作区：使用为本任务新建的 Worktree，开始时报告目录、分支和 HEAD。
范围：只处理导出编码及对应回归验证；公共字段变更先说明影响。
验收：用约定样例检查表头、中文内容和行数，运行项目已有的相关检查。
交付：列出改动文件、验证命令与结果、未解决问题，以及提交号（如已提交）。

长期适用的约定可以放进项目规则，按需执行的完整流程放进 Skill，具体分工留在任务里。AGENTS.md 与 Skills 的分工里有更详细的说明。

发送任务前，在两个线程里核对这几项

在 T3 Code 新线程的工作区选择里选 New worktree，并检查起始分支。两个独立任务通常从同一个已确认的提交出发；依赖任务则要用包含前置改动的起点。

随后，让每个 Agent 在自己将要工作的目录运行下面这些只读命令。这里使用 Bash、zsh 等常见终端写法，没有要求创建或删除工作区：

pwd
git rev-parse --show-toplevel
git branch --show-current
git rev-parse HEAD
git worktree list
git status --short

检查结果时，重点看这些含义：

• 运行机器：两个线程是否在预期的环境上；远程机器的目录要在那台机器上核对。
• 仓库根目录：需要隔离修改的任务应指向各自的目录。两个标题不同、输出的根目录相同，就仍共用代码。
• 分支和 HEAD：分支分别对应任务；HEAD 是起始提交。同一起点刚建的两个 Worktree，HEAD 相同是正常的。
• 工作区状态：新任务不应接手一批归属不明的改动。git worktree list 能把目录、提交和分支列在一起辅助核对。

Git 的官方 Worktree 说明解释了这种安排：多个目录共享仓库对象，但各自有 HEAD、索引和工作文件。因此，分开目录很有用；只是给任务取不同分支名，还不足以让同一目录里的两套文件同时存在。

另外，Worktree 只分开代码目录。两个开发服务器仍可能抢同一个端口，也可能连到同一个数据库。依赖安装、本地配置和服务地址要按项目准备，临时任务尽量用测试资源，密钥通过项目已有的安全配置方式提供。

如果一直停在 Preparing workspace，先打开准备脚本的终端看输出。Issue #32556有一个 v0.1.7、macOS、fish 4.3.2 的单个报告：脚本语法不兼容时一直等待，修了仓库里的 t3.json 后，已导入的 Action 仍保留旧命令。它没有证明所有卡住都由 fish 引起，但提醒我们同时检查实际执行的命令、Shell 和保存的 Action，不要只反复重发任务。

Agent 说完成以后，按分支接回改动

让每个任务分别交回改动范围、验证结果和提交号，再安排一处负责集成。先确认修改符合要求，再把任务分支逐个合入目标分支；合并后重新验证受影响的完整流程。

审查时，需要同时看未提交改动与分支中的提交。下面以 main 为目标分支举例，使用时换成项目实际的集成分支：

git status --short
git diff
git diff --cached
git log --oneline main..HEAD
git diff main...HEAD

git diff main...HEAD 适合看从共同起点到本任务分支的已提交变化；它不包含工作区和暂存区的修改。只看这一条，容易漏掉 Agent 还没提交的部分。未跟踪文件也要结合 status 单独查看。

T3 Code 的差异说明还区分了单轮改动和分支比较：一次操作带进来的 pull、merge、rebase 变化，可能不全部列在该轮自己的文件列表里。检查完整交付时，应结合分支比较，不能只看最后一轮动了哪些文件。

如果已经混到同一个目录，先停下会写文件的任务，保存当前差异和各方说明，辨认哪些改动属于哪个任务。确认归属后，再分支提交或转移到独立工作区。直接点恢复、清目录或让两边各自“自动解决”，都可能把仍需要的改动一起处理掉。

并行以后，费用也要按实际连接核对

任务更早完成和总调用更少，是两个需要分别记录的结果。多个 Agent 可能各自读取项目、分析、修改和重试；后面还有集成与检查。要判断值不值得，记录整个任务结束的时间、返工情况，以及所有相关调用。Agent Token 开销说明解释了这些调用为什么会多于用户看到的几句提问。

T3 Code 的 Usage 文档明确说明，其中的 API 等价费用是估算，不能直接当作订阅账单；统计也受可取得的历史记录影响。

使用 Nbility 时，先按接入基础确认当前 Agent 连接的地址、协议、令牌和模型，再按账户与计费说明核对用量日志与账单。只有实际经该连接发出的请求，才会进入对应服务的记录；在 T3 Code 里看到任务，并不意味着它经过了同一个 API 入口。

第一次试并行，可以只选两个边界清楚的小任务：先验证目录确实分开，再完成各自修改，最后在集成后的代码上验收。把这条流程跑通，比一次开很多对话更容易知道哪里省了时间、哪里增加了工作。