数据截至 (上游 commit 375d8081c48c)
Swarms — 深入
本章面向要真正读源码 / 做技术选型的人:提炼可借鉴的设计、诚实列出边界与坑、和兄弟框架对比,并给一张可 grep 的代码地图。
1. 巧妙之处(可借鉴的技术)
① 共享对话即接口。 多智能体间不靠显式的“返回值 → 入参”链传数据,而是共读共写一份 Conversation 黑板。好处:任意拓扑(顺序、并发、总监)都用同一种上下文传递方式,新拓扑几乎零成本复用。见 AgentRearrange._run 里对 self.conversation 的读写(structs/agent_rearrange.py:711、660-670)。
② 强制结构化工具调用来做“控制流”。 凡是需要“机器读懂 Agent 意图”的地方,都用 forced function call 而非解析自然语言:GroupChat 用 RESPOND_TOOL 让 Agent 用 (score, message) 竞价发言(structs/groupchat.py:74-98);HierarchicalSwarm 用 SwarmSpec 让总监吐出结构化 orders(structs/hiearchical_swarm.py:85-111);自主模式用 create_plan/subtask_done 等工具驱动状态机(structs/agent.py:2280-2319)。这把“不可靠的自然语言”转成“可校验的 JSON”,是全框架反复出现的模式。
③ 一切收敛到 Agent.run。 无论多复杂的 Swarm,叶子节点永远是 agent.run(task=...)。这让 Agent 成为唯一需要吃透的执行单元,也让“单智能体”和“多智能体”共用同一套重试/记忆/工具逻辑。
④ 顺序感知用临时 system_prompt 注入、跑完还原。 既让 Agent 知道自己在流程中的位置,又不把这些私有信息污染进共享黑板(try/finally 还原,structs/agent_rearrange.py:630-668)。
⑤ 编排层薄封装。 SequentialWorkflow 不重复造轮子,直接转包给 AgentRearrange(structs/sequential_workflow.py:152、256)——用组合而非继承扩展能力。
2. 边界与局限(诚实清单)
这些是从源码读到的真实约束,不是评判。
Agent是一个巨型类。structs/agent.py超过 6400 行、100+ 方法,构造函数有 80+ 个参数(structs/agent.py:331-419)。功能极全,但认知负担重、行为面广。context_length参数不生效。 构造函数在structs/agent.py:514无条件self.context_length = 16000,覆盖你传入的值。想控制上下文预算的人会被这行“坑”。- 同名 Agent 共享持久记忆。
MEMORY.md仅按agent_name落盘(structs/agent.py:1043-1045),多个 Agent 起同名 → 互相读写同一份记忆,可能污染。多智能体场景要么给唯一名字,要么persistent_memory=False。 - 并发结果顺序 = 完成顺序。
run_agents_concurrently默认用as_completed收集(structs/multi_agent_exec.py:180),返回列表顺序和输入顺序不一致;要对齐得用return_agent_output_dict=True。 - 线程池并发受 API 侧限制。 默认吃满 ~95% CPU 核开线程(
structs/multi_agent_exec.py:142-144),但真正瓶颈通常是模型服务商的速率限制;线程开太多可能撞 429。 - 可变默认参数。
tools_list_dictionary=[]作默认值(structs/agent.py:388)是 Python 经典陷阱写法;阅读/子类化时要小心跨实例共享。 - 命名遗留。 文件名
hiearchical_swarm.py(hierarchical 拼写错)等历史命名保留在源码里,import时按真实文件名来。