从Function Calling到Tool Calling：Spring AI架构升级背后的技能考量
一、背景与动机在 Spring AI 1.0.0.M6 版本中，官方正式宣布废弃 Function Calling 功能，全面转向 Tool Calling 体系。这一厘革不仅是 API 层面的重构，更标志着 Spring AI 对工具调用模式的深度优化。作为 Java 生态中最具影响力的 AI 框架，Spring AI 通过此次升级，旨在解决原有 Function Calling 的局限性，同时与行业术语保持划一。
在 Function Calling 模式下，开发者通过定义特定的函数接口，并将其注册到 Spring AI 的 ChatClient 中，实现大语言模型（LLM）与外部服务的交互。这种模式固然在肯定水平上解决了模型获取实时信息和执行复杂使命的问题，但随着应用场景的拓展，其局限性逐渐显现。比方，在处置惩罚复杂业务逻辑时，Function Calling 的接口定义和参数通报显得不敷机动，难以满足多样化的需求。此外，Function Calling 在工具定义和实现的分离上不敷彻底，导致代码的可维护性和复用性较差。
为了应对这些挑衅，Spring AI 引入了 Tool Calling。Tool Calling 不仅在术语上与行业标准接轨，更在设计上进行了全面优化，提供了更加机动、强大的工具调用机制，为开发者构建智能应用提供了更坚实的基础。
二、焦点技能升级解析
1. 术语体系重构
在 Spring AI 的升级过程中，术语体系的重构是迈向标准化和通用化的重要一步。之前版本中的 functions 同一被替换为 tools，这一改变看似简朴，却有着深远的意义。以 OpenAI 和 LangChain 等主流框架为例，它们早已接纳 tools 来形貌可调用的外部资源或功能。Spring AI 通过对齐这一术语，降低了开发者在多框架间切换的学习成本，使得代码库在术语利用上更加同一、清楚。
同时，Spring AI 对工具的相关概念进行了严格的澄清。明确区分工具定义（Tool Definition）与工具实现（Tool Implementation），工具定义如同一份左券，规定了工具的名称、输入输出参数的格式以及功能形貌，而工具实现则是详细的代码逻辑，负责执行工具定义中形貌的使命。这种区分使得工具的抽象和复用更加轻易，开发者可以根据差别的需求，在差别的项目中复用相同的工具定义，而只需提供差别的工具实现。
在场景扩展方面，新的 Tool Calling 体系支持更复杂的工具链编排。比方，在一个智能客服体系中，可能必要先通过信息检索工具从知识库中获取相关信息，然后根据这些信息执举措作执行工具，如天生回复邮件并发送。在 Function Calling 时代，实现这样的复合场景必要较为复杂的代码逻辑，而现在，Spring AI 的 Tool Calling 通过简便的设置和接口，即可轻松实现工具链的编排，大大提升了体系的机动性和扩展性。
2. 架构设计优化
Spring AI 在架构设计上进行了全面优化，以提升工具调用的效率和可维护性。接纳分离式设计，将工具定义与实现解耦。在旧的 Function Calling 模式下，工具的定义和实现往往精密耦合在一起，这使得代码的复用和维护变得困难。而在新的 Tool Calling 架构中，工具定义可以独立于实现存在，并且可以在差别的项目中复用。比方，一个用于查询数据库的工具定义，可以在多个差别的业务项目中利用，每个项目只需根据自身的数据库环境提供相应的工具实现。
为了加强类型安全，Spring AI 引入了 ToolDefinition 接口，该接口欺压要求工具输入输出的 JSON Schema 定义。通过 JSON Schema，开发者可以精确地定义工具的输入输出格式，从而在编译时就能发现类型错误，避免了运行时的错误。比方，一个用于计算两个数字之和的工具，通过 JSON Schema 可以明确规定输入参数为两个数字类型，输出也为数字类型，这样在调用该工具时，Spring AI 会主动验证输入参数的类型，确保工具的精确调用。
在方法级支持上，Spring AI 通过 MethodToolCallback 直接绑定 Java 方法，简化了反射调用。在旧模式下，调用 Java 方法必要通过复杂的反射机制，这不仅效率低下，而且轻易堕落。现在，通过 MethodToolCallback，开发者可以直接将 Java 方法与工具进行绑定，Spring AI 会主动处置惩罚方法的调用和参数通报，大大进步了开发效率和代码的可读性。
3. API 演进路径
随着从 Function Calling 到 Tool Calling 的厘革，Spring AI 的 API 也发生了显著的厘革，以适应新的工具调用模式。在回调接口方面，旧的 FunctionCallback 被替换为 ToolCallback，ToolCallback 继承了 FunctionCallback 的根本功能，并在此基础上进行了扩展，增长了对工具定义和元数据的支持。比方，ToolCallback 提供了 getToolDefinition 方法，用于获取工具的定义信息，包括工具名称、形貌和输入输出参数等。
客户端设置也进行了相应的调解。ChatClient.builder ().defaultFunctions 被替换为 ChatClient.builder ().defaultTools ()，用于设置默认的工具列表。这一厘革使得设置更加直观，符合新的术语体系。
在构造器模式上，FunctionCallback.builder ().function () 被替换为 FunctionToolCallback.builder ()，FunctionCallback.builder ().method () 被替换为 MethodToolCallback.builder ()。这些厘革简化了工具回调的构建过程，使得代码更加简便明了。
上下文选项方面，FunctionCallingOptions.builder ().functions () 被替换为 ToolCallbackChatOptions.builder ().toolNames ()，用于设置工具调用的上下文选项。同时，FunctionCallingOptions.builder ().functionCallbacks () 被替换为 ToolCallbackChatOptions.builder ().toolCallbacks ()，用于设置工具回调列表。这些厘革使得上下文选项的设置更加机动和强大，开发者可以根据详细需求，精确地控制工具的调用行为。
功能模块Function Calling 旧 APITool Calling 新 API回调接口FunctionCallbackToolCallback客户端设置ChatClient.builder().defaultFunctionsChatClient.builder().defaultTools()构造器模式FunctionCallback.builder().function()FunctionToolCallback.builder()FunctionCallback.builder().method()MethodToolCallback.builder()上下文选项FunctionCallingOptions.builder().functions()ToolCallbackChatOptions.builder().toolNames()FunctionCallingOptions.builder().functionCallbacks()ToolCallbackChatOptions.builder().toolCallbacks() 三、开发者迁移指南
1. 代码改造步调
开发者在从 Function Calling 迁移到 Tool Calling 时，必要遵照一系列的代码改造步调。首先，必要对项目中的工具定义进行全面的梳理和更新。将所有 Function 前缀的类替换为 Tool 前缀，比方，FunctionCallback 替换为 ToolCallback，FunctionToolCallback.builder () 替换为 FunctionToolCallback.builder () 。
在 ChatClient 设置方面，必要将 defaultFunctions 调用替换为 defaultTools ()。比方，原有的设置 ChatClient.builder().defaultFunctions(Arrays.asList(function1, function2)) 应改为 ChatClient.builder().defaultTools(Arrays.asList(tool1, tool2))。
工具参数的定义也必要进行调解，以符合 JSON Schema 规范。建议利用 @JsonProperty 注解来明确指定参数的名称和类型，确保工具调用时参数的精确性和划一性。
2. 关键留意事项
在迁移过程中，有几个关键的留意事项必要开发者特殊关注。所有 Function 前缀的类必须准确无误地替换为 Tool 前缀，这不仅涉及到类名的修改，还包括相关接口和方法的调用。在替换过程中，要细致检查代码的上下文，确保替换后的代码可以或许精确编译和运行。
必要检查 ChatClient 设置中的 defaultFunctions 调用，确保已全部替换为 defaultTools ()。假如遗漏了某些调用，可能会导致工具无法精确注册，从而影响应用的正常运行。
工具参数需严格符合 JSON Schema 规范，这是包管工具调用准确性和稳定性的关键。利用 @JsonProperty 注解可以清楚地定义参数的名称、类型和其他相关属性，避免因参数格式不划一而引发的错误。
异常处置惩罚策略也必要进行相应的调解。在新的 Tool Calling 体系中，新增了 ToolExecutionException 类型，用于处置惩罚工具执行过程中可能出现的异常。开发者必要在代码中捕获并妥善处置惩罚这些异常，确保应用的健壮性和稳定性。
四、Tool Calling 的焦点优势
1. 功能扩展能力
在当今数字化时代，实时数据的获取和处置惩罚对于企业的决策和运营至关重要。Spring AI 的 Tool Calling 为开发者提供了强大的功能扩展能力，使大语言模型可以或许突破自身的局限性，实现与外部体系的高效交互。
通过工具调用，模型可以实时访问数据库或 API，获取最新的数据信息。比方，在一个金融应用中，模型可以通过调用数据库查询工具，获取实时的股票价格、汇率等金融数据，从而为用户提供准确的投资建议。这种实时数据访问能力，使得模型可以或许根据最新的信息进行推理和决策，大大进步了应用的准确性和实用性。
Tool Calling 还支持触发外部体系的主动化操作。以一个企业的客户关系管理（CRM）体系为例，当客户提出服务请求时，模型可以通过调用创建工单工具，主动在 CRM 体系中创建相应的工单，并分配给符合的客服人员进行处置惩罚。同时，模型还可以调用发送邮件工具，向客户发送确认邮件，告知其服务请求已收到。这种主动化操作不仅进步了工作效率，还减少了人为错误，提升了客户满意度。
在多模态支持方面，Tool Calling 更是展现出了强大的优势。它可以集成图像处置惩罚、语音识别等非文本工具，实现多模态信息的处置惩罚和交互。比方，在一个智能安防体系中，模型可以通过调用图像处置惩罚工具，对监控摄像头拍摄的图像进行分析，识别出异常行为或物体。同时，模型还可以调用语音识别工具，将监控视频中的语音内容转换为文本，以便进行进一步的分析和处置惩罚。这种多模态支持能力，使得模型可以或许更加全面地理解和处置惩罚信息，为用户提供更加智能和便捷的服务。
2. 性能优化特性
为了进步工具调用的效率和性能，Spring AI 的 Tool Calling 引入了一系列的性能优化特性。
缓存机制是此中的一项重要特性。对于高频调用的工具，Tool Calling 会主动缓存其调用效果。当再次调用相同的工具时，体系会首先检查缓存中是否存在相应的效果，假如存在，则直接返回缓存效果，而无需再次执行工具。这大大减少了工具的重复执行次数，进步了体系的响应速度。比方，在一个电商应用中，用户经常查询商品的库存信息。通过缓存机制，当用户再次查询相同商品的库存时，体系可以直接从缓存中获取效果，而无需再次查询数据库，从而显著进步了查询效率。
批量处置惩罚功能也是 Tool Calling 的一大亮点。它可以将多个工具调用请求合并为一个，一次性发送给外部体系进行处置惩罚。这减少了网络传输次数和体系开销，进步了处置惩罚效率。比方，在一个数据分析应用中，必要同时查询多个数据表中的数据。通过批量处置惩罚功能，体系可以将这些查询请求合并为一个，一次性发送给数据库进行处置惩罚，从而减少了数据库的负载，进步了查询速度。
流式响应是 Tool Calling 的又一重要特性。它支持工具调用效果的分段返回，使得用户可以或许更快地看到部分效果，而无需等待整个处置惩罚过程完成。在处置惩罚大型文件或复杂使命时，流式响应可以显著进步用户体验。比方，在一个文件下载应用中，通过流式响应，用户可以在文件下载的过程中就开始查看文件内容，而无需等待整个文件下载完成。
3. 安全管理加强
在企业级应用中，安全是至关重要的。Spring AI 的 Tool Calling 在安全管理方面进行了全面的加强，为企业提供了更加可靠的安全保障。
细粒度权限控制是 Tool Calling 安全管理的焦点特性之一。它基于工具级别的 RBAC（基于角色的访问控制）管理，确保只有授权的用户或角色才能调用特定的工具。比方，在一个企业的财政体系中，只有财政人员才能调用财政数据查询工具，而普通员工则无法访问这些敏感信息。这种细粒度的权限控制，有效地掩护了企业的敏感数据和业务逻辑。
操作审计是 Tool Calling 安全管理的另一重要特性。它会完整记载工具调用链，包括工具的调用者、调用时间、输入参数和输出效果等信息。这些审计记载可以用于追踪和分析工具的利用情况，发现潜伏的安全风险和问题。比方，当出现数据泄漏变乱时，通过查看操作审计记载，可以快速确定是哪些用户在什么时间调用了哪些工具，从而采取相应的步调进行处置惩罚。
为了进一步掩护敏感数据的安全，Tool Calling 还支持敏感数据过滤。它可以主动屏蔽工具返回效果中的敏感字段，防止敏感信息泄漏。比方，在一个医疗应用中，工具返回的患者病历信息中可能包罗患者的身份证号、接洽方式等敏感信息。通过敏感数据过滤，这些敏感字段可以被主动屏蔽，只返回必要的医疗信息，从而掩护了患者的隐私。
五、典型应用场景
1. 智能客服体系
在智能客服体系中，Spring AI 的 Tool Calling 发挥着至关重要的作用，极大地提升了客服效率和用户体验。以电商平台的智能客服为例，当用户咨询 “我购买的商品什么时候能到货？” 这样的问题时，传统的智能客服可能只能根据预设的话术进行回答，无法提供准确的物流信息。而基于 Spring AI 的 Tool Calling，客服体系可以调用物流查询工具，直接从物流体系中获取实时的物流信息，并准确地告知用户商品的预计到货时间。
当用户扣问关于商品的详细信息时，智能客服体系可以调用商品信息查询工具，从商品数据库中获取商品的规格、材质、利用方法等详细信息，为用户提供全面的解答。假如用户必要退换货，智能客服体系还可以调用订单处置惩罚工具，直接在订单体系中为用户创建退换货申请，并跟踪处置惩罚进度，实时反馈给用户。
在实际应用中，许多电商企业已经乐成地接纳了 Spring AI 的 Tool Calling 技能，实现了智能客服的升级。某知名电商平台通过引入 Spring AI，将智能客服的问题解决率进步了 30%，用户满意度提升了 25%，同时大幅减少了人工客服的工作量，降低了运营成本。
2. 数据分析平台
在数据分析平台中，Spring AI 的 Tool Calling 为数据分析师提供了更加便捷、高效的数据分析工具。以金融行业的数据分析平台为例，数据分析师经常必要从多个数据源中获取数据，并进行复杂的数据分析和可视化处置惩罚。
在处置惩罚市场趋势分析时，数据分析师可以利用自然语言向数据分析平台提问，如 “分析过去一年股票市场的走势，并天生趋势图”。Spring AI 的 Tool Calling 会调用数据查询工具，从金融数据库中获取过去一年的股票数据，然后调用数据分析工具，对数据进行分析和处置惩罚，末了调用可视化工具，天生股票市场的趋势图，直观地展示给数据分析师。
在进行风险评估时，数据分析师可以扣问 “评估当前投资组合的风险，并给出建议”。Spring AI 的 Tool Calling 会调用风险评估工具，联合市场数据和投资组合信息，对投资组合的风险进行评估，并调用决策支持工具，根据评估效果给出相应的投资建议。
许多金融机构已经利用 Spring AI 的 Tool Calling 构建了智能数据分析平台，进步了数据分析的效率和准确性，为投资决策提供了有力的支持。某大型银行通过引入 Spring AI，将数据分析的时间紧缩了 50%，风险评估的准确率进步了 20%，有效提升了金融服务的质量和竞争力。
六、未来发展方向
1. 工具生态创建
Spring AI 计划打造一个丰富的官方工具库，涵盖多种常见的业务场景。在一样平常生活类应用中，提供天气查询工具，用户通过与智能助手交互，即可获取实时天气信息，合理安排出行计划；舆图导航工具则方便用户在出行时获取路线规划、实时路况等信息，实现高效出行。在金融领域，支付工具可实现安全便捷的在线支付功能，满足电商生意业务、转账汇款等场景需求；股票查询工具则能为投资者提供实时股票行情、汗青数据等信息，辅助投资决策。
2. 可视化编排
未来，Spring AI 将支持通过 Spring Boot Admin 进行工具链的可视化编排。Spring Boot Admin 是一个用于管理和监控 Spring Boot 应用步伐的工具，它提供了直观的用户界面。在这个界面中，开发者可以通过简朴的拖拽操作，将差别的工具节点连接起来，形成复杂的工具链。比方，在一个智能物流调度体系中，开发者可以将订单信息获取工具、库存查询工具、车辆调度工具等通过 Spring Boot Admin 进行可视化编排，实现订单从吸收、处置惩罚到配送的全流程主动化。这种可视化的编排方式，大大降低了工具链搭建的难度，进步了开发效率，使得非专业技能人员也能轻松参与到智能应用的开发中。
3. 模型无关性
为了满足企业多样化的需求，Spring AI 将进一步加强模型无关性，适配更多的第三方大模型。除了支持 OpenAI 等国际知名大模型外，还将积极与国内的优秀大模型互助，如百度的文心一言、字节跳动的云雀模型、阿里的通义千问、科大讯飞的星火认知大模型等。企业可以根据自身的业务需求、数据安全要求、成本预算等因素，自由选择适合的大模型。在对文本处置惩罚速度和准确性要求较高的场景下，企业可以选择性能杰出的文心一言；在注重多模态交互和创新能力的应用中，云雀模型可能是更好的选择。这种模型无关性，为企业提供了更多的选择空间，降低了对单一模型的依赖，同时也促进了大模型市场的竞争与发展。
4. 异步支持
为了更好地处置惩罚长时间运行的工具，Spring AI 计划引入 Reactor 模式。Reactor 模式是一种基于变乱驱动的设计模式，它通过一个变乱循环来监听和处置惩罚各种变乱。在处置惩罚必要长时间运行的工具时，如大数据分析工具、复杂的机器学习模型练习工具等，Spring AI 可以将工具的执行过程封装成一个异步使命，通过 Reactor 模式进行管理。在执行大数据分析使命时，Spring AI 会将使命提交给异步使命队列，然后立刻返回，不会壅闭主线程。当使命执行完成后，通过回调函数或变乱通知的方式，将效果返回给调用者。这种异步支持，进步了体系的响应性能，使得体系可以或许在处置惩罚长时间运行使命的同时，实时响应用户的其他请求，提升了用户体验。
七、总结
Spring AI 的 Tool Calling 升级不仅是 API 的版本迭代，更是对大模型应用架构的深度重构。通过标准化术语、加强类型安全、优化工具编排能力，开发者可以或许更高效地构建智能中枢体系。建议现有效户尽快迁移至新 API，以享受更稳定的工具调用体验和更强的扩展能力。未来，随着 Spring AI 与 Spring 生态的深度整合，工具调用将成为企业智能化转型的焦点基础办法。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]