大模型数学推理新范式：批评家引导的异构多智能体协同求解

1. 项目概述：当大模型遇上数学难题，为何需要“批评家”与“混合军团”？

数学问题求解，尤其是那些需要多步推理、逻辑严谨的复杂题目，一直是衡量人工智能系统认知能力的关键试金石。传统的单一大型语言模型（LLM）方法，比如直接向一个模型提问，常常会陷入“一步错，步步错”的困境。模型可能在第一步就产生了微妙的逻辑偏差或计算错误，但由于缺乏有效的自我校验机制，它会沿着这个错误路径一路狂奔，最终给出一个看似合理但完全错误的答案。更棘手的是，模型对自己犯下的错误往往“不自知”，自信满满地输出错误结果，可靠性无从谈起。

这正是“Critic-Guided Heterogeneous Multi-Agent Reasoning”（批评家引导的异构多智能体推理）这一框架试图攻克的痛点。简单来说，它不再依赖一个“全能型天才”，而是组建了一支各有所长的“特种作战小队”。这支小队里有擅长不同领域的“专家型”智能体（Heterogeneous Agents），比如有的精于代数变换，有的专攻几何证明，有的则对概率统计特别敏感。更重要的是，队伍里还配备了一位冷静的“批评家”（Critic），它的任务不是亲自下场解题，而是全程审视每个专家的推理步骤，像一位严格的教练，不断指出逻辑漏洞、计算失误或假设不合理之处，引导整个团队朝着正确的方向协同思考。

这个思路的兴起，与当前大模型服务领域的热点如“Chimera”（一种面向异构LLM的延迟与性能感知的多智能体服务框架）以及强化学习中的“Actor-Attention-Critic”架构遥相呼应。它们共同揭示了一个趋势：通过精心设计的协同与制衡机制，将多个能力、特性各异的模型组合起来，其整体效能和鲁棒性可以远超单个模型，尤其是在数学推理这种对精确性要求极高的任务上。接下来，我将深入拆解这套框架的核心设计、实现细节以及在实际操作中积累的经验与教训。

2. 核心架构设计：从“单打独斗”到“团队协作”的范式转变

2.1 异构智能体（Heterogeneous Agents）的角色定义与分工

构建一个有效的多智能体系统，首要任务就是明确每个成员的角色和能力边界。在数学问题求解场景下，“异构”主要体现在以下几个方面：

1. 领域知识异构：这是最直观的分工方式。我们可以部署多个模型，每个模型在训练时或在提示（Prompt）工程上被特别强化了某一数学子领域的能力。

   • 代数专家：擅长处理方程求解、不等式证明、函数分析等问题。它的系统提示（System Prompt）会强调符号运算的严谨性和变形技巧。
   • 几何专家：专注于空间想象、图形性质、定理应用。它的提示词会包含大量关于图形标注、辅助线添加的引导。
   • 概率统计专家：对随机变量、分布、期望值、假设检验等概念有更深的理解。
   • 通用推理专家：不一定在特定领域顶尖，但拥有强大的逻辑链构建和自然语言推理能力，负责将问题分解为子步骤。

2. 模型类型异构：除了基于提示的 specialization，我们还可以直接使用不同架构或规模的模型。

   • 大参数模型 vs. 小参数模型：一个大参数模型（如GPT-4、Claude-3）负责复杂规划和深度推理，而多个轻量级、低成本的小模型（如Llama 3 8B、Qwen2.5 7B）负责执行具体的计算、公式检索或简单推导。这直接呼应了“Chimera”框架中关于性能与成本权衡的思想。
   • 符号计算引擎集成：将LLM与传统的符号计算系统（如SymPy、Mathematica引擎）结合。LLM负责理解问题并将其转化为符号计算指令，符号引擎负责执行绝对精确的代数运算，从根本上杜绝计算错误。

3. 思维过程异构：即使使用同一个模型，也可以通过不同的解码策略或提示词，引导其产生不同的推理路径。

   • 链式思维（CoT）智能体：按部就班地进行线性推理。
   • 思维树（ToT）或思维图（GoT）智能体：探索多种可能的推理分支。
   • 验证回溯智能体：其核心任务是尝试从后往前推导，或者对中间结论进行代入验证。

实操心得：智能体不是越多越好。在项目初期，我曾尝试组建一个包含5-6个不同领域专家的团队，结果发现协调成本急剧上升，推理延迟大幅增加，而效果提升却有限。经验表明，一个由2-4个智能体组成的核心团队往往效率最高。一个经典的组合是：一个“规划者”（通用大模型）、一个“计算者”（小模型+符号引擎）、一个“验证者”（另一个大模型或专门训练的Critic）。

2.2 批评家（Critic）的核心职能与工作机制

批评家是整个系统的“大脑”和“质检中心”。它的设计质量直接决定了团队协作的效率和最终答案的可靠性。Critic的工作不是生成答案，而是进行评估、引导和协调。

1. 实时步骤评估：在每个智能体生成一段推理或一个中间结果后，Critic会立即对其进行检查。评估维度包括：

   • 逻辑正确性：这一步推导是否严格符合已知的公理、定理或上一步的结论？是否存在跳步或隐含的不合理假设？
   • 数学精确性：公式书写是否规范？计算过程是否有误？量纲是否一致？
   • 与问题相关性：当前步骤是否在有效推进问题的解决，还是陷入了无关的细节？

2. 错误定位与反馈生成：一旦Critic发现错误，它需要生成具体、可操作的反馈。例如，不是简单地说“这一步错了”，而是说“在将方程两边同时除以(x-1)时，未讨论x=1的情况，此处可能丢失解，建议分情况讨论”。这种反馈会作为新的输入，引导出错的智能体或其同伴进行修正。

3. 策略协调与路由：Critic根据当前推理状态，决定下一步应该由哪个智能体在哪个方向上工作。这类似于一个动态的任务调度器。例如，当问题进入复杂的多项式化简阶段时，Critic可能会暂停“几何专家”的工作，将任务路由给“代数专家”或直接调用符号计算引擎。

4. 终止条件判断：Critic需要判断推理过程是否已经完备、答案是否已经足够可靠，从而决定是否终止整个流程，避免无限循环。

技术实现上，Critic本身通常也是一个LLM，但它的提示词经过了特殊设计，专注于“批判性思维”和“评估”。它的输入通常是：原始问题 + 当前的完整推理历史 + 待评估的最新步骤。输出则是一个结构化的评估结果，例如：{“is_correct”: boolean, “confidence”: float, “feedback”: string, “suggested_next_agent”: string}。

2.3 智能体间的通信与协作流程设计

智能体们不能各自为政，需要一个高效的通信协议来交换信息、传递任务和整合结果。一个典型的工作流程如下：

1. 问题输入与初始化：用户输入数学问题。一个“调度智能体”或Critic本身对问题进行初步分析，判断其主要领域和复杂度，并初始化一个共享的“推理状态黑板”。

2. 迭代式求解循环： a.步骤提议：根据当前“推理状态黑板”上的内容，由Critic或某个智能体提议下一步应该做什么（例如，“求解方程f(x)=0”）。 b.智能体执行：Critic根据提议，选择最合适的智能体来执行该步骤。被选中的智能体生成详细的推理文本和结果。 c.批评家评估：Critic对刚生成的步骤进行评估。如果通过，则将该步骤及结果更新到“推理状态黑板”；如果未通过，则生成反馈，并可能选择另一个智能体重试该步骤，或退回上一步重新思考。 d.状态更新与循环：更新后的“推理状态黑板”成为下一轮循环的输入。如此反复，直到Critic判断问题已解决或达到最大迭代次数。

3. 答案整合与输出：当循环终止时，系统从“推理状态黑板”中提取出清晰的推理链和最终答案，以易于理解的形式呈现给用户。

这个流程的关键在于“推理状态黑板”的设计。它不仅仅是一个历史记录，更应该是一个结构化的表示，可能包含当前已知条件、已推导出的引理、待解决的子目标、尝试过但失败的路径等信息，方便所有智能体和Critic快速理解当前进展。

3. 关键技术实现细节与工具选型

3.1 智能体池的构建与模型选型策略

构建异构智能体池是项目的基础。以下是具体的选型考量与实操配置：

策略一：基于云服务API的混合这是最快上手的方案，适合验证概念和快速迭代。

• 规划与批评家（Critic）：选用能力最强的通用模型，如OpenAI的GPT-4 Turbo或Anthropic的Claude 3 Opus。它们的逻辑分析和指令遵循能力通常最好，适合担任团队的“指挥官”和“质检员”。
• 领域专家：可以继续使用上述通用模型，但通过精心设计的、领域特定的系统提示词（System Prompt）来塑造其“人格”。例如，给“几何专家”的提示词开头可以是：“你是一位严谨的几何学家，擅长平面几何与立体几何的证明与计算。你的每一步推理都必须引用明确的公理或定理...”。
• 计算执行者：为了降低成本并提高计算精度，可以搭配使用开源小模型。例如，使用DeepSeek-Coder或CodeLlama系列模型，因为它们通常具有更好的结构化输出和代码（计算）能力。或者，将计算任务卸载给本地部署的符号数学库。

配置示例（使用LangChain或类似框架）：

from langchain_openai import ChatOpenAI from langchain_community.llms import Ollama # 假设本地部署了Llama # 定义智能体 planner_agent = ChatOpenAI(model=“gpt-4-turbo”, temperature=0.1) critic_agent = ChatOpenAI(model=“gpt-4-turbo”, temperature=0) # temperature更低，更确定性 algebra_agent = ChatOpenAI(model=“gpt-4-turbo”, temperature=0.1, system_prompt=“你是代数专家...”) calculator_agent = Ollama(model=“qwen2.5:7b”) # 本地小模型，负责简单计算和格式化 agent_pool = { “planner”: planner_agent, “critic”: critic_agent, “algebra_expert”: algebra_agent, “light_calculator”: calculator_agent }

策略二：全本地化部署对数据隐私、成本和延迟有极高要求时采用。

• 选型核心：选择在数学基准（如MATH、GSM8K）上表现优异的开源模型。
• 推荐组合：
  • Meta Math或WizardMath系列：专门针对数学推理微调过的模型，作为核心推理智能体。
  • DeepSeek-Math或Qwen2.5-Math：同样为数学任务优化的模型，可作为异构备份或Critic。
  • CodeLlama或StarCoder：负责将数学问题转化为可执行的Python/SymPy代码，实现精确计算。
• 部署工具：使用vLLM、TGI（Text Generation Inference）或Ollama进行高效部署和管理。这里可以借鉴“Chimera”框架的思想，设计一个简单的调度器，根据任务类型和当前负载，将请求分发到不同的模型实例，在延迟和准确性之间取得平衡。

注意事项：提示词工程是成败关键。无论选用哪种模型，为每个智能体精心打磨系统提示词（System Prompt）和少量示例（Few-Shot Examples）的重要性，不亚于模型本身。提示词需要明确角色、规定输出格式（如“每一步推理前请标注‘Step X:’”、“最终答案用‘\boxed{}’包裹”）、并约束其行为边界。

3.2 批评家（Critic）的提示词工程与评估标准量化

让一个LLM当好“批评家”比让它当“解题者”更难，因为它需要更高级的元认知能力。以下是设计Critic提示词的核心要素：

1. 角色定义：必须清晰界定其作为“严谨的数学审查员”的角色，强调其任务是“挑错”而非“创造”。
2. 输入输出格式：规定严格的输入输出格式。输入应包含完整上下文，输出必须是结构化数据（如JSON）。
3. 评估准则具体化：不能只说“检查逻辑错误”，而要列出具体的检查清单。例如：
   • 检查等式变形是否等价（例如，两边乘除是否考虑了零值）？
   • 检查定理应用条件是否满足（例如，使用洛必达法则前是否验证了0/0或∞/∞型）？
   • 检查数值计算是否准确？
   • 检查推理步骤之间是否存在跳跃？是否需要补充中间推导？
   • 检查符号使用是否一致（例如，同一个变量是否始终代表同一含义）？
4. 反馈生成要求：要求反馈必须具体、可操作、指向明确的位置，并尽可能给出修正建议或思路。

一个简化的Critic提示词示例：

你是一位严格的数学推理评审专家。你的任务是对解题过程中的每一步进行审核。 【评审规则】 1. 聚焦逻辑严密性、数学准确性和步骤必要性。 2. 如果步骤正确，请指出；如果存在错误或瑕疵，必须明确指出错误类型、具体位置，并提供修改建议。 3. 你的输出必须是严格的JSON格式：{"verdict": "CORRECT"|"INCORRECT", "error_type": "逻辑错误"/"计算错误"/"符号错误"/"无", "error_location": "描述错误发生的步骤", "detailed_feedback": "具体的反馈文字", "suggestion_for_next": "建议接下来由哪个智能体处理（如：algebra_expert, re-calculate）"} 【当前推理状态】 <在此插入之前的推理步骤> 【待评审的新步骤】 <在此插入刚生成的步骤> 请开始评审：

3.3 多智能体协作的工程框架与状态管理

实现上述流程需要可靠的工程框架。虽然可以完全从零开始，但利用现有框架能事半功倍。

1. 框架选择：

   • LangGraph（LangChain）：这是目前构建多智能体系统最强大的框架之一。它允许你以图（Graph）的形式定义智能体之间的工作流，节点是智能体或函数，边是条件转移。非常适合实现我们设计的“评估-执行-循环”流程。其内置的状态管理（State）概念天然对应我们的“推理状态黑板”。
   • AutoGen（Microsoft）：另一个流行的多智能体对话框架，智能体之间通过对话来协作。其模式更自由，但对于需要严格流程控制的数学推理，可能需要更多定制。
   • CrewAI：侧重于角色扮演和任务分解，与我们的“异构智能体”概念契合，但其在复杂循环和动态路由方面的灵活性可能稍逊于LangGraph。

2. 状态（State）设计： 在LangGraph中，State是一个贯穿始终的字典。我们需要精心设计其结构。

   from typing import TypedDict, List, Annotated import operator class State(TypedDict): problem: str # 原始问题 messages: Annotated[List, operator.add] # 对话历史（包含所有智能体的输出） reasoning_steps: List[str] # 已通过的推理步骤列表 current_step_proposal: str # 当前待执行的步骤描述 last_agent_output: str # 上一个智能体的原始输出 critic_verdict: dict # Critic的评审结果（JSON） final_answer: str # 最终答案 iteration_count: int # 迭代计数器，防止无限循环

   通过这种设计，每个智能体或函数都可以读取和修改State中的特定部分，实现信息共享和流程推进。

3. 工作流（Graph）构建： 使用LangGraph，我们可以构建如下核心循环：

   [Start] -> (Analyze Problem) -> [Propose Step] -> (Route to Agent) -> [Execute Step] -> (Critic Review) -> {If Correct} -> [Update State] -> {If Problem Solved} -> [Generate Final Answer] -> [End] | | v v {If Incorrect} {If Not Solved} | | +---------------> [Generate Feedback] -> (Route to Agent) ...

   这个图清晰地定义了智能体、Critic和状态更新之间的交互逻辑，确保了流程的可控性和可调试性。

4. 实战演练：解构一道经典数学题

让我们通过一个具体例子，看看这个系统是如何工作的。题目：“已知函数 f(x) = x^3 - 3x + 1，求方程 f(f(x)) = x 的实数根个数。”

4.1 问题分析与初步规划

1. 输入：问题进入系统，State初始化。
2. 规划智能体（Planner）启动：它分析问题，识别出这是一个关于复合函数和方程求根的问题，涉及代数、函数性质，可能还需要图像分析。它提出初步计划：“首先，尝试理解f(f(x))的结构。其次，尝试求解方程f(f(x)) = x。由于是三次函数的复合，直接展开会得到高次方程，需寻找更巧妙的解法，可能利用函数迭代的不动点理论。”
3. Critic评审规划：Critic认为计划合理，但提醒：“直接展开f(f(x))会得到9次方程，解析求解极其困难。建议优先从函数迭代和不动点的角度分析。可以尝试分析f(x)的单调性、值域，并寻找f(x)=x的解（一阶不动点），因为如果x是f的不动点，那么它必然也是f∘f的不动点。”
4. 状态更新：current_step_proposal被更新为：“第一步：求解f(x)=x，即求一阶不动点。”

4.2 异构智能体的轮转与协作

1. 代数专家执行：收到“求解f(x)=x”的任务。它进行计算：x^3 - 3x + 1 = x => x^3 - 4x + 1 = 0。它尝试有理根检验，发现±1都不是根，于是输出：“方程x^3 - 4x + 1=0有一个实根和两个共轭复根。实根约为x≈1.8608（可通过数值方法或卡丹公式求得）。”
2. Critic评审：Critic检查后认为：“计算正确。但仅找到一个一阶不动点。需要提醒系统，f(f(x))=x的解集包含一阶不动点，但也可能包含二阶周期点（即满足f(f(x))=x但f(x)≠x的点）。下一步应分析f(x)的单调性和值域，以判断二阶周期点存在的可能性。”
3. 状态更新：reasoning_steps加入第一步的结论。current_step_proposal更新为：“第二步：分析f(x)=x^3-3x+1的单调性和值域。”
4. 函数分析专家（可由代数专家兼任，但提示词侧重分析）执行：计算导数f‘(x)=3x^2-3=3(x-1)(x+1)。得出：在(-∞, -1)和(1, +∞)上单调递增，在(-1, 1)上单调递减。极值点：f(-1)=3（局部极大值），f(1)=-1（局部极小值）。值域为R（全体实数）。
5. Critic评审：通过。
6. 规划智能体再次介入：基于现有信息（一个一阶不动点，f是连续函数且值域为R），它提出：“考虑函数g(x)=f(f(x))-x。我们需要求g(x)=0的实数根个数。由于直接求解困难，可以尝试分析g(x)的零点分布。一个关键思路：如果y=f(x)，那么方程f(f(x))=x等价于f(y)=x且y=f(x)。这构成了一个二维迭代系统。或许可以通过图形方法（如蛛网图）或分析f的迭代行为来推断。”
7. Critic评审：Critic认为思路有价值，但过于抽象。“建议采用更具体的数值-图形结合方法。可以令‘计算执行者’在关键区间内采样计算g(x)的值，通过符号变化来定位零点区间。同时，可以尝试绘制y=f(x)和y=x的图像，以及y=f(f(x))和y=x的图像，直观判断交点个数。”
8. 计算执行者工作：使用符号引擎或代码，在区间[-3, 3]内以0.1为步长计算g(x)=f(f(x))-x的值。发现g(-3)<0, g(-2)>0, g(0)<0, g(2)>0, g(3)<0。根据连续函数介值定理，g(x)在(-3,-2), (-2,0), (0,2), (2,3)内至少各有一个零点。
9. Critic评审：“数值采样发现至少4个符号变化区间，提示可能有4个实数根。需要验证每个区间内是否只有一个根，以及端点附近的行为。建议在发现的符号变化区间内使用更精细的二分法或牛顿法求根。”
10. 计算执行者进行精细求解：在四个区间内分别用二分法求根，得到四个近似实根：x1≈-2.1149, x2≈-0.2541, x3≈0.1149, x4≈1.8608。并验证x4正是之前找到的一阶不动点。
11. Critic最终验证：Critic要求验证这四个根是否确实满足原方程。计算执行者将四个值代入f(f(x))，确认与x的误差在极小范围内。同时，Critic推理：由于f是连续函数，且从图像和数值分析看，g(x)是连续函数，在四个区间内符号变化且单调（可通过导数粗略判断），因此每个区间有且仅有一个根。故最终实数根个数为4。

4.3 答案整合与输出

系统将最终的reasoning_steps整理成一条清晰的逻辑链，并附上最终答案：“方程 f(f(x)) = x 有4个实数根，分别约为 x≈-2.1149, x≈-0.2541, x≈0.1149, x≈1.8608。其中 x≈1.8608 是 f(x)=x 的解（一阶不动点），其余三个是二阶周期点。”

通过这个例子，我们可以看到异构智能体（规划、代数、计算）如何各司其职，以及Critic如何像导演一样，在关键节点进行评审、纠偏和引导，将求解过程从可能陷入的代数泥潭中拉出，转向更有效的数值-分析结合路径。

5. 性能调优与常见问题排查

在实际部署和运行这样的多智能体系统时，会遇到一系列工程和性能上的挑战。

5.1 延迟与成本控制策略

多轮LLM调用必然带来更高的延迟和成本。以下是一些有效的优化策略：

1. 智能体调用异步化：当智能体之间的任务没有严格依赖时，使用异步调用并行执行。例如，在需要从多个角度验证一个结论时，可以同时发起多个验证请求。
2. 缓存中间结果：对于相同的子问题或计算步骤（例如，“计算f(2)的值”），结果应该被缓存起来，避免重复调用。这在迭代求解中非常有效。
3. Critic评估的轻量化：不是每一步都需要动用最强的GPT-4作为Critic。可以设计一个两级评审机制：先用一个快速、低成本的小模型（如GPT-3.5 Turbo）进行初步筛选，只有在小模型不确定或标记为可能错误时，才提交给强大的Critic进行深度评审。
4. 设置超时与最大迭代次数：必须为整个求解流程设置超时（如30秒）和最大迭代次数（如20轮），防止在无解或过于复杂的问题上陷入死循环，消耗大量资源。
5. 选择性展开：对于“思维树”类的探索，Critic可以早期剪枝，放弃那些看起来希望不大的推理分支，集中资源攻关最有潜力的路径。

5.2 常见故障模式与调试技巧

即使设计再完善，系统在实际运行中也会出现各种“诡异”的问题。以下是我在实践中遇到的典型问题及解决方法：

1. 智能体“跑偏”或陷入循环：

   • 现象：某个智能体反复生成相似或无关的内容，Critic反复驳回但智能体无法修正。
   • 排查：首先检查该智能体的系统提示词是否足够清晰，是否约束了其输出格式和范围。其次，检查输入给它的上下文是否包含了导致混淆的信息。
   • 解决：在Critic的反馈中加入更强烈的“重置”或“转向”指令。例如，反馈不再是“这一步错了”，而是“请完全放弃当前思路，尝试从[另一种具体方法]重新开始”。也可以在状态中引入“失败计数器”，当某个智能体在同一任务上失败超过N次后，强制将任务转移给另一个异构智能体。

2. Critic过于“严苛”或过于“宽松”：

   • 现象：Critic要么否决所有步骤导致进程无法推进，要么通过所有步骤导致错误累积。
   • 排查：检查Critic的提示词，评估标准是否定得过高或过低。查看其评估的历史记录，分析误判案例。
   • 解决：调整Critic提示词中评估标准的描述，增加或减少容错度。引入“置信度”阈值，只有置信度高于某个值（如0.8）的“错误”判定才会触发回退流程，低于此值的则仅给出警告性反馈，允许流程继续但标记风险。也可以准备一个“仲裁者”智能体，当Critic的判定连续引发争议时，由仲裁者做最终裁定。

3. 状态（State）混乱或信息丢失：

   • 现象：智能体似乎“忘记”了之前的推理步骤，或者使用了过时、错误的状态信息。
   • 排查：检查工作流中State的传递和更新逻辑。确保每个节点都正确地读取和写入State的相应字段。在LangGraph中，要清晰定义每个节点的input和output。
   • 解决：简化State结构，确保关键信息（如已证结论）放在显眼且不易被覆盖的位置。在messages对话历史中，为每条消息明确标注发送者和角色（如user,assistant,critic），方便智能体理解上下文。

4. 最终答案格式不一致：

   • 现象：推理过程正确，但最终答案的呈现方式五花八门，有的是一段话，有的是纯数字，有的带解释。
   • 解决：在流程的最后，增加一个专门的“格式化智能体”或“报告生成器”。它的任务是从清晰的reasoning_steps和final_answer字段中，提取信息，按照预设的模板（如“问题：...\n\n推理过程：...\n\n因此，最终答案是：\boxed{...}”）生成美观、统一的输出。

5.3 评估体系构建：如何衡量系统的“可靠”性？

构建系统只是第一步，如何科学地评估其效果至关重要。不能只看最终答案对错，还要看过程。

1. 过程评估指标：

   • 步骤正确率：随机采样Critic评审过的步骤，由人工标注其是否正确，计算Critic的评审准确率、召回率。
   • 冗余步骤比例：统计推理链中，被Critic判定为“无关”或“重复”的步骤所占的比例。越低越好。
   • 平均修复轮次：当一个步骤被Critic驳回后，平均需要多少轮交互才能产生一个可接受的修正步骤。这个指标反映了协作效率。

2. 结果评估指标：

   • 最终答案准确率：在标准数学数据集（如MATH、GSM8K）上的准确率。
   • 解题覆盖率：系统能够产出最终答案（无论对错）的问题占总问题的比例。这反映了系统的鲁棒性，避免“卡住”无输出。
   • 置信度校准：让系统在输出答案时附带一个置信度分数。理想情况下，高置信度的答案应有高准确率。绘制可靠性曲线（Reliability Diagram）来评估置信度是否校准良好。

3. 效率评估指标：

   • 平均令牌消耗：解决一个问题所消耗的总Tokens（包括所有智能体和Critic的输入输出）。这直接关联成本。
   • 平均延迟：从问题输入到最终答案输出的时间。
   • 迭代次数分布：大部分问题在多少次迭代内可以解决？长尾分布的情况如何？

通过这套多维度的评估体系，我们可以系统地比较不同智能体组合、不同Critic策略、不同工作流设计的优劣，从而持续迭代优化整个系统。它不再是一个黑箱，而是一个可观测、可调试、可改进的复杂智能系统。