关于在智能体开发中工具节点的返回值处理 原创

“ 智能体开发过程中存在很多细节性问题，而这些问题决定着智能体的质量。”

最近要把RAG系统优化成智能体实现，因此又深入研究了一下智能体的实现方式，开发框架使用的是Langgraph；然后在工具执行的时候出了一点问题。

智能体工具节点

智能体简单来说就是会使用工具的大模型，主要由大模型(Model)+工具(Tool)+提示词(Prompt)构成；其原理就是通过让大模型理解用户问题，然后自己根据工具说明，生成调用参数执行工具，最终获取执行结果，本质上就是让大模型调API，只不过传统的方式是由开发人员写调用代码，而智能体自己生成请求参数。

既然智能体能够执行工具，因此我们就可以把很多功能封装成API提供给智能体使用，这样智能体就可以根据用户问题做自主决策来完成任务。

在Langgraph中，调用工具是通过工具节点——ToolNode来执行的；而且在Langgraph中的执行流程是一个节点一个节点的执行。因此，需要大模型调用工具之后，需要在ToolNode节点中执行完之后，把执行结果放到State状态图中，然后再在模型节点中从State获取工具调用结果。

在智能体中所谓的工具本质上就是一个个函数，其和我们平常写的功能函数没什么区别；只不过把调用方换成了大模型。因此，这里就有一个问题，那就是在平常人工编码开发过程中，函数的返回值基本上都是结构化的数据。

但在智能体中，模型直接获取工具节点的执行结果，然后解决用户问题；这时对工具的执行结果就有讲究了。

我们只能实现多功能智能体有两种方式，一种是给一个智能体配置多个工具，另一种是根据单一职责原则，一个智能体只配置有限的几个工具，然后通过组合的方式来实现复杂功能。

因此，针对多个功能不同的工具，比如说有些工具处理的是中间过程，而有些工具处理的是最终结果；这些中间过程的工具执行结果可能还需要用来调用另一个工具，而最终的处理结果需要丢给大模型进行处理。

以召回功能为例，我们最终丢给大模型的是一个格式化之后的参考文档，而不仅仅是一个检索回来的文档列表；因此，工具的最终执行结果也要进行处理格式化处理；比如说把召回文档列表的主要内容给提取出来，而不是把存在很多无用参数的查询结果丢给模型，比如说文档的ID，时间，介绍等。

其中还一个主要问题是，在工具中如果也要使用大模型功能，在Langgraph的模型节点进行流式返回的时候，会把工具中模型的执行结果也进行流式输出；从理论上来说这应该是有问题的。

因为，对模型节点来说需要的是工具的执行结果，而不是工具的执行过程；这样不但会影响到模型的最终输出效果，同时还会暴露背后的工具，这是一种潜在的风险；因此在处理过程中需要对工具节点的数据进行过滤。

本文转载自​​​​​​AI探索时代​​​​​​ 作者：DFires