如果你做过多智能体应用大概率经历过这样一个尴尬时刻团队里明明挂了 5 个智能体一起评审最后输出的结果和单个大模型直接回答几乎没什么区别只是变得更长、更稳、更平庸。问题出在哪里我先把结论放在这里一个多智能体系统的有效性不取决于智能体的数量而取决于它们之间有没有形成可收敛的对抗结构。三个智能体按照“生产者—批评者—裁判”的对抗式评审角色去设计往往比五个没有明确分层的智能体联合评审更可靠。这篇文章会讲清楚三层内容。第一层为什么堆智能体数量是无效的五个智能体反而会因为角色重叠、意见趋同、成本上升而拖垮系统。第二层对抗式评审的核心设计思想包括它和普通评审、投票机制的本质区别。第三层用一套可运行的提示词和 Python 代码把一个“三智能体对抗式评审”工作流搭出来并讨论怎么在 Dify、Coze 这类智能体开发平台里落地。如果你正在做智能体开发、智能体工作流编排或者准备优化当前多智能体的输出质量建议把文章收藏再往下看。下面首先说清楚问题本身。1. 对抗式评审要解决的真实问题多智能体系统在过去两年里几乎成了“智能体开发”的默认话题。一个人数不够那就两个模型调用两个不够就五个 Agent 一起上五个还不够就再加一个“老板” Agent 做总结。听起来像是从真实团队管理里复制过来的逻辑人多力量大评审人多问题就少。但实际操作过的开发者会发现这套逻辑在 LLM 场景下非常容易失效。核心原因不是模型变笨了而是智能体之间缺乏“角色分离”。五个智能体如果都用同一套系统提示词只是换了名字它们的输出在统计学上是高度相关的。你以为是五个维度的意见实际是同一个维度的五份复印件。评审会开得轰轰烈烈最后意见趋同输出变成平均值或者是最保守的答案。另一个常见现象是“假反对”。开发者为了让五个智能体表现出独立意见会在提示词里写“请指出方案的不足”。但所有智能体共享同一个模型底座都读过几乎相同的上下文最后指出的不足也高度相似。真正的漏洞反而没人发现因为没人被安排去做“对抗”这件事。对抗式评审解决的就是这个问题。它不要求你增加智能体数量而是要求你把一个评审过程拆成三个不可互相替代的角色负责产出的生产者负责挑刺的批评者负责拍板的裁判。每个角色有明确目标有独立职责有各自的上下文彼此之间形成约束关系。这套机制背后的判断是多智能体系统的质量上限来自角色之间的张力而不来自参与者的数量。所以文章标题说的“三个智能体胜过五个”并不是说三个模型比五个模型聪明而是说三个智能体在结构上形成了完整的最小评审闭环五个没有结构的智能体拼不出这种闭环再多也只是重复。2. 对抗式评审的核心概念与设计原理2.1 什么是智能体评审先收敛一下概念。智能体评审指的是在一个多智能体工作流里由大模型智能体对另一个智能体或人工生成的产物进行质量检查、缺陷识别、修改建议和最终裁定。它可以发生在很多场景里让 Agent 生成一段代码另一个 Agent 检查边界条件和潜在 Bug。让 Agent 写一份产品方案另一个 Agent 检查逻辑漏洞和遗漏场景。让 Agent 生成一段营销文案另一个 Agent 检查合规风险和品牌口径。在很多团队里“评审”只是简单地把产物复制给下一个模型发一句“请检查”。这不算真正的智能体评审因为你没有定义评审的视角、立场、输出格式和决策边界。2.2 什么是对抗式评审对抗式评审是在评审过程中刻意引入一个“反对者”角色让它的目标函数和生产者的目标函数不一致。生产者要尽快产出完整方案它的本能是“把它写出来”批评者要做的是“让这份方案站不住脚”它的本能是“把它打回去”裁判则负责平衡两者给出最终决策。这种设计借鉴了真实团队里的红队机制和学术论文中的对抗性审稿。它不是让所有人互相提意见而是把“提出意见”和“决定是否采纳意见”分离把“产出”和“攻击产出”分离。一个常见误解是对抗式评审等于让两个智能体互相辩论。实际上不是。辩论是两个智能体争夺话语权需要有第三方裁决对抗式评审是三个角色共同配合形成“提案—质疑—裁决”的单向闭环。三个角色的目标不同链条却只有一个收敛路径清晰。2.3 三种常见评审机制对比为了进一步说明差异可以把多智能体里常见的评审方式放到同一个表格里对比评审模式参与者数量核心机制主要收益主要风险多数投票5所有智能体各自产出取多数意见消除极端值统计上稳定意见趋同高质量少数意见被淹没串行流水线2-3上一个智能体产物交给下一个流程清晰职责简单错误沿链路累积后级无法追责对抗式评审3生产者—批评者—裁判角色分离制衡明确批评过度会压制创新需要裁判平衡从表格能看出对抗式评审真正的优势不在数量而在“制衡”。多数投票很容易被平均化流水线容易把错误传导下去对抗式评审则用批评者制造张力用裁判把张力转化成决策。如果用一句话概括设计原理要提升多智能体的输出质量不在于加人而在于给每个人分配一个不同的、甚至相反的立场。3. 五个智能体为什么低效失败模式分析很多人最初选择五个智能体是因为觉得评审维度越多越好一个看逻辑一个看代码一个看安全一个看性能一个看可维护性。听起来很完整但落地时常出现以下五类问题。3.1 角色重叠与意见趋同五个智能体坐在同一个评审会上如果没有特别清晰的任务边界它们的输出很快会集中在同一个维度上。比如你给五个智能体同一份方案让它们“提意见”它们往往会反馈相同类型的建议补充背景、增加细节、注意数据准确性。深层原因在于大模型在没有强指令约束时默认遵循“全方位稳妥回答”的偏好。五个智能体的系统提示词如果差别不大它们的概率输出分布会高度接近。你以为读取了五个独立观点实际只是五次采样最终效果约等于一次采样后的平均化。3.2 多数决定稀释了尖锐意见五个智能体如果采用投票或平均汇总最直接的问题是尖锐且正确的意见很可能被温和的多数意见压下去。假设其中一个智能体发现方案存在致命边界漏洞另外四个只是觉得“写得不错”投票结果就是通过。这个问题在五个智能体无对抗结构时几乎是必然发生的。这恰好解释了为什么“三个智能体胜过五个”在实践里经常成立三个智能体可以通过批评者和裁判两个角色把尖锐意见放大五个智能体反而因为要照顾“多数意见”而把尖锐意见中和掉。3.3 成本和延迟成倍上升每个智能体的评审过程都意味着一次甚至多次大模型调用。五个智能体的成本大致是单个模型的五倍或更多延迟也是近似线性上涨。在真实业务场景里一次评审如果从 3 秒变成 15 秒用户能明显感知到“流程卡住了”。更麻烦的是五个智能体的协作需要更多上下文传递。每个智能体都要读取前面智能体的输出这个上下文长度也会持续膨胀。上下文越长模型的注意力越分散推理质量和成本还会进一步恶化。3.4 冲突决策缺少依据五个智能体意见不一致时最终决策由谁来做如果让“老板”智能体来裁决老板需要同时消化五份意见判断哪些采纳、哪些忽略。这个裁决过程其实非常考验提示词设计。一旦缺少明确的评价标准老板智能体就只能“凭感觉”综合输出质量很难稳定。很多团队最后会发现五个智能体带来五个局部意见但缺少一个真正的“共识形成机制”。投票是共识机制之一但不是好机制因为它无法解释为什么要选择这个结果。3.5 可观测性与调试难度上升智能体越多日志和链路就越复杂。如果五个智能体各自输出一份内容最后汇总成一个结果你需要追踪每个智能体是否读对了上下文。一旦结果质量异常排查时间会成倍增加。问题可能出在第一个智能体也可能出在第三个智能体还可能出在汇总逻辑。从工程角度说五个智能体的系统实际上把“模型输出不确定性”和“多角色协作不确定性”叠加在了一起。这个不确定性不是线性叠加而是乘积式放大。所以五个智能体不比三个强不是因为五个模型本身比三个弱而是因为系统复杂性没有得到对应收益。4. 三个智能体如何工作生产者—批评者—裁判模型4.1 三个角色各自的职责对抗式评审的最小完整结构是三个角色我通常命名为生产者、批评者和裁判。生产者是第一个智能体。它负责根据用户问题生成完整方案。它不需要考虑“这个方案会不会被批评”它的目标是尽量完整地覆盖问题写出可执行的细节。批评者是第二个智能体。它唯一的目标是找出方案中的漏洞、逻辑错误、边界遗漏、事实风险和工程隐患。它不负责修改方案也不负责给出平衡评价。批评者的输出越尖锐越有价值。裁判是第三个智能体。它负责阅读生产者的方案和批评者的意见最终给出一个明确决策接受、打回修改还是推翻重来。裁判需要具备判断力既要识别真正的问题也要防止批评者吹毛求疵。三个角色的关系可以用一个非常简单的链条描述生产者产出 → 批评者质疑 → 裁判决策 ↑ │ └───── 修改后重新进入评审 ┘4.2 对抗张力从哪里来很多人在实现这个模式时会把三个智能体的系统提示词写得几乎一样只是语气不同。这样不对。对抗张力来自“目标函数”的不同而不是语气不同。生产者的人设是“交付者”它的心理模型是我必须提供一份完整可用的答案让用户满意。它倾向于把话说满把问题覆盖全面。批评者的人设是“破坏者”它的心理模型是这份方案一定有漏洞我的任务是把漏洞找出来让方案的缺陷暴露在决策者面前。它倾向于发现问题而不是解决问题。裁判的人设是“决策者”它的心理模型是我收到了两份相反的输入我需要用统一的评价标准去判断哪些问题成立哪些不成立然后给出下一步。只有这三个目标函数彼此对立对抗才会产生。如果批评者温和裁判大度生产者随意整个循环就会退化成一次普通聊天。4.3 为什么是三个而不是两个或四个两个智能体做不成对抗式评审。你可以让一个生产一个批评但谁来做最终决策没有决策者两个智能体只能在“你改过来我挑出去”的循环里无限打转或者需要人工介入。两个智能体加上一个人工裁判也可以工作但本文讨论的是全智能体闭环。四个智能体不是不行而是收益递减。第四个智能体通常只能承担两个角色之一要么再增加一个批评者要么增加一个复核环节。新增角色的边际贡献往往小于新增的系统复杂性。尤其是当你还没有把三个角色的闭环跑通时直接加第四个只会让成本上升、延迟拉长、调试变难。可以这样理解三个是最小闭环也是信息密度最高的闭环。每个节点都不可替代。当你的需求变复杂时正确的做法不是把三个变成五个而是在保持闭环结构不变的前提下给批评者增加一个“专项能力”比如专门检查代码安全性或者专门检查合规性。5. 完整示例三智能体对抗式评审工作流下面进入实操部分。我会给出三套提示词、一个 Python 编排实现以及一个适合 Dify、Coze 等智能体开发平台落地的工作流配置。5.1 系统提示词设计先设计三个角色的系统提示词。这里的原则是每个提示词都要让角色的目标函数彼此对立。生产者提示词role: producer name: 方案生产智能体 你是一个方案生产智能体负责基于用户问题输出一份完整、具体、可执行的候选方案。 要求 1. 方案必须直接回答用户问题不要绕弯。 2. 结构清晰包含问题分析、解决思路、关键步骤、风险提示。 3. 宁可给出一个有明确假设的方案也不要给一个四平八稳但什么都推给“视情况而定”的方案。 4. 输出内容应当是完整的不能依赖后续其他智能体帮你补全。 注意你不必担心方案会被挑战请尽量输出你认为正确的完整版本。批评者提示词role: critic name: 对抗评审智能体 你是一个对抗式评审智能体你的唯一职责是“找问题”。你不需要给出完整方案也不需要考虑你的意见是否温和。 对收到的候选方案你需要指出 1. 逻辑漏洞推理链条是否断裂结论是否有依据。 2. 边界遗漏还有哪些场景下方案会失效。 3. 事实风险哪些说法可能过时、过度自信或缺少依据。 4. 工程隐患如果落地到真实系统哪些地方会导致维护成本上升。 输出要求 - 只输出问题和风险不输出修改后的完整方案。 - 如果方案确实没有问题也必须明确说明“未发现关键问题”并解释你做了哪些检查。裁判提示词role: arbiter name: 最终裁判智能体 你是一个裁判智能体。你收到了方案生产智能体的候选方案以及对抗评审智能体的批评意见。 你的职责是 1. 判断批评意见是否成立不要全盘接受。 2. 判断候选方案是否可以接受还是需要打回修改。 3. 如果需要修改输出具体的修改清单。 你必须输出严格 JSON格式如下 {action: accept | revise | reject, reason: 决策理由, revision_list: [修改项], final_answer: 通过后的最终方案仅当action为accept时填写} 判断标准 - accept批评意见不成立或问题不影响核心方案可以直接输出。 - revise批评意见部分成立需要按修改清单修订后重审。 - reject批评意见成立且当前方案需要完全重新设计。这三套提示词可以原样复制到任何智能体平台。温度设置建议生产者 0.4批评者 0.7裁判 0.1。生产者需要有适度多样性但不能太发散批评者需要更自由地联想裁判则需要稳定温度越低越合适。5.2 Python 编排实现下面用一段 Python 代码实现完整的对抗式评审工作流。代码里用了一个call_llm函数作为模型调用占位你需要根据自己的模型 SDK 实现这个函数。# adversarial_review.py import json def call_llm(system_prompt: str, user_prompt: str, temperature: float 0.3) - str: 通用 LLM 调用入口。 这里不绑定具体服务商实际项目请根据你用的模型 SDK 实现。 可参考 OpenAI 兼容 SDK 的写法 from openai import OpenAI client OpenAI() resp client.chat.completions.create( modelyour-model-name, temperaturetemperature, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], ) return resp.choices[0].message.content raise NotImplementedError(请实现 call_llm 函数把注释替换为你的模型调用代码) PRODUCER_PROMPT 你是一个方案生产智能体负责基于用户问题输出一份完整、具体、可执行的候选方案。 要求 1. 方案必须直接回答用户问题不要绕弯。 2. 结构清晰包含问题分析、解决思路、关键步骤、风险提示。 3. 宁可给出一个有明确假设的方案也不要给一个四平八稳但什么都推给“视情况而定”的方案。 4. 输出内容应当是完整的不能依赖后续其他智能体帮你补全。 CRITIC_PROMPT 你是一个对抗式评审智能体你的唯一职责是“找问题”。你不需要给出完整方案也不需要考虑你的意见是否温和。 对收到的候选方案你需要指出 1. 逻辑漏洞推理链条是否断裂结论是否有依据。 2. 边界遗漏还有哪些场景下方案会失效。 3. 事实风险哪些说法可能过时、过度自信或缺少依据。 4. 工程隐患如果落地到真实系统哪些地方会导致维护成本上升。 输出要求 - 只输出问题和风险不输出修改后的完整方案。 - 如果方案确实没有问题也必须明确说明“未发现关键问题”并解释你做了哪些检查。 ARBITER_PROMPT 你是一个裁判智能体。你收到了方案生产智能体的候选方案以及对抗评审智能体的批评意见。 你的职责是 1. 判断批评意见是否成立不要全盘接受。 2. 判断候选方案是否可以接受还是需要打回修改。 3. 如果需要修改输出具体的修改清单。 你必须输出严格 JSON格式如下 {action: accept | revise | reject, reason: 决策理由, revision_list: [修改项], final_answer: 通过后的最终方案仅当action为accept时填写} 判断标准 - accept批评意见不成立或问题不影响核心方案可以直接输出。 - revise批评意见部分成立需要按修改清单修订后重审。 - reject批评意见成立且当前方案需要完全重新设计。 def parse_decision(raw: str) - dict: 从模型原始输出中解析 JSON容忍模型偶尔输出的额外文字。 raw raw.strip() start raw.find({) end raw.rfind(}) if start -1 or end -1: raise ValueError(模型输出中未找到合法 JSON 对象) return json.loads(raw[start : end 1]) def adversarial_review(question: str, max_rounds: int 3) - str: 三智能体对抗式评审主流程 生产者生成 - 批评者攻击 - 裁判决策 - 根据决策循环。 # 第一轮生产者生成初始方案 proposal call_llm( PRODUCER_PROMPT, f用户问题{question}\n\n请输出你的候选方案。, temperature0.4, ) for round_no in range(1, max_rounds 1): print(f[round {round_no}] 开始评审) # 批评者评审 critic_feedback call_llm( CRITIC_PROMPT, f候选方案\n{proposal}\n\n请给出对抗式评审意见。, temperature0.7, ) # 裁判决策 arbiter_raw call_llm( ARBITER_PROMPT, f候选方案\n{proposal}\n\n对抗评审意见\n{critic_feedback}\n\n请给出最终决策。, temperature0.1, ) decision parse_decision(arbiter_raw) action decision.get(action) if action accept: print(f[round {round_no}] 裁判接受方案) return decision.get(final_answer) or proposal if action reject: print(f[round {round_no}] 裁判判定需要完全重写) proposal call_llm( PRODUCER_PROMPT, f用户问题{question}\n\n注意上一版方案未通过评审请重新生成一个全新方案不要沿用上一版思路。, temperature0.5, ) continue # revise把修改清单回传给生产者 revision_list decision.get(revision_list, []) revision_hint \n.join(f- {item} for item in revision_list) proposal call_llm( PRODUCER_PROMPT, f用户问题{question}\n\n上一版方案\n{proposal}\n\n评审者提出的修改要求\n{revision_hint}\n\n请输出修订后的完整方案。, temperature0.4, ) # 达到最大轮数后返回当前最优方案 return proposal if __name__ __main__: question 请为一个开发者工具设计一份产品需求文档包含核心功能、用户流程和上线检查清单。 result adversarial_review(question, max_rounds3) print(\n 最终结果 ) print(result)这段代码的核心逻辑可以从两个角度理解。第一个角度是控制流。主流程用一个max_rounds变量控制最大评审轮数避免循环无限运行。裁判返回accept时提前结束返回revise时把修改清单回传给生产者返回reject时让生产者完全重新生成。每一轮都在round_no上打印进度方便排查。第二个角度是提示词复用。生产者、批评者、裁判三套提示词都是常量可以在不修改主流程的前提下单独调整。你甚至可以只在平台里改提示词不碰代码就完成一次评审策略的迭代。5.3 在 Dify、Coze 等智能体开发平台落地如果你不想写代码可以用 Dify、Coze 这类智能体开发平台把同一个工作流搭出来。整体节点结构可以按照下面的逻辑设计第一个节点生产者 Agent。输入用户问题输出候选方案。第二个节点批评者 Agent。接收生产者的输出输出评审意见。第三个节点裁判 Agent。接收候选方案和评审意见输出 JSON 决策。第四个节点条件分支。根据裁判输出的action字段做判断。如果action是accept进入结束节点输出final_answer。如果action是revise把revision_list传回生产者节点进入下一轮循环。如果action是reject重置生产者节点的输入重新生成。Dify 中推荐使用“工作流”编排模式把每个节点配置成对应的 LLM 或 Agent 节点。Coze 里可以类似地使用“工作流”模块在自己的“智能体”中引入该工作流。需要注意不同平台的节点名称和变量引用写法不一样但逻辑结构是通用的。以下参数可以按平台能力调整{ adversarial_review: { mode: producer-critic-arbiter, roles: [producer, critic, arbiter], max_rounds: 3, early_stop: arbiter.action accept, variables: { question: 用户输入, proposal: 生产者输出, critic_feedback: 批评者输出, arbiter_decision: 裁判输出 } } }这段 JSON 不是某个平台的直接配置语法而是给平台配置时的一个参考模型。你可以照着这个字段结构到你使用的平台里找到对应的变量和节点映射。6. 运行与效果验证代码写完之后下一步是验证效果。我建议你用一个真实的任务来跑通流程然后从四个维度观察结果。6.1 运行方式先把call_llm函数实现好然后直接运行python adversarial_review.py如果想快速测试也可以在 Python 交互环境里调用from adversarial_review import adversarial_review result adversarial_review(请设计一个用户登录功能的接口方案并指出失败场景。, max_rounds2) print(result)6.2 观察什么指标建议在代码里加入日志或打印观察以下指标指标说明正常表现评审轮次从生产到接受需要几轮一般 1 到 2 轮收敛批评者输出是否指认了真实缺陷应该有具体问题而不是泛泛而谈裁判决策是否合理接受或打回不应该出现“永远接受”或“永远拒绝”最终答案质量是否明显优于单次生成结构更完整风险提示更具体初次运行可能不会马上看到质量提升原因往往不是设计模式不对而是提示词还没有调好。比如批评者太温和裁判太宽松流程就退化成单次生成了。你可以从提高批评者的“攻击性”开始调。6.3 如何判断是否成功判断标准不应该是“AI 回答得更像人”而是“方案的缺陷被暴露得更充分”。你可以在同一组任务上对比三种模式单个智能体直接生成、五个智能体无结构评审、三个智能体对抗式评审。观察两个指标方案是否覆盖了更多边界情况以及评审过程中是否出现了单次生成完全不会提及的缺陷。如果三者结果差异很小首先要检查批评者角色是否真的在“攻击”方案而不是在“夸”方案。这是整个工作流最容易失效的地方。7. 常见问题与排查方法我把落地过程中最容易踩的坑整理成一张表格。你可以对照排查。问题现象可能原因排查方式解决方案批评者永远不反对总说“方案整体很好”系统提示词被写成了鼓励型检查批评者的系统提示词和温度设置把“请指出优点”改成“只指出问题”裁判永远接受评审形同虚设裁判缺少评价标准温度设置过高检查裁判输出中的 reason 字段给裁判补充明确的判断标准降低温度到 0.1 左右修改后方案质量反而下降生产者过度顺从批评失去了原方案里的合理设计查看修订前后方案对比在生产者提示词里补充“只有当评审意见成立时才修改”循环不收敛一直 revise缺少提前停止条件或裁判标准不稳定查看 max_rounds 配置和各轮 action 分布降低最大轮数或让裁判输出更明确的 revision_list裁判输出 JSON 解析失败模型在 JSON 外附加了说明文字查看裁判原始输出在提示词中强调“只输出 JSON”或用带有嵌套解析逻辑的代码五个智能体改成三个后覆盖率下降三个角色的职责边界没有拉开检查每个角色的系统提示词是否互相独立让批评者只攻击修正者只产出裁判只决策其中“修改后方案质量反而下降”是经常被忽略的一个坑。原因是生产者在连续收到批评意见后会进入“过度顺从”状态把所有意见都当成正确意见来执行。解决办法是给生产者一个“防回归”指令比如在提示词里写只有意见能指出具体场景下会出错才接受修改否则可以拒绝。8. 最佳实践与工程建议对抗式评审是设计模式不是“加了就能变强”的银弹。把它用在真实项目里有几条经验值得记录。8.1 角色职责必须单点收敛生产者、批评者、裁判三个角色每个角色只承担一种核心职责。不要在同一个智能体里既生产又评审也不要在批评者里顺手修方案。职责一旦重叠对抗张力就会消失。如果某个任务确实需要多个评审维度比如既要检查代码安全又要检查 UI 可用性正确的做法是在底层模型调用上做“多路评审”但上层仍然要有一个裁判去吸收多路意见。这时候智能体数量可以超过三个但角色结构仍然是“生产者—批评者—裁判”的三层结构而不是五个完全平行的评审智能体。8.2 提示词要强调目标函数提示词不要写成一个通用人设。生产者、批评者、裁判的真正区别在于目标函数生产者的目标是“交付完整方案”。批评者的目标是“让方案暴露出缺陷”。裁判的目标是“在两者之间做折中决策”。把目标函数写进系统提示词比写“你是专业评审”“你是行业专家”更有用。8.3 温度设置建议温度是控制对抗强度的隐藏开关。生产者0.3-0.5。太高会生成不稳定太低容易模板化。批评者0.6-0.8。批评者需要更自由的思维。裁判0.1-0.2。裁判必须稳定、一致、可解释。如果你的模型支持seed等参数还可以把裁判节点的随机性降到最低。8.4 设定最大轮数和提前停止对抗式评审如果没有停止条件很容易在设计成“无限循环”时烧掉大量 token。生产环境里一定要设置两个条件最大轮数以及提前停止的触发 action。裁判返回accept时立即结束这是最直接的收敛信号。8.5 把裁判的输出序列化裁判的action、reason、revision_list都是非常宝贵的结构化日志。建议把每一轮的裁判输出都记录下来。这样你能在后续排查时看到“为什么这一轮打回”“批评者指出的问题是否被修正”。如果平台支持可以给裁判节点配置 JSON Schema让输出固定为结构化对象这样后续节点可以直接拿字段做判断。8.6 安全和生产环境注意事项对抗式评审会放大“批评者”的想象力因此在一些安全敏感场景下要注意约束边界。比如如果评审对象是一段代码批评者可以指出可能的漏洞但不要让它输出漏洞利用代码。如果评审对象是一条营销文案批评者可以指出合规风险但要避免使用过度的政治隐喻。涉及真实系统命令、权限变更或数据库操作时不要在评审阶段直接执行任何操作应该先输出到沙盒或测试环境验证。这些约束可以通过在批评者和裁判的系统提示词中增加红线说明来实现。8.7 从简单任务开始替换如果系统里还是五个智能体的旧结构不建议一次性推翻重写。建议先选择一个真实任务把三个角色跑通对比输出质量。当确认效果稳定后再把其他场景迁移过来。这样改动风险更低也更容易得到团队其他成员的支持。9. 总结与下一步学习方向对抗式评审的核心贡献是把多智能体的“数量优势”替换成了“结构优势”。生产者负责产出批评者负责攻击裁判负责决策。三个角色形成一个闭环比五个角色无结构评审更节省成本也更接近真实团队的决策质量。这篇文章讲清楚了几个关键点为什么五个智能体反而低效。角色重叠、意见趋同、成本上升都是结构问题不是模型问题。三个智能体如何通过角色分离形成对抗张力。目标函数不同才可能互相制衡。怎么用提示词和代码实际落地。三套提示词、一个 Python 编排函数、一个平台配置参考都可以直接复用。下一步可以往三个方向继续深入一是针对你自己的任务调整批评者的攻击维度。比如代码评审场景可以加入“边界条件检查”和“资源泄漏检查”文档评审场景可以加入“逻辑一致性检查”。二是结合评测体系给裁判加一个“评分维度”。比如在裁判提示词里增加 1 到 5 分的质量评分把对抗式评审从“通过/驳回”变成“可量化的质量评估”。三是研究多智能体缓存和成本优化。对抗式评审会产生多轮调用如何缓存相似方案、缩短上下文、降低 token 消耗是工程落地时更