使用本地大模型调用代码，根本就是一场骗局！

通过大模型调用其他工具到底可不可行？ChatGPT 或许能轻松搞定一切，但同样的需求落在本地大模型上，恐怕就要打个问号了。
法国开发工程师 Emilien Lancelot 尝试了多款号称具备工具调用功能的 agent 框架，来看看本地大模型到底能不能完成任务，但结果就像他总结的“一无所获”。是什么让这位工程师失望了？

用 AutoGPT，得会点“糊弄学”

AutoGPT 是款貌似强大的框架，提供很酷的 CLI 外加 Flutter UI，能够通过浏览器创建 agent。其主要功能是处理用户的文档、音频、视频等本地内容。

但是……它主要依靠 ChatGPT 或其他专有大模型服务来完成繁重工作，至少给我们的感觉是如此。

我们必须“唬弄”AutoGPT 才能使用 Ollama 端点，让其误认为是 ChatGPT。

## OPENAI_API_KEY - OpenAI API Key (Example: sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
OPENAI_API_KEY="helloworld"...## OPENAI_API_BASE_URL - OpenAI API 的自定义 URL，可用于接入自定义后端。如果 USE_AZURE 为 true 则无效，注意留空以保留默认 url。
# 以下为示例内容：
OPENAI_API_BASE_URL=http://localhost:11434/v1...## SMART_LLM - 智能语言模型 (Default: gpt-4-turbo)
SMART_LLM=dolphin-mixtral:8x7b-v2.7-q4_K_M## FAST_LLM - 快速语言模型 (Default: gpt-3.5-turbo)
FAST_LLM=mistral:latest

这样应该可以解决问题：

./autogpt.sh runvalue is not a valid enumeration member; permitted: 'text-embedding-ada-002', 'text-embedding-3-small', 'text-embedding-3-large', 'gpt-3.5-turbo-0301', 'gpt-3.5-turbo-0613', 'gpt-3.5-turbo-16k-0613', 'gpt-3.5-turbo-1106', 'gpt-3.5-turbo-0125', 'gpt-3.5-turbo', 'gpt-3.5-turbo-16k', 'gpt-4-0314', 'gpt-4-32k-0314', 'gpt-4-0613', 'gpt-4-32k-0613', 'gpt-4-1106-preview', 'gpt-4-1106-vision-preview', 'gpt-4-0125-preview', 'gpt-4-turbo-2024-04-09', 'gpt-4', 'gpt-4-32k', 'gpt-4-turbo', 'gpt-4-turbo-preview', 'gpt-4-vision-preview' (type=type_error.enum; enum_values=[<OpenAIModelName.EMBEDDING_v2: 'text-embedding-ada-002'>, <OpenAIModelName.EMBEDDING_v3_S: 'text-embedding-3-small'>, <OpenAIModelName.EMBEDDING_v3_L: 'text-embedding-3-large'>, <OpenAIModelName.GPT3_v1: 'gpt-3.5-turbo-0301'>, <OpenAIModelName.GPT3_v2: 'gpt-3.5-turbo-0613'>, <OpenAIModelName.GPT3_v2_16k: 'gpt-3.5-turbo-16k-0613'>, <OpenAIModelName.GPT3_v3: 'gpt-3.5-turbo-1106'>, <OpenAIModelName.GPT3_v4: 'gpt-3.5-turbo-0125'>, <OpenAIModelName.GPT3_ROLLING: 'gpt-3.5-turbo'>, <OpenAIModelName.GPT3_ROLLING_16k: 'gpt-3.5-turbo-16k'>, <OpenAIModelName.GPT4_v1: 'gpt-4-0314'>, <OpenAIModelName.GPT4_v1_32k: 'gpt-4-32k-0314'>, <OpenAIModelName.GPT4_v2: 'gpt-4-0613'>, <OpenAIModelName.GPT4_v2_32k: 'gpt-4-32k-0613'>, <OpenAIModelName.GPT4_v3: 'gpt-4-1106-preview'>, <OpenAIModelName.GPT4_v3_VISION: 'gpt-4-1106-vision-preview'>, <OpenAIModelName.GPT4_v4: 'gpt-4-0125-preview'>, <OpenAIModelName.GPT4_v5: 'gpt-4-turbo-2024-04-09'>, <OpenAIModelName.GPT4_ROLLING: 'gpt-4'>, <OpenAIModelName.GPT4_ROLLING_32k: 'gpt-4-32k'>, <OpenAIModelName.GPT4_TURBO: 'gpt-4-turbo'>, <OpenAIModelName.GPT4_TURBO_PREVIEW: 'gpt-4-turbo-preview'>, <OpenAIModelName.GPT4_VISION: 'gpt-4-vision-preview'>])

看来没那么好唬弄，模型名称要求必须为专有名称，例如“GPT4-turbo”或者以上列表中包含的其他名称。遗憾的是，我的模型命名不在其中。

现在看看能不能“伪造”一个合规模型名称，这里将名称设置为“GPT4-turbo”并再次运行。

./autogpt.sh run
2024-05-19 16:03:01,937 ERROR  Invalid OpenAI API key! Please set your OpenAI API key in .env or as an environment variable.
2024-05-19 16:03:01,938 INFO  You can get your key from https://platform.openai.com/account/api-keys

这回我的 API key 没能过关。我尝试了多种不同 key，但仍然无法再进一步。

*项目链接：*https://github.com/Significant-Gravitas/AutoGPT

不过，奇怪的是，必要的配置文件设置现在显示“404”了。

实验小结

要想解决模型名称问题，我们可以在 Ollama 当中创建一个名为 GPT4-turbo 的自定义模型，但模型内容实际可以是任意本地模型。这单纯是在用重命名的方式唬弄 AutoGPT，但却无法解决 API key 错误。

另外需要强调的是，似乎可以在 AutoGPT 上照搬 OpenAI 模型提供的文件并删除所有不合规部分，但我不确定具体该怎么操作。

网上的相关文件*（https://github.com/Significant-Gravitas/AutoGPT/issues/6336#issuecomment-2119252849）*没有介绍使用本地模型的任何内容，也没有提到如何调用工具。

总之，我认为 AutoGPT 恐怕还没有准备好对接本地模型，只能等后续升级之后再做本地化应用尝试。

此外，网友 Wladastic 也在使用后评价道，“我没有任何本地模型可以完全与 Auto-GPT 配合使用，因为 GPT-4 可以保持上下文长度而不会过于关注它，但其他有效的模型确实过于关注给予 LLM 的提示。”

Wladastic 解释道，“我让它与 Mistral 7B AWQ、neural chat v3 AWQ 和其他模型一起运行。唯一的问题是，我必须从头开始编写自己的 Auto-GPT，因为 Auto-GPT 的提示对于本地 llms 来说太长且混乱。”

“它们有时会返回正确的提示，但有时会通过 Auto-GPT 专注于系统提示，因此它们会以“Hello，我正在使用命令 ask_user 与用户交谈，这是正确的吗?”，然后它会说“Hello，我能如何帮助你?”，大约 100 次，直到我取消它。”Wladastic 说道。

Wladastic 表示，“我目前使用 oobabooga text-generation-webui 的用例在添加 JSON 语法时效果最好。然后，它只能在非常基本的提示符和只有几个命令的情况下工作，否则它会不断生成新的命令，并开始产生幻觉、同时响应多个命令等等。”

太复杂的 LangChain

自从生成式 AI 浪潮爆发以来，Langchain 已经成为诸多项目的核心。而它之所以还没有成为客观标准，原因可能在于它的语法太过复杂，很多开发者没时间去学习和适应。

Langchain 提供的是一种相当晦涩的 Python 功能使用方式，很多经验丰富的开发者恐怕都弄不明白。举例来说：

chain = prompt | model | outputparser
chain.invoke("Question.")

Python 的 LCEL 系统使用 pipes（「|」）将事物串连起来。具体在 Python 之内，就是通过覆盖 Python 的 or 方法来实现。换句话说，Langchain 会像在 C++ 那些覆盖掉运算符。

但我们真有必要这么折腾吗？这就留待各位自行判断了……

现在说说本地模型。

Langchain 提供 2 款插件：

Ollama chat: 允许用户与大模型对话。
Ollama-functions: 允许大模型通过特定输出格式回答问题。例如，假设我们希望自己的大模型以 JSON 或者 YAML 形式作答，则可定义自己期望的格式类型、键和值类型。

另外请注意“函数调用”功能！这纯纯就是 OpenAI 的恶搞，千万别被功能名称给蒙蔽了！它并不像大家想象中那样以“使用工具”的方式调用函数，而只是对大模型的输出做格式调整。

那么，工具调用（即在本地执行真实代码）到底可不可行？这个嘛……Ollama 插件不提供这项功能……

在这里插入图片描述

这项操作的运行输出为：

ChatOllama doesn't have a method bind_tools()

可以确定它办不到，咱们又被耍了……

实验小结

必须承认，我感觉有点失望。因为这套框架在为 CrewAI 等许多其他框架提供支持，所以我本以为它能跟本地工具良好集成。但事实证明，它做得并不好，这个复杂的烂摊子同样没办法帮我们解决核心需求。

缺少工具支持的 Rivet

靠谱的选手终于来了！虽然 Rivet 还很年轻，但前景光明、未来可期。

Rivet 用于创建复杂的 AI 代理和提示链，它是某种用于跟大模型交互的 IDE，使用画布创建执行图（DAG）。Rivet 能够在浏览器中运行，同时允许用户导出 DAG 并作为代码运行以增强软件功能。

Rivet 目前支持的大模型有：GPT-3.5、GPT-4、Claude 2、 Claude 3 系列、用于语音数据的 AssemblyAI LeMUR 框架等。

大伙看看，这界面太酷了，Rivet 还提供 Ollama 插件以支持本地使用。

请注意单击右上角的三个点并将执行器更改为“节点”，否则可能无法运行。

遗憾的是，我没有找到调用自定义工具的方法，而且 Rivet 的项目文档也不够完备。这个项目显然还需要进一步更新，但强烈建议大家关注。

实验总结

这软件很酷，免费而且开源。我喜欢它的画面系统设计，用起来感觉就像做对了的 LangGraph。

要让它真正发挥作用，还得配合工具调用。但如果各位已经拥有 ChatGPT 账户，那还犹豫什么，赶紧把 Rivet 用起来。

让人看不懂教程的 AutoGen

作为本份榜单中表现最好的方案之一，AutoGen 微软公司开源的多智能体（Mutiple Agents）应用开发框架，多智能体应用让不同的 Agent 之间相互交流沟通来解决问题。

我已经按说明走完了教程，必须承认……其中大部分步骤我都没搞明白！刚开始几页还可以，但情况很快陷入失控，我可能得借助 AI agent 框架才能理解这一切到底是怎么起效的。

但 Autogen 确实具备我们需要的一切，而且开箱即用支持 Ollama：

在这里插入图片描述

在我看来，Autogen 最棒的特性包括：

动态生成代码并执行；
调用工具（即调用我们的代码）；
支持人工输入。

但工具调用真能起效吗？

还是不行……必须调用大模型的 OpenAI 兼容工具才能实现这项功能，所以 Ollama + Mistral 的理想终究只是理想。但是，Autogen 的代码生成和执行功能都运行良好。另外需要注意，它不支持调用 LangChain 工具。

可供使用的聊天机制

双模型聊天模式：允许两个大模型相互对话以完成任务

按序对话：任务将按照您指定的顺序进行评估。

这就有点复杂了。涉及多轮对话中积累的上下文延续机制，的确是个难以理解的概念。为什么每项任务仍然表现成两个 agent 之间的对话？为什么是 A 对 B、A 对 C、A 对 D 和 A 对 E？为什么永远是从 A 开始？我实在是整不明白。

群组对话：彻底无法理解了……

看这意思，好像是某个 agent 充当主脑，在其他各 agent 之间建立了某种层次结构。这个概念可能很有吸引力，但文档示例实在起不到帮助理解的作用。

它还支持最新的提示工程方式，例如：

ReAct：允许拆分操作并制定计划。之后它会尝试执行各个步骤，一旦出现问题，则会制定新的计划并重新开始。通过这样的方式，即可创建对于大模型具备语义含义的上下文，并帮助其专注于当前需要解决的任务。
Reflection：跟 ReAct 有点类似，但强调的是自己的输出。在“说话”之后，它会问自己“这个结果对吗？”而且自我迭代似乎确能提升答案质量。

与往常一样，所谓提升答案质量也就是减少幻觉，这正是当前困扰大语言模型的核心问题。

如果各位不想被代码吞没，也可以尝试下载 AutoGenStudio 软件，它能在不编写任何代码的前提下完成 agent 定义。这是一款有趣的软件，但并不能帮助我们真正掌握框架的核心功能。

实验小结

AutoGen 显然有着光明的未来。但因为是由微软开发而成，我们唯一担心的就是它可能会被最终抛弃、或者成为仅限跟 OpenAI 搭配使用的软件。

但哪怕是它，也仍然实现不了本地大模型的工具调用功能。😦

要写大量提示词的 CrewAI

另一款出色的软件。CrewAI 是一款用于协调角色扮演、自主 AI 代理的框架。通过促进协作智能，CrewAI 使代理能够无缝协作，解决复杂的任务。

但除了文档不错、框架简单之外，CrewAI 也有自己的问题。

先来看优点：

支持 Ollama；
支持 LangChain 工具调用；
支持自定义工具调用；
支持人工输入。

坏的一面：

工具调用仍然无法起效；
人工输入有时无法触发；
一致性差、无限循环；
Bug 频出；
需要编写的提示词太多。

可供选择的聊天机制

这里提供“按序”和“分层”两种选项。按序允许大模型按照我们指定的顺序完成任务；而分层则是创建一个幽灵 agent，由该 agent 自动决定应该根据描述触发哪个 agent。

分层设计其实想法挺好，可问题是它在寻找协作 agent 的过程中老是出错，会让人快速失去耐心。

这套框架提供三种使用模式：

第一，你已经拥有 agent，则可使用以下提示词将其绑定：

角色：该 agent 的职能定位
目标：该 agent 在团队中需要做什么
背景故事：该 agent 的来历……

在这里插入图片描述

第二是在提示词中描述任务：

描述：应该执行什么任务
预期输出：该任务的预期输出

在这里插入图片描述

最后是工具：可以将工具绑定至 agent 以实现功能。但出于某种考虑，此框架也支持将工具绑定至任务……但我觉得好像没什么意义。

在这里插入图片描述

我喜欢使用 @tool 装饰符。这里只需传递一条工具描述字符串，大模型就能知道是否需要使用。

总而言之，这个过程需要编写大量提示词，很容易把人搞得晕头转向。

比如说这条提示词属于任务还是 agent？这个工具是属于 agent 甲还是 agent 乙？或者说要不要把工具绑定至任务本身？问题很多，答案却非常有限，因为 CrewAI 的说明文档很不完备！

实验小结

如果大家想要各 agent 之间能相互交流，那 CrewAI 确实是个简单的框架。它速度快、设计简洁，唯一的问题就是需要编写大量提示词。但它也没办法实现工具调用，所以我们的实验目标仍然没能解决。

另外，CrewAI 的一致性相当差，我们经常会看到 agent 陷入无限循环。

相信很多朋友都注意到，最近 YouTube 上出现了很多看似热门、但实际上没什么帮助的视频。不少 YouTube 用户都发布了关于 agent 框架的视频，浅浅讨论一下 AI 趋势和如何制作糟糕的 RAG 系统。之所以帮助不大，就是因为现在我们还无法调用本地工具，有限的选项全都集中在 ChatGPT、Grok 或者 Claude 身上。

总结

一无所获！

老实说，现在我们真的需要一种更好的方法，来以较低的成本把大模型整合到自己的应用程序当中。调用工具在特定场景下可行，但仍需要更简单的架构，而且最好能脱离 OpenAI 的复杂格式。

毕竟对于 Phi 这样只能输出文本的小模型，如果无法与我们的应用程序相集成，那它跑在移动设备上还有什么意义呢？

附试验配置：

32 GB 显存的 RTX4090；

使用以下大模型进行测试：