T3 Code（pingdotgg/t3code）：把六种编码智能体收进一台服务器，用一张可审计的图管住多智能体协作

一、导读

T3 Code 是 2026 年 10 月 30 日 GitHub 日榜上最值得拆解的编码智能体项目：它自称「agent harness control surface」，把 Claude Code、Codex、Cursor、Grok Build、OpenCode、Antigravity 六种编码智能体收进一台服务器，再用 Electron 桌面端、Web 端与 iOS/Android 原生 App 三套客户端驱动。

本文三条核心结论：其一，它真正的架构赌注是「执行留在拥有工作区的环境里」，远端客户端永远不能用自己的文件系统、凭据或机器状态替代宿主环境；其二，它把多智能体协作实现成一张可审计的图，而不是几块并排的终端；其三，代价明确——0.1.x 版本号、默认 Full access 权限、只到 git worktree 的隔离。

二、项目速览

项目	内容
仓库	pingdotgg/t3code
开发方	T3 Tools Inc.（Theo Browne / t3dotgg 团队，另出品 T3 Chat、UploadThing）
主语言	TypeScript（Electron + React Native + Node 服务端）
Star 总数	32,662（GitHub API，2026-10-30 抓取）
当日涨星	920（GitHub Trending daily，2026-10-30 抓取）
Forks / Open Issues	8,643 / 3,988（同上）
License	MIT
首次创建	2026-02-08
官网	https://t3.codes

Star、Fork、Issue 数均为 2026-10-30 单次抓取快照，这类早期项目数字日间波动很大；「首次创建」指仓库创建时间，并非首个 Release 时间。

三、为什么是它：问题背景与定位

3.1 被解决的问题

2026 年的编码智能体市场出现了一个奇特的分裂：模型能力按月迭代，使用入口却越来越碎。一个开发者可能同时持有 Claude Max、ChatGPT Plus（Codex）、Cursor Pro 与 xAI 的订阅，每个订阅背后都是独立的 CLI、登录态、会话历史与权限弹窗。结果是单个任务都能跑，回看时却无法判断哪一次输出已验收、哪一次只是生成了漂亮但不可合并的 diff。

T3 Code 切进去的正是这个缝隙。README 里有一段罕见的自问自答——「你到底要卖我什么？」答案是「什么都不卖」，动机是「我们想要最好的智能体开发体验，参考了 Codex 桌面版、Conductor、Claude Desktop 与 Cursor Glass，但没有一个达到标准」。它刻意不宣称覆盖全链路，只把自己定义为控制面。

3.2 涨星动因

三个信号同时成立。第一是作者势能：项目出自 Theo Browne（t3dotgg）的 T3 Tools，他因 T3 Stack、create-t3-app 在开发者社区有庞大受众，第三方评测把这一影响力列为该项目数月内破两万星的主要推力。第二是定位稀缺：同赛道工具大多绑定单一平台或厂商——Conductor 只跑 macOS 且闭源，Codex app 只跑 Codex，Vibe Kanban 的母公司 Bloop 已于 2026 年 4 月关停转为社区维护；而 T3 Code 同时给出「六家 provider + 三套客户端 + MIT 可 fork」。第三是产品节奏：10 月 15 日 v0.1.0 把调度层整体换成 Orchestrator V2，10 月 21 日 v0.1.1（官方称含超过 1,400 项变更，第三方用 git 复核为 1,486 个提交，其中修复 905、性能 335、新功能仅 44），10 月 29 日 v0.1.5。

四、架构原理

4.1 整体架构：执行留在环境侧

第一条原则写在 docs/internals/overview.md 开头：执行留在拥有工作区的环境里，Web、桌面与移动客户端通过经过认证的 RPC 控制它，远端客户端永远不能用自己的文件系统、provider 凭据或机器状态替代宿主环境；桌面端虽内置服务器，其 renderer 遵守同一边界。

flowchart TB
    subgraph Clients["客户端层（无状态遥控器）"]
        W[Web app.t3.codes]
        D[Electron 桌面端]
        M[iOS / Android 原生 App]
    end
    subgraph Cloud["T3 Connect 中继（Cloudflare Worker）"]
        R[Relay: 身份 / 隧道分配 / 凭据签发]
    end
    subgraph Env["环境层（拥有工作区的那台机器）"]
        S[RPC 服务器 + 事件溯源编排器]
        Q[(SQLite statev2.sqlite 事件日志 = 唯一真相源)]
        P[Provider 适配层 Claude/Codex/Cursor/Grok/OpenCode/Antigravity]
        T[PTY 终端运行时]
        G[Git / worktree / 源码托管集成]
        B[环境侧浏览器标签页]
    end
    W --> R
    M --> R
    D --> S
    R --> S
    S --> Q
    S --> P
    S --> T
    S --> G
    S --> B
    P --> CLI[本机已登录的 Agent CLI]

关键点：provider 进程、终端、Git 与项目文件都属于服务器；客户端只提供平台服务与 UI。共享的连接与领域状态放在 client-runtime，避免 Web 与移动端在重连、多环境行为上漂移。

4.2 分层模块拆解

层	目录	职责
客户端运行时	packages/client-runtime	每个环境一个连接所有者；重试策略、凭据、会话生命周期
契约层	packages/contracts	rpc.ts 是独立版本化客户端与服务器的边界
Provider 适配	packages/provider-*	把各家私有协议归一化成统一命令与事件
编排核心	apps/server/src/orchestration-v2	Orchestrator、EventSink、EffectWorker、RunFinalizationService、ThreadSettlementService
检查点	apps/server/src/checkpointing	用隐藏 Git ref 捕获工作区状态
终端	apps/server/src/terminal	PTY 归属、增量历史、保留上限
源码托管	packages/source-control-*	GitHub / GitLab / Bitbucket / Azure DevOps / Forgejo / Gitea
云端	infra/relay	T3 Connect 中继 Worker 与 Durable Object

Provider 适配层的纪律值得单独指出：编排层记录意图与状态，完全不知道哪个 provider 在跑这条线程；provider 协议、账号归属、权限与能力全部收敛在 ProviderAdapter 边界内归一化。文档还有一条关键区分——driver kind 标识一种集成，instance 标识一份配置与账号生命周期；工作按 instance 路由，所以同一 driver 的两个账号不会共享可变的 session 或 catalog 状态。这是多账号成立的前提。

4.3 核心机制：事件溯源与意图/副作用分离

这是 T3 Code 最值得学习的一段设计。编排状态以事件日志为唯一真相源：Orchestrator 只串行化命令、决定事件，不执行任何 provider 或文件系统工作；EventSink 在一个数据库事务里提交事件、持久化投影、命令回执与 outbox 副作用，订阅者在提交之后才收到事件；EffectWorker 在意图落库之后才执行副作用，再把结果喂回编排。

// 语义化伪代码（依据 docs/internals/overview.md 描述还原）
command = decode(request)
events  = orchestrator.decide(command)          // 纯决策，无 I/O
sink.commit(events, projection, receipt, outbox) // 单事务原子提交
subscribers.notify(events)                       // 提交之后才广播
effectWorker.run(outbox)                         // 副作用在意图之后

由此得到一条非常重要的语义：命令被确认只意味着意图已提交，不意味着 provider、检查点或其他后续工作已完成。这解释了为什么界面把「provider 回合结束」与「后续工作结算」当作两个独立里程碑——RunFinalizationService 独立记录两者，迟到的检查点或 diff 不允许延长已记录的 provider 时长，也不允许让客户端继续显示 provider 在工作。

数据模型是一张有向图：

Project
  AppThread          # 用户可见的对话
    Run              # 一次计数的用户可见回合
      ExecutionNode  # run 内一单位 provider/运行时工作（树形）
    ProviderThread   # provider 原生会话句柄
    ContextTransfer / ContextHandoff
    Checkpoints

每个已提交的 V2 事件都有存储侧分配的单调递增 sequence，投影快照与 WebSocket 流以它为游标边界：

read snapshot at sequence N
  -> stream committed V2 events where sequence > N

sequence 属于存储侧的事件信封，不属于 provider 事件或领域载荷；provider 原生顺序通过 provider ref 与诊断日志单独保存。这条规则让「快照 + 增量补播」不会出现空洞或重复。

4.4 跨 provider 切换：delta 优先而非重写摘要

多 provider 工具最容易被忽略的难点是上下文交接。T3 Code 的默认策略是：回到此前用过的 provider 时，默认恢复该 provider 之前的 ProviderThread，并注入一段覆盖「该 provider 缺席期间发生的 run」的 delta 摘要；只有当恢复失败、设置不兼容、或 delta 交接质量可能很差时，才新建 ProviderThread 并注入全量摘要。

runs 1-5: Codex, ProviderThread C1
切换到 Claude 跑 run 6
  -> ContextHandoff H1 覆盖 runs 1-5
  -> 新建 ProviderThread L1
  -> run 6 使用 L1 + H1
runs 6-8: Claude, ProviderThread L1
切回 Codex 跑 run 9
  -> ContextHandoff H2 覆盖 runs 6-8
  -> 恢复 ProviderThread C1
  -> run 9 使用 C1 + H2

它同时否定了两个极端：总是新建 provider 线程会丢掉 provider 原生的隐藏推理、线程元数据与原生工具状态，并让每次切换都依赖全量摘要质量；恢复但不注入摘要更危险——app 线程在 provider 缺席期间已经前进，恢复后的 provider 不知道别的 provider 做了什么，会产生错误答案、过期计划与不安全的文件假设。

交接物是显式的图数据，而不是隐式字符串：

type ContextHandoff = {
  id: ContextHandoffId;
  threadId: ThreadId;
  targetRunId: RunId;
  fromProviderThreadIds: ProviderThreadId[];
  toProviderThreadId: ProviderThreadId;
  coveredRunOrdinals: { from: number; to: number };
  strategy:
    | "delta_since_target_last_seen"
    | "full_thread_summary"
    | "checkpoint_summary"
    | "manual_context";
  summaryText: string;
  status: "pending" | "ready" | "failed" | "superseded";
  createdByProvider: ProviderKind | null;
};

注意 superseded 状态：同一个摘要被重新生成时，旧 handoff 被标记为 superseded 而不是被静默改写，这让「这个结论是从哪一版上下文里得出来的」始终可追溯。

4.5 性能优化与设计取舍

取舍一，客户端只订阅它需要的东西：契约层写明「查看一条线程的客户端不为每条线程的历史付费」，代价是投影层要维护多种有界窗口，而这些约束被写进性能回归测试——performance-regressions.md 规定：冷打开与历史分页在约 1 MiB 编码行处停止；含一个用户回合的窗口在 10 个用户回合（旧页 20 个）或 500 行处停止；其他窗口在 75 行处停止；恢复补播先检查 1 MiB 持久化载荷预算，再最多重放 128 条线程事件与 1 MiB 投影事件 JSON，超限回退快照。文档还警告：原始 JSON 字节数不是堆内存上限，仅因「输出投影后很小」就抬高预算，会在重复的大工具更新上增加服务器分配。

取舍二，原始输出在传输边界被剥离。原始命令输出、动态工具结果体、内联文件变更体在 wire 边界被省略（包括很小的输出），只保留显式失败标志与有界的结果 ID 来维持状态与分组计数；推理文本、命令行与搜索结果在对应工作组展开时才发送。持久化事件仍然完整，diff 端点可按需提供文件内容。

取舍三，终端历史增量而非全量，重连策略集中在一个所有者手里。服务器端每个终端上限 5,000 行与 8 MiB UTF-8 文本，客户端缓冲另有 512 KiB 上限，恢复时必须只读历史文件的有界尾部并跳过不完整的 UTF-8 前缀，否则「读取整个旧日志会在启动时击穿内存边界」；supervisor 独占传输重试，瞬时失败用带抖动的指数退避、上限五分钟、只在连接稳定后才重置，探测超时按路径分级——loopback 与局域网、长时间移动端挂起后 3 秒，其他路径 15 秒。

4.6 与其他架构路线的差异

同赛道大致分三条路线：终端多路复用路线把多个 CLI 塞进分屏，不引入服务器，但屏幕宽度固定；本地看板路线把抽象放在任务而非会话上，适合「忘了当初要什么」的痛点；控制面路线把抽象放在会话、分支与审查上。

T3 Code 与 Conductor 的差异最能说明路线选择：Conductor 是 macOS 独占的闭源应用，Pro 档 50 美元/月提供云工作区、API 与 iOS App，企业档有 SAML SSO 与 SCIM；T3 Code 是 MIT、三平台桌面加 Web 加双移动端、零收费、零团队管控。它用个人开发者的跨设备体验换掉了企业身份与花费管控。

五、应用场景

场景一：长任务的手机遥控——把审批从工位搬到口袋

业务痛点：Claude Code 跑一个跨 20 个文件的重构，中途会停下来请求权限（写文件、执行命令、访问网络），人必须守在电脑前点允许，否则任务卡在那里，一卡就是几小时。

如何解决：T3 Code 的移动端是完整客户端而非查看器。推送通知覆盖四种事件——完成、失败、需要审批、需要输入，点击进入对应线程；iOS Live Activity 与 Android Ongoing Agent Activity 让你不打开 App 也能跟进，完成结果保留最多 15 分钟；离线队列允许在没信号时先写好消息，恢复后自动发送。

# 宿主机（保持开机）
t3 connect            # 登录并开启 T3 Connect
t3 service install    # Linux/macOS：装成后台服务，重启后仍在
# 手机端：安装 App Store / Google Play 的 T3 Code，
# 用同一 T3 Connect 账号登录并选择该环境，在线程里批准或拒绝请求

收益与量化指标：每个 T3 Connect 账号可关联 3 台机器（手机与浏览器不计入），付费 T3 Chat 计划提升到 Pro 的 10 台或 Premier 的 100 台。必须注意的边界：推送投递依赖 T3 Connect，仅用直连或 Tailscale 配对时收不到推送。

适用边界：适合「任务已启动、只需偶发审批」的场景。不建议当作无人值守的自动化执行器——它没有容器级隔离，权限默认偏宽；若合规禁止第三方中继参与，应改用纯局域网或 tailnet 配对并接受收不到推送。

场景二：多 provider 交叉验证——同一需求让两个智能体各写一版

业务痛点：单个智能体的输出难以判断质量。同一需求交给 Codex 与 Claude 各做一遍是最廉价的交叉验证手段，但两个 CLI 的会话历史互不可见，人工比对成本高。

如何解决：T3 Code 把切换 provider 变成线程内的一等操作，并用 delta handoff 保留连续性。v0.1.0 引入的 delegate_task 更进一步：智能体可以把工作交给任意 provider、任意模型上的子智能体并等待结果，官方推荐它为组合 harness 的方式，举例是「Claude 规划、Codex 实现」。

// 子智能体委派（语义化示意，能力来自 v0.1.0 release notes）
delegate_task({
  provider: "claude",
  role: "实现者",
  prompt: "按上一步的 SPEC 实现模块并补测试"
})
// 子智能体是独立线程，只收到任务提示词加角色指令，
// 父线程对话历史不会被复制进子线程

收益与量化指标：可量化的收益是上下文成本。T3CODE_CONTEXT_HANDOFF_TOKEN_CAP 默认 16,000（可调 1,024 至 64,000），文本计费按 1 token 兑 1 UTF-8 字节折算；导入历史另有 64,000 字节上限。没有容量信息时按 128,000 token 窗口估算，并预留至少 16,000 token（或窗口四分之一）给指令、工具与后续工作；图片每张按 8,192 token 估算，其他附件按 4,096 token。这些是上限与估算，不是 provider 上下文窗口的保证。

适用边界：适合规划与实现分离、或需要交叉验证的任务。不建议在长线程里频繁切换——每次切换都要为缺席期间的 run 生成摘要，切换越频繁，摘要质量影响越大。

场景三：worktree-per-thread——同一仓库并行跑多条任务

业务痛点：五个需求同时开工，如果都在同一个工作目录里，智能体会互相覆盖文件、互相污染 git 状态。

如何解决：T3 Code 让每条线程对应一个独立分支（默认 t3/ 前缀），新线程可默认开一个 git worktree。文档还提供清理策略：PR 合并后、线程结算后、或空闲若干天后删除。

# 线程 #1 -> 分支 feature/add-auth-flow
# 线程 #2 -> 分支 fix/payment-bug
# 线程 #3 -> 分支 refactor/api-layer
# 在 T3 Code 新建线程时选择「新建 worktree」即可

收益与量化指标：每个智能体的改动都有清晰的 Git 边界，无法污染其他线程。回滚由 CheckpointStore 支撑——它用隐藏 Git ref 捕获工作区状态，不向用户分支添加提交；文档同时给出一条重要约束：回滚必须让工作区状态与 provider 对话协同，如果某个 provider 无法回滚自己的对话，该操作必须在改动文件系统之前被拒绝。

适用边界：适合多任务并行。不建议把它当作安全隔离——第三方横向评测明确指出，这一整类工具（包括 T3 Code）都不提供 per-agent 容器隔离；若核心担忧是在真机上跑一个跳过权限的智能体，选哪个都不解决，需要下面垫 devcontainer 或 VM。

场景四：从线程到 PR 的闭环——把验收变成一步动作

业务痛点：智能体跑完后，人工还要切分支、写 commit message、开 PR、补描述，这些动作占掉的时间往往超过审查本身。

如何解决：源码托管内建支持 GitHub、GitLab、Forgejo、Gitea、Bitbucket、Azure DevOps。智能体完成后一键 commit、push、开 PR，标题、正文与 changelog 自动生成，支持 draft PR、stacked PR 与 amend。Settings 里的 Source Control 可选写作风格与模型，其中 Repository conventions 模式会读取项目指令与最近的 commit subject。审查也在同一界面：PR 视图可审阅改动与评论、请求 reviewer、检出分支、合并；标记文件为已读用的是 GitHub 自己的 viewed 标记，因此审查状态在 T3 Code 与 github.com 之间是通的。

# 宿主机先完成 git 宿主认证（三选一）
export GH_TOKEN=<token>     # 或 gh auth login（需 CLI 2.81.0+）
# 或在 Settings -> Source Control 保存 token
# 线程完成后：点击提交，一键开 PR

收益与量化指标：审查状态双向一致（复用 GitHub viewed 标记）与回合级 diff——一个回合的 diff 只显示该回合的工作。移动端可报告 PR 状态但不能显示 diff，这是明确的平台边界。

适用边界：适合已用标准托管、且愿意让智能体直接开 PR 的团队。不建议在无人工复核时开启自动合并；也不建议把 Azure DevOps 的评论编辑当作可用功能——文档写明其评论只读。

场景五：让外部智能体驱动 T3 Code——把控制面变成 MCP 服务端

业务痛点：你已经在终端里跑着 Claude Code 或 Codex，或者你在 ChatGPT 里工作，但希望它们能操作 T3 Code 里的项目与线程。

如何解决：每个环境都在自己的地址后暴露 MCP 端点（/mcp）。不是 T3 Code 启动的智能体——你自己终端里的 CLI、ChatGPT、任何支持 MCP 的机器人——都可以通过它读取项目与线程、创建并给线程发消息、查询可用的 provider 与模型。每个智能体登录一次，由你决定它能做什么。

# 1. Settings -> Environments -> 环境菜单 -> Copy MCP URL
#    形如 https://<environment-address>/mcp
# 2. 在外部智能体里配置该 MCP 端点并授权
# Codex 侧是命令行覆盖：
codex -c mcp_servers.t3-code.url=http://127.0.0.1:<port>/mcp \
      -c mcp_servers.t3-code.bearer_token_env_var="T3_MCP_BEARER_TOKEN"

收益与量化指标：编排工具集覆盖创建子智能体、等待或轮询结果、取消委派任务、创建顶层线程、增量读取线程、链接或取消链接 PR、发送或转向后续消息、等待或中断运行。凭据按环境、父线程、provider 实例、provider 会话四重作用域签发，有过期时间与空闲过期，会话释放即撤销，原始 token 不持久化在编排状态里。一条重要的安全边界写在 v0.1.0 说明里：智能体不能批准自己的权限请求。

适用边界：适合把 T3 Code 当作可被编排的编排器。不建议把 MCP 端点暴露到不可信网络——文档建议把配对 URL 与授权码当作密码对待，t3 pair 可只签发只读链接，Permissions 视图会显示当前连接的权限。

六、快速上手

npx t3@latest                                        # 免安装试用（Node 22.16+/23.11+/24.10+）
curl -fsSL https://t3.codes/install.sh | sh          # macOS / Linux
irm https://t3.codes/install.ps1 | iex               # Windows PowerShell
t3                       # 启动服务器并打开本地 Web App
t3 service install       # 装成后台服务（Windows 不支持）
t3 update                # 升级

前置条件是至少一个 provider 已在本机安装并登录：codex login、claude auth login、agent login（Cursor）、grok login、opencode auth login；Antigravity 在 Settings 里启用并用 Google 账号登录。一个容易被忽略的运维细节：provider 凭据存在于宿主机的 CLI 里，如果某个 provider 在那台机器上从未登录成功，你从手机会看到一个「忙碌或不存在的智能体」，症状像安装问题，实际是宿主机登录问题。

七、横向对比

维度	T3 Code	Conductor	Vibe Kanban	Codex app
License	MIT	闭源	Apache-2.0（社区维护）	闭源
平台	macOS/Win/Linux + Web + iOS/Android	仅 macOS（Pro 含 iOS）	浏览器	macOS/Win/Linux
支持的智能体	Claude Code、Codex、Cursor、Grok Build、OpenCode、Antigravity + ACP Registry	Claude Code、Codex、Cursor、OpenCode	多 provider	仅 Codex
移动端	原生 App，含离线队列与 Live Activity	Pro 档 iOS App	浏览器 + web push	无
跨网络远程	T3 Connect 中继 / 局域网 / Tailscale 三路由自动择优	云工作区（Pro）	无	SSH 主机
团队管控	身份、计费、花费、模型策略、审计、责任六项均缺失	企业档有 SAML SSO 与 SCIM	无	随 ChatGPT 计划
价格	免费（自付 provider 订阅）	本地免费；Pro 50 美元/月；Teams 60 美元/人/月	免费	含在 ChatGPT 计划内
主要代价	Electron；无容器隔离；0.1.x 早期	Mac 独占、闭源、智能体列表短	公司已关停、版本停在 2026-04	只能跑 Codex

上表中 Conductor、Vibe Kanban、Codex app 的价格与平台信息来自第三方对比站点（2026 年 8 至 10 月评测，抓取于 2026-10-30），未逐项向厂商官方文档核实，标注为待确认。

八、局限、风险与社区观察

License 与商业化：MIT，可自由 fork，官方明确不商业化、不转售 token。这既是优点也是风险——没有付费档就意味着没有 SLA、没有 DPA、没有责任方。第三方团队就绪度评分把它的身份、计费、花费控制、模型策略、审计、责任六项全部记为缺失，并评价「不花钱也不得分，这是一个自洽的立场」。

维护活跃度：极高。抓取当日（2026-10-30）仓库 pushed_at 为同日 22:00，当日有 3 个 nightly 与 1 个 preview 构建；v0.1.5 含 5 位贡献者的 25 项变更。但 3,988 个开放 issue 说明缺陷池很大，README 明确写着项目非常早期、预期有 bug，且基本不接受外部贡献。

安全与权限风险（最需要警惕的一项）：新线程的初始默认权限是 Full access，即命令与文件编辑都不弹审批。四种模式中，Auto 依赖 provider 的自动审查，而 OpenCode 与 Antigravity 没有等价能力会退化为询问；Muse Code 只有 Supervised 与 Full access 两档；fx 不支持 Auto-accept edits 与 Full access；Grok 不支持 Auto-accept edits。此外文档坦承：Claude 在 Full access 下仍可能询问，Antigravity 在 Full access 下仍会发送原生审批请求。Full access 不等于永不被问，Supervised 也不保证只读动作都会先问。

生产可用性：版本号仍在 0.1.x，官方对 0.0.x 阶段的说明是不携带任何兼容性承诺、请钉住验证过的版本。第三方提醒了一个陷阱：preview 标签自己写着不要安装，而版本号排序最高的往往不是最完成的那个。

隔离边界：只到 git worktree，没有容器、没有 VM。需要真正执行隔离时要在下面垫一层（devcontainer 或 microVM），这是同类工具的普遍现状。

安装脚本的信任成本：curl 管道进 sh 与 irm 管道进 iex 都是下载即执行，命令本身不校验 checksum 或签名；务实做法是先取回 install.sh 读一遍再运行。

九、小结与行动建议

先确认一个 provider 能在宿主机跑通，再装 T3 Code。体验上限完全取决于底层 CLI 是否已安装、已登录；先启动 GUI 再排查 provider 是最常见的误判。
第一周把默认权限从 Full access 改回 Supervised。线程新建默认值可改，项目还能覆盖环境默认；已有线程保留自己的模式，需逐条调整。
把它当跨设备遥控器与审查台，而不是自动化执行器。它没有容器隔离、推送依赖云端中继；需要无人值守与强隔离时应垫 devcontainer 或 microVM。
钉住验证过的版本，不要指向 preview 或 nightly。用 t3 update 走正式通道，升级前读 release notes，并注意所有设备需一起升级。
值得学的是它的架构纪律，而不是它的功能清单。执行留在环境侧、意图先落库副作用后执行且 ack 只代表意图已提交、provider 判断不许散落到编排层、旧 handoff 标记 superseded 而非静默改写——这四条独立于 T3 Code 本身，任何做多智能体编排的人都值得抄走。

数据来源与获取日期：GitHub Trending daily 与 GitHub REST API（仓库元数据、Release Notes、仓库树、docs），均于 2026-10-30 抓取；官方文档取自仓库 docs 目录（internals 与 orchestration-v2 系列、user 下的 permission-modes、remote-access、portable-handoffs、outside-agents）。第三方对比与用户量数据来自公开评测站点，已在正文标注待确认。