想象你是一家咨询公司的负责人,会议室里坐着四张不同名片:产品经理、程序员、测试员、文档专员。过去,你要亲自把需求拆成一条条指令,分别塞给每个人,再逐个回收结果,像流水线上的监工。现在,AutoGen 给这间会议室装了一套“会议规则”:谁说话、对谁说、说什么、说完之后谁接话,都由框架统一调度。你说一句“帮客户做一份数据分析报告”,几位“Agent 员工”会自己讨论、自己写代码、自己检查结果,直到把任务完成。AutoGen 是微软开源的多 Agent 开发框架,它的核心不是让模型变聪明,而是用“对话”这种人类最熟悉的协作方式,把多个 AI 角色组织成一支能自动推进任务的团队。

岗位关联

对 AI 从业者而言,AutoGen 是入局多 Agent 应用开发的必经一环:它让你从“调接口”升级为“设计一支 AI 团队”,是 AI 应用从 Demo 走向真实业务的关键能力。

目录
  1. 可视化演示
  2. 初识AutoGen:给会议室装上规则
  3. 核心概念:角色、便签与散会
  4. ConversableAgent:能说会道的员工
  5. 代码执行:让员工现场算账
  6. 群聊模式:多部门联席会议
  7. 构建实践:把会议室搭起来
  8. 对比展望:链式管道 vs 自由对话
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效(进入视口后自动加载,约 3KB)。

ConversableAgent基类体系 ConversableAgent消息收发 · 回复生成 · 对话管理ConversableAgentConversableAgent消息收发 · 回复生成 · 对话管理ConversableAgent ConversableAgent消息收发 · 回复生成 · 对话管理ConversableAgentConversableAgent消息收发 · 回复生成 · 对话管理ConversableAgent

初识AutoGen:给会议室装上规则

过去你管理一个团队,需要亲自把任务拆成小纸条,递给不同的人,再回来检查成果。当任务复杂起来,你的“接口人”工作会占满全部时间。AutoGen 的思路恰恰相反:它不让你当流水线监工,而是给会议室装上规则,让员工们自己传纸条、自己接话。微软开源这个框架时,核心承诺就是“多 Agent 协作 + 对话驱动”。也就是说,每个 Agent 是一个有角色设定的员工,任务通过一条条消息在员工之间流动,而不是你手动写死调用顺序。

在工程上,AutoGen 把“一个复杂任务”看成多个子任务的组合。无论是产品经理拆需求、程序员写代码,还是测试员纠错,每个 Agent 只负责自己那块拼图。最终任务完成的标志是各子任务的结果汇聚到一起。

回到比喻:AutoGen 没有取代任何员工,它只是把“谁来开会、谁先发言、谁对谁说话”这些会议规则写在系统里。你的团队从“听你指挥的木偶”变成了“围着会议桌自己推进问题的同事”。

Ttask=∑i=1nti\displaystyle T_{\text{task}} = \sum_{i=1}^{n} t_i
这条公式表示:总任务等于所有 Agent 子任务的累加。AutoGen 的作用就是把右边的“子任务集合”组织成一条有序的协作流。
  1. 任务总量符号T_{\text{task}} 代表整个复杂业务目标,比如“生成一份市场分析报告”。
    TtaskT_{\text{task}}
  2. 子任务变量t_i 表示第 i 个 Agent 负责的那一小块工作,比如“收集数据”或“绘制图表”。
    tit_i
  3. 累加运算\sum_{i=1}^{n} 表示把第 1 个到第 n 个子任务汇总在一起,形成最终交付物。
    ∑i=1nti\sum_{i=1}^{n} t_i

核心概念:角色、便签与散会

会议室里最重要的事情是什么?不是大家坐在一起,而是有人说话,有人接话,并且每个人都清楚自己现在的角色。AutoGen 的四个核心概念恰好对应这四个要素:Agent 是员工,Message 是传递的便签,Conversation 是连续多轮的对话流,Termination 则是主持人宣布散会的条件。

一条消息在 AutoGen 中最简单的表达是一个三元组:谁发的、发给谁、内容是什么。就像你在黄色便签上写“小码,请把冒泡排序写出来”,落款是“小产”,收件人是“小码”。这个结构简单却非常关键,因为所有 Agent 的协作都建立在这种“有明确收发对象”的便签之上。

一次完整的协作,是由许多条 M 首尾相接组成的。AutoGen 会把便签一张张贴进会议记录,形成对话历史。直到出现终止条件,比如“任务已完成”或“到达最大轮次”,会议才正式散场。

M=(s,r,c)\displaystyle M = (s, r, c)
这条公式把一条消息抽象成三元组:发送者、接收者、内容。理解它,就理解了 AutoGen 对话系统的最小数据单元。
  1. 消息整体M 代表一条完整的会议便签,也就是 Agent 之间传递的最小信息单位。
    MM
  2. 发送者s 是 sender,表示这条消息来自哪位 Agent,比如产品经理 Agent。
    ss
  3. 接收者r 是 receiver,表示这份便签递给谁,比如程序员 Agent。
    rr
  4. 内容c 是 content,表示便签上真正要传递的文字、代码或问题。
    cc

ConversableAgent:能说会道的员工

在 AutoGen 的员工手册里,几乎所有 Agent 都继承自同一个基类:ConversableAgent。你可以把它理解成一位“自带沟通能力”的标准员工。它有三个重要属性:system_message 是入职时写的岗位说明书,决定了员工的行为边界;llm_config 是员工的大脑配置,告诉它用哪个大模型思考;human_input_mode 则决定这位员工是否会在开会途中回头问你一句“领导,这一步怎么办”。

ConversableAgent 最核心的能力是“自动回复”。当一个 Agent 收到消息后,它会结合自己看到的完整会议记录 h_t,生成下一句话 a_{t+1}。这句话可能是一个回答、一段代码,也可能是一个请求。除了说话,它还能调用外部工具:通过注册 Python 函数,让 Agent 拥有“动手”的能力,比如查数据库、调 API、执行脚本。

在会议室比喻里,ConversableAgent 就是那张可以自由替换的“员工座位”。无论是真人代理、AI 助手,还是某个工具封装,只要坐上这把椅子,就能用同一套消息协议参与对话。这也是 AutoGen 灵活性的根源。

at+1=fagent(ht)\displaystyle a_{t+1} = f_{\text{agent}}(h_t)
这条公式表示:Agent 的下一条回复,是它根据当前完整对话历史做出的决策。h_t 越完整,回复越不跑题。
  1. 对话历史h_t 是截至当前时刻的全部会议记录,包括所有旧的便签和系统提示。
    hth_t
  2. Agent 决策函数f_{\text{agent}} 是 Agent 内部的生成逻辑,可以是大模型,也可以是规则或工具。
    fagentf_{\text{agent}}
  3. 下一条回复a_{t+1} 是 Agent 基于历史刚刚说出口的新消息,它会被追加到会议记录中。
    at+1a_{t+1}

代码执行:让员工现场算账

开会时如果只说空话,事情永远落不了地。AutoGen 的解法是给 Agent 配上“计算器”——代码执行引擎。当程序员 Agent 说“我写了一段 Python 可以算最大公约数”时,框架不会只让这句话停留在纸面,而是真的把代码拿去运行,再把运行结果贴回会议记录。

代码执行有三种常见配置:直接在本地环境跑、在 Docker 容器里跑、通过 Jupyter 解释器跑。Docker 沙箱尤其重要,它像一个隔离的“临时工位”:员工可以在里面随意测试,就算把桌子烧了,也不会影响外面的大办公室。每次执行后,代码 c 会产生输出 o,这个输出会变成一条新消息 m',回到 Agent 手中,让 Agent 根据真实结果继续下一步。

在会议室里,这等于给员工配了一台可以反复验算的电脑。产品经理说“算一下年度增长率”,程序员 Agent 写完代码,测试员 Agent 就能看到真实输出,而不是凭感觉说“我觉得没问题”。代码执行让多 Agent 协作从“嘴上讨论”变成“手上验证”。

o=run(c),m′=(r,s,c,o)\displaystyle o = \text{run}(c), \quad m' = (r, s, c, o)
这条公式表示:代码执行把 Agent 写的 c 变成运行输出 o,并把它重新包装成消息喂回对话中,形成“写码—执行—看结果—修改”的闭环。
  1. 代码内容c 是 Agent 生成的一段 Python 代码,相当于员工写下的计算草稿。
    cc
  2. 执行动作\text{run}(c) 表示把这段代码放到本地、Docker 或 Jupyter 中真正运行。
    run(c)\text{run}(c)
  3. 运行输出o 是代码跑完后产生的标准输出、结果或报错信息。
    oo
  4. 回传消息m' 是包含代码和输出结果的新便签,会被送回对话历史,供其他 Agent 继续讨论。
    m′=(r,s,c,o)m' = (r, s, c, o)

群聊模式:多部门联席会议

双 Agent 对话就像两个人面对面聊,但真实业务往往需要多方参与,比如产品、研发、测试一起评审。AutoGen 用 GroupChat 和 GroupChatManager 实现群聊模式。GroupChat 是所有消息汇聚的公共会议记录,而 GroupChatManager 是主持人,负责决定下一个发言的人是谁。

主持人有一套发言策略:可以是轮转(round-robin),让成员按顺序轮流说;也可以是自动选择(auto),由大模型根据全局信息判断哪位 Agent 最适合接话。这种调度方式避免了“所有人同时开口”的混乱。在 AutoGen 中,同一时刻只有一位 Agent 发言,其他人先看,再等待主持人点名的机会。

所有 Agent 都看着同一块共享白板,但只有主持人递出话筒的人才能开口。这样一来,“群聊”就不是七嘴八舌的菜市场,而是一场有秩序、有产出、有记录的联席会议。

st+1=g(ht,S)\displaystyle s_{t+1} = g(h_t, S)
这条公式表示:群聊主持人 g 会根据当前会议历史 h_t 和在场 Agent 集合 S,选出下一位发言者 s_{t+1}。
  1. 候选人集合S 是当前群聊中的所有 Agent 成员,就像围坐在会议桌旁的全部同事。
    SS
  2. 会议历史h_t 是群聊中已经产生的所有消息,主持人靠它判断会议进行到哪里。
    hth_t
  3. 选择函数g 是主持人的调度策略,可能是轮转、随机,也可能是大模型智能判断。
    gg
  4. 下一位发言者s_{t+1} 是主持人最终点名的 Agent,只有它能在当前轮次发言。
    st+1s_{t+1}

构建实践:把会议室搭起来

理解了概念,接下来要亲手搭会议室。第一步是环境初始化:安装 pyautogen,配置大模型 API key。第二步是创建 Agent,最经典的双 Agent 组合是“AI 助手 + 用户代理”。AI 助手负责思考与生成,用户代理则代表人类发起指令,也可以承载代码执行。

当任务比较复杂时,可以升级成多 Agent 群聊:定义 Planner 负责拆步骤,Coder 负责写代码,Critic 负责找问题,再把它们加入同一个 GroupChat,配上 GroupChatManager 作为主持人。初始化对话时,你只需要说一句“请帮我完成某某任务”,接下来的发言顺序、验证循环、修订过程都由框架协调。实际调试时,重点关注两个地方:消息是否按预期流转,以及终止条件是否会在合理时机触发。

搭会议室的过程中,最重要的设计不是写更多代码,而是想清楚“谁适合当什么角色、什么时候该散会”。AutoGen 把实现细节封装好了,真正的难点在于团队设计。

Nround=nmsg2\displaystyle N_{\text{round}} = \frac{n_{\text{msg}}}{2}
这条公式给出了一个粗略的轮次估算:双 Agent 对话中,消息总数 n_msg 除以 2,就是经历过的“提问—回复”轮数。轮数越大,代表协作越深入,但 token 成本也会越高。
  1. 消息总数n_{\text{msg}} 是对话历史里已经积累的所有消息条数。
    nmsgn_{\text{msg}}
  2. 轮次结果N_{\text{round}} 是估算出的完整对话轮数,对应会议室里来回了多少轮发言。
    NroundN_{\text{round}}

对比展望:链式管道 vs 自由对话

很多人会把 AutoGen 与 LangChain 放在一起比较。简单来说,LangChain 更像一条预设好的流水线:原料从入口进去,经过 A 模块到 B 模块再到 C 模块,每一步都是提前设计好的。而 AutoGen 更像一场自由讨论:Agent 之间你来我往,下一步谁说、说什么,是根据当下情况动态决定的。

因此,LangChain 适合流程稳定、步骤明确的场景,比如“先检索再总结最后生成回复”;AutoGen 适合流程不确定、需要多角色动态协商和验证的场景,比如“让 AI 团队自己研究一个开源项目并写复盘报告”。两者并非谁取代谁,而是互为补充。AutoGen 也可以作为 LangChain 生态里的一个环节,或者直接调用 LangChain 的工具链。

回到会议室比喻:LangChain 是提前铺好的传送带,适合重复生产标准件;AutoGen 是随时调整议程的圆桌会议,适合攻克没人完全想清楚的问题。选择哪个工具,取决于你要的是“稳定执行”还是“探索协作”。

LangChain:y=fn∘⋯∘f1(x),AutoGen:y=converse(a1,a2,…,am)\displaystyle \text{LangChain}: y = f_n \circ \cdots \circ f_1(x), \qquad \text{AutoGen}: y = \text{converse}(a_1, a_2, \dots, a_m)
这条公式对比了两种范式:LangChain 是函数复合的固定链,AutoGen 是多个 Agent 之间的自由对话。理解了这个区别,你就理解了两种框架的设计哲学。
  1. 固定链流程f_n \circ \cdots \circ f_1(x) 表示数据从 x 进入,依次经过多个模块,最终得到结果 y。
    y=fn∘⋯∘f1(x)y = f_n \circ \cdots \circ f_1(x)
  2. 多Agent对话\text{converse}(a_1, \dots, a_m) 表示一组 Agent 通过互相发消息共同产出结果,路径不唯一。
    converse(a1,a2,…,am)\text{converse}(a_1, a_2, \dots, a_m)

AI 应用场景

自动化软件研发小分队

阶段:AI 应用设计与开发

解决的问题:传统软件开发中,需求分析、代码编写、代码审查是三个割裂的环节,开发者要反复切换角色,沟通成本高。AutoGen 让三个 Agent 分别担任产品经理、程序员和测试员,通过群聊自动完成“拆需求—写代码—审代码”的循环。

具体案例:某数据团队需要写一个内部数据清洗脚本。产品 Agent 把需求拆成三步,编程 Agent 根据步骤生成 pandas 代码,测试 Agent 发现问题后要求重写。整个协商过程在几分钟内完成,开发者只负责最终确认。

企业知识库智能客服

阶段:AI 应用部署与运维

解决的问题:传统客服机器人只能做单轮问答,遇到复杂问题容易答非所问。AutoGen 让“前台客服 Agent”和“后台质检 Agent”协作:前台负责组织回答,后台负责核对知识库引用是否准确,必要时调用搜索工具补充证据。

具体案例:一家保险公司用 AutoGen 搭建售后助手。客户问保单条款时,前台 Agent 回答,后台 Agent 从知识库检索原文并校验一致性,降低了大模型“信口开河”的风险。

自动数据分析报告生成

阶段:AI 应用增效优化

解决的问题:数据分析报告往往包含取数、清洗、建模、可视化多个步骤,人工操作耗时长。AutoGen 利用代码执行能力,让 Agent 在沙箱中真正运行分析代码,再根据真实结果撰写结论。

具体案例:市场部每月要出一份销售复盘报告。Planner Agent 制定分析维度,Coder Agent 写 Python 代码拉取数据并画图,Critic Agent 检查图表和结论是否一致,最终输出一份带图表和摘要的完整报告。

Python 演示

python63 行
import osfrom autogen import ConversableAgent, GroupChat, GroupChatManager  def create_agent(name, system_message, llm_config):    return ConversableAgent(        name=name,        system_message=system_message,        llm_config=llm_config,        human_input_mode="NEVER",    )  def main():    config_list = [        {            "model": os.environ.get("OPENAI_MODEL", "gpt-4o-mini"),            "api_key": os.environ.get("OPENAI_API_KEY", "sk-..."),        }    ]    llm_config = {"config_list": config_list, "temperature": 0.3}     planner = create_agent(        "Planner",        "你负责把任务拆成清晰的步骤,只输出步骤,不写代码。",        llm_config,    )    coder = create_agent(        "Coder",        "你负责根据步骤写完整的 Python 代码,代码要可直接运行。",        llm_config,    )    critic = create_agent(        "Critic",        "你负责审查代码,指出错误并给出修改建议。",        llm_config,    )     group_chat = GroupChat(        agents=[planner, coder, critic],        messages=[],        max_round=6,    )    manager = GroupChatManager(        groupchat=group_chat,        llm_config=llm_config,    )     user_proxy = ConversableAgent(        name="Admin",        llm_config=False,        human_input_mode="NEVER",    )     result = user_proxy.initiate_chat(        manager,        message="请帮我写一个 Python 函数,计算两个整数的最大公约数。",    )    print(result.chat_history)  if __name__ == "__main__":    main()
目的:用 AutoGen 搭建一个 Planner、Coder、Critic 组成的三人群聊,自动完成“拆解任务—写代码—审查代码”的协作闭环。
  1. from autogen import ConversableAgent, GroupChat, GroupChatManager导入 AutoGen 的核心类,相当于把会议室的桌椅和主持人请进来。
  2. human_input_mode="NEVER"设置 Agent 运行时不主动打断询问人类,保证群聊可以自动推进。
  3. system_message="你负责把任务拆成清晰的步骤"给每个 Agent 写岗位说明书,决定它在协作中的角色边界。
  4. GroupChat(agents=[...], messages=[], max_round=6)创建共享会议记录,并设置最大 6 轮发言,防止“无限开会”。
  5. GroupChatManager(groupchat=group_chat, llm_config=llm_config)创建主持人,负责从 Agent 列表中挑选下一个发言人。
  6. user_proxy.initiate_chat(manager, message=...)由用户代理发起初始指令,正式开启多 Agent 对话。

常见误区

误区以为 AutoGen 和 LangChain 一样,只是把很多大模型调用通过 Prompt 一条条连起来,按固定顺序执行。

正解AutoGen 的核心是“多 Agent 对话”,消息会动态回流,Agent 可以根据上一步结果决定下一步内容。链式调用的路径是提前写死的,而 AutoGen 的会议进程是现场演化的。就像流水线工人只能等上一个工位传零件,而会议室里谁发言完全取决于刚才谁说了什么。

为何常见:两者都在编排大模型调用,表面形式相似,初学者容易从“串联组件”的角度理解所有编排框架。

误区以为 GroupChat 像微信群一样,所有成员都能随时发消息,大家一起讨论。

正解AutoGen 的群聊有主持人 GroupChatManager,它根据策略选择下一个发言者,同一时刻只有一个 Agent 说话。其他 Agent 先收声,等待消息进入公共记录后再等待被点名。

为何常见:“群聊”这个词太有误导性,让人联想到多人自由发言的聊天软件,忽略了 AutoGen 的调度机制。

误区以为把 `human_input_mode` 设置为 `"NEVER"` 之后,整个流程就可以完全摆脱人类,AI 全自动运行。

正解"NEVER" 只是说运行过程中不主动弹出输入框等待人类回答,但人类仍然可以通过初始指令、工具定义、终止条件来影响整个过程。就像你把会议交给主持人,不代表参会者不能提前准备议题。

为何常见:“全自动”是 AI 产品最吸引人的卖点,开发者容易把某个配置项理解为“彻底无人化”。

误区以为 Agent 生成代码后,结果会自动出现在它的“大脑”里,不需要真正运行。

正解AutoGen 的代码执行需要显式配置本地、Docker 或 Jupyter 环境。框架会把生成代码交给外部解释器执行,再把 stdout、stderr 返回给 Agent。没有执行引擎,Agent 就只能凭空猜测代码运行结果。

为何常见:大模型的回答太流畅,让人觉得它“什么都会算”,实际上它只是会生成文字,并不会亲自运行程序。

误区以为 Agent 数量越多,任务完成质量一定越高,于是堆砌一堆角色。

正解每个 Agent 都需要消耗 token,而且发言轮次会随着人数增加成倍增长。角色过多会导致会议冗长、成本飙升,甚至让主持人难以决策。好的配置是“够用就好”,就像 3 人小会能解决的问题,不必叫来 20 人。

为何常见:多 Agent 是热门概念,容易让人产生“数量等于能力”的直觉,忽略了协作的复杂度。

面试题

Q1. AutoGen 在 AI 应用开发中的定位是什么?

单选题 · easy

  • A.多Agent对话协作框架← 正确答案
  • B.大模型权重微调工具
  • C.向量数据库查询引擎
  • D.前端组件可视化库

答案:A。AutoGen 是微软开源的多 Agent 开发框架,目标是让多个 Agent 通过对话协作完成任务。它不负责微调模型、不管理向量数据库,也不做前端展示,所以 B、C、D 都是混淆项。

Q2. 在 ConversableAgent 中,system_message 的主要作用是什么?

单选题 · easy

  • A.设定Agent角色与行为边界← 正确答案
  • B.保存所有历史对话记录
  • C.控制代码执行的沙箱等级
  • D.决定群聊中的发言顺序

答案:A。system_message 相当于岗位说明书,告诉 Agent 它是什么角色、应该怎么表现。对话历史由消息池管理,代码执行由执行配置管理,发言顺序由 GroupChatManager 决定。

Q3. GroupChatManager 在群聊模式中的核心职责是什么?

单选题 · easy

  • A.选择下一个发言人← 正确答案
  • B.执行所有Agent生成的代码
  • C.训练群聊中的大模型
  • D.存储外部知识库文档

答案:A。群聊主持人负责根据会议历史和发言策略,从候选 Agent 中选出下一位发言者。代码执行、模型训练、知识库存储都不是主持人的职责。

Q4. 在 AutoGen 中,human_input_mode 设为 NEVER 的含义是什么?

单选题 · mid

  • A.运行中不主动询问人类输入← 正确答案
  • B.彻底禁止任何人参与系统
  • C.只允许人类在结束后评论
  • D.关闭所有Agent之间的对话

答案:A。NEVER 表示 Agent 在自动回复循环中不会弹出输入框等待人回答,但人仍然可以通过初始消息、工具注册等方式参与。B 说法过于绝对,C 和 D 与配置含义无关。

Q5. 关于 AutoGen 的代码执行能力,下列哪项描述正确?

单选题 · mid

  • A.可配置本地或Docker沙箱← 正确答案
  • B.只能执行C++语言代码
  • C.由模型在推理时自动运行
  • D.执行结果不会返回给Agent

答案:A。AutoGen 支持本地、Docker、Jupyter 等执行环境,主要用于运行 Python 代码。代码必须先执行,再把输出回传给 Agent,B、C、D 都违背了代码执行的基本设计。

Q6. 多 Agent 群聊相比单 Agent 的最大优势是什么?

单选题 · mid

  • A.不同角色分工协作处理复杂任务← 正确答案
  • B.一定会减少大模型调用次数
  • C.完全不需要设置终止条件
  • D.可以消除所有模型幻觉

答案:A。群聊通过角色分工让每个 Agent 专注于自己的职责,适合复杂任务。多 Agent 可能增加调用次数,也需要终止条件,更不能保证消除幻觉,所以 B、C、D 错误。

Q7. 在 AutoGen 中把 Python 函数暴露给 Agent 调用的常用方式是哪种?

单选题 · extreme

  • A.register_function 注册到工具列表← 正确答案
  • B.add_tool 动态注入系统内存
  • C.bind_api 连接外部数据库
  • D.set_plugin 加载本地插件

答案:A。AutoGen 通过 register_function 将自定义 Python 函数注册给 Agent,使 Agent 可以在对话中调用它。其他选项不是 AutoGen 的标准 API。

Q8. 下列哪些情况可以作为 AutoGen 对话的终止条件?

多选题 · mid

  • A.达到预设最大轮次← 正确答案
  • B.Agent 输出包含结束词← 正确答案
  • C.群聊 max_round 耗尽← 正确答案
  • D.磁盘空间达到上限

答案:ABC。AutoGen 支持通过最大轮次、自定义消息判断、群聊 max_round 等方式终止对话。磁盘空间是系统资源问题,不是正常的对话终止条件。

Q9. 关于 AutoGen 与 LangChain 的区别,下列说法正确的有哪些?

多选题 · hard

  • A.AutoGen 强调多个Agent对话协作← 正确答案
  • B.LangChain 通常用预定义链串联组件← 正确答案
  • C.AutoGen 允许人类参与对话流程← 正确答案
  • D.LangChain 无法调用任何工具

答案:ABC。AutoGen 的核心是动态对话协作,LangChain 更偏向固定链路。AutoGen 支持人类作为代理参与,LangChain 也支持工具调用,所以 D 错误。

Q10. 设计 AutoGen 群聊应用时,哪些做法是合理的?

多选题 · hard

  • A.给不同Agent明确角色边界← 正确答案
  • B.设置合理的对话终止条件← 正确答案
  • C.让所有Agent同时发言提速
  • D.对代码执行采用安全沙箱← 正确答案

答案:ABD。明确的角色边界能让每个 Agent 聚焦,合理的终止条件能避免无限开会,沙箱能保护运行环境。群聊模式同一时刻只能一人发言,C 违背 AutoGen 的调度机制。