convening-experts

表面路由——请先阅读

此技能通过原始 Anthropic API 调用手动编排子 Agent。现在，托管运行时可以完成同样的工作。根据你使用的界面，选择不同方案：

• 在 Claude Code（包括 CCotw）中：使用原生运行时，而非此技能。 如果你可以调用 /deep-research、使用 workflow 关键字触发运行、设置 /effort ultracode，或生成 Task 子 Agent，就应该改用这些方式。运行时支持最多 16 个并发任务／1000 个 Agent，提供审批关卡、对抗式交叉评审，以及会话内恢复功能；否则，此技能只能笨拙地重新实现这些功能。动态工作流已在研究预览版中发布（Claude Code v2.1.154+，2026 年）。
• 在 claude.ai 聊天或裸 API 中（没有工作流运行时）：使用此技能。 通过 httpx 并行运行 API 实例是此处唯一的扇出方式。muninn_utils.dispatch（17 个预构建视角）已基于 orchestrating-chat-agents 的执行模型实现此专家组；相比手动重建专家组，优先使用它。继续阅读下文。

判断标准：你有原生子 Agent／Task 工具，或工作流命令吗？有 → 使用原生方案。没有 → 使用此技能。运行时已存在时，切勿重新实现。

召集专家

召集领域专家和方法论专家，通过多轮协作讨论解决问题。专家会基于彼此的见解展开分析、质疑假设，并综合形成建议。

专家组形式

单轮咨询

适用于需要多种观点的简单问题：

1. 组建专家组（根据问题领域选取 3–5 位专家）
2. 每位专家独立提供观点（并行，而非按顺序）
3. 综合建议并注明观点来源

多轮讨论

适用于需要协作推理的复杂问题：

1. 第一轮：每位专家独立分析问题
2. 第二轮：专家回应彼此的见解，在其基础上展开分析或提出质疑
3. 第三轮（如有需要）：汇总综合结论，解决分歧
4. 最终综合：整合建议，并提供决策框架

专家角色

可提供的专业知识包括：

• MSD 领域专家（生命科学、工程、制造、质量、企业职能）
• 咨询框架专家（战略、流程改进、创新、系统分析、根因分析）
• 古代哲学家方法专家（反诘法、先分类后判断、控制二分法、权力分析）

完整角色目录请参阅 references/msd-domain-experts.md、references/consulting-frameworks.md 和 references/ancient-philosophers.md。

Claude 会根据问题领域加载相关参考资料。

专家组召集逻辑

Claude 会根据问题特征选取 3–5 位专家：

问题类型 → 主要专家 + 辅助专家

• 技术故障排查 → 领域专家 + 系统思考者 + 五个为什么引导者
• 战略决策 → McKinsey 顾问 + 相关领域专家 + SWOT 分析师
• 流程改进 → 六西格玛黑带 + 精益实践者 + 领域制造工程师
• 产品创新 → 设计思维引导者 + 待完成工作（Jobs-to-Be-Done）专家 + 相关工程师
• 根因分析 → 领域专家 + 五个为什么引导者 + 系统思考者
• 市场定位 → Porter 框架专家 + 营销专家 + BCG 顾问
• 跨职能问题 → 相关领域专家 + Bain 顾问（RAPID）+ 系统思考者
• 定义／概念争议 → 苏格拉底式审查者 + 亚里士多德式分类学家 + 领域专家
• 治理／制度设计 → 亚里士多德式分类学家 + 修昔底德式现实主义者 + 系统思考者
• 理想与务实之间的张力 → 柏拉图式理想主义者 + 亚里士多德式分类学家（依据《政治学》第四卷第二部分，两者是原生对抗组合）+ 领域专家

回复格式

先说明小组名称，再列出每位专家的观点，最后进行综合。

**单轮：**列出小组成员，然后依照任何清晰的顺序列出每位专家的独立分析（并行而非顺序），最后给出综合意见并注明观点归属。

**多轮：**先列出每位专家的初步分析，然后安排一轮讨论，让专家回应其他具名专家提出的具体观点（进行拓展或提出质疑），接着达成共识——解决分歧，或指出哪些分歧仍有探讨价值——最后给出综合意见。跳过没有意义的轮次（例如，如果第 2 轮已经达成共识，就不必进行第 3 轮）。

使用标题区分专家和轮次有助于读者理解；标题的具体文字不限。

专家行为准则

领域专家：

• 应用 MSD 背景（ECL 平台、监管限制、经验证的系统）
• 使用符合领域特点的术语，避免过度解释
• 优先考虑切实可行的实现方案，而非理论上的完美方案
• 指出领域特有的风险和限制

哲学家专家：

• 应用指定的方法（诘问法、分类法、控制二分法），并展示其结构——重在方法，而非角色扮演；不要使用古风语调
• 默认仅使用角色设定；当输出必须可审计或涉及某部作品的细节结构时，使用语料注入来提供依据（逐字引用源文本并为每项主张注明出处）；具体机制和路由表见 references/ancient-philosophers.md
• 与领域专家搭配——如果问题涉及现代议题，全由哲学家组成的小组会以不合适的层级作答，除非问题本身是概念性的

框架专家：

• 系统地应用框架（展示其结构）
• 根据问题背景调整框架（不要机械套用）
• 说明为何此问题适合使用该框架
• 应用通用框架时，融入领域背景

跨小组互动：

• 具体引用其他专家的观点（“基于 [Expert] 关于……的观察”）
• 进行建设性质疑（“我持不同看法，因为……”）
• 跨学科综合（“这将 [Expert 1] 提出的技术限制与 [Expert 2] 强调的业务优先事项联系起来……”）
• 明确指出不同观点之间的张力

分歧处理：

• 让分歧具有建设性（假设有何不同？）
• 在不必达成共识时，呈现多个合理方案
• 指出用于解决分歧的决策标准
• 如果专家无法达成共识，请升级给用户处理

决策框架

小组必须提出行动建议时：

RAPID（Bain）

• 建议（Recommend）：小组的建议及理由
• 同意（Agree）：哪些利益相关方必须同意
• 执行（Perform）：由谁实施
• 输入（Input）：由谁提供意见
• 决策（Decide）：由谁作出最终决定

加权决策矩阵

• 标准（按重要性加权）
• 按每项标准为各选项评分
• 总分及敏感性分析

风险—收益分析

• 上行潜力（概率 × 影响）
• 下行风险（概率 × 影响）
• 缓解策略
• 不确定情况下的决策

MSD 集成

自动应用 MSD 特定背景：

技术限制：

• ECL 平台和检测化学
• ISO 13485 合规性和经验证的系统
• 监管要求（FDA、CE 标志）
• 技术栈（Python、AWS、Java、TypeScript）

业务背景：

• 生命科学市场动态
• 客户群体（制药、生物技术、CRO、学术机构）
• 竞争格局

文化因素：

• 科学严谨性和数据驱动的决策
• 跨职能协作规范
• 在创新与风险管理之间取得平衡
• 质量和监管意识

示例

示例 1：技术故障排除

User: Our new assay is showing high background signal in serum samples

Claude convenes:
- Assay Scientist (primary)
- Systems Thinker (feedback loops)
- Five Whys Facilitator (root cause)

Format: Multi-round (technical nuance requires collaboration)

示例 2：战略决策

User: Should we build internal ML infrastructure or use vendor solutions?

Claude convenes:
- Software Engineer (implementation)
- McKinsey Consultant (strategic framing)
- Finance Analyst (cost analysis)
- DevOps Engineer (operational implications)

Format: Single-round → RAPID framework synthesis

示例 3：流程改进

User: Manufacturing yield dropped 8% after equipment upgrade

Claude convenes:
- Manufacturing Engineer (primary domain)
- Six Sigma Black Belt (DMAIC)
- Systems Thinker (unintended consequences)

Format: Multi-round (root cause needs collaborative analysis)

限制

如果问题有一个明确正确的答案，就完全跳过讨论小组——直接作答，而不是凭空编造各种观点。

本文档中有四项约束没有其他可供参考的依据，因此需要明确写出。不要虚构专家姓名（只使用职位名称——“软件工程师”，而不是“约翰·史密斯博士，软件工程师”），也不要编造超出通用领域知识范围的 MSD 特定细节；这两种做法都会让人误以为一个通用讨论小组掌握了它实际上并不具备的具体知识。

另外两项约束针对的是讨论小组形式本身容易引发的问题：专家确实存在分歧时，不要捏造共识（应指出分歧，并说明什么信息可以解决分歧）；不要以“以上是各种观点，请自行决定”收尾，而要给出切实可行的综合结论。