一个代理是有用的。一个代理团队是一种竞争优势。
保存这个 :)
一个单一的 AI 代理可以进行研究、写作、分析或编程。但它无法同时把这些事情都做好。就像一个试图同时处理研究、写作、销售和客户支持的员工,会把所有这些事情都做得很差。
解决方案与人类几个世纪前发现的解决方案相同:专业化。
构建团队而非单一超负荷代理
不是依靠一个超负荷的代理,而是建立一个团队。
- 研究代理:只负责研究。
- 写作代理:只负责写作。
- 分析代理:只负责分析。
- 协调代理:管理团队,分配任务,并组装最终输出。
每个代理都专注。每个代理在其特定工作中都表现卓越。它们协同合作,产出的成果是任何单个代理都无法比拟的。
这被称为多智能体编排(multi-agent orchestration),它是当前正在构建的最强大AI系统背后的架构。客户支持平台、研究系统、内容引擎以及业务自动化流水线,都在其核心使用多智能体团队。
本课程将教你如何设计、构建并部署你自己的系统。
架构:中心与辐射
每一个有效的多智能体系统都遵循相同的基本模式:中心与辐射。
中心(协调智能体)位于系统的核心。它从用户那里接收整体目标。它将目标分解为子任务。它决定哪个专业智能体处理每个子任务。它在各个专家之间传递上下文。它将所有部分组装成最终输出。
辐射(专业智能体)是专注的专家。每一个都有明确的角色,一小套为该角色优化的工具,以及一个将其限制在专业范围内的系统提示。
所有的通信都通过协调者进行。专家们从不直接互相交谈。协调者是唯一的路由、质量控制和组装点。
这种架构有巨大的优势。每个专家都保持专注——减少了由于上下文过载导致的错误。专家可以独立开发和测试。你可以在不重建系统的情况下更换或升级单个专家。协调者提供了单一的可观察点,用于调试和监控。
每个人都违反的关键规则
我无法过分强调这一点,因为这是多智能体系统中最常见的错误。
专门代理不会自动继承协调者的对话历史。
让我更直接地说。当协调者生成一个专门代理时,该专门代理从一个空白的上下文开始。它什么都不知道。它没有阅读过对话历史。它没有看到其他专门代理的产出。它对任何事情都没有任何意识,除了你明确包含在其提示中的内容。
大多数人认为,因为协调者知道一切,专家也必须知道一切。事实并非如此。如果协调者收集了研究数据,并希望写作专家将其转化为一份报告,那么协调者必须在写作专家的提示中包含所有研究数据。如果它只是说“根据我们的研究写报告”,写作专家根本不知道进行了哪些研究。
第二个版本更长。它也是唯一有效的版本。专家所需的每一条上下文都必须被明确包含。没有任何例外。
构建你的第一个多智能体团队:研究与报告系统
让我带你了解如何构建一个完整的多智能体团队。该系统接收一个研究问题,并生成一份全面、撰写良好、经过事实核查的报告。
团队成员:
智能体1:研究专家 - 搜索信息,提取关键事实,并汇总原始研究数据。
代理2:分析专家——获取原始研究数据,识别模式,得出结论,并发现来源之间的矛盾。
代理3:写作专家——获取已分析的数据,并以定义好的格式和语气生成一份经过打磨、结构化的报告。
代理4:审查专家——阅读完成的报告,根据原始研究检查其准确性,识别薄弱论点,并提出改进建议。
代理0:协调员——管理整个工作流程。
协调员的工作流程:
每位专家都有一个专注的系统提示:
研究专家:
分析专家:
作家专家:
审稿专家:
为什么这个团队的产出比单个代理更好:
研究代理专注于深入查找信息——不会因同时撰写报告而分心。分析师完全专注于模式——不需要查找信息或撰写文章。作家完全专注于高质量的文字——不进行研究或分析。审稿人发现作家遗漏的错误,因为审稿是其全部工作。
每个代理都把一件事做好。协调者确保各个部分彼此契合。结果是,其质量始终高于让一个代理做所有事情。
设计你自己的多代理团队
研究和报告团队只是其中一种配置。你可以为任何复杂的工作流程构建多代理团队。
内容团队:
研究员 → 大纲架构师 → 草稿撰写者 → 编辑 → 格式化员
接受一个主题并生成经过润色的、多格式的内容。
客户支持团队:
分类器 → 知识库搜索员 → 回复撰写者 → 质量检查员
处理具有多重验证层的支持工单。
业务分析团队:
数据收集器 → 趋势分析器 → 风险评估器 → 建议撰写者
将原始业务数据转化为可执行的战略建议。
设计原则始终如一:
每个代理都有一个明确的职责。每个代理都有一组专注的工具(最多3到5个)。所有通信都通过协调者进行。上下文在代理之间明确传递——绝不假设。协调者在将输出传递给下一个代理之前,会在每个阶段验证输出。
三种失败模式(及如何防止它们)
1. 目标不明确
一个项目如果没有明确的目标,团队就会失去方向,努力也会显得没有意义。目标模糊不清会导致无法衡量的结果,进而无法做出适当的调整。为了避免这种情况,团队应当:
- 制定清晰、具体、可衡量的目标。
- 确保每个成员都理解这些目标并能够将其分解为日常行动。
- 经常评估进展,并根据需要进行调整。
2. 没有足够的资源
即使目标明确,如果没有足够的资源来支持,项目也无法成功。资源包括时间、资金和人力。当资源不足时,团队可能会感到压抑,无法高效工作。为了避免资源不足:
- 评估项目所需的所有资源。
- 在项目启动前确保所有资源到位。
- 定期检查资源使用情况,确保没有超支或短缺。
3. 沟通失败
有效的沟通是任何项目成功的关键。沟通失败可能导致误解、错误和缺乏协作。为了防止这种情况:
- 确保团队成员之间有开放和透明的沟通渠道。
- 定期举行会议,及时讨论进展和问题。
- 提供明确的反馈,确保每个人都在同一页面上。
通过认识并防止这三种失败模式,你可以增加项目成功的机会,并确保团队朝着共同的目标努力。
失败 1:狭隘的分解。
协调者将“AI 对各行业的影响”仅拆分为软件和医疗保健两个子主题,完全遗漏了金融、教育、制造、媒体和法律等领域。
预防:指示协调者在拆分之前先枚举完整范围。添加一个自检步骤:“审查你的拆分。你是否覆盖了该主题的所有主要方面?如果有任何重要领域缺失,请将其补充进去。”
故障 2:上下文丢失。
研究代理发现的信息从未传递给写作代理,因为协调者没有将其传递下去。
预防:协调者必须在每个后续代理的提示中包含所有先前代理的输出。将显式的上下文传递构建到协调者的工作流程中。
失败 3:通过电话效应导致的质量下降。
每个代理都会微妙地改变或丢失前一个代理输出的细微差别。当信息经过四个代理时,重要细节已经被稀释。
预防:在每个阶段都包含原始源数据——不仅仅是前一个代理的输出。撰写者应同时收到原始研究和分析,而不仅仅是分析。
核心要点
单一代理是有用的。多代理团队是强大的。
架构是直接明了的:一个协调者管理各个专家,每个专家只擅长做好一件事,所有上下文都被显式传递,而协调者组装最终输出。
在本周构建你的第一个团队。从研究和报告配置开始。用一个真实的研究问题对其进行测试。观察其质量与让单一代理完成所有工作相比如何。
一旦你体验到质量的差异,你将永远不会回到单一代理执行复杂任务的工作流程。
人工智能的未来不是一个代理做所有事情,而是由团队代理把所有事情都做好。
关注我 @eng_khairallah1 获取更多关于代理架构指南、编排模式和系统构建的内容。
希望这对你有帮助,Khairallah ❤️
显示英文原文 / Show English Original
One agent is useful. A team of agents is a competitive advantage. Save this :) A single AI agent can research, or write, or analyze, or code. But it cannot do all of these things well simultaneously. Just like a single employee who tries to handle research, writing, sales, and customer support will do all of them poorly. The solution is the same solution humans figured out centuries ago: specialization. Instead of one overloaded agent, you build a team. A research agent that only researches. A writing agent that only writes. An analysis agent that only analyzes. A coordinator agent that manages the team, assigns tasks, and assembles the final output. Each agent is focused. Each agent is excellent at its specific job. Together they produce work that no single agent could match. This is called multi-agent orchestration and it is the architecture behind the most powerful AI systems being built right now. Customer support platforms, research systems, content engines, and business automation pipelines all use multi-agent teams at their core. This course teaches you how to design, build, and deploy your own.
The Architecture: Hub and Spoke Every effective multi-agent system follows the same fundamental pattern: hub and spoke. The hub (coordinator agent) sits at the center. It receives the overall goal from the user. It decomposes the goal into subtasks. It decides which specialist agent handles each subtask. It passes context between specialists. It assembles the final output from all the pieces. The spokes (specialist agents) are focused experts. Each one has a defined role, a small set of tools optimized for that role, and a system prompt that constrains it to its specialty. All communication flows through the coordinator. Specialists never talk to each other directly. The coordinator is the single point of routing, quality control, and assembly. This architecture has massive advantages. Each specialist stays focused - reducing errors from context overload. Specialists can be developed and tested independently. You can swap out or upgrade individual specialists without rebuilding the system. The coordinator provides a single point of observability for debugging and monitoring. The Critical Rule Everyone Violates I cannot emphasize this enough because it is the single most common bug in multi-agent systems.
Specialist agents do NOT automatically inherit the coordinator's conversation history. Let me say that more directly. When the coordinator spawns a specialist, the specialist starts with a blank context. It knows nothing. It has not read the conversation history. It has not seen what other specialists produced. It has zero awareness of anything except what you explicitly include in its prompt. Most people assume that because the coordinator knows everything, the specialist must also know everything. It does not. If the coordinator gathered research data and wants the writing specialist to turn it into a report, the coordinator must include all the research data in the writing specialist's prompt. If it just says "write the report based on our research," the writing specialist has no idea what research was done. The second version is longer. It is also the only version that works. Every piece of context the specialist needs must be explicitly included. No exceptions. Building Your First Multi-Agent Team: The Research and Report System Let me walk you through building a complete multi-agent team. This system takes a research question and produces a comprehensive, well-written, fact-checked report. The team: Agent 1: Research Specialist - searches for information, extracts key facts, and compiles raw research data.
Agent 2: Analyst Specialist - takes raw research data, identifies patterns, draws conclusions, and spots contradictions between sources. Agent 3: Writer Specialist - takes analyzed data and produces a polished, structured report in a defined format and voice. Agent 4: Reviewer Specialist - reads the finished report, checks for accuracy against the raw research, identifies weak claims, and suggests improvements. Agent 0: Coordinator - manages the entire workflow. The coordinator's workflow: Each specialist has a focused system prompt: Research Specialist: Analyst Specialist:
Writer Specialist: Reviewer Specialist: Why this team produces better output than a single agent: The research agent goes deep on finding information - it is not distracted by having to write a report at the same time. The analyst focuses purely on patterns - not on finding information or writing prose. The writer focuses purely on quality prose - not on doing research or analysis. The reviewer catches mistakes that the writer missed because reviewing is its entire job. Each agent does one thing well. The coordinator ensures the pieces fit together. The result is consistently higher quality than asking one agent to do everything. Designing Your Own Multi-Agent Teams The research and report team is just one configuration. You can build multi-agent teams for any complex workflow. The Content Team:
Researcher → Outline Architect → Draft Writer → Editor → Formatter Takes a topic and produces polished, multi-format content. The Customer Support Team: Classifier → Knowledge Base Searcher → Response Drafter → Quality Checker Handles support tickets with multiple verification layers. The Business Analysis Team: Data Collector → Trend Analyzer → Risk Assessor → Recommendation Writer Takes raw business data and produces actionable strategic recommendations.
The design principles are always the same: Each agent has ONE clear responsibility. Each agent has a focused set of tools (3 to 5 maximum). All communication flows through the coordinator. Context is passed explicitly between agents - never assumed. The coordinator validates output at each stage before passing to the next agent. The Three Failure Modes (And How to Prevent Them) Failure 1: Narrow decomposition. The coordinator decomposes "impact of AI on industries" into only software and healthcare subtopics, missing finance, education, manufacturing, media, and legal entirely. Prevention: Instruct the coordinator to enumerate the full scope before decomposing. Add a self-check step: "Review your decomposition. Have you covered all major aspects of this topic? If any significant area is missing, add it." Failure 2: Lost context. Information discovered by the research agent never reaches the writing agent because the coordinator did not pass it along.
Prevention: The coordinator must include all prior agent outputs in each subsequent agent's prompt. Build explicit context-passing into the coordinator's workflow. Failure 3: Quality degradation through telephone effect. Each agent subtly changes or loses nuance from the previous agent's output. By the time information passes through four agents, important details have been diluted. Prevention: Include the original source data at every stage - not just the previous agent's output. The writer should receive the raw research AND the analysis, not just the analysis alone. The Bottom Line Single agents are useful. Multi-agent teams are powerful. The architecture is straightforward: a coordinator manages specialists, each specialist does one thing well, all context is passed explicitly, and the coordinator assembles the final output. Build your first team this week. Start with the research and report configuration. Test it with a real research question. Observe how the quality compares to asking a single agent to do everything.
Once you experience the quality difference, you will never go back to single-agent workflows for complex tasks. The future of AI is not one agent doing everything. It is teams of agents doing everything well. Follow me @eng_khairallah1 for more agent architecture guides, orchestration patterns, and building systems. hope this was useful for you, Khairallah ❤️