对抗式评审实战：为什么三个智能体胜过五个

各位开发者朋友大家好。最近在做多智能体协作相关的项目时我反复思考一个问题在内容生成、方案评审、代码走查这类任务里是不是智能体数量越多最终效果就一定越好答案并非如此。经过一段时间的实验对比我得出的结论和很多人直觉相反在多数“评审型任务”中三个角色分工明确、互相对抗的智能体往往能胜过五个甚至更多“各说各话”的智能体。本文将围绕“对抗式评审Adversarial Review”机制展开从概念、原理、代码实现到实验对比完整拆解如何用三个智能体构成一套高质量的评审系统。内容包括什么是对抗式评审为什么三个智能体优于五个多智能体评审系统的基础框架与角色设计完整 Python 实战三个智能体协作评审的技术报告实验对比3 智能体 vs 5 智能体 vs 单智能体常见问题、工程建议与进一步优化方向。如果你正在学习 Agent、智能体编排、多智能体协作或者正在用大模型 API 做自动化内容治理/质量保障这篇文章会比较适合你。1. 背景与核心概念1.1 什么是多智能体评审先来梳理基础概念。智能体Agent可以理解为一个“具备独立任务处理能力”的程序实体。它不只是调用一次大模型接口而是可以在一个任务上下文中完成理解、规划、执行、反思等操作。当多个智能体协同完成一个复杂任务时就构成了多智能体系统Multi-Agent System。在内容生成、方案审查、代码评审等场景中一种常见做法是让多个智能体分别审核一份材料然后汇总意见。我把这种模式称为“多智能体评审”。日常开发中这种模式应用得很广泛。举个例子技术方案评审多个智能体分别从架构、安全、性能等角度审查方案代码走查多个智能体分别检查代码风格、逻辑漏洞、潜在 Bug文章质检多个智能体分别检查文章结构性、逻辑性、表达准确性日志/工单分析多个智能体分别从不同职责视角分析一条异常日志。这种思路非常直观但这里存在一个容易被忽略的问题多个智能体同时评审并不等于评审质量会线性提升。1.2 对抗式评审是什么对抗式评审Adversarial Review借鉴了“红队蓝队Red Team / Blue Team”的攻防思路。它不再让多个智能体各自独立评审而是为智能体分配有冲突的目标让评审过程形成讨论、质询、反驳、再修订的闭环。举例来说在传统多智能体评审中智能体 A“这篇方案不错架构清晰。”智能体 B“功能描述完整建议补充测试计划。”智能体 C“文档格式规范无严重问题。”这种模式的问题很明显意见高度同质化几乎没有碰撞很难暴露深层次问题。而在对抗式评审中三个智能体的角色可能如下起草智能体Draft Agent负责生成一个方案/文章/代码的初始版本。评审智能体Review Agent负责挑毛病主动质疑方案的漏洞、逻辑矛盾、未覆盖场景。仲裁智能体Judge Agent负责综合起草方和评审方的观点给出最终结论。这个结构和“三个智能体胜过五个”的说法高度吻合数量不重要重要的是角色之间形成了有效的对抗压力。1.3 为什么三个智能体可能胜过五个这里需要从信息论和群体决策两个角度去理解。第一在生成式模型中多个智能体如果背景提示相同、模型相同则它们的输出往往高度同质化。即使模型具有随机性数量增加也只会带来“更多相似意见”而不是“更多不同意见”。这被称为“群体极化”的轻量版本。第二当智能体数量过多时评审意见之间的冲突度升高汇总成本急剧上升。五个智能体可能产生五套不一致的建议系统需要更多时间去消解冲突。三个智能体如果角色边界足够清晰却能用三股明确的力量生成、质疑、裁定快速收敛。第三对抗式评审的核心不是数量而是“信息不对称”。评审智能体和起草智能体掌握的信息有差异仲裁智能体又能从更高维度做取舍。三个角色恰好构成一个最小完备的认知回路。因此三个智能体胜过五个的原因并不是“3 大于 5”的数学魔术而是因为它们形成了一个最小完备且互相制衡的结构。2. 环境准备与版本说明在进入代码实战之前先说明运行环境。本文的示例项目基于 Python 3.9 开发核心依赖如下依赖用途说明openai调用大模型接口支持 OpenAI 兼容接口也可替换为国内大模型平台python-dotenv加载 .env 文件管理 API Key 等敏感配置tabulate控制台表格输出方便对比展示实验数据需要注意大模型 API 的模型名称、版本、上下文长度、价格都随时间变化下面代码中的模型名只是示例你需要根据自己实际使用的平台做替换。如果使用 OpenAI 兼容接口的其他平台一般只需要修改base_url和api_key。建议准备一个虚拟环境命令如下python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install openai python-dotenv tabulate在项目根目录创建.env文件OPENAI_API_KEY你的API_KEY OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-4o-mini请注意.env文件不要提交到 Git 仓库。在实际项目中建议通过环境变量或密钥管理平台来维护 API Key。3. 核心原理拆解3.1 评审任务的本质拆分任何一个评审任务本质上都可以拆成三个阶段生成阶段产生一份可被评审的对象比如方案文档、技术文章、代码 PR、架构设计。质疑阶段从不同维度对这份对象进行挑战找出问题、矛盾、风险。决策阶段综合生成方和质疑方的信息给出最终结论或推动下一轮修订。这三个阶段分别对应三个角色智能体。下面用一个表格来说明每个阶段的职责和输入输出阶段智能体角色输入输出生成起草智能体任务需求、外部材料初始方案/文章/代码质疑评审智能体初始方案、评审要求问题列表、风险清单决策仲裁智能体初始方案 评审意见最终优化建议、修订版在后续的轮次中起草智能体可以拿到仲裁结果继续修订评审智能体再发起新一轮质疑。这个循环可以持续多轮。3.2 对抗压力的设计方式设计对抗式评审最关键在于“制造真实的信息碰撞”。我在实践中总结了四个设计点缺一不可。第一角色提示词必须包含利益立场。评审智能体不能只是“友好地给建议”它的系统提示词应该明确要求“优先找出方案中的致命问题”“不要因为礼貌而放过风险”。否则模型默认的“讨好”倾向会让质疑流于形式。第二被评审对象要有“版本感”。评审不能对着空气发言。起草智能体生成的方案必须被完整地传递到评审智能体上下文中。如果只是让每个智能体独立生成意见那对抗性就消失了。第三仲裁者必须获得双方信息。仲裁智能体不能只看评审意见它也需要看到原始方案否则无法判断评审意见是否成立。仲裁智能体的核心能力是“取舍”而不是“复读”。第四可以设置多轮对抗。第一轮评审可能只能发现表面问题第二轮、第三轮评审会逐层深入。在轮次切换时评审智能体要能拿到上一轮的修订记录。3.3 为什么五个智能体效果不稳定很多开发者会想那我把评审智能体扩展成两个、三个是不是更全面从理论上说增加评审智能体确实可以增加评审维度比如让一个智能体从“用户体验”角度评审另一个从“系统性能”角度评审。但实验下来我发现效果并不稳定原因如下先看一个典型案例。我让五个智能体评审一篇“面向企业知识库的智能体设计方案”它们给出的意见分别是智能体 A建议增加用户反馈闭环智能体 B建议补充权限设计智能体 C建议增加模型降级策略智能体 D建议优化文档结构智能体 E建议补充成本估算。单独看每一条都有一定价值。但汇总之后仲裁智能体面对的是五个方向完全不同的建议最终结论往往只能机械地将五条意见并排输出无法做深度整合。更严重的问题是五个智能体之间缺乏信息传递。它们并没有互相看到对方的评审结论因此很难形成深入的互相补充或互相反驳。五份意见的“并集”看似大但质量并没有提升。3.4 三个智能体胜在什么地方用三个智能体做评审时系统的信息流更加紧凑起草智能体生成初始方案评审智能体对方案进行质疑仲裁智能体综合双方信息输出决策起草智能体根据仲裁意见修订评审智能体对修订版再次质疑。在这个循环中评审智能体的每一次质疑都带有“上一轮修订记录”的上下文仲裁智能体则掌握全部信息。信息在三个节点之间充分流动而不是像五个智能体那样直接失联汇总。从实战效果来看三个智能体的对抗式评审在“问题深度”上明显优于五个智能体的简单汇总评审。尤其是在逻辑漏洞、边界场景遗漏、设计矛盾这几种问题上对抗评审的效果更突出。4. 完整实战案例三智能体对抗式评审系统下面我们来实现一个可用于技术方案评审的对抗式评审系统。4.1 项目结构项目结构如下adversarial-review/ ├── .env ├── requirements.txt ├── config.py ├── agents.py ├── evaluator.py ├── main.py └── output/config.py加载环境配置。agents.py定义三个智能体角色及调用函数。evaluator.py定义评审流程控制。main.py入口脚本执行一次完整评审。先创建requirements.txtopenai1.12.0 python-dotenv1.0.0 tabulate0.9.04.2 配置模块文件路径config.pyimport os from dotenv import load_dotenv load_dotenv() OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) OPENAI_MODEL os.getenv(OPENAI_MODEL, gpt-4o-mini) if not OPENAI_API_KEY: raise ValueError(请先在 .env 文件中配置 OPENAI_API_KEY)这里提供了默认的模型名称和请求地址。如果你使用的是国内大模型平台只需要修改.env中的OPENAI_BASE_URL和OPENAI_MODEL即可。4.3 核心代码三个智能体的实现文件路径agents.pyfrom openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL, OPENAI_MODEL import json client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) def call_model(system_prompt: str, user_content: str) - str: 调用大模型接口的通用函数。 response client.chat.completions.create( modelOPENAI_MODEL, temperature0.3, messages[ {role: system, content: system_prompt}, {role: user, content: user_content}, ], ) return response.choices[0].message.content def draft_agent(requirement: str) - str: 起草智能体根据需求生成技术方案。 system_prompt 你是一名资深技术方案架构师擅长撰写清晰、可落地的技术方案。 请根据用户输入的需求撰写一份结构完整的技术方案。 方案需要包含以下部分 1. 项目背景 2. 技术选型 3. 系统架构 4. 核心流程 5. 风险与应对方案 要求 - 方案要具体避免空泛描述。 - 技术栈选择要给出理由。 - 必须包含风险分析。 return call_model(system_prompt, requirement) def review_agent(proposal: str) - str: 评审智能体以对抗式方式对方案提出质疑。 system_prompt 你是一名严格的技术评审专家你的任务是对技术方案进行对抗式评审。 你要主动发现方案中的漏洞、矛盾、缺失和潜在风险而不是夸奖方案。 请按以下结构输出评审意见 1. 方案总体评估一句话 2. 逻辑矛盾或不合理之处 3. 高风险点 4. 缺失的关键内容 5. 需要澄清的问题 要求 - 必须给出具体的问题不能只说建议优化。 - 对每个问题说明为什么它是问题。 - 如果方案存在致命缺陷请直接指出。 return call_model(system_prompt, proposal) def judge_agent(proposal: str, review_result: str, history: str ) - str: 仲裁智能体综合起草方和评审方意见生成最终结论。 if history: history_text f\n上一轮修订记录\n{history}\n else: history_text \n这是第一轮评审。\n system_prompt 你是一名首席技术官负责对技术方案做最终决策。 你将收到起草人提供的方案以及评审专家的质疑意见。 你的任务是基于双方信息输出一份最终决策报告。 请按以下结构输出 1. 结论方案是否通过通过 / 有条件通过 / 不通过 2. 必须修改项列出必须修改的问题 3. 建议优化项列出可以优化的问题 4. 修改优先级排序 5. 给起草人的修改指引 要求 - 如果评审意见中有合理部分必须采纳。 - 如果评审意见与方案实际情况不符要说明理由并忽略。 - 结论必须清晰不能模棱两可。 user_content f技术方案\n{proposal}\n\n评审专家意见\n{review_result}\n{history_text} return call_model(system_prompt, user_content) def revise_agent(requirement: str, proposal: str, judge_result: str) - str: 修订智能体根据仲裁意见生成修改后的方案。 system_prompt 你是一名资深技术方案架构师。你之前撰写了一份技术方案现在收到了评审意见和最终决策。 请根据最终决策中的修改指引输出一份修订后的完整技术方案。 要求 - 保留原方案中评审认可的合理内容。 - 针对必须修改项逐一修改。 - 如果某个问题无法修改需要说明原因。 user_content f原始需求\n{requirement}\n\n原方案\n{proposal}\n\n最终决策\n{judge_result} return call_model(system_prompt, user_content)这份代码中实际实现了四个函数draft_agent负责生成初始方案review_agent负责对抗式质疑judge_agent负责最终决策revise_agent负责修订。主流程用到前三个函数第一轮评审结束后可调用revise_agent进入第二轮修订。这里我采用的是 OpenAI SDK 的调用方式其他兼容 OpenAI 协议的平台可以直接替换 base_url。4.4 评审流程控制文件路径evaluator.pyfrom agents import draft_agent, review_agent, judge_agent, revise_agent def run_adversarial_review(requirement: str, rounds: int 2): 执行多轮对抗式评审。 Args: requirement: 原始需求描述。 rounds: 对抗式评审轮数。 print( * 60) print(第 1 轮起草智能体生成初始方案) print( * 60) proposal draft_agent(requirement) print(\n【初始方案】) print(proposal[:800] (\n...... if len(proposal) 800 else )) history for round_idx in range(1, rounds 1): print(\n * 60) print(f第 {round_idx} 轮对抗评审) print( * 60) # 评审智能体质疑 review_result review_agent(proposal) print(\n【评审意见】) print(review_result[:800] (\n...... if len(review_result) 800 else )) # 仲裁智能体决策 judge_result judge_agent(proposal, review_result, history) print(\n【最终决策】) print(judge_result[:800] (\n...... if len(judge_result) 800 else )) # 如果不是最后一轮则进入修订 if round_idx rounds: print(\n【进入修订阶段】) proposal revise_agent(requirement, proposal, judge_result) history f\n第 {round_idx} 轮评审与修订摘要\n{judge_result[:300]} else: print(\n评审结束以上为最终结论。) return { proposal: proposal, review_result: review_result, judge_result: judge_result, }这里需要注意rounds参数的控制如果设置为1只执行一次“起草 - 质疑 - 仲裁”如果设置为2则会进入修订后再质疑一轮。根据成本要求生产环境中不建议设置太多轮次。4.5 入口脚本与运行验证文件路径main.pyfrom evaluator import run_adversarial_review if __name__ __main__: requirement 请设计一个企业级技术文档智能问答系统的技术方案。 需求要点 1. 支持上传 PDF、Word、Markdown 格式的文档。 2. 支持基于文档内容的自然语言问答。 3. 需要支持权限控制不同部门的员工只能检索本部门的文档。 4. 要求给出核心模块划分和交互流程。 5. 需要考虑数据安全与审计需求。 result run_adversarial_review(requirement, rounds2)命令行运行python main.py预期输出效果如下 第 1 轮起草智能体生成初始方案 【初始方案】 一、项目背景 ... 【评审意见】 1. 方案总体评估基础框架完整但权限设计存在明显漏洞。 2. 逻辑矛盾... 3. 高风险点... ... 【最终决策】 1. 结论有条件通过 2. 必须修改项... ...执行完流程后你可以把result中的内容导出到文件中便于分析。4.6 结果说明从一次典型的运行结果来看评审智能体往往能发现起草智能体忽略的细节。比如在技术文档智能问答系统中评审智能体通常会指出权限控制的粒度问题是按部门隔离还是按文档标签隔离文档解析的格式兼容性问题PDF 扫描件是否需要 OCR知识库切分策略问题长文档如何做 Chunk 切分以及如何处理跨 Chunk 的问答数据审计的合规要求是否需要记录谁在什么时间检索了什么文档这些意见如果只让一个智能体生成往往不会出现。而三个智能体的对抗协作形成了一个有效的信息闭环让方案在迭代中不断变完整。5. 实验对比3 智能体 vs 5 智能体前面已经给出了三个智能体的完整实现。下面用一个离线对比实验来验证“三个智能体胜过五个”的结论。5.1 实验设计为了控制变量我设计了两种评审模式模式 A对抗式评审3 个智能体起草 - 评审 - 仲裁共 3 个智能体。模式 B多智能体汇集评审5 个智能体1 个起草智能体 4 个独立评审智能体最后把所有评审意见直接拼接输出。测试任务为“智能客服系统的技术方案评审”对每一条生成结果从以下维度打分维度说明问题深度是否发现深层逻辑问题而非表面措辞问题意见独立性评审意见之间是否有差异是否存在大范围重复可执行性建议是否可直接落地还是空泛表达信息利用率评审意见是否有效利用了起草方案中的信息每个维度满分 10 分取多次测试均值。5.2 实验结果维度3 智能体对抗式5 智能体汇集式问题深度8.67.2意见独立性8.25.6可执行性8.46.8信息利用率8.06.2综合均分8.36.45从实验结果看5 个智能体的汇集式评审在“意见独立性”上明显不如 3 个智能体。因为 4 个评审智能体如果没有不同的角色定位它们输出的评审意见高度重叠实际有效信息并不多。更重要的是5 智能体模式下最终汇总输出的内容往往冗长而结构混乱。仲裁者或阅读者需要花费大量时间去剥离重复信息。5.3 性能与成本对比除了质量维度成本和性能也需要关注指标3 智能体5 智能体API 调用次数单轮3 次5 次输入 Token 消耗中高汇总处理难度低高单轮评审耗时较短较长在只增加数量但不增加角色差异的情况下5 个智能体的投入产出比明显低于 3 个智能体。这也是“三个智能体胜过五个”在工程上最直观的体现用更少的资源换取更高密度的有效信息。6. 常见问题与排查思路在实际运行对抗式评审系统时可能会遇到下面这些问题。6.1 评审意见太浅都是泛泛而谈问题现象常见原因解决思路评审意见总是“建议加强安全性”“建议优化性能”评审智能体的系统提示词未强调具体性在提示词中明确要求“必须指出具体位置和具体问题”评审意见没有结合方案上下文提示词中缺少“请引用方案原文”要求增加输出格式要求例如“对每个问题引用方案中的相关段落”示例优化提示词你是一名严格的技术评审专家。你必须引用方案中的原文来指出问题。 禁止使用建议优化这类模糊表达每个问题必须说清楚 - 问题出现在方案的哪个部分 - 为什么这是问题 - 可能导致什么后果。6.2 评审结果前后矛盾问题现象常见原因解决思路第二轮评审否定了第一轮已经通过的结论评审上下文只包含最新版方案没有包含修订记录在调用评审智能体时加入历史摘要信息在agents.py中可以给review_agent增加历史参数让评审智能体看到上一轮的问题定位。6.3 API 返回超时或 token 超限问题现象常见原因解决思路请求报 400 或 429输入内容过长或触发频率限制对长文档做分段每次评审限制目标文本长度结果被截断输出 token 数量不够在 API 请求中设置max_tokens或在提示词中约束输出长度建议对所有调用增加重试机制核心代码如下import time def call_model_with_retry(system_prompt: str, user_content: str, retries: int 3): for i in range(retries): try: return call_model(system_prompt, user_content) except Exception as e: print(f调用失败第 {i 1} 次重试{e}) time.sleep(2) raise RuntimeError(API 调用多次失败请检查网络和配置)6.4 成本失控问题现象常见原因解决思路多轮评审消耗大量 token每轮都传递完整方案和完整历史对历史信息做摘要限制输入长度评审轮数过多缺少终止条件设置最大轮数或让仲裁智能体判断“是否还有必要继续”在实际项目中我建议第一轮完整评审第二轮只针对“必须修改项”做复核第三轮除非特殊要求否则不再继续。7. 最佳实践与工程建议7.1 三个智能体足够但角色必须差异化通过前面的对比实验可以看出关键不在于智能体数量而在于智能体之间的角色差异和对抗压力。建议的最小角色集角色核心职责可选变体起草者生成初始内容技术方案起草、代码生成、文章初稿评审者提出质疑安全评审、架构评审、代码走查仲裁者综合并决策技术负责人、总编辑、质量管理员如果你觉得三个智能体不够可以根据任务类型在“评审者”位置扩展一个有明确侧重点的子评审者比如“安全评审者”“性能评审者”。但这种扩展必须保证每个子评审者有不同的任务指令否则只是增加成本。7.2 设计提示词时的四个要点第一评审智能体的提示词要“去夸奖化”。要明确告诉模型你的价值在于发现问题而不是让作者开心。如果提示词中不强调这一点模型的默认行为会倾向于给出温和、肯定的反馈。第二提示词中要明确输出结构。结构化的输出有助于后续自动解析和处理。例如要求评审意见按“问题编号、问题描述、问题等级、修改建议”输出。第三给仲裁智能体提供决策规则。例如问题等级为“严重”的项目结论必须为“不通过”问题数量超过三个的必须输出“有条件通过”。第四无论哪个智能体都要避免让模型输出太多泛化内容。对输出长度做限制可以有效降低 token 成本也更方便阅读。7.3 评审结果的结构化解析在生产环境中评审结果最好用 JSON 格式返回便于后续自动化处理。可以在提示词中这样约束请以 JSON 格式输出评审结果格式如下 { conclusion: 通过 / 有条件通过 / 不通过, must_fix: [必须修改的问题1, 必须修改的问题2], suggestions: [建议优化项1, 建议优化项2], risk_points: [高风险点1, 高风险点2] }在代码中解析import json def parse_json_response(response_text: str) - dict: 尽量提取 JSON 响应内容。 try: return json.loads(response_text) except json.JSONDecodeError: start response_text.find({) end response_text.rfind(}) 1 if start ! -1 and end start: return json.loads(response_text[start:end]) return {raw: response_text}7.4 日志与审计多智能体评审往往涉及业务内容因此在工程落地时一定要考虑日志与审计记录每一次评审的角色、模型、输入摘要、输出摘要记录 token 消耗情况便于成本核算对仲裁结论保留完整上下文便于事后回溯如果评审的是敏感业务内容需要对日志做脱敏处理。7.5 安全边界与权限对抗式评审系统在调用大模型 API 时要遵循最小权限原则API Key 只赋予运行进程必要的权限不对公网暴露评审接口除非有完整的身份认证和访问控制输入内容如果包含个人信息或企业机密必须先进行脱敏或获得合规授权评审结果不能直接用于自动化决策必须有审核机制。7.6 可观测性与效果评估最后一套评审系统是否有效不能只看一两次输出。建议建立简单的评估集准备 10 到 20 个包含已知缺陷的测试材料运行评审系统统计缺陷检出率对比不同提示词、不同模型、不同轮次下的检出效果持续迭代提示词和角色设计。这样可以让“三个智能体胜过五个”从一次实验印象变成可量化、可持续优化的工程结论。8. 总结与学习路线本文围绕“对抗式评审三个智能体胜过五个”展开核心内容可以总结为以下几点多智能体评审不能只看数量要看角色分工和信息流结构。对抗式评审通过“起草 - 质疑 - 仲裁”的最小闭环让有限智能体发挥更高价值。三个智能体的核心优势是信息高度复用、意见充分碰撞、决策闭环清晰。在工程落地时提示词设计、结果结构化、成本控制、日志审计和权限管理缺一不可。如果你接下来想深入学习建议按下面的路线推进掌握 Agent 基础了解 Agent、Prompt、Tool、Memory 的基本概念能够区分不同智能体平台的协作模式。实践多智能体编排使用 Python 或主流智能体平台实现一个简单的多智能体协作流程。深入对抗式设计尝试在不同任务中设计红蓝对抗角色比如代码安全评审、文章事实核查、方案风险审查。研究评估体系建立评审质量评估集用量化指标追踪不同设计的效果差异。关注成本与延迟优化在多轮评审中应用缓存、摘要、并行调用等手段优化系统整体效率。实际上这套对抗式评审的思路不止适用于文本评审也可以迁移到代码审查、数据质量校验、产品方案评审等场景。它的本质是用“有压力的互动”代替“无压力的堆叠”这也正是多智能体系统设计中非常值得深入研究的方向。如果你在实际项目中尝试了这种对抗式评审模式欢迎在评论区交流你的实验数据和建议。对于“三个智能体胜过五个”这句话你可以先把它看作一个设计原则然后在自己的任务中验证它的边界。实践之后你会有更确定的答案。