T3 Code：把 Codex、Claude 和 Cursor 装进一个轻量 Web 工作台
T3 Code：把 Codex、Claude 和 Cursor 装进一个轻量 Web 工作台
你是否同时使用 Codex、Claude Code 和 Cursor，却要在多个终端窗口之间来回切换？一个 Agent 在修改代码，另一个正在运行测试，第三个等待你确认命令。终端本身很强大，但当任务变多，真正消耗精力的往往不是写代码，而是管理这些会话。
最近 GitHub Trending 上的 T3 Code 就是在解决这件事。它不是新的大模型，也不是又一个封装 API 的聊天窗口，而是一个极简的 Web GUI，把多个现有 coding agent 放进同一套工作流里。
项目背景：Agent 越多，操作成本越高
AI 编程工具已经从 “帮我补全一段代码” 发展到可以阅读仓库、修改文件、执行命令和处理多步任务。问题也随之出现：不同 Agent 有不同的 CLI、登录方式和会话界面，开发者需要记住每个工具的启动命令，还要持续观察它们的输出。
T3 Code 的思路很直接：保留 Codex、Claude Code、Cursor Agent 和 OpenCode 的能力，只负责提供一个统一的图形界面。项目 README 将它定义为 “a minimal web GUI for coding agents”，当前支持这四类 provider，并明确提醒项目仍处于早期阶段，使用时应预期存在 bug。
这个定位很重要。T3 Code 不试图替代底层 Agent，也没有承诺自动解决所有工程问题。它更像一个调度台：让你更容易启动、查看和管理正在运行的编程任务。
核心功能
1. 一个界面管理多个 coding agent
T3 Code 当前支持 Codex、Claude、Cursor 和 OpenCode。你可以根据任务特点选择不同的 Agent，而不必为每个工具打开一套独立的交互界面。
例如，代码重构可以交给 Claude Code，快速生成补丁可以使用 Codex，习惯 Cursor 工作流的项目则继续使用 Cursor Agent。底层能力没有被抹平，只是入口被统一了。
2. 直接通过 npx 启动
项目提供了零安装体验：
1 | npx t3@latest |
这对想先试用的人很友好。Node.js 环境准备好后，不需要先下载桌面安装包，也不用手动配置一堆前端依赖。需要查看命令行参数时，可以运行：
1 | npx t3@latest --help |
3. 同时提供桌面应用
如果你更喜欢固定的桌面窗口，T3 Code 也提供 GitHub Releases 和包管理器安装方式。macOS 可以使用 Homebrew：
1 | brew install --cask t3-code |
Arch Linux 用户可以通过 AUR 安装，Windows 用户则可以使用 winget。CLI 与桌面应用覆盖了两种典型习惯：临时试用时快速启动，长期使用时固定在桌面上。
4. 对已有认证方式保持兼容
T3 Code 不负责替你创建模型账号。使用前，至少需要安装并登录一个 provider：
1 | # Codex |
这种设计减少了额外的密钥搬运。认证仍由各个官方 CLI 管理，T3 Code 只调用已经准备好的 Agent。对于公司代码或个人私有仓库，这比把 API Key 再复制到一个新服务中更容易理解和控制。
实战：五分钟启动第一个任务
下面以已经安装 Node.js 和 Claude Code 为例。
第一步，确认 CLI 已经完成认证：
1 | claude auth login |
第二步，在任意位置启动 T3 Code：
1 | npx t3@latest |
启动后打开它提示的本地地址，在界面中选择 Claude provider，并指定一个本地项目目录。接下来可以输入一个边界清晰的任务，例如：
1 | 阅读这个项目的 README 和测试目录，找出登录失败时没有覆盖的边界情况。 |
当 Agent 给出分析后，再继续要求它实现测试。这样分两步做，既能保留人的判断，也能避免一上来就让 Agent 修改整个仓库。
如果想换成 Codex，只需先完成 codex login，然后在工作台中选择对应 provider。T3 Code 的价值就在这里：切换工具时，思考仍然围绕项目任务，而不是围绕 “这个 CLI 的窗口在哪里”。
它和同类工具有什么不同
与 Cursor、Claude Code、Codex 本身相比，T3 Code 不是模型或 Agent 能力的提供者，而是统一入口。它适合已经认可多个 coding agent、但不想被各自界面分割的人。
与 OpenHands、Aider 这类项目相比，T3 Code 的重点也不同。OpenHands 更强调自主软件工程流程，Aider 更强调终端里的对话式代码修改；T3 Code 则尽量保持轻量，把现有 provider 放到 Web GUI 中，学习成本更低，但自主编排能力也没有那么重。
它也不同于传统 IDE 插件。IDE 插件通常围绕当前编辑器和文件树展开，T3 Code 更像独立的 Agent 工作台，适合同时观察多个任务。代价是它不能替代 IDE 的调试器、代码导航和完整编辑体验。
适用场景与限制
T3 Code 适合以下场景：
- 需要在多个 coding agent 之间快速切换的开发者；
- 想用浏览器界面管理终端 Agent 的团队；
- 希望先用
npx试用，再决定是否安装桌面版本的人； - 已经有 provider 账号，不想再维护一套模型接入层的项目。
它的限制同样需要提前说清楚。第一，项目目前仍然很早期，README 直接提示 “Expect bugs”，不适合未经验证就放进关键生产流程。第二，它依赖底层 provider 的安装和认证，T3 Code 本身不能解决账号权限、额度和模型可用性问题。第三，多个 Agent 同时修改同一个仓库时，仍然可能产生文件冲突，统一界面不会自动替你进行版本控制。
实际使用时，建议为不同任务准备独立分支或工作区，给 Agent 明确的修改范围，并在合并前运行测试。GUI 解决的是会话管理问题，工程质量仍然需要靠 Git、测试和人工 review 来保证。
总结
T3 Code 的亮点不在于功能数量，而在于抓住了 AI 编程工作流中的一个真实摩擦点：当开发者开始同时使用多个 Agent，终端窗口和认证入口本身就变成了管理负担。
它通过一个极简 Web GUI 统一 Codex、Claude、Cursor 和 OpenCode，并提供 npx、桌面安装和既有 CLI 认证兼容。对于想降低切换成本的人，这是一个值得试用的开源项目；对于追求成熟度的人，则应把它当作快速变化中的实验性工具，先在非关键仓库验证，再逐步纳入日常流程。