> ## Documentation Index
> Fetch the complete documentation index at: https://opc-43d279b8.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 专家团：角色正交、Lead 收敛与产物协作

> 专家团的角色正交、Lead 拆分与裁决、产物契约交接、成本控制与评估的面试要点。

> 多 Agent 协作我看两件事：角色是不是正交，交接和冲突有没有契约。只让几个专家一起讨论，成本和责任归属很快就说不清。

***

## 1. 定义与边界：专家团是"任务型临时组织"

专家团（Expert Team）是围绕一个复杂任务临时组建的组织：**角色分工 + 产物交接 + 裁决收敛**。任务结束即解散，不进入常设编制。

| 形态 | 组织方式 | 适用 | 不适用 |
| - | - | - | - |
| 单 Agent + 长 Prompt | 一个角色做所有事 | 任务边界清晰、上下文装得下 | 多专业、需要交叉验证 |
| Workflow | 代码写死节点与路由 | 步骤稳定、分支可枚举 | 需要运行时判断、任务高度不确定 |
| 群聊式 Multi-Agent | 多角色自由对话 | 探索性讨论、头脑风暴 | 需要可验收交付、强责任 |
| 专家团 | Lead 拆解 + 专家并行 + 契约交接 + 评审/裁决 | 高价值、可拆解、错误代价高 | 实时性极高、强串行、简单任务 |

### 1.1 什么时候值得上专家团

| 信号 | 说明 |
| - | - |
| 需要多种专业视角 | 法务、财务、安全、性能的判断标准不同 |
| 单 Agent 上下文装不下 | 材料多、工具多、约束多 |
| 错误代价高 | 需要生成者/评审者分离和交叉验证 |
| 任务可并行拆解 | 调研、方案、实现、评审能分头做 |
| 结果可验收 | 有明确产物和验收标准 |

反过来说：任务步骤固定、规则清晰、单 Agent 已能稳定完成、实时性要求极高、错误代价低，都不值得上专家团。**多 Agent 不是先进，是成本更高的协调方式。**

### 1.2 三个必须提前承认的失败模式

公开的多 Agent 评测实践把失败集中在"接缝"上，而不是单个 Agent 的能力上：

| 失败模式 | 表现 | 根因 |
| - | - | - |
| 交接误解 | 下游没保住上游的约束，漏掉一个条件 | 交接只有自然语言，没有契约 |
| 角色漂移 | 评审开始改写，调研开始下结论 | 角色边界没有架构级约束 |
| 群体一致性崩塌 | 最终共识悄悄推翻了前面的修正 | 汇总时丢失异议和证据 |

所以专家团的设计重点是**交接契约、角色约束、裁决记录**，"多请几个专家"解决不了问题。

> [!NOTE]
>
> 专家团的价值 = 角色正交 × 独立判断 × 契约交接 × 明确裁决。缺一项，人数越多，错误放大越快。

***

## 2. 角色正交设计：先定义"不做什么"

### 2.1 角色不是人设，是责任切片

一个角色至少要被六个维度定义清楚。两个角色如果在三个以上维度高度重合，就应该合并。

| 维度 | 要回答的问题 |
| - | - |
| 回答什么问题 | 这个角色唯一负责回答的问题是什么？ |
| 决策权 | 它能决定什么？不能决定什么？ |
| 输入 | 它需要哪些材料？不应该看哪些材料？ |
| 输出 | 它交付什么结构化产物？ |
| 工具 | 它允许调用哪些工具？ |
| 验收与失败 | 怎么算做好？最常见的失败是什么？ |

### 2.2 典型角色分工

| 角色 | 核心问题 | 主要产物 | 明确不做 |
| - | - | - | - |
| 调研专家 | 事实是什么？ | 证据表、现状图、来源清单 | 不做方案取舍 |
| 方案专家 | 有哪些可行解？ | 方案对比、架构图、取舍说明 | 不拍板最终方案 |
| 实现专家 | 能不能落地？ | 任务拆解、接口契约、原型/代码 | 不评价业务价值 |
| 评审专家 | 哪里会坏？ | 结构化 findings、风险等级 | 不重写产物 |
| 裁决者 | 最终选哪个？为什么？ | 决策记录、接受/驳回理由 | 不代替专家做专业分析 |
| 合规/风险 | 有没有越界？ | 合规清单、阻断项 | 不优化业务方案 |

### 2.3 正交性检查

用一张矩阵检查角色是否重叠：

| 检查项 | 通过标准 | 不通过的样子 |
| - | - | - |
| 问题唯一 | 每个角色只回答一类问题 | 两个人都在回答"方案好不好" |
| 输入不同 | 角色看到不同材料 | 所有人都拿到全量上下文 |
| 输出不同 | 产物 schema 不同 | 都输出一段自然语言 |
| 评价标准不同 | 调研看证据，方案看取舍，评审看缺陷 | 都用"写得好不好"评价 |
| 工具不同 | 调研用检索，实现用沙箱，评审用规则 | 所有人共用一套工具 |
| 失败模式不同 | 调研怕漏证据，方案怕漏约束，评审怕漏风险 | 失败都归因于"模型不够强" |

### 2.4 Agent 版 RACI

| 任务 | 调研 | 方案 | 实现 | 评审 | Lead/裁决 |
| - | - | - | - | - | - |
| 事实与证据 | R | C | I | C | A |
| 方案设计 | C | R | C | C | A |
| 可行性 | C | C | R | C | A |
| 缺陷发现 | I | I | C | R | A |
| 最终交付 | I | I | I | C | A |

规则：**每个关键产物只能有一个 A（Accountable）**。多个人都负责，等于没人负责。

***

## 3. Lead：拆解、分派、汇总、裁决

### 3.1 Lead 的职责边界

| 职责 | 做什么 | 不做什么 |
| - | - | - |
| 拆解 | 目标 → 任务树/DAG，定义叶子产物 | 不替专家做专业判断 |
| 分派 | 按能力、工具、上下文路由 | 不把完整历史无脑转发 |
| 监督 | 超时、失败、预算、越级上报 | 不频繁打断专家 |
| 汇总 | 合并产物、检查契约、保留异议 | 不做"平均化"总结 |
| 裁决 | 按证据与风险拍板 | 不在没有依据时和稀泥 |
| 负责 | 对最终交付负责 | 不把责任推给某个专家 |

### 3.2 拆解：叶子任务的标准

一个叶子任务应该满足：

```text theme={null}
一个明确产物 + 一组相关工具 + 可逐条验收的标准 + 明确的依赖
```

经验值：一个叶子任务的工作量控制在 5-15 个工具调用；太少说明拆碎了，太多说明上下文会膨胀。

```text theme={null}
目标：评审"订单中心拆分"技术方案
├── T1 现状调研（并行）
│   ├── T1.1 依赖与调用链
│   └── T1.2 数据一致性与迁移约束
├── T2 方案设计（依赖 T1）
│   ├── T2.1 服务边界与接口契约
│   └── T2.2 迁移与回滚方案
├── T3 专项评审（依赖 T2，可并行）
│   ├── T3.1 性能与容量
│   ├── T3.2 安全与合规
│   └── T3.3 可运维性
└── T4 裁决与交付（依赖 T3）
    ├── T4.1 冲突裁决
    └── T4.2 决策记录与验收
```

### 3.3 分派：只给"需要知道的"

子 Agent 不应该继承 Lead 的完整对话历史。原因：

1. **成本**：历史 token 乘以 N 个专家。
2. **噪声**：无关讨论会干扰判断，甚至让专家重复已排除的方案。
3. **一致性**：不同专家看到的历史版本不同，产物会互相矛盾。

正确做法是维护一份**任务简报**：目标、已确认事实、约束、验收标准、可用工具、禁止事项。专家只读简报 + 自己的子任务 + 上游产物。

### 3.4 汇总：合并产物，不合并口水

汇总要做的是下面几件事，单纯把几段自然语言拼在一起不够：

1. **契约校验**：每个产物是否符合 schema、是否带证据、是否满足验收。
2. **冲突检测**：同一事实是否出现不同数值/结论；同一约束是否被不同专家解释。
3. **依赖检查**：下游是否使用了上游的旧版本。
4. **异议保留**：少数意见必须进入决策记录，不能被"综合"掉。
5. **最终产物**：由 Lead/裁决者生成，专家产物作为附录和证据。

### 3.5 冲突裁决协议

冲突不可怕，可怕的是"看起来达成了一致"。建议按以下顺序裁决：

| 优先级 | 依据 | 说明 |
| - | - | - |
| 1 | 一手证据 | 原始数据、合同、日志、可复现实验 |
| 2 | 可复现验证 | 能跑一遍、能算一遍、能对账 |
| 3 | 约束与合规 | 法务/安全/合规的硬约束优先 |
| 4 | 置信度与历史正确率 | 专家在该类任务上的历史表现 |
| 5 | 错误代价 | 错了谁承担、损失多大 |
| 6 | 人工裁决 | 以上都无法收敛时升级给人 |

裁决必须留下**决策记录**：问题、各方观点、证据、取舍理由、最终决定、接受的风险、回滚条件。没有决策记录，冲突会在下一次任务里重演。

***

## 4. 独立上下文与"生成者/评审者分离"

### 4.1 为什么必须独立上下文

* 防止锚定：评审者如果看了生成过程，容易为已有方案找理由。
* 防止串味：生成者的偏好会污染评审标准。
* 防止角色漂移：评审者看到太多上下文，会开始"帮忙改"。
* 便于归因：每个角色的输入输出可独立审计。

### 4.2 生成者/评审者分离

一个成熟的模式是：**Generator 只产出，Critic 只找问题，Arbiter 只做裁决。**

| 角色 | 唯一输出 | 禁止 |
| - | - | - |
| Generator | 草稿/方案/代码 | 不给自己打分 |
| Critic | 结构化 findings | 不重写、不改稿、不只给总分 |
| Arbiter | PASS/FAIL/PARTIAL + 理由 | 不代替专家分析 |

Critic 的输出必须是结构化的，而不是"我觉得不太好"：

```json theme={null}
{
  "artifact_id": "adr-001",
  "version": "1.2.0",
  "findings": [
    {
      "section": "3.2 数据一致性",
      "issue_class": "missing-failure-mode",
      "severity": "blocking",
      "evidence": "未说明双写失败时的补偿路径",
      "suggested_fix": "补充 outbox + 对账 + 人工补偿",
      "rule": "ARCH-7"
    }
  ],
  "verdict": "PARTIAL"
}
```

关键点：**评审意见要可计数、可归因、可回归。** 如果评审只输出一段散文，团队无法判断它到底发现了什么，也无法统计哪类问题反复出现。

### 4.3 辩论协议

辩论的价值在于把分歧暴露得更清楚；让 Agent 互相说服没有意义。

```text theme={null}
Round 1：各方提交 claim + evidence + confidence
Round 2：针对对方证据提出 rebuttal，不允许重复立场
Round 3：只讨论仍未解决的证据冲突
Stop：达到轮次上限 / 无新证据 / 预算耗尽
Judge：按证据等级和错误代价裁决，保留异议
```

规则：

* 每轮必须引入**新证据或新推理**，不能重复立场。
* 不允许人身/语气攻击，只评价证据和逻辑。
* 最多 2-3 轮，超过就说明证据不足，应该升级给人或补数据。
* 裁决者不参与辩论，只做最后判断。

### 4.4 投票的局限

投票看起来很民主，但在专家团里经常是错的：

| 局限 | 说明 |
| - | - |
| 错误相关 | 多个专家用同一个模型、同一份材料，会犯同样的错 |
| 从众/谄媚 | Agent 容易迎合上一个发言者或"多数意见" |
| 多数不等于正确 | 三个错的专家可以投票压过一个对的 |
| 无法处理硬约束 | 合规问题不能靠投票决定 |
| 成本高 | 每轮投票都要重新调用，延迟和费用上升 |

更可靠的做法是：\*\* rubric 评分 + 证据等级 + 裁决者 + 人工兜底\*\*，而不是简单多数票。投票只适合低风险、无硬约束、分歧主要是偏好的场景。

***

## 5. 产物协作：artifact、manifest、版本与回滚

### 5.1 Artifact：专家之间传"东西"，不传"感觉"

```typescript theme={null}
interface Artifact {
  id: string;
  type: "evidence" | "design" | "code" | "review" | "decision" | "report";
  version: string; // 语义化版本
  producer: string; // 哪个角色/Agent
  parent?: string; // 上游产物 ID
  inputs: string[]; // 依赖的产物/数据
  schema: string; // 产物结构
  contentRef: string; // 存储位置/哈希
  citations: string[]; // 证据来源
  confidence: number; // 0-1，必须可解释
  status: "draft" | "review" | "approved" | "rejected";
  createdAt: string;
  cost: { tokens: number; tools: number; latencyMs: number };
}
```

原则：**产物不可变，修改产生新版本。** 这样任何结论都能回到具体版本，评审意见也能绑定到具体版本。这套 artifact/manifest 设计与本系列规划中的 Agent Artifacts 章节一致：产物是唯一交接单元，自然语言只做说明。

### 5.2 Manifest：一次任务的总账

```json theme={null}
{
  "run_id": "run-20261114-001",
  "goal": "评审订单中心拆分方案",
  "task_tree": "tasks.json",
  "artifacts": [
    { "id": "evidence-001", "version": "1.0.0", "status": "approved" },
    { "id": "adr-001", "version": "1.2.0", "status": "review" },
    { "id": "review-001", "version": "1.0.0", "status": "open" }
  ],
  "decisions": ["decision-001"],
  "open_questions": ["迁移窗口是否足够"],
  "budget": { "tokens_used": 182000, "cost_usd": 3.42 },
  "owner": "lead-agent",
  "human_gate": "cto-review"
}
```

Manifest 是回放、审计、续跑和成本归因的入口。没有 manifest，任务失败后只能从头再来。

### 5.3 交接契约

```typescript theme={null}
interface Handoff {
  taskId: string;
  from: string;
  to: string;
  goal: string;
  inputs: { artifacts: string[]; facts: Record<string, string> };
  constraints: string[];
  acceptance: string[];
  outputSchema: string;
  deadlineMs: number;
  budget: { tokens: number; tools: number };
  escalateTo: string;
}
```

交接必须记录：**为什么换手、哪些工作已完成、下游需要什么证据、什么算成功。** 否则多 Agent 会反复重做上一环已经确认的事。

### 5.4 版本与回滚

* 语义化版本：`major.minor.patch`，破坏契约升 major。
* 父指针：每个版本记录上游版本，支持追溯。
* 回滚粒度：单个 artifact、单个任务节点、整个 run。
* 决策绑定：决策记录引用具体 artifact 版本，不能引用"最新版"。
* 废弃策略：旧版本标记 deprecated，但不删除，保留审计期。

### 5.5 评审意见的结构化

| 字段 | 作用 |
| - | - |
| artifact\_id + version | 绑定评审对象 |
| section | 定位到具体段落/接口/指标 |
| issue\_class | 问题类型，便于统计 |
| severity | blocking / major / minor |
| evidence | 证据或规则编号 |
| suggested\_fix | 建议方向，不是代写 |
| blocking | 是否阻断交付 |

Lead 汇总时按 `blocking` 和 `severity` 排序，而不是按专家资历排序。

***

## 6. 成本与延迟：专家团不是免费的

### 6.1 成本公式

```text theme={null}
总成本 = Lead 成本
       + Σ 专家执行成本
       + Σ 评审/辩论轮次成本
       + 重试与返工成本
       + 人工裁决成本
       + 基础设施与工具成本

单位合格交付成本 = 总成本 / 合格交付量
```

arXiv 上的一项工作流研究（Jev-LiteMAS）测量了三个多 Agent 框架，发现**路由与评审消耗了 31.7%-43.5% 的生成式模型 token**。协调本身就是大头，不能只算专家执行的 token。

### 6.2 延迟公式

```text theme={null}
端到端延迟 ≈ 关键路径上的串行阶段
           + 最慢并行分支
           + 评审轮次 × 单轮评审延迟
           + 人工裁决等待
```

优化顺序：先压关键路径，再压评审轮次，最后才考虑换更快的模型。盲目增加并行度，可能让汇总和评审变成新瓶颈。

### 6.3 成本控制杠杆

| 杠杆 | 做法 | 风险 |
| - | - | - |
| 角色数量 | 只保留真正正交的角色 | 角色太少覆盖不足 |
| 模型分级 | Lead/裁决用强模型，例行抽取用便宜模型 | 分级不当导致质量塌方 |
| 并行度 | 独立子任务并行 | 汇总成本上升 |
| 轮次上限 | 评审最多 2 轮，辩论最多 3 轮 | 复杂问题可能没收敛 |
| 早停 | 无新证据、达到验收、边际收益低于成本就停 | 过早停止漏风险 |
| 缓存 | 复用证据、模板、历史产物 | 过期缓存导致错误 |
| 分级评审 | 低风险产物只做规则校验 | 规则覆盖不到的新问题 |

### 6.4 什么时候不值得上专家团

* 任务 10 分钟能做完，协调要 30 分钟。
* 只有一个专业面，不存在交叉验证需求。
* 实时性要求高，用户等不了多轮评审。
* 错误代价低，返工比评审便宜。
* 没有验收标准，评审只能凭感觉。
* 没有预算和轮次上限，专家团会无限膨胀。

***

## 7. 两个完整场景走查

### 7.1 场景一：技术方案评审（订单中心拆分）

**目标**：评审"订单中心从单体拆分为独立服务"的方案，输出是否放行的决策。

**任务树**：

```text theme={null}
T1 现状调研（并行）
├── T1.1 依赖与调用链
├── T1.2 数据一致性与迁移约束
└── T1.3 历史故障与容量基线
T2 方案设计（依赖 T1）
├── T2.1 服务边界与接口契约
├── T2.2 数据迁移与回滚
└── T2.3 灰度与可观测性
T3 专项评审（依赖 T2，并行）
├── T3.1 性能与容量
├── T3.2 安全与合规
└── T3.3 可运维性
T4 裁决（依赖 T3）
├── T4.1 冲突裁决
└── T4.2 决策记录
```

| 角色 | 产物 | 交接契约要点 |
| - | - | - |
| 调研 | `evidence.json`：调用链、QPS、数据量、故障史 | 每条事实带来源和时间 |
| 方案 | `adr-001.md`：边界、接口、迁移、回滚 | 必须引用 evidence 版本 |
| 性能评审 | `perf-findings.json`：瓶颈、容量缺口、压测方案 | 必须给数值和假设 |
| 安全评审 | `security-findings.json`：越权、审计、数据边界 | blocking 项不可协商 |
| 裁决 | `decision-001.md`：放行/有条件放行/驳回 | 记录异议和接受的风险 |

**冲突案例**：

* 方案专家主张"同步双写"保证一致性。
* 性能专家指出双写会把下单延迟放大 30%，且故障时可能拖垮主链路。
* 安全专家要求所有跨服务调用可审计、可追溯。

**裁决过程**：

1. 证据优先：性能专家给出压测数据，方案专家的"一致性更好"是定性判断。
2. 约束优先：审计是硬约束，不能投票取消。
3. 取舍：采用 outbox + 最终一致 + 对账补偿；跨服务调用统一 trace；双写只保留一个迁移窗口。
4. 风险接受：接受短时不一致，设置对账告警和人工补偿。
5. 决策记录：写明"为什么不是同步双写"，以及回滚条件。

**验收标准**：

* 所有 blocking findings 关闭或有明确风险接受人。
* ADR 包含失败模式、回滚方案、监控指标。
* 关键数值有压测/容量依据。
* 异议进入决策记录。
* 人工 CTO 签字放行。

### 7.2 场景二：投研报告生成（新能源车企）

**目标**：生成一份可对外发布的研究报告，覆盖行业、公司、财务、估值、风险。

**任务树**：

```text theme={null}
T1 数据底座（并行）
├── T1.1 行业供需与价格
├── T1.2 公司销量/车型/产能
├── T1.3 财报与现金流
└── T1.4 政策与舆情
T2 分析（依赖 T1）
├── T2.1 行业格局与竞争
├── T2.2 财务质量与盈利驱动
├── T2.3 估值与情景假设
└── T2.4 风险清单
T3 撰写（依赖 T2）
└── T3.1 报告正文与图表
T4 评审（依赖 T3）
├── T4.1 事实核查
├── T4.2 逻辑与估值复核
├── T4.3 合规审查
└── T4.4 裁决与定稿
```

| 角色 | 产物 | 关键约束 |
| - | - | - |
| 数据专家 | `evidence.json`：指标、来源、日期、口径 | 每个数字可追溯 |
| 行业专家 | `industry.md`：供需、格局、份额 | 区分事实与判断 |
| 财务专家 | `model.xlsx`：收入、毛利、现金流、估值 | 假设显式、可复算 |
| 风险专家 | `risk-register.json`：风险、概率、影响 | 包含反方观点 |
| 撰写 | `report.md` + `chart-manifest.json` | 不引入新事实 |
| 评审 | `review-findings.json` | 事实、逻辑、合规分开 |
| 裁决 | `decision-001.md` | 保留多空分歧 |

**冲突案例**：

* 行业专家看多：渗透率提升、出口增长、新品周期。
* 财务专家看空：价格战导致毛利率下滑，现金流承压。
* 估值专家给出两种情景，差异巨大。

**裁决过程**：

1. 事实层先对齐：销量、单价、毛利率、现金流必须用同一口径。
2. 逻辑层分开：行业增长不等于公司盈利，必须通过单位经济模型连接。
3. 情景化：给出乐观/中性/悲观三档，而不是强行给一个目标价。
4. 保留异议：报告明确写出"多空分歧点"和触发条件。
5. 合规 gate：所有预测标注假设，所有引用带来源，禁止内幕信息。

**验收标准**：

* 每个关键数字有来源、日期、口径。
* 财务模型可复算，假设可追溯。
* 报告区分事实、推断、预测。
* 多空分歧和风险被保留，而不是被"综合"掉。
* 合规审查通过，人工签字发布。

***

## 8. 深度面试追问：及格回答 vs 满分回答

### 追问 1：专家团和"一个 Agent 加长 Prompt"到底差在哪？

**及格回答**：专家团有多个角色，能分工，能并行，所以更强。

**满分回答**：差别不在角色数量，而在**责任切片和验证结构**。长 Prompt 是一个角色同时做调研、方案、评审，容易自说自话；专家团把生成和评审分开，用独立上下文和契约交接，让错误在接缝处暴露。但如果任务简单、单 Agent 已经稳定，专家团只是增加成本和延迟。判断标准是：专业化是否真的改变了工具、上下文、评价标准或风险边界。

### 追问 2：角色怎么划分才算"正交"？

**及格回答**：调研、方案、实现、评审，各干各的。

**满分回答**：用六个维度检查：回答的问题、决策权、输入、输出、工具、验收标准。如果两个角色在三个以上维度重合，就应该合并。每个关键产物只能有一个 Accountable。比如"评审"只输出结构化 findings，不重写；"方案"只做取舍，不拍板；"裁决"只看证据和风险，不代替专家分析。正交不是名字不同，是责任和产物不同。

### 追问 3：Lead 怎么避免成为瓶颈？

**及格回答**：让 Lead 少干活，多派活。

**满分回答**：Lead 只做四件事：拆解、分派、汇总、裁决，不参与专业生成。拆解要产出可调度的 DAG，分派只给任务简报和必要产物，汇总做契约校验和冲突检测，裁决按证据等级和错误代价。把例行路由交给规则或轻量决策模型，把专业判断交给专家，把硬约束交给合规。Lead 的上下文也要控制，否则它会变成新的单点故障。

### 追问 4：评审 Agent 为什么会失效？怎么设计？

**及格回答**：换个更强的模型，或者多评审几轮。

**满分回答**：评审失效多数出在角色不独立：看了生成过程、被要求"给点建议"、输出一段散文、最后还负责改写。正确做法是生成者/评审者分离：评审只看产物、验收标准和冻结的 rubric；只输出结构化 findings；不允许重写；blocking 项必须给证据和规则编号。这样评审信号可计数、可归因、可回归，不停留在"感觉不太好"。

### 追问 5：多个专家意见冲突，Lead 怎么裁决？

**及格回答**：少数服从多数，或者让 Lead 拍板。

**满分回答**：先看证据等级：一手数据/可复现实验 > 约束与合规 > 专家判断。硬约束不能投票。然后看错误代价和回滚成本。裁决要留下决策记录：各方观点、证据、取舍理由、接受的风险、回滚条件。如果证据不足，就补数据或升级给人，而不是和稀泥。多数票只能处理偏好问题，不能处理事实和合规问题。

### 追问 6：投票能不能解决专家分歧？

**及格回答**：可以，投票最公平。

**满分回答**：投票有三个硬伤：错误相关，多个专家用同一模型同一材料会犯同样的错；从众/谄媚，Agent 容易迎合多数；多数不等于正确，硬约束不能投票。更可靠的是 rubric 评分 + 证据等级 + 裁决者 + 人工兜底。投票只适合低风险、无硬约束、分歧主要是偏好的场景。

### 追问 7：专家产物怎么交接，才不会互相覆盖？

**及格回答**：让 Lead 汇总一下，大家把结果发群里。

**满分回答**：用 artifact + manifest。每个产物有 id、类型、版本、生产者、上游依赖、schema、证据、置信度、状态；产物不可变，修改产生新版本；manifest 记录任务树、产物索引、决策、未决问题、预算。交接用结构化契约，写明目标、输入、约束、验收、输出 schema、截止时间和升级对象。Lead 只合并通过契约校验的产物，冲突进入裁决，不直接覆盖。

### 追问 8：专家团成本怎么控？

**及格回答**：少用几个专家，少跑几轮。

**满分回答**：先算总成本：Lead + 专家 + 评审轮次 + 重试 + 人工 + 基础设施。然后用五个杠杆：角色只保留正交的；模型分级，Lead/裁决用强模型，例行抽取用便宜模型；独立子任务并行；设轮次和预算上限；无新证据或达到验收就早停。还要算单位合格交付成本，而不是只看 token 单价。协调本身可能占三成以上（同一研究口径下为 31.7%-43.5%），不能忽略。

### 追问 9：怎么评估一个专家团好不好？

**及格回答**：看最终报告质量，或者看用户满意度。

**满分回答**：评估单元应当放在**交接**上。看三类指标：交接保真度（下游是否保住上游约束）、角色依从度（有没有漂移）、群体一致性（最终结论是否丢了对的修正）。再加上最终产物的验收通过率、返工率、人工修改量、单位成本、延迟。回归集应该是"预期交接序列 + 预期角色覆盖"，最终答案只是其中一项。

### 追问 10：什么时候不该上专家团？

**及格回答**：任务简单的时候。

**满分回答**：任务步骤固定、单 Agent 已稳定、实时性高、错误代价低、没有验收标准、没有预算上限，都不该上。专家团适合高价值、可拆解、需要交叉验证、错误代价高的任务。还要看协调成本：如果协调时间超过执行时间，或者评审没有独立 rubric，上专家团只会更贵、更慢、更难追责。

***

## 9. 来源与延伸阅读

* 腾讯云 WorkBuddy 产品文档：[专家](https://cloud.tencent.com/document/product/1831/134393)（2026-10-15）：专家 = 人设 + 方法论 + 工具链；专家团 = 团长拆解、并行执行、整合交付；专家不主动获取系统权限。
* 腾讯云 WorkBuddy 产品文档：[专家管理](https://cloud.tencent.com/document/product/1831/134421)（2026-11-13）：企业专家分类、可见范围、下发策略、调用统计。
* 腾讯云开发者社区：[WorkBuddy Enterprise 产品功能](https://cloud.tencent.com.cn/developer/techpedia/2677/21381)（2026-08-04）。
* Agent Patterns Catalog：[Generator-Critic Separation](https://www.agentpatternscatalog.org/patterns/generator-critic-separation/)（2026-05-23）：评审只输出结构化 findings，不生成、不重写。
* Future AGI：[Evaluating AutoGen Agents: The Handoff Is the Unit](https://futureagi.com/blog/evaluating-autogen-agents-2026/)（2026-03-07，2026-05-20 更新）：交接误解、角色漂移、群体一致性崩塌。
* arXiv：[Jev-LiteMAS: Separating Decisions from Generation in Multi-Agent Workflows](https://arxiv.org/html/2610.21411v1)（2026-10-15）：路由与评审占生成式 token 的 31.7%-43.5%。
* IEEE/ACM ASEW 2025：[Traceability and Accountability in Role-Specialized Multi-Agent LLM Pipelines](https://dl.acm.org/doi/abs/10.1109/ASEW67777.2025.00064)（2025-11-16）：结构化交接、角色专属强弱项、可追溯与问责。
* LangGraph 多智能体图架构教程：[Multi-Agent Graphs: Supervisor, Specialist, and Handoff Architectures](https://www.tutorialslogic.com/langgraph/multi-agent-graphs)（2026-07-27）：状态所有权、显式交接、监督者边界。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.