# How To Build A Full Team Of Agents To Improve Workflow (Full Course).
**作者**: NeilXbt
**日期**: 2026-05-17T13:32:38.000Z
**来源**: [https://x.com/neil_xbt/status/2056004969430450276](https://x.com/neil_xbt/status/2056004969430450276)
---
There is a version of your content operation where you do not write, research, edit, or publish manually.
A research agent finds the non-obvious angle on any topic you give it. A production agent turns that research into a first draft that sounds like you wrote it at your best. A quality agent rejects anything below your defined standard and tells the production agent exactly what to fix. A distribution agent takes the approved output and formats it correctly for every platform you use.
You create the system once. Then you give it a topic and walk away.
This is not a hypothetical. It is a specific architecture that any person who uses Claude can build over a weekend, without a computer science degree, without DevOps experience, and without writing a single line of code beyond the configuration files the system needs.
The principle behind it is the same principle behind every high-performing team. Specialists consistently outperform generalists doing many things at once. When you ask one Claude session to research, write, review, and publish in the same conversation, you get context-switching, conflicting quality standards, and output that is mediocre across every phase. When you build four agents with distinct roles and clear handoffs, you get output that is excellent across every phase because each agent is doing exactly one thing.
Here is the complete architecture and exactly how to build it.
## Why Four Agents and Why This Structure
The number four is not arbitrary. It maps directly onto the four phases that every piece of knowledge work passes through, whether you have ever named them or not.
The first phase is intake and research. Raw information is gathered, synthesized, and shaped into a structured foundation that everything downstream will be built on. The second phase is production. The research foundation is turned into a finished first draft. The third phase is quality control. The draft is evaluated against defined standards and either approved or returned with specific instructions for revision. The fourth phase is output and distribution. Approved content is formatted correctly for each target platform and deployed.
Every complex knowledge work task passes through these four phases. A single agent context-switching between all four phases is slow, inconsistent, and difficult to debug when something goes wrong. Four specialized agents produce work that is consistent because each has one job, fast because agents can run their phases simultaneously where the workflow allows, and easy to debug because failures are isolated to the agent where they occur.
There is also a parallelism argument worth stating clearly. One agent running four phases sequentially takes four times as long as four agents running their phases in parallel. For anyone producing consistent content output, that time difference compounds quickly.
## Before You Build Anything: The Foundation That Makes It Work
Three things need to be in place before you build a single agent.
First, Claude Code installed and configured. If you do not have it yet, install it with npm install -g @anthropic-ai/claude-code and authenticate through the standard flow.
Second, a project directory with the folder structure your agents will use. Create the directory and build these folders inside it: inbox, research-briefs, drafts, approved-content, distribution, and logs. The inbox is where tasks enter the system. Each subsequent folder receives the output of the agent that precedes it in the workflow. Logs records every agent action in one place, which is what makes the system debuggable when something goes wrong.
Third, a master CLAUDE.md file at the root of your project. This file is the shared context every agent reads before taking any action. It defines the system, establishes the shared standards, names the agents and their roles, and sets the hard rules that govern every interaction.
Your CLAUDE.md should contain six sections. A system overview describing what the system does in two or three sentences. An agent roster naming each agent and its specific role. The folder structure with a one-line description of what belongs in each folder. Shared standards covering naming conventions, logging requirements, and minimum quality thresholds for each agent. The quality bar that production must meet before the quality agent will approve. And the hard rules: never delete files (archive to a timestamped backup instead), never publish without quality approval recorded in the file header, log every action before taking it, and when uncertain stop and flag for human review rather than guessing.
That last hard rule is the most important. An agent that halts and flags uncertainty produces one problem. An agent that guesses incorrectly in the wrong direction produces a different class of problem that is significantly more expensive to resolve.
## Agent 1: The Research Agent
The Research Agent is the most consequential agent in your system because the quality of every agent that follows depends entirely on what it produces.
A weak research brief produces a weak draft. A strong research brief produces a strong draft. The production agent cannot add insight the research agent did not find. The output quality ceiling of your entire system is set here.
The Research Agent's job is narrow and specific. Given a topic or a brief from the inbox folder, it produces a structured research document with exactly the following components: the core insight in one sentence, the non-obvious angle that most people miss; the target audience described specifically; at least three supporting pieces of evidence with sources; the counterintuitive angle that creates genuine interest; two or three specific data points or quotes; and three ranked content angles with one-sentence descriptions of each.
The quality standard for the research brief has one non-negotiable criterion. If the core insight is something most people already know, it fails. The research agent must produce a genuinely non-obvious insight or be directed to search further. Generic research produces generic content. The quality of your content operation scales directly with this standard.
The Research Agent's system prompt ends with a logging instruction: before completing the task, append a timestamped entry to logs/operations.md documenting what was researched and where the brief was saved. Every agent logs before completing, not after. The log is the paper trail that makes the system auditable.
## Agent 2: The Production Agent
The Production Agent turns research briefs into finished content. It reads the brief, selects the strongest angle, and writes a complete draft that matches your voice profile and meets the quality standards defined in the CLAUDE.md.
The most important configuration decision in your entire system is the voice profile you give the Production Agent. This is what determines whether the output sounds like you or sounds like a generic AI assistant. Generic AI content fails because it sounds generic. A precisely calibrated voice profile produces content that sounds like you wrote it at your best.
Before you write the Production Agent's system prompt, invest thirty minutes in this preparatory exercise. Take ten of your best-performing pieces of content and ask Claude to analyze them and extract: your average sentence length, your capitalization patterns and what you capitalize strategically, your structural patterns for opening and developing and closing, your vocabulary level and specific word choices, what you never do (the hedges and filler phrases you consistently avoid), how you handle transitions between ideas, and your call-to-action style.
Save that analysis. It becomes the voice profile section of your Production Agent's system prompt. The agent does not guess at your style. It works from a documented, analyzed, example-based profile that reflects your actual best work.
The Production Agent's output includes a metadata header at the top of every draft file that records which research brief it used, which content angle it selected and why, the word count, and the production date. This header is what allows the Quality Agent to trace decisions and the Orchestrator to track the workflow.
## Agent 3: The Quality Agent
The Quality Agent is the gate between production and publication. Most multi-agent systems skip this step and wonder why their outputs are inconsistent.
Without a quality gate, every piece of content that exits the production agent goes directly to distribution regardless of quality. Good days produce good content. Bad days produce bad content. There is no floor.
With a quality gate, nothing gets published below a defined standard. The floor is consistent because the evaluation is consistent.
The Quality Agent evaluates every draft on five criteria, each scored from one to ten. Voice match: does this sound exactly like the configured voice profile? Hook strength: does the first line stop a scroll? Information density: does every sentence earn its place? Call-to-action clarity: is the CTA specific and compelling? Format compliance: does the piece follow all format requirements?
The passing threshold is eight or above on all five criteria. Not an average of eight. Eight on every criterion individually. A piece that scores ten on four criteria and six on one fails and is returned with specific revision instructions.
The critical design principle here is in the word "specific." The quality agent must never give vague feedback. Not "make it more engaging." Not "the hook needs work." The revision brief must name the exact criterion that failed, describe the precise problem in that criterion, specify the exact change required, and ideally show a short example of the correct approach. Vague feedback produces vague revisions. The production agent can only fix what it understands clearly.
When all five criteria score eight or above, the quality agent adds an approval header to the file noting the date and the score on each criterion, and moves the file to the approved-content folder. That approval header is what authorizes the distribution agent to act. Nothing that lacks the approval header gets distributed. This is a hard rule the distribution agent enforces regardless of context.
## Agent 4: The Distribution Agent
The Distribution Agent is the final agent in the chain. Its job sounds simple but is consistently executed poorly when done manually: taking approved content and formatting it correctly for each target platform before publishing.
Different platforms require genuinely different content. A LinkedIn post that works at 400 words with a narrative structure fails on X where 280 characters per tweet is the constraint and every tweet must stand alone. A newsletter section with headers and clear structural hierarchy looks wrong reformatted without adjustment for a shorter social post. A single piece of content published identically across platforms performs worse on every platform than the same content formatted specifically for each.
The Distribution Agent solves this by maintaining platform-specific formatting guidelines and applying them automatically to every approved piece based on the target platforms listed in the content header. It never publishes to a platform without platform-specific formatting. It records every deployment in a timestamped log. And it verifies the quality approval header before taking any distribution action.
## The Orchestrator: The Brain That Connects Them
The Orchestrator is not a fifth agent. It is the routing logic that connects the four agents into a coherent workflow.
The Orchestrator receives an incoming task, routes it to the Research Agent, monitors for the research brief's appearance in the research-briefs folder, passes the brief to the Production Agent, monitors for the draft, passes the draft to the Quality Agent, handles either the approval path or the revision routing path, and confirms completion when the Distribution Agent records a successful deployment.
Two failure scenarios require specific handling in the Orchestrator's design.
A quality rejection routes back to the Production Agent with the revision brief. This is an expected path, not a failure state. The system anticipates that some drafts will require revision and routes them cleanly.
A distribution failure logs the failure and alerts for human review. It does not retry automatically. Distribution failures often have context-specific causes that require human judgment, and an agent that retries a distribution failure without that judgment can produce duplicate posts or compounding errors.
The Orchestrator makes no creative decisions. It routes and manages. That constraint is what keeps the system predictable.
## Running Your First End-to-End Task
With all four agents configured, create a task file in your inbox folder. It should contain the topic or content type, the target platforms for distribution, any specific requirements for this piece, and the deadline.
Trigger the Orchestrator with: claude "Read CLAUDE.md. You are the Orchestrator. A new task has arrived in inbox/[TASK-FILENAME]. Begin the workflow. Route to Research Agent first."
Then watch the output folders. Each folder in the chain receives a file when the preceding agent completes its work. The logs/operations.md file receives an entry at every step. The first end-to-end run will take fifteen to thirty minutes depending on topic complexity and research depth.
After ten runs the workflow becomes predictable and the quality of each component is clear. After fifty runs the system has accumulated enough operational history to reveal its own improvement opportunities, which agents are producing weak output that needs quality configuration tuning, which platform formats are working and which need adjustment, which topics the research agent finds easy versus where it consistently hits limitations.
## The Compounding Mechanism
A well-configured 4-agent system does not just produce better output than a single agent. It produces output that improves over time.
After each week of operation, spend ten minutes reviewing what worked and what did not. Update the CLAUDE.md with performance observations. Improve the voice profile in the Production Agent with examples from drafts that the Quality Agent approved with high scores. Tighten the Quality Agent's rubric wherever it allowed something through that, in retrospect, should not have passed. Add platform-specific formatting lessons to the Distribution Agent when a deployment underperformed.
The system learns what you feed it. Every week you feed it better information about what good looks like in your specific operation. Every week the output reflects that information.
One person running a 4-agent team with consistent weekly calibration produces the output of a team of four, with more consistency, faster turnaround, and a feedback loop that most human content teams do not build into their operations.
The first agent is the hardest to build because the whole system feels abstract until something runs end-to-end. After the first complete workflow, the pattern is clear. After the second agent, the architecture makes sense. After the third and fourth, the system feels less like a collection of configurations and more like a team that shows up every day and does what you trained it to do.
Build the Research Agent this weekend. Let it run on one real topic. Read what it produces.
That single output will tell you more about what the system can become than anything in this article.
## 相关链接
- [NeilXbt](https://x.com/neil_xbt)
- [@neil_xbt](https://x.com/neil_xbt)
- [5.9K](https://x.com/neil_xbt/status/2056004969430450276/analytics)
- [@anthropic](https://x.com/@anthropic)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:32 PM · May 17, 2026](https://x.com/neil_xbt/status/2056004969430450276)
- [5,911 Views](https://x.com/neil_xbt/status/2056004969430450276/analytics)
- [View quotes](https://x.com/neil_xbt/status/2056004969430450276/quotes)
---
*导出时间: 2026/5/18 14:31:31*
---
## 中文翻译
# 如何构建一支完整的代理团队以改善工作流程（完整教程）
**作者**: NeilXbt
**日期**: 2026-05-17T13:32:38.000Z
**来源**: [https://x.com/neil_xbt/status/2056004969430450276](https://x.com/neil_xbt/status/2056004969430450276)
---
在你的内容运营中，存在这样一个版本：你无需手动进行写作、研究、编辑或发布。
一个研究代理可以在你给出的任何主题上找到非显而易见的切入点。一个生产代理可以将该研究转化为一篇初稿，听起来就像你在最佳状态下写出来的一样。一个质量代理会拒绝任何低于你设定标准的内容，并准确地告诉生产代理需要修复什么。一个分发代理会获取批准的输出，并为你使用的每个平台正确地格式化它。
你只需构建一次这个系统。然后给它一个主题，就可以放手不管了。
这并非假设。这是一种特定的架构，任何使用 Claude 的人都可以在一个周末内构建完成，不需要计算机科学学位，不需要 DevOps 经验，除了系统所需的配置文件外，也不需要编写任何一行代码。
其背后的原理与每一个高绩效团队背后的原理相同。专注于单一任务的专家始终胜过同时处理多件事的通才。当你让同一个 Claude 会话在同一段对话中进行研究、写作、审查和发布时，你会遇到上下文切换、质量标准冲突以及每个阶段都表现平庸的输出。当你构建四个具有明确角色和清晰交接流程的代理时，你会得到在每个阶段都表现优异的输出，因为每个代理只做一件事。
以下是完整的架构及其构建方法。
## 为什么是四个代理，以及为什么采用这种结构
“四”这个数字并非随意决定的。它直接对应于每一项知识工作都会经历的四个阶段，无论你是否曾经命名过它们。
第一个阶段是输入与研究。原始信息被收集、综合，并塑造成一个结构化的基础，后续的所有工作都将建立在此基础之上。第二个阶段是生产。研究基础被转化为完成的初稿。第三个阶段是质量控制。根据定义的标准对草稿进行评估，要么批准通过，要么连同具体的修订说明一起退回。第四个阶段是输出与分发。批准的内容针对每个目标平台进行正确格式化并部署。
每一项复杂的知识工作都会经历这四个阶段。一个在所有四个阶段之间进行上下文切换的单个代理是缓慢的、不一致的，并且在出现问题时难以调试。四个专门的代理产生的工作是一致的，因为每个代理只有一项工作；是快速的，因为代理可以在工作流允许的地方同时运行它们的阶段；并且易于调试，因为故障被隔离在发生故障的代理处。
还有一个关于并行性的论点值得明确指出。一个代理按顺序运行四个阶段所需的时间，是四个代理并行运行其阶段所需时间的四倍。对于任何产出持续内容的人来说，这种时间差异会迅速累积。
## 在构建任何东西之前：使其奏效的基础
在构建单个代理之前，需要做好三件事。
首先，安装并配置 Claude Code。如果你还没有，请使用 `npm install -g @anthropic-ai/claude-code` 安装它，并通过标准流程进行身份验证。
其次，建立一个包含你的代理将使用的文件夹结构的项目目录。创建该目录并在其中构建这些文件夹：inbox（收件箱）、research-briefs（研究简报）、drafts（草稿）、approved-content（批准内容）、distribution（分发）和 logs（日志）。收件箱是任务进入系统的入口。每个后续文件夹接收工作流中前一个代理的输出。日志在一个地方记录每个代理的操作，这就是系统在出现问题时可调试的原因。
第三，在项目根目录下有一个主 CLAUDE.md 文件。该文件是每个代理在采取任何行动之前读取的共享上下文。它定义了系统，建立了共享标准，命名了代理及其角色，并设定了管理每次交互的硬性规则。
你的 CLAUDE.md 应包含六个部分。系统概述：用两三句话描述系统的作用。代理名册：命名每个代理及其具体角色。文件夹结构：用一行文字描述每个文件夹中应包含的内容。共享标准：涵盖命名约定、日志要求以及每个代理的最低质量阈值。质量门槛：生产必须达到的标准，质量代理才会批准。硬性规则：绝不删除文件（改为归档到带时间戳的备份中）；没有记录在文件头中的质量批准绝不发布；在采取任何行动之前记录每个操作；当不确定时停止并标记以供人工审查，而不是猜测。
最后一条硬性规则是最重要的。一个停止并标记不确定性的代理只会产生一个问题。一个朝错误方向错误猜测的代理会产生另一类问题，其解决成本要高得多。
## 代理 1：研究代理
研究代理是你系统中最重要的代理，因为其后续每个代理的质量完全取决于它的产出。
一份薄弱的研究简报只能产生一份薄弱的草稿。一份强有力的研究简报则能产生一份强有力的草稿。生产代理无法添加研究代理没有发现的洞察。你整个系统的输出质量上限就是在这里设定的。
研究代理的工作范围狭窄且具体。给定一个主题或来自收件箱文件夹的简报，它会生成一份结构化的研究文档，其中精确包含以下组成部分：核心洞察（一句话，大多数人都会忽略的非显而易见的切入点）；具体描述的目标受众；至少三个支持性证据及其来源；能产生真正兴趣的反直觉切入点；两三个具体的数据点或引语；三个排名的内容角度，并附有一句话的描述。
研究简报的质量标准有一个不可协商的标准。如果核心洞察是大多数人已经知道的事情，那就是失败的。研究代理必须产生真正非显而易见的洞察，或者被指示进一步搜索。通用的研究产生通用的内容。你的内容运营的质量与这个标准直接成正比。
研究代理的系统提示词以日志说明结束：在完成任务之前，在 logs/operations.md 中附加一个带时间戳的条目，记录研究了什么以及简报保存在哪里。每个代理在完成任务之前记录，而不是之后。日志是使系统可审计的纸质痕迹。
## 代理 2：生产代理
生产代理将研究简报转化为完成的内容。它阅读简报，选择最强的角度，并撰写一篇完整的草稿，与你的语音配置文件相匹配，并达到 CLAUDE.md 中定义的质量标准。
整个系统中最重要的配置决策是你为生产代理提供的语音配置文件。这决定了输出听起来像你，还是像一个通用的 AI 助手。通用的 AI 内容之所以失败，是因为它听起来很通用。一个精确校准的语音配置文件会产生听起来就像你在最佳状态下写出来的内容。
在编写生产代理的系统提示词之前，花三十分钟进行这项准备练习。选取你十篇表现最好的内容，让 Claude 分析它们并提取：你的平均句子长度；你的大写模式以及你策略性大写的内容；你的开场、展开和结尾的结构模式；你的词汇水平和具体的用词选择；你绝不做的事情（你一贯避免的模糊限定词和填充短语）；你如何处理观点之间的过渡；以及你的行动号召（CTA）风格。
保存该分析。它将成为生产代理系统提示词中的语音配置文件部分。代理不会猜测你的风格。它基于一个记录在案、经过分析且基于示例的配置文件工作，该配置文件反映了你实际的最佳工作。
生产代理的输出在每个草稿文件的顶部包含一个元数据头，记录了它使用的研究简报、它选择的内容角度及原因、字数和生产日期。这个头允许质量代理追溯决策，并允许协调器跟踪工作流。
## 代理 3：质量代理
质量代理是生产与发布之间的关卡。大多数多代理系统跳过这一步，然后纳闷为什么他们的输出不一致。
如果没有质量关卡，每一个退出生产代理的内容都会直接进入分发环节，无论质量如何。状态好的时候产生好的内容。状态不好的时候产生坏的内容。没有下限。
有了质量关卡，任何低于定义标准的内容都不会被发布。下限是一致的，因为评估是一致的。
质量代理根据五个标准评估每一份草稿，每个标准的评分从一到十。语音匹配：这听起来完全符合配置的语音配置文件吗？钩子强度：第一句话能让人停止滑动屏幕吗？信息密度：每一句话都赢得它的位置了吗？行动号召清晰度：CTA 是否具体且引人注目？格式合规性：该作品是否遵循了所有格式要求？
通过的标准是所有五个标准都必须达到八分或以上。不是平均八分。而是每个标准 individually 达到八分。一篇在四个标准上得十分而在一个标准上得六分的作品就是不合格的，会被退回并附上具体的修订说明。
这里关键的设计原则在于“具体”这个词。质量代理绝不能给出模糊的反馈。不能是“让它更吸引人”。不能是“钩子需要改进”。修订简报必须指明失败的具体标准，描述该标准中的确切问题，指定所需的确切更改，并理想情况下展示一个简短的正确方法示例。模糊的反馈产生模糊的修订。生产代理只能修复它清楚理解的东西。
当所有五个标准的得分都达到八分或以上时，质量代理会在文件中添加一个批准头，注明日期和每个标准的得分，并将文件移动到 approved-content 文件夹。该批准头授权分发代理采取行动。任何缺乏批准头的内容都不会被分发。这是分发代理无论上下文如何都会执行的硬性规则。
## 代理 4：分发代理
分发代理是链条中的最后一个代理。它的工作听起来很简单，但在手动操作时却始终执行得很差：获取批准的内容，在发布前为每个目标平台正确格式化。
不同的平台确实需要不同的内容。一篇 400 字且具有叙事结构的 LinkedIn 帖子在 X（推特）上会失败，因为那里每条推文 280 个字符的限制，且每条推文都必须独立存在。一个带有标题和清晰结构层级的简报部分，如果不经调整就重新格式化为较短的社交帖子，看起来会很奇怪。一篇跨平台 identical 发布的内容，在所有平台上的表现都不如针对每个平台专门格式化的同一内容。
分发代理通过维护特定于平台的格式指南并根据内容头中列出的目标平台自动将其应用于每份批准的内容来解决此问题。它绝不会在没有特定于平台格式的情况下发布到平台。它会在带时间戳的日志中记录每次部署。并且它在采取任何分发操作之前会验证质量批准头。
## 协调器：连接它们的大脑
协调器不是第五个代理。它是将四个代理连接成一个连贯工作流的路由逻辑。
协调器接收传入的任务，将其路由到研究代理，监控 research-briefs 文件夹中研究简报的出现，将简报传递给生产代理，监控草稿，将草稿传递给质量代理，处理批准路径或修订路由路径，并在分发代理记录成功部署后确认完成。
两种失败场景需要在协调器的设计中进行特定处理。
质量否决会连同修订简报一起路由回生产代理。这是一条预期的路径，而不是失败状态。系统预计有些草稿需要修订，并将它们干净地路由回去。
分发失败会记录失败并提醒进行人工审查。它不会自动重试。分发失败通常有特定于上下文的原因，需要人工判断，而在没有该判断的情况下重试分发失败的代理可能会导致重复发布或复合错误。
协调器不做任何创意决策。它只进行路由和管理。这种约束正是使系统具有可预测性的原因。
## 运行你的第一个端到端任务
配置好所有四个代理后，在收件箱文件夹中创建一个任务文件。它应包含主题或内容类型、分发的目标平台、针对此作品的任何具体要求以及截止日期。
使用以下命令触发协调器：`claude "Read CLAUDE.md. You are the Orchestrator. A new task has arrived in inbox/[TASK-FILENAME]. Begin the workflow. Route to Research Agent first."`
然后观察输出文件夹。链中的每个文件夹在前一个代理完成其工作时都会收到一个文件。logs/operations.md 文件在每一步都会收到一个条目。第一次端到端运行将需要十五到三十分钟，具体取决于主题的复杂性和研究的深度。
运行十次后，工作流变得可预测，每个组件的质量也很清晰。运行五十次后，系统已经积累了足够的运营历史，从而揭示其自身的改进机会：哪些代理产生的薄弱输出需要调整质量配置，哪些平台格式有效，哪些需要调整，哪些主题研究代理觉得容易，而哪些地方它始终遇到局限性。
## 复利机制
一个配置良好的 4 代理系统不仅比单个代理产生更好的输出。它产生的输出会随着时间的推移而改进。
在运行一周后，花十分钟回顾哪些有效，哪些无效。用性能观察结果更新 CLAUDE.md。使用质量代理给予高分的草稿中的示例，改进生产代理中的语音配置文件。收紧质量代理的评分标准，针对那些事后看来不应该通过的情况。当部署表现不佳时，向分发代理添加特定于平台的格式化经验教训。
系统会学习你喂给它的东西。每周你都会喂给它关于在你的特定运营中什么是好的内容的更好信息。每周的输出都会反映这些信息。
一个人运行一个 4 代理团队，通过每周进行一致的校准，能产生一个四人团队的产出，具有更高的一致性、更快的周转速度，以及大多数人肉内容团队都没有建立到其运营中的反馈循环。
第一个代理是最难构建的，因为在某样东西端到端运行之前，整个系统感觉很抽象。在第一个完整的工作流之后，模式就很清晰了。在第二个代理之后，架构就变得合理了。在第三个和第四个之后，系统感觉不再像是一堆配置文件的集合，而更像是一个每天出现并执行你训练它去做的事情的团队。
就在这个周末构建研究代理。让它在一个真实的主题上运行。阅读它产出的内容。
那单一的输出会比这篇文章中的任何内容都更能告诉你这个系统可以成为什么样子。