DeepSeek Harness插件开发实战教程：我让它自己写了一个 arXiv 搜索插件

如何开发一个 DeepSeek Harness 插件

前面聊 DeepSeek Harness 的时候，我提到过一句：

这东西最有意思的地方，就是**「一切皆插件」**。

模型是一块，工具是一块，能力是一块，甚至不同的运行模式，本质上也是一堆插件组合出来的。

那问题来了。

既然一切皆插件，那自己能不能写一个？

当然可以。

而且实际折腾下来，比我想象中简单不少。

所以这篇不聊太虚的，直接动手。

笔者准备给 DeepSeek Harness 搞一个 arxiv-search 插件，让它能够直接搜索 arXiv 论文。

顺便看看，这套所谓「一切皆插件」的架构，开发体验到底怎么样。

先把 DeepSeek Harness 跑起来

安装没什么好说的，官方仓库已经写得很清楚：

github.com/deepseek-ai...

如果只是想直接体验 Harness，不需要先把整个源码仓库拉下来。

一条命令就行：

shell 复制代码

npx @deepseek-ai/dsh web

第一次运行会提示安装：

text 复制代码

Need to install the following packages:
@deepseek-ai/dsh@...
Ok to proceed? (y)

直接输入 y。

等依赖装完，终端会出现：

text 复制代码

dsh web: http://127.0.0.1:3080

浏览器打开 http://127.0.0.1:3080，Harness 的 Web 工作台就起来了。

这两天 DeepSeek API 的价格也在调整，所以这次笔者没有直接用在线模型，而是顺便试了一下本地部署的 Qwen3.8-27B-FP8。

正好也看看 Harness 接本地模型之后，实际干活能力怎么样。

环境有了。

接下来进入正题。

Harness 的插件到底怎么写？

官方其实专门准备了一篇最基础的插件教程：

地址在这里：

text 复制代码

https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/user/develop/basic/index.zh.md

不过比较尴尬的是，可能是最近 Harness 关注度确实有点高，笔者折腾的时候 GitHub 页面一度直接打不开。

行。

网页看不了，那就把仓库直接拉下来。

找到对应的 index.zh.md，内容就都在里面。

看完之后，会发现 Harness 的插件机制其实没那么玄乎。

最核心的东西，就两个：TypeScript 插件 + cordis.yml。

一个最基础的插件，本质上就是一个 TypeScript 模块。

里面导出插件名称 name，再实现一个 apply(ctx)。

Harness 加载插件的时候，会把上下文对象 ctx 传进来，然后插件通过这个 ctx 注册自己的能力。

比如工具、事件、定时器，甚至其他服务。

如果插件还依赖 Harness 已有的 tools、llm 等能力，就通过 inject 声明依赖。

框架会等依赖准备好，再加载你的插件。

所以简单理解，整个过程其实就是：

text 复制代码

写插件
   ↓
通过 ctx 注册能力
   ↓
在 cordis.yml 中声明插件
   ↓
Harness 加载配置
   ↓
插件能力进入 Agent

还有一个细节我挺喜欢。

通过 ctx 注册的事件监听、工具、定时器等资源，在插件卸载的时候，Harness 会自动帮你清理。

如果是网络连接之类的特殊资源，也可以通过 ctx.effect() 自己定义清理逻辑。

这套设计很像一个完整的插件生命周期管理机制。

插件本身也支持三种写法：函数、对象和继承 Service 的类。

日常写个工具插件，用函数形式基本就够了。

如果这个插件以后还要给别的插件提供公共服务，再考虑 Service。

理论差不多搞懂了。

那就不继续看文档了。

直接让模型写一个试试。

让 DeepSeek 给 Harness 写一个 arXiv 插件

我准备做的东西很简单：

一个 arxiv-search 插件。

目标是让 Harness 里的 Agent 能够自己去 arXiv 搜论文、拿论文信息，然后继续做分析。

手头有两份资料：

index.zh.md：DeepSeek Harness 插件开发说明
arXiv API Basics.md：arXiv API 请求说明

然后直接把任务扔给 DeepSeek-V4-Flash。

提示词甚至没怎么写：

text 复制代码

index.zh.md为如何开发一个Deepseek Harness组件
arXiv API Basics.md是arxiv请求说明

请帮我创建一个arxiv-search插件

接下来就比较有意思了。

DeepSeek-V4-Flash 先把两份资料读了一遍，然后自己拆任务，生成了一份任务清单。

然后开始写代码。

最后给这个插件做了两个 arXiv 相关工具。

一个负责搜索论文 ，另一个负责获取论文详情。

代码写完还没结束。

它又自己跑了一遍冒烟测试，确认插件至少能够正常加载和调用。

到这里，其实已经有点 Agent Coding 那味了。

给资料。

说明自己想要什么。

模型自己读文档、拆任务、写插件、做测试。

最后直接给一个能跑的东西。

打开生成出来的目录，可以看到整个插件代码已经放好了：

甚至还很贴心地顺手生成了一份插件使用说明。

接下来，本来按照官方插件教程，应该这样启动：

bash 复制代码

cd /Users/mac/Projects/dsh-plugin
pnpm dsh web --patch ./arxiv-search/cordis.yml

结果一敲。

报错了。

bash 复制代码

(base) mac@macdeMacBook-Pro dsh-plugin % pnpm dsh web --patch ./arxiv-search/cordis.yml

/Users/mac/Projects/dsh-plugin:
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Command "dsh" not found

看到这里我一开始还以为，插件哪里配错了。

后来发现，不是。

坑在启动方式上。

一个小坑：npx 安装的 Harness，别直接照抄 pnpm 命令

官方插件教程默认的场景，是你已经把 deepseek-harness 仓库源码拉下来了，并且在源码环境里完成依赖安装和构建。

这种情况下：

bash 复制代码

pnpm dsh web

当然没问题。

但笔者前面并没有从源码启动。

我是直接：

bash 复制代码

npx @deepseek-ai/dsh web

跑起来的。

本地这个 dsh-plugin 项目里根本没有 dsh 这个 pnpm 可执行命令。

所以：

bash 复制代码

pnpm dsh web

自然找不到。

解决办法也简单。

既然前面是用 npx 跑 Harness，那加载插件的时候继续用 npx：

bash 复制代码

npx -y @deepseek-ai/dsh web \
  --patch /Users/mac/Projects/dsh-plugin/arxiv-search/cordis.yml

重新启动。

打开 Harness。

这次在插件列表里已经可以看到 arxiv-search。

OK。

插件正式加载成功。

接下来就不是「能不能装」的问题了。

得看看它到底能不能干活。

测试一下 arxiv-search

先来最基础的。

测试一：直接搜索 RAG 论文

我输入：

text 复制代码

用 arxiv_search 搜索 "retrieval augmented generation"，返回 5 篇论文，列出标题、作者和摘要。

然后 Harness 会自己调用刚刚安装的 arxiv_search 工具。

这一步其实已经验证了最关键的一件事：

自己写的插件，真的已经进入 Harness 的工具调用链了。

不是单独跑个 TypeScript 脚本。

而是模型能够根据任务，自己判断什么时候调用它。

这才是插件真正有意思的地方。

接下来再加点难度。

测试二：搜索 + 对比 + 总结

这次不只是让它搜论文，而是：

text 复制代码

搜索 "retrieval augmented generation" 的 4 篇最新论文，对比它们的摘要，然后用中文总结该方向的研究热点。

这里整个任务链已经变成了：

text 复制代码

理解问题
   ↓
调用 arxiv_search
   ↓
获取多篇论文
   ↓
读取论文信息
   ↓
对比摘要
   ↓
归纳研究热点
   ↓
生成中文结论

也就是说，这个插件不只是给 Harness 多塞了一个 API。

它相当于给 Agent 增加了一种新的外部能力。

最后，Harness 根据检索到的论文进行了对比，并给出了对应的分析结论。

到这里，这个 arxiv-search 插件基本就算跑通了。

最后

整个过程折腾下来，我对 Harness 所谓的「Everything is a Plugin」，算是有了更直观的理解。

以前听「插件化 Agent」这种词，很容易觉得又是架构层面的包装。

但真正自己写一个之后，会发现它的思路其实特别直接。

缺什么能力，就给它装什么能力。

今天可以接 arXiv。

明天可以接 Semantic Scholar、GitHub、企业知识库、数据库，甚至自己内部的科研系统。

然后这些能力不是写死在 Agent 里的，而是通过插件往 Harness 里面插。

这就很有意思了。

更有意思的是，这次插件的大部分代码，其实都不是我自己一行一行敲出来的。

我只是把：

Harness 插件文档 + arXiv API 文档 + 想实现什么

扔给模型。

剩下的读文档、拆任务、写代码、测试，基本都让模型自己干了。

某种意义上，这才是 Harness 这类东西真正值得玩的地方：

不仅 Agent 可以用插件干活，Agent 甚至可以开始给自己造插件。

现在这个 arxiv-search 还非常简单。

但思路已经跑通了。

后面我准备继续折腾几个稍微复杂一点的插件，看看 Harness 的上限到底在哪里。

毕竟才 v0.1。

能玩的东西，应该还有不少。

以上。

既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧。

如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章。

我们，下次再见。