AI News HubLIVE
站內改寫6 分鐘閱讀

待翻譯:What is Tool Calling?

AI 服務暫時不可用,以下為來源摘要,待恢復後補全翻譯:Tool calling is the ability of an AI model to interact with external tools, APIs,...

AI 服務暫時不可用,以下為來源正文,待恢復後補全翻譯。

What is Tool Calling? | Databricks Blog Skip to main content Tool calling is the mechanism that allows AI models to interact with external tools, APIs, and systems, transforming basic chatbots into capable AI agents that can take real-world action. The process follows a structured loop: the model recognizes when a tool is needed, selects the right one, builds a request, processes the response, and delivers a result to the user. Databricks Agent Bricks provides a governed platform for building tool-calling agents grounded in enterprise data, with native support for the Model Context Protocol (MCP) and Unity Catalog governance. Tool calling is the ability of an AI model to interact with external tools, APIs, or systems to perform actions and retrieve information beyond what the model can do on its own. Rather than relying solely on the knowledge baked into its training data, a model with tool-calling capabilities can recognize when a user's request requires outside help, select the appropriate tool, and structure a request to get the job done. This is the capability that separates a static chatbot from a functional AI agent. Without tool calling, a large language model can only generate text based on patterns it learned during training. With it, the same model can check live inventory, query a database, send an email, execute code, or call a third-party API. Tool calling gives AI models hands. Why tool calling matters for AI agents AI agents are systems that can perceive their environment, make decisions, and take action to accomplish goals. Tool calling is what makes the "take action" part possible. An agent that cannot call tools is limited to conversation. An agent that can call tools becomes a worker. The shift from generative to agentic AI Generative AI produces text, images, and code. Agentic AI goes further by planning multi-step workflows, using tools to execute each step, and adapting based on results. Tool calling is the bridge between these two paradigms. It is the mechanism through which an AI model stops describing what could be done and starts doing it. Why enterprises are paying attention The business case is straightforward. According to Gartner, 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025. That growth depends on reliable tool calling. If an agent cannot dependably query a CRM, update a record, or trigger a downstream workflow, it cannot deliver production-grade value. Tool calling also changes how teams think about automation. Instead of building rigid, rule-based integrations for every possible workflow, organizations can deploy AI agents that dynamically select and invoke the right tools based on context. This makes systems more flexible and reduces the engineering overhead of maintaining brittle point-to-point connections. How does AI tool calling work? Tool calling follows a structured loop. The model does not execute tools directly. Instead, it generates structured requests that an application layer fulfills, then incorporates the results into its response. Here is how the process works step by step. Step 1. Recognizing when a tool is needed The process begins when a user sends a request that the model cannot answer from its training data alone. If a user asks "What is the capital of France?" the model answers directly. If a user asks "What were our Q2 sales numbers?" the model recognizes it needs to query an external data source. This recognition depends on the model's training. Models that support tool calling have been fine-tuned to identify when a query falls outside their knowledge boundary and when an available tool could help. The model evaluates the user's intent against the list of tools it has been given access to. Step 2. Choosing the right tool Once the model determines that a tool is needed, it selects the most appropriate one from its available set. Each tool is described to the model using a schema that includes the tool's name, what it does, and what parameters it accepts. The model matches the user's request against these descriptions to pick the right tool. For example, if an agent has access to both a weather API and a database query tool, and the user asks about tomorrow's forecast, the model selects the weather API. If the user asks about last month's revenue, it selects the database query tool. Step 3. Building and sending the request After selecting a tool, the model generates a structured output, typically in JSON, that specifies which tool to call and what arguments to pass. The model does not execute this call itself. It produces the request, and the application layer handles execution. Step 4. Receiving and processing the response The external tool executes the request and returns a result. This could be a data payload from a database, a confirmation that an action was completed, an error message, or any other structured response. The application layer passes this result back to the model as context for generating its final answer. Step 5. Delivering the answer or executing an action With the tool's response in hand, the model synthesizes a natural-language answer for the user. If the user asked for Q2 sales numbers, the model might respond: "North American Q2 2026 sales totaled $14.3 million, up 12% from Q1." The model combines the raw data from the tool with its language capabilities to produce a clear, contextual response. In some cases, the result is not a conversational answer but an executed action, such as a sent email, an updated database record, or a triggered workflow. The model confirms the action to the user. Step 6. Iterating and refining the result Tool calling is not always a single pass. Complex requests may require multiple tool calls in sequence. An agent asked to "prepare a summary of last quarter's performance and email it to the leadership team" might first query a database for performance metrics, then call a code execution tool to generate a chart, then invoke an email API to send the summary. At each step, the model evaluates whether it has enough information to proceed or whether additional tool calls are needed. This iterative loop is what makes agentic AI systems capable of handling multi-step workflows. Common types of tool calling Tool calling is not a single pattern. Different use cases require different types of tools, each serving a distinct purpose in an agent's workflow. Information retrieval and search The most common type of tool calling involves fetching data the model does not have. This includes querying databases, searching document repositories, calling search APIs, or retrieving real-time information like stock prices, weather data, or news. Retrieval-augmented generation (RAG) is a specific form of this pattern where the model queries a knowledge base to ground its responses in verified data. Code execution Some tasks require the model to write and run code rather than simply generate text. Code execution tools allow agents to perform calculations, transform data, generate visualizations, or run analytical scripts. An AI coding agent might write a Python function, execute it in a sandboxed environment, and return the output to the user. Process automation Tool calling enables agents to trigger actions in external systems. This includes sending emails, creating tickets in project management tools, updating CRM records, initiating approval workflows, or posting messages to communication platforms. These tools turn agents into participants in business processes rather than passive observers. Smart devices and IoT monitoring In industrial and operational contexts, tool calling connects AI agents to physical systems. An agent might query sensor data from manufacturing equipment, adjust thermostat settings in a smart building, or monitor fleet vehicle telemetry. These integrations extend AI capabilities from the digital world into the physical one. Read now Tool calling vs. function calling These two terms are closely related and often used interchangeably, but there is a meaningful distinction worth understanding. Tool callingFunction calling ScopeBroad capability that includes APIs, databases, code execution, external services, and any callable resourceSpecific mechanism where the model generates arguments for a predefined function ContextUsed in agentic AI frameworks where models orchestrate multi-step workflows across multiple toolsOriginally introduced by OpenAI in 2023 to describe structured output generation for function invocation RelationshipThe umbrella conceptA subset of tool calling Industry usageThe term the industry has converged on as AI agents have become more capableStill used in some API documentation and legacy contexts Function calling is how tool calling started. When OpenAI first introduced the capability, it was framed as a way for models to generate structured arguments for developer-defined functions. As the ecosystem matured and agents began orchestrating more complex workflows involving multiple external systems, the broader term "tool calling" became standard. In practice, if you are reading documentation that says "function calling," it is describing the same underlying mechanism. Databricks supports both terms in its documentation and platform capabilities. For a deeper look at how function calling is evaluated in practice, see the Databricks function calling benchmarks. Real-world examples of AI tool calling in action Tool calling is already operating in production across industries. Here are concrete examples of how organizations use it. Customer support agents A support agent receives a customer message asking about the status of an order. The agent calls a tool to query the order management system, retrieves the tracking information, and responds with a delivery estimate. If the customer wants to change the shipping address, the agent calls an update tool to modify the record. Every tool interaction is governed and auditable through platforms like Unity Catalog, which enforces access controls and maintains lineage from agent actions to source data. Data analysis workflows An analyst asks an AI agent to compare this quarter's revenue across regions. The agent calls a SQL query tool to pull data from the lakehouse, calls a code execution tool to calculate growth rates and generate a chart, and returns a formatted summary. What would have taken an analyst 30 minutes of manual querying and spreadsheet work happens in a single conversational exchange. IT operations and monitoring An operations team deploys an agent that monitors infrastructure health. When a server's CPU usage exceeds a threshold, the agent calls a diagnostics tool to gather system logs, calls an alerting tool to notify the on-call engineer, and calls a remediation tool to scale up resources automatically. The agent handles the first-response workflow without human intervention. Enterprise search and knowledge management An employee asks an internal AI assistant about the company's parental leave policy. The agent calls a retrieval tool to search the HR knowledge base, finds the relevant policy document, and returns a concise answer with a link to the full document. This pattern replaces the common experience of searching through an intranet and reading through multiple pages to find a specific answer. Start building AI agents with tool calling on Databricks Databricks provides a complete platform for building, deploying, and governing tool-calling agents through Agent Bricks. According to Databricks, organizations have already built over 100,000 agents on the platform, processing more than one quadrillion tokens per year. How Databricks supports tool calling Agent Bricks natively supports the Model Context Protocol (MCP), the emerging open standard for tool integration. This gives agents secure access to APIs, databases, and [truncated for AI cost control]