企业官网建设流程全解析

我最近在调多个 AI 编程 Agent 一起干活的时候，被一个问题憋得难受：每个 Agent 各自有终端、各自记上下文、各自报错，结果一个需求拆给三个智能体，代码倒是写完了，但我根本没法在同一个地方看到整套任务的进度、改动和成本。后来同事丢给我一个开源项目 T3 Code，说它是 AI 编程 Agent 的统一控制台，我试了几天，最大的感受是——它把“多 Agent 并行改代码”这件事从玄学变成了可管理的工作流。这篇第 206 天的开源项目笔记，就从头讲一下 T3 Code 到底是什么、适合谁用、以及我在部署和实测中踩过的坑。

1. 为什么多 Agent 工作流会先混乱起来

1.1 每个 Agent 都有自己的“工作记忆”

先说个很现实的场景：你手上有一个仓库，既要修接口报错，又要新增页面，还想顺手把测试补了。正常的偷懒思路是开三个终端，分别让 Aider、Claude Code、Codex CLI 各干一摊。结果往往是这样——Aider 改完接口返回结构，Claude Code 那边还拿着旧字段写页面，最后代码合到一起直接编译不过。

很多人第一反应是“模型不够聪明”，但我实际跑下来发现，问题多半出在上下文没有统一传递上。每个 Agent 启动时都是从零开始，它只认识你给它的那一段 prompt 和当前工作区里的文件。你之前在某一个终端里拍板定的技术方案，换个 Agent 就完全不记得了。这不是某个工具的问题，而是所有 CLI 类 AI 编程工具的通病：它们都只有局部记忆。

1.2 “端”越来越多，历史记录散落各处

一个人同时开三四个终端还勉强能忍，但团队里三个人、五个人都这么干，整个仓库就会变成一锅粥。我见过一个前端小组，同一天里有两个人分别让不同的 Agent 改了同一个页面组件，Git log 里一片混乱，谁也说不清哪段代码是哪个需求带进来的。

更难办的是执行记录。终端一关，刚才 Agent 干了什么都只剩一个回车键的距离。哪怕当时看到了一个很有参考价值的 prompt 写法，过两天想复盘，翻遍 shell history 也找不到全貌。T3 Code 这类统一控制台要解决的，其实就是这种“历史不可追溯、上下文不互通、改动不可视”的混乱。

1.3 统一控制台不是套个 Web UI 就完事

有人会觉得，给每个 Agent 套一个好看的网页面板，再把所有日志汇总到一个页面，就是“统一控制台”了。我一开始也这么以为，用了 T3 Code 之后才意识到，真正的统一至少要解决三件事：

• 第一，状态同步。所有 Agent 当前在跑什么任务、跑到哪一步、失败了几次，要能在同一屏看得一清二楚。
• 第二，执行可回放。每一步的输入 prompt、触发工具、生成 diff、最终结果，都要像视频录像一样可以按时间线倒回去看。
• 第三，审计可追溯。谁在什么时候、通过哪个 Agent、改了哪些文件，要能对应到具体的任务和会话上，而不是靠人肉从终端里复制粘贴。

这三件事听起来简单，真正落地的时候牵扯到任务调度、文件锁、上下文打包、结果归并，工程量其实不小。

2. T3 Code 的核心设计：从任务到记录的完整链路

2.1 四个核心概念：Workspace、Task、Agent、Session

我先按自己的理解把 T3 Code 里的抽象模型捋一遍。它没有发明什么玄乎概念，基本就是把传统的研发协作模型映射到了 Agent 场景里：

理解这个模型之后，T3 Code 的运作逻辑就很好懂了：用户把一个 Task 扔进去，T3 Code 会先让内置的 planner 把任务拆成若干子步骤，然后根据每个 Agent 的能力声明把步骤匹配出去，最终把结果以 diff 的形式汇总回来。

Agent概念本身也做过一层抽象。它不直接内置某个固定模型，而是通过适配器对接底层 CLI 工具或 API。这意味着你之前用惯的 Aider 规则、Claude Code 的 CLAUDE.md 说明文件，都可以继续沿用。T3 Code 更像是一个管理层，而不是要取代你现有的工具链。

2.2 任务编排的默认策略：并行还是串行

我用的第一个版本默认是串行执行，后来在配置里可以打开并发。串行的好处是稳，每个 Agent 都等前一个稳定落盘再继续，几乎不会有文件冲突；坏处是慢，一个多模块需求可能要排队好几分钟。并行的好处是明显缩短整体时间，但代价是必须做路径级隔离。

T3 Code 的处理方式是给每个 Agent 分配一个“文件锁定区”，类似 Git 的 index.lock 思路，但粒度更细。比如 Agent-A 正在改src/server下的文件，那么同一个 Workspace 里其他 Agent 默认不会被分配到这些路径。只有显式声明的 shared 目录（比如接口文档目录）才允许多个 Agent 同时写入，写入时加锁排队。

我当时第一次跑并行任务就踩到过一次冲突：一个 Agent 在改数据库模型，另一个 Agent 在生成迁移文件，两个文件都涉及同一张表结构。T3 Code 的路径锁并没有拦下来，因为它俩改的不是同一个文件，但语义上是相关的。后来我才意识到，路径锁只能解决物理重叠，解决不了逻辑冲突。所以我在配置里干脆给同一领域的改动串行执行，跨模块再并行。

2.3 为什么把“回放”做成第一公民

T3 Code 最让我觉得值的地方，不是面板好看，而是 Replay 机制。每个 Session 都像一段可拖动的录像，我能看到 Agent 在某个时间点读了哪个文件、执行了什么命令、基于什么 prompt 给出了什么输出。对于排错来说，这个能力几乎是救命级的。

有一次一个 Agent 把我某个配置文件里的一行环境变量改掉了，当时没人发现，过了两天测试环境才挂。普通情况下这种问题只能去翻 shell history 和 git blame，靠猜。但在 T3 Code 里，我直接打开那个 Session，找到它执行edit_file的那一步，diff 一展开，根因清清楚楚。这个功能被我后来用作每周代码复盘的核心素材。

3. 本地部署与首次接入：实操过程中的关键节点

3.1 准备条件与版本选择

先说一下我自己的部署环境，方便你对照：Ubuntu 22.04，Docker 24，8 核 16G 内存，磁盘剩余 40G 左右。T3 Code 的前端和调度器都打包成了容器，仓库里带了 docker-compose 文件，所以最省事的路径就是直接起容器。

如果你只是想试用，不打算上多用户，其实也不需要配太高的资源。我观察下来的资源占用大概是：主服务 500M 内存左右，每个 Agent 执行器会额外占用 200M 到 600M，看具体底层模型是否本地加载。如果接的是远端模型 API，内存需求会更低。

我建议优先用最新 release 版，而不是 main 分支。原因是这个项目迭代挺快，main 分支可能已经引入了 schema 变更，旧版本或者文档没同步，容易踩坑。我遇到过一次版本不一致的情况：容器镜像已经更新到新 schema，但我的配置还在按旧版写，导致任务创建成功后无法分配给任何 Agent，最后只能把数据目录清掉重来。

3.2 启动服务与第一个 Agent 接入

这里给一套最简配置，你照抄就能跑通：

git clone https://github.com/t3-code/t3-code.git cd t3-code cp .env.example .env docker compose up -d

docker compose up之后，默认会在http://localhost:3000打开控制台。第一次进入，它会要求你创建一个 Workspace；创建时可以直接指定一个本地已有的代码目录，也可以用git clone拉一个新仓库。

创建完 Workspace 之后，需要配置 Agent。我以接 Aider 为例，在.env里要写清下面几项：

T3_DEFAULT_AGENT=aider T3_AGENT_AIDER_MODEL=qwen-coder-plus T3_MODEL_API_KEY=你的ApiKey T3_MODEL_BASE_URL=https://api.example.com/v1

这里有几个注意点。首先，T3_MODEL_BASE_URL一定要写支持 OpenAI 兼容协议的接口地址；其次，如果模型支持 streaming，尽量打开，否则你会在控制台里看到很长一段“等待中”之后才一次性整段输出，体感很差。

配置完成后，我建议先在控制台里跑一个最小任务测试一下，比如“给 README.md 追加一行项目简介”。这个任务足够小，能验证链路通不通，又不会因为代码逻辑复杂而分不清是调度问题还是模型问题。

3.3 一次端口冲突日志的完整排查链路

接下来说一次我自己遇到的真实报错，完整走一遍排查过程。

现象是：页面能打开，但提交任务后一直停在queued状态，没有 Agent 被唤起。我第一时间看 T3 Code 的调度器容器日志，发现里面反复出现：

connection refused on localhost:50051

我当时的思路是，50051 这个端口应该是 T3 Code 内部 scheduler 与 worker 通信用的 gRPC 端口。系统提示连接被拒，说明某个依赖进程没起来，或者容器网络没有打通。于是我做了三步定位：

第一步，执行docker compose ps查看所有服务状态。结果发现t3-scheduler容器显示为 unhealthy。

第二步，查看 scheduler 的 healthcheck 配置，发现它写的是curl 127.0.0.1:50051/healthz，但检查的其实是宿主机的 50051 端口，而不是容器内端口。而 compose 文件里根本没有把 50051 暴露到宿主机，所以健康检查永远失败。

第三步，把 healthcheck 改成在容器内自检：

healthcheck: test: ["CMD", "curl", "-f", "http://127.0.0.1:50051/healthz"] interval: 10s timeout: 3s retries: 5

改完后重启容器，任务马上就能跑起来了。这个坑说到底是容器端口映射和健康检查探测地址不一致导致的，属于比较典型的小白级问题，但如果你不了解内网服务之间通信和宿主机端口映射的区别，可能会卡很久。

4. 在真实项目中怎么编排多个 Agent

4.1 一个“订单导出”功能的拆解示例

光聊理论容易飘，我拿最近一次真实需求举例。这个需求是给后台管理页面加一个“订单导出”功能，大致包含三块：后端新增一个/api/orders/export接口，支持按时间范围和订单状态过滤，导出结果走异步生成；前端在订单列表页加一个导出按钮，并轮询导出进度；数据库这边要加一张导出任务表。

以前我都是自己手动拆，再按模块喂给不同 Agent。用 T3 Code 之后，我直接把需求原文贴成一个 Task，然后手动指定分配策略：

这里我特意没有让 Agent-A 和 Agent-C 并行，因为后端接口和数据库表结构是强依赖关系，表没建好，接口写了也白写。T3 Code 的路径锁没有这个语义判断能力，得靠我自己在设计任务时把依赖关系理清楚。

4.2 Diff 审查和回滚的完整路径

Agent 跑完不等于任务完成。T3 Code 的每个 Task 完成后，都会生成一份汇总 diff，我一般会按这个顺序检查：

1. 先看变更文件列表，判断有没有“顺手牵羊”改了无关文件。
2. 再逐文件看 diff，重点看接口签名、数据库字段、环境变量引用。
3. 最后跑一遍本地测试命令，比如pytest或npm test，确认没有破坏已有功能。

如果发现某个 Agent 的产出有问题，也不需要直接回滚整个仓库。在 T3 Code 里可以只恢复该 Task 关联的文件，把对应文件 checkout 到任务开始前的状态，然后重新分配任务。这个能力非常实用，因为多 Agent 并行时，其他 Agent 可能已经产生了新的有效改动，整体git reset会把别人的劳动成果也干掉。

在做一次复盘时，我发现回滚次数最多的场景并不是“Agent 写错了逻辑”，而是“Agent 改对了内容但改了错误的格式或位置”。比如它把一个工具函数的定义从工具库文件复制到了业务页面里，逻辑没错，但架构上不对。这类问题提示了一个方向：以后应该在 Task 描述里明确每个函数的归属文件，避免 Agent 自己发挥。

4.3 把 T3 Code 暴露给其他工具的扩展方式

除了手动在 Web 控制台点任务，T3 Code 也支持通过接口或者 MCP 的方式对外暴露能力。MCP 在这里我简单提一下，它是 AI 编程生态里常见的一种工具交互协议，T3 Code 自身能被配置成 MCP server，这样其他 Agent 调度框架可以直接把任务投递进来。

我试用过一个流程：外层调度 Agent 负责理解用户意图，到了实际改代码的环节，就把任务交给 T3 Code 去执行。好处是外层 Agent 不需要知道内部仓库结构，只需要传进去一个规范化的任务描述，T3 Code 负责把任务拆解和执行细节全部搞定。对团队来说，这相当于把“谁负责改代码”这件事收口到一个地方，而不是让每个 Agent 都直接操作仓库。

由于 T3 Code 和外部交互最终都会记录成 Session，所以即使是通过接口投递的任务，回放和审计也依然保留。这个设计对需要合规审计的团队来说非常加分。

5. 边界与成本：哪些场景我不建议硬上

5.1 延迟与 Token 消耗的体感数据

我实际测试过几种并发配置下的表现。以“给现有模块补一个 CRUD 接口 + 单元测试”这种中等复杂度的任务为例：

这组数据不能当严谨 benchmark，只看趋势。明显能看到的是，并发到 5 个之后，总耗时并没有继续线性下降，反而因为任务之间互相等待文件锁、上下文重试次数增加，Token 消耗成倍上涨，可用变更比例却明显下降。

很多朋友跑多 Agent 就是图一个“快”，但最终你会发现，真正的瓶颈不是单任务耗时，而是审查成本。你生成 10 个低质量 diff，审核时间可能比你自己动手写还长。所以我的默认建议是：并行度控制在 2 到 3 个，超过这个数，性价比会断崖式下跌。

5.2 不适合 T3 Code 的几个典型场景

第一类场景是极小的临时脚本任务。比如你只是想让 Agent 写一个一次性数据清洗脚本，跑完就删，那完全没必要起一个控制台来管理。T3 Code 的价值在于“留痕”和“协作”，单次任务用 CLI 直接做反而更快。

第二类是涉及敏感环境的直接操作。T3 Code 目前对权限的管理主要是文件路径级别的白名单，底层的 Agent 如果被配置了可以执行任意 shell 命令，理论上还是有误操作风险。如果你需要 Agent 在生产环境机器上直接改配置，我建议不要让 T3 Code 直接管生产环境，而是让它只负责生成 diff，由人工确认后再应用。

第三类场景是团队还没有建立 AI 编程规范的时候。如果你连“什么任务适合交给 AI、什么任务必须人工写”都还没想清楚，引入统一控制台只会把混乱的流程放大，不会自动变好。工具是放大镜，不是清洗剂。

5.3 与 CI/CD 的职责边界

有朋友问过 T3 Code 能不能替代 CI，我的回答是别这么用。T3 Code 擅长的是“写代码”的过程管理，包括生成、审查、回滚；它的职责边界在“把代码提交到分支”这一层。至于分支合并后跑不跑得起来，是 CI 的活儿。

我目前的用法是：T3 Code 负责在本地分支上生成和验证代码，完成任务后保留一个干净的 commit；CI 负责拉取这个分支做更完整的检查，比如 lint、单测、构建。这样分工可以最大程度避免 Agent 自己开一大堆临时分支，又无法和现有 CI 流程协同的问题。

如果让 T3 Code 去跑 CI 工作流的自动化判断，它既不够稳定可靠，也缺少足够的流程上下文，出了问题很难定位。

6. 如果你也想引入 T3 Code，我的几条经验

6.1 第一天先接一个 Agent，跑通链路再谈并发

我见过不少同事一听说“统一控制台”很兴奋，上来就配置五个 Agent 并行，结果第一天就淹没在 diff 审查里。我的建议非常朴素：第一个星期只接你最有把握的那个 Agent，跑真实但低风险的任务。先让团队习惯在控制台里看 Session、看 diff、做回滚，这些基础动作熟练之后，再逐步加 Agent 个数和任务复杂度。

6.2 文件白名单和权限配置要提前定好

T3 Code 允许你在 Workspace 级别设定 Agent 可访问的目录。我在新项目里会先锁根目录，只在该放开的地方放开。具体操作是在任务描述里明确列出允许修改的路径，超出路径的改动全部标记为异常。这套思维和给外包开发人员开权限没什么区别——你越早规范，后面越少翻车。

6.3 把提示词也纳入版本管理

很多人在管理 Agent 的时候只盯着代码 diff，忽略了一个问题：同一个 Agent 在不同 prompt 下的表现是完全不同的，甚至可能相差很远。所以我建议把每个 Task 的 prompt 模板也存进 Git 仓库，和代码变更一起提交。T3 Code 的 Session 回放已经包含了 prompt 输入，但如果 prompt 本身有版本演进，你的复盘会更直观。

我现在每个项目的根目录下会放一个prompts/文件夹，里面按任务类型拆分成bugfix.md、feature.md、refactor.md等模板文件。新的 Task 直接引用模板，有变化就更新模板版本。这么做了两周之后，发现 Agent 的产出质量明显更为一致，因为大家用的是同一套“标准话术”，而不是每个人各自喷一段自由发挥的英文。

6.4 从 T3 Code 延伸出去的下一步想象

试用一段时间后，我最大的感受是这个工具真正解放的不是写代码本身，而是“管理代码生产过程”的那一部分。当所有 Agent 都变成可控的、可回放的、可成本量化的执行单元时，你就有机会把原来对“人”的研发管理逻辑，平移到对整个 AI 协作流程上。

我现在继续在用的扩展方向有两个：一个是把 T3 Code 的 Session 数据同步到数据分析平台，按周汇总每个 Agent 的耗时、Token 成本、失败率，用来判断下一步哪些任务更适合交给 AI；另一个是尝试用它做 code review，先让 Agent 按照团队规范检查每一次变更，再让核心成员只关注它筛出来的问题。

如果你也正处于“一个人开五个终端，不知道谁改了什么东西”的混乱期，与其继续靠意志力硬撑，不如花一个下午把 T3 Code 这类统一控制台跑起来。先从一个小任务开始，你会很快感受到“所有执行记录都在一个地方回放”到底意味着什么。