三模型辩论式答案校验

原文要点

原模板为免费 n8n 工作流：Chat Trigger 接收问题（可带 domain、maxRounds、maxCycles），GPT 先作答；AWS Bedrock Claude Sonnet 评审并输出以 VERDICT: {…} 结尾的单行裁决，不同意且有剩余轮次则把异议反馈给 GPT 重答，最多 maxRounds（默认 3）；Sonnet 同意或轮次用尽后交 Claude Opus 终审，输出 DECISION: {…}，批准则返回答案，拒绝则 Opus 自己写修正版；拒绝且有 cycle 剩余可把理由送回 GPT 重跑，最多 maxCycles（默认 2）。计数取自节点运行索引，保证循环终止。需 n8n 1.60+ 与 LangChain 节点，三个模型子节点可换成 Anthropic、Gemini、OpenRouter、Azure OpenAI 或本地 Ollama。

这次做成什么

在自有 n8n 上搭建“三模型辩论式答案校验”流程：一个模型起草、一个模型挑错、一个模型终审，练习时用最小配置跑通一轮提问—评审—裁决，并理解轮次/循环计数如何防止死循环。

准备什么

• n8n 1.60 或更高版本，含 LangChain 节点（Chat Trigger、AI Agent）
• OpenAI API 凭据用于起草模型
• AWS 凭据且开通 Bedrock，所在区域可用 Claude Sonnet 与 Opus 聊天模型
• 或替代方案：Anthropic、Google Gemini、OpenRouter、Azure OpenAI、本地 Ollama 任一模型节点
• 三家模型 API 均会产生各自平台调用费用

具体怎么做

1. 导入模板并接入 Chat Trigger

   从 n8n.io 工作流 19828 免费导入模板。入口是 Chat Trigger，先在 n8n Chat 界面发一条测试消息确认流程被触发；后续如需从其他入口触发，可把 Chat Trigger 换成 Webhook 或 Slack 触发器，保持后续节点不变。

2. 为三个角色分别挂模型凭据

   模板里起草（debater）、评审（evaluator）、终审（judge）是三个独立的语言模型子节点：起草节点挂 OpenAI 凭据，评审和终审节点挂 AWS Bedrock 凭据并确认 Sonnet、Opus 模型在你的区域/账户可用。没有 Bedrock 时可直接把这两个子节点替换成 Anthropic/Gemini/Ollama 节点，逻辑不受影响。

3. 理解评审与终审的裁决协议

   评审节点要求模型只回一行以 VERDICT: 开头的 JSON（含是否同意与异议）；终审节点要求回一行以 DECISION: 开头的 JSON（含批准/拒绝及理由，拒绝时附修正版答案）。流程靠解析这两行决定走向：不同意→异议反馈给起草模型重答；拒绝→返回终审自写的修正版。

4. 用测试消息跑通完整链路

   在 Chat 里发送一条带参数的消息：问题、domain（如 security）、maxRounds=2、maxCycles=1。观察节点依次亮起：起草→评审→（若反对）回到起草→终审→输出最终答案。轮次计数来自节点运行索引，即使模型永远不同意也会在 maxRounds/maxCycles 处终止。

5. 核对输出并调整预算

   确认聊天返回的是“经过评审的答案”：被批准时返回起草模型的答案，被拒绝时返回终审模型的修正版并附状态说明。根据成本与质量需要，在消息里调大或调小 maxRounds（默认 3）与 maxCycles（默认 2）。

可直接复制的材料

你是严格的答案评审员。下面是用户问题和另一位模型给出的答案。请批判性检查事实错误、逻辑漏洞、遗漏前提和过度承诺。只输出一行，不要输出其他内容，格式必须是：
VERDICT: {"agree": true/false, "objections": ["若不同意，逐条列出具体异议，每条一句话"]}
如果答案整体正确，agree 为 true 且 objections 为空数组。
用户问题：{{ $json.question }}
待评审答案：{{ $json.draftAnswer }}

你是最终裁判。下面有用户问题、起草模型的最终答案、评审模型的裁决记录。请判断该答案是否可以交付。只输出一行，不要输出其他内容，格式必须是：
DECISION: {"approved": true/false, "reason": "一句话说明理由", "finalAnswer": "若 approved 为 true，原样给出被批准的答案；若为 false，给出你自己撰写的修正版完整答案"}
用户问题：{{ $json.question }}
起草答案：{{ $json.draftAnswer }}
评审记录：{{ $json.verdicts }}

{
  "question": "把 10TB 日志从本地机房迁到 S3，给出一个低停机方案要点",
  "domain": "cloud infrastructure",
  "maxRounds": 2,
  "maxCycles": 1
}

输入与输出示例

本站虚构演示，未实际调用任何模型，输出仅为协议格式示意。

输入

发送测试消息：{"question":"把 10TB 日志从本地机房迁到 S3，给出一个低停机方案要点","domain":"cloud infrastructure","maxRounds":2,"maxCycles":1}

对应输出

一轮示意为：起草模型给出含数据同步、增量复制、切换窗口的初稿；评审节点返回 VERDICT: {"agree": false, "objections": ["未说明回滚方案","未估算带宽与迁移时长"]}；异议回送后起草模型补全；评审再次返回 agree: true；终审节点返回 DECISION: {"approved": true, "reason": "异议已解决，方案可交付", "finalAnswer": "...（补全后的完整方案）"}；聊天最终返回该 approved 答案。

做完检查这些

• 发送测试消息后 Chat Trigger 触发，起草、评审、终审节点依次执行
• 评审节点输出以 VERDICT: 开头且可被后续解析为 JSON
• 评审不同意时流程回到起草节点重答，且不超过 maxRounds 次
• 终审节点输出以 DECISION: 开头；approved=false 时聊天返回终审自写的修正版
• maxCycles 用尽后流程必然结束，不会无限循环

容易卡住的地方

• AWS Bedrock 模型按区域开放，需先在账户里申请 Sonnet 与 Opus 访问权限，否则终审节点报错
• 评审或终审模型不遵守单行 VERDICT/DECISION 格式会导致解析失败，换模型后要重测输出格式
• 三个模型 API 各自计费，多轮辩论会成倍放大调用费用
• 轮次/循环计数来自节点运行索引，自行改结构时不要破坏该计数节点
• n8n 版本低于 1.60 时 LangChain 节点行为可能不一致