mixture-of-experts

专家混合（MoE）审计

专家混合模式是一种强大的批判性思维框架。它通过要求多个独立的“专家角色”从截然不同的角度分析同一个主题，然后交叉比对他们的发现，来避免视野局限。

它几乎适用于任何场景：代码库、功能计划、部署流程，或仓库的治理技能。

使用时机

• “使用专家混合模式评审这份架构计划”
• “我们是否有意图重复的技能？”
• “审计此部署脚本的安全性和性能”
• 遇到复杂的设计决策，需要严谨、多角度的批判性评估。

工作流

1. 确定主题 了解用户想要审计的内容（例如“仓库技能重叠”“新的缓存架构”“发布流程”）。

2. 定义专家角色 设定 2-3 个专业领域各异的专家角色，其视角与主题高度相关。只有在用户明确要求广泛覆盖子 Agent，或各领域确实相互独立时，才使用 3 个以上；默认最多为 4 个。不要启动 Agent 来复述主计划。 为每位专家撰写简短的职责约定：

   • Role：批判性视角。
   • Scope：要检查的证据或子系统。
   • Out of scope：不得作出决定或编辑的内容。
   • Expected output：发现、矛盾之处或制品建议。
   • Fallback：如果该视角超时或只返回部分证据，应如何处理。
   • Integration contract：其发现会影响的具体文档、检查项、技能或代码部分。 示例：
   • 对于仓库治理：“代码库审计员”、“技能分析师”
   • 对于系统架构：“安全专家”、“可扩展性工程师”、“成本分析师”
   • 对于前端组件：“无障碍审计员”、“性能专家”
   • 对于产品声明或外部平台支持： “证据 / 验证 QA”。此视角会询问：提出了什么声明、哪些证据能确切证明该声明、需要怎样的验证或来源时效性，以及哪些内容不构成声明。当讨论涉及平台支持、生成的资产、跨仓库清理、基准测试证明、公开兼容性或外部 API 时，请使用此视角。
   • 对于证据档案、PDSA 循环、dogfood 笔记、模板和证明包： “证据 / 保留 QA”。此视角会询问：该产物属于 ADR、当前台账、历史证据、公开可复现卡片、模板、检查 / 工具候选项，还是待删除项；它用于维护者分流、当前状态、历史溯源，还是公开审计；它保护什么声明；是否标明了状态 / 类型 / 限制 / 不作出的声明；以及怎样处理后续事项才能避免证明过时。当讨论涉及这些内容时，请使用此视角。
   • 对于 E2E 执行与评估（Dogfooding）： “Harness QA 专家”。当工作流、工具链、类型化操作或基准测试循环发生变化时，请加入 Harness QA 视角。条件允许时使用子代理；否则按顺序运行该视角，并注明这一点。如果变更声称达到 H2+ 成熟度，或改变了操作 / 基准测试行为，请在最终摘要或 PR 摘要中记录一份审查产物：范围、所用仓库、执行的命令 / 操作、达到的证据级别，以及仍未证实的内容。仅涉及文档对齐时可使用较为宽松的措辞；除非变更影响就绪声明，否则无需单独记录审查产物。
   • 对于维护工作、工具、harness 或不断发展的产品： “代际架构质疑者”。此视角会询问：哪些内容可以删除、合并、保留为原生实现、移至文档 / FAQ、提取为公开 API、根据架构生成，或提升为 harness 证明；设计究竟能否帮助下一个仓库、下一个 Agent、下一个版本和下一位维护者，还是会造成路径魔法、仅供单一使用者使用的变通方案、过度声明、“全面采用”偏移，或工具依赖循环。清晰的承诺是：Skill Steward 帮助仓库发现何时已超出现有形态，选择最小的下一层，并证明此变更能减少未来工作。
   • 对于停滞的 PDSA、反复出现的阻塞因素、证据循环或仓库痛点： “循环压缩 / 痛点辅导员”。此视角会询问：原本的用户目标被什么拖延、现在可以修复哪个负责人、哪个原生门禁能证明修复有效、哪些界面可以移除，以及该痛点是否应转化为错误消息、FAQ 条目、测试、架构、脚本、操作候选项或当前台账更新，而不是再增加一份证据产物。

3. 启动子代理 使用当前宿主环境提供的子代理能力，独立启动这些专家。向他们提供明确提示词，让他们从各自的特定视角审查目标主题。除非用户明确要求实施，否则保持只读视角为只读。如果没有可用的子代理工具，则按顺序运行专家视角，并将输出标记为非并行 MoE。

4. 交叉核对发现 等待所有子代理返回报告，或在声明的回退点停止。综合各自独立的评审意见。查找结构性矛盾、遗漏的边缘情况、维护陷阱，以及（对于仓库技能）意图重复。如果某个视角超时或返回的证据不可用，请标记为 missing_lens、partial_lens、timed_out_lens 或 superseded_lens；然后重试、降低置信度后继续，或说明缺失的视角会妨碍提出更有力的声明。只要 MoE 结果会影响实施、证据或就绪声明，就加入简洁的视角状态摘要。

   视角状态摘要示例：

   | Lens | Status | Integration |
   |------|--------|-------------|
   | Evidence QA | integrated | limited the claim ceiling |
   | Operations QA | partial | accepted as input, not proof |
   | Skeptic | timed_out | no stronger claim based on this lens |
   

   Skeptic 视角处于启用状态时，在建议新工具之前，先指出最小的有效层级以及任何删除／合并选项；对于宽泛的表层形态问题，还要指出有效做法是拆分、压缩、提升、降级、删除还是保持原样。Evidence / Retention QA 视角处于启用状态时，在建议新增证据之前，先指出产物状态、受保护的主张以及保留／处置路径。如果批评意见会改变持久文档、技能、契约或工具，应在 docs/evidence/ 下创建或建议创建 Pattern Promotion Review，而不是制定新原则。 对于广泛的仓库问题，MoE 可以发现可能的分工候选项以及不同分工之间的矛盾。这些发现仅作为建议性批评输入；它们不授权写入、不分配工作者、不接受结果，也不取代上级综合。上级分工契约和直接修复权限属于 multi-agent-handoff。

5. 选择输出模式

   • 只读批评模式： 如果用户只要求分析、讨论、批评或验证，则在聊天中总结发现。不要创建文件或计划。
   • 实施规划模式： 如果用户要求制定计划或实施已批准的更改，则拟定简明的实施计划或学习产物。
   • 执行模式： 如果用户明确批准实施，则应用范围最小的更改并进行验证。如果跳过或无法进行验证、生成器检查或新鲜度检查，则记录未运行的确切命令、原因，以及因此无法证实的主张。

6. 向用户呈现 先列出关键发现、矛盾和可执行的建议。综合结论以以下一种处置方式结尾：

   • chat_only：有用的批评意见，无持久更改。
   • promote_to_artifact：更新 ADR、FAQ、证据说明、技能、文档地图或 Pattern Promotion Review。
   • convert_to_check：应将重复出现的确定性事实转化为测试、验证器、生成器新鲜度检查或测试框架探针。
   • compress_existing：合并重叠的指南或导航，同时保留下级内容中的事实。
   • delete_or_retire：在有用信息已在其他位置留存后，删除过时的指南、证据或脚手架。
   • leave_native：将工作保留在仓库现有的命令、框架或负责人界面中。

   如果 MoE 得出的结论需要实施，应通过 multi-agent-handoff 交接执行，或由上级负责，并明确主张范围上限。MoE 发现本身不是最终分工状态，也不会让临时或工作者的证明成为源归属证明。 只有当下一步会修改文件或扩大范围时，才征求批准。

精简规则：为独立性而启动，为矛盾而综合，只持久化会改变未来行为的内容。

安装

npx skills add arenukvern/skill_steward --skill mixture-of-experts

来源

参见 references/sources.md。