专家、Subagent、Review与Judge，多智能体系统中角色定义的实质差异

当一个AI系统需要生成一份基金费用对比报告时，开发者常会考虑引入额外模型参与——是让“专家”把关方法论，还是派“子智能体”分担核对工作？抑或请“评审员”复查结论，再由“裁判”打分评估质量？表面上看，这些都只是多发一次请求，但实际运行中却频频出现预期外的问题：新模型拿到哪些资料？能否修改原报告？它的意见是否自动覆盖主输出？失败后原始结果是否仍应展示？

问题核心在于：模型是工具，角色由任务、输入、产物与决策权共同定义。同一模型可承担多种职责，不同模型也可能重复同类工作。若不厘清角色本质，仅以模型数量衡量系统复杂度，极易陷入“调用越多越可靠”的误区。

角色分工：回答四个根本性问题

以基金费用分析为例，主智能体需比较两只基金的费率结构。资料中既有年度费用率，也有基于假设投资金额的示例成本——二者口径不同，不可直接混用。围绕这一任务，四个常见角色实则对应四个不同层级的问题：

• 专家配置（Expert Configuration）：回答“按什么方法做？”

例如规定：先识别份额类别与生效日期；区分持续费用、交易费用与示例成本；仅在口径一致时比较，禁止将不同假设下的金额换算为年化费率。这是一套可复用的研究流程模板，本身不依赖特定执行模型。

• Subagent（子智能体）：回答“把哪一小块工作交出去？”

例如将“核对两份授权资料中的费用口径”拆解为独立任务，交由子智能体执行。它接收限定输入（小问题+必要资料+明确方法），输出局部结论与原始来源，主智能体再据此整合最终报告。关键在于“边界清晰”，而非单纯“另起一个模型”。

• Review（复核）：回答“这份已写出的报告哪里需要再看？”

它针对固定报告版本展开检查：材料是否支持某句话？实际引用是否对应？哪些内容未被核查？复核过程必须锚定具体文本与来源，不能泛泛而谈。

• Judge（裁判）：回答“按什么标准评价结果？”

它在预设样本集上，依据明确定义的评分规则（如“口径错误次数”“证据缺失条数”）给出量化分数。其价值在于横向对比不同配置的效果代价比，而非实时干预单次输出。

值得注意的是，“Judge”一词在部分框架中被用于跨样本效果评估，但这并非其普遍定义；现实系统常将配置、执行与角色打包为单一对象，本文拆解旨在厘清责任归属，而非强推统一命名规范。

专家≠新模型：方法先行，执行可选

“你是一位资深基金专家”这类提示词看似赋予身份，实则未说明研究如何展开。真正有效的专家配置，是将方法论显式结构化：识别什么、哪些数据不可比、缺证据时如何表述、最终需提交哪些依据。

Open ETF Agent项目将专家配置管理为版本化方法卡：操作者维护配置库，任务启动时选择具体修订版并冻结至本次任务中。后续配置更新不影响已开始的研究——这解决的是“本次采用哪版方法”，而非授予模型新权限。

该机制沿用原有执行框架：主智能体可在冻结的方法集合中选择使用，也可跳过；预设列表并非强制流水线。排查“专家未生效”时，应依次确认：配置是否进入任务、方法是否被选中、执行是否实际发生——而非盲目增加专家数量。

Subagent的核心价值：切割工作边界

当主智能体需处理长文档或多维度研究时，将“核对两份资料的费用口径”交给Subagent，可实现执行分工与结论综合的分离。

关键要求在于输入的精确性：子智能体应获得一个小问题、必要资料与明确方法，而非模糊指令“帮我研究一下”。其输出为局部结论+原始来源，主智能体保留最终整合与判断权。

Open平台的有界Child机制为此提供支撑：独立上下文、受限执行身份、资料授权与时间约束均继承自主任务。但需警惕一个常见误解——上下文独立不等于判断独立。若主智能体将“费用必为差异主因”作为前提一并传递, 子智能体可能仅为其补充理由，而非独立取证。

公开实现中，真正的独立取证会剥离主智能体的局部解释，确保子智能体仅基于指定材料与方法作答。尽管如此，二者仍可能共享底层模型偏差。Claude Code的Subagent文档亦强调：独立上下文、专用提示与工具访问是关键配置项，远非简单切换模型即可达成。

Review与Judge：复核无改写权，评分需规则锚定

Review环节的本质是“针对固定输入的二次检验”。图3所示流程清晰表明：输入为原报告版本+原始来源，复核过程不得擅自替换为“最新材料”；其产出是问题清单（如“此句缺乏支持”“引用未对应”），而非自动修正。

最终修改权归属“读者”——即主智能体或人工审核者：原报告保留，修改后另存新版本。整个过程无搜索、无自动修复、无发布权，强调可追溯性与责任隔离。

Judge则服务于系统级优化。它不介入单次任务生成，而是在一批固定测试题上，按预定义规则（如错误类型权重、响应长度惩罚）对不同配置方案打分。例如：A配置在100道题中出现3次口径混淆，B配置出现7次但平均耗时少40%，由此权衡取舍。

这种评分必须落到具体样本与明确规则，否则“高分”毫无意义。现实中，许多团队误将Judge当作实时质量门禁，导致系统僵化或反馈失真。

系统设计启示：先定义角色，再决定调用

当前多智能体架构常陷入两个误区：一是将角色等同于模型实例数量，二是混淆执行分工与质量控制职能。事实上，一个模型可通过多次调用承担专家、Subagent与Review三重职责；反之，三个模型若未明确分工，也可能重复做同一件事。

对研究型Agent开发者而言，关键步骤应是：

明确任务链条中的薄弱环节（是方法缺失？执行超载？结论不可靠？）；

为该环节匹配对应角色定义（方法配置 / 局部执行 / 报告复核 / 效果评分）；

再决定是否需新增模型实例，并严格限定其输入边界与输出格式。

Open ETF Agent与Claude Code的实践表明，成熟的多智能体系统并非堆叠模型，而是通过清晰的角色契约与执行约束，使各环节责任可追溯、行为可预期、效果可度量。

随着AI系统向专业领域纵深演进，角色语义的精确性将直接影响系统的可靠性与可维护性。与其追问“要不要加一个专家”，不如先问：“这次任务里，究竟缺了哪种责任主体？”