LLM之Agent落地篇

---

前言

继之前的两篇文章：

LLM之Agent初探
LLM之Agent再探

前面两篇文章主要是介绍了如何用LLM做个Agent的Demo，离实际的落地，还差了一大截，这篇文章就来讲讲Agent该如何落地。

以下几个模块，是Agent在企业产品落地中必然会碰到的问题

多轮Query改写

想要把Agent做到实际的产品中，多轮对话是必须要支持的，这个模块，主要解决以下问题。

• 当需要调用Tool时，用户并没有一次性传递全部参数，举个例子：购票场景，用户需要购买杭州到长沙的车票，此时API需要两个参数：起点、终点。如下
  
  此时，应该结合用户的历史对话，去判断当前用户输入的意图，并且能够拼接历史提供的参数信息。如：帮我买一张火车票，起点是杭州，终点是长沙。

如果不进行改写，在第三轮用户输入为：长沙 时，Tool检索模块将无法检索到正确的Tools.

Tools 检索模块

tool的检索和重排是必不可少的，我给这里再增加了一个tool的过滤，即使用LLM过滤出要解决该问题，最可能会用到的API，如果过滤后的Tools为空，则表示该问题只需要使用LLM的通用能力来回答即可。既做到了Tools的过滤，又实现了Query的分类，一举多得。

提示检索

这个模块的主要作用：为了快速解决复杂的API调用或者需要将问题进行分解/分步执行才能拿到结果的场景。

比如说：API B 的输入参数，依赖于API A 的输出。

对于通用LLM来说，是不知道你这个业务场景需要怎样的调用逻辑的，无法对你给出的问题进行分解，除非你直接在Prompt中直接告诉LLM，API B 的输入参数，依赖于API A 的输出，否则它是不知道如何调用的，这里的提示检索，就是为了解决这个问题，将一些业务复杂的API的调用逻辑，人工编辑好调用逻辑，使用检索+LLM过滤的方式，筛选出最相关的提示，帮助LLM进行问题分解。

总结

以上三个模块，仅仅提供一种思路，各位有更好的想法，可以在评论区留言讨论。

暂时写到这儿了，有点流水账的感觉，很久没写了。