企业官网建设流程全解析

本文收录于专栏《AI Agent原理与实战》2026版—— 专栏系统覆盖 AI Agent 的记忆、工具、插件与实战，点击订阅可跟踪后续更新。

本课定位：单个 Agent 的天花板到了，进入多体世界。本课讲多 Agent 系统的五种拓扑、四大成败因子（任务划分/上下文传递/结果合并/错误处理）、何时值得上多 Agent。先立组织学，再进下一课的编排实战。

阶段 4｜多智能体系统 ｜ 来源：【微软课程·8】+ Anthropic《How we built our multi-agent research system》《Patterns and problems in multiagent systems》

关键字：多智能体系统、Agent拓扑、链式协作、星型架构、编排模式、去中心化协商、层级组织、多Agent设计

本节目录

• 21.1 什么是多 Agent 系统
• 21.2 组织结构：五种拓扑
• 21.3 四大成败因子
• 21.4 因子 1：任务划分（Task Decomposition）
• 21.5 因子 2：上下文传递（Context Passing）
• 21.6 因子 3：结果合并（Result Aggregation）
• 21.7 因子 4：错误处理（Error Handling）
• 21.8 何时值得上多 Agent
• 21.9 运行环境说明

概念讲解

21.1 什么是多 Agent 系统

多 Agent 系统（Multi-Agent System，MAS）：多个各自独立的 Agent（每个都拥有自己的上下文窗口、工具集和系统提示）通过某种协作结构共同完成一个目标的系统。

与单 Agent 的本质区别不在"数量"，而在三点：

1. 上下文隔离：每个 Agent 有独立的上下文窗口。子 Agent 在自己的窗口里做大量探索，只把压缩后的结论回传主 Agent——Anthropic 把这称为"搜索的本质是压缩"（the essence of search is compression）。这是多 Agent 能处理超出单窗口任务的根本机制。
2. 职责分离（separation of concerns）：每个 Agent 配专属的工具、提示和探索路径。专用的检索 Agent 不会分心去写报告，审查 Agent 不受生成过程的"思路污染"。
3. 并行执行：多个 Agent 同时开工，各查各的，互不阻塞。

微软课程第 8 课（Multi-agent design patterns）给出的适用场景三类：大工作负载（可切分并行，如大规模数据处理）、复杂任务（可分解为专精子任务，如自动驾驶中导航/避障/车际通信各司其职）、多样化专长（不同环节需要不同能力，如医疗中诊断/治疗计划/病患监护分工）（微软·8）。三者共同前提是：任务可分且子任务间依赖少。

微软同课给出的"为什么多 Agent 优于单 Agent"三大优势（微软·8）：专业化（Specialization——单 Agent"什么都能干"意味着面对复杂任务时不知道该干什么，可能做了不擅长的事）、可扩展性（Scalability——加 Agent 比给单个 Agent 加负载更容易扩展系统）、容错性（Fault Tolerance——一个 Agent 失败，其他 Agent 继续运转，保障系统可靠性）。微软用旅行预订做例子：单 Agent 要一个 monolith 拿着全部工具订机票+酒店+租车，多 Agent 则是机票/酒店/租车三个专家——像"夫妻店旅行社 vs 连锁旅行社"的差别（微软·8）。这三大优势与 Anthropic 的"上下文隔离+职责分离+并行执行"三本质互为表里：前者讲组织收益，后者讲技术机理。

反过来的推论同样重要——Anthropic 明确指出两类任务不适合多 Agent：需要所有 Agent共享同一上下文的任务，以及子任务间依赖密集的任务。典型反例就是写代码：改一个函数会影响另一个函数，大多数编码任务的并行度远低于研究类任务（截至检索日，LLM Agent 尚不擅长实时协调与委派）。微软知识检查的判定口径与此一致：高并发的同一简单请求只是扩展性问题，不构成多 Agent 理由；多 Agent 的强信号是"需要不同专长角色、各配独立工具、结果需协调"——单 Agent 的强信号是"一套指令+一套工具即可覆盖、无专家交接"（微软·8）。

21.2 组织结构：五种拓扑

多 Agent 系统的协作结构可以归纳为几种拓扑（图示见下）：

两个高频术语在此澄清：Supervisor偏"调度"——按顺序决定谁发言/谁执行，worker 之间常共享一条对话流；Orchestrator-Worker偏"并行分治"——orchestrator 把任务切成多份，同时派给多个独立 worker，各自返回结果再合并。Anthropic 的 Research 功能就是 Orchestrator-Worker 的生产级实现（第 22 课完整拆解）。

微软第 8 课另外点名三种具体参考模式（微软·8），可与上表拓扑对照：Group chat（群聊）——多 Agent 在共享消息流里交换消息，可走中央服务器路由（集中式）也可直接互发（去中心式），适合团队协作/客服/社交场景；Hand-off（移交）——每个 Agent 代表工作流中的一步，按预定义规则把任务移交给下一个 Agent，适合客服转接、任务管理、流程自动化（这与第 19 课 A2A 的移交语义同源）；Collaborative filtering（协作过滤）——多个不同专长的 Agent 各出一份判断再合成推荐，如选股时行业专家 + 技术分析 + 基本面分析三个 Agent 协作给出更全面建议。三模式分别对应上表的 Pipeline/对等/合并密集型拓扑，是微软给出的落地起手式。

关于去中心化要泼一盆冷水：Anthropic 2026 年 8 月的研究《Patterns and problems in multiagent systems》指出，当前模型擅长把其他 Agent 当工具调用（输入提示、输出回答，边界清晰），但不擅长把彼此当作平等的长期协作者——即没有清晰层级、各自有目标的对等协调。真·对等 swarm 系统仍处婴儿期（原文用词 infancy）。工程上可靠的落点仍然是"有中央协调者的多 Agent"，本课程第 22 课的实战也基于此。

21.3 四大成败因子

先看微软第 8 课的六大构建块（微软·8，Building Blocks of Implementing the Multi-Agent Design Pattern）——它是把"多 Agent 设计"拆成六个必须逐一决策的工程问题的完整清单：

其中可观测性三件套值得在此展开（微软·8）：日志监控——每个 Agent 动作记一条（谁、什么动作、何时、结果如何），供调试与优化；可视化工具——用信息流图直观看到 Agent 间的传递路径，定位瓶颈与低效环节；性能指标——任务完成耗时、单位时间完成任务数、推荐准确率等，量化系统有效性。微软的建议是搭一个 dashboard 展示每个 Agent 的状态、用户偏好约束、Agent 间交互全貌（微软·8）——这套做法在第 22 课 Anthropic 的"全链路 tracing"教训里会以生产级形态再次出现。

微软课程第 8 课与 Anthropic 生产经验都指向同一组决定成败的工程决策。总纲将其归纳为四大因子：

21.4 因子 1：任务划分（Task Decomposition）

把总目标切成"互相独立、尽量穷尽"（MECE）的子任务。微软第 8 课的退款场景给出了任务划分的实用分类法（微软·8）：把 Agent 分成流程专属 Agent（只服务当前流程，如退款流程里的 Customer/Seller/Payment/Resolution/Compliance Agent）与业务通用 Agent（可被多个流程复用，如 Shipping/Feedback/Escalation/Notification/Analytics/Audit/Reporting/Knowledge/Security/Quality Agent）——通用 Agent 是企业资产，退款流程能用，购买流程也能用。这个"专属 vs 通用"的划分直接决定你的 Agent 清单怎么开：先列流程专属的，再沉淀可复用的。Anthropic 的教训则补充了说明质量维度：早期让主 Agent 给子 Agent 下简单指令（如"研究半导体短缺"），结果子 Agent 理解歧义、彼此重复搜索——一个查 2021 汽车芯片危机，另外两个都在查 2025 供应链，分工失败。每份子任务说明必须包含四要素：目标（objective）、输出格式、工具/来源指引、明确的任务边界。

21.5 因子 2：上下文传递（Context Passing）

子 Agent 只知道主 Agent 告诉它的东西。传太少，子 Agent 缺背景做无用功；传太多，token 爆炸且干扰判断（呼应第 13 课上下文工程）。Anthropic 的两个实操模式：

• 计划先行落盘：主 Agent 先把研究计划写入外部记忆（Memory），防止上下文超窗截断后"忘了自己要干什么"；
• 产物落盘 + 轻引用回传：子 Agent 把大块产出（报告、代码、图表）写入文件系统等外部存储，只回传轻量引用给协调者，避免大输出在多级对话历史里反复拷贝——所谓"传话游戏"（game of telephone）问题。

21.6 因子 3：结果合并（Result Aggregation）

并行返回的多份结果如何合成一份高质量答案？矛盾信息怎么裁决？重复内容怎么去重？合并质量直接决定系统输出下限。常见做法：指定一个"综合者"角色（可以是主 Agent 自己，也可以是专职 Agent，如 Anthropic 系统里单独的 CitationAgent 负责引用定位）；给合并者明确的质量标准（事实是否可溯源、来源是否一手）。

21.7 因子 4：错误处理（Error Handling）

多 Agent 系统的错误会复合（compound）：单 Agent 里一步走错影响一步，多 Agent 里一步走错会让整条协作轨迹偏航。学术界对此已有系统研究——MAST（Multi-Agent System Failure Taxonomy，arXiv:2503.13657，NeurIPS 2025）基于 1600+ 条真实失败 trace，把 14 种失败模式归为三大类：

MAST 的核心发现值得记住：多数失败源于系统设计与协调，而非模型能力不足——这意味着改提示、改分工、加验证的收益常常大于换更强的模型。

21.8 何时值得上多 Agent

一个经常被忽略的事实：单 Agent + Skills 可能更优。Anthropic 在 Agent Skills 发布后的经验（2025-2026）指出，给单个 Agent 注入按需加载的技能文件（提示+脚本+资源，参见第 32 课前沿方向），在许多场景能达到与多 Agent 相当的效果，而成本和调试复杂度低得多。判断清单：

微软知识检查口径（微软·8）：多 Agent 的最强信号 = “需要独立专长角色（如反欺诈/支付/合规）、各配独立工具、结果需要协调”；单 Agent 更优的信号 = “一套指令+一套工具即可处理、无专家交接、无独立权限与审计要求”。工具多不等于该多 Agent——"能访问多个工具"本身不构成拆分理由（微软·8）。

案例实战：检索 + 分析 + 审查三分工的多 Agent 系统

• 目标：用纯 Python（无多 Agent 框架，只依赖openai>=1.x兼容 SDK）实现一个三角色多 Agent 系统，覆盖四大因子：规划器（Supervisor）→ 并行 Worker（检索 Agent、分析 Agent）→ 审查 Agent 验收 → 合并输出。重点演示任务划分四要素与错误处理（最大迭代数、结果为空的兜底）。
• 为什么不用框架：第 6 课已建立"先看裸机制再看框架"的原则；本例的 supervisor-loop 结构在第 23 课会与 AutoGen/CrewAI 的对应抽象对照。

21.9 运行环境说明

# 三分工多 Agent demonstrator【已实测——2026-10-01 于 Linux (Ubuntu 22.04, Python 3.10, openai 3.6.0)# 分别以 deepseek-chat / MiniMax-M2 / glm-4.7-flash 三家国产模型端到端跑通; Windows 无平台差异】# 角色划分对应四大因子：划分(PLANNER→WORKER spec 四要素) 传递(BRIEF) 合并(MERGER) 错误(MAX_ROUNDS/空结果兜底)importjson,os,timefromopenaiimportOpenAI# ── 国产模型三选一: 改 PROVIDER 即切换 ─────────────────────────PROVIDER=os.environ.get("PROVIDER","deepseek")CONFIGS={"deepseek":{"base_url":"https://api.deepseek.com","model":"deepseek-chat","env":"DEEPSEEK_API_KEY"},"minimax":{"base_url":"https://api.minimaxi.com/v1","model":"MiniMax-M2","env":"MINIMAX_CN_API_KEY"},"glm":{"base_url":"https://api.z.ai/api/coding/paas/v4","model":"glm-4.7-flash","env":"GLM_API_KEY"},}cfg=CONFIGS[PROVIDER]client=OpenAI(api_key=os.environ.get(cfg["env"],"YOUR_API_KEY"),base_url=cfg["base_url"],default_headers={"Accept-Encoding":"gzip, deflate"})# 绕开 openai SDK+brotli 的解压 bug (MiniMax 实测踩坑)MODEL=cfg["model"]MAX_ROUNDS=3# 失控防控: 审查不通过最多重来 3 轮（因子4）defrobust_json(text:str):"""实测发现: 国产模型常在 JSON 外包 markdown 栅栏或前言, 且 MiniMax-M2 思考模型的 决策文本可能落在 content 之外的思考段 -> 先剥栅栏再捞平衡大括号段"""t=(textor"").strip()ift.startswith("```"):t=t.split("\n",1)[1]if"\n"intelset t=t.rsplit("```",1)[0]s,e=t.find("{"),t.rfind("}")ifs>=0ande>s:try:returnjson.loads(t[s:e+1])exceptjson.JSONDecodeError:passdepth,start=0,-1# 逐段捞第一个可解析的 {...}fori,chinenumerate(t):ifch=="{":depth+=1ifstart<0:start=ielifch=="}":depth-=1ifdepth==0andstart>=0:try:returnjson.loads(t[start:i+1])exceptjson.JSONDecodeError:start=-1raiseValueError("no JSON found")defask(system:str,user:str,retries:int=3)->str:forattemptinrange(retries):# GLM coding 端点高峰 429 限流实测常见, 退避重试try:r=client.chat.completions.create(model=MODEL,temperature=0.2,messages=[{"role":"system","content":system},{"role":"user","content":user}])m=r.choices[0].message content=m.contentor""# MiniMax-M2 等思考模型 content 可能为空ifnotcontent.strip():rc=getattr(m,"reasoning_content",None)or""ifrc:content=rc[-800:]# 思考链末段通常已含决策returncontentexceptExceptionase:ifattempt==retries-1or("429"notinstr(e)and"overloaded"notinstr(e)):raisetime.sleep(5*(attempt+1))PLANNER="你是规划器。把用户问题拆成2个可并行的子任务：一个负责检索事实，一个负责分析论证。\ 每个子任务给出四要素:目标/输出格式/工具指引/边界。只输出 JSON:{\"research\":..., \"analysis\":...}，不要输出其他文字。"WORKER="你是{role}子Agent。任务说明：{brief}\n上下文：{context}\n严格按任务说明的输出格式返回，不超过 300 字。"REVIEWER="你是审查Agent。对照原始问题，检查两份子结果：事实是否彼此一致？是否遗漏关键方面？\ 只输出 JSON:{\"pass\": true或false, \"missing\": \"...\"}，不要输出其他文字。"MERGER="你是综合器。基于两份子结果写最终答案，事实性内容标注来源子任务。"defrun(question:str):# 因子1: 任务划分（含四要素的 brief 由规划器生成）plan=robust_json(ask(PLANNER,question))results,review={},Noneforround_noinrange(1,MAX_ROUNDS+1):# 失控防控：迭代上限# 因子2: 上下文传递（brief + 已有审查反馈）ctx=review["missing"]ifreviewelse"无"results["research"]=ask(WORKER.format(role="检索",brief=plan["research"],context=ctx),question)results["analysis"]=ask(WORKER.format(role="分析",brief=plan["analysis"],context=ctx),question)# 因子4: 错误处理——空结果兜底fork,vinresults.items():ifnotvornotv.strip():results[k]="（该子任务本轮无有效产出，综合时请标注缺口）"review=robust_json(ask(REVIEWER,json.dumps({"question":question,**results},ensure_ascii=False)))print(f"[round{round_no}] review.pass={review.get('pass')}")ifreview.get("pass"):break# 因子3: 结果合并returnask(MERGER,json.dumps({"question":question,**results},ensure_ascii=False))if__name__=="__main__":print(run("2025 年多 Agent 框架的主流协作抽象有哪些？"))

• 实测记录（2026-10-01，Linux/Ubuntu 22.04 + Python 3.10 + openai 3.6.0）：
  • deepseek-chat：规划 JSON 一次解析成功，审查第 1 轮通过，综合输出含"六类协作抽象表+三类归并视角"结构化报告。
  • MiniMax-M2：思考型模型，初版代码两次踩坑——响应体 brotli 压缩触发 openai SDK 解压 bug（用default_headers={"Accept-Encoding":"gzip, deflate"}绕开）、思考文本落在reasoning_content而content为空（降级拼接解决）；修复后第 1 轮通过。
  • glm-4.7-flash：coding 端点高峰期 429 限流两次（退避重试 5s/10s 后通过），第 1 轮通过。
• 步骤：①setx DEEPSEEK_API_KEY "sk-xxx"（Windows）或export（Linux/macOS）→ ②pip install "openai>=1.30"→ ③ 保存为multi_agent_demo.py运行 → ④ 换PROVIDER=minimax/glm观察三家行为差异（MiniMax 会看到思考链输出）。
• 预期输出：终端逐行打印[round N] review.pass=...，最后输出综合答案（三家的实测输出风格各异：DeepSeek 偏结构化表格、MiniMax 带思考痕迹、GLM 偏论证文）。
• 改造练习：给检索 Agent 接真实的 web_search 工具（第 7 课模式）；把两次 worker 调用换成asyncio.gather并行版（第 22 课的 fan-out 结构）。

小结

• 多 Agent 的本质收益 = 上下文隔离 × 职责分离 × 并行执行；前提是任务可分、子任务低依赖。
• 组织拓扑五式：Supervisor / Orchestrator-Worker / Pipeline / Swarm / 层级式；当前工程可靠落点是有中央协调者的结构，对等 swarm 仍是前沿（Anthropic 2026-08 评估）。
• 四大成败因子：任务划分（四要素 brief）、上下文传递（计划落盘+轻引用）、结果合并（专职综合者）、错误处理（MAST 三类 14 式失败图谱）。
• 决策清单先问"该不该上"：共享上下文/强依赖任务、低价值高成本场景，单 Agent + Skills 或 workflow 更优。
• 下一课把 Supervisor 与 Orchestrator-Worker 两种模式做到生产级：参见第 22 课《编排实战：Supervisor 与 Orchestrator-Worker》。框架侧对照见第 23 课《多 Agent 框架横评》。

扩展阅读

🌐 网络提示：github.com 需代理（clone 可走 ghproxy 加速、push 优先 SSH）；anthropic.com 需代理（核心结论已摘进本课正文）；学术站 arxiv.org 境内多可直连（慢），其余评测/规范站需代理；pip 安装建议加清华镜像-i https://pypi.tuna.tsinghua.edu.cn/simple。详见总纲附录《国内网络访问与国产适配指南》。

• 微软课程第 8 课 Multi-agent design patterns（含视频）：https://github.com/microsoft/ai-agents-for-beginners/tree/main/08-multi-agent
• Anthropic《How we built our multi-agent research system》（2025-06-13，本课与第 22 课核心参考）：https://www.anthropic.com/engineering/multi-agent-research-system
• Anthropic《Patterns and problems in multiagent systems》（2026-08-13）：https://www.anthropic.com/research/multiagent-systems
• MAST 失败分类学论文《Why Do Multi-Agent LLM Systems Fail?》（arXiv:2503.13657）：https://arxiv.org/abs/2503.13657
• 《Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks》（arXiv:2609.09233，"单 Agent + Skills 可能更优"的专门实证研究）：https://arxiv.org/abs/2609.09233
• Anthropic Agent Skills 工程博客：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
• Anthropic《Building effective agents》（workflow 五模式，orchestrator-workers 详解）：https://www.anthropic.com/engineering/building-effective-agents

我的专栏