「要不要装一个专家库」这个问题的答案不是「要」或「不要」而是「你现在缺的是哪一块」。DSH 里能拿到「另一个视角」的路径至少有三条装michengai/dsh-agency-agents站内显示名「专家智能体库」这样的专家库插件、自己写子代理提示词、以及把流程固化成自定义 SKILL。三条路不互斥但成本结构完全不同——另外先说清身份它 README 写明是社区维护产品并非 DeepSeek AI 官方出品。选型前建议先看一眼 完整插件清单与汉化避坑指南把同类插件的边界摸清楚再决定。三种方案各自解决什么问题方案你付出什么你得到什么专家库插件装一个社区插件接受它的角色粒度开箱可用的固定角色按分类管理、按需启用自带子代理自己写提示词、自己保证一致性完全贴合自己项目的角色定义自定义 SKILL维护文档、脚本与模板可复用、可版本化的固定流程三者最本质的差别是专家库给你的是已经被写好的角色子代理给你的是自己定义的角色SKILL 给你的是可重复执行的流程。角色和流程是两件事混在一起谈最容易选错。什么场景该用专家库判断标准是你要的是一个固定角色的专业分析而且这个角色的定义你不想自己写。代码审查、安全评审这类有成熟方法论的角色直接召唤比从零写提示词快需要横向覆盖很多领域工程、设计、市场、财务、法务、游戏、GIS 等 22 个分部逐个自建不现实需要「先启用再使用」的管理面设置 → 专家里可以启用、停用、复制、新建只搜已启用的专家选择器搜索则能翻到停用的需要一组视角而不是一个视角时用内置专家团产品方案评审团、技术方案评审团、内容选题策划团、数据分析诊断团、专题研究专家团或者自建28 位成员的团最多保存100 个。有一条边界要提前接受专家不会继续召唤其他专家。它给你专业分析汇总由主会话完成。什么场景该自己写 SKILL如果诉求是「每次都要按同一套步骤做」专家库解决不了SKILL 才是对的工具流程里有确定的步骤、产物和检查项需要每次都一致需要带上脚本、模板、目录约定而不是只带一段提示词需要跟着仓库走、被评审、被版本化规范是团队私有的市面上的通用角色并不贴合。反过来说如果只是一个「视角」需求——比如「帮我从安全角度看看」——写一整个 SKILL 就过重了。什么场景直接在主会话做上下文已经全在主会话里再委派反而要重新交代一遍一次性、小范围的改动委派的往返成本高于收益需要连续多轮追问、边聊边改你需要的不是独立视角而是把你已经想清楚的事执行掉。判断起来其实很简单当你不需要「另一个人格」就不要引入另一个人格。provider 的 spawn 与 fork 怎么选配置表里provider默认是spawn。fork也可用但有一个硬前置该 provider 需要支持 persona 与工具过滤。这条限制的后果很实际——如果换到一个不支持这两项能力的 providerpersona 会失效角色的系统提示注不进去工具过滤也没了。所以换 provider 前先确认这两项能力别只看「fork 看起来更轻」就换。另外两个与选型相关的点成员继承主会话的模型选择没有 per-expert 的模型设置maxDepth默认未设置显式设置时会走普通模式以保留深度限制。不做递归委派省心的地方与受限的地方好处结果可归因、成本可预期专家不派活链路的终点永远是主会话。带来三个好处结果可归因一份结论对应明确的分析来源、成本可预期不会因为某一层再展开而指数级膨胀、汇总统一主会话负责核对证据与处理分歧最后交付一份结果。配上summon_experts一次最多 8 个专家、并发 4、部分失败仍返回成功结果可控性其实相当高。代价多层协作要自己编排如果你要的是「架构师评审完安全专家基于架构师的产出接着看」这条链得由你自己用list_experts(division?)与summon_expert(expert, task)编排顺序。插件不会自动加分析轮次也不会替你接力。想清楚这一点再决定要不要为「多层」付费。数字口径不一致带来的选型沟通成本这是实际会影响到你写选型文档的一点站内详情页与包描述、README 开头标注的是321名可召唤的专业智能体README 的「Expert roster」章节写的是331bundled experts across22 divisionsFeatures段落又回到 321。同一份 README 里两个数字并存。后果是如果你在评估表里写「三千多个」或缺省写死一个具体数字评审时很容易被追问来源而且你没法自洽地回答。建议的写法是注明「站内与包描述标注 321 名README 名册章节写作 331 名、分 22 个分部两处口径不一致以官方口径为准」。这条沟通成本很小但不写就得反复解释。决策速查要固定角色的专业分析→ 专家库插件要固定流程与产物→ 自定义 SKILL上下文与执行都在手边、不需要新人格 → 直接主会话做要多层接力→ 自己编排summon_expert调用顺序别指望插件递归宿主不在白名单尤其 0.1.6 / 0.1.7 alpha→ 先解决宿主版本再谈选型。总结选型的落点其实就一句话专家库买的是「现成的角色」SKILL 买的是「稳定的流程」主会话买的是「零额外成本」三条路的边界清楚了剩下的就是看你当下缺哪一块——完整插件清单与汉化避坑指南 里还有同类插件的对照能帮你把「角色」和「流程」这两类需求分开看。适合与不适合适合团队里需要稳定产出「风险清单 / 验收清单 / 选题方案」这类固定角色分析的人不想自己维护几百条角色提示词、希望按分类启用管理的用户需要在多个分部之间横向取视角、又接受主会话统一交付的评估场景。不适合想靠它搭多层级智能体流水线的团队——不做递归委派接力得自己写把角色定义当作核心资产、要求逐字可控的人用专家库不如自己写提示词宿主版本不在白名单里的人尤其还在 0.1.6 / 0.1.7 alpha 上的安装装不上就谈不上选型对数字口径必须唯一、无法接受「321 与 331 并存」的正式评审文档建议先自行核实再引用。标签专家智能体库、DeepSeek Harness、选型对比、SKILL、子代理本文由 DeepSeek Harness Hub 自动整理数据来源于插件详情页。