本文收录于专栏《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 Decomposition21.5 因子 2上下文传递Context Passing21.6 因子 3结果合并Result Aggregation21.7 因子 4错误处理Error Handling21.8 何时值得上多 Agent21.9 运行环境说明概念讲解21.1 什么是多 Agent 系统多 Agent 系统Multi-Agent SystemMAS多个各自独立的 Agent每个都拥有自己的上下文窗口、工具集和系统提示通过某种协作结构共同完成一个目标的系统。与单 Agent 的本质区别不在数量而在三点上下文隔离每个 Agent 有独立的上下文窗口。子 Agent 在自己的窗口里做大量探索只把压缩后的结论回传主 Agent——Anthropic 把这称为搜索的本质是压缩the essence of search is compression。这是多 Agent 能处理超出单窗口任务的根本机制。职责分离separation of concerns每个 Agent 配专属的工具、提示和探索路径。专用的检索 Agent 不会分心去写报告审查 Agent 不受生成过程的思路污染。并行执行多个 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中央 Agent 决定下一个谁干活控制力强、可加审批中央瓶颈、token 集中消耗Orchestrator-Worker主 Agent 规划并并行派出子 Agent并行度最高、上下文隔离彻底结果合并难、子 Agent 失控Pipeline固定顺序传递简单可预测环节间信息衰减传话游戏Swarm/对等Agent 间直接移交handoff无单点、灵活全局视野缺失、易绕圈层级式supervisor 套 supervisor适合超大规模任务层间信息失真叠加两个高频术语在此澄清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 课的六大构建块微软·8Building Blocks of Implementing the Multi-Agent Design Pattern——它是把多 Agent 设计拆成六个必须逐一决策的工程问题的完整清单构建块微软·8要决策什么与四大因子的关系Agent 通信Agent Communication哪些 Agent 之间共享信息、用什么协议与方法共享如订机票 Agent 必须把出行日期传给订酒店 Agent→ 因子 2 上下文传递协调机制Coordination MechanismsAgent 间如何协调动作以满足用户偏好与约束如酒店要靠近机场遇上租车只在机场取→ 因子 1 任务划分 因子 3 合并Agent 架构Agent Architecture每个 Agent 内部如何决策、如何从交互中学习改进→ 第 12 课元认知 / 第 14 课记忆交互可观测Visibility into Interactions用什么工具跟踪 Agent 活动与交互——日志监控、可视化、性能指标三件套→ 本课 21.9 前置 第 26 课可观测多 Agent 模式Multi-Agent Patterns集中式/去中心式/混合架构中选哪种即 21.2 的拓扑选择→ 21.2 五种拓扑人机回路Human in the loop何时请求人工介入如用户指定要某家酒店、下单前要确认→ 第 25 课边界与审核其中可观测性三件套值得在此展开微软·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 里一步走错会让整条协作轨迹偏航。学术界对此已有系统研究——MASTMulti-Agent System Failure TaxonomyarXiv:2503.13657NeurIPS 2025基于 1600 条真实失败 trace把 14 种失败模式归为三大类MAST 大类含义典型模式系统设计问题任务划分/工具配置本身有缺陷子任务重叠或遗漏、工具能力与任务不匹配Agent 间失配inter-agent misalignment传话失真、职责边界不清指令歧义导致重复劳动、信息在 Agent 间衰减任务验证缺位没人检查结果对不对错误无人发现、验证 Agent 形同虚设MAST 的核心发现值得记住多数失败源于系统设计与协调而非模型能力不足——这意味着改提示、改分工、加验证的收益常常大于换更强的模型。21.8 何时值得上多 Agent一个经常被忽略的事实单 Agent Skills 可能更优。Anthropic 在 Agent Skills 发布后的经验2025-2026指出给单个 Agent 注入按需加载的技能文件提示脚本资源参见第 32 课前沿方向在许多场景能达到与多 Agent 相当的效果而成本和调试复杂度低得多。判断清单问题答是意味着子任务能真正并行、彼此少依赖多 Agent 的核心收益成立信息量超出单个上下文窗口需要多窗口分担多 Agent 是刚需各环节需要截然不同的工具/提示职责分离有价值任务价值高到能覆盖 ~15× token 成本经济性成立子任务需要共享同一份实时上下文如协作写同一份代码不建议多 Agent考虑单 Agent Skills只是流程有先后的确定性步骤用 workflow第 9 课不需要 Agent只是同一请求的高并发重复微软·8 知识检查那是扩展性问题加机器/加缓存即可不是多 Agent 理由微软知识检查口径微软·8多 Agent 的最强信号 “需要独立专长角色如反欺诈/支付/合规、各配独立工具、结果需要协调”单 Agent 更优的信号 “一套指令一套工具即可处理、无专家交接、无独立权限与审计要求”。工具多不等于该多 Agent——能访问多个工具本身不构成拆分理由微软·8。案例实战检索 分析 审查三分工的多 Agent 系统目标用纯 Python无多 Agent 框架只依赖openai1.x兼容 SDK实现一个三角色多 Agent 系统覆盖四大因子规划器Supervisor→ 并行 Worker检索 Agent、分析 Agent→ 审查 Agent 验收 → 合并输出。重点演示任务划分四要素与错误处理最大迭代数、结果为空的兜底。为什么不用框架第 6 课已建立先看裸机制再看框架的原则本例的 supervisor-loop 结构在第 23 课会与 AutoGen/CrewAI 的对应抽象对照。21.9 运行环境说明项目要求操作系统Windows 10/11PowerShell 或 CMD/ macOS / Linux 均可纯 HTTP 调用无平台差异Python≥ 3.10依赖pip install openai1.30仅需这一个包模型以下三家国产模型任选均为 OpenAI 兼容端点2026-10-01 实测可通DeepSeekhttps://api.deepseek.com模型deepseek-chat实测版本 DeepSeek-V4.1-Flash1M 上下文MiniMaxhttps://api.minimaxi.com/v1模型MiniMax-M2思考型模型智谱 GLMhttps://api.z.ai/api/coding/paas/v4模型glm-4.7-flashGLM Coding 套餐端点。API key 分别在三家开放平台申请Windows 下用setx DEEPSEEK_API_KEY sk-xxx持久化# 三分工多 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 即切换 ─────────────────────────PROVIDERos.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},}cfgCONFIGS[PROVIDER]clientOpenAI(api_keyos.environ.get(cfg[env],YOUR_API_KEY),base_urlcfg[base_url],default_headers{Accept-Encoding:gzip, deflate})# 绕开 openai SDKbrotli 的解压 bug (MiniMax 实测踩坑)MODELcfg[model]MAX_ROUNDS3# 失控防控: 审查不通过最多重来 3 轮因子4defrobust_json(text:str):实测发现: 国产模型常在 JSON 外包 markdown 栅栏或前言, 且 MiniMax-M2 思考模型的 决策文本可能落在 content 之外的思考段 - 先剥栅栏再捞平衡大括号段t(textor).strip()ift.startswith():tt.split(\n,1)[1]if\nintelset tt.rsplit(,1)[0]s,et.find({),t.rfind(})ifs0andes:try:returnjson.loads(t[s:e1])exceptjson.JSONDecodeError:passdepth,start0,-1# 逐段捞第一个可解析的 {...}fori,chinenumerate(t):ifch{:depth1ifstart0:startielifch}:depth-1ifdepth0andstart0:try:returnjson.loads(t[start:i1])exceptjson.JSONDecodeError:start-1raiseValueError(no JSON found)defask(system:str,user:str,retries:int3)-str:forattemptinrange(retries):# GLM coding 端点高峰 429 限流实测常见, 退避重试try:rclient.chat.completions.create(modelMODEL,temperature0.2,messages[{role:system,content:system},{role:user,content:user}])mr.choices[0].message contentm.contentor# MiniMax-M2 等思考模型 content 可能为空ifnotcontent.strip():rcgetattr(m,reasoning_content,None)orifrc:contentrc[-800:]# 思考链末段通常已含决策returncontentexceptExceptionase:ifattemptretries-1or(429notinstr(e)andoverloadednotinstr(e)):raisetime.sleep(5*(attempt1))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 由规划器生成planrobust_json(ask(PLANNER,question))results,review{},Noneforround_noinrange(1,MAX_ROUNDS1):# 失控防控迭代上限# 因子2: 上下文传递brief 已有审查反馈ctxreview[missing]ifreviewelse无results[research]ask(WORKER.format(role检索,briefplan[research],contextctx),question)results[analysis]ask(WORKER.format(role分析,briefplan[analysis],contextctx),question)# 因子4: 错误处理——空结果兜底fork,vinresults.items():ifnotvornotv.strip():results[k]该子任务本轮无有效产出综合时请标注缺口reviewrobust_json(ask(REVIEWER,json.dumps({question:question,**results},ensure_asciiFalse)))print(f[round{round_no}] review.pass{review.get(pass)})ifreview.get(pass):break# 因子3: 结果合并returnask(MERGER,json.dumps({question:question,**results},ensure_asciiFalse))if__name____main__:print(run(2025 年多 Agent 框架的主流协作抽象有哪些))实测记录2026-10-01Linux/Ubuntu 22.04 Python 3.10 openai 3.6.0deepseek-chat规划 JSON 一次解析成功审查第 1 轮通过综合输出含六类协作抽象表三类归并视角结构化报告。MiniMax-M2思考型模型初版代码两次踩坑——响应体 brotli 压缩触发 openai SDK 解压 bug用default_headers{Accept-Encoding:gzip, deflate}绕开、思考文本落在reasoning_content而content为空降级拼接解决修复后第 1 轮通过。glm-4.7-flashcoding 端点高峰期 429 限流两次退避重试 5s/10s 后通过第 1 轮通过。步骤①setx DEEPSEEK_API_KEY sk-xxxWindows或exportLinux/macOS→ ②pip install openai1.30→ ③ 保存为multi_agent_demo.py运行 → ④ 换PROVIDERminimax/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 优先 SSHanthropic.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-agentAnthropic《How we built our multi-agent research system》2025-06-13本课与第 22 课核心参考https://www.anthropic.com/engineering/multi-agent-research-systemAnthropic《Patterns and problems in multiagent systems》2026-08-13https://www.anthropic.com/research/multiagent-systemsMAST 失败分类学论文《Why Do Multi-Agent LLM Systems Fail?》arXiv:2503.13657https://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.09233Anthropic Agent Skills 工程博客https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skillsAnthropic《Building effective agents》workflow 五模式orchestrator-workers 详解https://www.anthropic.com/engineering/building-effective-agents我的专栏蛋白 / 抗体 / 多肽 / 核酸分子模拟 / 动力学 / 对接药物 / 设计 / 案例AI / Agent / 大模型开源蛋白结构预测分子模拟基础小分子药物设计案例AI Agent系列开源蛋白生成方法实践分子动力学模拟-Amber蛋白药物设计案例化学大模型开源多肽设计模型分子动力学模拟-Gromacs多肽药物设计案例《AI Agent原理与实战》开源多肽性质预测分子动力学模拟-OpenMM开源小分子生成设计CADD中的机器学习模型DNA/RNA药物设计結合自由能高效计算配置《MCP 入门实战》siRNA药物设计模型UCSF DOCK系列我胡师兄说药《AI入门实战2026》ASO药物设计模型rDock系列 LeDock系列 gnina系列《经典机器学习实战》 《AI Agent原理与实战》2026版 第21课 多 Agent 设计模式
本文收录于专栏《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 Decomposition21.5 因子 2上下文传递Context Passing21.6 因子 3结果合并Result Aggregation21.7 因子 4错误处理Error Handling21.8 何时值得上多 Agent21.9 运行环境说明概念讲解21.1 什么是多 Agent 系统多 Agent 系统Multi-Agent SystemMAS多个各自独立的 Agent每个都拥有自己的上下文窗口、工具集和系统提示通过某种协作结构共同完成一个目标的系统。与单 Agent 的本质区别不在数量而在三点上下文隔离每个 Agent 有独立的上下文窗口。子 Agent 在自己的窗口里做大量探索只把压缩后的结论回传主 Agent——Anthropic 把这称为搜索的本质是压缩the essence of search is compression。这是多 Agent 能处理超出单窗口任务的根本机制。职责分离separation of concerns每个 Agent 配专属的工具、提示和探索路径。专用的检索 Agent 不会分心去写报告审查 Agent 不受生成过程的思路污染。并行执行多个 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中央 Agent 决定下一个谁干活控制力强、可加审批中央瓶颈、token 集中消耗Orchestrator-Worker主 Agent 规划并并行派出子 Agent并行度最高、上下文隔离彻底结果合并难、子 Agent 失控Pipeline固定顺序传递简单可预测环节间信息衰减传话游戏Swarm/对等Agent 间直接移交handoff无单点、灵活全局视野缺失、易绕圈层级式supervisor 套 supervisor适合超大规模任务层间信息失真叠加两个高频术语在此澄清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 课的六大构建块微软·8Building Blocks of Implementing the Multi-Agent Design Pattern——它是把多 Agent 设计拆成六个必须逐一决策的工程问题的完整清单构建块微软·8要决策什么与四大因子的关系Agent 通信Agent Communication哪些 Agent 之间共享信息、用什么协议与方法共享如订机票 Agent 必须把出行日期传给订酒店 Agent→ 因子 2 上下文传递协调机制Coordination MechanismsAgent 间如何协调动作以满足用户偏好与约束如酒店要靠近机场遇上租车只在机场取→ 因子 1 任务划分 因子 3 合并Agent 架构Agent Architecture每个 Agent 内部如何决策、如何从交互中学习改进→ 第 12 课元认知 / 第 14 课记忆交互可观测Visibility into Interactions用什么工具跟踪 Agent 活动与交互——日志监控、可视化、性能指标三件套→ 本课 21.9 前置 第 26 课可观测多 Agent 模式Multi-Agent Patterns集中式/去中心式/混合架构中选哪种即 21.2 的拓扑选择→ 21.2 五种拓扑人机回路Human in the loop何时请求人工介入如用户指定要某家酒店、下单前要确认→ 第 25 课边界与审核其中可观测性三件套值得在此展开微软·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 里一步走错会让整条协作轨迹偏航。学术界对此已有系统研究——MASTMulti-Agent System Failure TaxonomyarXiv:2503.13657NeurIPS 2025基于 1600 条真实失败 trace把 14 种失败模式归为三大类MAST 大类含义典型模式系统设计问题任务划分/工具配置本身有缺陷子任务重叠或遗漏、工具能力与任务不匹配Agent 间失配inter-agent misalignment传话失真、职责边界不清指令歧义导致重复劳动、信息在 Agent 间衰减任务验证缺位没人检查结果对不对错误无人发现、验证 Agent 形同虚设MAST 的核心发现值得记住多数失败源于系统设计与协调而非模型能力不足——这意味着改提示、改分工、加验证的收益常常大于换更强的模型。21.8 何时值得上多 Agent一个经常被忽略的事实单 Agent Skills 可能更优。Anthropic 在 Agent Skills 发布后的经验2025-2026指出给单个 Agent 注入按需加载的技能文件提示脚本资源参见第 32 课前沿方向在许多场景能达到与多 Agent 相当的效果而成本和调试复杂度低得多。判断清单问题答是意味着子任务能真正并行、彼此少依赖多 Agent 的核心收益成立信息量超出单个上下文窗口需要多窗口分担多 Agent 是刚需各环节需要截然不同的工具/提示职责分离有价值任务价值高到能覆盖 ~15× token 成本经济性成立子任务需要共享同一份实时上下文如协作写同一份代码不建议多 Agent考虑单 Agent Skills只是流程有先后的确定性步骤用 workflow第 9 课不需要 Agent只是同一请求的高并发重复微软·8 知识检查那是扩展性问题加机器/加缓存即可不是多 Agent 理由微软知识检查口径微软·8多 Agent 的最强信号 “需要独立专长角色如反欺诈/支付/合规、各配独立工具、结果需要协调”单 Agent 更优的信号 “一套指令一套工具即可处理、无专家交接、无独立权限与审计要求”。工具多不等于该多 Agent——能访问多个工具本身不构成拆分理由微软·8。案例实战检索 分析 审查三分工的多 Agent 系统目标用纯 Python无多 Agent 框架只依赖openai1.x兼容 SDK实现一个三角色多 Agent 系统覆盖四大因子规划器Supervisor→ 并行 Worker检索 Agent、分析 Agent→ 审查 Agent 验收 → 合并输出。重点演示任务划分四要素与错误处理最大迭代数、结果为空的兜底。为什么不用框架第 6 课已建立先看裸机制再看框架的原则本例的 supervisor-loop 结构在第 23 课会与 AutoGen/CrewAI 的对应抽象对照。21.9 运行环境说明项目要求操作系统Windows 10/11PowerShell 或 CMD/ macOS / Linux 均可纯 HTTP 调用无平台差异Python≥ 3.10依赖pip install openai1.30仅需这一个包模型以下三家国产模型任选均为 OpenAI 兼容端点2026-10-01 实测可通DeepSeekhttps://api.deepseek.com模型deepseek-chat实测版本 DeepSeek-V4.1-Flash1M 上下文MiniMaxhttps://api.minimaxi.com/v1模型MiniMax-M2思考型模型智谱 GLMhttps://api.z.ai/api/coding/paas/v4模型glm-4.7-flashGLM Coding 套餐端点。API key 分别在三家开放平台申请Windows 下用setx DEEPSEEK_API_KEY sk-xxx持久化# 三分工多 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 即切换 ─────────────────────────PROVIDERos.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},}cfgCONFIGS[PROVIDER]clientOpenAI(api_keyos.environ.get(cfg[env],YOUR_API_KEY),base_urlcfg[base_url],default_headers{Accept-Encoding:gzip, deflate})# 绕开 openai SDKbrotli 的解压 bug (MiniMax 实测踩坑)MODELcfg[model]MAX_ROUNDS3# 失控防控: 审查不通过最多重来 3 轮因子4defrobust_json(text:str):实测发现: 国产模型常在 JSON 外包 markdown 栅栏或前言, 且 MiniMax-M2 思考模型的 决策文本可能落在 content 之外的思考段 - 先剥栅栏再捞平衡大括号段t(textor).strip()ift.startswith():tt.split(\n,1)[1]if\nintelset tt.rsplit(,1)[0]s,et.find({),t.rfind(})ifs0andes:try:returnjson.loads(t[s:e1])exceptjson.JSONDecodeError:passdepth,start0,-1# 逐段捞第一个可解析的 {...}fori,chinenumerate(t):ifch{:depth1ifstart0:startielifch}:depth-1ifdepth0andstart0:try:returnjson.loads(t[start:i1])exceptjson.JSONDecodeError:start-1raiseValueError(no JSON found)defask(system:str,user:str,retries:int3)-str:forattemptinrange(retries):# GLM coding 端点高峰 429 限流实测常见, 退避重试try:rclient.chat.completions.create(modelMODEL,temperature0.2,messages[{role:system,content:system},{role:user,content:user}])mr.choices[0].message contentm.contentor# MiniMax-M2 等思考模型 content 可能为空ifnotcontent.strip():rcgetattr(m,reasoning_content,None)orifrc:contentrc[-800:]# 思考链末段通常已含决策returncontentexceptExceptionase:ifattemptretries-1or(429notinstr(e)andoverloadednotinstr(e)):raisetime.sleep(5*(attempt1))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 由规划器生成planrobust_json(ask(PLANNER,question))results,review{},Noneforround_noinrange(1,MAX_ROUNDS1):# 失控防控迭代上限# 因子2: 上下文传递brief 已有审查反馈ctxreview[missing]ifreviewelse无results[research]ask(WORKER.format(role检索,briefplan[research],contextctx),question)results[analysis]ask(WORKER.format(role分析,briefplan[analysis],contextctx),question)# 因子4: 错误处理——空结果兜底fork,vinresults.items():ifnotvornotv.strip():results[k]该子任务本轮无有效产出综合时请标注缺口reviewrobust_json(ask(REVIEWER,json.dumps({question:question,**results},ensure_asciiFalse)))print(f[round{round_no}] review.pass{review.get(pass)})ifreview.get(pass):break# 因子3: 结果合并returnask(MERGER,json.dumps({question:question,**results},ensure_asciiFalse))if__name____main__:print(run(2025 年多 Agent 框架的主流协作抽象有哪些))实测记录2026-10-01Linux/Ubuntu 22.04 Python 3.10 openai 3.6.0deepseek-chat规划 JSON 一次解析成功审查第 1 轮通过综合输出含六类协作抽象表三类归并视角结构化报告。MiniMax-M2思考型模型初版代码两次踩坑——响应体 brotli 压缩触发 openai SDK 解压 bug用default_headers{Accept-Encoding:gzip, deflate}绕开、思考文本落在reasoning_content而content为空降级拼接解决修复后第 1 轮通过。glm-4.7-flashcoding 端点高峰期 429 限流两次退避重试 5s/10s 后通过第 1 轮通过。步骤①setx DEEPSEEK_API_KEY sk-xxxWindows或exportLinux/macOS→ ②pip install openai1.30→ ③ 保存为multi_agent_demo.py运行 → ④ 换PROVIDERminimax/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 优先 SSHanthropic.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-agentAnthropic《How we built our multi-agent research system》2025-06-13本课与第 22 课核心参考https://www.anthropic.com/engineering/multi-agent-research-systemAnthropic《Patterns and problems in multiagent systems》2026-08-13https://www.anthropic.com/research/multiagent-systemsMAST 失败分类学论文《Why Do Multi-Agent LLM Systems Fail?》arXiv:2503.13657https://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.09233Anthropic Agent Skills 工程博客https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skillsAnthropic《Building effective agents》workflow 五模式orchestrator-workers 详解https://www.anthropic.com/engineering/building-effective-agents我的专栏蛋白 / 抗体 / 多肽 / 核酸分子模拟 / 动力学 / 对接药物 / 设计 / 案例AI / Agent / 大模型开源蛋白结构预测分子模拟基础小分子药物设计案例AI Agent系列开源蛋白生成方法实践分子动力学模拟-Amber蛋白药物设计案例化学大模型开源多肽设计模型分子动力学模拟-Gromacs多肽药物设计案例《AI Agent原理与实战》开源多肽性质预测分子动力学模拟-OpenMM开源小分子生成设计CADD中的机器学习模型DNA/RNA药物设计結合自由能高效计算配置《MCP 入门实战》siRNA药物设计模型UCSF DOCK系列我胡师兄说药《AI入门实战2026》ASO药物设计模型rDock系列 LeDock系列 gnina系列《经典机器学习实战》