Trae 多 Agent 架构：理解 AI 协作的底层逻辑

什么是多 Agent 架构

你用 Trae 的 Builder 模式写过稍微复杂点的需求吗？比如”帮我搭一个带登录功能的 Todo 应用”。你会发现，Trae 不是一股脑把代码甩给你，而是有条不紊地：先分析需求、再规划结构、然后逐步编码、最后检查问题。

这背后就是多 Agent 架构在起作用。

传统 AI 编程助手大多是单 Agent——一个模型干所有事，像让一个人同时当产品经理、架构师、程序员和测试员。多 Agent 的思路不同：把复杂任务拆给多个专门的 Agent，各管各的。

单 Agent：用户需求 → [一个模型处理所有事] → 输出结果

多 Agent：用户需求 → [规划] → [编码] → [审查] → 输出结果
                       ↑                     │
                       └─── 反馈循环 ─────────┘

维度	单 Agent	多 Agent
任务复杂度	适合简单明确的任务	能处理多步骤跨文件的复杂任务
上下文管理	容易超出上下文窗口	每个 Agent 只关注自己的上下文
错误处理	出错后难以自我纠正	审查 Agent 可以发现并修复问题
输出质量	依赖单次生成质量	多轮协作逐步提升质量

Trae 的 Agent 分工

Trae 的多 Agent 系统由三类核心 Agent 组成：规划、编码、审查。

规划 Agent（Planner）

整个流程的”大脑”，负责理解意图、拆解任务、确定依赖和执行顺序：

// 规划 Agent 的输出（概念示意）
const plan: TaskPlan = {
  goal: "搭建带登录功能的 Todo 应用",
  subtasks: [
    { id: 1, type: "scaffold", desc: "初始化项目结构" },
    { id: 2, type: "code", desc: "实现用户认证模块" },
    { id: 3, type: "code", desc: "实现 Todo CRUD 功能" },
    { id: 4, type: "code", desc: "实现前端页面" },
    { id: 5, type: "review", desc: "检查代码质量和安全性" },
  ],
  dependencies: [{ from: 1, to: [2, 3, 4] }, { from: 2, to: [4] }],
  executionOrder: [1, 2, 3, 4, 5],
};

编码 Agent（Coder）

实际写代码的”手”。它接收子任务，读取项目上下文，生成代码，调用工具完成操作。编码 Agent 可以有多个并行工作——一个写后端 API，另一个同时写前端组件。

审查 Agent（Reviewer）

质量的”守门员”，检查语法逻辑、验证项目规范、发现 bug 和安全问题，不通过就打回给编码 Agent 返工：

审查 Agent 的检查清单：
├── 语法检查：代码能否正常编译/运行
├── 逻辑检查：实现是否符合需求
├── 规范检查：是否遵循项目的 Trae Rules
├── 安全检查：有无明显的安全漏洞
└── 一致性检查：与现有代码风格是否统一

自定义 Agent：工具、技能与逻辑

Trae 允许你通过配置来自定义 Agent 的行为。

工具（Tools）

Agent 的能力取决于它能调用哪些工具。除了内置的文件读写、终端执行、代码分析等，你还可以通过 MCP 接入自定义工具：

{
  "mcpServers": {
    "database": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "postgresql://localhost:5432/mydb" }
    }
  }
}

这样 Agent 就能直接查询数据库，而不仅仅是读写文件。

技能（Skills）

通过 Trae Rules 定义 Agent 应该具备的专业技能：

# .trae/rules
## 编码规范
- 使用 TypeScript strict 模式
- 组件使用函数式写法，不用 class
## 测试要求
- 使用 Vitest，覆盖率不低于 80%
## 架构偏好
- 前端 React + Zustand，后端 Hono，数据库 Drizzle ORM

自定义工作流

组合工具和技能，定义 Agent 的工作逻辑，比如写完代码自动跑测试：

const coderWorkflow = {
  steps: [
    { action: "read_context", tool: "file_read" },
    { action: "generate_code", tool: "code_generation" },
    { action: "write_files", tool: "file_write" },
    { action: "run_tests", tool: "terminal_exec", command: "npm test" },
    { action: "check_result", onFailure: "fix_and_retry", maxRetries: 3 },
  ],
};

Agent 通信与协调

Trae 采用中心化协调模式，由 Orchestrator（编排器）统一调度：

                ┌─────────────┐
                │ Orchestrator│
                └──────┬──────┘
           ┌───────────┼───────────┐
     ┌─────┴─────┐ ┌───┴───┐ ┌────┴─────┐
     │  Planner  │ │ Coder │ │ Reviewer │
     └───────────┘ └───────┘ └──────────┘

编排器接收用户输入转发给规划 Agent，根据规划调度编码 Agent，编码完成触发审查，审查不通过就打回修改，全部完成后汇总结果。

Agent 之间通过结构化消息通信，每个 Agent 的状态都被追踪：

状态	含义	触发条件
`idle`	空闲等待	初始状态或任务完成
`planning`	正在规划	收到新需求
`executing`	正在执行	收到子任务分配
`reviewing`	正在审查	编码 Agent 提交结果
`blocked`	被阻塞	等待依赖任务完成

在 Builder 和 SOLO 中的体现

Builder 模式

Builder 中多 Agent 协作最直观。你输入”给页面加搜索功能”，规划 Agent 拆解任务，编码 Agent 逐步执行，审查 Agent 检查结果。你看到的”思考中…”、“正在编写…”、“正在检查…”，就是不同 Agent 在轮流工作。

SOLO 模式

SOLO 模式下 Agent 自主性更强——规划 Agent 自主决定技术方案，编码 Agent 连续执行不需要每步确认，审查标准也更严格：

Builder: 用户 → 规划 → [确认] → 编码 → [确认] → 审查 → 完成
SOLO:    用户 → 规划 → 编码 → 审查 → 修复 → 再审查 → 完成
                   （全程自主，无需确认）

SOLO 适合你对 Trae 足够信任、需求描述足够清晰的场景。

与 Claude Code Agent Teams 简要对比

维度	Trae 多 Agent	Claude Code Agent Teams
运行环境	IDE 内集成	终端 CLI
Agent 创建	系统自动管理	用户通过命令显式创建
协调方式	内置编排器自动协调	Lead Agent 协调 Executor
并行能力	内部并行，用户无感	显式并行，用户可控
自定义程度	通过 Rules 间接配置	通过 prompt 直接定义角色
适合场景	GUI 偏好、快速开发	CLI 偏好、精细控制

# Claude Code：显式控制
/team 3:executor "重构所有 API 路由为 RESTful 风格"

# Trae：在 Builder 中直接描述需求
# "帮我把所有 API 路由重构为 RESTful 风格"
# Trae 自动决定需要几个 Agent、如何分工

核心区别：Trae 把多 Agent 的复杂性藏在 IDE 背后；Claude Code 给你更多控制权，但也需要你理解 Agent 的工作方式。

实战：观察复杂任务中的多 Agent 协作

在 Builder 模式中输入：

给这个 Express 项目添加用户认证功能：
- JWT token 认证
- 注册、登录、登出
- bcrypt 加密密码
- 认证中间件保护 API 路由

你会看到规划 Agent 先输出执行计划，然后编码 Agent 逐步生成代码：

// middleware/auth.middleware.ts — 编码 Agent 生成
import { Request, Response, NextFunction } from "express";
import jwt from "jsonwebtoken";

export const authMiddleware = (req: Request, res: Response, next: NextFunction) => {
  const token = req.header("Authorization")?.replace("Bearer ", "");
  if (!token) return res.status(401).json({ message: "认证令牌缺失" });

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET!) as { userId: string };
    (req as any).userId = decoded.userId;
    next();
  } catch {
    return res.status(401).json({ message: "无效的认证令牌" });
  }
};

接着审查 Agent 介入，发现 JWT_SECRET 用了非空断言、缺少 token 过期配置等问题，编码 Agent 自动修正。这个循环可能进行多轮，直到审查通过。

优势与局限

优势	局限
复杂需求被清晰拆解执行	简单任务可能比单 Agent 更慢
内置 Code Review 保障质量	规划失误会导致连锁反应
上下文管理高效不会”迷路”	出问题时难判断是哪个 Agent 的锅
只需描述需求，无需理解调度	多 Agent 意味着更多 Token 消耗

场景	推荐方式
简单代码补全	单 Agent（Chat 模式）
单文件修改	单 Agent 即可
多文件功能开发	多 Agent（Builder 模式）
完整项目搭建	多 Agent（SOLO 模式）

未来展望

多 Agent 架构在 AI 编程领域还处于早期，但方向已经很清晰：更智能的规划、更多专业 Agent（测试、部署、文档）、跨工具协作（通过 MCP 等标准协议）、学习与记忆能力、以及更好的人机协作平衡。

Trae 的多 Agent 架构代表了一个重要方向：不是让一个超级 AI 做所有事，而是让多个专业 AI 像团队一样协作。这和现实中的软件团队是一个道理——没有人能独自搞定所有事，但一个配合默契的团队可以。

多 Agent 不是让 AI 变得更复杂，而是让复杂的任务变得更简单。当你在 Trae 中输入一个需求，背后是多个 Agent 在默默协作——就像一支训练有素的团队，各司其职，只为交付你想要的结果。

加载中...