Tool-based interactive language model agent control method, device and equipment
Patent Information
- Application Number
- CN202611097237.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-22
- Publication Date
- 2026-10-27
AI Technical Summary
[0004]本说明书实施方式旨在至少在一定程度上解决相关技术中的技术问题之一。为此，本说明书实施方式提出一种基于工具的交互式语言模型代理控制方法、装置及设备。
Smart Images
Figure CN122985262A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of artificial intelligence agent technology, and in particular to a tool-based interactive language model agent control method, apparatus, and device. Background Technology
[0002] Breakthrough progress has been made in artificial intelligence technology centered on large language models (LLMs). However, LLMs are essentially closed systems, whose knowledge scope is limited to the cutoff point of the training data, and they do not have the ability to interact with the external environment in real time or perform specific operations.
[0003] In related technologies, the system initiates an execution loop. In each iteration, the user task, historical interaction records, and a list of available tools are input into the LLM, and the next action is determined by parsing the LLM's output. However, relying on the implicit rule of "terminating if no tool is invoked," the agent returns incomplete or even incorrect intermediate results to the user, causing the entire task execution to fail, making it difficult to guarantee the system's reliability and task completion rate. Summary of the Invention
[0004] The embodiments described in this specification aim to at least partially address one of the technical problems in the related art. To this end, the embodiments of this specification propose a tool-based interactive language model agent control method, apparatus, and device.
[0005] This specification provides a tool-based interactive language model agent control method, the method comprising: By invoking the large language model invocation module, a tool invocation request is generated using system prompts, context information, and a tool definition list. The tool call request is parsed by calling the tool scheduler module to determine the target tool to be called; By invoking the tool scheduler module to execute the operation logic corresponding to the target tool, closed-loop control of the agent's output response and execution loop is achieved.
[0006] In one implementation, the tool definition list includes at least one external business tool definition for executing business logic, and a core control tool definition for controlling the agent's own interactive state; wherein the core control tool definition includes a user response tool definition and a loop termination tool definition.
[0007] In one implementation, the step of generating a tool invocation request by invoking a large language model invocation module, utilizing system prompts, context information, and a tool definition list, includes: Generate an initial model request using system prompts, contextual information, and a list of tool definitions; The initial model request is constrained according to the forced tool invocation parameters, and the tool invocation request is generated.
[0008] In one implementation, the step of parsing the tool invocation request and determining the target tool to be invoked by invoking the tool scheduler module includes: Based on the tool call request, the tool name field is extracted; The target tool to be invoked is determined based on the tool name field.
[0009] In one implementation, the target tool includes a user response tool, and the step of executing the operation logic corresponding to the target tool by calling the tool scheduler module to achieve closed-loop control of the agent's output response and execution loop includes: Since the target tool is a user response tool, data is extracted based on the tool's call request to obtain the push response data; The data to be pushed and replied is output using a preset output channel.
[0010] In one implementation, the target tool includes a loop termination tool. The step of executing the operation logic corresponding to the target tool by calling the tool scheduler module to achieve closed-loop control of the agent's output response and execution loop includes: In response to the target tool being the loop termination tool, a loop termination command is generated; In response to the loop termination instruction, the current execution loop ends.
[0011] In one implementation, the target tool includes an external business tool, and the step of executing the operation logic corresponding to the target tool by calling the tool scheduler module to achieve closed-loop control of the agent's output response and execution loop includes: In response to the target tool being the external business tool, the tool call request is forwarded to the external tool execution module through the tool scheduler module; The business execution result is obtained by calling the target tool through the external tool execution module.
[0012] This specification provides a tool-based interactive language model agent control device, the device comprising: The tool call request generation module is used to generate tool call requests by calling a large language model call module, using system prompts, context information, and a list of tool definitions. The tool call request parsing module is used to parse the tool call request by calling the tool scheduler module to determine the target tool to be called; The target tool execution module is used to execute the operation logic corresponding to the target tool by calling the tool scheduler module, thereby realizing closed-loop control of the agent's output response and execution loop.
[0013] This specification provides a computer device comprising: a memory, and one or more processors communicatively connected to the memory; the memory stores instructions executable by the one or more processors, the instructions being executed by the one or more processors to cause the one or more processors to perform the steps of the method described in any of the above embodiments.
[0014] This specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the above embodiments.
[0015] This specification provides a computer program product that includes instructions that, when executed by a processor of a computer device, enable the computer device to perform the steps of the method described in any of the above embodiments.
[0016] In the above-described implementation, firstly, a tool invocation request is generated by invoking the large language model invocation module, utilizing system prompts, context information, and a tool definition list. During this process, due to the deep integration of control flow and inference, the system prompts and tool definition list can be dynamically adjusted or re-injected at different execution stages. This ensures that the generation of the tool invocation request itself is precisely controlled by external logic, providing stable and predictable input for subsequent steps. Then, the tool invocation request is parsed by invoking the tool scheduler module to determine the target tool to be invoked. Finally, the operation logic corresponding to the target tool is executed by invoking the tool scheduler module, achieving closed-loop control of the agent's output response and execution loop. Through this mechanism, the tool invocation process no longer relies on the model's own guesswork-based output, but is precisely parsed and executed by the scheduler, making each action traceable and interventionable. This effectively improves the real-time interactivity, behavioral controllability, and system reliability of the large language model tool invocation agent. Attached Figure Description
[0017] Figure 1 A flowchart illustrating the tool-based interactive language model agent control method provided for the embodiments of this specification; Figure 2 A flowchart illustrating the generation tool call request provided in the embodiments of this specification; Figure 3 A flowchart illustrating the process of determining the target tool to be invoked, provided for the implementation of this specification; Figure 4 A flowchart illustrating the output of data to be pushed for response is provided for the implementation of this specification. Figure 5 A flowchart illustrating the termination of the current execution loop, provided for the implementation of this specification; Figure 6 A flowchart illustrating the process of obtaining business execution results provided for the implementation of this specification; Figure 7 A schematic diagram of a tool-based interactive language model agent control device provided for embodiments of this specification; Figure 8 An internal structural diagram of a computer device provided for embodiments of this specification. Detailed Implementation
[0018] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.
[0019] Significant breakthroughs have been achieved in artificial intelligence technology centered on Large Language Models (LLMs). Typical examples include the GPT and Qwen series models, which have demonstrated powerful capabilities in natural language understanding, generation, and logical reasoning. However, LLMs are inherently closed systems; their knowledge scope is limited by the deadline of the training data and they lack the ability to interact with the external environment in real time or perform specific operations.
[0020] To overcome these limitations, research into AI agents has emerged. The core idea is to treat the LLM (Limited Language Model) as a central "brain," endowing it with the ability to invoke a series of predefined tools or functions. These tools can encompass invocations of external application programming interfaces (APIs) (e.g., querying the weather, retrieving web pages), database access, or native code execution. Based on this mechanism, AI agents can break down complex user-provided instructions into several reasoning steps and tool invocation sequences, thereby accomplishing tasks beyond the scope of plain text generation.
[0021] However, existing AI agent solutions based on tool invocation, especially in loop control, still have the following significant shortcomings: Lack of process interaction capabilities: When performing multi-step tasks, AI agents usually operate in a "black box" mode, unable to provide users with real-time progress feedback, nor can they proactively request user decisions or clarify ambiguous information at key nodes, resulting in poor user experience and task transparency.
[0022] Uncertainty in execution flow: The agent's execution flow is highly dependent on the probabilistic results of the LLM output. The model may not follow preset instructions, returning unstructured free text, which may cause unexpected workflow interruptions, or the output format may not meet downstream parsing requirements, affecting system stability.
[0023] Coupling of control logic and business logic: In existing implementation schemes, control logic such as user interaction triggering and task termination determination is often hard-coded and solidified in the program periphery, rather than being autonomously driven by the inference core of LLM.
[0024] In related technologies, a tool-invoking AI agent based on manually defined rules for cyclical control is employed. Specifically, the system initiates an execution loop. In each iteration, the user task, historical interaction records, and a list of available tools are input into the LLM (Linux Virtual Machine), and the next action is determined by parsing the LLM's output. Its core cyclical control logic is determined by a set of externally defined manually defined rules; a typical rule combination is as follows: Tool invocation rules: The program parses the LLM output using string matching or regular expressions. If the output contains a tool invocation instruction that matches a predefined format, the tool is executed, and the execution result is appended to the history before proceeding to the next iteration of the loop.
[0025] Implicit termination rule: If the output of a certain round of LLM does not contain any resolvable tool call instructions, the system assumes that the task has been completed, terminates the loop, and returns the plain text of the output of that round as the final answer to the user.
[0026] Forced termination rule: To prevent infinite loops and control computational costs, the system presets a maximum number of execution rounds (e.g., 10 rounds). Once the number of loops reaches this limit, the loop will be forcibly terminated regardless of whether the task has actually been completed.
[0027] The related technologies have the following inherent defects: First, relying on the implicit rule of "terminating without invoking tools" easily leads to premature task termination. The output of an LLM is inherently probabilistically generated; it may produce transitional, dialogic text or intermediate result summaries midway through task execution, and this text may not contain tool invocation instructions. The implicit termination rule will incorrectly classify such situations as task completion, thus prematurely interrupting the loop. The inevitable result is that the agent returns incomplete or even incorrect intermediate results to the user, causing the entire task to fail, making it difficult to guarantee system reliability and task completion rate.
[0028] Secondly, the reliance on a forced termination rule based on "reaching the maximum number of rounds" leads to semantic ambiguity in the final state. When a loop terminates due to reaching a preset limit, the program cannot distinguish whether the termination point was due to successful task completion or forced interruption due to excessive task complexity. This forced exit mechanism based on external counting deprives the system of its inherent ability to autonomously determine task success or failure, thus preventing it from providing clear status codes (such as success / failure) to upstream applications and hindering the reliable implementation of error handling mechanisms and automated process integration.
[0029] In summary, the crux of the problem with these technologies lies in the fact that their control flow, especially task termination determination and user interaction triggering, is determined by externally heuristic manual rules, which are separate from the core inference of LLM. This separation leads to fragile control logic and ambiguous states, making it difficult to meet the accuracy, reliability, and scalability requirements of practical applications.
[0030] Based on the above analysis, this specification provides a tool-based interactive language model agent control method. First, by invoking the large language model invocation module, a tool invocation request is generated using system prompts, context information, and a tool definition list. During this process, due to the deep integration of control flow and inference, the system prompts and tool definition list can be dynamically adjusted or re-injected at different execution stages. This allows the generation of the tool invocation request itself to be precisely controlled by external logic, providing stable and predictable input for subsequent steps. Then, by invoking the tool scheduler module, the tool invocation request is parsed to determine the target tool to be invoked. Finally, by invoking the tool scheduler module, the operation logic corresponding to the target tool is executed, achieving closed-loop control of the agent's output response and execution loop. Through this mechanism, the tool invocation process no longer relies on the model's own guesswork output, but is precisely parsed and executed by the scheduler, making each action traceable and interventionable. This effectively improves the real-time interactivity, behavioral controllability, and system reliability of the large language model tool invocation agent.
[0031] This specification provides a tool-based interactive language model agent control method. Please refer to [link / reference]. Figure 1 The tool-based interactive language model agent control method may include the following steps: S110. By calling the large language model calling module, a tool calling request is generated using system prompts, context information, and a tool definition list.
[0032] S120. By calling the tool scheduler module, the tool call request is parsed to determine the target tool to be called.
[0033] S130. By calling the tool scheduler module to execute the operation logic corresponding to the target tool, closed-loop control of the agent's output response and execution loop is achieved.
[0034] Specifically, the agent driven by the large language model internally integrates a large language model invocation module and a tool scheduler module. In actual operation, the agent first invokes the large language model invocation module, providing the large language model with pre-defined system prompts, accumulated context information up to the current moment, and a complete tool definition list as input. The system prompts define the agent's behavioral role and response guidelines; the context information includes user input, historical dialogues, and obtained tool execution results; and the tool definition list details the name, function, required parameter names and types, and whether parameters are required for each available tool. Based on these inputs, the large language model infers that a tool is needed to complete the current task or answer the user's question, generating a structured tool invocation request. Subsequently, the agent invokes the tool scheduler module to parse the request, extracting the unique identifier of the target tool and its corresponding invocation parameters from the structured request data, thereby determining the target tool to be executed. Based on the parsing results, the tool scheduler module executes the pre-encapsulated operation logic of the target tool locally or remotely. This operation logic can include calling an internal function, accessing an external application programming interface, querying a database, or executing a script. After execution, the tool scheduler module obtains a structured tool execution result. This result is automatically appended to the context, forming updated context information, and then sent back to the large language model invocation module to start the next round of inference.
[0035] In some implementations, an agent driven by a large language model is configured, acting as an examiner. This agent's overall workflow, decision-making strategies, and interaction logic are defined through pre-designed system prompts. A set of standardized external tool interfaces is configured for this agent to perform specific tasks such as test paper generation, answer retrieval, and content evaluation. Based on the guidance of the system prompts and the collaboration of external tools, this agent can dynamically generate personalized test papers for different candidates, provide progressive guidance during the conversational answering process, analyze and score the submitted answers in real time, and automatically generate a complete exam summary report at the end of the exam. This achieves fully automated and intelligent management of the entire process, from test paper customization and answer interaction to instant evaluation and result feedback.
[0036] In the above implementation, firstly, a tool invocation request is generated by invoking the large language model invocation module, utilizing system prompts, context information, and a tool definition list. During this process, due to the deep integration of control flow and inference, the system prompts and tool definition list can be dynamically adjusted or re-injected at different execution stages. This ensures that the generation of the tool invocation request itself is precisely controlled by external logic, providing stable and predictable input for subsequent steps. Then, the tool invocation request is parsed by invoking the tool scheduler module to determine the target tool to be invoked. Finally, the operation logic corresponding to the target tool is executed by invoking the tool scheduler module, achieving closed-loop control of the agent's output response and execution loop. Through this mechanism, the tool invocation process no longer relies on the model's own guesswork output, but is precisely parsed and executed by the scheduler, making each action traceable and interventionable. This effectively improves the real-time interactivity, behavioral controllability, and system reliability of the large language model tool invocation agent.
[0037] In some implementations, the tool definition list includes at least one external business tool definition for executing business logic, and a core control tool definition for controlling the agent's own interactive state.
[0038] The core control tool definition includes the user response tool definition and the loop termination tool definition.
[0039] In some cases, the agent is configured with a tool module, which is essentially a configuration module that uses a structured format such as JSON Schema to store the definitions of all the tools that can be called by the large language model.
[0040] Specifically, when defining tools, developers obtain the corresponding tool definition by providing the tool name, functional description, and input parameter patterns conforming to the JSON Schema specification, and then store this tool definition in the tool module. When the agent system starts and initializes, the agent will call the tool module, perform initialization operations based on the stored tool definitions, read the structured definitions of all tools one by one, and integrate them into a list, thus generating a tool definition list. This tool definition list must contain at least one external business tool definition for executing specific business logic, such as weather queries, database queries, or calling external APIs. Simultaneously, the list must also contain core control tool definitions for controlling the agent's own interactive state. Core control tool definitions specifically include user response tool definitions and loop termination tool definitions. The user response tool definition specifies the calling interface and parameter patterns when the agent returns natural language to the user, while the loop termination tool definition is invoked by the agent when it determines that the task has been completed and the tool call loop needs to be terminated. It should be noted that during the process of generating the tool definition list during system initialization, user response tool definitions and loop termination tool definitions are forcibly and programmatically injected into the tool definition list, thereby ensuring that the agent always has the basic control capabilities to send responses and actively terminate call loops when interacting with users.
[0041] For example, a user response tool (respond_user) is used to deliver procedural information or a final response to a user. Its definition includes a string parameter `content`. The tool structure specification for the user response tool in the tool definition list can be as follows: { "type": "function", "function": { "name": "respond_user", / / Function name "description": "Sends messages to the user. All content that needs to be displayed to the user must be invoked through this tool." / / Function description "parameters": { "type": "object", "properties": { "content": { "type": "string", "description": "The message to be returned to the user" } }, "required": ["content"] / / Lists the names of the parameters that must be provided when calling this tool. } } } The loop termination tool definition (end_agent_loop) is used to terminate the agent loop when the task is completed or when it is necessary to wait for the next user input. The tool structure description of the loop termination tool in the tool definition list can be as follows: { "type": "function", "function": { "name": "end_agent_loop", "description": "The current session round has ended, awaiting new input from the user. Or the user's task has been completed." "parameters": { "type": "object", "properties": { }, "required": [] } } } In the above implementation, the two core control behaviors are abstracted into structured formal tools: user response tool definition and loop termination tool definition. These are given equal status with business tools and can be proactively planned and invoked by the Large Language Model (LLM) in the inference chain as needed. Simultaneously, a mandatory tool invocation mechanism at the API level ensures that the model must complete user interaction and task termination through these tools during execution. This completely transfers control from external programs to the core of model inference, eliminating dependence on fragile heuristics, giving the system explicit state management, predictable execution paths, and support for procedural human-computer interaction. Furthermore, decoupling control logic from business logic enhances the framework's scalability and stability, providing a reliable foundation for subsequent complex task orchestration.
[0042] In some implementations, please refer to Figure 2 By invoking a large language model invocation module, and utilizing system prompts, contextual information, and a tool definition list, a tool invocation request can be generated, which may include the following steps: S210. Using system prompts, context information, and the tool definition list, generate an initial model request.
[0043] S220. Constrain the initial model request according to the forced tool call parameters and generate a tool call request.
[0044] Specifically, the agent is configured with a large language model invocation module. This module encapsulates the logic for API communication with the large language model. When the agent begins an inference decision, it invokes the large language model invocation module. This module uses pre-defined system prompts, current context information, and a tool definition list provided by the tool definition module to generate an initial model request. When assembling the request body sent to the large language model API, the module, in addition to passing in the message context constructed by the memory management module as the dialogue history and embedding the tool list provided by the tool definition module as the available toolset in the request, must also forcibly set a tool invocation parameter, explicitly assigning the `tool_choice` field in the interface to "required". This parameter is a control function provided by the large language model API. Once set to "required", it forces the language model to return a structured description of at least one tool invocation in this response. The result is limited to a structured object (such as a JSON object) containing tool invocation instructions, fundamentally eliminating the possibility of the model returning unstructured natural language text. By imposing this mandatory tool invocation parameter on the initial model request, the large language model invocation module ultimately generates a structured tool invocation request. This request may include a tool name field to identify the invoked tool, and a parameter field to pass the input required for the invocation.
[0045] In the above implementation, an initial model request is generated using system prompts, context information, and a tool definition list. This initial model request is then constrained by mandatory tool call parameters to generate a tool call request, thus establishing the basis for the tool execution loop. This execution loop is entirely and strictly governed by program code. Its core mechanism lies in the deep integration of formal control tools with the mandatory tool call parameters supported by the large language model API, forming a fully predictable proxy execution framework. Under this framework, each round of response from the large language model is forcibly reduced to structured tool call instructions. This design fundamentally eliminates the uncertainty of execution flow branches and the risk of unexpected early task termination caused by the model returning unstructured or free-form text. It significantly improves the programmatic controllability and reliability of proxy behavior along the execution path, ensuring that each step of the entire loop process strictly follows the preset logic, ultimately achieving determinism and robustness in system-level execution behavior.
[0046] In some implementations, please refer to Figure 3The process of parsing tool invocation requests and determining the target tool to be invoked by calling the tool scheduler module can include the following steps: S310. Extract the tool name field based on the tool call request.
[0047] S320. Determine the target tool to be invoked based on the tool name field.
[0048] Specifically, the agent is equipped with a tool scheduler module. The tool scheduler module is the nerve center of the agent system, and its core responsibility is to parse and execute tool invocation instructions returned by the large language model. The internal implementation of this tool scheduler module uses a conditional branching structure to complete tool routing. When the large language model invocation module receives a tool invocation request, the agent immediately invokes the tool scheduler module and passes the tool invocation request to it for processing. Upon receiving the tool invocation request, the tool scheduler module first parses the request, extracting the tool name field that identifies the invoked tool. Then, the tool scheduler module uses the extracted tool name field as input, traversing multiple pre-set conditional branches, matching the tool name field with the tool name identifier bound to each branch. These conditional branches correspond to various specific tools integrated by the agent, and each branch is associated with a unique tool name identifier. When the tool name field matches the identifier of a branch, that conditional branch is hit, and the tool scheduler module determines the tool pointed to by that branch as the target tool to be invoked in this round.
[0049] In the above implementation, the tool name field is extracted based on the tool call request, and the target tool to be called is determined based on the tool name field, providing a data foundation for the subsequent execution of the tool.
[0050] In some implementations, please refer to Figure 4 The target tool includes a user response tool. By calling the tool scheduler module to execute the corresponding operation logic of the target tool, a closed-loop control of the agent's output response and execution cycle can be achieved. This can include the following steps: S410, responding to the target tool as a user response tool, extracts data based on the tool call request to obtain the data to be pushed as a reply.
[0051] S420: Output the data to be pushed and replied to using the preset output channel.
[0052] Specifically, the agent is equipped with a tool scheduler module. When the agent determines that the target tool to be invoked is a user response tool, in response to the target tool being a user response tool, the agent invokes the tool scheduler module to parse the tool invocation request and perform data extraction operations to obtain the response data to be pushed. Subsequently, the tool scheduler module invokes a pre-configured message output channel in the system, i.e., the preset output channel, to push the extracted response data to be pushed out through this channel, thereby completing the user-facing information response process.
[0053] It's important to note that the parsing rules used to extract the response data from the tool's call request, as well as the preset output channel used to push this data to the user interface, are all built into the definition and configuration of the user response tool itself. In other words, as a specific type of tool, the user response tool pre-encapsulates parsing rules for its call request parameters. These rules define how to extract the content entity to be replied to from the structured data of the request. Simultaneously, the user response tool is bound to a preset output channel that is pre-established and maintained in the system. When the agent identifies the target tool as the user response tool and calls the tool scheduler module, the tool scheduler module actually extracts the data according to the parsing rules bound to the user response tool and pushes the response data out through the preset output channel bound to the tool. Therefore, the agent does not need to specify the parsing method or output channel during the call process; everything is uniformly handled and executed by the user response tool itself.
[0054] For example, in response to the target tool being a user response tool, the tool call request is parsed, the "content" parameter is located, and its value is extracted. This "content" parameter is the key field used to carry the content of the message to be replied to, thereby obtaining the reply data to be pushed. The preset output channel can be a yield statement in the generator on which the intelligent agent's execution flow relies. By executing this yield statement, the tool scheduler module passes the reply data to be pushed out as the generator's output to the external caller. The external caller can obtain the data of each push in real time by iterating through the generator, thereby realizing real-time message push to the user and meeting the needs of streaming response and progressive message presentation.
[0055] In the above implementation, in response to the target tool being a user response tool, data is extracted based on the tool call request to obtain the data to be pushed for reply, and the data to be pushed for reply is output using a preset output channel. Therefore, the system architecture supports the agent in actively and repeatedly streaming task progress or interaction requests to the user through the user response tool during the execution of long-cycle tasks, thereby achieving transparent, multi-round procedural interaction, improving the user's perception and control over the agent's execution process, and effectively improving the human-computer collaboration interaction experience.
[0056] In some implementations, please refer to Figure 5 The target tool includes a loop termination tool. By calling the tool scheduler module to execute the corresponding operation logic of the target tool, closed-loop control of the agent's output response and execution loop can be achieved, which may include the following steps: S510, in response to the target tool being a loop termination tool, generates a loop termination command.
[0057] S520, in response to the loop termination instruction, ends the currently executing loop.
[0058] Specifically, the agent is equipped with a tool scheduler module. When the agent determines that the target tool to be invoked is a loop termination tool, in response to this, the agent invokes the tool scheduler module to trigger a "termination" signal within the agent, which in turn drives the generation of a loop termination instruction acting on the current execution flow. Immediately afterward, the loop execution control mechanism within the agent, upon receiving this loop termination instruction, immediately interrupts the currently running loop flow, preventing it from entering the next iteration and thus ending the current execution loop.
[0059] In the above implementation, a deterministic determination of task termination status is achieved through a clear instruction-driven mechanism, which can effectively distinguish between two situations: normal task completion and abnormal interruption. This eliminates state ambiguity at the system level, significantly enhances the robustness of the task execution process, and reduces semantic coupling and adaptation costs when integrating with other automated systems.
[0060] In some implementations, please refer to Figure 6 The target tools include external business tools. By calling the tool scheduler module to execute the corresponding operation logic of the target tools, a closed-loop control of the agent's output response and execution cycle can be achieved, which may include the following steps: S610: In response to the target tool being an external business tool, the tool call request is forwarded to the external tool execution module through the tool scheduler module.
[0061] S620: The target tool is invoked and executed by calling an external tool execution module to obtain the business execution result.
[0062] Specifically, the agent is configured with a tool scheduler module and an external tool execution module. When the agent determines that the target tool to be invoked is an external business tool, in response to this, the agent forwards the tool invocation request to the external tool execution module through the tool scheduler module. Upon receiving the tool invocation request, the external tool execution module parses the request to extract the target tool name and invocation parameters. Based on the protocol adapter pre-configured for the target tool, or according to the communication protocol and interface specifications required by the target tool, it initiates a remote business invocation to the target tool, driving the target tool to execute its externally provided business logic. After completing the business processing, the target tool returns the business execution result to the external tool execution module. The external tool execution module obtains the business execution result and, optionally, performs internal format standardization conversion on the result before sending the converted result back to the tool scheduler module. Upon receiving the result, the tool scheduler module returns it to the agent's decision engine or dialogue management module, thus enabling the agent to obtain the business execution result of this invocation.
[0063] In the above implementation, in response to the target tool being an external business tool, the tool call request is forwarded to the external tool execution module through the tool scheduler module. The target tool is then called and executed by the external tool execution module to obtain the business execution result. This decouples the tool call from the business logic and manages external services through a unified scheduling layer, simplifying the process of adding or modifying tools and significantly improving the maintainability of the system.
[0064] This specification provides a tool-based interactive language model agent control device 700. Please refer to [link to documentation]. Figure 7 The tool-based interactive language model agent control device 700 includes: a tool call request generation module 710, a tool call request parsing module 720, and a target tool execution module 730.
[0065] The tool call request generation module 710 is used to generate a tool call request by calling a large language model call module, using system prompts, context information and a tool definition list; The tool call request parsing module 720 is used to parse the tool call request by calling the tool scheduler module to determine the target tool to be called; The target tool execution module 730 is used to execute the operation logic corresponding to the target tool by calling the tool scheduler module, thereby realizing closed-loop control of the agent's output response and execution loop.
[0066] For a detailed description of the tool-based interactive language model agent control device, please refer to the description of the tool-based interactive language model agent control method above, which will not be repeated here.
[0067] In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a tool-based interactive language model agent control method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.
[0068] Those skilled in the art will understand that Figure 8 The structures shown are merely block diagrams of some structures related to the solutions disclosed in this specification, and do not constitute a limitation on the computer device to which the solutions disclosed in this specification are applied. Specifically, the computer device may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.
[0069] In some embodiments, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method steps described above.
[0070] This specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method in any of the above embodiments.
[0071] One embodiment of this specification provides a computer program product including instructions that, when executed by a processor of a computer device, enable the computer device to perform the steps of the method described in any of the above embodiments.
[0072] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.
Claims
1. A tool-based interactive language model agent control method, characterized in that, The method includes: By invoking the large language model invocation module, a tool invocation request is generated using system prompts, context information, and a tool definition list. The tool call request is parsed by calling the tool scheduler module to determine the target tool to be called; By invoking the tool scheduler module to execute the operation logic corresponding to the target tool, closed-loop control of the agent's output response and execution loop is achieved.
2. The method according to claim 1, characterized in that, The tool definition list includes at least one external business tool definition for executing business logic, and a core control tool definition for controlling the agent's own interaction state; wherein, the core control tool definition includes a user response tool definition and a loop termination tool definition.
3. The method according to claim 1, characterized in that, The process of generating a tool invocation request by calling a large language model invocation module, utilizing system prompts, context information, and a tool definition list, includes: Generate an initial model request using system prompts, contextual information, and a list of tool definitions; The initial model request is constrained according to the forced tool invocation parameters, and the tool invocation request is generated.
4. The method according to claim 1, characterized in that, The step of parsing the tool invocation request and determining the target tool to be invoked by calling the tool scheduler module includes: Based on the tool call request, the tool name field is extracted; The target tool to be invoked is determined based on the tool name field.
5. The method according to claim 2, characterized in that, The target tool includes a user response tool. The step of executing the operation logic corresponding to the target tool by calling the tool scheduler module to achieve closed-loop control of the agent's output response and execution loop includes: Since the target tool is a user response tool, data is extracted based on the tool's call request to obtain the push response data; The data to be pushed and replied is output using a preset output channel.
6. The method according to claim 2, characterized in that, The target tool includes a loop termination tool. The step of executing the operation logic corresponding to the target tool by calling the tool scheduler module to achieve closed-loop control of the agent's output response and execution loop includes: In response to the target tool being the loop termination tool, a loop termination command is generated; In response to the loop termination instruction, the current execution loop ends.
7. The method according to claim 2, characterized in that, The target tool includes external business tools. The step of executing the operation logic corresponding to the target tool by calling the tool scheduler module to achieve closed-loop control of the agent's output response and execution loop includes: In response to the target tool being the external business tool, the tool call request is forwarded to the external tool execution module through the tool scheduler module; The business execution result is obtained by calling the target tool through the external tool execution module.
8. A tool-based interactive language model agent control device, characterized in that, The device includes: The tool call request generation module is used to generate tool call requests by calling a large language model call module, using system prompts, context information, and a list of tool definitions. The tool call request parsing module is used to parse the tool call request by calling the tool scheduler module to determine the target tool to be called; The target tool execution module is used to execute the operation logic corresponding to the target tool by calling the tool scheduler module, thereby realizing closed-loop control of the agent's output response and execution loop.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.