想象你建了一个跨部门项目微信群：产品经理在群里发需求，工程师在群里回复方案，偶尔老板潜进来说两句话。表面看是一群人在聊天，实际上每一次发言都遵循着隐形的「群聊协议」——谁发言、什么格式、什么时候结束、老板何时介入。AutoGen 框架中的 ConversableAgent，正是把这种「人肉群聊协议」搬进了代码世界：每个 Agent 都是群里一个有身份、有说话风格、有专长的「数字同事」，它们通过结构化的消息一来一往，围绕同一个任务展开多轮对话。这套协议由七个关键部分构成：对话基础、消息传递、会话机制、终止条件、人类输入、角色定制和多 Agent 群聊编排。学完你就会发现，所谓「多智能体协作」，本质上是把一群人开会的默契写成可运行的程序。

岗位关联

掌握 ConversableAgent 的对话协议设计，是成为 AI Agent 架构师的必经之路——你将能把「角色分工」与「流程管控」从想法落地为可运行的多 Agent 系统。

目录
  1. 可视化演示
  2. 对话基础：每个 AI 都是群里有身份的同事
  3. 消息传递协议：群里每条消息都有标准格式
  4. 对话会话机制：一次讨论从建群到收尾
  5. 终止条件：群聊不会永远进行下去
  6. 人类输入集成：老板什么时候该发言
  7. 角色与个性定制：给每个 AI 一张立体名片
  8. 多Agent群聊编排：从一对一私聊到全员大会
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示数据库Write-Ahead Logging崩溃恢复的三个阶段：分析、重做和撤销，动态演示日志扫描与事务状态重建的完整流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

分析阶段 正向扫描WAL日志重建事务表 识别已提交与未提交事务 ARIES 三阶段恢复协议第一阶段

对话基础：每个 AI 都是群里有身份的同事

想象你是一个项目群的管理员，群里产品经理小林、工程师小张各司其职。每个人进群都要备注职位和职责，这就是 Agent 的「名片」。AutoGen 框架中的 ConversableAgent——你可以把它理解为群聊里一个会说话、有记忆、能调工具的数字同事。它的自我介绍（system_message）、大脑型号（llm_config）、发言规则（human_input_mode）共同构成一张完整的「身份卡」。

纯大模型 API 是「一次性问答」：你抛一个问题，它回一段答案，没有记忆、没有身份。而 ConversableAgent 是一个「有状态」的对话参与者：它记得之前的聊天内容，知道自己是谁，还能根据角色切换说话方式。这正是「可对话 Agent」与普通 API 调用的分水岭——它不是为了回答单个问题而生，而是为了在持续对话中完成复杂任务。

在代码层面，创建一个 ConversableAgent 需要四个关键配置，它们的组合决定了一个 Agent 的全部行为：

有了「身份卡」，每个 Agent 就像群里一个有血有肉的同事——不只是一个 API，而是一个有名字、有职位、有说话风格的「数字员工」。后续讨论的所有协议，都是围绕着「这些数字员工如何高效礼貌地聊天」展开的。

A=(name, system_message, llm_config, human_input_mode)A = (\text{name},\ \text{system\_message},\ \text{llm\_config},\ \text{human\_input\_mode})
公式含义：一个 ConversableAgent 的本质就是这四项配置的组合——名字决定身份、人设决定风格、模型决定智力、介入模式决定自主权。
  1. name（身份证）Agent 在对话中的唯一标识，相当于微信群里的昵称，消息中会用它标记发言者。
    name∈String\text{name} \in \text{String}
  2. system\_message（人设卡）一段角色说明文字，让底层 LLM 按该角色风格回复。
    system_message∈Prompt\text{system\_message} \in \text{Prompt}
  3. llm\_config（大脑连接）指定模型名称、API Key 等参数，决定用哪个大模型驱动该 Agent。
    llm_config={model, api_key, …}\text{llm\_config} = \{\text{model},\ \text{api\_key},\ \ldots\}
  4. human\_input\_mode（自主度旋钮）取值 NEVER / ALWAYS / TERMINATE，决定人类何时介入。
    mode∈{NEVER, ALWAYS, TERMINATE}\text{mode} \in \{\text{NEVER},\ \text{ALWAYS},\ \text{TERMINATE}\}

消息传递协议：群里每条消息都有标准格式

在项目群里，你绝不会发一条没有署名、没有对象的乱码消息。每条消息都遵循「谁发的 → @谁 → 说了什么 → 什么时候」的格式。消息传递协议就是把这个格式固化成代码，让机器之间也能对齐「沟通格式」。

ConversableAgent 之间传递的消息不是裸文本，而是结构化的数据字典。它包含发送者名字、接收者身份、正文内容和时间顺序等信息。这种结构化设计让每个 Agent 拿到消息时都能立刻回答四个问题：这话是谁说的？说给谁听？内容是什么？排在哪个位置？

send 和 receive 是通信的两个核心动作。send 负责把消息推送给指定 Agent；receive 负责接收消息、追加到自己的对话历史中，并触发回复生成逻辑。一次「send → receive → reply」构成一个完整的通信周期，消息本身可以抽象成：

就像群消息没有「@谁」就会让人摸不着头脑，结构化消息的每个字段都是为了消除歧义——谁说的、跟谁说、说了啥、啥时候，四项齐全，机器人才能准确接话。

M=(s, r, c, t)M = (s,\ r,\ c,\ t)
公式含义：一条消息由四个维度唯一确定——发送方是谁、接收方是谁、内容是什么、发生在什么时候。
  1. s（发送方）消息的发起者 Agent 名字，相当于群消息的「发送人」。
    s∈AgentSets \in \text{AgentSet}
  2. r（接收方）消息的目标 Agent，相当于「@ 对象」。
    r∈AgentSetr \in \text{AgentSet}
  3. c（内容）实际对话文本，是消息的灵魂。
    c∈Stringc \in \text{String}
  4. t（时序）时间戳或序号，保证消息在历史中按序排列，谁也不能插队。
    t1<t2<⋯<tnt_1 < t_2 < \cdots < t_n

对话会话机制：一次讨论从建群到收尾

任何一个项目讨论都有自己的发起方式：管理员建群、拉人、抛第一句话。AutoGen 中这个「抛第一句话」的动作叫做 initiate_chat——它指定讨论对象、抛出初始话题、限制讨论轮数，最后把聊天记录整理好返回给你。每次调用它，就开启一个独立的「会话」。

会话内部是一个多轮交替过程：发送方发消息 → 接收方生成回复 → 发送方再回复……如此循环。每一轮都由「谁来发言」驱动，而发言依据是双方共同维护的对话历史。这正是多 Agent 协作和普通 API 调用的重要区别：决策依赖「上下文上下文」，而上下文就是不断累积的消息列表。

随着对话推进，所有消息按时间顺序排列，形成完整的聊天记录：

群聊记录每一条都按时间排好，谁也别想插队——正是这份完整有序的「聊天记录」，让每个 Agent 都能准确理解「我们刚才聊到哪儿了」，也让对话可以随时恢复、随时审计。

Ht=[M1, M2, …, Mt]H_t = [M_1,\ M_2,\ \ldots,\ M_t]
公式含义：到第 t 轮为止，对话历史就是前 t 条消息按序排成的列表；无论哪一方发言，都会追加到列表尾部。
  1. H_t（聊天记录）截至第 t 轮的完整消息序列，是 Agent 感知上下文的唯一来源。
    Ht=[M1, M2, …, Mt]H_t = [M_1,\ M_2,\ \ldots,\ M_t]
  2. M_i（每条消息）第 i 次通信产生的结构化消息，包含发送方、接收方、内容与时间。
    Mi=(si, ri, ci, ti)M_i = (s_i,\ r_i,\ c_i,\ t_i)
  3. 追加规则（增量累积）每轮新消息按序追加到列表末尾，历史永不覆盖。
    Ht+1=Ht∪{Mt+1}H_{t+1} = H_t \cup \{M_{t+1}\}

终止条件：群聊不会永远进行下去

高效的群聊懂得「见好就收」：有人说出「就这么定了」，或者到了下班时间，讨论就该结束。AI 对话也一样，必须明确「什么时候闭嘴」。ConversableAgent 提供了三重「刹车」，防止两个 Agent 在无限循环中烧光你的 Token 预算。

第一重刹车是 is_termination_msg：一个自定义回调函数，每次收到新消息时检查内容，如果判断为「结束语」就返回 True，对话立即终止。第二重是 max_consecutive_auto_reply：限制某个 Agent 在没有人类或其他 Agent 参与的情况下最多连续回复多少次。第三重是 max_turns：整场对话最多进行多少轮，相当于「到点强制散会」。

三种机制可以单独使用，也可以组合成更严格的总闸门。综合判定逻辑如下：

这三重刹车就像一个项目群的「散会规则」：有人拍板就散会（结束语）、没人说话就少说两句（连发上限）、到时间就强制散会（轮数上限）。没有规则的群聊会一直灌水，没有终止条件的 Agent 对同样会无限空转。

Terminate(Ht)=TermMsg(ct)∨(Countconsec≥K)∨(t≥T)\text{Terminate}(H_t) = \text{TermMsg}(c_t) \lor (\text{Count}_{\text{consec}} \ge K) \lor (t \ge T)
公式含义：对话在三种情况下终止——当前消息被识别为结束语、连续自动回复次数达到上限、或总轮数达到上限。
  1. TermMsg（结束语检测）调用 is_termination_msg 判断当前消息是否包含终止信号。
    TermMsg(ct)→{True, False}\text{TermMsg}(c_t) \to \{\text{True},\ \text{False}\}
  2. Count\_consec（连发计数）统计没有人类介入的连续自动回复次数。
    Countconsec=#{consecutive auto replies}\text{Count}_{\text{consec}} = \#\{\text{consecutive auto replies}\}
  3. K（连发上限）max_consecutive_auto_reply 设置的门槛，超过即触发刹车。
    Countconsec≥K\text{Count}_{\text{consec}} \ge K
  4. t ≥ T（轮数保险丝）max_turns 设置的整场对话最大轮数，兜底保证一定结束。
    t≥Tt \ge T

人类输入集成：老板什么时候该发言

项目群里最怕两种极端：老板一句话不说，AI 完全失控；或者每句话都要 @ 老板，讨论寸步难行。合理的方式是「平时 AI 自己讨论，关键时刻老板拍板」。这正是 human_input_mode 参数的设计哲学，它控制 Agent 在生成回复前是否征求人类意见，有三个档位。

NEVER 表示从不询问，Agent 完全自主对话，适合可审计的多轮自动化流程；ALWAYS 表示每次回复前都暂停，等待人类输入，适合人机协同的创作场景；TERMINATE 是折中方案——平时让 AI 自由交流，只有在对话即将触发终止条件时，才把决定权交给人类做最终裁决。

三种模式下，第 t 轮回复的生成者可以用公式表达：

好的管理者懂得「授权」——让能干的员工自己推进，只在里程碑节点把报告递到老板桌上。TERMINATE 模式就是这种「里程碑汇报」的数字化实现。

rt={LLM(Ht)NEVERHuman(Ht)ALWAYSLLM(Ht) or Human(Ht)TERMINATEr_t = \begin{cases} \text{LLM}(H_t) & \text{NEVER} \\ \text{Human}(H_t) & \text{ALWAYS} \\ \text{LLM}(H_t) \ \text{or} \ \text{Human}(H_t) & \text{TERMINATE} \end{cases}
公式含义：NEVER 模式下回复由大模型全程生成；ALWAYS 模式下人类直接产出回复；TERMINATE 模式平时由大模型发言，但当终止信号出现时，是否结束由人类拍板。
  1. LLM(H_t)（AI 发言）大模型基于聊天记录生成回复文本。
    LLM:Ht↦ct\text{LLM}: H_t \mapsto c_t
  2. Human(H_t)（人类发言）人类查看聊天记录后手动输入回复内容。
    Human:Ht↦ct\text{Human}: H_t \mapsto c_t
  3. 决策边界（TERMINATE 语义）仅当终止条件将被触发时，把回复权交接给人类裁决。
    Term(Ht)⇒Human(Ht)\text{Term}(H_t) \Rightarrow \text{Human}(H_t)

角色与个性定制：给每个 AI 一张立体名片

同样一句话，产品经理说出来和工程师说出来味道完全不同。群成员能「演好自己的角色」，靠的是进群时那份清晰的人设约定。ConverterableAgent 的角色定制，最核心的就是 system_message——一段加在模型上下文最前面的人设提示语，告诉 LLM「你是谁、你的职责、你的说话风格」。

除了人设，还可以给 Agent 注册工具函数，让它能查询数据库、调用外部 API；可以配置代码执行容器，让它在沙箱里运行代码验证方案；更灵活的玩法是嵌套对话——让 Agent 一对一私聊拿到结论后，再回到主对话中汇报，就像员工私下对齐后回到大群发言。

无论哪种定制方式，底层的数学逻辑都一样：回复的生成不再是「大模型看聊天记录自由发挥」，而是「带着人设卡看聊天记录」。生成概率可以写作：

人设卡就是群成员头像下那行签名——「产品经理小林」和「工程师小张」读着同一份聊天记录，却输出完全不同风格的回复。角色定制让多 Agent 协作有了「分工」的根基。

P(ct∣Ht, Ss)=LLM(Ht∪{Ss})P(c_t \mid H_t,\ S_s) = \text{LLM}(H_t \cup \{S_s\})
公式含义：Agent 的回复不仅取决于聊天历史，而是「聊天历史 + 自己的人设卡」共同决定——人设卡越清晰，角色行为越稳定。
  1. S_s（人设卡）Agent s 的 system_message，是角色定制的灵魂。
    Ss∈PromptS_s \in \text{Prompt}
  2. Context（上下文拼接）系统提示语放在对话历史的开头，约束后续所有回复。
    Context=[Ss, M1, M2, …, Mt]\text{Context} = [S_s,\ M_1,\ M_2,\ \ldots,\ M_t]
  3. P(c_t)（生成概率）模型根据完整上下文输出下一段文本的概率分布。
    P(ct∣Context), ct+1∼PP(c_t \mid \text{Context}),\ c_{t+1} \sim P

多Agent群聊编排：从一对一私聊到全员大会

两人私聊能解决部分问题，但真正复杂的项目需要全员大会——产品、研发、设计、测试一起碰头。AutoGen 用 GroupChat 实现了这种「全员群聊」：所有 Agent 的消息汇入同一个共享列表，所有成员都能看到完整讨论。

群聊的运转离不开一个「群主」——GroupChatManager。它不负责产生内容，只负责「点名」：从成员集合中选出下一个发言人。被点名的 Agent 基于共享历史生成消息，消息进入群记录后，管理员再次点名，如此循环。选择策略可以是简单的轮流发言（round robin），也可以让 LLM 根据讨论进度智能决定「该谁说话」了。

下一轮发言者的决策过程可以抽象为：

群聊管理器像一个高效主持人：先让产品经理说需求，再点名工程师给方案，最后叫测试同学评估风险——每个人在合适的时间发言，讨论有序推进，最终产出一份没人吵架的完整方案。

st+1=Manager(Ht, S)s_{t+1} = \text{Manager}(H_t,\ S)
公式含义：Manager 拿着完整聊天记录和成员名单，选出一个 Agent 作为下一个发言者——这就是群聊编排的核心决策。
  1. S（成员集合）GroupChat 中全部 Agent 的集合，是候选发言人的池子。
    S={A1, A2, …, An}S = \{A_1,\ A_2,\ \ldots,\ A_n\}
  2. Manager（点名函数）根据调度策略，从成员集合中挑选一个下标。
    Manager:(Ht, S)↦i∈{1..n}\text{Manager}: (H_t,\ S) \mapsto i \in \{1..n\}
  3. s_{t+1}（下一发言人）被选中的 Agent 成为第 t+1 条消息的发送方。
    st+1=Ais_{t+1} = A_i

AI 应用场景

智能客服多部门协办

阶段：多智能体对话编排

解决的问题：传统客服系统用「意图识别 → 标准话术」的单点应答，遇到跨部门复杂问题（退款 + 物流 + 优惠券）时无法整合多方信息，只能让用户反复转人工，体验差、成本高。

具体案例：某电商平台部署三个 ConversableAgent：前台接待 Agent、售后 Agent、物流 Agent。用户问「我的退款怎么还没到？」，接待 Agent 先安抚并收集订单号，然后发起一个 GroupChat，把售后 Agent（查退款状态）和物流 Agent（查拦截信息）拉进来交换信息，最后汇总成一句完整答复。整个流程就像一个客服组长拉了个内部小群讨论后再统一回复客户。

自动化代码评审流转

阶段：多 Agent 协作 + 角色定制

解决的问题：传统代码评审依赖人工同步评审人与被评人时间，轮转慢、标准不统一，重要检查项容易被遗漏。

具体案例：开发提交代码后，评审机器人自动把代码片段分发给三个 Agent：架构师 Agent 评审设计合理性、安全 Agent 扫描漏洞、测试 Agent 生成测试建议。三者通过 GroupChat 交换意见，最终由评审机器人生成综合报告并 @ 对应责任人。终止条件设为「所有评审 Agent 都回复『通过』」。

数据分析报告生成流水线

阶段：对话会话 + 人类输入集成

解决的问题：传统数据分析报告流程冗长——取数、分析、写报告、人工改稿，每个环节都要人工切换工具，一个口径错误就全盘重来。

具体案例：业务方提出「分析近三个月用户留存」，数据 Agent 先从数据库取数并生成图表，分析 Agent 解读数据规律，撰写 Agent 把结论写成周报。分析师用 human_input_mode="TERMINATE" 全程旁观，只在最终报告定稿前介入修改统计口径。

Python 演示

python49 行
"""AutoGen ConversableAgent 双 Agent 对话协议演示"""from autogen import ConversableAgent llm_config = {    "config_list": [        {"model": "gpt-4o-mini", "api_key": "YOUR_API_KEY"}    ]}  def is_termination_msg(msg):    """当消息包含'完成'时，判定为结束语，终止对话"""    return "完成" in (msg.get("content") or "")  product_manager = ConversableAgent(    name="产品经理小林",    system_message=(        "你是产品经理小林，负责把需求讲清楚，"        "询问工程师方案可行性，最后确认方案。"    ),    llm_config=llm_config,    human_input_mode="NEVER",    is_termination_msg=is_termination_msg,    max_consecutive_auto_reply=2,) engineer = ConversableAgent(    name="工程师小张",    system_message=(        "你是工程师小张，收到需求后评估可行性，"        "给出实现方案，最后以'完成'结束对话。"    ),    llm_config=llm_config,    human_input_mode="NEVER",    is_termination_msg=is_termination_msg,    max_consecutive_auto_reply=2,) result = engineer.initiate_chat(    product_manager,    message="我们想给电商App加一个智能推荐功能，请明确需求。",    max_turns=6,) print("对话总消息数:", len(result.chat_history))for message in result.chat_history:    sender = message.get("name", message.get("role"))    print(f"[{sender}] {message['content']}")
目的：演示如何使用 AutoGen 的 ConversableAgent 搭建「产品经理 + 工程师」双 Agent 对话协作流程，并展示终止条件、人设定制与消息历史的使用方式。
  1. from autogen import ConversableAgent导入 AutoGen 核心的「可对话智能体」类，这是我们要用的数字员工模板。
  2. def is_termination_msg(msg)定义「散会暗号」识别函数：一旦消息里出现「完成」二字，就触发终止条件。
  3. "完成" in (msg.get("content") or "")从最新消息的正文中查找关键词，返回布尔值供调用方判断。
  4. product_manager = ConversableAgent(...)创建产品经理 Agent，把「人设卡」和「自主度」通过构造参数一次性绑定。
  5. system_message=(...)设置人设提示语，相当于给数字员工贴上一张「角色名片」。
  6. human_input_mode="NEVER"全自动模式，AI 自己讨论，不打断人类。
  7. is_termination_msg=is_termination_msg挂载自定义终止条件，让对话在见到结束语时自动收尾。
  8. max_consecutive_auto_reply=2限制同一 Agent 最多连续自动回复 2 次，防「自言自语」。
  9. engineer.initiate_chat(...)工程师发起对话，把第一个话题抛给产品经理，并限制整场最多 6 轮。
  10. max_turns=6设定对话轮数保险丝，即使没有触发结束语也会强制收场。
  11. result.chat_history会话结束后获取完整聊天记录，用于审计和展示。
  12. message.get("name", message.get("role"))从结构化消息中安全地取出发送者名字，拿不到时回退到角色字段。

常见误区

误区很多初学者以为创建一个 ConversableAgent 就会自动获得智能，不需要配置大模型。但实际上不传 `llm_config`，它连一句话都说不出来。

正解ConversableAgent 本身是「对话协议的执行框架」，真正的大脑来自底层 LLM。它就像微信群聊框架本身不产生观点，群里发言的人（大模型）才有想法。Agent 的职责是组织对话流程、管理消息、控制节奏，而不是自己「想」出答案。

为何常见：ConversableAgent 名字听起来像「智能体」，加上文档中总是配合 GPT 一起出现，容易让人产生「它自带智能」的错觉。

误区「max_turns=10 就代表一共只能对话 10 轮吧？那 max_consecutive_auto_reply=3 又是什么？」很多人在配置时把这两个参数当同一个东西。

正解max_turns 指「这个会话最多进行多少轮交替」，是整场会议的时长限制；max_consecutive_auto_reply 指「某个 Agent 在没有人类或其他 Agent 介入时，最多连续自动回复几次」，是单个人连续发言的限制。就像群里「总讨论时长」和「某个人最多连发几条消息」是两回事。

为何常见：两个参数都带「限制数字」的语义，且作用位置相近，写代码时很容易张冠李戴。

误区「NEVER 就是把人锁在门外，AI 全自动搞定一切，人类永远插不上话。」这是对参数名的望文生义。

正解NEVER 只是「AI 不会主动停下来询问人类」，但代码层面仍可通过外部工具回调、消息注入等方式在对话流中加入人类指令；而且人类可以在对话结束后查看完整记录做最终裁决。它管的是「主动询问」这件事，不是「彻底隔绝」。

为何常见：NEVER 这个词太绝对，容易让人以为这是一道不可跨越的铁墙。

误区以为 GroupChat 像真实微信群一样异步，大家同时噼里啪啦发消息，群聊管理器只管收集。

正解AutoGen 的 GroupChat 是「单工轮转」的：管理器从成员中挑一个发言者，其他人保持沉默；消息进入共享历史后，管理器再选下一个。整个过程是回合制的，和线下开会「主持人点名、一人一席话」类似，而不是实时聊天室。

为何常见：生活经验里的群聊是异步并发的，容易先入为主地把现实群聊模型套到代码上。

误区「让两个 Agent 对话，它们聊完自然就停了。」初学者经常不配置任何终止条件，结果对话无限循环，Token 费用飙升。

正解LLM 没有「自觉停止」的本能，只要上下文还有话可接，它就会继续回复。生产环境必须配置 max_turns、is_termination_msg 或 max_consecutive_auto_reply，最好三管齐下，并配合成本监控告警。

为何常见：人类对话天然有社交默契知道何时收场，但机器没有这种默契，需要人为编写「散会规则」。

面试题

Q1. 下列关于 ConversableAgent 的设计核心，正确的是？

单选题 · easy

  • A.通过对话协议交换消息完成协作← 正确答案
  • B.通过共享数据库同步内部状态
  • C.通过读写本地文件进行通信
  • D.通过共享内存完成并行计算

答案：A。ConversableAgent 的灵魂是「对话协议」：所有协作都通过结构化消息一来一往完成。就像项目群里靠聊天推进工作，而不是靠改数据库。B/C/D 描述的都是其他协作范式，与 AutoGen 的对话模型不符。

Q2. human_input_mode="NEVER" 的直接效果是？

单选题 · easy

  • A.人类彻底无法参与整个对话
  • B.Agent 不会主动征求人类输入← 正确答案
  • C.对话内容对用户完全不可见
  • D.大模型停止生成任何回复

答案：B。NEVER 只表示「AI 不会主动停下来问人」，不表示人类被隔绝——仍可外部注入消息，结束后也能查看记录。这就像老板说「你们自己讨论，别 @ 我」，但必要时仍可以插话。

Q3. 以下哪个不是 ConversableAgent 的必备配置？

单选题 · easy

  • A.system_message 角色人设提示
  • B.llm_config 大模型连接参数
  • C.内置数据库存储引擎← 正确答案
  • D.human_input_mode 介入模式

答案：C。name、system_message、llm_config、human_input_mode 是四大核心配置；数据库存储引擎不在其中，ConversableAgent 本身不强制存储数据。它更像个「对话协调器」而不是「数据库」。

Q4. is_termination_msg 回调返回什么值时会终止对话？

单选题 · mid

  • A.返回 False 时正常继续对话
  • B.返回 True 时终止当前对话← 正确答案
  • C.返回空字符串时立即终止
  • D.返回整数 0 时终止对话

答案：B。is_termination_msg 是一个布尔判定回调，返回 True 表示「这条消息是结束语」，对话立刻终止。就像群里有人发了句「散会」，大家就停止讨论——是 True 还是 False，不是字符串或数字。

Q5. 消息结构 M=(s,r,c,t) 中 r 代表什么？

单选题 · mid

  • A.消息的发送方 Agent 身份
  • B.消息的目标接收方 Agent← 正确答案
  • C.消息正文的文本内容
  • D.消息产生的时间序号

答案：B。四元组中 s 是 sender（发送方）、r 是 receiver（接收方）、c 是 content（内容）、t 是 timestamp（时序）。r 相当于群消息里的「@谁」，指明了这条消息讲给哪个 Agent 听。

Q6. 关于 max_consecutive_auto_reply 的说法，正确的是？

多选题 · mid

  • A.限制单个 Agent 连续自动回复次数← 正确答案
  • B.可配合结束语识别共同使用← 正确答案
  • C.数值越大越容易无限对话← 正确答案
  • D.与对话轮数上限含义完全相同

答案：ABC。max_consecutive_auto_reply 限制单个 Agent 在无人介入时连发的次数，数值越大，循环风险越高，因此可以调小来兜底；它能和 is_termination_msg 组合成多重刹车。D 错在它与 max_turns 是不同维度——一个管单人的连续发言，一个管整场轮数。

Q7. GroupChatManager 的核心职责是？

单选题 · hard

  • A.生成所有 Agent 的回复内容
  • B.决定下一个发言的 Agent← 正确答案
  • C.存储全部大模型权重
  • D.编译对话消息成二进制

答案：B。GroupChatManager 是「群主」角色，负责从成员集合中选下一个发言人，维护群聊秩序，而不是自己生成内容。就像会议主持人负责点名，不负责替每个人发言。

Q8. 以下哪些配置可以防止对话无限进行？

多选题 · mid

  • A.is_termination_msg 结束语识别← 正确答案
  • B.max_consecutive_auto_reply 上限← 正确答案
  • C.max_turns 对话轮数上限← 正确答案
  • D.system_message 角色人设

答案：ABC。前三项是三重刹车：结束语识别靠内容判断、连发上限防自言自语、轮数上限兜底。system_message 只是定义人设风格，不参与终止判定，就像名片写得再详细也不会让会议自动散场。

Q9. 以下哪些属于 ConversableAgent 角色定制手段？

多选题 · hard

  • A.自定义 system_message 角色人设← 正确答案
  • B.注册工具函数供 Agent 调用← 正确答案
  • C.配置代码执行容器运行代码← 正确答案
  • D.修改 llm_config 的 API 地址

答案：ABC。人设卡、工具注册、代码执行都是让 Agent「更像某个角色」的手段——既能说人话，也能动手干活。修改 API 地址只是换了模型连接，不改变角色行为，就像换了个手机号不改变说话风格。

Q10. 在嵌套对话中，内层对话的总结通常用于什么？

单选题 · extreme

  • A.覆盖外层对话的全部历史
  • B.作为外层对话的一条消息← 正确答案
  • C.直接删除外层对话记录
  • D.关闭外层所有 Agent

答案：B。嵌套对话（nested chat）是让 Agent 先私聊拿到结果，再把总结作为一条消息返回外层对话。这就像员工私下对齐后回到大群汇报结论——内层结论成为外层上下文的一部分，而不是覆盖或删除外层历史。