做一个智能体很简单，但想做好一个智能体很不简单 原创

“ 多智能体协同将是未来智能体的主要开发形式，其相对于单智能体更灵活更强大。”

技术是一项重实践而轻理论的东西，但我们很多时候容易陷入重理论轻实践；总觉得理论我懂了，做出来肯定很简单，但事实上理论很容易懂，但真正做出来却很难。

知行合一，在知中行，在行中知；知行是一体的，而不是割裂的。

怎么做好一个智能体

之前学习过一段时间智能体的实现，使用的是Langgraph框架，但当时只是做了一些简单的Demo，并没有真正应用到具体的业务场景中，因此那时觉得做一个智能体好像很简单，而且智能体好强大。

但等到真正想把智能体应用到真实的业务场景中才发现，想做好一个智能体真的不简单，因为到现在为止好像感觉有点无从下手。

在学习智能体开发时，那时的主要思路是按照智能体的开发模式，然后找一个简单的案例去实现；但在真实场景中很难有那种理想模式的智能体开发，反而因为业务需求的原因，导致智能体开发变得很复杂。

以作者使用智能体改造RAG系统为例，理想情况下是给大模型配置几个召回工具，然后让智能体根据用户问题去调用工具然后获取结果；但现实的需求点是，在使用工具召回数据之后，还需要对这些数据进行处理；比如说需要给用户端展示参考了哪些文档，哪些内容；这时就不仅仅只是把工具召回的结果丢给模型，而是需要对召回的数据做处理；但问题是这个处理怎么做？更重要的是怎么才能做的更通用？

毕竟从技术的角度来说，我总不能每次添加一个工具，就要对智能体进行重构，这样不论从技术上还是时间上成本都太高，而且不符合软件设计的原则。

因此，到底怎么做好一个智能体？

首先一点是，我们要明白什么是智能体，以及智能体应该怎么做，还有就是智能体的能力边界；孙子兵法云:“知己知彼，百战不殆”；这句话应用到技术开发中同样如此。

简单来说智能体就是大模型+工具+提示词，但这只是智能体最简单的模式，其能实现的功能也很简单；而面对复杂业务问题就需要对智能体进行适当的调整或者改变。

首先，以作者改造RAG为例，智能体就不能简单的调用召回工具，然后把召回结果丢给模型；这时甚至一个智能体都无法完成这个任务，更好的解决方式可能是使用两个智能体，也就是多智能体。

第一个智能体的任务是接受用户请求，并处理响应结果；第二个智能体只做数据召回，其功能是根据用户需求调用召回工具，然后把召回结果做合并，清洗，格式化等操作；之后再把结果丢给第一个智能体。

这样就可以从技术上把用户端和业务端分开，不论业务端怎么变化；在数据召回上都是无感的，而且可以在任何地方使用。

所以，从理论上来说多智能体开发应该是未来的趋势，其相当于单智能体具备很多优势；而且，多智能体可以简单到就一句提示词，也可以复杂到是一个ReAct智能体，甚至更复杂。

智能体是一个使用 LLM 来决定应用程序控制流的系统。随着你开发这些系统，它们可能会随着时间的推移变得越来越复杂，使得管理和扩展变得更加困难。例如，你可能会遇到以下问题：

• 智能体有太多工具可供使用，导致在决定下一步调用哪个工具时做出糟糕的决策
• 上下文变得过于复杂，单个智能体难以跟踪
• 系统中需要多个专业领域（例如，规划师、研究员、数学专家等）

使用多智能体系统的主要好处是：

• 模块化：独立的智能体使得开发、测试和维护智能体系统更加容易。
• 专业化：你可以创建专注于特定领域的专家智能体，这有助于提高整个系统的性能。
• 可控性：你可以明确控制智能体之间的通信方式（而不是依赖于函数调用）。

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