dsh-subagents 是一个为 DeepSeek Harness (DSH) 设计的插件。它的核心作用是让你能够用 Markdown 文件定义各种专业的“角色”（比如代码审查员、测试编写员等），并将这些角色变成主模型可以随时调用的“子代理”工具。
它的主要特点在于灵活的运行方式和便捷的管理。
核心价值：为何需要它？
- 为特定任务指派专属模型：主模型（可能很贵）可以委派任务。比如，让一个便宜的模型（如 glm-5.3-flash）去执行代码审查，而主模型则专注于更核心的推理工作，能有效节省开支。
- 任务委派与解耦：将“例行公事”委托给专门的子代理，能保持主模型上下文清晰，避免token和注意力被无关任务消耗。
- 集成外部 CLI 工具：它能调用 cmdc, pi, agy, claude 等外部命令行工具，把它们也变成一个可用的子代理，大大扩展了能力边界。
⚙️ 核心特性与工作原理
- 定义即工具：在 ~/.dsh/agents/ 目录下创建Markdown文件。文件头的 frontmatter 定义角色属性（名称、描述、使用的模型等），正文则是该角色的系统提示词。文件保存后，该角色就会变成一个名为 agent_* 的工具供主模型调用。
- 两种运行模式：
- 模型驱动 (Model-backed)：让子代理在指定的模型路由上运行。可以在后台运行，不阻塞主对话。
- CLI 驱动 (CLI-backed)：通过外部 CLI 执行任务。适用于想用 claude 命令行或 agy 等工具的场景。CLI 角色始终在前台运行。
与 ZCode 的主要区别
作者在 README 中专门列出了它与类似项目 ZCode 的区别：
- CLI 支持：dsh-subagents 支持将外部 CLI 作为子代理，而 ZCode 不支持。
- 热加载：dsh-subagents 修改定义后无需重启会话，ZCode 需要。
- 配置方式：dsh-subagents 以文件为配置源，ZCode 有专门的设置界面。
介绍
这个dsh-subagents的插件做的事听起来很简单：让你用Markdown文件定义一堆“角色”，然后主模型可以随时把这些角色叫出来干活。代码审查员、测试编写员、文档调研员——你写一个文件，它就变成一个工具。
这个不起眼的插件捅破了一层窗户纸，AI推理成本正在失控，而你完全可以把其中一大半省下来。
顶级模型干杂活，等于让资深架构师去搬砖
先看一个基本事实。你跟AI模型聊天，每说一句话，模型都要“想”一下怎么回你。这个“想”的过程叫推理，按token计费。模型越大越聪明，每个token就越贵。DeepSeek最新的V4 Pro模型能力很强，但调用一次的成本是轻量模型的几倍到十几倍。
一个典型的AI编程会话，你让模型帮你写登录页面。模型先写HTML，再写CSS，再写JavaScript，然后自己检查bug，跑测试，最后补文档。这一套流程里真正需要顶级智力的是哪个环节？设计整体架构。剩下的全是体力活。但你付的钱按顶级模型的token价算。
OpenRouter在2026年6月的博客里算过账：主模型用Claude Opus 4.8，输入每百万token花5美元、输出花25美元。干活的子代理用GLM 5.2，输入每百万token只要1.40美元、输出只要4.40美元。同一个任务，每个token的计价差了三到五倍。让主模型亲自跑测试写文档，等于让资深架构师去搬砖，搬一块砖给一份架构师的时薪。
2026年7月ICML发表的AgentRouter论文给出了一个让人没法忽略的数据：相比全程只用最贵的前沿模型，动态路由可以把成本降低72%，任务完成率只下降了不到3%。72%——你花在AI上的钱，有一大半可以省下来。
主模型的办公桌只有那么大，堆满杂活就放不下正事了
成本之外还有另一个问题。上下文窗口就是模型一次能记住多少字。DeepSeek的模型支持100万token以上，听起来很多。但如果你让主模型一边写代码一边跑测试一边审查代码，所有中间输出全塞在上下文里。处理每条新消息时，模型要从100万token里找到跟你当前问题最相关的那几百个，越来越慢。真正重要的信息，你最开始的需求、整体架构设计，被大量琐碎输出淹没。
Subagent就是来解决这个问题的。DeepSeek Harness官方文档的定义很直白：让一个agent把工作委派给子agent。主模型当项目经理，把具体任务甩给专门干某一件事的子代理。每个子代理有自己的上下文窗口、系统指令、工具集，干完活只把结果摘要返回给主模型。
这就像一张办公桌只能放那么多东西。测试报告、审查意见、文档草稿全堆上，桌子很快就废了。子代理让这些东西不出现在主模型的桌上。子代理在别的房间干活，干完了贴一张便签回来：“测试通过了”“审查完了，有三个小问题”。主模型的桌子始终干净。
dsh-subagents把角色定义的门槛降到写备忘录的水平
这个插件具体怎么用？在~/.dsh/agents/文件夹里放Markdown文件。文件开头有一小段YAML配置叫frontmatter，后面是这个角色的系统提示词。
比如你建一个reviewer.md文件：
name: reviewer
description: 审查代码或diff，找bug、风险、遗漏的测试
model: bai/glm-5.3-flash
tools: [bash, read, grep]
disallowedTools: [write]
你是一个代码审查子代理。请仔细阅读下面的代码变更...
frontmatter里写上角色名叫reviewer，描述是审查代码找bug和风险，模型指定为便宜的bai/glm-5.3-flash。正文写“你是一个代码审查子代理”。保存，插件自动把文件注册成agent_reviewer工具。你跟主模型说“帮我审查这段代码”，主模型看到工具描述就会调用它。
插件有两个重要设计。第一个是热加载。你修改了reviewer.md，不需要重启会话甚至不需要刷新页面，下一轮对话里改动就生效了。ZCode的自定义子代理修改之后需要新建会话，dsh-subagents把这一步省了。会话里发现某个角色的提示词写得不好，当场改文件，下一句话就用新版本。
第二个是两种运行模式。模型驱动模式：子代理通过DSH调用指定的LLM路由，frontmatter里写model: bai/glm-5.3-flash，每次被调用都用智谱的GLM而不是主模型的贵家伙。CLI驱动模式：子代理不调用DSH模型路由，直接执行外部命令行工具，写cli: agy就启动agy进程。模型驱动模式下子代理默认在后台运行，主模型调用完不用等结果，可以继续干别的事，子代理跑完了以通知形式发回来。多个后台子代理可以并行跑。
你写的每个Markdown文件都等于给AI团队加了一个专职成员
以前给AI定义新角色，要改系统提示词、调参数、配工具权限，一套下来半小时。dsh-subagents的做法是写文件，自动变成工具。改角色就是改文件，增删就是增删文件。用下划线开头命名文件就能禁用角色，不用删。
每个角色指定自己的模型。你可以维护一个角色库：代码审查用便宜的GLM，架构设计用最强的DeepSeek V4，测试编写用中等价位的模型。主模型根据任务类型自动选择角色，也就自动选择了模型。AgentRouter论文用算法做路由，dsh-subagents的做法更朴素：用户自己定义角色、绑定模型，主模型根据工具描述自己做选择。工具描述写得好，主模型就知道什么场景用什么模型。
项目自带了一套现成的角色库：代码审查员、安全审计员、Flutter开发者、ASO专家、UI设计师、编排器。装完插件运行安装脚本就能直接用。编排器这个角色最特别，它的职责不是亲自干活，而是制定执行计划，然后指示其他角色去执行。主模型只需要调用编排器一次，它自己调度整个团队。复杂的多步任务可以完全自动化。
主模型根本不知道背后是谁在干活，Claude Code和Gemini CLI都能装进来当插件用
CLI驱动模式打开了更大的想象空间。写cli: agy，每次调用启动agy进程，agy是Google的Antigravity CLI，底层跑Gemini。写cli: claude，角色启动Claude CLI。写cli: cmdc，启动cmdc，一个免费支持多种模型的命令行工具。
你的DeepSeek Harness主模型可以通过子代理间接调用Gemini、Claude和其他任何支持命令行的模型。用DeepSeek的框架，同时跑Google和Anthropic的模型。这些调用被封在“角色”这个抽象层底下，主模型不知道也不关心agent_translator背后是哪个模型。
2026年8月19日DeepSeek Harness发布了v0.1.0-rc.8，把Claude Code和Codex做成了可按需安装的Profile Bundle。dsh-subagents的CLI驱动模式做的是同一件事，但它不限制你用哪个CLI。agy也行，claude也行，cmdc也行，谁支持命令行谁就能被装进来。
插件处理CLI调用时还有一个自我修复：某些思考模型不支持--effort参数，配了会报错退出。运行器检测到错误会自动去掉参数重试一次，不用手动处理兼容性问题。
其他有五个同类插件，说明子代理委派是整个DSH生态的真实痛点
dsh-subagents只是DSH子代理生态里的一个。过去一周GitHub和npm上至少冒出了五个相关插件。
- dsh-subagent-library在设置页维护角色，模型通过工具完成选人和派活。
- dsh-custom-subagents把角色保存成可复用定义，主Agent用delegate_agent工具调用。
- dsh-subagent-pool在设置页维护一批子代理，主代理按描述判断什么时候用谁。
- dsh-subagent-pi把Pi注册成原生子代理提供者。
- dsh-subagent-inspector是一个只读监视器，在会话标题栏展示子代理的推理、工具调用、耗时和token用量。
同一个概念不到十天被不同的人用不同方式实现了五遍。这说明让主模型把任务委派给子代理这件事，是DSH用户群体里一个真实的、普遍的痛点。大家都觉得原生缺了点什么，都在用自己的方式补。
每个子代理调用都留下一条活动记录，右下角实时显示谁在跑、跑了多久
活动面板是另一个细节。插件后台追踪每一次子代理运行：角色名、任务内容、已耗时、当前阶段、结果预览。这些信息通过接口暴露。管理器面板打开时每两秒轮询一次，显示实时滚动的活动列表：哪些在运行、最近20条记录、CLI队列深度。
任何时候有子代理在后台跑，屏幕右下角浮出小角标——“N个子代理运行中”。点一下角标直接弹出管理器面板。后台任务跑起来之后你知道它跑完了吗？跑得怎么样？活动面板给了实时仪表盘。不用在对话里追问“刚才那个审查跑完了吗”，看一眼右下角就行。活动记录跨会话持久化，关掉再打开还在。对调试和复盘很有用，可以回头看看上一次审查花了多久、返回了什么结果。
廉价模型在特定任务上可能并不比昂贵模型差多少，但这个账还没人仔细算过
dsh-subagents默认示例角色里，大部分路由是bai/glm-5.3-flash，智谱的轻量模型。这是个刻意的选择。代码审查、测试编写、文档翻译这类任务，真的需要最顶级的模型吗？
OpenRouter在2026年6月的博客里提到，一个有20次工具调用的复杂工作流里，可能有5到8次是子代理委派——摘要、数据提取、模板填充、格式转换。这些任务都不需要顶级模型的推理能力。
缺少的是精确的数据。廉价模型在子代理任务上的表现到底比顶级模型差多少？差的那点值不值得省下72%的成本？dsh-subagents的文档里没有。学术论文里的路由研究用的是标准基准测试，不是真实代码审查场景。目前唯一确定的是，让主模型亲自干所有事，付的是顶级模型的价格。把杂活甩给子代理，不管用什么模型，至少省下了主模型处理杂活消耗的token。省了多少、牺牲了多少质量，这个账还没人仔细算过。
DeepSeek Harness的插件生态刚刚开始。dsh-subagents是第一个把ZCode风格角色定义搬进DSH的插件，但肯定不是最后一个。下一个插件会怎么处理子代理的模型选择？会不会有人做自动路由，根据任务复杂度动态决定用哪个模型？会不会有人把活动数据和可观测性整合在一起做出完整监控面板？