1.1 定义、核心理念与发展背景

1.1 定义、核心理念与发展背景

先说一个反例。你让单个大模型"帮我写个爬虫并把数据存进数据库"，它给了一段代码，你跑起来报错，它再改，改三轮后凑合能跑但把字段名写错了，你到第三天才发现数据对不上。问题不在模型笨，而在于"写代码"和"验数据"被塞进同一个脑子，它没法站在旁观者角度挑自己的刺。AutoGen 的核心理念，就是把这两个角色拆开成两个会对话的 Agent，让一个写、一个验，对话本身成了推进任务的引擎。这就是"对话即编排"——我们整本书的主线。

为什么多智能体不是噱头

单智能体面对长链条任务时，控制和状态会缠成一团：你要写循环决定下一步调谁，要写判断决定什么时候停，要自己维护上下文。任务一复杂，这段胶水代码比业务还长。AutoGen 的思路是：把这些"下一步怎么办"的决策，交给 Agent 之间的对话去涌现，而不是你提前写死。代价是可控性下降、调试更难；收益是面对没见过的子任务时，系统能自己商量出解法。

我们做个判断：如果你的任务是一条直线、不需要角色间商量、出错也不致命，单智能体加几行脚本更划算。AutoGen 真正划算的场景是"多角色、有来回、可中断"——代码生成加自审、数据分析加复核、文档起草加校对，都属此类。

发展背景：它从哪来

微软在 2023 年开源 AutoGen，背景是大模型应用从"一问一答"走向"多步协作"。早期大家用提示词把多个角色塞进一个系统提示里，让模型假装自己是团队。这种做法在简单任务上能跑，但角色边界模糊、上下文容易串味。AutoGen 把"角色"做成一等公民：每个 Agent 是独立对象，有独立系统提示、独立模型配置、独立记忆。这个设计让它比"一个提示里分饰多角"稳得多。

# 最小可运行：两个 Agent 互致问候，验证对话回路
from autogen import ConversableAgent

# 两个 Agent 都用同一个模型配置（示例里用占位 key，真实场景换成你的凭据）
llm_cfg = {"model": "gpt-4o-mini", "api_key": "YOUR_KEY"}

alice = ConversableAgent("alice", llm_config=llm_cfg,
                         system_message="你叫 Alice，说话简洁。")
bob = ConversableAgent("bob", llm_config=llm_cfg,
                       system_message="你叫 Bob，说话简洁。")

# Alice 发起对话，把第一句话丢给 Bob
chat = alice.initiate_chat(bob, message="Bob，今天聊聊多智能体？", max_turns=2)
print(chat.summary)
​

上面这段代码跑起来会打印出一段对话摘要，大概是 Alice 开头、Bob 接话、再回到 Alice 的格式。重点不在内容，而在你确认了"消息能从 A 流到 B 再回来"这条回路是通的。后面所有复杂协作，都是在这条回路上加东西。

核心理念落地为三个抽象

把理念翻译成代码，就是三个核心抽象：

• 智能体（Agent）：独立的计算单元，持有自己的系统提示、模型配置和记忆。它是"谁在说"。
• 对话（Conversation）：消息在 Agent 之间的往返，是"怎么推进"。
• 群聊（GroupChat）：多个 Agent 共享同一段对话历史的容器，由管理器决定下一轮谁说，是"怎么协作"。

函数调用是 Agent 伸向外部世界的手，我们放到第三章细讲。这里先建立直觉：你写的不是程序流程，而是一张角色关系网，任务顺着网里的对话流动。

# 用 GroupChat 把三个角色放进同一段对话（本章先认识结构，第四章细讲）
from autogen import GroupChat, GroupChatManager, ConversableAgent

llm_cfg = {"model": "gpt-4o-mini", "api_key": "YOUR_KEY"}
coder = ConversableAgent("coder", llm_config=llm_cfg, system_message="你负责写代码。")
reviewer = ConversableAgent("reviewer", llm_config=llm_cfg, system_message="你负责审代码。")
tester = ConversableAgent("tester", llm_config=llm_cfg, system_message="你负责测代码。")

group = GroupChat(agents=[coder, reviewer, tester], messages=[], max_round=6)
manager = GroupChatManager(group=group, llm_config=llm_cfg)
# manager 会按策略让三个角色轮转发言，直到 max_round 用尽或有人喊停
​

这段你会看到三个角色在同一段历史里轮流出现。注意 GroupChat 本身不决定内容，只决定"谁先说"——内容照样来自每个 Agent 自己的模型。这正是对话即编排的体现：结构你定，内容交给对话涌现。

一个学界视角的对照

把 AutoGen 和更早期的"多 Agent 仿真"放一起看会有启发：那些研究里 Agent 也是独立个体、靠消息交互，但目标往往是观察群体涌现现象，而不是完成一个具体工程任务。AutoGen 把同一套思想落到实用——每个 Agent 是能调模型、能跑函数的工程单元，对话的终点是交付物而不是观察报告。这个转向很关键：它让"多智能体"从论文走进生产线。

# 用一个简单对照看"涌现"：两个 Agent 互审，产出比单 Agent 更稳
from autogen import AssistantAgent
import os
cfg = {"model": "gpt-4o-mini", "api_key": os.environ.get("OPENAI_API_KEY")}
solo = AssistantAgent("solo", llm_config=cfg, system_message="你写并自审代码。")
pair_a = AssistantAgent("a", llm_config=cfg, system_message="你写代码。")
pair_b = AssistantAgent("b", llm_config=cfg, system_message="你只审不写。")
# solo 自己写自己审，容易放自己一马；a/b 分工，挑刺更狠
chat_solo = solo.initiate_chat(solo, message="写个去重函数。", max_turns=2)
chat_pair = pair_a.initiate_chat(pair_b, message="写个去重函数。", max_turns=4)
​

本节要点回顾

• 多智能体解决的是"单智能体控制流缠成一团"的问题，不是模型能力问题。
• 适合多智能体的任务特征：多角色、有来回、可中断。
• AutoGen 用 Agent / Conversation / GroupChat 三个抽象把"角色"做成一等公民。
• 本章 1.5 会让你真正把环境配好跑通，背景只是让你知道为什么这么设计。

⚠️ 别把 AutoGen 当万能胶。直线型、不可中断的批处理任务，手写脚本往往更省心、更好调试。

💡 记住主调"对话即编排"：你设计的不是流程，而是角色关系网，任务顺着对话流动。