Multi-Agent Peer Review Content: Design and Engineering a Reproducible Pipeline

1. From a Chat Experiment to a Reproducible Multi-Agent Content Project

Having multiple agents create content on the same topic, read one another’s work, evaluate it, and respond is essentially a lightweight multi-agent collaboration experiment. It is entertaining, but it also raises clear engineering questions: How can inputs be kept consistent? How can later participants avoid being influenced by earlier answers? How can raw results be preserved? How can text be converted reliably into visuals, voice, and video? And how can viewers understand the process and take part in judging it?

A complete project can usually be divided into five layers:

1. Role layer: Give each agent a stable, recognizable expression style.
2. Task layer: Standardize the topic, output format, word limits, and evaluation rules.
3. Experiment layer: Control the order in which information is exposed, preserve raw outputs, and record timestamps.
4. Production layer: Convert text into voiceover, subtitles, animation, and video.
5. Interaction layer: Collect audience feedback through voting, comments, or follow-up tasks.

If any layer is missing, the final work may run into problems. For example, unclear role settings can make four answers sound too similar; without input isolation, later agents may imitate an earlier response; without raw records, viewers cannot tell whether content was edited manually; and without production standards, video pacing and audio quality are difficult to keep consistent.

2. Unified Input: Making Comparisons Meaningful

The most important principle in a multi-agent experiment is to give every participant conditions that are as similar as possible in the first round. Unified content should include at least:

• Role identity instructions;
• Task objectives;
• Output order;
• Word limits for each part;
• Prohibited content;
• Answer stop conditions;
• Whether participants may use information from other participants.

For example, the task can be abstracted as:

Please provide the following for each of the other three participants:
1. A short nickname;
2. One positive comment;
3. One humorous but non-attacking criticism.
Requirements:
- Each participant must complete three sets of content;
- Nicknames should relate to role characteristics;
- Comments must not involve real-world identity, appearance, privacy, or sensitive attributes;
- Each set of content must stay within the specified word limit;
- In the first round, do not refer to other participants' answers.

This format is better suited to later editing than “free-form improvisation.” It gives outputs a fixed structure, makes automatic parsing easier, and helps viewers compare responses side by side.

At the same time, role settings should be “differentiated but controlled.” Different expression tendencies can be assigned, for example:

• Logical analytical type: prefers structured, restrained, precise wording;
• Light teasing type: focuses more on rhythm and verbal contrast;
• Warm encouraging type: emphasizes positive feedback and makes criticism more tactful;
• High-density creative type: good at using metaphors, but exaggeration should be limited.

Note that a role style is not the same as a brand persona, and it should not lead a model to imitate a real person. Roles should only serve content expression and experimental comparison.

3. Result Sealing and Information Isolation: Avoiding “Answer After Seeing the Answer” Bias

If the goal is to compare first-round results, the safest approach is a process of “answer everything first, then reveal gradually.”

1. Recommended Process

In the first stage, send exactly the same task to four agents and require independent completion.
In the second stage, save each answer’s raw text, task version, generation time, and system state.
In the third stage, after confirming that all first-round results have been saved, provide other answers to the corresponding agents one by one.
In the fourth stage, ask the agents to complete a second-round response, clearly distinguishing “original answer” from “follow-up response.”

To demonstrate that first-round results were not modified afterward, a content digest fingerprint can be generated. The digest fingerprint is not intended to hide content; it establishes a verifiable time record. The basic flow is:

Raw answer
   ↓
Unified encoding
   ↓
Generate content digest
   ↓
Save answer, time, task version, and digest
   ↓
Publish first-round results

In practice, the following metadata should also be saved:

• Version number of the task text;
• Role-setting version;
• Output word limits;
• Model category used;
• Request start and end times;
• Whether retries occurred;
• Whether manual redaction or formatting was applied.

This information helps creators explain the experiment boundaries when publishing and supports later review.

2. Why Screenshots Alone Are Not Enough

Screenshots are intuitive, but they are poor for retrieval, verification, and batch processing. A better approach is to save structured records as well:

{
  "round": 1,
  "role": "participant_a",
  "prompt_version": "v1",
  "answer": "...",
  "created_at": "2025-01-01T12:00:00Z",
  "content_digest": "..."
}

The video can show part of the digest information, while the full data can be saved as a project attachment or internal archive. This keeps the screen from becoming too crowded while preserving basic auditability.

4. Content Safety: Keeping “A Quick Jab” Within Humor

Mutual teasing is part of the appeal of this format, but there is a clear boundary between humor and attack. Task design should proactively exclude the following:

• Private information about real people;
• Sensitive attributes such as identity, ethnicity, gender, or illness;
• Disparagement of specific groups;
• Violence, threats, or malicious defamation;
• Content that encourages viewers to attack a participant;
• Fictional accusations that could be mistaken for facts.

A safer approach is to limit criticism to “expression habits, answer style, or virtual settings.” For example, instead of saying a role is “incompetent,” point out that it “often makes simple questions too complicated”; instead of attacking real-world attributes, tease it for “always trying to turn every answer into a formal document.”

Before publishing, run three checks:

1. Semantic check: Confirm that content has no real-world targets or malicious labels.
2. Context check: A single sentence should not cause serious misunderstanding when clipped out of context.
3. Subtitle check: Voiceover, subtitles, and on-screen text must remain consistent.

If a piece of content is clearly controversial, it is better not to keep it even if it could drive engagement. Long-term content projects need stable trust more than one-off stimulation.

5. From Text to Video: Building a Maintainable Production Pipeline

This type of work usually includes role avatars, dialogue bubbles, subtitles, transitions, background music, and sound effects. Rather than manually assembling everything across multiple tools, it is better to treat the visuals as a code-driven timeline.

1. Page Structure

The video interface can be divided into independent components:

• Top: title, round, and current task;
• Left and right areas: two roles in conversation;
• Center area: nickname, praise, criticism, or response;
• Bottom: subtitles and progress indicators;
• Background layer: gradients, particles, or lightweight motion effects.

Role data and page styles should be separated:

const speakers = [
  { id: "a", name: "Role A", color: "#6c8cff" },
  { id: "b", name: "Role B", color: "#ff9b6a" },
  { id: "c", name: "Role C", color: "#66c7a5" },
  { id: "d", name: "Role D", color: "#d48cff" }
];
const scenes = [
  {
    round: 1,
    from: "a",
    to: "b",
    label: "Nickname",
    text: "Example text"
  }
];

The benefit is that changing lines does not require rewriting layout code; adding new roles or rounds only requires extending the data.

2. Timeline Design

Each piece of content should have a clear start time, duration, and end action:

Scene start
→ Role avatar appears
→ Nickname card pops up
→ Positive comment appears
→ Criticism appears
→ Other party reacts
→ Transition to the next group

If voiceover lengths differ, do not simply assign a fixed number of seconds to every line. A more reliable approach is to generate audio first, read the audio duration, and let subtitles and animation follow that duration. For overly long text, split at semantic pauses so that too much subtitle content does not appear at once.

6. Speech Synthesis and Subtitle Synchronization

The most common problem in multi-role videos is that “all voices sound the same.” Even when using the same speech generation system, different roles should have different speed, pitch, pause, and emotion parameters. Parameters should not be exaggerated too much, or intelligibility will suffer.

Recommended steps:

1. Generate audio separately for each line;
2. Use a consistent numbering scheme for audio files;
3. Record the actual duration of each file;
4. Generate subtitle timecodes based on duration;
5. Apply consistent processing for plosives, sibilance, and volume;
6. Listen to each line before assembling the final video.

Subtitles are not only accessibility support; they also reinforce comedic timing. Each subtitle should preferably use short sentence structures. Keywords can be emphasized with color, weight, or slight scaling, but too many animation effects should not be used at the same time.

If the voice comes from a local or third-party general-purpose synthesis service, the ending credits or description should clearly state that it is a “synthetic voice, not the official voice of any real person.” This prevents viewers from assuming that the work was authorized by a relevant institution or individual.

7. Render Quality and Pre-Publish Validation

Web animations ultimately need to be rendered frame by frame into video. During rendering, focus on checking:

• Whether all text exceeds the safe area;
• Whether cropping occurs at different screen ratios;
• Whether garbled characters appear when fonts are missing;
• Whether transparent images have black edges;
• Whether the animation frame rate is stable;
• Whether audio and video gradually drift out of sync;
• Whether blank frames appear during transitions;
• Whether background music covers the voice.

It is advisable to output a low-resolution preview first to confirm pacing and logic, then perform the full render. Do not generate the final file immediately; otherwise, the cost of rework after discovering a subtitle error increases significantly.

Before publishing, someone who did not participate in production should also watch the video from start to finish. Creators often know all the context and may miss places that first-time viewers cannot understand. Test viewers should answer three questions:

1. Can they distinguish the four roles?
2. Can they understand the difference between the first and second rounds?
3. Do they know how to participate in voting or commenting?

If viewers cannot quickly understand the rules, the opening explanation still needs to be simplified.

8. Turning the Comment Section into Analyzable Feedback Data

Voting prompts should be as simple as possible. For example, ask viewers to choose the “best teaser” and the “best praiser.” To reduce invalid comments, explain the required format in advance and define how multiple selections will be handled.

When collecting feedback, do not look only at the most-liked comments. Also count:

• The number of positive comments each role receives;
• The number of criticisms or teasing comments each role receives;
• Viewers’ questions about the rules;
• The rounds viewers focus on most;
• New task types viewers want to see.

This data can inform the next episode. For example, if viewers generally find the first round interesting but the second round slow, the response segment can be shortened. If viewers prefer style differences between roles, strengthen role settings rather than simply increasing the number of lines.

9. Conclusion: The Engineering Method Behind a Creative Format

“Four agents give one another nicknames and respond” may look like a light interaction, but it actually combines prompt design, experiment control, content safety, data retention, speech synthesis, web animation, and video rendering.

To make it stable, the core is not letting models improvise freely, but establishing clear production constraints:

• Use unified tasks to ensure comparability;
• Use information isolation to reduce mutual imitation;
• Use digest fingerprints and metadata to preserve process evidence;
• Use safety rules to control the boundaries of teasing;
• Use structured data to drive visuals and subtitles;
• Use actual audio duration to calibrate the timeline;
• Use low-cost previews to reduce rework risk;
• Use comment data to guide later iterations.

On this basis, the format can be extended to debates, collaborative problem-solving, proposal review, role-playing, and multi-round voting. Whether the final work is published on a standard web page, a video platform, or deployed into Baidu AI Cloud’s object storage, container platform, logging service, and monitoring/alerting systems, project quality ultimately depends on whether the process is reproducible, whether results are explainable, and whether viewers can clearly understand what happened at each step.