平时我们都在和 AI 进行“一对一”的对话，它彬彬有礼、有问必答。但作为一个爱折腾的程序员，我总在想：如果让两个持相反观点的 AI 互相对话，甚至“吵”起来，会碰撞出什么样的火花？

是会互相吹捧陷入死循环？还是会像人类辩手一样针锋相对？

为了验证这个想法，上周末我开发了一个 

。这个系统由正方、反方和总结官三个 Agent 组成，用户只需抛出一个话题（比如“AI 是否会取代程序员”），剩下的就交给它们自己去“撕”。

我写下来该篇文章，用于复盘我开发过程中的真实路径：设计思路、核心代码实现，以及 Web 接入时踩过的坑。

在动手写代码前，我使用NanoBanana画了个草图。这个系统不像传统的 RAG 或聊天机器人，它更像是一个“编排好的小剧场”。

1.2 架构选型：为什么要选择 openJiuwen？

在 Agent 框架的选择上，我主要对比了 LangChain 和 openJiuwen。

说实话，LangChain 生态虽大，但在做这种自定义控制流时，那种“Chain 套 Chain”的有时候让我调试得很痛苦。对于这个辩论系统，我需要的是

openJiuwen 的优势在于它的声明式风格

，然后把 Agent 像积木一样插进去。它负责管好模型调用和 Prompt 渲染，我负责在 Python 层写 

 循环控制谁先谁后。这种“框架负责能力，我负责编排”的模式，非常适合多 Agent 场景。

这一部分是重头戏。多 Agent 协作的核心不在于代码有多复杂，而在于 

最开始我写的 Prompt 很温和，结果正反方互相客气，简直是商业互吹。后来我迭代了三版，加上了强约束。

# 必须让反方具有攻击性，否则辩论不精彩
con_prompt_template = """
你是辩论赛的反方辩手。你的目标是驳倒正方的观点。

当前辩题：{topic}
当前是第 {round} 轮辩论。

【历史记录】
{history}

【指令】
1. 仔细阅读上方历史记录中正方的最新发言。
2. **必须**引用正方的原话进行反驳，指出其逻辑谬误或证据不足。
3. 语言要犀利、一针见血，不要讲客套话。
4. 控制在 300 字以内。
"""


pro_prompt_template = """
你是辩论赛的正方辩手。请坚定维护你的立场。
当前辩题：{topic}
...
【指令】
1. 立论清晰，多用数据或案例支撑。
2. 如果反方进行了反驳，请在本次发言中通过逻辑回击。
"""


openJiuwen 负责定义 Agent，而 Agent 之间的协作（谁说完轮到谁）我写了一个 

这里我没有使用框架内复杂的 Graph 编排，而是直接用了 Python 的控制流，这样调试最方便。

from openjiuwen import Workflow, Agent, LLM

class DebateOrchestrator:
    def __init__(self):
        # 初始化基础组件
        self.llm = LLM(model="gpt-4o") # 或者使用 openJiuwen 支持的其他模型
        self.history = [] # 所有的辩论历史

    async def run_debate(self, topic: str, total_rounds: int = 3):
        """
        核心调度逻辑：生成器函数，方便 SSE 流式输出
        """
        # 1. 也是最重要的一步：初始化上下文
        self.history = []
        
        yield f"event: system\ndata: 辩论开始，辩题：{topic}\n\n"

        # 2. 循环多轮辩论
        for round_num in range(1, total_rounds + 1):
            
            # --- 正方发言 ---
            pro_prompt = pro_prompt_template.format(
                topic=topic, round=round_num, history=self._format_history()
            )
            # 使用 openJiuwen 的 Agent 执行
            pro_response = await self._run_agent("正方", pro_prompt)
            self.history.append({"role": "正方", "content": pro_response})
            
            # 实时推送到前端
            yield f"event: pro\ndata: {pro_response}\n\n"

            # --- 反方发言 ---
            con_prompt = con_prompt_template.format(
                topic=topic, round=round_num, history=self._format_history()
            )
            con_response = await self._run_agent("反方", con_prompt)
            self.history.append({"role": "反方", "content": con_response})
            
            yield f"event: con\ndata: {con_response}\n\n"

        # 3. 总结
        summary = await self._run_summary(topic)
        yield f"event: summary\ndata: {summary}\n\n"

    def _format_history(self):
        # 将列表格式化为字符串，传给 Prompt
        return "\n".join([f"[{item['role']}]: {item['content']}" for item in self.history])

    async def _run_agent(self, role, prompt):
        # 封装 openJiuwen 的调用
        agent = Agent(llm=self.llm, prompt=prompt)
        workflow = Workflow(agent)
        return await workflow.run()


。正方说完话，必须把这句话塞进 

，反方在生成 Prompt 时，必须把这份 

 喂给它。openJiuwen 的 stateless（无状态）设计其实在这个场景下很舒服，因为状态完全由我在外部控制，不会出现框架内部状态混乱的问题。

三、 Web 接入实战：EventSource 的坑

后端逻辑跑通后，我用 FastAPI 包装了一个接口。

from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()
orchestrator = DebateOrchestrator()

@app.get("/debate/stream")
async def stream_debate(topic: str):
    # StreamingResponse 接收一个生成器
    return StreamingResponse(
        orchestrator.run_debate(topic), 
        media_type="text/event-stream"
    )


这部分是我觉得最值得分享的“血泪史”。

 可能会很长，或者未来要传复杂的配置参数，所以习惯性地把接口定义成了 

# ❌ 错误示范
@app.post("/debate/stream") 


// ❌ 浏览器直接报错
const evtSource = new EventSource('/debate/stream', { 
    method: 'POST', // EventSource 根本不支持配置 method！
    body: JSON.stringify({ topic: '...' }) 
});


结果浏览器控制台一直报连接错误。排查了半小时，翻了 MDN 文档才猛然想起来：

如果你非要用 POST 做流式传输（比如参数真的很多），你有两个选择：

为了保持项目简单，我最终乖乖把后端改回了 

，参数通过 URL Query 传递。一改完，前端瞬间就开始哗哗出字了。

“人工智能该不该有法律权利”

来原图直出看看效果，以下是前两轮的辩论内容：

可以看到，反方不仅反驳了正方的观点，还直接引用了正方的例子进行回击。这就是 Prompt 中加入 

通过这个项目，我对 Agent应用 有了更深的理解。

。在这个项目中，我把 Agent 当作一个个纯粹的函数接口。它的配置很轻，没有多余的样板代码，让我的 Python 胶水代码写得很清爽。

方面，还没有内置像 LangGraph 那样复杂的图状态机。

这个从设计到实现花了约 1 个小时的项目，让我明白了多 Agent 系统的两个设计真理：

如果你也想做类似的尝试，建议先跑通单个 Agent，再考虑多 Agent 的协作。毕竟，

让一个 AI 变聪明很难，但让两个 AI 吵架，真的很有趣。（吃瓜）

不仅是对话：我用运用多 Agent 攒了一个 AI 版“奇葩说”

产品KOL

人工智能

编程语言

架构设计

探索AI多智能体辩论系统开发，通过正方、反方和总结官三个Agent实现自动辩论。采用openJiuwen框架和FastAPI后端，优化Prompt设计让AI针锋相对。分享SSE流式传输、状态管理等实战经验，展示"AI是否该有法律权利"的精彩辩论案例。

聊天机器人

智能体

Python

Agent

JSON

2026新春采购季

ai-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

不仅是对话：我用运用多 Agent 攒了一个 AI 版“奇葩说”

不仅是对话：我用运用多 Agent 攒了一个 AI 版“奇葩说”

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐