刚刷屏的 T3 Code 深度拆解Electron 外壳之下三个 AI 引擎如何共享同一套上下文【免费下载链接】t3code项目地址: https://gitcode.com/GitHub_Trending/t3/t3code2026 年 10 月初一篇题为《t3code 整合 Claude Code、Codex 与 Cursor 的 AI 编程桌面工具》的文章在 CSDN 引发关注让“一个桌面 App 同时驱动多个命令行 AI 编程 Agent”的话题再次升温。相比“装一个控制台管所有模型”的表层叙事真正值得深挖的是它解决的核心难题当 Claude Code、Codex、Cursor 各自带着完全不同的进程模型、协议方言和会话语义跑在同一台机器上时如何让它们读同一份项目上下文、产出同一种可审查的输出并在一套安全边界内协作本文将以仓库源码为唯一事实依据拆解 T3 Code 的“统一会话层”与“Electron 外壳”之间的分工事件溯源如何保证三个引擎的并发行为可回放ContextHandoff如何把跨引擎的历史“翻译”成对方读得懂的摘要能力声明capability系统如何在权限模式层面归一化各家差异以及 Electron 之外那层真正握有 Provider 进程、Git、文件系统和密钥的主进程到底承担了什么。一、统一会话层三个引擎之上的“同一套上下文”如果你把 T3 Code 当成一个“多标签终端”就错过了它 90% 的工程含量。真正的主战场在 apps/server/src/orchestration-v2一个事件溯源的编排层。其设计文档docs/orchestration-v2/README.md写得很直白provider 事件永远不会被改写成另一个 provider 的事件应用侧 ID 是主键provider 原生 ID 只是引用。1. 执行图把“对话”和“机器上的真实动作”分开建模社区文章常把 T3 Code 的能力概括为“统一会话与上下文共享”但源码给出的模型要严谨得多。它区分了三层概念见docs/orchestration-v2/README.md的 Minimal Mental ModelAppThread用户可见的对话线程是全量历史的权威来源Run一次被计数的用户可见轮次ExecutionNode一次 Run 内部的工作树——根节点之下挂着 tool 调用、approval 审批、subagent 子代理。这套模型的直接后果是子代理完成事件永远不能关闭父 Run。Codex app-server 探针观察到的协议现实thread/status/changed可能提前转 idleturn/completed才是权威终态子代 turn 完成可能先于根 turn被完整保留了下来。也就是说UI 上的“这条消息结束了”不等于“文件系统里的事干完了”二者是分离的里程碑。2. 事件日志与 Effect Outbox并发调度的可回放底座统一调度三个引擎最怕的是什么是“意图”和“副作用”混在一起。T3 Code 的处理是把两者彻底切开Orchestrator.ts 只负责把命令串行化、基于事件日志做决策绝不直接执行 provider 或文件系统操作EventSink.ts 把“事件 持久化投影 命令回执 outbox 效果请求”放进同一个数据库事务提交EffectWorker.ts 在意图落库之后才去执行副作用再把结果反馈回编排。EffectOutbox.ts 里定义的效果请求类型就是这套分工的缩影provider-turn.start、provider-turn.interrupt、provider-turn.steer、provider-session.detach……每条请求都携带causationEventId因果事件 ID和commandId命令 ID。这意味着重连、崩溃、重试都是幂等的重复的命令 ID 只会返回同一个回执不会重复触发 provider 副作用。README 中那句“command acknowledgement means the intent committed, not that the provider finished”是理解整套系统的心法。3. 上下文交接真正把“共享上下文”做成数据结构的部分这是本文最想强调的一点。多引擎“共享上下文”在普通工具里通常靠把历史塞进 prompt但 T3 Code 把它做成了一等公民ContextHandoff。ContextHandoffService.ts 负责生成交接工件handoffBudget.ts 负责计算“能塞多少历史”。关键的预算逻辑export function handoffBudget(input: { tokenCap: number; userText: string; attachments: ReadonlyArrayChatAttachment; providerThread: OrchestrationV2ProviderThread; nativeContextEstimate: number; modelContextWindow?: number | undefined; }): number { const usage input.providerThread.contextUsage; const window Math.min( input.modelContextWindow ?? usage?.maxTokens ?? 128_000, usage?.maxTokens ?? Infinity, usage?.autoCompactThreshold ?? Infinity, ); const native usage?.usedTokens ?? input.nativeContextEstimate; const current Buffer.byteLength(JSON.stringify(input.userText)) attachmentTokenAllowance(input.attachments); return Math.max( 0, Math.min( input.tokenCap, HANDOFF_BYTE_CAP, window - native - current - Math.max(16_000, Math.ceil(window / 4)), ), ); }这段代码很有代表性它先读目标 provider 原生线程的已占用上下文contextUsage再在“目标模型的窗口大小 − 原生占用 − 当前输入 − 预留的 25% 余量”的约束下决定还能注入多少历史默认 token 上限 16,000T3CODE_CONTEXT_HANDOFF_TOKEN_CAP可配置。也就是说交接不是“把整个对话丢给对方”而是基于对方原生上下文实时算预算。交接策略本身也是结构化的见 docs/orchestration-v2/provider-switching-and-context.mdruns 1-5: Codex, ProviderThread C1 switch to Claude for run 6 - ContextHandoff H1 covers runs 1-5 - create ProviderThread L1 - run 6 uses L1 with H1 runs 6-8: Claude, ProviderThread L1 switch back to Codex for run 9 - ContextHandoff H2 covers runs 6-8 - resume ProviderThread C1 - run 9 uses C1 with H2默认策略是优先恢复之前的 provider 原生线程只注入“它缺席期间发生的增量摘要”delta_since_target_last_seen只有恢复失败、设置不兼容或增量交接质量堪忧时才退化为“全线程摘要 新建线程”。原因写在文档里原生线程里藏着只存在于 provider 侧的隐藏推理、线程元数据、原生工具状态无脑新建线程等于每次切换都押注全量摘要的质量而完全不注入摘要则会让刚被接回的引擎“不知道别人干了什么”产生过期计划和不安全的文件假设。交接摘要本身也是从TurnItem结构生成的user_message、assistant_message、command_execution、file_change、checkpoint各自渲染成一行条目。对 Codex 这类支持历史注入的协议适配器还能直接调用原生thread/inject_items见 CodexAdapterV2.ts 的injectHistory把历史真正注入对方原生线程而非只写在 prompt 里。这就是“共享同一套上下文”在工程上的真实含义不共享 transcript共享的是可审计、有预算、按策略生成的交接物。二、多工具权限管理与输出格式归一化能力声明而不是厂商分支第二个高频社区话题是“权限管理与输出格式归一化”。源码里对应的答案是两套机制**适配器Adapter**负责把各家协议翻译成统一事件**能力声明capability**负责让编排层不做“按厂商名 if/else”。1. 适配器唯一的协议方言出口编排层只认一套归一化命令与事件。ProviderAdapterV2Event见 ProviderAdapter.ts是一张明确的联合类型app_thread.created、provider_thread.updated、provider_turn.updated、node.updated、subagent.updated、turn.terminal……无论底层是 Codex app-server 的 JSON-RPC、Claude 的进程协议还是 ACPAgent Client Protocol的会话运行时最终都汇入这十几种事件。对应地Adapters 目录里每种引擎一个文件CodexAdapterV2.ts、ClaudeAdapterV2.ts、CursorAdapterV2.ts、GrokAdapterV2.ts、AntigravityAdapterV2.ts、OpenCode2AdapterV2.ts等。驱动类型在 model.ts 统一注册const CODEX_DRIVER_KIND ProviderDriverKind.make(codex); const CLAUDE_DRIVER_KIND ProviderDriverKind.make(claudeAgent); const CURSOR_DRIVER_KIND ProviderDriverKind.make(cursor); const GROK_DRIVER_KIND ProviderDriverKind.make(grok); const OPENCODE_DRIVER_KIND ProviderDriverKind.make(opencode);适配器暴露的会话运行时接口是统一的ensureThread/resumeThread/startTurn/steerTurn/interruptTurn/rollbackThread/forkThread/injectHistory……差异全部收敛在适配器内部。这正是 ProviderAdapterRegistry.ts 存在的意义编排层按instanceId动态取适配器热重载、凭据切换都能即时生效而无须维护第二套实例映射。2. 能力声明把“做不到”显式化交给策略处理再优秀的归一化也抹不平一个事实Claude 能原生 fork 线程Grok 可能只能合成 forkCodex 能回滚快照OpenCode 可能连原生线程 ID 都不暴露。T3 Code 的处理是不假装它们一样而是让每个适配器在会话启动时声明能力矩阵provider-capability-system.mdtype TurnCapabilities { exposesNativeTurnId: boolean; emitsTurnStarted: boolean; emitsTurnCompleted: boolean; supportsInterrupt: boolean; supportsActiveSteering: boolean; supportsSteeringByInterruptRestart: boolean; supportsQueuedMessages: boolean; terminalStatusQuality: strong | weak | none; };terminalStatusQuality为 weak 时编排层通过策略推断终态但会如实标记相关度supportsActiveSteering与supportsSteeringByInterruptRestart的区分决定了“在途轮次被新消息打断”是直接改写对方原生 turn还是“先 interrupt 再起一个替代 attempt”。这些能力随后喂给 CommandPolicy.ts由它输出MessageDispatchDecisionV2start_run/steer_active/restart_active/queue_after_active/switch_provider把“用户想干什么 引擎能干什么”解析成唯一合法的调度决策。3. 权限模式四档收敛按引擎细化权限层面同样拒绝一刀切。用户侧只有四档见 docs/user/permission-modes.mdSupervised命令与文件改动都需审批、Auto-accept edits自动批准文件编辑、Auto用 provider 的自动审查、Full access免审批。但同一档位落到不同引擎上语义是不同的Codex/Claude/Cursor/Grok 支持 Auto 模式的自动审查OpenCode 与 Antigravity 没有对等物就退化为“提问”Muse 只提供 Supervised 与 Full access其他档位会被降级Grok 没有 Auto-accept edits 且文件改动审批提供“本次会话允许全部编辑”而命令审批故意不提供会话级宽免——因为 Grok 会为整个项目记住那条命令。这种“统一档位 引擎级细化”的设计正是能力系统在权限域的延伸。4. 输出归一化流向 UI 的结构化数据“输出格式归一化”在源码里的载体是投影Projection。编排层把归一化事件写入事件日志后由 ProjectionStore.ts 维护快照 游标的投影流UI 订阅的是投影而非原始事件。文档docs/internals/connection-runtime.md明确说明订阅按需发送客户端真正需要的状态——看一条线程不必为所有线程的历史买单。这也解释了“多标签会话隔离 统一审查视图”的体验从何而来shell 列表、线程详情、游标缓存各司其职断线重连时只回放游标之后的事件不重复拉全量。三、Electron 外壳的真相它只是“客户端”不是“引擎所在”社区讨论常纠结“为什么选 Electron”但仓库文档给出了一个更值得注意的定位执行发生在拥有工作区的环境里docs/internals/overview.md。桌面端只是“内置了一个 server 的客户端”渲染进程与 Web、移动端遵守同一条边界远程客户端永远不能用自己那套文件系统、Provider 凭据或机器状态去替代环境侧。1. 进程与安全主进程才是权力中枢真正握着 Provider 进程、终端、Git 和项目文件的是服务端server而桌面端通过 apps/desktop/src/ipc 把系统能力以窄接口暴露给渲染层。DesktopIpcMain只允许注册明确的invoke/sync通道且 ElectronShell.ts 对外部 URL 做了协议白名单只有http:/https:以及vscode://vscode-remote/ssh-remote…这类远程编辑器深链才放行其他一律拒绝——Zed 甚至单独校验 userinfo 必须为空。凭据存储走的是两条路ElectronSafeStorage.ts 用 Electron 的safeStorage.encryptString做系统级加密Linux 下还会暴露getSelectedStorageBackend()供诊断而服务端侧的 ServerSecretStore.ts 把“安全化、临时文件、持久化、并发读、删除、编解码”全部建模为带错误类型的操作集合。社区文章常说的“electron-store 存密钥”其实只是其中一环——对密钥这类高价值数据T3 Code 使用的是系统加密原语而非普通 JSON 存储。原生模块的边界也值得注意crowecawcaw/xa11y只在 fork 出的 Node 子进程里跑截屏无障碍树ffi-rs只在WindowsForeground.ts里懒加载做几个 Win32 调用macOS 的窗口查找干脆 shell 出去调osascript。任何原生能力崩溃都不能拖垮主进程所以新原生能力必须放进带超时的子进程而不是在 main 里import。2. 选型背后的权衡Electron 是性价比最高的“远程客户端载体”为什么要用 Electron从源码反推答案不是“因为它是桌面壳的标准答案”而是它只是众多客户端之一。桌面渲染进程与 Web、移动端共享 packages/client-runtime 里同一套连接运行时断线重连的退避策略、认证刷新、线程订阅生命周期全都在共享层防止“每个视图各重连各的”。选 Electron 意味着白拿一个完整的 Chromium 渲染器来承载这套共享 UI而无需为三端各自实现。主进程补足了 Web 拿不到的系统能力系统级密钥存储、全局快捷键、系统设置面板跳转、osascript/Win32 窗口查询、SSH 生命周期管理。代价被显式管理启动路径上禁止加载原生模块Wayland 下 Electron 的同步快捷键注册结果只证明“已提交”不证明“桌面已同意”或“绑定生效”因此桌面入口身份必须在 Chromium 初始化 portal 连接之前同步设置DesktopPreReadyPlatform.layer否则 Linux 上 URL handler 会拿到失效的Exec路径——这是 AppImage 更新移走旧可执行文件后的真实故障模式。换句话说Electron 的“重”在这里不是浪费它承担的是远程控制面control surface的渲染职责而引擎执行、状态持久化、文件操作都在 server 一侧。Electron 是窗口server 是大脑。3. 这样设计的红利桌面、网页、手机三端同一套编排状态正因为执行与 UI 分离T3 Code 才能把同一套编排层同时暴露给桌面 App、Web 控制台和移动 App。连接层docs/internals/remote.md按“环境”划界直连、Tailscale、SSH、T3 Connect 只是到达 server 的不同路由不引入第二种执行模型环境 ID 跨重启、跨端点保持不变。这也回应了社区里“本地优先”的说法——数据与状态归属环境server客户端只持有连接与缓存这正是“三个引擎共享同一套上下文”能够跨设备成立的前提。四、写在最后把这几层叠起来看T3 Code 给出的不是一个“AI 聚合器”的简单答案而是一套可验证的工程命题三引擎并发 ≠ 三块终端拼盘而是事件日志 执行图 投影支撑的可回放调度跨引擎上下文 ≠ prompt 拼接而是有 token 预算、有覆盖区间、有策略降级的结构化交接物多引擎权限 ≠ 一份全局开关而是能力声明 命令策略在四档权限模式上的逐引擎细化Electron ≠ 引擎宿主而是一个严格遵守“执行在环境侧”原则的远程客户端。对于想在自己的多 Agent 工作流里借鉴这些设计的开发者最值得抄走的不是某个 UI而是三条原则把意图与副作用分离并事件化、把跨引擎上下文做成有预算的显式交接物、用能力声明代替厂商判断。它们共同回答了那个最根本的问题——当机器上同时跑着 Claude Code、Codex 和 Cursor 时它们凭什么读的是“同一套上下文”凭的不是运气而是一整套以事件日志为底座的编排协议。【免费下载链接】t3code项目地址: https://gitcode.com/GitHub_Trending/t3/t3code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考