One Requirement, Five Agents: Reshape Your Development Rhythm with TRAE Multi-Agent Parallel Collaboration

Author: 悟空码字 Tags: Trae, AI Coding, AIGC

Competition track: Full-Lifecycle Development Practice Topic direction: Multi-Agent Parallel Collaboration

Hello everyone, I'm Xiaowu.

This article fully reviews a real project delivery process — from zero to a runnable visitor appointment registration system. Normal serial development would take at least two hours, but TRAE's multi-agent parallel collaboration compressed the time to under thirty minutes. The complete deliverables include a frontend prototype, backend APIs, test cases, and a full set of documentation.

---

1. Starting from a requirement

Visitor appointment registration system: visitors make an appointment online in advance, filling in their name, phone number, visit target, visit time, and reason; backend administrators view the appointment list, review appointments, and mark visit status. Runnable frontend pages, backend APIs, test cases, and a complete set of delivery documentation are required.

If this were done with a traditional single-agent serial development approach, the path would look roughly like this:

Understand requirement → draw prototype → write backend → integration test → write tests → write docs → deliver
   └─ each step depends on the previous one, and finding a problem midway means rework

Conservative estimate: 2 hours, with the integration stage most prone to repeated friction from mismatched frontend and backend fields.

This time something different was done: in Agent mode, multiple dedicated agents were dispatched at the same time to advance all modules in parallel. What was the result? First, look at an architecture diagram:

This diagram is the core metaphor of the entire article: the main control Agent acts like a project director, dispatching one requirement to four "professional team leads" at the same time. The four team leads never block each other; each advances independently. Once the first drafts are ready, the main control does horizontal alignment, detects conflicts, and immediately fixes them in parallel. No one waits for anyone else.

2. The clear division of labor among the five agents

You might ask: "Why five? What does each one actually do?"

A good multi-agent system is not about having as many agents as possible; rather, each agent's responsibility boundary must be clear enough, and its inputs and outputs standardized enough. The five agents this time are defined as follows:

Agent No.	Code name	Responsibility	Input	Output
01	Orchestrator-Main (main control)	Requirement decomposition, parallel scheduling, milestone control, cross-module conflict detection and resolution	Complete requirement document	Field alignment specification, conflict report, delivery checklist
02	UI-Page (prototype page)	Frontend prototype + runnable Mock code	Page list, field requirements, validation rules	Complete Vue3 project + page structure documentation
03	Backend-Code (business coding)	Backend API + data model + validation middleware	API list, data model, validation rules	Complete Express project + API Schema documentation
04	Test-QA (testing and validation)	Test case design + defect report template	Feature list, validation rules	Test plan + 58 test cases + defect report template
05	Doc-Writer (documentation)	Complete delivery documentation	System overview, tech stack	PRD + operation manual + deployment guide + ops troubleshooting

The main control Agent (01) does not write business code; its only job is to make the other four agents collaborate efficiently. This is a key design decision — separating orchestration from execution. Each sub-agent focuses only on its own domain, avoiding the context confusion that comes from one agent simultaneously thinking about page layout, database design, and documentation.

3. Task decomposition: understanding "how to split" in one diagram

The prerequisite for multi-agent parallel collaboration is that tasks can be split. If the four sub-agents' outputs are highly coupled, starting them at the same time only ends with them waiting on each other. So how was the split done?

There is a very counterintuitive design here: the main control Agent does not preset the final field names before dispatching tasks. It only states the semantics clearly, such as "visitor name", and lets the frontend and backend each come up with the most suitable English key. It compares only after the drafts are done — this exposes problems better than the main control deciding on a name upfront.

The reason is simple: frontend and backend are likely to have different "best naming" for the same business concept. The frontend tends toward short names (name), while the backend tends toward semantically complete names (visitorName). If the main control had settled on a name at the start, one side would have to compromise, and the compromise would probably spread beyond field names into the whole data structure design. Let both sides think independently first, then align under the main control's coordination — that is the real quality gate.

4. Parallel practice

The flowchart below shows the timeline of the whole process. Note that the 4 sub-agents start strictly at the same time — the main control Agent issues 4 Task calls in a single turn, then waits for each to finish and return results.

4.1 First parallel wave: four drafts produced at the same time

The four sub-agents each independently complete their own domain:

• Prototype page Agent built a complete Vue3 + Element Plus project, including the visitor appointment form page, appointment result page, status query page, and administrator list page. It used localStorage to seed 4 preset Mock records (covering the four statuses pending/approved/rejected/visited) and output a pages-structure.md listing all field names, data types, and validation rules in detail.

• Business coding Agent built an Express + SQLite project, implementing 7 APIs: submit appointment, query details, admin list, approve review, reject review, mark visited, and visitor query, and passed 17 interface self-tests. It output api-schema.md detailing the request/response body fields of every API.

• Testing and validation Agent produced 57 test cases (P0:39 / P1:9 / P2:9), covering 10 categories including normal flows, required-field validation, phone number format, time boundaries, query functionality, and administrator operations. Each case reserved placeholders such as ${visitorName}, to be replaced once the real field names were settled.

• Documentation Agent wrote 4 delivery documents: PRD (with mermaid flowcharts), user operation manual, deployment guide, and ops troubleshooting (with a fault table of 20+ entries).

4.2 The first wave already hit a snag: field alignment conflicts

Once the four drafts were out, the main control Agent immediately did the most critical thing — pulled out the frontend's pages-structure.md and the backend's api-schema.md and compared the field names. The result: 3 Critical-level conflicts + 1 booking-number format conflict:

Business meaning	Frontend field name	Backend field name	Consequence
Visitor name	name	visitorName	During integration, the frontend sends name, the backend never receives it
Visit target	visitTarget	hostName	Same as above
Visit reason	reason	purpose	Same as above
Booking number format	2610210001 (YYMMDD + 4-digit number)	RSV17294688000001234 (RSV + timestamp + random number)	The query API regex doesn't match

With serial development, these conflicts would only be discovered at the integration stage — by then the frontend, backend, and tests are all written, and the rework cost is extremely high. In parallel mode, however, they are discovered the moment the drafts are produced, and fixing them takes only one turn.

The fix also used a parallel strategy: the frontend Agent renamed all fields to align with the backend specification (6 files modified in sync), and the test Agent replaced the placeholders in the 57 test cases with real field names. The two fix tasks were dispatched in the same turn and completed in the same turn.

After the fix, the frontend passed npm run build, and the test cases were upgraded to 58 with zero leftover placeholders. A true "out of the left pocket, into the right pocket" flow — the main control dispatched the fixes the moment it received the conflict report; no one waited.

5. Efficiency data: serial vs parallel

At this point you might want to know exactly how much efficiency improved. Let's look at a Gantt chart:

Core numbers:

• Serial development (including mid-way rework): about 2 hours
• Actual time with multi-agent parallelism: about 0.5 hours
• Efficiency gain: about 4x

And this is not simply "opening 4 terminals at once". The rework time of serial mode is completely eliminated in parallel mode — because the field alignment check was moved forward to "right after the drafts come out" instead of waiting until "all the code is written".

6. Taking stock: a general, reusable collaboration pattern

This build is not an isolated case. It can be distilled into a multi-agent parallel collaboration pattern for any small or medium project, called the "1+4 parallel architecture":

The pattern has five key design principles, applicable to any project:

Principle one: the main control does not write code

The main control Agent's only responsibility is decomposing the requirement + scheduling sub-agents + alignment checks + conflict coordination. If the main control starts writing code itself, it loses its orchestration perspective and becomes a "serial executor". A good main control should act like a project manager, not a senior developer.

Principle two: standardize sub-agent inputs and outputs

Each sub-agent's task description must include three elements: specified tech stack, deliverable checklist, and constraints. For example, the task given to the UI Agent explicitly states "Vue3 + Element Plus", "produce package.json + 4 view files + pages-structure.md", and "phone number regex /^1[3-9]\d{9}$/". This makes the four sub-agents' output formats highly predictable, so the main control can compare them automatically.

Principle three: let sub-agents think independently first, then align under the main control

Do not force unified naming before dispatching tasks. Let the frontend choose the most suitable field names itself, let the backend define its own API schema, let the tests plan their own validation baseline — independently produced solutions are higher quality and expose design conflicts more readily. Then the main control does one round of horizontal comparison, turning conflicts into "discussable problems" rather than "default assumptions".

Principle four: fixes are parallel too

After a conflict is discovered, do not have one agent fix things slowly while the others wait. The main control should break the fix work down and dispatch it in parallel again. In this build, the frontend field fix and the test-case placeholder replacement were completed in the same turn; nobody waited.

Principle five: alignment checks must run automatically

The main control Agent cannot rely on "memory" to do alignment. It must explicitly read each sub-agent's alignment output documents (such as pages-structure.md and api-schema.md) and compare them at the text level. In this build, if the main control had not explicitly read those two documents, the 3 field conflicts would very likely have been missed — and the price of missing them is rework across the entire integration phase later.

7. Two key pieces of code

No amount of words beats seeing the actual effect. Below is the core call code for the main control Agent dispatching the four subtasks:

// Main control Agent: synchronously dispatches 4 Task calls in the same turn
// The 4 sub-agents start simultaneously and do not block each other
const results = await Promise.all([
  Task({
    description: "Prototype page Agent",
    subagent_type: "general_purpose_task",
    query: `Develop the visitor appointment registration system frontend...
      Tech stack: Vue 3 + Vite + Element Plus
      Deliverables: complete project + pages-structure.md`
  }),
  Task({
    description: "Business coding Agent",
    subagent_type: "general_purpose_task",
    query: `Develop the visitor appointment registration system backend...
      Tech stack: Node.js + Express + SQLite
      Deliverables: complete project + api-schema.md`
  }),
  Task({
    description: "Testing and validation Agent",
    subagent_type: "general_purpose_task",
    query: `Write test cases and reports...
      Deliverables: test-cases.md + test-plan.md + defect-template.md`
  }),
  Task({
    description: "Documentation Agent",
    subagent_type: "general_purpose_task",
    query: `Write the complete delivery documentation...
      Deliverables: PRD.md + user manual.md + deployment.md + ops.md`
  })
]);

The main control Agent's alignment-check core logic is even simpler — like diffing two config files:

// Main control Agent: field alignment check pseudocode
const frontFields = read("pages-structure.md");  // the field table output by the frontend
const backFields  = read("api-schema.md");        // the field table output by the backend

// Compare, field by field, whether the mapping of business meaning → English field name is consistent
const conflicts = compare(
  extractMapping(frontFields, "business meaning → English field name"),
  extractMapping(backFields,  "business meaning → English field name")
);

// Immediately fix in parallel once conflicts are found
if (conflicts.length > 0) {
  await Promise.all([
    Task({ query: "Rename frontend fields to align with the backend specification" }),
    Task({ query: "Replace test-case placeholders with real field names" })
  ]);
}

These two pieces of code are the core of the entire parallel collaboration: dispatch simultaneously, check explicitly, and upon discovering conflicts, fix in parallel immediately.

8. Conclusion

The industry has been discussing "multi-agent" for a while, but much of the discussion stays at the framework level (LangGraph, AutoGen, CrewAI). Few explain clearly how tasks are actually split, how conflicts are discovered, and how quality is guaranteed in a real project.

This visitor appointment registration system build gives a very concrete answer:

Multi-agent parallel collaboration is not some fancy architectural pattern; it is simply moving "spawning multiple worker threads at once" from the CPU layer to the AI Agent layer.

You do not need to build a complex multi-agent framework first. All you need is:

1. A main control that does not write code, focused on scheduling and alignment
2. Several sub-agents with clear responsibilities, each independently completing its own domain
3. An explicit alignment-check step that discovers conflicts as soon as drafts come out
4. Parallel fixes, instead of letting one person slowly make changes

Do these four things well, and the efficiency of AI development may go from "one requirement per day" to "a complete deliverable in one morning". And this may be the way of working that developers truly need in the AI era.

Thank you for reading my article. Since you've made it this far, if you think it's good, go ahead and like, share, and bookmark — thank you. We'll see each other next time.

Your one-click like, share, and bookmark is my biggest motivation to keep updating, thank you.

Mountains and rivers will meet again, and the days ahead are all worth looking forward to. Thanks for reading, until we meet again.

The golden cudgel in my hand reaches the heavens above and the seas below.