尧图网站建设 
Swarms AutoAgentBuilder 实战指南让模型替你设计多智能体编队【免费下载链接】swarmsThe Enterprise-Grade Multi-Agent Orchestration Framework. Website: https://swarms.ai项目地址: https://gitcode.com/GitHub_Trending/swar/swarmsAutoAgentBuilder 是 swarms 项目中的编队设计器你只需给出一句任务描述一个受限的 builder 智能体会通过强制函数调用返回一支由name / description / system_prompt / model_name四个字段构成的智能体编队替你省去逐个手写 Agent 配置的繁琐工作。读完本文你将掌握 AutoAgentBuilder 的完整配置项max_agents与num_agents的区别、两种输出形态Agent 对象与配置字典、如何将其编队接入SequentialWorkflow/ConcurrentWorkflow/SwarmRouter等执行架构以及设计一次、缓存复用的可复现实战方案。为什么需要 AutoAgentBuilder大多数多智能体代码的起点是手写每一个 Agent起一个名字、写一段描述、配一个系统提示词、选一个模型。当任务拆分成多个角色时这些样板代码会迅速膨胀而且角色划分本身也需要设计判断。AutoAgentBuilder把这一步交给了模型。你给它一个任务它返回一份编队roster。它在架构上只做一件事设计团队——不选择多智能体执行架构也不执行任何任务。选择SequentialWorkflow还是ConcurrentWorkflow、让谁先跑谁后跑仍然由你的代码决定因此你始终掌控谁来运行这支编队。从源码看其核心机制是一个只跑单轮的 builder Agent 被强制调用唯一的工具函数build_agents并以列表而非散文的形式作答见 swarms/structs/auto_agent_builder.py 中_builder_agent的实现。因为模型提供商强制校验工具 schema所以返回结果里既没有需要剥离的 markdown 代码围栏也不需要从一段文字里打捞 JSON——输出天然就是结构化的。核心数据契约四个字段每个生成的 Agent 恰好携带四个字段这也是构造一个Agent对象所需的最小集合name, description, system_prompt, model_name这四个字段在源码中由常量REQUIRED_FIELDS定义swarms/structs/auto_agent_builder.py并同时出现在强制工具BUILD_AGENTS_TOOL的 JSON Schema 中作为必填项swarms/structs/auto_agent_builder.pyname简短、带连字符、描述角色如Churn-Analyst。它同时作为 Agent 记忆的键因此不能重复。description一句话说明该 Agent 负责什么、产出什么是编排器路由工作的信号。system_prompt该 Agent 的完整操作指令要求第二人称、任务专属、足以让一个毫无上下文的专家独立开工。model_nameLiteLLM 模型字符串如gpt-5.4、gpt-5.4-mini、claude-sonnet-4-6、groq/llama-3.3-70b-versatile。两种输出形态Agent 对象还是配置字典run()返回哪种形态取决于 builder 配置时的return_dict标志AutoAgentBuilder().run(task) # - [Agent, Agent, ...] AutoAgentBuilder(return_dictTrue).run(task) # - [{...}, {...}, ...]如果你需要固定的一种形态、无论 builder 如何配置可以绕过run()直接调用形状专属的方法这两个方法都会忽略return_dictbuilder.build_agents(task) # 始终返回 Agent 对象 builder.build_configs(task) # 始终返回配置字典对应源码swarms/structs/auto_agent_builder.pybuild_configs调用模型、校验并返回字典列表build_agents在build_configs的基础上用生成的四个字段构造Agent对象run则根据return_dict在两者之间二选一。此外还提供了__call__run的别名和batch_run基于batched_run顺序为多个任务分别生成编队。最简单的只出配置用法见 examples/multi_agent/auto_agent_builder_examples/auto_agent_builder_simple.pyimport json from dotenv import load_dotenv from swarms import AutoAgentBuilder load_dotenv() TASK ( Analyze why a B2B SaaS companys customer churn increased last quarter, and write a short brief for the leadership team. ) builder AutoAgentBuilder( model_namegpt-5.4, max_agents5, return_dictTrue, agent_kwargs{reasoning_effort: None, max_tokens: 45_000}, ) configs builder.run(TASK) print(json.dumps(configs, indent4))这里agent_kwargs会透传给每个生成的 Agent但四个生成字段不可通过它覆盖。运行后你可以直接审视 JSON团队成员是谁、各自用什么模型、提示词写得如何然后决定是否继续。控制编队规模max_agents是上限num_agents是精确值这是最容易被误解的配置值得重点说明参数含义max_agents一个上限而非目标值。builder 被指示优先采用能覆盖任务的最小编队因此通常会返回更少的 Agent。默认值为 5。num_agents一个精确数量。设置后会覆盖max_agents并且会覆盖 builder偏向更少的指导。默认值为None。例如max_agents5对一个能干净拆分成三个角色的任务只会返回三个 Agent——这是 builder 正常工作而不是故障。想要精确五个时使用num_agents5AutoAgentBuilder(num_agents5, return_dictTrue).run(task)源码中的实现细节印证了这一行为swarms/structs/auto_agent_builder.py当num_agents被设置时指令会以hard requirement硬性要求的措辞写进提示词要求不多不少、必要时沿更细的接缝拆分工作、但每个 Agent 都要有真实职责此时上限取num_agents否则指令是至多max_agents个使用能完全覆盖任务的最小编队上限取max_agents模型可能无视限制返回更多代码会对列表做截断到上限并记录 warning如果模型返回的 Agent 数少于num_agents代码会记录一条 warning 而不是默默接受缺口——任务本身不足以拆出这么多角色时Agent 是无法凭空捏造的提示词里明确禁止用没有真实工作的 Agent 凑数。构造时如果max_agents或num_agents小于 1会直接抛出ValueError。exact_agent_count.py把两种配置放在同一个任务上对照运行便于直观看到差别examples/multi_agent/auto_agent_builder_examples/exact_agent_count.pyfrom dotenv import load_dotenv from swarms import AutoAgentBuilder load_dotenv() TASK Evaluate whether a mid-size logistics company is worth acquiring. # 一个上限。builder 自己决定实际需要多少个。 ceiling AutoAgentBuilder(max_agents5, return_dictTrue) # 一个精确值。builder 必须拆分工作来凑到这个数。 exact AutoAgentBuilder(num_agents5, return_dictTrue) for label, builder in [ (max_agents5, ceiling), (num_agents5, exact), ]: configs builder.run(TASK) names , .join(c[name] for c in configs) print(f{label:16} - {len(configs)} agents: {names})选择执行架构编队与编排解耦builder 回答的是团队里都有谁不回答他们怎么跑。这是有意的设计同一支编队在多种架构下都有用武之地。结构适用场景示例SequentialWorkflow每个 Agent 都基于前一个的输出继续工作auto_agent_builder_example.pyConcurrentWorkflowAgent 相互独立、各管一块concurrent_workflow.pySwarmRouter想不重写接线就切换架构swarm_router_handoff.py由于编队本质上就是一个 Agent 列表它也可以直接放进MixtureOfAgents、HierarchicalSwarm、GroupChat或任何接受 Agent 列表的结构里。串联SequentialWorkflow最典型的设计 → 构建 → 运行全流程见 auto_agent_builder_example.pyfrom dotenv import load_dotenv from swarms import Agent, AutoAgentBuilder, SequentialWorkflow load_dotenv() TASK ( Analyze why a B2B SaaS companys customer churn increased last quarter, and write a short brief for the leadership team. ) builder AutoAgentBuilder(model_namegpt-5.4, max_agents3) # 只调用一次 builder。复用结果——再次调用会设计一支全新的编队。 configs builder.build_configs(TASK) print(f\nDesigned {len(configs)} agents:\n) for config in configs: print(f {config[name]} [{config[model_name]}]) print(f {config[description]}\n) # 用这些精确的配置构建 Agent。 agents [ Agent( agent_nameconfig[name], agent_descriptionconfig[description], system_promptconfig[system_prompt], model_nameconfig[model_name], max_loops1, ) for config in configs ] result SequentialWorkflow(agentsagents, max_loops1).run(TASK) print(\n--- Result ---\n) print(result)注意脚本里的关键步骤build_configs只调用一次随后从这些配置逐个构造Agent并交给SequentialWorkflow。这样打印出来的编队与真正运行的编队是同一支。并行ConcurrentWorkflow当 Agent 之间没有依赖关系时没有理由串行执行。concurrent_workflow.py展示了一个风险领域一个 Agent并行评估的用法concurrent_workflow.pyfrom dotenv import load_dotenv from swarms import AutoAgentBuilder, ConcurrentWorkflow load_dotenv() TASK ( Assess the risks of deploying autonomous AI agents in a hospitals clinical workflow. Cover clinical safety, regulatory exposure, and patient privacy. ) # 每个风险领域一个 Agent——互不依赖因此没有理由串行。 agents AutoAgentBuilder( model_namegpt-5.4, num_agents3, agent_kwargs{max_loops: 1}, ).run(TASK) print(fRunning {len(agents)} agents concurrently:) for agent in agents: print(f - {agent.agent_name}) results ConcurrentWorkflow(agentsagents).run(TASK) print(\n--- Results ---\n) print(results)这里直接用num_agents3精确对齐临床安全 / 监管合规 / 患者隐私三个并行维度并通过agent_kwargs{max_loops: 1}让每个生成的 Agent 只跑一轮。换架构不换编队SwarmRouterswarm_router_handoff.py展示了builder 选团队、SwarmRouter选架构的组合swarm_router_handoff.pyfrom dotenv import load_dotenv from swarms import AutoAgentBuilder, SwarmRouter load_dotenv() TASK ( Design a go-to-market strategy for an open-source developer tool moving to a paid cloud offering. ) agents AutoAgentBuilder( model_namegpt-5.4, max_agents4, agent_kwargs{max_loops: 1}, ).run(TASK) print(fBuilder designed {len(agents)} agents:) for agent in agents: print(f - {agent.agent_name}: {agent.agent_description}) router SwarmRouter( namegtm-swarm, agentsagents, # 也可以尝试 ConcurrentWorkflow、MixtureOfAgents、 # HierarchicalSwarm或 auto 让 router 自己决定。 swarm_typeSequentialWorkflow, max_loops1, ) print(\n--- Result ---\n) print(router.run(TASK))只要把swarm_type换成ConcurrentWorkflow、MixtureOfAgents、HierarchicalSwarm或auto就能切换执行架构而编队无需任何改动。每个公开方法一次 LLM 调用非确定性与重用这是另一个容易踩的坑每个公开方法都会触发一次全新的 LLM 调用而 builder 不是确定性的。先调用build_configs()再调用build_agents()会设计出两支不同的编队——所以你打印出来的东西可能并不是你真正运行的东西。正确做法是生成一次、复用结果configs builder.build_configs(task) agents [ Agent( agent_namec[name], agent_descriptionc[description], system_promptc[system_prompt], model_namec[model_name], max_loops1, ) for c in configs ]底层build_agents的内部实现也正是这么做的它只调用一次build_configs再用返回的配置逐一构造 Agent并透传agent_kwargsswarms/structs/auto_agent_builder.py。因此只要走build_configs → 自己构造 Agent这条路就能保证所见即所跑。跨进程可复现设计一次、缓存、复用对于需要跨进程复现的运行可以把配置缓存到磁盘之后从文件重建——这就是 save_and_reuse_roster.py 的完整思路import json from pathlib import Path from dotenv import load_dotenv from swarms import Agent, AutoAgentBuilder load_dotenv() TASK Audit a Python codebase for security vulnerabilities and write up the findings. ROSTER_FILE Path(roster.json) def design_roster() - list[dict]: 调用一次 builder把结果缓存到磁盘。 configs AutoAgentBuilder(num_agents3, return_dictTrue).run(TASK) ROSTER_FILE.write_text(json.dumps(configs, indent2)) print(fDesigned {len(configs)} agents - {ROSTER_FILE}) return configs def load_roster() - list[dict]: 读取缓存的编队。没有模型调用、没有成本、每次都是同一支团队。 configs json.loads(ROSTER_FILE.read_text()) print(fLoaded {len(configs)} agents from {ROSTER_FILE}) return configs configs load_roster() if ROSTER_FILE.exists() else design_roster() # 配置就是普通字典构建前可以编辑—— # 把每个 Agent 固定到同一个模型、收紧系统提示词、删掉你不认同的 Agent。 for config in configs: config[model_name] gpt-5.4-mini agents [ Agent( agent_nameconfig[name], agent_descriptionconfig[description], system_promptconfig[system_prompt], model_nameconfig[model_name], max_loops1, ) for config in configs ] print(\nReady to run:) for agent in agents: print(f {agent.agent_name} [{agent.model_name}])这套模式的收益有两个一是配置是纯字典可以在构建前随意编辑——把全部 Agent 钉到同一模型、修改某条提示词、删掉不合理的角色二是磁盘缓存让每次运行的成本从N 次模型调用降为零且团队结构完全一致。底层实现剖析解析、校验与防御_extract_agentsswarms/structs/auto_agent_builder.py负责把强制工具调用的原始输出解析成标准配置列表值得注意的健壮性设计包括两种 provider 输出形态归一化有的提供商返回普通字典MCP 归一化形态function是键有的返回原始对象如 litellm 的ChatCompletionMessageToolCallfunction是属性。两者都会在此被归一化处理。字段缺失防御四个必填字段任何一个缺失该条配置会被跳过并记录 warning——因为缺失system_prompt会静默回退到默认人格缺失校验能避免隐患。名称去重记忆以agent_name为键重名会相互污染状态因此重复名字会被跳过。容错返回畸形或缺失的输出返回空列表而非抛异常是否致命由调用方决定build_configs在拿到空编队时会抛出ValueError提示检查模型是否支持函数调用或换个方式描述任务。此外builder 的构建过程接入了一致的工程化设施_builder_agent关闭了持久化记忆persistent_memoryFalse、output_typefinal、温度与top_p置为None以保证编队只依赖任务、不泄漏跨次运行的状态实例初始化与build_configs分别被capture_init与trace_run埋点便于接入 OpenTelemetry 遥测swarms/telemetry/otel.py。提示词即设计规范任务如何被拆分builder 的系统提示词swarms/prompts/auto_agent_builder_prompt.py本身就体现了一套可复用的团队设计方法论理解它有助于你写出更高质量的 task拆分接缝seam按阶段研究→分析→综合→评审、按领域技术/财务/法律/监管、按来源每个数据集/文档类型一个 Agent、按视角正方与反方、作者与批评者。接缝选择要贴合任务的自然关节不要随意混用。数量判断只有真正单技能的任务才用 1 个 Agent2–3 个是大多数任务的常见正确形态4–5 个仅在任务横跨清晰可分的领域或阶段时出现超过 5 个几乎必然是过度拆分。合并测试逐对检查 Agent如果一个称职专家能同时做好这两件事就合并——职责重叠超过约三分之一、一个只是给另一个的产出做排版、或无法一句话说清各自独有能力时都应当合并。覆盖测试从任务起点走到终点确认每个环节都有归属者只分析不产出或只产出不校验都是不完整的编队。缺口比冗余更糟。字段写作system_prompt是最重要的字段必须第二人称、若干段、包含身份与专长、职责含边界、方法、产出形式、质量标准且必须任务专属model_name应匹配认知负荷而非角色重要性跨层级混搭模型前沿模型做推理综合、小模型做抽取格式化、高速托管模型做吞吐是刻意为之的合理设计。运行要求与多提供商注意事项AutoAgentBuilder 需要支持函数调用的模型以及对应的提供商密钥export OPENAI_API_KEYsk-...两点前提与限制需要留意生成出来的 Agent 可能使用与 builder 不同的提供商——builder 会按每个 Agent 的实际工作负载分别选模型并且刻意混搭模型层级。如果某个 Agent 引用了你没有密钥的提供商要么设置对应密钥要么在构造前直接编辑model_name。任务描述不能为空空任务会抛出ValueError模型不支持函数调用、或任务无法拆出可用角色时build_configs会抛出ValueError并给出排查提示。小结AutoAgentBuilder 的价值在于把设计团队这件需要判断力、又充满样板的事交给模型同时通过强制工具调用保证了输出的结构化与四个字段的数据契约。要发挥它的威力记住四条铁律max_agents是上限、num_agents才是精确值return_dict决定run()的输出形态而build_configs/build_agents固定返回字典或 Agent每个公开方法都是独立的 LLM 调用务必生成一次、复用结果配置是普通字典先缓存到磁盘、编辑后再构建即可获得跨进程可复现且完全可控的编队。想直接上手从 auto_agent_builder_simple.py 开始沿 auto_agent_builder_example.py → exact_agent_count.py → concurrent_workflow.py → swarm_router_handoff.py → save_and_reuse_roster.py 的顺序逐个运行每个示例都在前一个之上只增加一个概念。【免费下载链接】swarmsThe Enterprise-Grade Multi-Agent Orchestration Framework. Website: https://swarms.ai项目地址: https://gitcode.com/GitHub_Trending/swar/swarms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Swarms AutoAgentBuilder 实战指南：让模型替你设计多智能体编队
Swarms AutoAgentBuilder 实战指南让模型替你设计多智能体编队【免费下载链接】swarmsThe Enterprise-Grade Multi-Agent Orchestration Framework. Website: https://swarms.ai项目地址: https://gitcode.com/GitHub_Trending/swar/swarmsAutoAgentBuilder 是 swarms 项目中的编队设计器你只需给出一句任务描述一个受限的 builder 智能体会通过强制函数调用返回一支由name / description / system_prompt / model_name四个字段构成的智能体编队替你省去逐个手写 Agent 配置的繁琐工作。读完本文你将掌握 AutoAgentBuilder 的完整配置项max_agents与num_agents的区别、两种输出形态Agent 对象与配置字典、如何将其编队接入SequentialWorkflow/ConcurrentWorkflow/SwarmRouter等执行架构以及设计一次、缓存复用的可复现实战方案。为什么需要 AutoAgentBuilder大多数多智能体代码的起点是手写每一个 Agent起一个名字、写一段描述、配一个系统提示词、选一个模型。当任务拆分成多个角色时这些样板代码会迅速膨胀而且角色划分本身也需要设计判断。AutoAgentBuilder把这一步交给了模型。你给它一个任务它返回一份编队roster。它在架构上只做一件事设计团队——不选择多智能体执行架构也不执行任何任务。选择SequentialWorkflow还是ConcurrentWorkflow、让谁先跑谁后跑仍然由你的代码决定因此你始终掌控谁来运行这支编队。从源码看其核心机制是一个只跑单轮的 builder Agent 被强制调用唯一的工具函数build_agents并以列表而非散文的形式作答见 swarms/structs/auto_agent_builder.py 中_builder_agent的实现。因为模型提供商强制校验工具 schema所以返回结果里既没有需要剥离的 markdown 代码围栏也不需要从一段文字里打捞 JSON——输出天然就是结构化的。核心数据契约四个字段每个生成的 Agent 恰好携带四个字段这也是构造一个Agent对象所需的最小集合name, description, system_prompt, model_name这四个字段在源码中由常量REQUIRED_FIELDS定义swarms/structs/auto_agent_builder.py并同时出现在强制工具BUILD_AGENTS_TOOL的 JSON Schema 中作为必填项swarms/structs/auto_agent_builder.pyname简短、带连字符、描述角色如Churn-Analyst。它同时作为 Agent 记忆的键因此不能重复。description一句话说明该 Agent 负责什么、产出什么是编排器路由工作的信号。system_prompt该 Agent 的完整操作指令要求第二人称、任务专属、足以让一个毫无上下文的专家独立开工。model_nameLiteLLM 模型字符串如gpt-5.4、gpt-5.4-mini、claude-sonnet-4-6、groq/llama-3.3-70b-versatile。两种输出形态Agent 对象还是配置字典run()返回哪种形态取决于 builder 配置时的return_dict标志AutoAgentBuilder().run(task) # - [Agent, Agent, ...] AutoAgentBuilder(return_dictTrue).run(task) # - [{...}, {...}, ...]如果你需要固定的一种形态、无论 builder 如何配置可以绕过run()直接调用形状专属的方法这两个方法都会忽略return_dictbuilder.build_agents(task) # 始终返回 Agent 对象 builder.build_configs(task) # 始终返回配置字典对应源码swarms/structs/auto_agent_builder.pybuild_configs调用模型、校验并返回字典列表build_agents在build_configs的基础上用生成的四个字段构造Agent对象run则根据return_dict在两者之间二选一。此外还提供了__call__run的别名和batch_run基于batched_run顺序为多个任务分别生成编队。最简单的只出配置用法见 examples/multi_agent/auto_agent_builder_examples/auto_agent_builder_simple.pyimport json from dotenv import load_dotenv from swarms import AutoAgentBuilder load_dotenv() TASK ( Analyze why a B2B SaaS companys customer churn increased last quarter, and write a short brief for the leadership team. ) builder AutoAgentBuilder( model_namegpt-5.4, max_agents5, return_dictTrue, agent_kwargs{reasoning_effort: None, max_tokens: 45_000}, ) configs builder.run(TASK) print(json.dumps(configs, indent4))这里agent_kwargs会透传给每个生成的 Agent但四个生成字段不可通过它覆盖。运行后你可以直接审视 JSON团队成员是谁、各自用什么模型、提示词写得如何然后决定是否继续。控制编队规模max_agents是上限num_agents是精确值这是最容易被误解的配置值得重点说明参数含义max_agents一个上限而非目标值。builder 被指示优先采用能覆盖任务的最小编队因此通常会返回更少的 Agent。默认值为 5。num_agents一个精确数量。设置后会覆盖max_agents并且会覆盖 builder偏向更少的指导。默认值为None。例如max_agents5对一个能干净拆分成三个角色的任务只会返回三个 Agent——这是 builder 正常工作而不是故障。想要精确五个时使用num_agents5AutoAgentBuilder(num_agents5, return_dictTrue).run(task)源码中的实现细节印证了这一行为swarms/structs/auto_agent_builder.py当num_agents被设置时指令会以hard requirement硬性要求的措辞写进提示词要求不多不少、必要时沿更细的接缝拆分工作、但每个 Agent 都要有真实职责此时上限取num_agents否则指令是至多max_agents个使用能完全覆盖任务的最小编队上限取max_agents模型可能无视限制返回更多代码会对列表做截断到上限并记录 warning如果模型返回的 Agent 数少于num_agents代码会记录一条 warning 而不是默默接受缺口——任务本身不足以拆出这么多角色时Agent 是无法凭空捏造的提示词里明确禁止用没有真实工作的 Agent 凑数。构造时如果max_agents或num_agents小于 1会直接抛出ValueError。exact_agent_count.py把两种配置放在同一个任务上对照运行便于直观看到差别examples/multi_agent/auto_agent_builder_examples/exact_agent_count.pyfrom dotenv import load_dotenv from swarms import AutoAgentBuilder load_dotenv() TASK Evaluate whether a mid-size logistics company is worth acquiring. # 一个上限。builder 自己决定实际需要多少个。 ceiling AutoAgentBuilder(max_agents5, return_dictTrue) # 一个精确值。builder 必须拆分工作来凑到这个数。 exact AutoAgentBuilder(num_agents5, return_dictTrue) for label, builder in [ (max_agents5, ceiling), (num_agents5, exact), ]: configs builder.run(TASK) names , .join(c[name] for c in configs) print(f{label:16} - {len(configs)} agents: {names})选择执行架构编队与编排解耦builder 回答的是团队里都有谁不回答他们怎么跑。这是有意的设计同一支编队在多种架构下都有用武之地。结构适用场景示例SequentialWorkflow每个 Agent 都基于前一个的输出继续工作auto_agent_builder_example.pyConcurrentWorkflowAgent 相互独立、各管一块concurrent_workflow.pySwarmRouter想不重写接线就切换架构swarm_router_handoff.py由于编队本质上就是一个 Agent 列表它也可以直接放进MixtureOfAgents、HierarchicalSwarm、GroupChat或任何接受 Agent 列表的结构里。串联SequentialWorkflow最典型的设计 → 构建 → 运行全流程见 auto_agent_builder_example.pyfrom dotenv import load_dotenv from swarms import Agent, AutoAgentBuilder, SequentialWorkflow load_dotenv() TASK ( Analyze why a B2B SaaS companys customer churn increased last quarter, and write a short brief for the leadership team. ) builder AutoAgentBuilder(model_namegpt-5.4, max_agents3) # 只调用一次 builder。复用结果——再次调用会设计一支全新的编队。 configs builder.build_configs(TASK) print(f\nDesigned {len(configs)} agents:\n) for config in configs: print(f {config[name]} [{config[model_name]}]) print(f {config[description]}\n) # 用这些精确的配置构建 Agent。 agents [ Agent( agent_nameconfig[name], agent_descriptionconfig[description], system_promptconfig[system_prompt], model_nameconfig[model_name], max_loops1, ) for config in configs ] result SequentialWorkflow(agentsagents, max_loops1).run(TASK) print(\n--- Result ---\n) print(result)注意脚本里的关键步骤build_configs只调用一次随后从这些配置逐个构造Agent并交给SequentialWorkflow。这样打印出来的编队与真正运行的编队是同一支。并行ConcurrentWorkflow当 Agent 之间没有依赖关系时没有理由串行执行。concurrent_workflow.py展示了一个风险领域一个 Agent并行评估的用法concurrent_workflow.pyfrom dotenv import load_dotenv from swarms import AutoAgentBuilder, ConcurrentWorkflow load_dotenv() TASK ( Assess the risks of deploying autonomous AI agents in a hospitals clinical workflow. Cover clinical safety, regulatory exposure, and patient privacy. ) # 每个风险领域一个 Agent——互不依赖因此没有理由串行。 agents AutoAgentBuilder( model_namegpt-5.4, num_agents3, agent_kwargs{max_loops: 1}, ).run(TASK) print(fRunning {len(agents)} agents concurrently:) for agent in agents: print(f - {agent.agent_name}) results ConcurrentWorkflow(agentsagents).run(TASK) print(\n--- Results ---\n) print(results)这里直接用num_agents3精确对齐临床安全 / 监管合规 / 患者隐私三个并行维度并通过agent_kwargs{max_loops: 1}让每个生成的 Agent 只跑一轮。换架构不换编队SwarmRouterswarm_router_handoff.py展示了builder 选团队、SwarmRouter选架构的组合swarm_router_handoff.pyfrom dotenv import load_dotenv from swarms import AutoAgentBuilder, SwarmRouter load_dotenv() TASK ( Design a go-to-market strategy for an open-source developer tool moving to a paid cloud offering. ) agents AutoAgentBuilder( model_namegpt-5.4, max_agents4, agent_kwargs{max_loops: 1}, ).run(TASK) print(fBuilder designed {len(agents)} agents:) for agent in agents: print(f - {agent.agent_name}: {agent.agent_description}) router SwarmRouter( namegtm-swarm, agentsagents, # 也可以尝试 ConcurrentWorkflow、MixtureOfAgents、 # HierarchicalSwarm或 auto 让 router 自己决定。 swarm_typeSequentialWorkflow, max_loops1, ) print(\n--- Result ---\n) print(router.run(TASK))只要把swarm_type换成ConcurrentWorkflow、MixtureOfAgents、HierarchicalSwarm或auto就能切换执行架构而编队无需任何改动。每个公开方法一次 LLM 调用非确定性与重用这是另一个容易踩的坑每个公开方法都会触发一次全新的 LLM 调用而 builder 不是确定性的。先调用build_configs()再调用build_agents()会设计出两支不同的编队——所以你打印出来的东西可能并不是你真正运行的东西。正确做法是生成一次、复用结果configs builder.build_configs(task) agents [ Agent( agent_namec[name], agent_descriptionc[description], system_promptc[system_prompt], model_namec[model_name], max_loops1, ) for c in configs ]底层build_agents的内部实现也正是这么做的它只调用一次build_configs再用返回的配置逐一构造 Agent并透传agent_kwargsswarms/structs/auto_agent_builder.py。因此只要走build_configs → 自己构造 Agent这条路就能保证所见即所跑。跨进程可复现设计一次、缓存、复用对于需要跨进程复现的运行可以把配置缓存到磁盘之后从文件重建——这就是 save_and_reuse_roster.py 的完整思路import json from pathlib import Path from dotenv import load_dotenv from swarms import Agent, AutoAgentBuilder load_dotenv() TASK Audit a Python codebase for security vulnerabilities and write up the findings. ROSTER_FILE Path(roster.json) def design_roster() - list[dict]: 调用一次 builder把结果缓存到磁盘。 configs AutoAgentBuilder(num_agents3, return_dictTrue).run(TASK) ROSTER_FILE.write_text(json.dumps(configs, indent2)) print(fDesigned {len(configs)} agents - {ROSTER_FILE}) return configs def load_roster() - list[dict]: 读取缓存的编队。没有模型调用、没有成本、每次都是同一支团队。 configs json.loads(ROSTER_FILE.read_text()) print(fLoaded {len(configs)} agents from {ROSTER_FILE}) return configs configs load_roster() if ROSTER_FILE.exists() else design_roster() # 配置就是普通字典构建前可以编辑—— # 把每个 Agent 固定到同一个模型、收紧系统提示词、删掉你不认同的 Agent。 for config in configs: config[model_name] gpt-5.4-mini agents [ Agent( agent_nameconfig[name], agent_descriptionconfig[description], system_promptconfig[system_prompt], model_nameconfig[model_name], max_loops1, ) for config in configs ] print(\nReady to run:) for agent in agents: print(f {agent.agent_name} [{agent.model_name}])这套模式的收益有两个一是配置是纯字典可以在构建前随意编辑——把全部 Agent 钉到同一模型、修改某条提示词、删掉不合理的角色二是磁盘缓存让每次运行的成本从N 次模型调用降为零且团队结构完全一致。底层实现剖析解析、校验与防御_extract_agentsswarms/structs/auto_agent_builder.py负责把强制工具调用的原始输出解析成标准配置列表值得注意的健壮性设计包括两种 provider 输出形态归一化有的提供商返回普通字典MCP 归一化形态function是键有的返回原始对象如 litellm 的ChatCompletionMessageToolCallfunction是属性。两者都会在此被归一化处理。字段缺失防御四个必填字段任何一个缺失该条配置会被跳过并记录 warning——因为缺失system_prompt会静默回退到默认人格缺失校验能避免隐患。名称去重记忆以agent_name为键重名会相互污染状态因此重复名字会被跳过。容错返回畸形或缺失的输出返回空列表而非抛异常是否致命由调用方决定build_configs在拿到空编队时会抛出ValueError提示检查模型是否支持函数调用或换个方式描述任务。此外builder 的构建过程接入了一致的工程化设施_builder_agent关闭了持久化记忆persistent_memoryFalse、output_typefinal、温度与top_p置为None以保证编队只依赖任务、不泄漏跨次运行的状态实例初始化与build_configs分别被capture_init与trace_run埋点便于接入 OpenTelemetry 遥测swarms/telemetry/otel.py。提示词即设计规范任务如何被拆分builder 的系统提示词swarms/prompts/auto_agent_builder_prompt.py本身就体现了一套可复用的团队设计方法论理解它有助于你写出更高质量的 task拆分接缝seam按阶段研究→分析→综合→评审、按领域技术/财务/法律/监管、按来源每个数据集/文档类型一个 Agent、按视角正方与反方、作者与批评者。接缝选择要贴合任务的自然关节不要随意混用。数量判断只有真正单技能的任务才用 1 个 Agent2–3 个是大多数任务的常见正确形态4–5 个仅在任务横跨清晰可分的领域或阶段时出现超过 5 个几乎必然是过度拆分。合并测试逐对检查 Agent如果一个称职专家能同时做好这两件事就合并——职责重叠超过约三分之一、一个只是给另一个的产出做排版、或无法一句话说清各自独有能力时都应当合并。覆盖测试从任务起点走到终点确认每个环节都有归属者只分析不产出或只产出不校验都是不完整的编队。缺口比冗余更糟。字段写作system_prompt是最重要的字段必须第二人称、若干段、包含身份与专长、职责含边界、方法、产出形式、质量标准且必须任务专属model_name应匹配认知负荷而非角色重要性跨层级混搭模型前沿模型做推理综合、小模型做抽取格式化、高速托管模型做吞吐是刻意为之的合理设计。运行要求与多提供商注意事项AutoAgentBuilder 需要支持函数调用的模型以及对应的提供商密钥export OPENAI_API_KEYsk-...两点前提与限制需要留意生成出来的 Agent 可能使用与 builder 不同的提供商——builder 会按每个 Agent 的实际工作负载分别选模型并且刻意混搭模型层级。如果某个 Agent 引用了你没有密钥的提供商要么设置对应密钥要么在构造前直接编辑model_name。任务描述不能为空空任务会抛出ValueError模型不支持函数调用、或任务无法拆出可用角色时build_configs会抛出ValueError并给出排查提示。小结AutoAgentBuilder 的价值在于把设计团队这件需要判断力、又充满样板的事交给模型同时通过强制工具调用保证了输出的结构化与四个字段的数据契约。要发挥它的威力记住四条铁律max_agents是上限、num_agents才是精确值return_dict决定run()的输出形态而build_configs/build_agents固定返回字典或 Agent每个公开方法都是独立的 LLM 调用务必生成一次、复用结果配置是普通字典先缓存到磁盘、编辑后再构建即可获得跨进程可复现且完全可控的编队。想直接上手从 auto_agent_builder_simple.py 开始沿 auto_agent_builder_example.py → exact_agent_count.py → concurrent_workflow.py → swarm_router_handoff.py → save_and_reuse_roster.py 的顺序逐个运行每个示例都在前一个之上只增加一个概念。【免费下载链接】swarmsThe Enterprise-Grade Multi-Agent Orchestration Framework. Website: https://swarms.ai项目地址: https://gitcode.com/GitHub_Trending/swar/swarms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考