多 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 拆解:叶子任务的标准
一个叶子任务应该满足:3.3 分派:只给”需要知道的”
子 Agent 不应该继承 Lead 的完整对话历史。原因:- 成本:历史 token 乘以 N 个专家。
- 噪声:无关讨论会干扰判断,甚至让专家重复已排除的方案。
- 一致性:不同专家看到的历史版本不同,产物会互相矛盾。
3.4 汇总:合并产物,不合并口水
汇总要做的是下面几件事,单纯把几段自然语言拼在一起不够:- 契约校验:每个产物是否符合 schema、是否带证据、是否满足验收。
- 冲突检测:同一事实是否出现不同数值/结论;同一约束是否被不同专家解释。
- 依赖检查:下游是否使用了上游的旧版本。
- 异议保留:少数意见必须进入决策记录,不能被”综合”掉。
- 最终产物:由 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:专家之间传”东西”,不传”感觉”
5.2 Manifest:一次任务的总账
5.3 交接契约
5.4 版本与回滚
- 语义化版本:
major.minor.patch,破坏契约升 major。 - 父指针:每个版本记录上游版本,支持追溯。
- 回滚粒度:单个 artifact、单个任务节点、整个 run。
- 决策绑定:决策记录引用具体 artifact 版本,不能引用”最新版”。
- 废弃策略:旧版本标记 deprecated,但不删除,保留审计期。
5.5 评审意见的结构化
Lead 汇总时按
blocking 和 severity 排序,而不是按专家资历排序。
6. 成本与延迟:专家团不是免费的
6.1 成本公式
6.2 延迟公式
6.3 成本控制杠杆
6.4 什么时候不值得上专家团
- 任务 10 分钟能做完,协调要 30 分钟。
- 只有一个专业面,不存在交叉验证需求。
- 实时性要求高,用户等不了多轮评审。
- 错误代价低,返工比评审便宜。
- 没有验收标准,评审只能凭感觉。
- 没有预算和轮次上限,专家团会无限膨胀。
7. 两个完整场景走查
7.1 场景一:技术方案评审(订单中心拆分)
目标:评审”订单中心从单体拆分为独立服务”的方案,输出是否放行的决策。 任务树:
冲突案例:
- 方案专家主张”同步双写”保证一致性。
- 性能专家指出双写会把下单延迟放大 30%,且故障时可能拖垮主链路。
- 安全专家要求所有跨服务调用可审计、可追溯。
- 证据优先:性能专家给出压测数据,方案专家的”一致性更好”是定性判断。
- 约束优先:审计是硬约束,不能投票取消。
- 取舍:采用 outbox + 最终一致 + 对账补偿;跨服务调用统一 trace;双写只保留一个迁移窗口。
- 风险接受:接受短时不一致,设置对账告警和人工补偿。
- 决策记录:写明”为什么不是同步双写”,以及回滚条件。
- 所有 blocking findings 关闭或有明确风险接受人。
- ADR 包含失败模式、回滚方案、监控指标。
- 关键数值有压测/容量依据。
- 异议进入决策记录。
- 人工 CTO 签字放行。
7.2 场景二:投研报告生成(新能源车企)
目标:生成一份可对外发布的研究报告,覆盖行业、公司、财务、估值、风险。 任务树:
冲突案例:
- 行业专家看多:渗透率提升、出口增长、新品周期。
- 财务专家看空:价格战导致毛利率下滑,现金流承压。
- 估值专家给出两种情景,差异巨大。
- 事实层先对齐:销量、单价、毛利率、现金流必须用同一口径。
- 逻辑层分开:行业增长不等于公司盈利,必须通过单位经济模型连接。
- 情景化:给出乐观/中性/悲观三档,而不是强行给一个目标价。
- 保留异议:报告明确写出”多空分歧点”和触发条件。
- 合规 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 产品文档:专家(2026-10-15):专家 = 人设 + 方法论 + 工具链;专家团 = 团长拆解、并行执行、整合交付;专家不主动获取系统权限。
- 腾讯云 WorkBuddy 产品文档:专家管理(2026-11-13):企业专家分类、可见范围、下发策略、调用统计。
- 腾讯云开发者社区:WorkBuddy Enterprise 产品功能(2026-08-04)。
- Agent Patterns Catalog:Generator-Critic Separation(2026-05-23):评审只输出结构化 findings,不生成、不重写。
- Future AGI:Evaluating AutoGen Agents: The Handoff Is the Unit(2026-03-07,2026-05-20 更新):交接误解、角色漂移、群体一致性崩塌。
- arXiv:Jev-LiteMAS: Separating Decisions from Generation in Multi-Agent Workflows(2026-10-15):路由与评审占生成式 token 的 31.7%-43.5%。
- IEEE/ACM ASEW 2025:Traceability and Accountability in Role-Specialized Multi-Agent LLM Pipelines(2025-11-16):结构化交接、角色专属强弱项、可追溯与问责。
- LangGraph 多智能体图架构教程:Multi-Agent Graphs: Supervisor, Specialist, and Handoff Architectures(2026-07-27):状态所有权、显式交接、监督者边界。
