介绍一下 t3code

回复 群友 607 T3 Code 是 Theo（t3.gg）和 jullerino 做的，仓库在 pingdotgg/t3code，MIT 开源，现在已经 3 万 star。它把自己定位成「agent harness 的控制面」，并没有去做 IDE，也没有自己训练模型。 它解决的问题是多 agent 并行运行后变得杂乱：哪个 thread 对应哪个仓库、哪条分支、哪个 worktree、还在跑还是卡在等审批、哪次改动属于哪句 prompt、这条 thread 用哪个模型和账号。终端标签页装得下这些进程，却装不下一套共享的状态模型；IDE 只能深支持自家 agent；托管的 agent 平台又把代码搬到自己的云里。T3 Code 的做法是在你的机器上跑一个本地服务，由它去启动 Codex、Claude Code、Cursor、Grok、OpenCode、Antigravity、Pi 这些 provider CLI，把各家不同的事件流翻译成统一接口，浏览器、Electron 桌面端、iOS 和 Android 都只是这个服务的视图。执行仍然发生在你自己的文件系统上。 核心概念就几个：environment 是一台跑着服务的机器，project 指向一个目录，workspace 决定 thread 在哪个目录里干活，可以用当前 checkout 也可以用新的 git worktree，thread 是跨客户端持久存在的对话，turn 是一次完整的用户与 agent 交互循环，每轮前后打 checkpoint，因此能按消息级回滚；provider 是真正的 agent runtime，T3 Code 只管会话，模型选择、工具、权限细节仍然由 provider 自己决定。 我比较在意的几个设计： 一是权限模式映射，不做假统一。Supervised 全部先问、Auto-accept edits 自动改文件但命令仍然先问、Auto 只拦危险操作、Full access 全放。关键在最后一句：provider 没有对应能力时，它会退回成先问你，而不是假装自己能执行一个它其实没有的模式。这个处理比「界面看起来一样、实际各自为政」要诚实。 二是 Mobile app 是它区别于同类产品的地方。审批卡片跟着 thread 走，agent 卡在一个 shell 命令上等授权时，你在手机上就能放行。 三是 skills 不归它所有：语音输入里打斜杠就选命令，打 $ 就搜 skills，它只是发现并展示上游 agent 生态里已有的 skill，标注来源是 System、Personal、Project 还是 App。 四是 t3.json 把可重复的项目行为固定下来：默认 workspace 模式、命名脚本、worktree 创建时自动跑的初始化脚本、preview URL 是否自动打开。这也让「每个 worktree 自己装依赖、自己起 dev server」变得可行。 它的边界也说得很清楚：不提供模型额度，需要自带订阅并先在服务机器上登录；不是云开发环境，笔记本一关服务就停；不是所有人的 IDE 替代品，大重构和深度调试还是专用编辑器舒服；权限模式本身不是安全边界，Full access 等于这台机器上的完全权限，而它现在恰恰默认 Full access，加重要项目时最好先改掉。 我的判断：它真正的价值在于采用本地控制面架构，而单是「GUI 更好看」并不构成核心价值。它把「执行位置」和「观察入口」分开了，所以手机、浏览器、桌面能同时看同一份工作，agent 干活的地方还是你的机器。但这种架构的风险也很明确：它比 ThinkRail 更彻底地依赖别人的 harness，主体能力全在 provider 那边，Codex 或 Claude Code 一改事件格式，它就得跟着改 adapter，护城河基本只在交互和状态模型上。另外项目自述还很早期，明确说不怎么收大功能 PR，介意稳定性的先拿个小的可丢弃仓库试，别直接开在重要 checkout 上。 安装最省事的是 npx t3@latest，或者用 brew、winget 装桌面版；记得先在服务机器上至少 codex login 或 claude auth login 一个。