Modelos de Linguagem Grandes (LLMs) não acessam dados em tempo real nem sistemas externos. O Function Calling permite que os modelos chamem ferramentas externas, como APIs, bancos de dados e funções definidas pelo usuário. Isso possibilita ao modelo recuperar informações ou executar ações além de suas capacidades nativas.
Como funciona
O Function Calling opera por meio de uma interação em várias etapas entre sua aplicação e o LLM:
- Faça a primeira chamada ao modelo A aplicação envia a pergunta do usuário e uma lista de ferramentas disponíveis para o LLM.
-
Receba instruções de chamada de ferramenta do modelo
Se o modelo decidir chamar uma ferramenta externa, ele retornará uma instrução JSON especificando o nome da função e os parâmetros de entrada.
Caso o modelo decida não chamar uma ferramenta, ele retornará uma resposta em linguagem natural.
- Execute a ferramenta na aplicação A aplicação executa a ferramenta especificada e obtém a saída.
- Faça a segunda chamada ao modelo Adicione a saída da ferramenta ao array de mensagens e chame o modelo novamente.
- Receba a resposta final do modelo O modelo combina a saída da ferramenta com a pergunta do usuário para gerar uma resposta em linguagem natural.
Modelos suportados
- Qwen
- DeepSeek
- GLM
- Kimi
- MiniMax
-
Modelos de geração de texto
- Qwen-Max: séries Qwen3.8-Max, Qwen3.7-Max, Qwen3.6-Max, Qwen3-Max e Qwen-Max
- Qwen-Plus: séries Qwen3.7-Plus, Qwen3.6-Plus, Qwen3.5-Plus e Qwen-Plus.
- Qwen-Flash: séries Qwen3.7-Flash, Qwen3.6-Flash, Qwen3.5-Flash e Qwen-Flash
- Qwen-Coder: séries Qwen3-Coder, Qwen2.5-Coder e Qwen-Coder
- Qwen-Turbo: série Qwen-Turbo
- Série open source Qwen3.6
- Série open source Qwen3.5
- Série open source Qwen3
- Série open source Qwen2.5
- Série open source Qwen3.8
-
Modelos multimodais
- Qwen-VL: séries Qwen3-VL-Plus e Qwen3-VL-Flash
- Qwen-Omni: séries Qwen3.5-Omni-Plus, Qwen3.5-Omni-Flash e Qwen3-Omni-Flash
- Qwen-Omni-Realtime: séries Qwen3.5-Omni-Plus-Realtime e Qwen3.5-Omni-Flash-Realtime
- Série open source Qwen3-VL
-
Modelos de chat por voz
- Qwen-Audio-Realtime: séries Qwen-Audio-3.0-Realtime-Plus e Qwen-Audio-3.0-Realtime-Flash
Primeiros passos
Antes de começar, obtain an API key e configure it as an environment variable. Se você utilizar o OpenAI SDK ou o DashScope SDK, também será necessário install the SDK.
O exemplo a seguir demonstra o fluxo completo de Function Calling para um cenário de consulta meteorológica.
- Compatível com OpenAI
- DashScope
Como usar
O Function Calling oferece duas formas de transmitir informações sobre ferramentas:
- Método 1: Transmitir informações pelo parâmetro tools (recomendado) Para mais detalhes, consulte How to use. Siga as etapas para definir ferramentas, criar um array messages, executar um Function Calling, rodar a função da ferramenta e permitir que o LLM resuma a saída dessa função.
-
Método 2: Transmitir informações por meio de uma System Message
Transmitir informações pelo parâmetro
toolsgera os melhores resultados, pois o servidor se adapta automaticamente ao modelo de prompt ideal. Caso utilize um modelo Qwen e prefira não usar o parâmetrotools, consulte Pass tool information through a System Message.
tools.
Considere um cenário de negócios que recebe dois tipos de perguntas: consultas sobre o clima e consultas sobre a hora.
1. Definir ferramentas
As ferramentas conectam os LLMs a serviços externos. Portanto, é necessário defini-las primeiro.
1.1. Criar funções de ferramenta
Crie duas funções de ferramenta: uma para consulta de clima e outra para consulta de hora.
-
Ferramenta de consulta de clima
Esta ferramenta recebe o parâmetro
arguments. O formato deargumentsé{"location": "queried location"}. A saída da ferramenta é uma string no formato:"{location} today is {weather}".Para fins de demonstração, a ferramenta de consulta de clima definida aqui não realiza uma consulta real. Ela seleciona aleatoriamente entre ensolarado, nublado ou chuvoso. Em um cenário real de negócios, substitua este código por uma ferramenta como Amap Weather .
-
Ferramenta de consulta de hora
A ferramenta de consulta de hora não exige parâmetros de entrada. Sua saída é uma string no formato:
"Current time: {queried time}.".Se estiver usando Node.js, execute
npm install date-fnspara instalar o pacote date-fns e obter a hora atual.
1.2. Criar o array tools
Antes de escolher uma ferramenta, é preciso compreender sua função, cenários de uso e parâmetros de entrada. O mesmo vale para os LLMs. O modelo seleciona a ferramenta adequada com base nessas informações. Forneça os dados da ferramenta no seguinte formato JSON.
| Para a ferramenta de consulta de clima, o formato das informações de descrição é o seguinte: |
tools) no seu código. Esse array inclui o nome da função, a descrição e a definição de parâmetros para cada ferramenta. O array será transmitido como parâmetro nas requisições subsequentes.
2. Criar o array messages
O Function Calling transmite instruções e contexto ao LLM por meio do array messages. Antes de fazer uma chamada, o array messages deve conter uma System Message e uma User Message.
System Message
Embora a função e os cenários de uso das ferramentas já tenham sido descritos quando você created the tools array, reforçar no System Message o momento exato de chamar cada ferramenta geralmente melhora a precisão da invocação. Para o cenário atual, defina o System Prompt como:
User Message
A User Message serve para transmitir a pergunta do usuário. Supondo que o usuário pergunte "Weather in Shanghai", o array messages neste momento será:
Como as ferramentas disponíveis incluem consultas de clima e de hora, também é possível perguntar a hora atual.
3. Fazer um Function Calling
Transmita os arrays toolsemessages criados ao LLM para realizar um Function Calling. O LLM determina se deve chamar uma ferramenta. Em caso afirmativo, ele retorna o nome da função da ferramenta e seus parâmetros.
Para verificar os modelos suportados, consulte Supported models .
"get_current_weather" e o parâmetro de entrada da função como "{\"location\": \"Shanghai\"}".
content. Ao enviar "Hello", o parâmetro tool_calls fica vazio e o formato do objeto retornado é:
Se o parâmetrotool_callsestiver vazio, seu programa pode retornar diretamente ocontentsem executar as etapas seguintes.
Para garantir que o LLM selecione uma ferramenta específica sempre que você fizer um Function Calling, consulte Forced tool calling .
4. Executar a função da ferramenta
Executar a função da ferramenta transforma a decisão do modelo em uma operação real.
A execução da função da ferramenta ocorre no seu ambiente de computação, e não no LLM.O LLM apenas gera uma string. Antes de rodar a função da ferramenta, analise separadamente o nome da função e seus parâmetros de entrada.
-
Função da ferramenta
Crie um mapeamento
function_mapperdo nome da função da ferramenta para a entidade da função da ferramenta, a fim de vincular a string retornada à entidade correspondente. - Parâmetros de entrada Os parâmetros de entrada retornados pelo Function Calling são uma string JSON. Utilize uma ferramenta para convertê-la em um objeto JSON e extrair as informações dos parâmetros.
Em cenários reais de negócios, muitas ferramentas executam ações específicas (como enviar e-mails ou fazer upload de arquivos) em vez de consultar dados, e não geram uma string de saída. Recomendamos adicionar mensagens de status (como "E-mail enviado com sucesso" ou "Falha na operação") para essas ferramentas, ajudando o LLM a compreender o estado da execução.
5. Permitir que o LLM resuma a saída da função da ferramenta
O formato de saída da função da ferramenta tende a ser rígido. Retorná-lo diretamente ao usuário pode soar robótico. Envie a saída da ferramenta para o contexto do modelo e chame-o novamente para gerar uma resposta em linguagem natural.
-
Adicionar uma Assistant Message
Depois que você make a Function Calling, obtém uma Assistant Message através de
completion.choices[0].message. Primeiro, adicione-a ao arraymessages. -
Adicionar uma Tool Message
Inclua a saída da ferramenta no array
messagesno formato{"role": "tool", "content": "tool output", "tool_call_id": completion.choices[0].message.tool_calls[0].id}.- Certifique-se de que a saída da ferramenta esteja em formato de string.
- O
tool_call_idé um identificador único gerado pelo sistema para cada solicitação de chamada de ferramenta. O modelo pode solicitar a chamada de várias ferramentas simultaneamente. Ao devolver múltiplos resultados ao modelo, otool_call_idgarante que a saída de cada ferramenta corresponda corretamente à sua intenção de chamada.
messages fica assim:
messages, execute o código abaixo.
content: "The weather in Shanghai today is cloudy. If you have any other questions, feel free to ask."
Uso avançado
Especificar o método de chamada de ferramenta
Chamada paralela de ferramentas
Uma consulta de clima para uma única cidade exige apenas uma chamada de ferramenta. Porém, se uma pergunta demandar múltiplas chamadas — como "Como está o tempo em Beijing e Shanghai?" ou "Qual o clima em Hangzhou e que horas são agora?" —, após você make a Function Calling, apenas uma informação de chamada de ferramenta será retornada. Por exemplo, ao perguntar "How's the weather like in Beijing and Shanghai?":
parallel_tool_calls como true quando você make a Function Calling.
A chamada paralela de ferramentas é adequada para tarefas sem dependências entre si. Se houver dependências (por exemplo, a entrada da ferramenta A depende da saída da ferramenta B), consulte Getting started para implementar chamadas seriais de ferramentas (uma por vez) usando um loop
while.tool_calls no objeto retornado passa a conter as informações de parâmetros de entrada tanto para Beijing quanto para Shanghai:
Chamada forçada de ferramenta
Os LLMs geram conteúdo com certo grau de incerteza e podem escolher a ferramenta errada. Para forçar o uso ou a desativação de uma ferramenta específica para determinado tipo de pergunta, modifique o parâmetro tool_choice. O valor padrão de tool_choice é "auto", o que significa que o LLM decide autonomamente como realizar a chamada de ferramenta.
Quando o LLM resumir a saída da função da ferramenta, remova o parâmetro tool_choice . Caso contrário, a API continuará retornando informações de chamada de ferramenta.
-
Forçar o uso de uma ferramenta específica
Se desejar que o Function Calling invoque obrigatoriamente uma ferramenta específica para certo tipo de pergunta, defina o parâmetro
tool_choicecomo{"type": "function", "function": {"name": "the_function_to_call"}}. Dessa forma, o LLM não participará da seleção da ferramenta e apenas emitirá as informações de parâmetros de entrada. Supondo que o cenário atual envolva apenas perguntas sobre clima, altere o código defunction_callingpara:
get_current_weather.
Antes de adotar essa estratégia, certifique-se de que a pergunta tenha relação com a ferramenta selecionada. Do contrário, resultados inesperados podem ocorrer.
tool_calls no objeto retornado não esteja vazio), defina o parâmetro tool_choice como "required". Assim, o Function Calling sempre retornará informações de ferramenta e parâmetros de entrada.
Considerando que todas as perguntas do cenário atual requeiram uma chamada de ferramenta, modifique o código de function_calling para:
tool_calls no objeto retornado nunca estará vazio.
Antes de adotar essa estratégia, certifique-se de que a pergunta tenha relação com as ferramentas disponíveis. Do contrário, resultados inesperados podem ocorrer.
-
Forçar a não utilização de ferramentas
Caso precise que o Function Calling jamais realize uma chamada de ferramenta (fazendo com que o objeto retornado contenha apenas conteúdo de resposta em
contente o parâmetrotool_callsvazio), defina o parâmetrotool_choicecomo"none"ou simplesmente não envie o parâmetrotools. O parâmetrotool_callsretornado pelo Function Calling estará sempre vazio. Supondo que nenhuma pergunta no cenário atual exija uma chamada de ferramenta, altere o código defunction_callingpara:
Conversa de múltiplas rodadas
Um usuário pode perguntar "Weather in Beijing" na primeira rodada e, em seguida, "What about Shanghai?" na segunda. Se o contexto do modelo não contiver as informações da primeira rodada, ele não conseguirá determinar qual ferramenta chamar. Em cenários de conversa de múltiplas rodadas, mantenha o array messages completo após cada interação. Adicione a nova User Message a esse array e siga com make a Function Calling e as etapas subsequentes. A estrutura de messages ficará assim:
Saída em streaming
O uso de saída em streaming permite obter o nome da função da ferramenta e as informações dos parâmetros de entrada em tempo real, melhorando a experiência do usuário. Nesse cenário:
- As informações de parâmetros da chamada de ferramenta são retornadas em fragmentos como um fluxo de dados.
- O nome da função da ferramenta é retornado no primeiro fragmento de dados da resposta do fluxo.
arguments):
tool_calls pelo conteúdo obtido anteriormente.
Chamada de ferramentas com a Responses API
Os exemplos anteriores baseiam-se nas APIs OpenAI Chat Completions e DashScope. Caso você utilize a OpenAI Responses API, o processo geral permanece o mesmo, mas o formato da API apresenta as seguintes diferenças:
| Dimensão | Chat Completions | Responses API |
|---|---|---|
| Formato de definição da ferramenta | ||
| Saída da chamada de ferramenta | response.choices[0].message.tool_calls | Itens em response.output onde type é function_call |
| Retorno do resultado da ferramenta | ||
| Resposta final | response.choices[0].message.content | response.output_text |
Chamada de ferramentas para modelos omni-modal
Modelos omni-modal suportam chamada de ferramentas. Os métodos de chamada para as séries Qwen-Omni e Qwen-Omni-Realtime são diferentes.
Série Qwen-Omni
As séries Qwen3.5-Omni-Plus, Qwen3.5-Omni-Flash e Qwen3-Omni-Flash suportam chamada de ferramentas por meio da API compatível com OpenAI. A etapa de obtenção das informações da ferramenta difere de outros modelos nas seguintes formas:
- Saída em streaming é obrigatória: O Qwen-Omni suporta apenas saída em streaming. Ao obter informações da ferramenta, você também deve definir
stream=True. - Recomenda-se saída apenas em texto: O modelo precisa apenas de informações textuais ao obter dados da ferramenta (nome da função e parâmetros). Para evitar a geração de áudio desnecessário, recomendamos definir ``modalities=["text"]`. Quando a saída inclui modalidades de texto e áudio, é necessário ignorar os fragmentos de dados de áudio durante a obtenção das informações da ferramenta.
Para mais informações sobre o Qwen-Omni, consulte Non-real-time (Qwen-Omni) .
arguments), consulte Streaming output.
Série Qwen-Omni-Realtime
As séries Qwen3.5-Omni-Plus-Realtime e Qwen3.5-Omni-Flash-Realtime oferecem suporte a chamadas de ferramentas e são ideais para cenários de conversação por voz. Você pode invocá-las por meio do DashScope SDK ou do protocolo WebSocket nativo.
Fluxo de trabalho:
Após estabelecer uma conexão WebSocket, transmita a definição da ferramenta via session.update para iniciar o seguinte fluxo de interação:
Fase 1: Entrada de voz e chamada de ferramenta
- O usuário faz uma pergunta por voz. O cliente captura o áudio e o envia ao servidor (o que corresponde ao método
append_audio()). Quando o VAD do servidor detecta o fim da fala, ele executa a inferência do modelo e determina que uma ferramenta precisa ser chamada. - O servidor retorna as informações da chamada de ferramenta ao cliente (correspondentes ao evento
response.function_call_arguments.done), incluindo o nome da função (name), os parâmetros de entrada (arguments) e o identificador da chamada (call_id). Veja um exemplo abaixo:
- Com base no nome da função e nos parâmetros de entrada recebidos, execute a ferramenta correspondente localmente no cliente para obter o resultado da execução.
- Envie o resultado da execução da ferramenta de volta ao servidor (por meio do evento
conversation.item.create), informando o identificador da chamada (call_id) e o resultado obtido (output). Confira o exemplo a seguir:
- Em seguida, envie um evento
response.createpara que o servidor gere a resposta final em voz com base no resultado da ferramenta. - Ao receber o áudio e o texto retornados pelo servidor (eventos
response.audio.deltaeresponse.audio_transcript.delta), reproduza a resposta de voz para o usuário.
A série Qwen-Omni-Realtime não oferece suporte aos parâmetrostool_choiceeparallel_tool_calls.
Para obter mais informações sobre o Qwen-Omni-Realtime, consulte Real-time (Qwen-Omni-Realtime) , Client events e Server-side events .
DashScope Python SDK
Chamada de ferramentas para modelos de raciocínio profundo
Modelos de raciocínio profundo executam inferência antes de gerar informações de chamada de ferramenta, o que aumenta a interpretabilidade e a confiabilidade das decisões.
- Processo de raciocínio O modelo analisa a intenção do usuário, identifica as ferramentas necessárias, verifica a validade dos parâmetros e planeja a estratégia de chamada passo a passo.
-
Chamada de ferramenta
O modelo gera uma ou mais solicitações de chamada de função em formato estruturado.
Há suporte para chamadas paralelas de ferramentas.
Para obter mais informações sobre modelos de raciocínio para geração de texto, consulte Deep thinking . Para obter mais informações sobre modelos de raciocínio multimodais, consulte Image and video understanding e Non-real-time (Qwen-Omni) .
O parâmetroNo modo de raciocínio (tool_choiceaceita apenas os valores"auto"(valor padrão, no qual o modelo seleciona a ferramenta autonomamente) ou"none"(força o modelo a não selecionar nenhuma ferramenta).
enable_thinking=True), o parâmetro tool_choice não pode ser definido como "required" nem como um objeto (por exemplo, {"type": "function", "function": {...}}). Definir tool_choice com qualquer um desses valores enquanto o modo de raciocínio está ativado faz com que a solicitação falhe e retorne o erro The tool_choice parameter does not support being set to required or object in thinking mode. Não use tool_choice="required" como forma de garantir que tool_calls seja não vazio no modo de raciocínio. Se você precisar de chamadas de ferramentas MCP confiáveis com o modo de raciocínio ativado, utilize a Responses API para se conectar ao MCP.
- OpenAI compatible
- DashScope
- Python
- Node.js
- HTTP
Código de exemplo
Resultado retornado
Insira "Weather in the four municipalities" para obter o seguinte resultado:Entrada em produção
Testar a precisão da chamada de ferramentas
- Estabelecer um sistema de avaliação: Construa um conjunto de dados de teste que reflita cenários reais de negócios e defina métricas de avaliação claras, como precisão na seleção de ferramentas, precisão na extração de parâmetros e taxa de sucesso de ponta a ponta.
- Otimizar prompts Com base nos problemas identificados durante os testes, como seleções incorretas de ferramentas ou parâmetros errados, otimize os prompts do sistema, as descrições das ferramentas e as descrições dos parâmetros.
-
Atualizar o modelo
Se o ajuste de prompts não melhorar o desempenho, atualizar para uma versão mais poderosa do modelo, como
qwen3.6-plus, é o método mais direto e eficaz.
Controlar dinamicamente o número de ferramentas
Quando uma aplicação integra dezenas ou até centenas de ferramentas, fornecer todas elas ao modelo pode causar os seguintes problemas:
- Degradação de desempenho: A dificuldade do modelo em selecionar a ferramenta correta dentro de um grande conjunto aumenta drasticamente.
- Custo e latência: Muitas descrições de ferramentas consomem uma grande quantidade de tokens de entrada, o que eleva os custos e torna as respostas mais lentas.
-
Recuperação semântica
Converta as descrições das ferramentas (
description) em vetores usando um modelo de embedding e armazene-os em um banco de dados vetorial. Quando um usuário enviar uma consulta, execute uma busca por similaridade vetorial no vetor da consulta para recuperar as K ferramentas mais relevantes. -
Recuperação híbrida
Este método combina a correspondência aproximada da recuperação semântica com a correspondência exata de palavras-chave tradicionais ou tags de metadados. Para isso, adicione campos
tagsoukeywordsàs ferramentas. Durante a recuperação, executar tanto a busca vetorial quanto a filtragem por palavras-chave melhora significativamente a precisão, especialmente em cenários específicos ou de alta frequência. - Roteador LLM leve Para lógicas de roteamento mais complexas, utilize um modelo menor, mais rápido e menos custoso, como o Qwen-Flash, como modelo roteador. A tarefa desse modelo é gerar uma lista de nomes de ferramentas relevantes com base na consulta do usuário.
- Mantenha o conjunto de candidatos conciso: Independentemente do método utilizado, recomendamos fornecer no máximo 20 ferramentas ao modelo principal. Isso garante um equilíbrio ideal entre carga cognitiva do modelo, custo, latência e precisão.
- Estratégia de filtragem em camadas: Construa uma estratégia de roteamento em funil. Por exemplo, use primeiro correspondências de baixo custo por palavras-chave ou regras para filtrar ferramentas claramente irrelevantes. Em seguida, aplique recuperação semântica nas ferramentas restantes para aumentar a eficiência e a qualidade.
Princípios de segurança de ferramentas
Ao conceder capacidades de execução de ferramentas a um LLM, a segurança é a prioridade máxima. Os princípios fundamentais são o privilégio mínimo e a confirmação humana.
- Princípio do privilégio mínimo: O conjunto de ferramentas fornecido ao modelo deve seguir rigorosamente o princípio do privilégio mínimo. Por padrão, as ferramentas devem ser somente leitura, como ferramentas para consultar o clima ou pesquisar documentos. Evite fornecer quaisquer permissões de "escrita" que envolvam alterações de estado ou operações em recursos.
- Isolar ferramentas perigosas: Não forneça ferramentas perigosas diretamente ao LLM, como ferramentas para executar código arbitrário (
code interpreter), operar o sistema de arquivos (fs.delete), realizar operações de exclusão ou atualização em bancos de dados (db.drop_table) ou processar transações financeiras (payment.transfer). - Envolvimento humano: Um processo de revisão e confirmação manual é obrigatório para todas as operações irreversíveis ou de alto privilégio. O modelo pode gerar uma solicitação de operação, mas o botão final de "executar" deve ser clicado por um usuário humano. Por exemplo, o modelo pode preparar um e-mail, mas o usuário precisa confirmar o envio.
Otimização da experiência do usuário
O processo de chamada de função envolve múltiplas etapas, e um problema em qualquer uma delas pode afetar negativamente a experiência do usuário.
Tratar falhas na execução de ferramentas
Falhas na execução de ferramentas são comuns. Adote as seguintes estratégias:
- Limite de tentativas: Defina um limite razoável de novas tentativas, como 3, para evitar longas esperas do usuário ou desperdício de recursos do sistema devido a falhas contínuas.
- Fornecer respostas alternativas: Se as tentativas se esgotarem ou ocorrer um erro irresolúvel, retorne um aviso claro e amigável ao usuário, como: "Desculpe, não consigo encontrar as informações relevantes no momento. O serviço pode estar ocupado. Tente novamente mais tarde."
Lidar com a latência de processamento
Alta latência reduz a satisfação do usuário. Implemente otimizações tanto no frontend quanto no backend.
- Definir timeout: Configure um timeout independente e razoável para cada etapa do processo de chamada de função. Se ocorrer um timeout, interrompa imediatamente a operação e forneça feedback ao usuário.
- Oferecer feedback instantâneo: Quando uma chamada de função iniciar, exiba um aviso na interface, como "Consultando o clima para você..." ou "Buscando informações relevantes...". Isso dá ao usuário feedback em tempo real sobre o progresso.
Faturamento
Além dos tokens no array messages, as descrições de ferramentas também são cobradas como tokens de entrada.
Passar informações de ferramentas via System Message
Passar informações de ferramentas via System Message
Recomendamos passar as informações das ferramentas para o modelo de linguagem grande (LLM) usando o parâmetro
tools, conforme descrito na seção How to use. Para passar as informações das ferramentas através de uma System Message, utilize o modelo de prompt no código abaixo para obter o melhor desempenho do modelo:- OpenAI compatible
- DashScope
- Python
- Node.js
Código de exemplo
Após executar o código anterior, use um analisador XML para extrair as informações da chamada de ferramenta, incluindo o nome da função e os parâmetros de entrada, entre as tags<tool_call>e</tool_call>.