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

1. 定义与边界:专家团是”任务型临时组织”

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

1.1 什么时候值得上专家团

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

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

公开的多 Agent 评测实践把失败集中在”接缝”上,而不是单个 Agent 的能力上: 所以专家团的设计重点是交接契约、角色约束、裁决记录,“多请几个专家”解决不了问题。
专家团的价值 = 角色正交 × 独立判断 × 契约交接 × 明确裁决。缺一项,人数越多,错误放大越快。

2. 角色正交设计:先定义”不做什么”

2.1 角色不是人设,是责任切片

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

2.2 典型角色分工

2.3 正交性检查

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

2.4 Agent 版 RACI

规则:每个关键产物只能有一个 A(Accountable)。多个人都负责,等于没人负责。

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

3.1 Lead 的职责边界

3.2 拆解:叶子任务的标准

一个叶子任务应该满足:
经验值:一个叶子任务的工作量控制在 5-15 个工具调用;太少说明拆碎了,太多说明上下文会膨胀。

3.3 分派:只给”需要知道的”

子 Agent 不应该继承 Lead 的完整对话历史。原因:
  1. 成本:历史 token 乘以 N 个专家。
  2. 噪声:无关讨论会干扰判断,甚至让专家重复已排除的方案。
  3. 一致性:不同专家看到的历史版本不同,产物会互相矛盾。
正确做法是维护一份任务简报:目标、已确认事实、约束、验收标准、可用工具、禁止事项。专家只读简报 + 自己的子任务 + 上游产物。

3.4 汇总:合并产物,不合并口水

汇总要做的是下面几件事,单纯把几段自然语言拼在一起不够:
  1. 契约校验:每个产物是否符合 schema、是否带证据、是否满足验收。
  2. 冲突检测:同一事实是否出现不同数值/结论;同一约束是否被不同专家解释。
  3. 依赖检查:下游是否使用了上游的旧版本。
  4. 异议保留:少数意见必须进入决策记录,不能被”综合”掉。
  5. 最终产物:由 Lead/裁决者生成,专家产物作为附录和证据。

3.5 冲突裁决协议

冲突不可怕,可怕的是”看起来达成了一致”。建议按以下顺序裁决: 裁决必须留下决策记录:问题、各方观点、证据、取舍理由、最终决定、接受的风险、回滚条件。没有决策记录,冲突会在下一次任务里重演。

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

4.1 为什么必须独立上下文

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

4.2 生成者/评审者分离

一个成熟的模式是:Generator 只产出,Critic 只找问题,Arbiter 只做裁决。 Critic 的输出必须是结构化的,而不是”我觉得不太好”:
关键点:评审意见要可计数、可归因、可回归。 如果评审只输出一段散文,团队无法判断它到底发现了什么,也无法统计哪类问题反复出现。

4.3 辩论协议

辩论的价值在于把分歧暴露得更清楚;让 Agent 互相说服没有意义。
规则:
  • 每轮必须引入新证据或新推理,不能重复立场。
  • 不允许人身/语气攻击,只评价证据和逻辑。
  • 最多 2-3 轮,超过就说明证据不足,应该升级给人或补数据。
  • 裁决者不参与辩论,只做最后判断。

4.4 投票的局限

投票看起来很民主,但在专家团里经常是错的: 更可靠的做法是:** rubric 评分 + 证据等级 + 裁决者 + 人工兜底**,而不是简单多数票。投票只适合低风险、无硬约束、分歧主要是偏好的场景。

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

5.1 Artifact:专家之间传”东西”,不传”感觉”

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

5.2 Manifest:一次任务的总账

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

5.3 交接契约

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

5.4 版本与回滚

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

5.5 评审意见的结构化

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

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

6.1 成本公式

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

6.2 延迟公式

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

6.3 成本控制杠杆

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

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

7. 两个完整场景走查

7.1 场景一:技术方案评审(订单中心拆分)

目标:评审”订单中心从单体拆分为独立服务”的方案,输出是否放行的决策。 任务树:
冲突案例:
  • 方案专家主张”同步双写”保证一致性。
  • 性能专家指出双写会把下单延迟放大 30%,且故障时可能拖垮主链路。
  • 安全专家要求所有跨服务调用可审计、可追溯。
裁决过程:
  1. 证据优先:性能专家给出压测数据,方案专家的”一致性更好”是定性判断。
  2. 约束优先:审计是硬约束,不能投票取消。
  3. 取舍:采用 outbox + 最终一致 + 对账补偿;跨服务调用统一 trace;双写只保留一个迁移窗口。
  4. 风险接受:接受短时不一致,设置对账告警和人工补偿。
  5. 决策记录:写明”为什么不是同步双写”,以及回滚条件。
验收标准:
  • 所有 blocking findings 关闭或有明确风险接受人。
  • ADR 包含失败模式、回滚方案、监控指标。
  • 关键数值有压测/容量依据。
  • 异议进入决策记录。
  • 人工 CTO 签字放行。

7.2 场景二:投研报告生成(新能源车企)

目标:生成一份可对外发布的研究报告,覆盖行业、公司、财务、估值、风险。 任务树:
冲突案例:
  • 行业专家看多:渗透率提升、出口增长、新品周期。
  • 财务专家看空:价格战导致毛利率下滑,现金流承压。
  • 估值专家给出两种情景,差异巨大。
裁决过程:
  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. 来源与延伸阅读