在上一篇什么是多智能体系统？中掌握了"协调多个 AI"这一概念之后，接下来的问题就是实际该如何构建。本文以 2026 年事实上的标准——主管模式（指挥中枢型）为题材，面向初学者讲解5 步实践流程。
在进入复杂的框架话题之前，先说最重要的原则——"先用单一智能体构建，撞到瓶颈后再以最小配置增加"。一开始就用多智能体来组建，大多属于过度设计。代码以不依赖特定框架的伪代码呈现，因此无论你使用 MCP 还是各类 SDK，都能套用。
先小步构建，先测量，再增加
— 从最小配置起步的主管模式
* 本文的步骤与数值引用自各类公开资料、实务指南与研究报告（截至 2026 年 6 月）。代码为展示概念的伪代码，实际 API 请查阅各框架的官方文档。
1. 动手之前：你真的需要多智能体吗
第一道关卡不是技术，而是判断。多智能体很强大，但约 80% 的用途用单一智能体就足够了。如果以下任何一条都不符合，那么先用单一智能体来构建才是正解。
应当转向多智能体的 3 个信号
- 专业性分离：知识无法塞进一个提示词里（横跨调研、法务、代码等领域）
- 并行性：同时推进多项作业明显更快
- 判断分离：把"执行者"与"验证者"分开能提升质量
反过来，对一条直线式的简单流程使用多智能体，正如上一篇所提到的，会让成本膨胀 3-10x，在顺序型任务上反而精度下降（Google 研究报告称相对单一为 -39-70%）。请把"用多个就会更聪明并非如此"作为出发点。
2. 基本形态＝主管模式（2026 的默认选择）
如果拿不准用哪种模式来构建，那么主管模式（指挥中枢型）是唯一选择。Claude Code 的子智能体、LangGraph 的 Supervisor、OpenAI Agents SDK 的交接——主要的实现几乎都收敛到了这一形态。原因很明确。
框架支持最广
主流框架原生支持，参考实现丰富。
失败模式已知
主要失败是"过度委派"，可用迭代次数上限来抑制。
易于审计
"谁做了什么"一目了然，便于调试。
机制很简单。主管（指挥中枢）接收整体任务，将其分解为子任务，委派给专业工作者，再汇总结果。主管无需知道工作者具体怎么干，只需判断"调用哪个工作者、以何种输出格式"。专业知识由工作者那一方掌握。
3. 用 5 步构建
用五个步骤搭建一套最小配置的主管模式。铁律是：最初从2-3 个工作者起步，边测量边按需增加。
STEP 1. 分解任务
把"最终目标"和"所需的专业角色"写在纸上。例如：制作市场调研报告，就是"①收集信息→②分析→③撰写→④事实核查"。分解要事先明确——这里含糊，整体就会崩盘。
STEP 2. 定义工作者（最多 3-5 个）
给每个工作者赋予一个角色、所需的工具、一种输出格式。一开始别贪多，最多 3-5 个。每个工作者相互独立，只持有自己的工具（搜索、代码执行等）。
STEP 3. 设计主管
在主管的提示词中，明确列出"允许调用的工作者名称"（硬上限）。诀窍在于：比起单个工作者，要在主管的设计上花最多时间。这里决定了整体质量。
STEP 4. 确定交接与上下文共享
定义工作者之间传递什么、以何种格式传递。把全部上下文传给所有人会让 token 膨胀，因此只挑选必要的信息来传递。智能体间协同的标准协议就是 A2A。
4. 最小代码示例（伪代码）
主管模式的本质短得出人意料。下面用不依赖框架的伪代码，展示主管选出工作者并循环运行的循环（实际 API 请参阅各 SDK 的官方文档）。
# 定义工作者（专业角色）：一个角色＋专用工具
workers = {
"researcher": Agent(tools=[web_search]),
"writer": Agent(tools=[]),
"factcheck": Agent(tools=[web_search]),
}
# 主管：把可调用的工作者名称设为硬上限
supervisor = Agent(
instructions="Decompose the goal and pick one worker to call next. "
"Return 'DONE' when finished.",
allowed_workers=["researcher", "writer", "factcheck"],
)
# 运行循环（用迭代上限防止过度委派）
state = {"goal": "Write an AI market report", "history": []}
for step in range(MAX_STEPS): # <- 上限是必须的
next_worker = supervisor.decide(state)
if next_worker == "DONE":
break
result = workers[next_worker].run(state)
state["history"].append({next_worker: result}) # 只共享必要的上下文
log_handoff(next_worker, result) # <- 测量每一次交接有三个要点。①每个工作者是一个角色＋专用工具 ②主管能调用的对象有限 ③循环中必须设置迭代上限。在这副骨架上再叠加测量、护栏、评估，就能接近生产级质量。Claude Agent SDK 和 Claude Code 的子智能体，思路也是相同的。
5. 常见陷阱与对策
在多智能体开发中容易栽跟头的地方，基本是固定的。提前做好对策吧。
| 陷阱 | 对策 |
|---|---|
| 过度委派（主管无休止地循环） | 迭代次数上限＋限定可调用的工作者 |
| token 膨胀（成本 3-10x） | 停止共享全部上下文，只传必要部分＋缓存 |
| 不稳定、非确定性的行为 | 收紧工作者数量（3-5 个）＋固定输出格式 |
| 顺序型任务精度下降（-39-70%） | 直线式流程就退回单一智能体 |
| 搞不清在哪里失败的 | 扩展之前先测量每一次交接（可观测性） |
共通的教训是"比起框架，提示词、工具设计与评估框架（eval harness）更能决定成败"。比起华丽的架构，小步构建、测量、只在划算时才增加的纪律，最终才是最快的。
总结
多智能体系统的构建，只要从最小配置的主管模式起步就不可怕。我们来回顾要点。
本文要点
- 🚦 先用单一。 等专业分离／并行／判断分离的信号出现后再增加。
- 🧠 基本形态是主管模式（2026 的默认）。在主管的设计上花最多时间。
- 🔢 5 步：分解→定义工作者(3-5 个)→设计主管→交接→测量。
- ⚠️ 陷阱：过度委派、token 膨胀、不稳定。用上限、按需共享、测量来应对。
- 📏 纪律：比起框架，提示词、工具、评估更能决定成败。
"小步构建，先测量，再增加"。只要守住这条纪律，多智能体就会成为能托付复杂工作的强力搭档。概念梳理见什么是多智能体系统？，单体的构建方法见如何构建 AI 智能体。
FAQ
Q. 应该先从哪种模式开始构建？
A. 主管模式（指挥中枢型）是唯一选择，没有疑问。主流框架都支持它，失败模式已知，参考实现也最丰富。等熟练之后再去探索其他模式。
Q. 工作者从几个开始比较好？
A. 最初 2-3 个，最多也控制在 3-5 个以内。数量越多越不稳定，token 也会膨胀。常规做法是边测量，只在证明确有需要时才增加。
Q. 框架是必须的吗？
A. 并非必须。如本文伪代码所示，仅凭循环和提示词也能搭出最小配置。但如果在生产中需要状态持久化、可观测性与恢复能力，使用配套框架会是一条捷径。
Q. 怎样防止成本爆炸？
A. 有三点见效：①给迭代次数设上限 ②不传全部上下文，只共享必要部分 ③使用提示词缓存。多智能体化后成本可能达到单一的 3-10x，因此从第一天起就必须设上限。
