TL;DR

本文核心观点：

  1. 专家团队永远胜过单打独斗的全能选手 — 这对 AI Agent 和对人类组织同样适用
  2. 4-Agent 是最小可行团队结构 — 覆盖知识工作的完整周期： intake → production → quality → distribution
  3. 边界定义质量 — 每个 Agent 清晰的 never does 是防止上下文污染的关键
  4. 30 天复利效应 — 每个 Agent 在自己领域持续学习，输出随时间指数级提升

为什么是四个 Agent

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

四个不是随意选的数字。

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

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

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

💡 Key Insight

单个 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：研究、写作或质量评估

Agent 4：Distribution Agent

Orchestrator 的角色

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

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

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

💡 Key Insight

Orchestrator 的全局可见性是整个系统的安全阀——它知道哪里堵了，而其他 Agent 只知道自己是否在干活。

环境配置

前提条件

本系统的部署要求非常轻量，无需额外的基础设施投入，但有几项前置条件决定了整个工作流能否顺畅运转。

Claude Code 版本：建议使用最新稳定版（>= 0.4.0），因为多 Agent 并行执行依赖 --worktree flag 和会话隔离能力，这些在早期版本中尚不完善。在项目初始化阶段运行 claude --version 确认版本号。

项目目录初始化：在目标项目根目录下创建 master CLAUDE.md（注意是项目级别，不是用户全局级别）。这个文件是 4-Agent 系统的共享契约，所有 Agent 启动时都会读取它来判断自己处于哪个角色。没有这个文件，系统无法区分不同项目的职责边界。

目录结构预设：至少需要 /inbox/、/research-briefs/、/drafts/、/outputs/ 四个目录。如果这些目录不存在，Orchestrator 在初始化阶段会自动创建，但手动预先建立可以避免运行时的权限问题。

网络与认证：如果 Distribution Agent 需要向外部平台推送内容（CMS、GitHub、Notion 等），需要在运行前完成对应的 API 认证配置。这部分由 Orchestrator 在任务分发时检查，缺少认证会导致工作流卡在第四阶段。

文件夹结构

项目目录的顶层结构遵循固定约定，所有 Agent 都依赖这个结构来定位输入和输出文件：

project/
├── master CLAUDE.md      # 共享契约，定义 4-Agent 系统的角色与规则
├── inbox/
│   └── task.md           # 任务入口，由需求方写入，等待 Orchestrator 认领
├── research-briefs/
│   └── YYYYMMDD-task-slug.md   # Research Agent 输出
├── drafts/
│   ├── YYYYMMDD-task-slug.md   # Production Agent 初稿
│   └── YYYYMMDD-task-slug-v2.md # 修订版本（质量审核后）
├── outputs/
│   ├── YYYYMMDD-task-slug-published.md  # 最终发布稿
│   └── YYYYMMDD-task-slug-platform-meta.json  # 平台元数据

每个文件名包含日期前缀（YYYYMMDD 格式），确保文件列表按时间顺序排列，便于 Orchestrator 追踪任务历史。-slug 部分是任务名称的 URL-safe 简化版本，如 llm-evaluation-framework 或 weekly-newsletter-23。

/inbox/ 是一个”收件箱”语义，文件一旦被 Orchestrator 认领后会标记为已处理（可移至 /_archive/），不会留在原地造成重复处理。/outputs/ 的文件是只读的发布产物，任何 Agent 都不会回写这个目录。

Master CLAUDE.md 示例

以下是一个最小可用的 master CLAUDE.md，涵盖 4-Agent 系统的核心约定。实际项目中可以根据领域需求增删字段，但角色定义和 never does 列表是必填项：

# 4-Agent 内容团队 — 共享约定

## 角色定义

### Orchestrator
- **职责**：任务路由、全局状态追踪、失败恢复
- **权限**：读写所有目录，调度任意 Agent
- **Never does**：不直接生成内容、不做质量判断

### Research Agent
- **职责**：信息收集、结构化brief生成
- **输入**：inbox/task.md
- **输出**：research-briefs/YYYYMMDD-task-slug.md
- **Never does**：不写作、不编辑、不发布、不调用Distribution Agent

### Production Agent
- **职责**：将研究brief转化为成品内容
- **输入**：research-briefs/ 中的brief文件
- **输出**：drafts/YYYYMMDD-task-slug.md
- **Never does**：不研究、不编辑、不发布、不访问inbox目录

### Quality Agent
- **职责**：质量评估、修订brief或批准发布
- **输入**：drafts/ 中的初稿
- **输出**：批准决定 + 可选修订brief（写回drafts/）
- **Never does**：不研究、不从头写作、不发布、不访问inbox目录

### Distribution Agent
- **职责**：格式化、部署到目标平台
- **输入**：drafts/ 中被Quality Agent批准的文件
- **输出**：outputs/ 下的发布产物
- **Never does**：不研究、不写作、不做质量评估、不回写drafts目录

## 共享上下文规则

1. 所有Agent通过文件系统传递信息，不通过内存共享
2. Orchestrator在每次任务切换时更新任务状态文件 `/.orchestrator/state.json`
3. 每个Agent的任务完成后向 `/tmp/agent-done/<agent-name>/<task-slug>` 写入标记文件
4. Orchestrator轮询标记文件目录检测任务完成状态

## 失败处理

- 单个Agent失败时，Orchestrator将任务状态标记为 `needs_review`
- 已生成的中间文件保留在原目录，不删除
- Orchestrator在下次调度时优先处理 `needs_review` 状态的任务

这个示例涵盖了所有四个角色、完整的 never does 列表和关键的共享上下文规则。实际使用时，将此文件放入项目根目录即可驱动整个系统。

工作流实战

第一阶段：任务输入

任务以 Markdown 文件的形式写入 /inbox/task.md，由需求方（或 Orchestrator 定时扫描）触发工作流。一个合格的 task brief 需要包含以下字段：

---
topic: LLM 评测框架的选择与配置
target_platform: 微信公众号
tone: 技术深度，面向有经验的开发者
deadline: 2026-05-20
priority: high
requester: 产品组
---

## 任务背景
（此处填写业务背景和写作目的）

## 核心要点
- （3-5个必须覆盖的点）
- 避免过于笼统的概述

## 参考资料
（链接、文档、或"无"）

Orchestrator 在启动时读取 inbox/task.md，验证必填字段是否完整。如果缺少 topic、target_platform 或 deadline，Orchestrator 会向需求方发送格式补全请求，而不是跳过这些字段继续执行——这是防止产出偏离目标的第一个关卡。

格式验证通过后，Orchestrator 生成任务 slug（将 topic 转换为 URL-safe 字符串），在 /research-briefs/ 和 /drafts/ 下预建空文件占位，然后触发 Research Agent 运行。从这一刻起，这个任务在整个系统中就有了唯一的身份标识，后续所有中间产物都以此 slug 命名。

第二阶段：Research Agent

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

第三阶段：Production Agent

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

Quality Agent 给出修订 brief 或批准。

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

第四阶段：Distribution Agent

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

第五阶段：每日站会

每日站会是 4-Agent 系统的”巡逻检查点”——不是仪式，而是信息同步机制。Orchestrator 在每天固定时间（通常是团队工作日开始时）汇总所有进行中任务的状态，生成一份结构化报告，分发给相关方。

报告内容：

  • 各 Agent 的任务完成数：当天完成了多少任务，处于哪个阶段
  • 阻塞点（Blockers）：哪些任务卡在某个 Agent 处超过 24 小时，原因是超时还是错误
  • 队列深度：等待处理的任务数量，如果某类任务堆积说明该 Agent 成为瓶颈
  • 30 天复利追踪：每个 Agent 的平均产出质量趋势——如果 Quality Agent 的”批准”比例持续上升，说明该 Agent 的判断标准在随时间收敛；如果 Production Agent 的初稿被要求修订的轮次在减少，说明领域熟悉度在积累

站会产出形式：一份 JSON 状态文件（/.orchestrator/daily-standup-YYYYMMDD.json）加上可选的摘要文字，通过 Slack/邮件/飞书等渠道推送。这份文件也是月度复盘的原始数据——当需要向团队解释某个 Agent 的产出为何在第三周突然提升时，30 天的历史数据就是答案。

站会的核心价值不在于”汇报”，而在于让 Orchestrator 的全局可见性真正发挥作用。每个 Agent 只知道自己当前的任务，但 Orchestrator 看到的是整个系统的热力图——哪里堵了，哪里空了，哪里在加速。

延伸思考

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

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

💡 Key Insight

never does 列表是架构层面的护栏，而非道德层面的约束——系统设计必须假设 Agent 会尝试边界外的行为，边界必须由结构强制执行，而非依赖 Agent 的自我判断。

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

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

💡 Key Insight

30 天复利效应的核心在于：Agent 的产出质量不是线性增长的，而是随着领域熟悉度累积出现跃升拐点——这是人工监督无法复制的时间壁垒。

结尾

4-Agent 框架最值得复制的设计点不是”4”这个数字，而是”边界定义 + never does”这套工程纪律。它的本质是承认 AI 代理和人一样，在多任务切换中会丢失注意力——单一职责才是稳定输出的前提。当你把”边界”作为物理约束编码进系统（Orchestrator 全局可见、文件目录隔离、文件系统协议传递信息），它就不再依赖代理自觉做好自己的部分。

30 天复利是这个系统最有商业价值的隐藏效果：每个 Agent 在自己的领域里重复犯错和被纠正，会积累出它独有的经验曲线。这意味着部署时间越久，竞争对手越难追赶——这是 AI 产品里少见的时间壁垒。可惜大多数团队还在追求”换一个更强的模型”而不是”让当前的模型在它的领域里练上三十天”。

如果把这个框架迁移到其他场景——法律文书、合规审查、代码评审、医疗编码——核心一样：先识别完整工作流的最小可行阶段数，再为每个阶段规定 never does，让边界的稳定性换来自治模型的质量。

💡 Key Insight

4-Agent 框架的真正价值不是并行加速，而是把”边界”从道德约束转化为架构约束——AI 不会再”顺手多做点”，这是稳定输出和 30 天复利的前提。

深度阅读时间：约 12 分钟

相关链接

本系列相关：