DSH 尝鲜：用自定义 Plugin 构建工作Agent
返回博客列表
这两天最火的就属于 DeepSeek Harness 了，我也忍不住用它做了一组 Plugin，尝个鲜，看看能不能做出工作场景 Agent 的效果：能真正指挥它做事，也能让它自己动起来；而我呢，尽可能腾出更多时间用来思考沉淀——正如下图所示的「召唤者」模式 😁
现在打开，左侧边栏十来个入口：Plugins、Automation tasks，再往下是我写的十个，今日待办（Daily To-Do）是第一个。点开它，今天的任务已经分好组：左边是「只有你能做」「AI 干着 / 待审」「排期 / 批处理」「插件候选」，再往下是今天做完的，右边每张卡片写着为什么排这个位置。
两天前不是这样。同样八点二十，我打开的是一个空白对话框，得先告诉它我是谁、手上有哪个客户、今天想干什么，说到第三句自己先烦了。
- 🧩 Plugin 机制：DSH 是什么，四家的 Plugin 机制对比
- 🧭 定制方法：给工作场景定制 Plugin
- 🪞 体验变化：使用 DSH Plugin 之后，用起来有什么不同
- 🕳 还不够好的地方：界面起不来、模型排队、事件层缺席、企业数据接不进来
一、DSH 及其 Plugin 机制
DSH 是什么
DSH（DeepSeek Harness）是一个跑在本地的 agent 运行时。它自带的是一批通用工具（读写文件、跑命令、待办、定时这些），业务能力来自一份可组合的配置（DSH 里叫 profile）：装哪些 Plugin、每个 Plugin 挂什么，启动的时候按顺序叠起来。
拆开看，它给我这几样东西：
| 能力 | 具体是什么 | 我用它干什么 |
|---|---|---|
| 工具 | 注册一批可被模型调用的函数，带参数校验和输出格式 | 让 agent 能读写文件、跑命令、调飞书 |
| agent preset | 一份 persona 加一套专属工具集，开新会话时选 | 换一种「想事情的方式」，比如按 SDD 流程走 |
| 面板 | 侧边栏一个入口加一块界面 | 有个地方能看、能点，不用每次都打字 |
| 定时 | 挂在某个会话上的定时任务 | 到点在那个会话里跑一段 |
| 存储 | Plugin 自己的数据文件 | 记住工时、状态、待审队列 |
| 路由 | Plugin 自己开的 HTTP 接口 | 面板和后台交换数据 |
🧩 一个 Plugin 的最小构成
先说最小。如果只是声明几个 agent，两个文件就够；要带工具或面板，再往上加。
| 文件 | 干什么 | 什么时候需要 |
|---|---|---|
package.json | 声明自己是个 Plugin 包，patch 在哪个文件 | 必须有 |
cordis.patch.yml | 往配置里插行：Plugin 本体、agent preset、技能目录 | 必须有 |
index.js | Host 侧的逻辑，跑在宿主进程里（和界面渲染进程分开的 Node 进程） | 要注册工具、定时、存储、路由时 |
client.js | 面板，浏览器里手写的 React，没有构建步骤 | 要有侧边栏界面时 |
locale/zh.json、en.json | Plugin 列表页显示的标题和描述 | 要出现在 Plugin 列表里时 |
拿 Blog Writer 举例：它的 index.js 只有 11 行，apply 是空的，一行服务都没注册。但它是完整的一个 agent，persona 全文写在 patch 的 preset 行里，工具集、时间上下文、技能目录也在那一行。
所以做 Plugin，代码量往往不多，花时间的是配置：写清它是谁、能用什么工具、上下文塞到多满。
📊 四家的 Plugin 机制对比
Claude Code 和 Opencode 的 Plugin 我都配过；Codex 我主要用 MCP 和 AGENTS.md，没见到 marketplace 那种 Plugin 包。四家放一张表里看：
| Claude Code | Opencode | Codex | DSH | |
|---|---|---|---|---|
| Plugin 是什么形态 | 一个包，打包命令、子 agent、技能、hooks、MCP | 一个 JS/TS 模块，导出一组 hooks | 我用法里靠 MCP、AGENTS.md，没有 Plugin 包 | 一个包，带一份配置 patch |
| 扩展点 | 斜杠命令、子 agent、hooks、MCP | tool.execute.before/after、session.*、permission.*、tui.* 等事件，加自定义工具 | MCP 工具、规则文件 | 工具、preset、面板、定时、存储、路由 |
| 能改到多深 | 工具调用前后、上下文注入 | 同上，另有压缩钩子可以改 | 工具层 | 连模型适配器、压缩策略、agent 循环都能替换 |
| 长什么样 | 终端命令 | 终端 TUI | 终端命令 | 桌面应用，带侧边栏 |
| 怎么分发 | marketplace 安装 | npm 包或 .opencode/plugins/ | 配置里写 MCP | 本地包，装进 profile |
区别主要在「能改到多深」这一行。前三家的插件接口能拦工具调用、能加工具、能改上下文，但改不了 agent 一轮一轮往下走的那套循环，要动它得改源码或者换产品。DSH 把这一层也交出来了，Plugin 可以换模型适配器、换压缩策略，甚至替换 agent 循环。
代价是这边没有稳定的内核边界：前三家的 Plugin 只在口子上挂东西，DSH 这边改配置就是在改环境，第四节那些坑很多是改配置改出来的。
🛠 我上手的过程
我的做法是先搬再改。Opencode 里常用的 skills 和 agent 大多是现成的，搬过来配好 persona 和工具，先凑成一个能跑的 Plugin；跑起来之后再一点点优化——补个面板、加条定时、把常改的参数抽成配置。SDD 那几个就是这么来的。
安装我试过两种。一种是让 Plugin 管理器装：给它一个包目录的绝对路径，它替我在 profile 里装依赖、改锁文件、写进组合清单。另一种是手工把包软链进 profile，再自己往列表里加一行，也能用，就是容易漏步骤。
装完要不要重启，看改的是哪半。面板那半（client.js）刷页面就行；index.js、patch、preset 这些 Host 侧的东西，得重启才会重新组装。
Blog Writer 是最省事的一个：Host 侧没有实际逻辑，只把 persona 和技能目录配好就能开工。做到现在我也没给它加工具，够用了。
二、给工作场景定制 Plugin
从常用场景到 Plugin
动手之前我先问自己两件事：最常用的工作场景是哪几个？这些场景以前有没有沉淀成 skill？
第二个问题的答案是有，而且不少。我这几年的工作成果大多是文档，很多场景早就写成了 skill 或者 agent 定义，比如 SDD 的端到端交付、给企业做 AI 场景规划那套四步法。所以做 Plugin 的时候，大部分功夫花在搬东西和配工具上，写代码只占一小块。
按场景排下来是这样：
| 常用场景 | 之前沉了什么 | 做成的 Plugin |
|---|---|---|
| 产品与研发的端到端交付（SDD） | 六个角色的 agent 定义 | SDD 团队（SDD Team）+ PM 工作台 |
| 企业 AI 场景规划与落地 | 四步法加一批 skill | FDE 工具箱 |
| 方案或决策定稿前找人挑毛病 | grilling 那组 skill | Grilling |
| 做培训课件 | 课件设计的 agent 和子技能 | 课件设计 |
| 给客户出方案 | 两套报价口径加一个 Deck 模板 | 售前方案 |
| 面试评估 | 材料整理、评分、复核三个 skill | 面试评估 |
| 写东西 | 写作流程和排版的那几个 skill | Blog Writer |
| 每天的事情怎么安排 | 以前没有，靠脑子记 | 今日待办 |
| 报销前整理发票 | 以前没有，靠手点 | 发票整理 |
十个 Plugin 对着九个场景：七个是把已有的沉淀搬进来，今日待办、发票整理、PM 工作台是新建的。
下面按场景一个一个说。一件事值不值得做成 Plugin，我只看一条：它有没有稳定的输入。邮件、发票、简历这种输入干净，做出来就准；靠我脑子里那点印象的，做出来多半是猜的。
今日待办（Daily To-Do）
这个是新建的，以前没有对应的方法论，从零做起。它把飞书邮件、日历、待办收成一份今天的清单，排好序，分成几组：只有你能做、AI 干着 / 待审、排期 / 批处理、插件候选，做完的另收一组。每条卡片写着为什么排这个位置，还有分项打分，权重可以自己改。
能交出去的任务它会写成工作包：目标、上下文、产出格式、验收标准、护栏。举个例子，目标写「把这三份客户材料压成一页诊断结论」，验收标准写「每条结论后面挂着材料里的原话」，护栏写「不许编数字，缺的地方标待确认」。后台跑完，产物落到本地目录，再发我一条消息。
它还能扫最近三十天的历史，按任务族归并，找出该做成 Plugin 的重复任务，给证据和预计节省的时间，然后生成一个最小 Plugin 骨架。
唤起的方式不止一种：面板、模型工具 14 个动作、7 条斜杠命令、一个 preset、早晚各一条定时，还有启动 8 秒后补一次同步。
不行的地方：定时任务只在 DSH 运行时触发，错过只补最近一次，电脑合上它就不跑。飞书邮件和日历的接口权限被租户策略卡过一次，后来用 CalDAV 和 IMAP 兜底，两条通道独立，配一个就能跑。
SDD 团队与 PM 工作台（SDD Team / PM Workbench）
产品设计交付这条线我用得最多，从 Opencode 搬过来的头一个就是它。Lead、PM、Engineer、QA、Reviewer、验收执行者（Acceptance Runner），6 个角色各自注册成一个 preset，面板里逐字写着每个角色的职责、约束和彼此怎么交接。要用的时候不用解释「你现在是 QA」，点一下就是那套 persona。
局限也明显：它保证我按流程走，保证不了流程本身对。角色是我写的，写歪了就一起歪。
PM 这一角跟我自己的定位最近，所以我又把它单独拆出来做成了一个插件（PM Workbench）。点开就是一块产品经理看板：哪些在等我 review、哪些在等我处理、哪些被卡住了，一眼看得到。
随便点进去一条，可以 handoff 给对应的子 agent 接着做，也可以我自己改完往下走。看板是只读的，所有改动都要经过 PM Agent 会话，谁动了什么有据可查。
FDE 工具箱（FDE Toolkit）
接着是企业 AI 场景的规划和落地。10 个 agent、54 个技能、12 条命令，agent、技能、命令三边都能互相跳：从 agent 能看到它挂的技能和命令，从技能能看到谁在用它。
它主要用来查：这件事该找哪个 agent、用哪个技能，不用每次重新回忆自己写过什么。
Grilling
方案快定稿的时候，我一般会拿它过一遍。三档入口：常规追问、快速版、带文档版，带文档那档会把澄清出来的结论落成决策记录和术语表。
它产出的是「你这版哪儿站不住」这份挑刺清单，方案还得自己改。
课件设计（Courseware）
做培训课件用的。8 个阶段的编排，每个阶段有明确产出和门禁，底下挂十几个子技能，另有一份 8 条硬规则加 6 项复核的清单，管的是什么样的课件不许发出去。它比前几个重，因为它管的是质量下限。
售前方案（Proposal Studio）
一段客户简报进去，四章结构的单文件 Deck 出来，含实施计划的人天和报价。模板里有 2 套场景预设：AI 场景落地 3 周、SDD 加 Harness 4 到 6 周。保存的时候复制进规范目录并登记。
面板在这儿只是个启动器，3 张卡片，点了预填指令，不自动发送。预填和不发送我特意分开的：前者是帮忙，后者就越界了。
不行的地方：报价没有业务校验，人天对不对还得我自己核。
面试评估（Interview Review）
简历、录音转写、面试官笔记，三份材料进来先归位，缺什么直接说；再拉出证据底稿；然后按 9 个模块评分，权重从 4 分到 2 分、合计 30 分，每个模块的分数等于权重乘等级再除以 4；最后给结论、推荐度、建议职级，以及对齐内部表单的 5 个字段。
两条硬规矩：每个模块的结论必须挂回原话，没有证据的结论不写；生成表单粘贴版时自动把手机号、邮箱、身份证打码。面板只读，写入只有一条路，数据只留一个入口。
Blog Writer
写东西用的。五阶段流程固化成 preset：洞察碰撞、设计确认、起草、读者视角评审、去 AI 味终审。它是我所有 Plugin 里最小的那个，index.js 只有 11 行，全部价值就是把我写东西的顺序固定下来。
局限得说清楚：它能保证流程，保证不了观点。观点还得我自己想。
发票整理（Invoice Organizer）
也是新建的。选一个文件夹，它读出每张票的供应商、项目、日期、金额，把文件名改成「供应商-产品-日期-金额」。PDF 有文本层就读文本，扫描件渲染成图再识别，图片直接读，XML 读原文，OFD 只给提示。
它只改名，不移动也不删除；已经是目标名的返回未变；同名自动加后缀。判断交给模型，执行留给确定性代码，这条界线划清了，我才敢让它动我的文件。
三、使用 DSH Plugin 的体验变化
搬是搬过来了，用起来还是不一样。下面分三段：跟 Opencode 比变了什么，跟豆包Work比它做不到什么，还有几件跟对比无关的。
⚖️ 跟 Opencode 比，变了五处
Opencode 我用来跑仓库里的工程任务，拿它对照最直接。用下来变化集中在五处。
1. 定时把主动性拉起来了
DSH 有原生的定时服务，Plugin 可以往里建任务，任务挂在某个会话上，到点自己跑一段。我这边现在挂着 4 条：每天 18:00 做待办复盘和任务拆解、每周二到周五 8:00 跑平台日报、每天 12:00 巡检 Blog Writer 还没写完的篇目、每周一 9:00 扫一遍发票文件夹。跑完还能通过飞书 CLI 把结果推到手机上。Opencode 那边没有这一层，主动跑的任务在那边做不了。
2. skills 和 agent 变成能点的应用
今日待办打开就是一张待办清单，左边按状态分组，右边每张卡片写着为什么排这个位置、下一步谁做什么；面试评估左边是记录列表，右边是这场的结论，三段各带一个 Copy，直接粘进内部表单。界面是 Plugin 自带的那半代码（client.js）画的，聊天窗口在这儿没什么用。
3. Agent Team 和子 agent 拆开跑
DSH 的 profile 里装了一个实验性的 Agent Teams 包，加上子 agent 和后台任务的工具，我发一条指令它常先把任务拆一遍，适合后台的单独起一个。图里这一次，两个子 agent 并行跑了 11 分 47 秒和 6 分 05 秒，各消耗 5.2M 和 4.8M token。
效率是上来了，token 也上来了：跟以前比，每天大概多花 60% 到 80%。
4. 语音输入
官方随包带了一个语音输入的 Plugin（标注是实验性的），说一段就变成指令。以前得先把需求敲成一段话，长一点的要改好几遍；现在对着麦克风说一遍，识别错的地方再改两个字。省下来的主要是打字和改字的时间。
5. 产出物能直接看
写完的文件不用另开编辑器，在 DSH 里点开就是渲染后的样子：markdown 出排版，图片直接显示。图里这一栏就是这篇稿子，标签页上写着 blog24.md。
🤖 跟豆包Work比
现在不少企业办公都在飞书，飞书 8.0 又把豆包Work接了进来。它确实更贴企业环境：文档、消息、审批、日程这些它直接就能拿到，权限跟员工本人一致，企业也敢让它跑。
但我这几个场景，有几件事在豆包Work里做不到。
1. 不够开放，插不进现成的流程
比如飞书里的面试，这块已经做得挺完善了，我要的只是在它的评估结果上加一段自己写的判断。按理说这一步该允许我写个 skill 直接插进现在的流程里，现在没这个口子。面试只是举个例子，换成别的流程也一样。
2. 任务拆解和后台执行跟不上
Agent Team、子 agent、后台任务这套做法，在豆包Work里我没看到；它执行任务时基本在一个会话里往下推，简单任务也要跑很久。
3. 上下文处理不够
我举的这几个场景大多是长程任务，要拿很多个文件当上下文。文件一多，它对文件的理解和处理就开始失焦，输出跟预期偏差比较大——这可能主要还是基础模型的能力问题。
4. 没有「Plugin 即应用」这种形态
我这边 skill 和 agent 写完，包成 Plugin 点开就是应用；它那边得先有 agent，再构建成智能体应用，再发布，走的是无代码平台那条路。对不懂技术的人来说，反而要按平台的套路搭一遍；我这边 vibe coding 一个 Plugin，个性化的应用就有了。
它的长处我也记着：权限天然对齐、合规上企业放心。这几样我这边补不上，要自己申请接口权限（被租户策略卡过一次，后来拿 CalDAV 和 IMAP 兜底），数据自己存，出问题自己修。
所以飞书里发生的事我还在飞书里办；带我自己标准、最后要落成文件的活，用 Plugin。
🧩 其他
上下文分四层
全局组合（选哪个 preset）、工作区说明文件、技能目录、Plugin 自己的存储。前三种决定它像不像我；第四层是字段，决定它能不能接手。
文档是给人看的，字段是给程序读的。把「我几点上班、一天最多排几条、每条实际花了多久」存成字段，比写在一段说明里管用。
上下文也会过期
四层都是文件，文件会腐烂，一张两周前的客户清单读起来比没有更糟。
能力画像那套给了我一个办法：周更校对，只推「这周有变化」的人，本人逐条确认，驳回的条目下次重算不许悄悄改回。它管的是「记的东西还对不对」。
Plugin 里的上下文也需要这一套：谁写、什么时候写、过期了谁负责。今日待办这块做得还行，工作时段、每天最多几条我手动改，每条实际耗时我回填；但更多时候没这个机制，技能文件写完就没人再看，三个月后它描述的已经不是我了。
软记忆与硬记忆
| 类型 | 长什么样 | 换个会话还在吗 | 能审计吗 |
|---|---|---|---|
| 软记忆 | 偏好、说过的话、上次的结论 | 靠召回，可能丢 | 难，通常是一段看不见的摘要 |
| 硬记忆 | 阈值、模板、验收标准、评分权重 | 在文件里，永久 | 能，可 diff、可回滚 |
举个具体的：能力画像那套规则里，「累计 18 人月算高」「置信度上限 0.85」「从未主责则封顶」。这些写进规则文件就是资产，写在对话框里，下周就飘。搬进来的那批 Plugin 存的是方法论，自己做的这几个存的是判断阈值，两样都比记忆硬。
四、目前还不够好的地方
不稳定
改完 Plugin 要重启，重启后界面起不来我遇到不止一次：不报错，就是一片空白，或者侧边栏少一项，只能翻备份猜是哪一行。还有一次更麻烦，面板照常打开、agent 说明也在，按钮指向的 agent 根本没被加载，因为那两个包没写进组合清单。另外，两条 patch 指向同一个 id 的时候，后一条会把前一条的配置整段覆盖掉。
晚上模型慢
同一个请求，晚上的等待比上午长一截。这一条我没法证实，像是调用在排队。能确定的是把能算准的部分放到本地，模型只做必须判断的那一两次，它就不受排队影响。
Super Agent 还没正式上线，事件驱动的自主性还做不到
10 月 31 日 DSH 团队开源了 dsh-superagent，MIT 许可，官方说得很清楚：研究原型、不是产品、不建议上生产。
它的拆法是主会话接单，把任务派成一个个 worker 会话，各自有独立目录，产物是 PR 这种能审的东西，再报回原始线程；另有一个面板专门列需要人看的事——提问、评审、失败。主动那部分现在是观察模式：系统只记录「如果允许它会做什么」，团队确认之后才开自动执行，授权也只认明确请求和被批准的人与来源。
所以我现在还做不到的是：事情发生的时候叫它。客户邮件进来、日历撞了、群里被 @，这些都得我自己看一眼再决定要不要动它；现在的定时只能按时间叫，事情发生了它不知道。另外它目前只盯一个 GitHub 仓库，我这边的工作台横跨邮件、日历、飞书和本地文件。
企业数据和知识怎么接进来，还没有好机制
现在这些 Plugin 用的是我自己的凭据：读哪个文件、调哪个接口、能看到谁的数据，都跟着我这个人的账号走。自己用够了，放到企业里就不行。
企业那边要的是另一套：按部门、按角色分权限，操作要能审计，数据边界要划清楚。比权限更靠前的一步是，企业自己的数据知识（文档库、知识库、业务系统）怎么合规地接进来——这一步现在没有现成机制，得靠组织在外围补。
我想到的一种做法是：如果有一个带着企业权限的飞书 CLI 插件，调用时按我的企业身份鉴权，返回的只是我被允许看的那部分，这类 Plugin 在企业环境里就好用得多。但没有这一层，DSH 离企业应用还是有点远。
五、最后
这算是一个新鲜的尝试。如果结合你的工作角色，也想试试更有主动性的 Agent，可以拿 DSH 插件试试；也希望能听到大家的体验和感受。
[注：本篇博客也是由 Blog-writer 协助写好并推送到博客大赛 wiki 空间]
#WorkAgent #DSH #Plugin机制 #AI产品经理 #企业AI落地
