Health management method based on large language model, electronic device, storage medium and program product

Abstract

The application provides a health management method based on a large language model, an electronic device, a storage medium and a program product, and relates to the technical field of computers. The method uniformly schedules various agents through an orchestrator, decouples intent recognition, professional calculation and reply generation, and each agent cooperates to execute a task based on shared state variables. Compared with a single-agent architecture, the division of labor mechanism enables each agent to focus on its own field of expertise, avoiding fluctuations in reply quality and information bias caused by the generalization of a single model. The business agent calls professional tools to complete deterministic calculation, and the output agent generates a reply based on structured data, significantly improving the stability and professionalism of the reply in the health management scenario and effectively solving the problem of inaccurate information in complex tasks.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a health management method, electronic device, storage medium, and program product based on a large language model. Background Technology

[0002] Currently, with the rapid development of large language model (LLM) technology, health management applications based on LLM are gradually emerging, providing users with services such as dietary advice, weight management, and health consultation. However, most existing health management systems adopt a single LLM direct dialogue model, where the system generates a response through a general large language model after the user inputs a request. While this single-agent architecture is simple to implement, it often results in inconsistent response quality and inaccurate professional information when faced with complex health management tasks. Summary of the Invention

[0003] The purpose of this application is to provide a health management method, electronic device, storage medium, and program product based on a large language model, so as to improve the problem of inaccurate responses when facing complex health management tasks in the prior art.

[0004] In a first aspect, embodiments of this application provide a health management method based on a large language model, applied to an orchestrator of the large language model. The large language model further includes multiple agents, each agent being configured with role instructions and a callable toolset. The orchestrator is used to schedule collaborative processes among the multiple agents. The method includes: Receive user health management requests; The navigation agent among the multiple intelligent agents is scheduled to perform intent recognition on the health management request and obtain the intent recognition result; Based on the intent recognition result, at least one business agent among the plurality of agents is scheduled to collaboratively execute tasks and update processing results based on a shared state variable. The shared state variable is maintained by the orchestrator and is used to store the execution context of each business agent. The output agent among the multiple agents is scheduled to generate and output a user-oriented response based on the processing result.

[0005] In the above implementation process, an orchestrator uniformly schedules all agents, decoupling intent recognition, specialized computation, and response generation. Each agent collaborates to execute tasks based on shared state variables. Compared to a single-agent architecture, this division of labor allows each agent to focus on its area of ​​expertise, avoiding fluctuations in response quality and information bias caused by the generalization of capabilities of a single model. The business agent invokes specialized tools to complete deterministic computations, while the output agent generates responses based on structured data, significantly improving the stability and professionalism of responses in health management scenarios and effectively solving the problem of inaccurate information in complex tasks. Simultaneously, through the shared state and deterministic switching mechanism, process controllability and data decoupling are achieved, significantly improving the system's maintainability and scalability.

[0006] Optionally, the method further includes: Maintain a global object, which includes the identifier of the currently executing agent, the shared state variables, and the dialogue history; The process of scheduling one of the business intelligence agents to collaboratively execute a task based on shared state variables includes: Determine the identifier of the currently executing agent in the global object; Based on the identifier, the corresponding business agent is scheduled to invoke the tool to execute the corresponding business logic using the shared state variables and the dialogue history.

[0007] In the above implementation process, the global object maintained by the orchestrator enables orderly and controllable collaboration among multiple agents, which can be widely applied to personalized health management scenarios.

[0008] Optionally, the identifier of the currently executing agent is returned by the routing tool invoked by the previous agent.

[0009] Optionally, the identifier of the currently executing agent is obtained through one of the following methods: If the previous agent calls the routing tool and returns the identifier of a new agent, then that identifier is used as the identifier of the currently executing agent and written into the global object; If the previous agent did not call the routing tool and a default next agent is configured, then the identifier of the next agent is used as the identifier of the currently executing agent and written into the global object; If the previous agent did not call the routing tool and no default next agent was configured, the identifier of the output agent was used as the identifier of the currently executing agent and written into the global object.

[0010] In the above implementation process, this mechanism is closely integrated with the global object, enabling the orchestrator to accurately determine the executor of each step, thereby supporting the automation of complex health management tasks.

[0011] Optionally, the global object also includes the maximum number of cooperative rounds among the agents, and the shared state variable also includes the number of cooperative rounds among the agents. Before determining the identifier of the currently executing agent in the global object, the following is also included: Determine whether the number of collaborative rounds recorded in the shared state variable has reached the maximum number of collaborative rounds; if so, terminate the collaboration process.

[0012] In the above implementation, this mechanism complements the termination condition based on the next hop identifier (termination occurs when the next hop cannot be obtained), jointly ensuring the robustness and controllability of the multi-agent collaborative process. The introduction of the round limit is applicable to abnormal branches or infinite loops that may occur in complex scenarios, ensuring that system resources are not consumed indefinitely, while providing developers with configurable fault tolerance boundaries.

[0013] Optionally, the process of scheduling one of the business agents to collaboratively execute a task based on shared state variables includes: If a business intelligence agent initiates multiple tool calls in a single interaction and parallel calls are not allowed, then one tool call should be selected.

[0014] In the above implementation process, when the system configuration does not allow parallel calls, the orchestrator selects one tool call to execute and discards the rest of the calls to ensure the determinism and controllability of the process.

[0015] Optionally, if the business intelligence agent initiates multiple tool calls in a single interaction and parallel calls are not allowed, then one tool call is selected, including: If a business intelligence agent initiates multiple tool calls in a single interaction and parallel calls are not allowed, then one tool call is selected based on the priority of each tool, which is determined according to the business logic dependencies between the tools.

[0016] In the above implementation process, by setting priorities for tool calls based on business dependencies, only the highest priority tool is executed when multiple tools are executed concurrently. This mechanism ensures that data producers (such as planning adjustment tools) are executed before consumers (such as consultation output tools), avoiding inconsistencies in state or incorrect results caused by improper data read / write order; at the same time, it prevents agent switching conflicts caused by multiple tool calls, ensuring a single path for the process.

[0017] Optionally, the output agent includes a first medical agent and a second medical agent. The process of scheduling the output agent among the plurality of agents to generate and output a user-oriented response based on the processing result includes: The first medical intelligent agent is scheduled to determine the medical risks involved in the health management request. If the medical risks exceed the risk threshold, medical advice is output. If the medical risk does not exceed the risk threshold, the first medical agent is scheduled to retrieve relevant information and write the retrieval results into the shared state variable. The second medical agent is scheduled to read the retrieval results from the shared state variables, generate user-oriented response results, and output them.

[0018] In the above implementation process, by splitting medical processing into risk assessment and information retrieval (first medical agent) and compliance response generation (second medical agent), high-risk issues are quickly blocked, while low-risk issues are retrieved and then professional responses are generated by a dedicated output agent. The first medical agent, as the business agent, is responsible for deterministic operations and state writing, while the second medical agent, as the output agent, focuses on expression style and compliance. The two collaborate by sharing state variables, ensuring both the rigor of medical information processing and the consistency of user interaction.

[0019] Secondly, embodiments of this application provide a health management device based on a large language model. This device is applied to an orchestrator of the large language model, which further includes multiple agents. Each agent is configured with role instructions and a callable toolset. The orchestrator is used to schedule collaborative processes among the multiple agents. The device includes: The request receiving module is used to receive users' health management requests; The intent recognition module is used to schedule the navigation agent among the multiple agents to perform intent recognition on the health management request and obtain the intent recognition result; The service scheduling module is used to sequentially schedule at least one of the multiple intelligent agents to collaboratively execute tasks and update processing results based on shared state variables according to the intent recognition result. The shared state variables are maintained by the orchestrator and are used to store the execution context of each intelligent agent. The output module is used to schedule the output agent among the multiple agents to generate and output a user-oriented response based on the processing result.

[0020] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the steps of the method provided in the first aspect above are performed.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the method provided in the first aspect above.

[0022] Fifthly, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the steps of the method provided in the first aspect above.

[0023] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a health management method based on a large language model, provided as an embodiment of this application; Figure 2 A structural block diagram of a health management device based on a large language model provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an electronic device for executing a health management method based on a large language model, provided as an embodiment of this application. Detailed Implementation

[0026] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0027] It should be noted that the terms "system" and "network" in the embodiments of this invention can be used interchangeably. "Multiple" refers to two or more; therefore, in the embodiments of this invention, "multiple" can also be understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0028] It should also be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0029] This application provides a health management method based on a large language model. This method uses an orchestrator to uniformly schedule various agents, decoupling intent recognition, specialized computation, and response generation. Each agent collaborates to execute tasks based on shared state variables. Compared to a single-agent architecture, this division of labor allows each agent to focus on its area of ​​expertise, avoiding fluctuations in response quality and information bias caused by the generalization of capabilities of a single model. The business agent invokes specialized tools to complete deterministic computations, and the output agent generates responses based on structured data, significantly improving the stability and professionalism of responses in health management scenarios and effectively solving the problem of inaccurate information in complex tasks.

[0030] The large language model involved in this solution includes an orchestrator and multiple agents. Each agent is configured with role instructions and a set of callable tools. The orchestrator is used to schedule the collaborative process between multiple agents.

[0031] Specifically, the Large Language Model (LLM) acts as the brain of the agent. Each agent is based on the same LLM instance or an LLM with different configurations, and its behavior is guided by different role instructions. The LLM receives user input and context, generates natural language responses, or initiates tool calls.

[0032] Each agent is a configurable role unit, with core elements including: Role instructions: Define the agent's responsibilities, behavioral guidelines, and output style; Callable toolset (functions): A set of functions that can be called by the LLM to perform deterministic operations (such as computation, retrieval, database read and write); each tool encapsulates deterministic business logic, can read or write shared state variables, and can selectively return a new agent identifier to instruct the orchestrator to switch the currently executing agent; Default next agent: Optional configuration. When an agent does not generate a tool call, the orchestrator automatically switches to this agent. Other attributes include whether the output is streamed (can_stream) and whether parallel tool calls are allowed (parallel_tool_calls). For example, the orchestrator can insert structured cards / references / buttons into the streamed output and segment and adapt to TTS / version for specific agents, improving the consistency of interaction on the client side.

[0033] Based on their functional type, intelligent agents can be divided into navigation intelligent agents, business intelligent agents, and output intelligent agents. For healthcare scenarios, a separate medical intelligent agent is also provided. Adding or replacing intelligent agents is primarily accomplished by configuring their instruction and tool sets, without requiring changes to the main orchestration process.

[0034] Navigation agents, such as NavigatorAgent, are responsible for intent recognition and route distribution. They do not directly answer business questions but distribute user requests to the most appropriate agent (such as consultation, plan recalculation, information query, medical health or weight record, etc.).

[0035] Business intelligence agents are used to execute specific business logic, such as PlanAdjustmentAgent, WeightHandlerAgent, and GuidePageQueryInfoAgent.

[0036] PlanAdjustmentAgent: Responsible for responding to user requests to modify weight loss goals, speed, stages, or dates. It extracts change points, merges user information, performs safety checks, recalculates and generates the plan and curves, and writes the structured results (such as plan descriptions and stage curve data) into shared state variables. Its business objective is to achieve plan adjustability and safety constraints. Typically, it is triggered by the navigation agent through routing tools, and then writes explanatory prompts into the output agent's communication message, which then explains the changes to the user.

[0037] WeightHandlerAgent (Weight Processing): Responsible for recognizing and recording weight data (text or images), supporting operations such as adding, correcting, updating, and querying historical data. It triggers encouraging messages after recording, providing a data foundation for subsequent tracking and weekly reports. Its business goal is to help users develop sustainable weight recording habits. In terms of handover, after processing, the results are written to a shared state variable, typically switched to the output agent via a default next agent or tool return.

[0038] GuidePageQueryInfoAgent (Data Query): When a user asks a question about personal data (such as calorie goals, remaining calories, calculation methods, etc.), the answer is organized from shared state variables and written to the tool message for use by downstream agents. Its goal is to allow users to track their key metrics at any time, reducing the cost of repetitive explanations. It is typically routed to this point by the navigation agent, and after completion, it is handed over to the output agent to generate a response.

[0039] The Coordinator (or orchestrator): Responsible for generating a list of planned tasks, planned timeframes, and default reminder strategies based on user information and stages, and writing the results to shared state variables for display by other agents and the front end. Its core function is to orchestrate the initial plan and refactor tasks after dynamic adjustments. As a data producer, it typically executes before other business agents to ensure the accuracy of downstream dependent data.

[0040] Output agents, such as ConsultantAgent, are responsible for integrating business results into user-facing natural language responses, maintaining a consistent interaction style. As the primary, general user-facing output outlet, it formats historical dialogues and places upstream-injected information (such as plans, reminders, and tool results) into relevant prompt areas, allowing the large language model to prioritize explaining, reassuring, and guiding users based on this information. Its goal is to uniformly handle communication responsibilities such as plan explanation, emotional support, reminders, and task list display, converging multi-module results into a single natural language response and reducing style inconsistencies caused by direct output from multiple agents. In terms of handover, it typically acts as the last agent in the process, reading all business results from shared state variables and generating a response; collaboration terminates when there is no default next hop or a return switch.

[0041] Medical Agent is a specialized intelligent agent designed for healthcare scenarios. It includes MedicalHealthAgent (medical risk assessment and retrieval) and MedicalHealthConsultant (medical compliance response generation) to achieve security boundary control.

[0042] MedicalHealthAgent: As the core of business processing in healthcare scenarios, it is responsible for medical risk assessment and information retrieval. It uses a large language model to assess the risk of user input: if serious medical issues are involved (such as acute symptoms, drug overdose, etc.), it directly outputs medical advice and terminates the process, achieving compliance boundary control; if it is a health consultation related to diet or weight loss, it calls online search or knowledge base tools to obtain authoritative information and writes the search results and reference links into a shared state variable (or transmits them via agent_communication_message). Its business objective is to provide reliable information support for answerable health questions while ensuring professionalism and security. In terms of handover, MedicalHealthAgent is typically triggered by a navigation agent through a routing tool. After completing the risk assessment or retrieval, it configures the default next agent as MedicalHealthConsultant, or switches control through a tool return instruction, handing over control to the latter to generate the final response.

[0043] MedicalHealthConsultant: A dedicated output agent specifically designed for healthcare scenarios. Its functions include reading search results or risk assessment information written by MedicalHealthAgent from shared state variables, integrating them into professional, rigorous, and easily understandable natural language responses, and adding reference links or disclaimers when necessary based on role instructions. Its business objective is to provide users with reliable health information support while ensuring that the output content complies with medical compliance requirements, avoiding the risk of misleading responses caused by generated replies. In terms of handover, this agent is typically triggered by MedicalHealthAgent through the default next agent configuration, serving as the final exit point for the healthcare branch. Upon completion, since there is no default next hop and no tool calls are generated, the collaboration process naturally terminates, thus achieving a secure closed loop in the healthcare scenario.

[0044] As the central control unit for multi-agent collaboration, the orchestrator maintains the following core states: the identifier of the currently executing agent (pointing to the agent currently executing), the dialogue history (recording all interaction information used with the system), and the shared state variable (serving as a bridge for communication between agents; all intermediate data generated by business agents are written into this variable, and output agents read from and aggregate it to ensure information consistency and avoid duplicate calculations).

[0045] Please refer to the following. Figure 1 , Figure 1 A flowchart of a health management method based on a large language model provided in this application embodiment is included, the method comprising the following steps: Step S110: Receive the user's health management request.

[0046] Users can input multimodal requests via mobile applications (such as health management apps), including text, images, and voice. For example, a user might upload a photo of a meal with the caption, "Can you check the calories in this meal? How much can I eat today?" After receiving the request, the system hands it over to the orchestrator for processing. The orchestrator initializes shared state variables, stores the user input in the dialogue history, and sets the currently executing agent as the navigation agent.

[0047] Step S120: Schedule the navigation agent among multiple agents to perform intent recognition on the health management request and obtain the intent recognition result.

[0048] The NavigatorAgent receives the user's health management request and, based on its role instructions, invokes the LLM (Limited Learning Model) to analyze the user's intent. The LLM parses text and / or images to identify key information, such as meal calorie analysis and planned remaining calorie query in the example above. Based on this, the NavigatorAgent determines that it needs to be routed to the WeightHandlerAgent to complete image recognition and calorie calculation, and may subsequently require the PlanAdjustmentAgent to assess remaining calories.

[0049] The navigation agent can invoke routing tools such as `transfer_to_weight_handler`, which returns the identifier of `WeightHandlerAgent` and writes this identifier to the `next_agent` field in the shared state variable. When the orchestrator detects `next_agent`, it immediately switches the currently executing agent to `WeightHandlerAgent`.

[0050] Step S130: Based on the intent recognition result, at least one business agent among multiple agents is sequentially scheduled to collaboratively execute tasks based on shared state variables and update the processing results.

[0051] The shared state variables are maintained by the orchestrator and are used to store the execution context of each business agent.

[0052] For example, if the intent recognition result determines that the first business agent to be invoked is the weight handling agent (WeightHandlerAgent), the orchestrator, upon determining from the shared state variables that the currently executing agent is WeightHandlerAgent, will schedule that agent to execute the corresponding business logic. The role instruction for this weight handling agent is "You are responsible for handling weight-related matters, including recognizing food images, calculating calories, and recording weight." This agent can read image data uploaded by the user from the shared state variables.

[0053] WeightHandlerAgent can call an image recognition tool (such as recognize_food) to identify the type and portion of food, then call a calorie calculation tool (calculate_calories) to calculate the total calories based on a standard food database, and finally write the recognition results and calorie values ​​into a shared state variable.

[0054] If WeightHandlerAgent is configured with PlanAdjustmentAgent as the default next agent and no new tool calls are generated, the orchestrator will automatically switch the currently executing agent to PlanAdjustmentAgent.

[0055] PlanAdjustmentAgent continues to read the user's daily calorie intake from the shared state variables (assuming it's obtained from the user's historical data, such as the daily_intake field stored in the shared state variables) and the current calorie intake, calculating the total intake. Combined with the user's weight loss goal (such as the recommended daily intake), the remaining calories can be determined.

[0056] PlanAdjustmentAgent writes the remaining heat and adjustment recommendations into a shared state variable. If PlanAdjustmentAgent is also configured with ConsultantAgent (the output agent) as the default next agent, the orchestrator switches to ConsultantAgent accordingly.

[0057] In the above process, shared state variables act as a medium for data transmission, enabling various business agents to collaborate and complete tasks simply by reading and writing to the same global dictionary, without needing to communicate directly. The orchestrator is responsible for sequential scheduling, ensuring that each agent continues processing based on the previous result.

[0058] Step S140: Schedule the output agent among multiple agents to generate and output user-oriented response results based on the processing results.

[0059] The current executing agent is ConsultantAgent (the output agent). Its role instruction is "You are a friendly health consultant, responsible for translating business processing results into natural, encouraging language to respond to users." It reads all data written by business agents from shared state variables: food lists, calorie values, remaining calories, planning suggestions, etc.

[0060] The ConsultantAgent then invokes the LLM to integrate the information and generate a user-oriented response, such as: "Your meal includes rice (200g), stir-fried vegetables (150g), and chicken breast (100g), with a total of approximately 442 kcal. You have already consumed 600 kcal today, bringing your total to 1042 kcal. You have 458 kcal remaining, which perfectly matches your weight loss goal! We recommend that you maintain a balanced diet for dinner, and you can consume appropriate amounts of staple foods and protein."

[0061] The response can be delivered to the user via text, voice, or a card, while simultaneously updating the conversation history. If the ConsultantAgent is not configured with a default next agent and no tools are invoked, the orchestrator detects the lack of subsequent steps and terminates the collaboration process.

[0062] In the above implementation process, an orchestrator uniformly schedules all agents, decoupling intent recognition, specialized computation, and response generation. Each agent collaborates to execute tasks based on shared state variables. Compared to a single-agent architecture, this division of labor allows each agent to focus on its area of ​​expertise, avoiding fluctuations in response quality and information bias caused by the generalization of capabilities of a single model. The business agent invokes specialized tools to complete deterministic computations, while the output agent generates responses based on structured data, significantly improving the stability and professionalism of responses in health management scenarios and effectively solving the problem of inaccurate information in complex tasks. Simultaneously, through the shared state and deterministic switching mechanism, process controllability and data decoupling are achieved, significantly improving the system's maintainability and scalability.

[0063] Based on the above embodiments, the orchestrator also maintains a global object, which includes the identifier of the currently executing agent, shared state variables, and dialogue history.

[0064] When the orchestrator schedules one of the business agents to collaboratively execute a task based on shared state variables, it can first determine the identifier of the currently executing agent in the global object, and then schedule the corresponding business agent based on the shared state variables and dialogue history to call the tool to execute the corresponding business logic.

[0065] When the orchestrator initially receives a user's health management request, it initializes the global object, such as setting the identifier of the currently executing agent to the identifier of the navigation agent (e.g., active_agent="navigator_agent"), clearing the shared state variables, and appending the user input to the dialogue history.

[0066] The orchestrator reads the value of `active_agent` from the global object to obtain the identifier of the agent to be executed. For example, in the initial loop, `active_agent` is "navigator_agent". The orchestrator finds the corresponding navigation agent instance based on this identifier and calls its execution logic. The navigation agent analyzes the user request based on role instructions, identifies the intent as "meal calorie analysis", and calls the routing tool `transfer_to_weight_handler`. After execution, the tool returns a new agent identifier "weight_handler_agent", which is written to the global object (or directly returned to the orchestrator). The orchestrator detects the identifier returned by the tool, immediately updates `active_agent` in the global object to "weight_handler_agent", and simultaneously records the tool execution results (such as routing information) to the dialogue history and updates the shared state variables.

[0067] The orchestrator continues to the next loop, again reading `active_agent` from the global object (now "weight_handler_agent"), and scheduling the corresponding weight handling agent. This agent reads user image data from the dialogue history, calls an image recognition tool to identify food and calculate calories, and writes the results to shared state variables and the dialogue history. Since this agent is configured with the default next agent as the plan adjustment agent (`default_next_agent="plan_adjustment_agent"`), and no new tool calls are generated, the orchestrator automatically updates `active_agent` in the global object to "plan_adjustment_agent" after the agent finishes execution.

[0068] Next, the orchestrator schedules the agent, which reads the stored calorie data from the shared state variable, calculates the remaining calorie intake based on the user's goal, and writes the result back to the shared state variable. The default next agent is the output agent ("consultant_agent"), and the orchestrator updates the active_agent again.

[0069] Finally, the orchestrator schedules the output agent, which reads all business results from the shared state variables, generates a natural language response, and outputs the response to the user. Since the output agent has no default next hop and does not invoke any tools, the orchestrator detects that there are no subsequent steps and terminates the loop.

[0070] In the above implementation process, the global object maintained by the orchestrator enables orderly and controllable collaboration among multiple agents, which can be widely applied to personalized health management scenarios.

[0071] Building upon the above embodiments, the identifier of the currently executing agent can be returned by the routing tool invoked by the previous agent. A routing tool is a special type of utility function that returns a new agent identifier upon execution, used for dynamically switching execution flows. For example, `transfer_to_weight_handler` returns the identifier of the weight handling agent.

[0072] After each agent completes its execution, the orchestrator determines the next active agent based on the agent's behavior and writes it to the global object. The specific rules are as follows: (1) If the previous agent calls the routing tool and returns the identifier of the new agent, then use the identifier as the identifier of the currently executing agent and write it into the global object.

[0073] If the current agent invokes the routing tool during execution, and the tool returns a new agent identifier, the orchestrator uses this returned identifier as the next round's `active_agent` and writes it to the global object. This rule allows the process to dynamically jump based on business needs, such as jumping from a navigation agent to a business agent.

[0074] (2) If the previous agent did not call the routing tool and a default next agent is configured, the identifier of the next agent is used as the identifier of the currently executing agent and written into the global object.

[0075] If the current agent does not invoke any tools (or the invoked tools do not return a new identifier), but the agent is configured with a default next agent (default_next_agent), the orchestrator will use that default identifier as the next round's active_agent and write it to the global object. This rule provides a static alternative path and is suitable for most standard business processes, such as automatically handing over to the output agent after business processing is completed.

[0076] (3) If the previous agent did not call the routing tool and no default next agent was configured, the identifier of the output agent will be used as the identifier of the currently executing agent and written into the global object.

[0077] If the current agent neither invokes a tool nor configures a default next agent, the orchestrator will use the output agent's identifier as the next round's `active_agent` and write it to the global object. This rule is a safety fallback mechanism to ensure that the process eventually converges to the output stage, preventing process interruption due to missing subsequent instructions. If there are no subsequent actions after the output agent executes, the process will naturally terminate.

[0078] In the above implementation process, this mechanism is closely integrated with the global object, enabling the orchestrator to accurately determine the executor of each step, thereby supporting the automation of complex health management tasks.

[0079] Based on the above embodiments, the global object also includes the maximum number of collaboration rounds between each agent, and the shared state variables also include the number of collaboration rounds between each agent. Before or after the orchestrator determines the identifier of the currently executing agent in the global object, it can also determine whether the number of collaboration rounds recorded in the shared state variables has reached the maximum number of collaboration rounds. If so, the collaboration process is terminated.

[0080] In this implementation, a collaboration round counter is introduced into the global object maintained by the orchestrator as a guarantee mechanism for process convergence. In addition to containing the identifier of the currently executing agent (active_agent), shared state variables (context_variables), and dialogue history (history), the global object also includes a field in the shared state variables to record the number of completed collaboration rounds (e.g., turn_count). The orchestrator presets a maximum number of collaboration rounds (max_turns) as a global threshold to prevent infinite loops. Before or after determining the identifier of the next executing agent, the orchestrator checks whether the current number of collaboration rounds has reached or exceeded the maximum number. If so, the collaboration process is immediately terminated, and no more agents are scheduled; if not, the process continues.

[0081] In practice, before updating the `active_agent` for the next round after each agent finishes execution, the orchestrator first increments `turn_count` by 1 and then compares it with `max_turns`. If `turn_count >= max_turns`, the loop stops, and even if the current agent returns a new identifier or a default next hop exists, no subsequent agents are executed, and the process ends directly. If the maximum number of turns is not reached, `active_agent` is updated according to the normal rules, and the next round begins. This check can also be performed at the beginning of each loop to ensure that the number of rounds has not exceeded the limit before each round. Both methods achieve the same control effect.

[0082] For example, suppose the system defaults to a maximum of 5 collaboration rounds. A user initiates a complex health consultation request, which requires passing through multiple stages, including a navigation agent, a medical health agent, and a medical consultation agent. If, during the collaboration process, the number of rounds accumulates to 5 due to some reason (such as repeated intentional jumps or tool call loops), even if the process has not yet terminated naturally (e.g., there is still a default next hop that has not been executed), the orchestrator will forcibly terminate the collaboration and return the currently generated intermediate results (if any) or a prompt to the user, preventing the system from falling into an infinite loop. If the process has completed all business processing and output results within 4 rounds, it will terminate naturally, and the round count check will have no impact.

[0083] In the above implementation, this mechanism complements the termination condition based on the next hop identifier (termination occurs when the next hop cannot be obtained), jointly ensuring the robustness and controllability of the multi-agent collaborative process. The introduction of the round limit is applicable to abnormal branches or infinite loops that may occur in complex scenarios, ensuring that system resources are not consumed indefinitely, while providing developers with configurable fault tolerance boundaries.

[0084] Based on the above embodiments, when scheduling one of the business agents to collaboratively execute a task based on shared state variables, if the business agent initiates multiple tool calls in one round of interaction and parallel calls are not allowed, one tool call is selected.

[0085] In a single round of interaction, the orchestrator schedules the corresponding business agent based on the currently executing agent identifier (active_agent) in the global object. This agent, based on user input and shared state variables, invokes the large language model to generate a response. Because user requests may be ambiguous or have multiple intents, or the LLM may have multiple interpretations of the same question, the model may initiate multiple tool calls in a single output round. For example, when processing photos of meals uploaded by a user, the weight handling agent (WeightHandlerAgent) may simultaneously generate two tool calls: recognize_food and query_user_history, intending to simultaneously complete recognition and background data acquisition.

[0086] The orchestrator receives the LLM output and parses out the tool call list. If the list length is greater than 1 and the agent's configuration has parallel_tool_calls=false (parallelization is not allowed), then a multi-tool arbitration process is triggered.

[0087] One implementation is to randomly select one tool call to execute, that is, to select one tool call from multiple tool calls to keep it in execution.

[0088] Another approach is to select and invoke a tool based on its priority, which is determined by the dependencies between the tools in the business logic. For example, coordination tools have higher priority than nutrition calculation tools, and nutrition calculation tools have higher priority than consulting output tools.

[0089] Of course, priority rules can also be designed based on the following principles: Data producers take precedence over consumers: generate data first, then use it. For example, `recognize_food` (generating calorie data) takes precedence over `query_user_history` (querying historical data) because the latter may require the results generated by the former.

[0090] Core functions take precedence over auxiliary functions: core tools that directly affect users' health management, such as plan adjustments and calorie calculations, are given higher priority than auxiliary tools such as queries and reminders.

[0091] Routing tools are given priority: Tools involving agent switching (such as transfer_to_*) are usually given higher priority to ensure that the flow direction is determined first.

[0092] For example, the default priority can be configured as: coordinator-type tools > nutrition-type tools > consultant-type tools. The specific tool names can be determined through keyword matching or an explicit priority list.

[0093] The orchestrator executes only the selected tool call, writes its return value to a shared state variable, and records it in the dialogue history. All other tool calls are discarded without any further action.

[0094] After the tool is executed, if it returns a new agent identifier, the orchestrator updates the active_agent in the global object accordingly; if it does not return a new agent identifier and the current agent has a default next agent configured, the switch is performed according to the default link; otherwise, the current agent continues or the process terminates.

[0095] In the above implementation process, by setting priorities for tool calls based on business dependencies, only the highest priority tool is executed when multiple tools are executed concurrently. This mechanism ensures that data producers (such as planning adjustment tools) are executed before consumers (such as consultation output tools), avoiding inconsistencies in state or incorrect results caused by improper data read / write order; at the same time, it prevents agent switching conflicts caused by multiple tool calls, ensuring a single path for the process.

[0096] Based on the above embodiments, in a healthcare scenario, the output agent may include a first medical agent and a second medical agent. When scheduling the output agent to output a response result, the first medical agent is first scheduled to determine the medical risks involved in the health management request. If the medical risks exceed the risk threshold, medical advice is output. If the medical risks do not exceed the risk threshold, the first medical agent is scheduled to retrieve relevant information and write the retrieval results into a shared state variable. Then, the second medical agent is scheduled to read the retrieval results from the shared state variable, generate a user-oriented response result, and output it.

[0097] The first medical agent (MedicalHealthAgent) is equipped with medical risk assessment instructions and a retrieval toolset. It is responsible for analyzing whether user input involves serious medical risks (such as acute symptoms, drug interactions, emergency needs, etc.). Functionally, the first medical agent can act as both a business agent and an output agent. If the risk exceeds a preset threshold, it directly outputs medical advice and terminates the process; if the risk is controllable, it calls online retrieval or knowledge base tools to obtain authoritative information and writes the results into a shared state variable.

[0098] The second medical agent (MedicalHealthConsultant) is configured as the output agent. It reads the search results written by the first medical agent from the shared state variables, combines them with the user's original question to generate a natural language response, and ensures that the content is professional and compliant, and includes citation links or disclaimers when necessary.

[0099] Risk thresholds are a predefined set of rules used to determine the severity of medical issues. For example, questions involving keywords such as chest pain, difficulty breathing, or drug overdose are considered high-risk and require direct medical attention; while food and drug interactions, general dietary advice, etc., are considered low-risk and can be addressed after information retrieval.

[0100] When the orchestrator routes a user's health management request to the medical and health processing branch through intent recognition, it first schedules the execution of the first medical agent. The first medical agent receives the user input and, based on its role instructions, invokes a large language model for risk assessment. For example, if a user asks, "My blood pressure has been a bit high lately, can I eat grapefruit while taking antihypertensive medication?" the agent analyzes the information and determines that this is a general inquiry about drug-food interactions, not reaching the high-risk threshold. Therefore, it invokes an online search tool to query authoritative medical information. The search tool returns the search results, and the first medical agent writes these results to a shared state variable, along with a reference link. Since the first medical agent is configured with the second medical agent as the default next agent, the orchestrator automatically switches the currently executing agent.

[0101] If the user inputs "I have severe chest pain, what should I do?", the first medical agent recognizes that "severe chest pain" is a high-risk keyword that exceeds the risk threshold. It then directly generates medical advice (such as "chest pain may involve serious heart problems, please seek medical attention immediately"), terminates the collaboration process, and no longer schedules the second medical agent.

[0102] When the second medical agent is dispatched, it reads `medical_retrieval_result` and other relevant data from the shared state variable, and generates a final response based on its role instructions (such as "You are a professional health consultant; please convey medical information to the user in a clear and easy-to-understand way, emphasizing the importance of consulting a doctor"). This response is returned to the user in text or voice format, and the process terminates.

[0103] In the above implementation process, by splitting medical processing into risk assessment and information retrieval (first medical agent) and compliance response generation (second medical agent), high-risk issues are quickly blocked, while low-risk issues are retrieved and then professional responses are generated by a dedicated output agent. The first medical agent, as the business agent, is responsible for deterministic operations and state writing, while the second medical agent, as the output agent, focuses on expression style and compliance. The two collaborate by sharing state variables, ensuring both the rigor of medical information processing and the consistency of user interaction.

[0104] In some implementations, a state version controller can be integrated into the orchestrator as an internal submodule to address data race and consistency issues when multiple agents concurrently write to shared state variables.

[0105] Specifically, the state version controller encapsulates all write operations to shared state variables in a versioned manner, maintaining a monotonically increasing version number for each shared state variable. When an agent reads a shared state variable, the orchestrator returns not only the data value but also the current version number. Before performing a write operation, the agent must carry the version number obtained during the read. During verification, if the version number carried in the write request matches the current version number, the state version controller allows the write and increments the version number by 1. If they do not match, it indicates that another agent has modified the data after the agent read but before the write, so the write is rejected, and a state rollback and retry mechanism is triggered. This means that the agent that initiated the write is notified to reread the latest state, re-execute the business logic based on the latest data, and then attempt to write again.

[0106] For example, a user quickly sends two consecutive requests: the first to update weight data, and the second to recalculate a weight loss plan based on the latest weight. The orchestrator schedules the weight processing agent and the plan adjustment agent to execute in parallel. The weight processing agent reads the current weight data (version number 5) and begins writing the new weight value; simultaneously, the plan adjustment agent also reads the same weight data (also version number 5) and prepares to calculate the plan based on it. If the weight processing agent completes the write first, the state version controller updates the version number to 6 and updates the weight data. Then, the plan adjustment agent attempts to write its plan calculation result with version number 5. The state version controller detects that the current version number has become 6, which is inconsistent with the version number 5 in the request, determines that the data is outdated, rejects the write, and triggers a retry mechanism. The plan adjustment agent rereads the latest state (version number 6, including the updated weight data), recalculates the plan, and submits the write again. This time, the version number matches, and the write succeeds.

[0107] This mechanism ensures that the intelligent agent for planning adjustments always calculates based on the latest weight data, avoiding data inconsistencies and calculation errors caused by concurrent writes, and ensuring the certainty and professionalism of the output results in health management scenarios.

[0108] Please refer to Figure 2 , Figure 2 This is a structural block diagram of a health management device 200 based on a large language model, provided as an embodiment of this application. The device 200 may be a module, program segment, or code on an electronic device. It should be understood that the device 200 corresponds to the above method embodiment and is capable of executing the various steps involved in the method embodiment. The specific functions of the device 200 can be found in the description above; to avoid repetition, detailed descriptions are appropriately omitted here.

[0109] Optionally, the device 200 includes: The request receiving module 210 is used to receive users' health management requests; The intent recognition module 220 is used to schedule the navigation agent among the multiple intelligent agents to perform intent recognition on the health management request and obtain the intent recognition result; The service scheduling module 230 is used to sequentially schedule at least one of the multiple intelligent agents to collaboratively execute tasks and update processing results based on shared state variables according to the intent recognition result. The shared state variables are maintained by the orchestrator and are used to store the execution context of each intelligent agent. The output module 240 is used to schedule the output agent among the multiple agents to generate and output a user-oriented response result based on the processing result.

[0110] Optionally, the device 200 further includes: The object maintenance module is used to maintain a global object, which includes the identifier of the currently executing agent, the shared state variables, and the dialogue history. The business scheduling module 230 is used to determine the identifier of the currently executing intelligent agent in the global object; and to schedule the corresponding business intelligent agent according to the identifier, based on the shared state variables and the dialogue history, to call the tool to execute the corresponding business logic.

[0111] Optionally, the identifier of the currently executing agent is returned by the routing tool invoked by the previous agent.

[0112] Optionally, the identifier of the currently executing agent is obtained through one of the following methods: If the previous agent calls the routing tool and returns the identifier of a new agent, then that identifier is used as the identifier of the currently executing agent and written into the global object; If the previous agent did not call the routing tool and a default next agent is configured, then the identifier of the next agent is used as the identifier of the currently executing agent and written into the global object; If the previous agent did not call the routing tool and no default next agent was configured, the identifier of the output agent was used as the identifier of the currently executing agent and written into the global object.

[0113] Optionally, the global object also includes the maximum number of collaboration rounds between each agent, and the shared state variable also includes the number of collaboration rounds between each agent. The service scheduling module 230 is further used to determine whether the number of collaboration rounds recorded in the shared state variable has reached the maximum number of collaboration rounds. If so, the collaboration process is terminated.

[0114] Optionally, the business scheduling module 230 is configured to select one tool call if the business intelligence agent initiates multiple tool calls in a round of interaction and parallel calls are not allowed.

[0115] Optionally, the business scheduling module 230 is configured to select one tool to call based on the priority of each tool if the business intelligence agent initiates multiple tool calls in one round of interaction and parallel calls are not allowed. The priority is determined based on the business logic dependency relationship between the tools.

[0116] Optionally, the output intelligent agent includes a first medical intelligent agent and a second medical intelligent agent. The output module 240 is used to schedule the first medical intelligent agent to determine the medical risks involved in the health management request. If the medical risks exceed a risk threshold, it outputs medical advice. If the medical risks do not exceed the risk threshold, it schedules the first medical intelligent agent to retrieve relevant information and write the retrieval results into the shared state variable. It also schedules the second medical intelligent agent to read the retrieval results from the shared state variable, generate user-oriented response results, and output them.

[0117] It should be noted that those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0118] Please refer to Figure 3 , Figure 3 This application provides a schematic diagram of the structure of an electronic device for executing a health management method based on a large language model. The electronic device may include: at least one processor 310, such as a CPU; at least one communication interface 320; at least one memory 330; and at least one communication bus 340. The communication bus 340 is used to establish communication between these components. In this embodiment, the communication interface 320 is used for signaling or data communication with other node devices. The memory 330 may be a high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 330 may also be at least one storage device located remotely from the processor. The memory 330 stores computer-readable instructions, which, when executed by the processor 310, enable the electronic device to perform the aforementioned method process.

[0119] Understandable. Figure 3 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown. Figure 3 The components shown can be implemented using hardware, software, or a combination thereof.

[0120] This application provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it performs the method process executed by the electronic device in the above method embodiments.

[0121] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments, such as including: Receive user health management requests; The navigation agent among the multiple intelligent agents is scheduled to perform intent recognition on the health management request and obtain the intent recognition result; Based on the intent recognition result, at least one business agent among the plurality of agents is scheduled to collaboratively execute tasks and update processing results based on a shared state variable. The shared state variable is maintained by the orchestrator and is used to store the execution context of each business agent. The output agent among the multiple agents is scheduled to generate and output a user-oriented response based on the processing result.

[0122] In summary, this application provides a health management method, electronic device, storage medium, and program product based on a large language model. This method uses an orchestrator to uniformly schedule various agents, decoupling intent recognition, specialized computation, and response generation. Each agent collaborates to execute tasks based on shared state variables. Compared to a single-agent architecture, this division of labor allows each agent to focus on its area of ​​expertise, avoiding fluctuations in response quality and information bias caused by the generalization of capabilities of a single model. The business agent invokes specialized tools to complete deterministic computations, and the output agent generates responses based on structured data, significantly improving the stability and professionalism of responses in health management scenarios and effectively solving the problem of inaccurate information in complex tasks.

[0123] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0124] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0126] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0127] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A health management method based on a large language model, characterized in that, An orchestrator applied to the large language model, the large language model further comprising multiple agents, each agent configured with role instructions and a callable toolset, the orchestrator being used to schedule collaborative processes among the multiple agents, the method comprising: Receive user health management requests; The navigation agent among the multiple intelligent agents is scheduled to perform intent recognition on the health management request and obtain the intent recognition result; Based on the intent recognition result, at least one business agent among the plurality of agents is scheduled to collaboratively execute tasks and update processing results based on a shared state variable. The shared state variable is maintained by the orchestrator and is used to store the execution context of each business agent. The output agent among the multiple agents is scheduled to generate and output a user-oriented response based on the processing result.

2. The method according to claim 1, characterized in that, The method further includes: Maintain a global object, which includes the identifier of the currently executing agent, the shared state variables, and the dialogue history; The process of scheduling one of the business intelligence agents to collaboratively execute a task based on shared state variables includes: Determine the identifier of the currently executing agent in the global object; Based on the identifier, the corresponding business agent is scheduled to invoke the tool to execute the corresponding business logic using the shared state variables and the dialogue history.

3. The method according to claim 2, characterized in that, The identifier of the currently executing agent is returned by the routing tool invoked by the previous agent.

4. The method according to claim 3, characterized in that, The identifier of the currently executing agent is obtained through one of the following methods: If the previous agent calls the routing tool and returns the identifier of a new agent, then that identifier is used as the identifier of the currently executing agent and written into the global object; If the previous agent did not call the routing tool and a default next agent is configured, then the identifier of the next agent is used as the identifier of the currently executing agent and written into the global object; If the previous agent did not call the routing tool and no default next agent was configured, the identifier of the output agent was used as the identifier of the currently executing agent and written into the global object.

5. The method according to claim 2, characterized in that, The global object also includes the maximum number of cooperative rounds among the agents, and the shared state variables also include the number of cooperative rounds among the agents. Before determining the identifier of the currently executing agent in the global object, the following is also included: Determine whether the number of collaborative rounds recorded in the shared state variable has reached the maximum number of collaborative rounds; if so, terminate the collaboration process.

6. The method according to claim 1, characterized in that, The process of scheduling one of the business intelligence agents to collaboratively execute a task based on shared state variables includes: If a business intelligence agent initiates multiple tool calls in a single interaction and parallel calls are not allowed, then one tool call should be selected.

7. The method according to claim 6, characterized in that, If a business intelligence agent initiates multiple tool calls in a single interaction and parallel calls are not allowed, then one tool call is selected, including: If a business intelligence agent initiates multiple tool calls in a single interaction and parallel calls are not allowed, then one tool call is selected based on the priority of each tool, which is determined according to the business logic dependencies between the tools.

8. The method according to claim 1, characterized in that, The output agent includes a first medical agent and a second medical agent. The process of scheduling the output agent among the plurality of agents generates and outputs a user-oriented response based on the processing result, including: The first medical intelligent agent is scheduled to determine the medical risks involved in the health management request. If the medical risks exceed the risk threshold, medical advice is output. If the medical risk does not exceed the risk threshold, the first medical agent is scheduled to retrieve relevant information and write the retrieval results into the shared state variable. The second medical agent is scheduled to read the retrieval results from the shared state variables, generate user-oriented response results, and output them.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, perform the method as described in any one of claims 1-8.

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 performs the method as described in any one of claims 1-8.

11. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-8.

Images