企业 Agent 落地的一个普遍痛点是：每搭一个新 Agent，都要重新写一遍工具对接代码。查订单要写一套接口，查库存又要写一套，查客户信息还是得写。工具越多，重复代码越多，维护成本越高。

一种可行的思路是：把"开发 Agent"变成"装配 Agent"。就像搭积木一样，把工具函数、MCP 服务、知识库等资源做成标准化的"零件"，Agent 只需要在配置界面里选择挂载哪些零件，就能组装出一个可用的智能体。

这个思路听起来简单，但工程化落地涉及三个关键设计：工具怎么标准化注册、执行时怎么安全调用、多种工具怎么协同工作。本文从 AIGS 框架的完整工具体系出发，梳理这三个设计的工程实现。

一、五类 AI 资产：框架的工具全貌

AIGS 框架把企业 Agent 能用到的资源抽象为五类 AI 资产：

资产类型	说明	注册方式
AI 模型	LLM、Embedding 等推理服务	配置接入
Embedding	向量化模型	配置接入
向量数据库	知识库的存储后端	配置接入
Function	自定义工具函数	注解自动注册
MCP	外部工具协议	配置注册

五类资产统一注册在 AI 资产管理中心，Agent 按需挂载。其中 Function 和 MCP 是最核心的"可装配工具"——它们决定了 Agent 能做什么。

Function 是开发者自己写的 Java 方法，通过注解声明工具信息，框架启动时自动扫描注册。MCP 是外部工具协议，支持本地、流式远程、SSE 远程三种模式。无论是哪种类型，注册后都进入资产管理中心，Agent 在配置界面里勾选即可挂载，不需要写绑定代码。

这种"统一注册 + 按需挂载"的设计，让工具的开发和 Agent 的组装完全解耦。

二、工具注册：从"写代码"到"写注解"

传统做法是每新增一个工具函数，就要写一套注册逻辑——在配置文件里声明工具名称、描述、参数类型，然后在 Agent 代码里手动绑定。工具一多，注册代码比业务代码还长。

AIGS 框架的做法是通过注解自动注册。开发者只需要在方法上加 @FunctionResource 注解声明工具描述，在参数上加 @FunctionParam 注解声明参数含义，框架在启动时自动扫描指定包路径下的注解，完成工具注册。

@FunctionResource(desc = "根据设备编号查询当前运行状态")
public String queryDeviceStatus(
    @FunctionParam(desc = "设备编号，如 DEV-001") String deviceId
) {
    // 业务逻辑
}

框架启动时扫描 extend.ai.tools 包下的所有带注解的类和方法，自动注册为可用的 Function 资源。开发者不用写任何注册代码，不用改配置文件，只要注解写好了，工具就自动出现在资产管理中心。

这种"注解即注册"的模式带来的好处是：工具的开发和 Agent 的开发完全解耦。工具开发者只关心业务逻辑和注解描述，Agent 开发者只关心在配置界面选择挂载哪些工具。两边互不干扰，各自独立演进。

三、工具调用：ReAct 推理链 + 智能反思

工具注册解决了"有什么工具"的问题，调用时的安全性和灵活性同样重要。

ReAct 推理链：让 Agent 边思考边行动

AIGS 框架的 Agent 调用工具不是简单的"用户问 → 调工具 → 返回结果"，而是基于 ReAct 推理链的模式。Agent 在每一步都经历"思考 → 行动 → 观察"的循环：先思考用户的问题需要什么信息，决定调用哪个工具；执行后观察结果，判断是否需要继续调用其他工具；直到收集到足够信息才生成最终回答。

这种"边推理、边行动、边观察"的模式，让 Agent 可以处理需要多步推理的复杂问题——先查知识库找到设备型号，再调接口查实时参数，然后对比历史数据，最终给出综合建议。而不是一次性把所有工具都调用一遍。

智能反思机制

一个常见的风险是 Agent 误触发工具调用——用户只是随便聊天，Agent 却把聊天内容当成了查询指令。比如用户问"设备一般怎么编号"，Agent 不应该去调用"查询设备状态"的函数。

Function Calling 节点内置了智能反思机制：在执行工具调用之前，先让 AI 判断用户的问题是否真的需要调用工具。如果判断结果是"不需要"，就跳过工具调用，直接走普通对话链路。

这个反思判断虽然增加了一次 AI 调用，但能有效避免误触发——比如不必要的数据查询、不必要的接口调用、甚至不必要的写操作。对于企业场景来说，"宁可多判断一次，不可多执行一次"是合理的策略。

分支路由

调用后的结果处理通过分支路由实现：工具匹配并执行成功走 func_call_success 分支，未匹配到合适工具走 func_no_match 分支。开发者可以在编排链路中为两种分支设计不同的后续处理逻辑——匹配成功走数据解读节点，未匹配走兜底对话节点。

安全校验

对于数据源查询类工具，框架在 SQL 执行层内置了安全校验：语句类型检查只允许 SELECT 开头的查询，危险关键词和注释符检查防止 SQL 注入。开发者不需要自己写安全校验逻辑，默认生效。

四、多工具协同：聚合节点

企业 Agent 经常需要同时调用多个数据源。比如用户问"3号产线上周的产量和设备故障率"，产量数据在数据库里，设备故障记录在知识库里，设备状态要通过 API 查询。

AIGS 框架的解法是聚合对话节点，专门负责汇总多个数据源的结果。这个节点支持同时接收五类数据源的输入：

数据源类型	配置字段	典型场景
知识库	klbResultField	文档检索结果
数据源	dataSourceResultField	SQL 查询结果
Excel	excelResultField	表格查询结果
函数调用	funcCallResultField	API 返回数据
MCP	mcpResultField	MCP 工具调用结果

聚合节点的工作逻辑是：各路数据源并行查询，结果汇总后交给大模型做综合分析，生成一个统一的回答。在编排层面，执行链路是"扇形展开再收拢"的——用户输入触发多路并行查询，聚合节点收拢结果，LLM 生成综合回答。

这种设计的工程价值在于：各数据源的查询逻辑独立，互不影响。新增一个数据源只需要挂载资源并在聚合节点里启用对应字段，不需要修改已有的查询逻辑。

五、节点也是可装配的：NodeProvider 机制

不仅工具可装配，执行节点本身也是可装配的。JBoltAI 采用 NodeProvider 机制实现节点的动态注册与管理：

• InnerNodeType 定义所有内置节点类型的常量标识
• NodeProviderCenter 作为节点提供者注册中心，管理节点类型与实现类的映射
• BaseNodeProvider 定义节点执行规范，开发者实现这个接口即可创建自定义节点

框架内置了 27 个节点，覆盖 AI 对话、知识库检索、函数调用、数据处理、流程控制、输出渲染等。开发者也可以编写自定义节点放入 extend.ai.chain 包，框架启动时自动扫描注册。

这意味着如果内置节点不够用，开发者可以自己写节点——比如一个专门查询工业 SCADA 系统的节点，注册后就能像内置节点一样在编排界面里拖拽使用。

六、实战建议

1. 工具描述要写清楚，@FunctionResource 的 desc 直接影响大模型的判断准确率
2. 参数描述要具体，@FunctionParam 的 desc 不要写"查询参数"，要写"设备编号，格式为 DEV-XXX"
3. 反思机制默认开启，除非能确认所有用户输入都需要触发工具调用
4. 先单工具跑通，再加多工具聚合，避免一开始就陷入多数据源调试的复杂性
5. 自定义节点遵循 NodeProvider 规范，保持与内置节点一致的输入输出约定

总结

AIGS 框架的工具体系围绕"装配化"设计：五类 AI 资产统一注册、Function 和 MCP 通过注解和配置自动注册、ReAct 推理链让 Agent 具备"边思考边行动"的复杂推理能力、Function Calling 节点内置反思和分支路由、聚合节点实现多数据源并行协同、NodeProvider 机制让执行节点也可装配。JBoltAI 把这套"注册 → 推理 → 调用 → 协同"的完整链路做了标准化封装，让企业 Agent 的工具装配从"手工编码"变成了"配置组装"，是一种可参考的工程化落地思路。