如何写适配多个llm的提示词

本文采用的提示词工程主要有两部分代码组成：提示词注入和工具结果回传。提示词注入用于将工具信息以及使用工具的提示词添加到系统提示中。工具结果回传则是解析tool calling的输出，并将工具返回的内容再次嵌入LLM。[heading2]1、提示词注入阶段[content]INSTRUCTION为最后注入到系统提示中的字符串，他又包含了TOOL_EAXMPLE、tools_instructions、REUTRN_FORMAT三个部分。TOOL_EAXMPLE用于提示LLM如何理解tool以及如何使用tool。在编写TOOL_EAXMPLE时，请注意用一些无关紧要的工具作为示例，例如本文使用的将数字加一和数字减一的工具，从而避免LLM混淆真正可以使用的工具与示例工具。tools_instructions是由目前通用的工具字典转换成LLM可读的工具列表。实际使用LLM时，可以通过输入不同的工具来动态调整tools_instructions，让LLM得知目前可用的工具有哪些以及如何使用。REUTRN_FORMAT定义了调用API的格式。[heading2]2、工具结果回传阶段[content]利用正则表达式抓取输出中的"tool"和"parameters"参数。对于interpreter工具，使用了另一种正则表达式来提取LLM输出的代码，提高LLM使用interpreter工具的成功率。本文使用代码如下：通过识别LLM返回的调用工具的字典，提取出对应的值，再传入相应的工具函数，最后将工具返回的结果以observation的角色返回给LLM。对于一些不接受observation、tool、function角色的LLM接口，可以改为回传给user角色，例如：通过以上提示词工程，可以避免微调，让完全没有tool calling能力的LLM获得稳定的tool calling能力。

大家好，我是一个开源项目作者ailm。目前，绝大多数小型本地开源大语言模型以及部分商用大模型接口都不支持稳定的tool calling功能。而现有的解决方案是微调LLM，这导致大量的时间和算力被浪费。本文提出一种仅使用提示词工程和一些精巧的代码设计，即可让LLM获得稳定的tool calling能力。本文使用多个不具备tool calling能力的LLM作为测试模型，在多个工具调用任务上进行实验，成功率为100%。本文所有工作是基于comfyui开发，适合完全没有代码基础的小伙伴们复现并且按自己的想法修改我的工作。

当用户在【引导】节点输入“开始游戏”之后，Coze会执行如下流程（图5）：图5用户输入“开始游戏”触发的执行流程我们先来看一下第一次LLM调用的输入（图5）：忽略其他参数，我们关注messages列表。列表中只有一条消息，它的内容是：这是一段系统提示词，这就是Coze用来处理多Agent跳转的关键。提示词有5个部分：INSTRUCTION，是一段指令，包含角色设定和简要的任务描述。注意，这段提示词给LLM描述的任务是“根据用户需求和最新的聊天记录，从以下Agent列表中选择最合适的Agent”。AGENTS/BOTS LIST，是候选的Agent列表。agent_id是一个序号，供LLM选择。agent_name就是你给Agent节点设置的名字。condition就是你在Agent节点设置的适用场景（Scenarios）（图6）。USER REQUEST，就是你在【切换节点设置】界面设置的自定义提示词（见图7）。至于我为什么在这里写了一段有些奇怪的提示词，我下面马上会解释。CONSTRAINT，是一些限制条件。这里还告诉LLM，在没有合适的Agent时，要输出0，表示不跳转。PREVIOUS CONVERSATION HISTORY，是之前的对话历史。Coze提供了一个选项，可以控制这个传给跳转模型的对话记录的长度（见图7），但是这个选项并没有效果（应该是Bug）。图6适用场景图7自定义提示词前面说Coze的多Agent跳转总是不可靠，我们从这段短短的提示词中就可以找到几个导致不稳定的因素：