1. 项目概述当AI学会“讲段子”社区讨论能带来什么最近在折腾大语言模型LLM应用时我脑子里一直盘旋着一个有点“不务正业”的想法我们总在让AI写代码、做分析、搞创作那它到底能不能真正理解并生成“幽默”不是那种基于模板的冷笑话而是能让人会心一笑甚至需要一点“脑回路”的幽默。这个想法催生了“Multi-Agent Comedy Club”这个实验项目。简单来说我想看看如果让多个AI智能体Agent像喜剧俱乐部的演员和观众一样互动、讨论、甚至“吐槽”它们集体生成的幽默内容会不会比单个AI“闭门造车”更有趣、更贴近人类的幽默感这个项目的核心是探究社区讨论效应对LLM幽默生成的影响。我们不再把LLM看作一个孤立的文本生成器而是将其置于一个模拟的社交环境中。在这里多个具备不同角色如“段子手”、“吐槽者”、“捧哏”、“普通观众”的Agent会围绕一个主题展开多轮对话。它们会提出笑话草稿、进行点评、修改甚至相互辩论某个笑点是否好笑。我的假设是这种多智能体间的碰撞能够模拟人类喜剧创作中的“头脑风暴”和“现场反馈”环节从而引导LLM生成质量更高、更符合社群共识的幽默内容。这不仅仅是关于“讲笑话”。其背后涉及多智能体系统协作、基于反馈的迭代优化、人类幽默的认知建模等多个前沿方向。对于开发者而言理解多Agent如何通过讨论提升特定任务的输出质量可以为构建更复杂、更智能的协作型AI应用如协同创作、集体决策、复杂问题求解提供新的思路。对于普通用户或内容创作者这可能意味着未来能借助AI工具更高效地激发创意产生更“有灵魂”的趣味性内容。2. 核心思路与系统架构设计2.1 为什么选择“多智能体”与“社区讨论”在深入代码之前我们先聊聊为什么这个架构是合理的。传统的单LLM生成幽默通常依赖于精心设计的提示词Prompt例如“请生成一个关于程序员的笑话。” 这种方法存在几个明显瓶颈缺乏迭代生成即结束没有根据反馈进行优化和打磨的过程。视角单一输出完全依赖于单个模型在那一刻的“灵光一现”缺乏不同角度和风格的碰撞。难以评估幽默本身具有极强的主观性单次生成的结果“好不好笑”很难被模型自身量化评估。而引入多智能体和社区讨论正是为了突破这些瓶颈模拟创作流程一个喜剧段子的诞生往往需要写手创作、内部试讲、观众反馈、反复修改。多Agent系统可以自然地模拟这一流程一个Agent负责初稿生成其他Agent扮演同行评审或观众提供“这里包袱没响”、“预期违背不够突然”等具体反馈。引入多元视角通过为不同Agent赋予不同的系统提示System Prompt我们可以让它们具备不同的“人格”或专业背景。例如一个Agent偏重语言双关另一个擅长情景荒谬第三个则专注于情感共鸣。它们的讨论能融合多种幽默范式。实现基于共识的优化讨论过程本身会产生大量的中间文本评论、建议、投票。这些文本可以作为新的上下文引导生成Agent进行下一轮的修改。这种“生成-反馈-再生成”的循环是提升输出质量的关键机制。2.2 系统核心组件设计基于上述思路我设计了一个由四个核心角色Agent组成的“喜剧俱乐部”最小可行系统。每个Agent都是一个独立的、拥有特定指令的LLM调用实例。1. 喜剧作家 (Comedian Agent)职责核心的内容生产者。根据主题生成笑话的初始草稿。系统提示设计要点你是一位专业的喜剧作家擅长观察生活能从平凡事物中发现荒谬和笑点。你的任务是创作简短、精炼的笑话或幽默短句。请避免使用冒犯性、低俗或过于晦涩的梗。你的幽默应该机智、巧妙能让人略加思考后发笑。实操心得这个Agent的提示词需要平衡“创造性”和“约束性”。过于宽泛会导致输出天马行空难以评价过于具体又会限制创意。我通常会加入“避免...”、“倾向于...”这类引导而不是硬性规定。2. 犀利评论家 (Critic Agent)职责扮演挑剔的观众或同行。负责找出笑话中的逻辑漏洞、预期违背不够明显、笑点陈旧等问题并提供具体的修改建议。系统提示设计要点你是一位言辞犀利的喜剧评论家对幽默有着极高的标准和敏锐的洞察力。你的任务是冷静地分析一个笑话的构成它的铺垫Setup是否清晰笑点Punchline是否产生了有效的预期违背语言是否精炼请直接指出弱点并提供1-2个具体的、可操作的修改方向例如“尝试将笑点与更常见的日常场景结合”或“铺垫部分可以更夸张一些以强化对比”。实操心得评论家的有效性直接决定了迭代优化的方向。要让它“批评到点子上”提示词必须引导它进行结构化分析铺垫、笑点、语言而不是笼统地说“不好笑”。3. 氛围组员 (Hype Man Agent)职责扮演积极的观众或捧哏。负责发现笑话中的亮点进行正面强化并可能从不同角度解读笑点增加其层次感。系统提示设计要点你是一位热情洋溢的喜剧俱乐部观众总是乐于发现表演中的闪光点并给予热烈回应。你的任务是欣赏一个笑话指出你认为最巧妙、最有趣的部分并解释为什么这里能引人发笑例如是因为意外的转折、精准的比喻还是情感的共鸣。你也可以尝试为这个笑话补充一个额外的、有趣的背景联想。实操心得这个角色至关重要它避免了系统在负面反馈中陷入“不断否定”的循环。正面反馈能帮助模型理解“什么是对的”从而巩固有效的幽默模式。4. 调解主持人 (Moderator Agent)职责控制讨论流程总结各方意见并最终向“喜剧作家”发出整合后的修改指令。系统提示设计要点你是一位经验丰富的喜剧工作坊主持人。你将收到一个笑话草稿以及来自评论家和观众的反馈。你的任务是1. 简要总结批评和建议的核心点2. 综合正面评价明确需要保留的亮点3. 将这些信息整合成一份清晰、无冲突的修改指南发给喜剧作家进行下一轮创作。请确保你的指南具体、可行。实操心得主持人是多轮对话的“大脑”。它的提示词需要极强的归纳和指令转换能力。测试时我发现如果主持人只是机械罗列反馈效果很差必须让它学会“理解冲突、权衡意见、形成决策”。系统的运行流程是一个清晰的循环初始化用户输入一个主题如“远程办公”。第一轮生成“喜剧作家”根据主题生成笑话草稿Joke_v0。社区讨论将Joke_v0同时发送给“评论家”和“氛围组员”两者独立给出反馈。意见整合“主持人”接收两份反馈进行综合生成修改指南。迭代优化“喜剧作家”根据修改指南和原始草稿生成改进版Joke_v1。循环判断可以设置循环次数如3轮或当主持人判断反馈已充分融合、修改空间不大时停止。输出输出最终版笑话及完整的讨论日志。3. 关键技术实现与核心细节3.1 Agent的具身化提示词工程与角色设定让LLM扮演一个角色远不止是在提示词开头加上“你是一个...”那么简单。关键在于通过细节构建其“认知背景”和“行为模式”。以“犀利评论家”为例一个初级的提示词可能是“你是一个评论家请评价这个笑话。” 这会导致评价空洞无力。我采用的进阶方法是critic_system_prompt 角色你是“冷面笑匠”喜剧杂志的主编以毒舌和精准的行业洞察著称。你评审过上千个投稿深知一个好笑话的骨架。 你的任务分析下方笑话草稿。请按以下结构回应 1. **逻辑连贯性**笑话的铺垫和笑点之间是否存在合理的哪怕是荒谬的联系有没有断裂 2. **预期违背强度**笑点是否足够出乎意料这种“意外感”是来自情节反转、语言双关还是认知失调 3. **语言效率**有没有冗余的词语能否用更少的字表达同样的效果 4. **修改建议必须提供**针对最突出的一个问题给出一个非常具体的修改句子示例。例如如果问题是铺垫太长请直接写出你建议缩短后的铺垫句。 请用严厉但专业的口吻回应。直接指出问题不要客气。 笑话草稿[JOKE_PLACEHOLDER] 为什么这样设计赋予具体身份“杂志主编”比“评论家”更具象暗示了其权威性和经验。结构化输出强制要求按逻辑、预期、语言等维度分析避免了笼统的评价。要求具体示例“给出修改句子示例”是最关键的一步。这迫使LLM不仅指出问题还必须深入文本内部进行“脑补式”修改这种脑补过程蕴含了丰富的、可被生成器学习的模式。定义口吻“严厉但专业”设定了交互的基调会影响生成词汇的选择如使用“冗余”、“疲软”等词使反馈更像来自真人。3.2 讨论流程的编排与状态管理多Agent系统的核心挑战之一是协调与状态管理。我们不能让多个Agent同时七嘴八舌地修改同一份文本。我采用了一种中心化调度、串行讨论的架构。实现方案使用工作流引擎或简单状态机即使是简单的Python脚本也需要明确的状态变量。我通常定义一个全局的discussion_state字典包含current_joke,critique,praise,moderator_instruction,round_number等字段。序列化调用严格按照“生成 - 并行获取评论与赞美 - 整合 - 再生成”的顺序调用API。并行获取反馈时可以使用asyncio或concurrent.futures来同时调用评论家和氛围组员以提高效率。上下文管理每一轮给“喜剧作家”的提示词中都需要包含完整的历史上下文上一版的笑话、主持人的修改指南。这相当于给了它一个“创作笔记”。comedian_prompt_for_round_2 f 你之前的草稿是{previous_joke} 经过俱乐部讨论主持人给出了以下修改意见{moderator_instruction} 请根据这些意见创作一个改进后的新版本。注意保留原有亮点同时针对性解决提到的问题。 主题仍然是{topic} 终止条件我设计了两种终止条件可以结合使用固定轮次简单粗暴如3轮后停止。优点是可控。基于反馈收敛让“主持人”在总结后判断“当前反馈是否已经非常具体且修改意见与上一轮重复” 可以要求主持人输出一个“收敛分数”1-10当分数高于阈值时停止。这更智能但实现更复杂。注意事项必须为每个Agent的对话历史Context做独立管理避免不同角色的指令和对话历史相互污染。一个常见的坑是复用同一个对话ID或列表导致评论家突然以喜剧作家的口吻说话。我的做法是为每个Agent实例维护一个独立的messages列表。3.3 幽默的评估从主观感受到可量化指标如何评估这个系统是否成功“更好笑”是一个主观标准。为了能相对客观地衡量我引入了多层评估体系1. 内部评估基于规则/模型惊喜度Surprise计算笑话笑点部分与铺垫部分的语义向量通过Sentence-BERT等模型获取余弦相似度。相似度越低可能意味着预期违背越大。这只是一个粗糙的代理指标。简洁性Brevity统计字数。在传达相同意图下越短通常越好符合“妙语”的定义。迭代改进度对比相邻两轮笑话的修改幅度。可以使用文本编辑距离Levenshtein Distance或基于嵌入的相似度。健康的迭代应该显示有意义的修改而不是完全重写或毫无变化。2. 外部评估人工评估这是黄金标准。我会设计一个简单的评估界面将单Agent直接生成的笑话和多Agent讨论N轮后的笑话去标识化打乱顺序后呈现给人类评估者。评分从1-5分评价“好笑程度”。偏好测试直接询问“你觉得哪个更好笑”反馈具体性评估者能否从多Agent版本中看出更清晰的构思或更巧妙的转折3. 过程评估讨论质量分析评论家和氛围组员的反馈文本。高质量的反馈应该是具体的、可操作的如“把‘电脑’改成‘996的战友’”而不是模糊的如“不好笑”。共识形成观察多轮讨论中修改建议是否逐渐聚焦。如果每一轮都在讨论全新的、不相关的问题说明讨论是发散无效的。通过结合这些评估我们不仅能判断最终产出是否更好还能诊断整个多Agent协作流程哪里出了问题。4. 实战演练从“远程办公”到一个段子让我们用一个完整的、简化的流程来演示系统是如何工作的。假设我们使用OpenAI的GPT-4系列模型作为所有Agent的底层引擎。初始输入主题“远程办公的尴尬瞬间”第一轮初稿生成喜剧作家输出Joke_v0“远程办公最大的好处就是可以一边开会一边撸猫。直到有一天你的猫跳上键盘在全员会议上按下了‘共享屏幕’键而你的浏览器标签页正开着‘如何偷偷找新工作’。”第二轮社区讨论犀利评论家反馈“1. 逻辑连贯性尚可场景真实。2. 预期违背强度中等。‘共享屏幕’暴露尴尬是常见梗预期违背不够强烈。笑点找新工作与铺垫撸猫的连接可以更意外。3. 语言效率‘你的浏览器标签页正开着...’表述稍显冗长。4. 修改建议尝试将‘找新工作’替换成一个更私人、更瞬间社会性死亡的场景例如‘如何治疗猫毛过敏’与撸猫形成直接矛盾或‘老板穿着玩偶服的照片’与专业会议形成反差。”氛围组员反馈“这个笑话的亮点在于将‘远程办公的随意性’与‘职场隐私的脆弱性’结合得非常巧妙。‘撸猫’这个元素很有共鸣是很好的情感切入点。‘共享屏幕’是每个远程工作者都恐惧的时刻这里能引发强烈的代入感和紧张感而紧张感的突然释放就是幽默的来源。”调解主持人整合“总结笑话基础扎实有共鸣点。主要批评在于笑点标签页内容的意外性不足属于常见套路且语言可更精炼。正面评价认为‘撸猫’和‘共享屏幕’的链接很好。修改指南喜剧作家请保留‘撸猫’和‘误共享屏幕’的核心结构。重点修改浏览器标签页的内容将其替换为一个与‘撸猫’或‘居家’场景产生更强烈、更意想不到矛盾的选项。同时精简描述笑点的句子。”第三轮迭代优化喜剧作家根据指南生成Joke_v1“远程办公让你能边开会边撸猫。直到猫主子帮你按了‘共享屏幕’而你的浏览器正停留在‘如何优雅地告诉同事你刚才说的那个蠢主意是我提的’搜索页。”分析改进Joke_v1将“找新工作”换成了“如何优雅地告诉同事...”。这个修改非常精妙它依然是一个职场尴尬场景保持了相关性。它产生了更强的“预期违背”观众原以为会暴露的是个人隐私找工作结果暴露的是职场人际中的小虚伪甩锅。这种从“对外”到“对内”的转折更细腻、更出乎意料。它与“开会”场景的链接更直接、更紧迫正在进行的会议 vs. 刚才发生的对话。讨论的作用评论家没有直接写出这个句子但它提供了正确的修改方向“更私人、更瞬间社会性死亡”、“与撸猫形成直接矛盾”。喜剧作家在这个方向下结合自己的“创作能力”找到了一个更优的具体表达。氛围组员的正面反馈则确保了“撸猫”这个受欢迎的元素被保留下来。5. 常见问题、挑战与优化策略在实际搭建和运行这个系统的过程中我遇到了不少坑也总结出一些优化策略。5.1 Agent的“人格漂移”与指令遗忘问题在长时间、多轮对话中Agent可能会逐渐忘记自己的初始角色设定开始说一些“不符合人设”的话。例如评论家突然开始自己创作笑话。根因LLM的上下文窗口有限随着对话轮次增加最初的系统提示System Prompt在上下文中的相对重要性下降。同时Agent在交互中可能会模仿其他Agent的说话方式。解决方案强化系统提示在每一轮发送给Agent的指令中都以精简的方式重申其核心角色和任务。例如在给评论家的每一条用户消息前都加上“[角色冷面评论家]”。短上下文策略不要无限制地将所有历史对话都塞进上下文。对于非主持人的Agent其上下文可以只包含其系统提示、当前需要评价的笑话、以及可能的上一条自己给出的反馈用于保持连贯。主持人的上下文需要更长但也要定期清理过于久远的历史。温度Temperature参数对于需要稳定输出的角色如评论家、主持人使用较低的Temperature如0.2使其输出更确定、更少“胡言乱语”。对于创意生成角色喜剧作家可以适当调高如0.7以增加多样性。5.2 讨论陷入循环或僵局问题多轮迭代后笑话文本不再发生实质性变化或者修改总是在几个无关痛痒的词语上打转。评论家反复提出相同类型的批评。根因Agent的“创造力”枯竭或者反馈意见过于笼统无法提供新的优化路径。解决方案引入外部刺激在第三轮或第四轮后可以主动向系统注入新的信息。例如让主持人说“让我们从另一个角度思考试试加入一点‘夸张的比喻’或者‘时代的共鸣’。” 这相当于人类创作中的“换个脑子”。轮换角色提示为同一个职能的Agent准备2-3套略有不同的系统提示词。例如准备一个“擅长语言幽默的评论家”和一个“擅长情景喜剧的评论家”。在每一轮或当检测到僵局时轮换使用不同的提示词以引入新的视角。设置多样性奖励在评估内部指标时加入对“语义新颖度”的考量鼓励生成与之前版本差异更大的文本但要小心避免为了不同而不同损害笑话质量。5.3 成本与延迟控制问题每个笑话都需要调用多次LLM API4个角色 * N轮成本和生成延迟显著高于单次调用。优化策略模型分级并非所有角色都需要使用最强大、最昂贵的模型。例如“氛围组员”的任务相对简单可以使用更轻量、更便宜的模型如GPT-3.5-Turbo。只有核心的“喜剧作家”和需要复杂归纳的“主持人”使用高性能模型如GPT-4。这能大幅降低成本。异步与批处理如前所述将可以并行进行的步骤如获取评论和赞美异步化。如果批量生成多个主题的笑话可以考虑将不同笑话的同一阶段任务批量调用API如果API支持。提前终止实现有效的收敛判断逻辑避免无意义的额外轮次。如果主持人判断修改已足够好或连续两轮修改度低于阈值则提前结束循环。5.4 幽默的文化与语境依赖性问题系统生成的幽默可能严重依赖训练数据中的文化背景对于不同地区、不同年龄段的用户可能失效甚至产生冒犯。应对方法在系统提示中加入文化敏感性约束明确要求避免涉及特定地域、种族、性别、宗教的刻板印象或敏感话题。本地化角色设定可以根据目标受众定制Agent的角色背景。例如为中国用户创作时“喜剧作家”可以设定为“擅长玩网络流行语和段子的脱口秀演员”评论家可以是“混迹于贴吧和微博的资深梗学家”。人工审核与过滤层在最终输出前加入一个基于关键词或轻量级分类模型的过滤层拦截明显不恰当的内容。对于重要应用人工审核仍是必要的。通过这个“Multi-Agent Comedy Club”项目我深刻体会到将LLM从“工具”转变为“协作者”的关键在于设计有效的交互机制和社会性模拟。幽默生成只是一个有趣的切入点其背后关于多智能体协作、基于讨论的迭代优化、复杂创意任务的分解与整合等思想完全可以迁移到代码评审、方案设计、营销文案创作等更广泛的领域。让AI们先“吵一架”或“夸一夸”也许真的能让我们得到更优的答案。