人工智能大模型AI 应用后端AI AgentRAG流程编排微服务【免费下载链接】fit-frameworkFIT: 企业级AI开发框架提供多语言函数引擎FIT、流式编排引擎WaterFlow及Java生态的LangChain替代方案FEL。原生/Spring双模运行支持插件热插拔与智能聚散部署无缝统一大模型与业务系统。项目地址https://gitcode.com/ModelEngine/fit-framework点击查看免费下载导读本文档系统讲解 FELFIT Extension for LLM插件在 FIT 框架中的启动顺序机制。当应用以 JAR 包方式运行时FIT 框架会依据插件的category类别与level等级两个维度以确定性的先后顺序加载插件从而保证工具仓库、工具发现器、模型集成等组件按正确依赖关系就绪。读完本文你将掌握 FEL 全部 9 个插件的加载层级与先后次序、category/level 的配置语法与默认值、以及插件间启动依赖背后的源码实现原理能够据此合理规划自定义插件的启动优先级。一、两级排序机制category → levelFEL 插件与 FIT 内置插件共用同一套启动顺序规则。FIT 框架对插件执行两级排序第一级按 category 排序第二级在同一 category 内按 level 数值排序。1.1 启动规则规则说明category 优先级categorySYSTEM (id1)的插件先于categoryUSER (id2)的插件加载level 优先级相同 category 内level 数值越小启动优先级越高同级顺序相同 category 和相同 level 的插件加载顺序不确定1.2 默认值未指定 category 时默认为categoryUSER未指定 level 时默认为level4。1.3 源码依据category 的两个枚举值在 FIT 核心 API 中定义于 PluginCategory.javapublic enum PluginCategory implements CodeableEnumPluginCategory { SYSTEM(1, system), USER(2, user); ... }其中SYSTEM的 id 为 1、USER的 id 为 2这正是“SYSTEM 先于 USER 加载”这一规则的底层来源。SYSTEM类别通常承载框架级基础设施HTTP 服务、序列化、工具链路而USER类别则承载面向业务的功能插件二者解耦后用户插件在启动时即可安全使用系统插件提供的 Bean 与服务。二、整体启动流程图29 个插件的两级启动顺序当前build/plugins目录共统计29 个插件其中 FEL 插件 9 个本文档详细说明FIT 内置插件 20 个详见 FIT插件启动顺序说明.md。整体启动顺序如下插件启动顺序29个插件 │ ├─ 阶段1: SYSTEM 插件启动 │ │ │ ├─ Level 4 (21个) │ │ ├─ FIT 内置插件 (20个详见FIT文档) │ │ └─ fel-tool-repository-simple │ │ │ ├─ Level 5 (5个) │ │ ├─ fel-tool-discoverer │ │ ├─ fel-tool-executor │ │ ├─ fel-tool-factory-repository │ │ ├─ fel-tool-mcp-client │ │ └─ fel-tool-mcp-server │ │ │ └─ Level 7 (1个) │ └─ fel-model-openai-plugin │ └─ 阶段2: USER 插件启动 ├─ Level 1 (1个) │ └─ fel-tokenizer-hanlp-plugin │ └─ Level 4 (1个) └─ fel-langchain-runnable从图中可以清晰看出两个关键设计意图SYSTEM 插件整体先于 USER 插件工具链相关插件全部属于 SYSTEM 类别它们构成了 FEL 工具能力的“地基”同一 category 内按 level 从小到大FIT 内置插件与工具仓库Level 4最先就绪随后是工具发现/执行/工厂/MCP 相关插件Level 5模型集成插件Level 7最后启动USER 类别中分词器Level 1先于 LangChain 运行时Level 4。三、FEL 插件清单详解以下按启动阶段逐一说明 9 个 FEL 插件的启动层级、职责与其源码位置。3.1 阶段1SYSTEM 插件categorySYSTEM, level41 个插件名称说明fel-tool-repository-simple工具仓库简单实现该插件是工具链的数据存储层。核心实现为 SimpleToolRepository.java通过Component注册为ToolRepository与ToolChangedObserverRegistryaddTool(ToolInfoEntity tool)将工具写入ConcurrentHashMap缓存并向所有已注册的ToolChangedObserver广播工具添加事件deleteTool(namespace, toolName)移除工具并广播工具移除事件getTool/listTool按 namespace 查询与列举工具。作为 Level 4 插件它与 20 个 FIT 内置插件处于同一层级意味着工具仓库在工具发现器启动之前就已经就绪。categorySYSTEM, level55 个插件名称说明fel-tool-discoverer工具发现器fel-tool-executor工具执行器fel-tool-factory-repository工具工厂仓库fel-tool-mcp-clientMCP 客户端fel-tool-mcp-serverMCP 服务端这 5 个插件构成 FEL 工具能力的中枢链路各自职责如下fel-tool-discoverer核心实现为 DefaultToolDiscoverer.java实现PluginStartedObserver与PluginStoppingObserver。当任意插件启动时它会扫描该插件内符合ToolSchema.TOOL_MANIFEST约定的工具清单资源解析后调用toolRepository.addTool(...)将工具装配进仓库插件停止时则执行反向卸载。此外它还通过Value(${tool.max-num})读取插件内最大工具数量限制。fel-tool-executor核心实现为 DefaultToolExecutor.java实现ToolExecuteService是工具的执行入口负责从工具仓库取出工具信息、经工具工厂创建可执行实例并完成调用。fel-tool-factory-repository核心实现为 DefaultToolFactoryRepository.java实现ToolFactoryRepository以工具类型type为键维护ToolFactory注册表供执行器按类型查找对应的工厂。fel-tool-mcp-clientMCP 客户端插件核心实现为 DefaultMcpClient.java 与DefaultMcpClientFactory通过io.modelcontextprotocol.sdk:mcp版本 0.17.1接入 MCPModel Context Protocol客户端能力使 FEL 能够调用外部 MCP 服务器提供的工具。fel-tool-mcp-serverMCP 服务端插件核心实现位于 tool-mcp-server同时提供基于 SSE 与 Streamable 两种传输方式的服务器实例详见其 README.md将 FEL 工具系统暴露为 MCP 服务供外部 MCP 客户端发现与调用。categorySYSTEM, level71 个插件名称说明fel-model-openai-pluginOpenAI 模型集成这是 FEL 的模型接入插件位于 fel-community/model-openai核心实现为 OpenAiModel.java。它实现ChatModel、EmbedModel、ImageModel、RerankModel等 FEL 核心模型接口通过fit-http-classic、fit-http-protocol、fit-security等 FIT 服务完成对 OpenAI 兼容 API 的调用是 FEL 应用接入大模型的“最后一公里”。为什么 Level 7模型插件依赖 HTTP 客户端、安全、序列化等 FIT 基础服务这些服务由 Level 4 的内置插件提供因此将其安排在 SYSTEM 类别内较高的 level确保底层能力全部就绪后才加载模型集成。3.2 阶段2USER 插件categoryUSER, level11 个插件名称说明fel-tokenizer-hanlp-pluginHanLP 分词器该插件位于 fel-community/tokenizer-hanlp核心实现为 HanlpTokenizer.java通过Component注册为 FEL 的Tokenizer实现基于 HanLP 分词器提供countToken等文本 token 计数能力。作为 USER 类别中 level 最低的插件它在所有用户插件中最先启动保证后续用户插件在做上下文长度计算时可直接使用。categoryUSER, level41 个插件名称说明fel-langchain-runnableLangChain 运行时支持该插件位于 fel-langchain-runnable核心实现为 LangChainRunnableServiceImpl.java声明Fitable(modelengine.fel.plugin.langchain.runnable.invoke)通过BrokerClient按 taskId 路由并远程调用指定 fitableId 的算子为 LangChain Runnable 提供跨进程的调用适配。注意fel-langchain-runnable的 POM 中未显式声明 category 与 level因此其实际生效的配置正是默认值categoryUSER、level4见 pom.xml这恰好验证了第一节中的默认值规则。四、插件依赖关系FEL 插件之间存在明确的启动期依赖文档中记录的依赖如下依赖方插件被依赖插件依赖说明fel-tool-discoverer(Level 5)fel-tool-repository-simple(Level 4)在onPluginStarted()回调时调用addTool()方法这一依赖在源码层面清晰可见DefaultToolDiscoverer的构造器强依赖ToolRepository接口见 DefaultToolDiscoverer.java而SimpleToolRepository正是该接口在 Level 4 阶段的实现。若工具仓库未先启动工具发现器将无法完成工具装配。这正是“工具仓库 Level 4 → 工具发现器 Level 5”层级设计的根本原因。五、category 与 level 的配置方式fit-build-maven-plugin每个 FEL 插件在构建为插件 JAR 时通过 Maven 构建插件fit-build-maven-plugin的configuration声明其启动类别与等级。以fel-tool-repository-simple为例见 pom.xmlplugin groupIdorg.fitframework/groupId artifactIdfit-build-maven-plugin/artifactId version${fit.version}/version configuration categorysystem/category level4/level /configuration executions execution idbuild-plugin/id goals goalbuild-plugin/goal /goals /execution execution idpackage-plugin/id goals goalpackage-plugin/goal /goals /execution /executions /plugin各 FEL 插件的实际配置值可在其 POM 中逐一核实插件categorylevel配置文件fel-tool-repository-simplesystem4pom.xmlfel-tool-discoverersystem5pom.xmlfel-tool-executorsystem5pom.xmlfel-tool-factory-repositorysystem5pom.xmlfel-tool-mcp-clientsystem5pom.xmlfel-tool-mcp-serversystem5pom.xmlfel-model-openai-pluginsystem7pom.xmlfel-tokenizer-hanlp-pluginuser1pom.xmlfel-langchain-runnable未声明默认 user未声明默认 4pom.xml此外所有插件在package或install阶段通过maven-antrun-plugin将构建产物复制到build/plugins/目录例如 tool-repository-simple/pom.xml 中的copy ... todir../../../../../build/plugins/最终由 FIT 框架在启动时按该目录中的插件清单统一加载。自定义插件如何选择 category 与 level提供基础设施、且被其他插件依赖的插件应声明为categorysystem并选择一个小于其依赖方 level 的数值如level4面向业务功能、依赖框架能力即可的插件保持默认categoryuser并按业务需要指定 level数值越小越早启动同一 category 与 level 的插件之间不存在顺序保证若两个插件存在启动期依赖必须通过调整 level 显式表达先后关系而不能依赖同级插件的加载顺序。六、与 FIT 内置插件的关系build/plugins中的另外 20 个 FIT 内置插件全部配置为categorySYSTEM, level4它们在 FEL 插件启动前提供 HTTP 服务、序列化、验证、服务发现、日志等框架级能力。FEL 插件尤其是fel-model-openai-plugin在依赖层面直接引用了fit-http-classic、fit-http-protocol、fit-security等 FIT 服务这些服务正是由内置插件承载的具体清单与说明参见 FIT插件启动顺序说明.md。一个值得注意的细节是FIT 内置插件与fel-tool-repository-simple同属SYSTEM Level 4但文档明确指出——相同 category 与 level 的插件之间加载顺序不确定因此表格中的序号仅用于标识不代表实际加载顺序。在设计依赖时不应假设同层级插件之间的先后关系。七、常见问题与排错建议插件启动后发现工具未注册优先检查fel-tool-discovererLevel 5是否在fel-tool-repository-simpleLevel 4之后加载以及插件内是否包含符合ToolSchema.TOOL_MANIFEST约定的工具清单资源自定义插件需要访问模型服务但启动过早模型集成插件位于SYSTEM Level 7依赖它的插件应声明为categoryuser且 level 大于其依赖对象或至少确保不早于依赖方同 level 插件间存在隐式依赖由于同级顺序不确定应立即通过调整 level 显式化依赖关系否则可能在部分环境下出现偶发启动失败想确认插件实际生效的 category/level查看该插件 POM 中fit-build-maven-plugin的configuration若未声明则对应默认值USER与4fel-langchain-runnable即为此例。八、总结FEL 插件的启动顺序由categorySYSTEM → USER与 level从小到大两级排序共同决定工具仓库Level 4→ 工具发现/执行/工厂/MCPLevel 5→ 模型集成Level 7构成了 SYSTEM 阶段的清晰链路分词器Level 1与 LangChain 运行时Level 4则在 USER 阶段完成收尾。理解这一机制是正确设计自定义 FEL 插件启动优先级、避免启动期依赖问题的前提配置入口统一为 POM 中fit-build-maven-plugin的category与level两个参数未配置时分别默认USER与4。赞分享人工智能大模型AI 应用后端AI AgentRAG流程编排微服务【免费下载链接】fit-frameworkFIT: 企业级AI开发框架提供多语言函数引擎FIT、流式编排引擎WaterFlow及Java生态的LangChain替代方案FEL。原生/Spring双模运行支持插件热插拔与智能聚散部署无缝统一大模型与业务系统。项目地址https://gitcode.com/ModelEngine/fit-framework点击查看免费下载相关推荐leetcode-rust中的5个核心算法技巧提升你的Rust编程能力leetcode rust中的5个核心算法技巧提升你的Rust编程能力 在竞争激烈的编程世界中掌握高效算法是提升Rust编程能力的关键。leetcode r示例工程FIT 框架 FEL 工具调用机制实战从 Pattern 委托到插件化工具编排FIT 框架 FEL 工具调用机制实战从 Pattern 委托到插件化工具编排 导读 本文聚焦 FIT 框架中 FELFramework for Engin人工智能大模型AI 应用后端AI AgentRAG流程编排微服务FIT 框架 FEL 实战基于 fel-flow 流程编排搭建 Native RAG 检索增强应用FIT 框架 FEL 实战基于 fel flow 流程编排搭建 Native RAG 检索增强应用 本文以 examples/fel example/05 r人工智能大模型AI 应用后端AI AgentRAG流程编排微服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FEL 插件启动顺序完全指南：基于 FIT 框架的 category 与 level 两级加载机制
人工智能大模型AI 应用后端AI AgentRAG流程编排微服务【免费下载链接】fit-frameworkFIT: 企业级AI开发框架提供多语言函数引擎FIT、流式编排引擎WaterFlow及Java生态的LangChain替代方案FEL。原生/Spring双模运行支持插件热插拔与智能聚散部署无缝统一大模型与业务系统。项目地址https://gitcode.com/ModelEngine/fit-framework点击查看免费下载导读本文档系统讲解 FELFIT Extension for LLM插件在 FIT 框架中的启动顺序机制。当应用以 JAR 包方式运行时FIT 框架会依据插件的category类别与level等级两个维度以确定性的先后顺序加载插件从而保证工具仓库、工具发现器、模型集成等组件按正确依赖关系就绪。读完本文你将掌握 FEL 全部 9 个插件的加载层级与先后次序、category/level 的配置语法与默认值、以及插件间启动依赖背后的源码实现原理能够据此合理规划自定义插件的启动优先级。一、两级排序机制category → levelFEL 插件与 FIT 内置插件共用同一套启动顺序规则。FIT 框架对插件执行两级排序第一级按 category 排序第二级在同一 category 内按 level 数值排序。1.1 启动规则规则说明category 优先级categorySYSTEM (id1)的插件先于categoryUSER (id2)的插件加载level 优先级相同 category 内level 数值越小启动优先级越高同级顺序相同 category 和相同 level 的插件加载顺序不确定1.2 默认值未指定 category 时默认为categoryUSER未指定 level 时默认为level4。1.3 源码依据category 的两个枚举值在 FIT 核心 API 中定义于 PluginCategory.javapublic enum PluginCategory implements CodeableEnumPluginCategory { SYSTEM(1, system), USER(2, user); ... }其中SYSTEM的 id 为 1、USER的 id 为 2这正是“SYSTEM 先于 USER 加载”这一规则的底层来源。SYSTEM类别通常承载框架级基础设施HTTP 服务、序列化、工具链路而USER类别则承载面向业务的功能插件二者解耦后用户插件在启动时即可安全使用系统插件提供的 Bean 与服务。二、整体启动流程图29 个插件的两级启动顺序当前build/plugins目录共统计29 个插件其中 FEL 插件 9 个本文档详细说明FIT 内置插件 20 个详见 FIT插件启动顺序说明.md。整体启动顺序如下插件启动顺序29个插件 │ ├─ 阶段1: SYSTEM 插件启动 │ │ │ ├─ Level 4 (21个) │ │ ├─ FIT 内置插件 (20个详见FIT文档) │ │ └─ fel-tool-repository-simple │ │ │ ├─ Level 5 (5个) │ │ ├─ fel-tool-discoverer │ │ ├─ fel-tool-executor │ │ ├─ fel-tool-factory-repository │ │ ├─ fel-tool-mcp-client │ │ └─ fel-tool-mcp-server │ │ │ └─ Level 7 (1个) │ └─ fel-model-openai-plugin │ └─ 阶段2: USER 插件启动 ├─ Level 1 (1个) │ └─ fel-tokenizer-hanlp-plugin │ └─ Level 4 (1个) └─ fel-langchain-runnable从图中可以清晰看出两个关键设计意图SYSTEM 插件整体先于 USER 插件工具链相关插件全部属于 SYSTEM 类别它们构成了 FEL 工具能力的“地基”同一 category 内按 level 从小到大FIT 内置插件与工具仓库Level 4最先就绪随后是工具发现/执行/工厂/MCP 相关插件Level 5模型集成插件Level 7最后启动USER 类别中分词器Level 1先于 LangChain 运行时Level 4。三、FEL 插件清单详解以下按启动阶段逐一说明 9 个 FEL 插件的启动层级、职责与其源码位置。3.1 阶段1SYSTEM 插件categorySYSTEM, level41 个插件名称说明fel-tool-repository-simple工具仓库简单实现该插件是工具链的数据存储层。核心实现为 SimpleToolRepository.java通过Component注册为ToolRepository与ToolChangedObserverRegistryaddTool(ToolInfoEntity tool)将工具写入ConcurrentHashMap缓存并向所有已注册的ToolChangedObserver广播工具添加事件deleteTool(namespace, toolName)移除工具并广播工具移除事件getTool/listTool按 namespace 查询与列举工具。作为 Level 4 插件它与 20 个 FIT 内置插件处于同一层级意味着工具仓库在工具发现器启动之前就已经就绪。categorySYSTEM, level55 个插件名称说明fel-tool-discoverer工具发现器fel-tool-executor工具执行器fel-tool-factory-repository工具工厂仓库fel-tool-mcp-clientMCP 客户端fel-tool-mcp-serverMCP 服务端这 5 个插件构成 FEL 工具能力的中枢链路各自职责如下fel-tool-discoverer核心实现为 DefaultToolDiscoverer.java实现PluginStartedObserver与PluginStoppingObserver。当任意插件启动时它会扫描该插件内符合ToolSchema.TOOL_MANIFEST约定的工具清单资源解析后调用toolRepository.addTool(...)将工具装配进仓库插件停止时则执行反向卸载。此外它还通过Value(${tool.max-num})读取插件内最大工具数量限制。fel-tool-executor核心实现为 DefaultToolExecutor.java实现ToolExecuteService是工具的执行入口负责从工具仓库取出工具信息、经工具工厂创建可执行实例并完成调用。fel-tool-factory-repository核心实现为 DefaultToolFactoryRepository.java实现ToolFactoryRepository以工具类型type为键维护ToolFactory注册表供执行器按类型查找对应的工厂。fel-tool-mcp-clientMCP 客户端插件核心实现为 DefaultMcpClient.java 与DefaultMcpClientFactory通过io.modelcontextprotocol.sdk:mcp版本 0.17.1接入 MCPModel Context Protocol客户端能力使 FEL 能够调用外部 MCP 服务器提供的工具。fel-tool-mcp-serverMCP 服务端插件核心实现位于 tool-mcp-server同时提供基于 SSE 与 Streamable 两种传输方式的服务器实例详见其 README.md将 FEL 工具系统暴露为 MCP 服务供外部 MCP 客户端发现与调用。categorySYSTEM, level71 个插件名称说明fel-model-openai-pluginOpenAI 模型集成这是 FEL 的模型接入插件位于 fel-community/model-openai核心实现为 OpenAiModel.java。它实现ChatModel、EmbedModel、ImageModel、RerankModel等 FEL 核心模型接口通过fit-http-classic、fit-http-protocol、fit-security等 FIT 服务完成对 OpenAI 兼容 API 的调用是 FEL 应用接入大模型的“最后一公里”。为什么 Level 7模型插件依赖 HTTP 客户端、安全、序列化等 FIT 基础服务这些服务由 Level 4 的内置插件提供因此将其安排在 SYSTEM 类别内较高的 level确保底层能力全部就绪后才加载模型集成。3.2 阶段2USER 插件categoryUSER, level11 个插件名称说明fel-tokenizer-hanlp-pluginHanLP 分词器该插件位于 fel-community/tokenizer-hanlp核心实现为 HanlpTokenizer.java通过Component注册为 FEL 的Tokenizer实现基于 HanLP 分词器提供countToken等文本 token 计数能力。作为 USER 类别中 level 最低的插件它在所有用户插件中最先启动保证后续用户插件在做上下文长度计算时可直接使用。categoryUSER, level41 个插件名称说明fel-langchain-runnableLangChain 运行时支持该插件位于 fel-langchain-runnable核心实现为 LangChainRunnableServiceImpl.java声明Fitable(modelengine.fel.plugin.langchain.runnable.invoke)通过BrokerClient按 taskId 路由并远程调用指定 fitableId 的算子为 LangChain Runnable 提供跨进程的调用适配。注意fel-langchain-runnable的 POM 中未显式声明 category 与 level因此其实际生效的配置正是默认值categoryUSER、level4见 pom.xml这恰好验证了第一节中的默认值规则。四、插件依赖关系FEL 插件之间存在明确的启动期依赖文档中记录的依赖如下依赖方插件被依赖插件依赖说明fel-tool-discoverer(Level 5)fel-tool-repository-simple(Level 4)在onPluginStarted()回调时调用addTool()方法这一依赖在源码层面清晰可见DefaultToolDiscoverer的构造器强依赖ToolRepository接口见 DefaultToolDiscoverer.java而SimpleToolRepository正是该接口在 Level 4 阶段的实现。若工具仓库未先启动工具发现器将无法完成工具装配。这正是“工具仓库 Level 4 → 工具发现器 Level 5”层级设计的根本原因。五、category 与 level 的配置方式fit-build-maven-plugin每个 FEL 插件在构建为插件 JAR 时通过 Maven 构建插件fit-build-maven-plugin的configuration声明其启动类别与等级。以fel-tool-repository-simple为例见 pom.xmlplugin groupIdorg.fitframework/groupId artifactIdfit-build-maven-plugin/artifactId version${fit.version}/version configuration categorysystem/category level4/level /configuration executions execution idbuild-plugin/id goals goalbuild-plugin/goal /goals /execution execution idpackage-plugin/id goals goalpackage-plugin/goal /goals /execution /executions /plugin各 FEL 插件的实际配置值可在其 POM 中逐一核实插件categorylevel配置文件fel-tool-repository-simplesystem4pom.xmlfel-tool-discoverersystem5pom.xmlfel-tool-executorsystem5pom.xmlfel-tool-factory-repositorysystem5pom.xmlfel-tool-mcp-clientsystem5pom.xmlfel-tool-mcp-serversystem5pom.xmlfel-model-openai-pluginsystem7pom.xmlfel-tokenizer-hanlp-pluginuser1pom.xmlfel-langchain-runnable未声明默认 user未声明默认 4pom.xml此外所有插件在package或install阶段通过maven-antrun-plugin将构建产物复制到build/plugins/目录例如 tool-repository-simple/pom.xml 中的copy ... todir../../../../../build/plugins/最终由 FIT 框架在启动时按该目录中的插件清单统一加载。自定义插件如何选择 category 与 level提供基础设施、且被其他插件依赖的插件应声明为categorysystem并选择一个小于其依赖方 level 的数值如level4面向业务功能、依赖框架能力即可的插件保持默认categoryuser并按业务需要指定 level数值越小越早启动同一 category 与 level 的插件之间不存在顺序保证若两个插件存在启动期依赖必须通过调整 level 显式表达先后关系而不能依赖同级插件的加载顺序。六、与 FIT 内置插件的关系build/plugins中的另外 20 个 FIT 内置插件全部配置为categorySYSTEM, level4它们在 FEL 插件启动前提供 HTTP 服务、序列化、验证、服务发现、日志等框架级能力。FEL 插件尤其是fel-model-openai-plugin在依赖层面直接引用了fit-http-classic、fit-http-protocol、fit-security等 FIT 服务这些服务正是由内置插件承载的具体清单与说明参见 FIT插件启动顺序说明.md。一个值得注意的细节是FIT 内置插件与fel-tool-repository-simple同属SYSTEM Level 4但文档明确指出——相同 category 与 level 的插件之间加载顺序不确定因此表格中的序号仅用于标识不代表实际加载顺序。在设计依赖时不应假设同层级插件之间的先后关系。七、常见问题与排错建议插件启动后发现工具未注册优先检查fel-tool-discovererLevel 5是否在fel-tool-repository-simpleLevel 4之后加载以及插件内是否包含符合ToolSchema.TOOL_MANIFEST约定的工具清单资源自定义插件需要访问模型服务但启动过早模型集成插件位于SYSTEM Level 7依赖它的插件应声明为categoryuser且 level 大于其依赖对象或至少确保不早于依赖方同 level 插件间存在隐式依赖由于同级顺序不确定应立即通过调整 level 显式化依赖关系否则可能在部分环境下出现偶发启动失败想确认插件实际生效的 category/level查看该插件 POM 中fit-build-maven-plugin的configuration若未声明则对应默认值USER与4fel-langchain-runnable即为此例。八、总结FEL 插件的启动顺序由categorySYSTEM → USER与 level从小到大两级排序共同决定工具仓库Level 4→ 工具发现/执行/工厂/MCPLevel 5→ 模型集成Level 7构成了 SYSTEM 阶段的清晰链路分词器Level 1与 LangChain 运行时Level 4则在 USER 阶段完成收尾。理解这一机制是正确设计自定义 FEL 插件启动优先级、避免启动期依赖问题的前提配置入口统一为 POM 中fit-build-maven-plugin的category与level两个参数未配置时分别默认USER与4。赞分享人工智能大模型AI 应用后端AI AgentRAG流程编排微服务【免费下载链接】fit-frameworkFIT: 企业级AI开发框架提供多语言函数引擎FIT、流式编排引擎WaterFlow及Java生态的LangChain替代方案FEL。原生/Spring双模运行支持插件热插拔与智能聚散部署无缝统一大模型与业务系统。项目地址https://gitcode.com/ModelEngine/fit-framework点击查看免费下载相关推荐leetcode-rust中的5个核心算法技巧提升你的Rust编程能力leetcode rust中的5个核心算法技巧提升你的Rust编程能力 在竞争激烈的编程世界中掌握高效算法是提升Rust编程能力的关键。leetcode r示例工程FIT 框架 FEL 工具调用机制实战从 Pattern 委托到插件化工具编排FIT 框架 FEL 工具调用机制实战从 Pattern 委托到插件化工具编排 导读 本文聚焦 FIT 框架中 FELFramework for Engin人工智能大模型AI 应用后端AI AgentRAG流程编排微服务FIT 框架 FEL 实战基于 fel-flow 流程编排搭建 Native RAG 检索增强应用FIT 框架 FEL 实战基于 fel flow 流程编排搭建 Native RAG 检索增强应用 本文以 examples/fel example/05 r人工智能大模型AI 应用后端AI AgentRAG流程编排微服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考