文章目录
- 前言
- 前言
- 实战案例演示
- 实现思路
-
- [基于function call实现HTTP工具调用](#基于function call实现HTTP工具调用)
- 核心插件组件设计实现
- 业务插件系统模块实现
- 总结与未来展望
- 资料获取

前言
博主介绍:✌目前全网粉丝4W+,csdn博客专家、Java领域优质创作者,博客之星、阿里云平台优质作者、专注于Java后端技术领域。
涵盖技术内容:Java后端、大数据、算法、分布式微服务、中间件、前端、运维等。
博主所有博客文件目录索引:博客目录索引(持续更新)
CSDN搜索:长路
视频平台:b站-Coder长路
前言
对接语雀文档问答应用场景
公司数栈内部研发平台为了能够更好的拥抱ai,想要尝试进行搭建内部的ai平台来快速构建特定的一些应用去给内部不同部门来进行提效,在初步阶段我们实现了对接语雀文档的知识库,并植入到ai,能够实现ai文档问答匹配相似文档内容以及文档链接。
**对于ai集成知识库的应用场景如:**构建内部技术方案文档知识库ai助手
我们将内部语雀文档知识库对接进来将特定目录下的文档导入:

在ai bot界面配置知识库:

点击访问发布的bot,即可开始进行知识库问答,效果如下:

初探插件实现
后续逐步想要寻找一些需求案例来进行尝试落地,初步发现需要寻找一种方式能够去增强ai对接不同场景的情况。
此时我们进行了调研,对于市面上常见的一些增强能力的方式,包含有工作流、插件等,我们将目光投入到了插件这块上,我们需要寻找一种能够快速集成且能够配置创建常见的一种方案,通过初步调研,我们查看对比了coze、dify的插件设计,发现coze的插件设计十分优秀,你可以理解在coze当中的插件,本质就是http接口,也就是说你只需要有一个核心的http接口,就能够对接为一个插件工具,支持界面配置,最终将插件植入到ai中,让ai进行内部插件工具的调用最终实现问答增强的效果。
实战案例演示
介绍
**何为插件?**你可以理解插件是作为一组工具的集合,插件是特定一个领域能力的代名词,在插件中的工具则具备特定实现某个功能。
我们的目标是如果你有一个search搜索接口,那么通过我们的平台可以直接在我们的平台界面上去配置这个接口作为一个插件工具,无需去自定义一个插件,然后去上传,同时我们在插件编辑界面能够提供调试该插件的方法,在构建好插件后我们只需要在ai bot配置界面选择插件,然后编写提示词什么场景去调用该插件工具,那么我们就能够实现一个插件的集成。
总结提炼几个关键词就是:支持界面配置无代码改动、对接http接口、插件工具快速集成ai。
接下来来演示下配置一个联网搜索的插件工具,一个能够实现联网搜索的插件构建并配置到ai bot中,实现联网搜索的功能。
步骤一:配置插件工具
首先我们需要一个能够具备联网搜索能力的接口,这里我们使用目前比较流行的一个搜索平台接口:serper.dev,在这个平台其本身就提供了多种接口,如下,我们使用其search接口:

对应的http接口curl格式如下:
shell
curl --location 'https://google.serper.dev/search' \
--header 'X-API-KEY: 4dxxxxxxxxxxxxe5c7269' \
--header 'Content-Type: application/json' \
--data '{"q":"apple inc","location":"China","gl":"cn","hl":"zh-cn","num":20}'
目前平台提供还额外提供了快速对接接口的能力,平台可快速的将curl转换为一个插件的工具,如下我们去复制到界面中,首先我们点击导入插件:

将插件名称以及curl内容复制进来点击确定:

此时你就获取到了一个搜索插件:

点击进入即可看到该插件的工具列表(你可以理解一个curl就是一个插件工具,所以我们初步导入就首先了导入一个工具):

再次点击工具名称,我们进入到具体工具的配置栏目,配置栏目左边就是工具的信息包含对接的http接口的请求方式、参数等等,同时还包含有一组参数配置:

我们初步来对参数配置进行调整,其中的q字段是关键的搜索问题内容描述,如果我们希望ai去自主的去提出问题,那么我们需要将其默认值设置为空,其他如果是带有默认值的默认有值即可,我们也可以对参数描述进行初步的介绍。

此时我们回到工具列表,编辑修改名称为聚合搜索:

至此我们初步的插件工具就配置完成了。
步骤二:测试插件工具
我们重新进入到工具中,点击左上角的试运行按钮:

接着我们模拟ai输入要询问的问题,点击测试运行,如果接口可以调通,那么右侧就会有响应值,我们check是否正常,正常的话则测试完成:

步骤三:集成AI实现插件工具调用
我们回到工具列表,将工具进行启用,同时将插件进行发布,启用与已发布如下所示:

我们回到ai bot编辑配置界面,添加相应的插件以及系统提示词后,此时完成初步配置我们来进行保存与发布即可:

此时我们进入到ai问答界面,输入以下内容,其中内容含义很明显就是要让ai进行聚合搜索:

回车,你即可会发现当前问题已经结合联网搜索工具完成了对话,对话效果如下:

此时你可以理解对应的这个ai已经实现了工具了调用,并将刚刚接口返回的内容进行组织语言回答。
至此我们就初步完成了插件的配置与集成。
实现思路
基于function call实现HTTP工具调用
Function calling是大语言模型(LLM)与外部系统或工具交互的核心机制,它允许AI模型在推理过程中动态选择并调用预定义的工具方法,从而扩展模型的能力边界(如实时搜索、数据库查询、API调用等)。其核心思想是将工具方法封装为标准化描述,由LLM在对话过程中根据上下文决定是否调用、如何调用,并解析调用结果继续生成回复。
我这里首先举一个集成了本地tools方法sum求和以及求平方根的例子,比如我们有一个sum求和工具以及一个求平方根的工具,问题是1+2等于多少、指定数字的平方根是多少,此时作为中间层如何和chat模型进行交互呢?

在我们的内部AI平台中,我们底座llm框架是langchain4j框架,在llm框架中提供了可扩展的toolexecutor接口,我们基于此自己执行了能够完成http请求的toolexecutor实现。
如何对接AI实现tools方法调用,下面会以上面的search接口来进行例子说明:
第一步:工具描述生成(JSON Schema)
在系统加载插件后会生成如下结构的ToolSpecification(JSON格式):
json
{
"name": "searchWeb",
"description": "使用 Serper API 搜索网络",
"parameters": {
"type": "OBJECT",
"properties": {
"query": {
"type": "STRING",
"description": "搜索关键词"
},
"country": {
"type": "STRING",
"description": "国家代码(如:'cn')",
"default": "cn"
},
"language": {
"type": "STRING",
"description": "语言代码(如:'zh-CN')",
"default": "zh-CN"
}
},
"required": ["query"]
}
}
该描述会在对话开始时发送给LLM,告知其有一个名为searchWeb的工具可用于网络搜索。
第二步:用户提问与LLM决策
举例用户提问:"最近有什么关于人工智能的重大新闻?"
LLM判断需要调用搜索工具,返回如下function call请求:
json
{
"name": "searchWeb",
"arguments": "{\"query\": \"人工智能 重大新闻 2025\", \"country\": \"cn\", \"language\": \"zh-CN\"}"
}
第三步:平台执行工具并返回结果
平台接收到上述请求后,通过**ToolExecutor(我们自定义实现的httpexecutor)**执行searchWeb方法,向Serper API发送请求,获取搜索结果(JSON格式),并将其返回给LLM:
json
{
"role": "tool",
"name": "searchWeb",
"content": "{\"searchResults\": [{\"title\": \"2025年AI技术突破:...\", \"link\": \"https://example.com/news1\"}, ...]}"
}
第四步:LLM生成最终回复
LLM根据搜索结果生成最终回复:"根据最新搜索,2025年人工智能领域有以下重大进展:..."
我们内部首先通过自定义IHttpPlugin接口统一管理HTTP工具插件,再利用langchain4j的ToolSpecification和ToolExecutor机制将HTTP接口转换为AI可识别的工具方法,最终实现自动化的function call流程。
那实际上与ai交互,如何让ai自行多次使用插件工具呢?
在langchain4j中对于有一组tools和ai交互多轮对话过程,你可以理解我们会有一个循环会根据ai当前返回的是否是包含function call request来决定是否继续和ai工具交互:

如果没有的话最终将ai的响应内容给到浏览器界面进行回显,这就是整个交互的过程。
核心插件组件设计实现
核心我们应当做两个部分实现才能够去对接到langchain4j的tools机制中。
第一个部分:实现基于ai的funcation calling指定的方法&参数进行http接口调用
在langchain4j这个llm框架内部给我们提供了一个接口,我们可以基于这个接口来去扩展一个httpToolExecutor:
java
public interface ToolExecutor {
// ToolExecutionRequest 则是langchain4j给我们将function call request封装成了一个类
String execute(ToolExecutionRequest var1, Object var2);
}
我们设计了一个HttpToolExecutor来实现这个接口,在execute方法内部我们去做了基于大模型function calling的结果中的参数去选择相应的http接口然后封装参数去进行请求,最终拿到结果。

第二个部分:我们需要去规范我们的http接口相应的参数方法去封装出来一个ToolSpecification
为了后续能够作为一个开发包实现后续http插件实现,我们设计了一个httpplugin接口:
java
/**
* @description 提供接口后续可自定义扩展httpplugin
* @author changlu
* @date 2025/8/23 17:19
*/
public interface IHttpPlugin {
/**
* 初始化必备参数配置
* @param props Properties
* @return void
*/
void init(Properties props);
/**
* 获取HttpPlugin实体类
* @param
* @return HttpPlugin
*/
HttpPlugin getHttpPlugin();
/**
* 构建plugin name
* @param
* @return String
*/
String getPluginName();
/**
* 快速构建可提供注入到AiService中的tools封装
* @return Map<ToolSpecification,ToolExecutor>
*/
default Map<ToolSpecification, ToolExecutor> buildHttpTools() {
// 校验特定参数是否传递
doCheckProps();
// 获取自定义HttpPlugin的参数配置
HttpPlugin httpPlugin = this.getHttpPlugin();
if (httpPlugin == null) {
throw new AiServiceException(String.format(ErrorMsgConstant.PLUGIN_METHOD_NO_IMPL, this.getClass().getName(), "getHttpPlugin()"));
}
return HttpPluginFactory.buildHttpPluginTools(httpPlugin);
}
/**
* check是否已填充必填参数,如果没有填写则会直接报错提示
* @param
* @return void
*/
void doCheckProps();
}
同时还设计构成一组插件工具的实体类结构设计:

java
@Data
@Builder
public class HttpPlugin {
// 基础服务名称
private String baseUrl;
// 公共请求头
private Map<String, String> staticHeaders;
// 包含多个插件方法
List<HttpPluginMethod> pluginMethods;
}
其中在IHttpPlugin中的buildHttpTools方法能够将我们的这个HttpPlugin转换为ToolSpecification以及ToolExecutor方便后续对接到langchain4j的tools工具中调用(其中一个ToolSpecification就是一个工具的方法参数json格式描述的抽象类实现)。
对接方式如下,当我们构建好一个插件后,只需要去转换为一组ToolSpecification & ToolExecutor,然后按照如下方式集成即可:

业务插件系统模块实现
业务插件系统库表设计
底层核心基于langchain4j实现的这么一套http插件对接好了之后,我们就要开始应用层的实现了。
因为我们的目标是去最终提供一个界面可配置的方式来对外提供,因此,我们基于核心包中HttpPlugin、HttpPluginMethod以及HttpToolParameter各自所需的字段属性去设计了三个表用于存储我们的插件信息。
- 插件表:存储插件基本信息,包括名称、基础URL、描述等。
- 方法表:管理插件提供的具体工具方法。
- 参数表:存储方法参数的详细配置。
对于加载db的这个插件类 & 我们核心包实现的插件模块里的实体类HttpPlugin实际上是分开的,我们基于业务层去实现了一个将db加载的插件转换为我们核心模块的HttpPlugin的工具类:

那此时你可以理解我们想要实现对接到langchain4j中的tools实现过程就是:加载db插件工具信息 -> 自定义的HttpPlugin -> Map<ToolSpecification, ToolExecutor>。
对于界面中在技能配置部分,我们的底层原理实现就是如上所说:

CURL解析器实现
对于插件配置界面,提供用户可创建、编辑的方式还不够,我们希望能够有更快的对接方式,让用户将http接口快速对接进来,我们还设计了一个基于curl的解析器并实现将解析后的内容转换为一个插件工具(和插件业务模块融合对接起来),你可以理解用户只需要如下在浏览器中将接口复制curl:

对接方式就是我们一开始案例演示中的导入curl实现:

针对于该curl解析器,我们初步实现了对于curl的解析以及转换插件的实现:

CurlParser为curl解析器,用来将curl解析为一个实现类CurlParseResult。
CurlParser的解析接口如下:
java
public CurlParseResult parse(String curlCommand) {
...
}
CurlParseResult解析结果类实现如下:
java
@Data
public class CurlParseResult {
private String url;
private String method = "GET";
private Map<String, String> headers = new HashMap<>();
private String data;
private String user;
private List<FormData> formData = new ArrayList<>();
private String cookie;
private String referer;
private String userAgent;
private boolean followRedirects = false;
private boolean insecure = false;
private String proxy;
// 添加查询参数映射
private Map<String, String> queryParams = new HashMap<>();
...
}
解析出来之后,我们会将CurlParseResult去转换为我们的核心包HttpPlugin的核心能力实现提供出去,这块就由CurlToHttpPluginConverter转换器来实现,该三个核心实现类我们作为dt-ai-core公共包来提供出去。
CurlToHttpPluginConverter转换器的实现接口方法为:
java
public class CurlToHttpPluginConverter {
public HttpPlugin convert(CurlParseResult curl) {
...
}
}
由于这三个核心类具备能够将curl转换为一个HttpPlugin插件实体类,由于我们是作为core包的公共能力提供出去,我们则会将HttpPlugin的插件实体类转换为能够进行db存储的pojo来进行最终存储到db:

最终完成了解析 -> 导入的功能,至此我们的插件系统初步完成。
总结与未来展望
借助这个插件核心系统模块以及业务层的插件对接实现,我们能够快速完成http接口的对接,并实现为ai能力的增强,对于初步插件系统的雏形,我是通过调研了多种插件方案,发现字节的coze插件实现非常好,最终参考coze并结合实际场景去进行落地实现,实际上无论是mcp还是http都可以按照同样的模式去实现对接,选择http接口作为插件工具是因为http接口非常广泛,大多数的web系统都提供了http接口,能够支持用户快速对接。
在整个模块实现过程中,还是涉及到很多代码编写内容的,我会将快速将一些简单、边界的活使用ai来进行实现,而我则对最对最上层的接口方法、抽象类来进行设计,并对部分ai生成的代码进行check review最终独立完成了这一整个插件系统的设计,面对ai时代的到来,应当拥抱ai,并且借助ai的能力与自身能力来结合起来,实现将更多原本排期特别长、感觉不可能的事情。
目前来看当前的插件系统在业务实现上是初步完成了,对于未来设想将推出插件市场,后续内部将基于插件模块来提供更多的内置插件,来为更多不同的场景进行赋能,实现内部更多ai文本交互场景落地。
希望整篇技术博客能够给你带来一些启发与帮助,如有问题请指正。
资料获取
大家点赞、收藏、关注、评论啦~
精彩专栏推荐订阅:在下方专栏👇🏻
- 长路-文章目录汇总(算法、后端Java、前端、运维技术导航):博主所有博客导航索引汇总
- 开源项目Studio-Vue---校园工作室管理系统(含前后台,SpringBoot+Vue):博主个人独立项目,包含详细部署上线视频,已开源
- 学习与生活-专栏:可以了解博主的学习历程
- 算法专栏:算法收录
更多博客与资料可查看👇🏻获取联系方式👇🏻,🍅文末获取开发资源及更多资源博客获取🍅