一、为什么单个 Agent 开始力不从心
用单个大模型搭出的 AI Agent 跑通 Demo 很容易，但一旦进入真实场景，三个结构性瓶颈就会暴露。其一是上下文窗口有限：把”需求分析、写代码、做测试、写文档”全部塞进同一个 System Prompt，角色边界会迅速模糊，模型开始”既当裁判又当运动员”。其二是难以并行：单 Agent 本质是串行对话，无法让”编码”和”评审”两个动作同时进行。其三是可观测性差：出错了你很难判断是哪一步的决策导致的。多智能体编排（Multi-Agent Orchestration）正是为这些痛点而生——把一个复杂任务拆给多个专才 Agent，让它们像团队一样对话、交接、互相校验。
微软开源的 AutoGen 就是一套面向开发者的多智能体编排框架。它用极少的代码就能拉起一个会”群聊”的 Agent 团队：有负责写代码的，有负责跑代码的，有负责挑毛病的，最后由调度器把他们的对话串成一条可复用的流水线。本文用可运行示例，带你从零搭出一个协作式 AI Agent 团队，并给出生产落地的检查清单。
二、AutoGen 的三个核心抽象
理解 AutoGen，先记住三个角色：AssistantAgent（由 LLM 驱动的”员工”，会思考、对话、产出内容）、UserProxyAgent（代表人类或执行环境，能真正运行代码、调用函数并把结果回传）、以及 GroupChat + GroupChatManager（多智能体群聊调度器，决定下一轮轮到谁发言）。前两者负责”干活”，后者负责”控场”。
2.1 五分钟跑通一个双智能体
先装包，再写一个最小可运行示例：让助手写代码、代理在本机执行代码。
pip install pyautogen
import autogen
config_list = [{"model": "gpt-4o", "api_key": "YOUR_KEY"}]
assistant = autogen.AssistantAgent(
name="assistant",
llm_config={"config_list": config_list},
)
user_proxy = autogen.UserProxyAgent(
name="user_proxy",
human_input_mode="NEVER",
code_execution_config={"work_dir": "coding"},
)
user_proxy.initiate_chat(
assistant,
message="用 Python 写一个带类型注解的快速排序",
)
运行后，assistant 生成代码，user_proxy 在 coding 目录里执行它并把 stdout 回传给助手，形成”生成—执行—纠错”的自动闭环。这就是单 Agent 最难稳定做到的”边写边跑”。
三、构建协作式多智能体团队
真正的价值在群聊。下面我们组一个”程序员 + 测试员 + 项目经理”的小团队，由 GroupChatManager 轮流点名发言，直到任务收敛或达到最大轮数。
coder = autogen.AssistantAgent(
name="coder",
system_message="你是资深后端工程师，只输出可运行代码与必要说明。",
llm_config={"config_list": config_list},
)
reviewer = autogen.AssistantAgent(
name="reviewer",
system_message="你是严格的代码评审，指出 bug、边界与安全隐患，不写代码。",
llm_config={"config_list": config_list},
)
group = autogen.GroupChat(
agents=[user_proxy, coder, reviewer],
messages=[],
max_round=12,
)
manager = autogen.GroupChatManager(
group=group,
llm_config={"config_list": config_list},
)
user_proxy.initiate_chat(
manager,
message="实现一个线程安全的栈，带单元测试与复杂度说明。",
)
在这个循环里，coder 写实现，user_proxy 执行测试，reviewer 读结果挑问题，再交回 coder 修改——一个会自我修复的开发闭环就这样跑起来了。若你想把这套能力接入已有的 Dify + Ollama 本地工作流，可以把 Dify 暴露的 API 包成一个函数交给 UserProxy 调用，让”低代码编排”和”代码编排”互补。
四、让 Agent 真正干活：函数调用与工具
多智能体不只是聊天，关键是让它们能调用外部能力。AutoGen 允许你把任意 Python 函数注册为工具，模型在对话中即可触发。
def get_weather(city: str) -> str:
# 这里换成真实天气 API
return f"{city} 今天晴，28℃，适宜出行"
user_proxy.register_function(
function_map={"get_weather": get_weather},
)
user_proxy.initiate_chat(
assistant,
message="北京今天适合户外运动吗？",
)
注册后，当对话需要”查天气”，UserProxy 会自动执行 get_weather 并把返回值回灌给助手。把它扩展成查数据库、调内部微服务、读写文件，Agent 就从”嘴强王者”变成能动手的同事。涉及大模型推理时，底层选择哪款 推理引擎 会直接决定延迟与成本，建议先在小流量验证再全量。
五、实战：代码评审 + 自动修复流水线
这是最贴近工程现场的组合。我们让三个 Agent 共享一个工作目录，角色分工如下：
| 角色 | 职责 | 是否执行代码 |
|---|---|---|
| coder | 根据需求产出实现与单元测试用例 | 否（产出代码文本） |
| user_proxy | 在隔离目录运行测试，回传 stdout / 报错 | 是 |
| reviewer | 读测试结果与 diff，指出缺陷与改进点 | 否 |
把 max_round 设为 10～15，意味着最多自我修复十几轮；超过即停止并汇总当前最优结果，避免无限循环烧钱。若测试长期不过，可在 reviewer 的 system_message 里强制”只报最关键的一个 blocking 问题”，让收敛更快。需要把生成结果接进 CI 时，可参考 GitHub Actions 持续集成 的流水线写法，把 AutoGen 跑在 PR 的预提交钩子里。
六、AutoGen vs Dify vs 手写编排
| 维度 | AutoGen（代码编排） | Dify（低代码） | 纯手写（直接调 API） |
|---|---|---|---|
| 上手速度 | 中（需写 Python） | 快（拖拽） | 慢 |
| 灵活性 | 极高 | 受节点能力限制 | 极高 |
| 多智能体原生支持 | 强（GroupChat） | 一般（需拼装） | 需自己实现调度 |
| 调试可观测性 | 好（消息流可打印） | 好（有界面） | 差（自己埋点） |
| 适合场景 | 研发型、需代码执行的任务 | 业务型、快速试点 | 极致定制 |
结论很直接：要快速给业务同学做个对话原型，用 Dify；要让 Agent 真正读写代码、跑测试、自我修复，AutoGen 的群聊范式更省心。二者并非互斥，很多团队用 Dify 做前端编排、用 AutoGen 做后端”代码智能体”内核。
七、生产落地检查清单
| 检查项 | 建议做法 |
|---|---|
| 模型与成本控制 | 给 GroupChat 设 max_round，避免无限轮对话；小模型做评审、大模型做编码 |
| 代码执行隔离 | UserProxy 的 work_dir 用临时目录 + 容器，禁止访问宿主机密钥 |
| 失败兜底 | 捕获异常，超过轮数返回”当前最优”，不抛错中断业务 |
| 可观测 | 把每轮消息落日志，定位是哪一步 Agent 跑偏 |
| 密钥管理 | API Key 走环境变量，勿硬编码进代码 |
| 本地验证 | 先在 本地量化部署 的小模型上跑通流程再上云 |
开发阶段强烈建议配合 VS Code 的 Python 调试与 Docker 容器做执行隔离，把”Agent 写代码”关在沙箱里，既安全又易于复现。
八、结语
单 Agent 是”一个人扛全部”，多智能体编排是”组一支队伍”。AutoGen 用 AssistantAgent、UserProxyAgent 和 GroupChat 三件套，把”分工—执行—评审—修复”的工程闭环压缩到几十行代码。它不一定是唯一选择，但当你需要让 AI 真正动手写代码、跑测试、自我纠错时，这套群聊范式几乎是当下最省心的起点。下一步，不妨从一个”编码 + 评审”的最小双人组开始，跑通后再逐步加角色、加工具、加护栏。
