AI AGENT 开发 · 从入门到实战 · #08

多智能体协作:编排者、工作者与它们的组织学

上篇回顾:上一篇给 Agent 装上了记忆,单个 Agent 已经耳聪目明、越用越懂你。但它依然只有一个脑子、一副上下文、一条时间线。什么时候该从一个 Agent 变成一支团队?本篇讲组织学:什么时候拆、怎么拆、以及为什么多数时候你不该拆。

一、默认答案是「别用」,直到出现三个瓶颈

先泼冷水。Anthropic 的总原则在第 1 篇就引用过:「寻找最简单的可行方案,只在必要时增加复杂度」,而且很多场景「用检索和上下文示例优化单次 LLM 调用通常就足够」[1]。多智能体(multi-agent)是复杂性阶梯的最后一格,不是第一格。

那什么时候才真的需要?Anthropic 在自研多智能体研究系统后总结过它擅长的三类任务 [2]:一是重并行——任务天然可以拆成互不依赖的多路探索;二是信息量超过单一上下文——要读的资料总量塞不进一个窗口;三是工具与数据源过多——全部挂在一个 Agent 身上会互相干扰。LangChain 文档的镜像表述更直白:「如果上下文无限、延迟为零,你可以把所有知识塞进一个 prompt——正因不行,才需要模式来选择性地呈现信息」[4]。三个瓶颈一个都没有,就别拆——这句话能帮你省下最多的钱。

细看会发现,三个瓶颈其实是同一个根源的三种表现:一个上下文装不下。所以拆分最大的红利,表面是「多几个脑」,里子是「上下文隔离」——每个工作者带着干净的最小上下文出发,只回传蒸馏结果。这也划出了一条容易忽略的分界线:第 4 篇说的「子 Agent 隔离」是用完即走的外包——主 Agent 发起一次性任务、收回摘要,全程一个主子;而本章的 multi-agent 是持续协作的团队——有分工、有通信、有共享状态。先试外包,再建团队。判定时别凭感觉,给三个量化自查:这个任务串行跑完要几小时、且没人愿意等吗?要读的资料总量做个粗估,真的超过单个窗口的三分之一吗?工具清单超过 20 个、且明显有几组在「抢戏」吗?三问全「是」,往下读;否则回到上一篇把单 Agent 磨利。

二、组织学:四种模式一张表

真要拆,先认识四种基本组织形态:

模式	一句话机制	适用场景
编排者-工作者(Orchestrator-Workers)	中央 LLM 动态拆解任务、委派给工作者 LLM、综合结果——子任务不预定义,由编排者根据输入现场决定	无法预测所需子任务的复杂任务:多文件改动、多源搜索
评审循环(Evaluator-Optimizer)	一次调用生成,另一次调用循环评估与反馈	有明确评估标准、且「人给出反馈就能证明改进」的任务:翻译、多轮检索分析
流水线(Prompt Chaining)	固定步骤串行,每步一个 LLM 调用	步骤可预测的结构化任务——严格说这是工作流,不是多智能体
控制权移交(Handoff)	移交表现为一次工具调用,新 Agent 接管对话,可看到此前的完整历史	按专业分工接线:客服按业务线转接专家 Agent

前两种是 Anthropic 的官方模式,定义都出自《Building Effective Agents》[1];Handoff 在 OpenAI Agents SDK 里的机制值得看一眼本质:每个「移交」就是一个特殊工具(比如 transfer_to_refund_agent),模型调用它,控制权就换了主人,还可以用过滤器裁剪交接时携带的历史(比如 remove_all_tools)[3]。LangChain 则把多智能体拆成 Subagents、Handoffs 等内建模式,并给出按「可并行度/多跳数/是否直面用户」打分的选型矩阵 [4]——选型工具很成熟了,难的不是选,是判断要不要进这一章。真到了这一章,按这个顺序过决策:步骤可预测 → 流水线,别浪费智能;有明确的评估标准 → 评审循环;需要多视角并行探索 → 编排者-工作者;按用户意图切换专家领域 → Handoff。从上往下第一个满足的,就是你的模式。另外四种模式并不互斥:编排者手下的每个工作者,内部可以是完整的 ReAct 循环(第 3 篇);工作者的产出,可以交给评审循环把关后再汇总——大型系统几乎都是复合体,先认清单细胞,再谈组合。

三、实证:90.2% 的提升,与 15 倍的账单

讲完模式看账本。Anthropic 的内部研究功能就是编排者-工作者:主 Agent(Opus 4)负责规划,「创建并行子智能体从不同角度同时搜索」,子 Agent(Sonnet 4)各自独立探索——在内部研究评测上,多智能体系统比单 Agent Opus 4 高出 90.2%;并行拉起 3-5 个子 Agent、每个再并行调多个工具,把复杂查询的研究时间砍掉至多 90%[2]。

但同一篇文章给出了必须贴在墙上的另一半:智能体通常比聊天多耗约 4 倍 token,多智能体系统比聊天多耗约 15 倍 token;而且 BrowseComp 类评测中,token 用量单独解释了 80% 的性能方差 [2]。15 倍是怎么堆出来的?拆开看并不神秘:每个工作者都自带完整的 system、工具定义与多轮上下文,并行不会让 token 变少——它只是让时间变短。把这两半合起来的诚实结论是:多智能体的本质,是用钱和延迟买「搜索面积」——它不是免费的能力跃迁。经济上要成立,任务价值必须高到付得起这笔 token;结构上要成立,任务必须可并行。反过来,需要所有成员共享同一上下文、或成员间强依赖的领域就不适合——大多数编码任务的可并行度就低于研究任务 [2]。账还可以算得更细:一次深度研究的产出若值一杯咖啡钱,15 倍 token 也只是一美元量级的事;而每轮客服问答的价值以角计,同一套架构就是纯烧钱。先给任务定价,再给架构标价——两个数字一比,答案自然浮出来。所以我的建议始终是:先榨干「单 Agent + 第 4 篇的子 Agent 隔离」,确认仍然撞到第一节那三个瓶颈,再拆真团队。

四、动手:五十行的最小编排器

最小编排器不需要任何框架——它就是「一次拆解 + 一批并行 + 一次汇总」,几十行 Python:

import json
from concurrent.futures import ThreadPoolExecutor
from pathlib import Path
from openai import OpenAI   # pip install openai(>=1.x);需先设置环境变量 OPENAI_API_KEY

client = OpenAI()

def plan(goal: str) -> list:
    """编排者:把目标动态拆成 2-4 个互不依赖、可并行的子任务。"""
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "你是编排者。把目标拆成 2-4 个互不依赖、可并行的子任务,"
                                          "每条注明要查什么;只输出 JSON:{\"tasks\": [\"...\"]}"},
            {"role": "user", "content": goal},
        ],
        response_format={"type": "json_object"})
    return json.loads(resp.choices[0].message.content)["tasks"]

def worker(task: str) -> str:
    """工作者:真实场景里内部是第 3 篇的完整循环;此处为演示骨架,只回传蒸馏要点。"""
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "你是研究员。只处理交给你的子任务,"
                                          "输出不超过 200 字的事实要点,不要展开写作。"},
            {"role": "user", "content": task},
        ])
    return resp.choices[0].message.content

def orchestrate(goal: str) -> str:
    tasks = plan(goal)                              # 拆解:动态,不预定义
    with ThreadPoolExecutor() as pool:             # 并行度在这里,不在「更多轮」里
        results = list(pool.map(worker, tasks))
    digest = "\n".join(f"[{t}]\n{r}" for t, r in zip(tasks, results))
    return client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "基于各工作者要点写最终答复,注明每条来自哪个子任务。"},
            {"role": "user", "content": f"目标:{goal}\n\n{digest}"},
        ]).choices[0].message.content

# 预期输出:无中间打印;最终打印一段综合各子任务要点的对比答复
print(orchestrate("对比 LangGraph 与 OpenAI Agents SDK 在多智能体编排上的差异"))

注意工作者那一行的系统提示:「只回传不超过 200 字的要点」。这是整个模式里最容易被忽略的细节——工作者必须被要求蒸馏,否则每个工作者都往编排者嘴里倒几千字,主上下文瞬间爆炸(第 4 篇的预算,会被团队自己吃光)。通信还有第二条路线:不让结果过「传声筒」,直接落成共享工件:

# 共享工件:工作者结果直接落盘,编排者只传「文件指针」不传全文(tasks/results 取自上文 orchestrate() 内部)
# Anthropic 的实战经验:结果直达工件系统,同时改善保真度与性能(转述)
Path("work").mkdir(exist_ok=True)          # write_text 不建父目录,先补上
for i, (task, result) in enumerate(zip(tasks, results), 1):
    Path(f"work/report_{i}.md").write_text(result, encoding="utf-8")
digest = "\n".join(
    f"[{t}] -> work/report_{i}.md(前 200 字:{r[:200]})"
    for i, (t, r) in enumerate(zip(tasks, results), 1))
# 预期效果:全文落盘在 work/,上下文里只留 200 字摘要加文件指针

消息传递适合短结果,共享工件适合长产出;共同原则是让大内容停在文件里,让上下文里只流摘要和指针。设计任何一条通信线之前,问三个问题:谁发起这条信息(编排者派发,还是工作者回报)?随行带多少上下文(全量历史、裁剪摘要,还是裸任务)?结果落在哪里(对话内存、共享文件,还是外部系统)?三个答案落定,通信协议就有了;两个 Agent 之间如果连这三个答案都说不清,它们不是团队,是两条并行的孤龙。

五、反模式与组织制度

Anthropic 分享过他们真实踩过的坑,每一条都能对号入座 [2]:早期版本会为简单查询一次拉起 50 个子 Agent(subagent)(过度拆分);为不存在的资料无休止扫网(无限循环);三个 subagent 重复调研同一主题、互不知情(职责重叠);还有同步执行的协调瓶颈——主 Agent 无法中途纠偏,整个系统被最慢的那个成员拖住。这些不是新手才会犯的错,是这条路的固有地形。

他们的解法朴素得迷人:把组织制度写进 prompt。Agent 难以自行判断合理的投入度,那就明文给出缩放规则——简单事实检索只配 1 个 agent、3-10 次工具调用;对比类任务 2-4 个 subagent、各 10-15 次调用;只有复杂研究才允许 10 个以上并明确分工 [2]。最好的协作 prompt 不是死命令,而是「定义分工、解题路径与投入预算的框架」。另外记住可靠性会级联:Anthropic 提醒过,传统软件里一个 bug 只破坏一个功能,而智能体系统里微小的改动可能级联成大的行为变化(转述)[2]——团队越大,越需要第 9 篇要讲的评测与护栏。反模式的共同解药其实只有两个字:纪律——拆几个、谁负责、何时停,全部白纸黑字写下来。

给你的落地建议收在一句:第一次拆团队,从「1 个编排者 + 2 个工作者」起步——这是能称得上「协作」的最小配置,组织成本最低,效果边界最清楚;跑通之后再按缩放规则扩。一上来就照抄「50 个 subagent」的规模故事,大概率会把第 5 节的反模式集齐。还有一位成员永远别忘掉:人类也是团队的正式成员。编排者拆出的关键决策点(方案确认、成本授权、外发审批),应该显式路由给人——第 5 篇的确认门控在多智能体场景不是可选项,是编制表上的常设岗位。

---

小结

• 默认答案是别拆;重并行、超上下文、海量工具三个瓶颈同时出现,才进入本章议题;
• 四种组织形态里,Orchestrator-Workers 是主力:动态拆解、并行委派、要求工作者蒸馏回传;
• 账本要诚实:高出 90.2% 的另一面是 15 倍 token;任务价值和可并行度,决定这笔投资是否成立;
• 通信少玩传声筒,大内容落工件;把缩放规则写进 prompt——组织制度比聪明更可靠。

下一篇预告:团队越大,越需要考勤。下一篇《评测与护栏》回答本系列最严肃的问题:怎么证明你的 Agent 靠谱——而不是「感觉靠谱」:评测维度、LLM-as-Judge、三层护栏,以及上线前的最后清单。

参考来源

1. Building Effective Agents, Anthropic, 2024-2025,anthropic.com
2. How we built our multi-agent research system, Anthropic, 2025,anthropic.com
3. Handoffs — OpenAI Agents SDK, OpenAI, 2025,openai.github.io
4. Multi-agent, LangChain, 2025-2026,docs.langchain.com