Claude Multi-Agent 系统：从零到跑通 4-Agent 内容团队的完整指南

TL;DR

本文核心观点：

专家团队永远胜过单打独斗的全能选手 — 这对 AI Agent 和对人类组织同样适用

4-Agent 是最小可行团队结构 — 覆盖知识工作的完整周期： intake → production → quality → distribution

边界定义质量 — 每个 Agent 清晰的 never does 是防止上下文污染的关键

30 天复利效应 — 每个 Agent 在自己领域持续学习，输出随时间指数级提升

📋 本文结构

为什么是四个 Agent — 不是随意选的数字
4-Agent 架构 — 研究 / 生产 / 质量 / 分发
Orchestrator 的角色 — 路由任务、管理失败
环境配置 — Claude Code + 项目结构 + CLAUDE.md
工作流实战 — 从任务输入到内容分发
延伸思考

一、为什么是四个 Agent

在谈架构之前，先说原理。

四个不是随意选的数字。

四个 Agent 代表最小可行团队结构，覆盖知识工作的完整周期：intake 和研究 → 生产 → 质量控制 → 输出和分发。

每个复杂知识工作都会经过这四个阶段。

单个 agent 在所有四个阶段之间上下文切换，产生的输出质量不一致、执行缓慢、出了问题难以调试。模型在同时优化太多东西。

四个专家型 agents 产生一致的输出，因为每个 agent 只有一个工作；执行快速，因为 agents 可以在工作流允许的地方并行运行；易于调试，因为失败隔离在发生的 agent 内部。

数学也很清楚。

一个 agent 顺序跑四个阶段的时间，是四个 agents 同时跑自己阶段的时间的四倍。对于每周生产 20 篇内容的内容业务，仅并行性差异就足以证明这个架构的合理性。

二、4-Agent 架构

Agent 1：Research Agent

Role：信息收集和综合
Input：一个主题、一个问题，或一个 brief
Output：结构化研究 brief
Never does：写作、编辑或发布

Agent 2：Production Agent

Role：将研究 brief 转化为成品内容
Input：Research Agent 的结构化 brief
Output：完整的初稿
Never does：研究、编辑或发布

Agent 3：Quality Agent

Role：评估和改进生产输出
Input：Production Agent 的初稿
Output：批准稿或具体修订 brief
Never does：研究、从头写作或发布

Agent 4：Distribution Agent

Role：格式化和部署批准的内容
Input：Quality Agent 的批准稿
Output：以正确格式部署到正确平台
Never does：研究、写作或质量评估

三、Orchestrator 的角色

Role：在 agents 之间路由任务、管理工作流、处理失败

Input：初始任务
Output：完成的交付物
Knows everything the other agents are doing. Each agent knows only its own task.

这是关键的设计选择：Orchestrator 是唯一知道全局的 agent。每个执行 agent 只知道自己的任务。这防止了上下文污染——当每个 agent 只处理一个领域时，它不会被其他领域的复杂性干扰。

四、环境配置

前提条件

Claude Code 已安装并配置
项目目录内有 master CLAUDE.md

文件夹结构

inbox/             — 任务输入
research-briefs/  — 研究简报输出
drafts/            — 初稿
approved-content/ — 批准内容
distribution/     — 分发准备
logs/              — 执行日志

Master CLAUDE.md 示例

# Multi-Agent Content System

## System Overview
4-agent content team: Research → Production → Quality → Distribution

## Agent Roles
- /agents/research.md    — Research Agent
- /agents/production.md  — Production Agent  
- /agents/quality.md     — Quality Agent
- /agents/distribution.md — Distribution Agent

## Workflow
1. Task lands in /inbox
2. Research Agent → /research-briefs
3. Production Agent → /drafts
4. Quality Agent → /approved-content or /drafts (revision)
5. Distribution Agent → deployed

## Quality Standards
Each agent has a never does list. Respect boundaries.

五、工作流实战

第一阶段：任务输入

将任务描述放入 /inbox/task.md：

# Task: 写一篇关于 multi-agent 系统的博客
Topic: Claude Multi-Agent systems
Audience: AI-Native 工程师
Length: 1500 words
Deadline: 2026-05-12

第二阶段：Research Agent

Research Agent 读取 /inbox/task.md，输出到 /research-briefs/YYYYMMDD-task-slug.md：

# Research Brief: Multi-Agent Systems

## Topic Overview
[研究结果...]

## Key Points
1. 四个 agents 覆盖完整周期
2. 并行比串行快 4 倍
3. 边界定义质量

## Sources
- [相关链接]

## Open Questions
[需要进一步确认的问题]

第三阶段：Production Agent

Production Agent 读取 brief，输出到 /drafts/YYYYMMDD-task-slug.md。

Quality Agent 给出修订 brief 或批准。

修订循环继续直到 Quality Agent 批准。

第四阶段：Distribution Agent

Distribution Agent 读取批准稿，部署到目标平台。

第五阶段：每日站会

# Daily Standup

Yesterday: [completed tasks]
Today: [planned tasks]
Blocked: [any blockers]

六、延伸思考

CyrilXBT 的这个 4-Agent 框架本质上是一个内容工厂的生产线设计。它的价值不在于每个 agent 本身，而在于它们之间的握手协议和边界定义。

最有意思的设计细节是 never does 列表。每个 agent 的 never does 是防止职责污染的护栏。当 Production Agent 明确”不写作”以外的任何事时，它不会因为”这个来源看起来不对”而开始修改研究内容。

这种边界设计的原则可以迁移到任何多 agent 系统：不要相信 agent 的自我约束，要用架构强制职责分离。

30 天复利效应是这个系统的隐藏价值。每个 agent 在自己领域积累经验，初稿质量逐月提升。这是真正意义上的认知复利——不是人在积累知识，而是 agent 的工作方式在积累知识。