Method and apparatus for multi-role intelligent agent collaborative scheduling and high-concurrency expansion in campus service systems

Abstract

This invention discloses a method and apparatus for multi-role intelligent agent collaborative scheduling and high-concurrency expansion in a campus service system, relating to the fields of artificial intelligence and educational informatization. The invention employs a single-agent runtime architecture combined with a dynamic loading architecture of multi-role prompt words and skill combinations. User requests are distributed through a multi-signal fusion intent routing algorithm. Structured boundary messages are inserted during role switching to preserve the complete context, achieving differentiated protocols for web-based human-computer confirmation and automatic switching on the IM side. A student-level and session-level dual-layer isolation mechanism is constructed to support multi-historical session management. Multi-machine horizontal expansion is achieved by decoupling the stateless API layer from the inference worker nodes and combining a message queue with student ID as the partition key. This invention significantly reduces the cost of calling large language models and improves the system's concurrent service capabilities and the contextual coherence of role switching.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and educational informatization, and in particular to a method for collaborative scheduling and high-concurrency expansion of multi-role intelligent agents in campus service systems. Background Technology

[0002] With the rapid development of large language model technology, universities are gradually applying AI agents to student services to cover multi-dimensional service needs such as academic tutoring, campus life, psychological and emotional support, and career planning. Existing campus intelligent service solutions mainly have the following shortcomings:

[0003] First, multi-agent architectures suffer from high deployment costs and poor contextual coherence. Mainstream multi-agent architectures employ a coordinator-executor pattern, deploying independent agent processes for each service domain. Each user request requires message transmission across multiple processes, easily leading to contextual information loss. Unstructured information such as students' emotional states and historical preferences cannot be fully transmitted. Concurrent operation of multiple agents significantly increases the number of API calls for large language models, with token consumption being 3 to 5 times that of single-agent solutions for the same user scale. At the same time, multi-process orchestration places high demands on server resources, resulting in high deployment and maintenance complexity. Furthermore, there is a noticeable "switching gap" when switching between roles, and context cannot be seamlessly inherited.

[0004] Secondly, single-agent solutions lack specialized capabilities. Existing single-agent campus dialogue systems mostly use a single, general prompt word configuration. Although deployment is simple, they cannot activate specialized skill subsets according to different service scenarios. For academic tutoring, they cannot implement guided teaching; for emotional appeals, they cannot switch to an empathy-first response strategy; and for employment consultations, they cannot activate professional analysis tools. Furthermore, registering all skill tools can easily lead to a high rate of accidental tool selection and unstable response quality.

[0005] Third, the session isolation capability is insufficient under multi-user concurrency. When a single service node serves multiple students at the same time, the conversation history of different students is easily overwritten. When the concurrency exceeds the threshold, the serialization processing scheme based on memory locks causes the system response latency to rise sharply, triggering a large number of service unavailability errors. At the same time, the existing solution lacks a two-layer isolation mechanism of "student-session" for educational scenarios, and multiple historical sessions of the same student lack effective context boundary management.

[0006] Fourth, the single-machine architecture has scalability bottlenecks. Existing solutions are mostly single-machine, single-process architectures, where the agent's running state is coupled to the process's memory, making stateless transformation difficult and hindering horizontal scaling across multiple instances. When the data layer uses file-based storage, multi-process writes pose a risk of lock contention, and multi-machine deployments lack a concurrent write coordination mechanism. Furthermore, the message queue is not partitioned at the student level, meaning that consecutive messages from the same student may be processed out of order by different worker nodes, leading to context disorder.

[0007] Currently, most of the publicly disclosed related patents adopt multi-process independent intelligent agent solutions, which do not solve the problem of context coherence; educational AI patents mostly focus on a single field and do not involve a joint solution for dynamic switching of roles across multiple fields and session isolation; message queue partitioning technology for general scenarios does not combine AI inference work nodes to achieve joint optimization of orderly processing by student partitions and context cold and hot loading. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method and apparatus for multi-role intelligent agent collaborative scheduling and high-concurrency multi-machine expansion in a campus service system, solving the problems of poor context coherence, high calling cost, insufficient session isolation, and weak expansion capability in the existing solutions.

[0009] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0010] A method and apparatus for multi-role intelligent agent collaborative scheduling and high-concurrency multi-machine expansion in a campus service system is proposed to solve the problems of poor context coherence, high calling cost, insufficient session isolation, and weak expansion capability in existing solutions.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] On one hand, this invention provides a campus multi-role intelligent agent cooperative scheduling method, including the following steps:

[0013] Receive natural language messages sent by student users through access channels and obtain the current service role identifier and corresponding session context;

[0014] Perform multi-signal fusion intent routing analysis on the natural language message, detect explicit role switching instructions, strong semantic pattern matching signals, and domain keyword scoring signals in order of priority, and output role switching proposals;

[0015] A differentiated role switching protocol is executed based on the access channel type: If it is a Web access channel, a role switching proposal is returned to the user, and the role switching is executed after the user confirms; if it is an IM access channel, the role switching is executed automatically and a switching prompt is output to the user.

[0016] When switching roles, structured boundary messages are inserted into the dialogue history sequence to preserve the complete dialogue context. Only the currently active role's personality prompts and exclusive skill tools subset are replaced, and the session identifier remains unchanged before and after the switch.

[0017] The system dynamically assembles system prompts by recalling memory content related to the current request semantics from a pre-defined five-layer memory system.

[0018] Invoke the large language model configuration bound to the target role to perform inference, generate and return the response result.

[0019] Furthermore, each service role is defined by a triplet consisting of role personality cue words, a subset of exclusive skill tools, and a large language model configuration; different roles correspond to different interaction styles, sets of available tools, and parameters of the large language model.

[0020] Furthermore, the intent routing analysis of the multi-signal fusion specifically includes:

[0021] Prioritize detecting explicit character switching commands, including commands that directly reference character names and commands that contain character handover action words. If a match is detected, output a high-confidence character switching suggestion directly.

[0022] When no explicit instruction is hit, strong semantic pattern matching is performed. Each service role has a corresponding domain of strong semantic regular expression patterns. If a single pattern is hit, a high-confidence role switching proposal is output.

[0023] When a strong semantic pattern is not hit or there is a conflict between multiple roles, domain keyword scoring is performed to calculate the keyword hit score for each role. When the highest score meets the threshold and the leading difference between the highest score and the second highest score meets the threshold, a role switching proposal with the corresponding confidence level is output.

[0024] Furthermore, the five-layer memory system, from bottom to top, consists of the school identity kernel layer, the student explicit memo layer, the student growth record layer, the semester scenario memory layer, and the daily dialogue log layer; the dynamic assembly system prompts are specifically: splicing the global identity kernel, student growth record summary, relevant scenario memory fragments, student explicit memos, and current role personality prompts according to priority.

[0025] Furthermore, the method also includes a session two-layer isolation step:

[0026] Student-level isolation: Maintain the student session manager and cache the current student's conversation context when switching service students; if the target student has a cached snapshot, restore the context directly; otherwise, load the history from persistent storage to reconstruct the context.

[0027] Session-level isolation: Each session is assigned a unique identifier, supporting the creation of new sessions, restoration of specified historical sessions, and session hiding operations. Multiple sessions of the same student are managed independently through identifiers.

[0028] On the other hand, the present invention provides a high-concurrency multi-machine expansion method for campus intelligent agents, which is used in conjunction with the above-mentioned collaborative scheduling method, and includes the following steps:

[0029] The stateless API layer receives user dialogue requests, completes identity authentication and student identity binding, and then constructs task payloads and delivers them to the message queue.

[0030] The message queue uses the student identifier as the partition key for message routing, ensuring that messages from the same student are processed by the same inference worker node in the order they are sent, and messages from different students are distributed to different inference worker nodes in parallel.

[0031] After consuming the task, the inference worker node loads the target student's conversation history and memory file from the persistent data layer to reconstruct the agent's runtime context;

[0032] The inference worker node performs dialogue inference to generate response results, writes the results back to the persistent data layer, and notifies the stateless API layer to return a response to the user through a publish / subscribe mechanism.

[0033] Furthermore, the persistent data layer adopts a dual-track storage architecture, supporting the switching between a lightweight database in a single-machine environment and a relational database plus object storage in a distributed environment. The backend storage type is configured through environment variables to achieve smooth architecture migration.

[0034] Furthermore, the number of inference worker nodes dynamically expands or shrinks based on the message queue depth; each inference worker node contains an independent agent instance, and the running state is not shared between nodes.

[0035] Furthermore, the present invention provides a campus multi-role intelligent agent collaborative scheduling device, comprising:

[0036] The access module is used to receive natural language messages sent by student users through different access channels and obtain the current service role identifier and session context;

[0037] The intent routing module is used to perform multi-signal fusion intent routing analysis on natural language messages. It detects explicit role switching instructions, strong semantic pattern matching signals, and domain keyword scoring signals in order of priority, and outputs role switching proposals.

[0038] The role switching module is used to execute differentiated role switching protocols based on the access channel type. When switching, structured boundary messages are inserted into the dialogue history sequence to preserve the complete dialogue context and only replace the role personality prompts and exclusive skill tools subset.

[0039] The memory retrieval module is used to retrieve memory content related to the semantics of the current request from the five-layer memory system on demand, and dynamically assemble system prompt words;

[0040] The inference execution module is used to call the large language model configuration bound to the target role to perform inference, generate and return response results.

[0041] Furthermore, the present invention provides a high-concurrency multi-machine expansion device for campus intelligent agents, comprising:

[0042] The stateless API module is used to receive user dialogue requests, complete identity authentication and student identity binding, construct task payloads and deliver them to the message queue, and return inference results to the user.

[0043] The message queue module is used to route messages using the student identifier as the partition key, ensuring that messages from the same student are processed sequentially and messages from different students are distributed in parallel.

[0044] The inference worker node pool contains several independent inference worker nodes, which are used to consume message queue tasks, load session history and memory files to reconstruct the context, execute dialogue inference, and write the results back to the persistence module.

[0045] The persistence module is used to store student identity information, session index, dialogue messages, skill call logs, and student memory files;

[0046] The publish / subscribe module is used to publish a completion event to the stateless API module after inference is completed, triggering the return of the response result.

[0047] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0048] 1. Significantly improved contextual coherence. The architecture adopts a single-agent runtime plus multi-role dynamic loading, replacing the traditional multi-process independent agent solution. When switching roles, the complete dialogue history is preserved, and students' historical preferences, emotional states, and other information are inherited with zero loss, avoiding context loss when passing across processes.

[0049] 2. Significantly reduced API costs for large language models. By using a hierarchical memory on-demand recall mechanism, the number of system prompt tokens per round is controlled within the range of 8K to 20K, reducing token consumption by 40% to 60% compared to the full memory injection solution; combined with a dual-model routing strategy that binds different roles to different ability level models, the overall cost is reduced by 30% to 57% compared to a single high-ability model solution.

[0050] 3. Enhanced multi-user concurrent service capabilities. By employing a dual-layer isolation mechanism at the student and session levels, session overlay issues are eliminated. Combined with asynchronous message queue processing, the number of concurrent students that a single node can serve has increased from a single path to 10 to 50 paths.

[0051] 4. The architecture is linearly scalable. The message queue mechanism, which uses the student ID as the partition key, ensures the order of messages for the same student while supporting parallel processing of requests from different students, achieving near-linear horizontal scaling from a single machine to multiple machines.

[0052] 5. Strong channel adaptability. Human-computer confirmation protocols and automatic switching protocols are designed for both the web and IM platforms, taking into account user operating habits and experience needs in different usage scenarios. Attached Figure Description

[0053] Figure 1 This is a diagram of the overall system architecture of the present invention;

[0054] Figure 2 This is a flowchart of the multi-signal fusion intention routing algorithm of the present invention;

[0055] Figure 3 This is a flowchart of the single-agent multi-role collaborative scheduling process of the present invention;

[0056] Figure 4 This is a diagram of the five-layer memory architecture of the present invention;

[0057] Figure 5 This is a schematic diagram of the two-layer isolation mechanism for student conversations in this invention;

[0058] Figure 6 This is a diagram of the high-concurrency multi-machine deployment architecture of this invention;

[0059] Figure 7 This is a schematic diagram illustrating the context retention for role switching in this invention. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] See Figure 1 The overall system architecture of this invention is divided into five layers from top to bottom: the access layer, the stateless API layer, the message queue layer, the inference worker node pool, and the data persistence layer. The access layer supports access from multiple channels such as WeChat Bot, QQ Bot, and web browsers; the stateless API layer is responsible for identity authentication, intent routing, session management, and task delivery, and supports horizontal scaling with multiple replicas; the message queue layer uses student IDs as partition keys to ensure sequential processing of messages from the same student; the inference worker node pool consists of multiple independent agent instances, responsible for context loading, inference execution, and result writing back; the data persistence layer includes Redis, PostgreSQL, and object storage, responsible for caching, structured data storage, and unstructured memory file storage, respectively.

[0062] I. Single-agent multi-role cooperative scheduling architecture

[0063] This invention adopts an architecture of "single agent runtime + multi-role prompt words - dynamic loading of skill combinations" to replace the traditional multi-process independent agent solution.

[0064] The system predefines N service roles; in this embodiment, N=6, including one general manager role and five domain roles, corresponding to service domains such as academic tutoring, campus life, psychological and emotional support, and career planning. Each role is defined by a triplet structure:

[0065] Role_i=(P_persona_i,S_skill_i,L_LLM_config_i)

[0066] Among them, P_persona_i is the character personality cue word, which defines the character's identity, interaction style, service boundaries and professional methodology in Markdown format. For example, the academic tutoring character adopts the Socratic guidance teaching strategy, and the emotional character adopts the empathy-first response strategy. S_skill_i is a subset of the character's exclusive skill tools, which is a JSON Schema collection of tools that the character can call. Different characters only activate tools in their corresponding fields to avoid accidental triggering of tools due to full registration. L_LLM_config_i is the large language model configuration bound to the character, which supports routing simple dialogue characters to low-cost fast models and complex reasoning characters to high-capability models.

[0067] Each time a user request is processed, the system dynamically assembles system prompts using a layered injection strategy:

[0068] Final_System_Prompt=Layer_L0⊕Layer_L2_summary⊕Layer_L3_relevant⊕Layer_L1_notes⊕P_persona_i

[0069] Where ⊕ indicates concatenation by priority, Layer_L0 is the global identity kernel, defining the school name and overall service positioning, shared by all roles; Layer_L2_summary is the student's growth profile summary, containing structured facts such as major, year, and learning goals; Layer_L3_relevant is the chapter in the current semester's contextual memory that is semantically relevant to this request; Layer_L1_notes are explicit memos that the student actively requests to remember; and P_persona_i is the personality cue word for the currently active role. This mechanism controls the number of system cue word tokens in a single round to between 8K and 20K, avoiding the context window exhaustion problem caused by full memory injection.

[0070] When a role switch is performed, the system does not reset the agent's dialogue history. Instead, it inserts a structured boundary message into the history sequence, in the format of [System-Role Switch: Switching from {Old Role} to {New Role}, with the following continuing from {New Role}]. The new role inherits the complete dialogue history, and only updates the role personality prompts and exclusive skill tool subsets in the system prompts. The session identifier remains unchanged before and after the switch, ensuring that the multi-role switching path forms a complete session timeline in the database.

[0071] II. Multi-signal fusion intentional routing algorithm

[0072] This invention employs a multi-signal fusion intent routing algorithm to distribute user requests to corresponding service roles. The algorithm fuses three types of signals and processes them sequentially according to priority, as follows: Figure 2 As shown.

[0073] The first type is the explicit switching instruction, which has the highest priority. The system maintains two types of explicit switching modes: one is the direct reference mode, where the user message precisely matches the role name, such as "@Employment Mentor", using regular expression matching; the other is the instruction-based switching mode, where the user message contains explicit role transfer action words, such as "Switch to Employment Mentor", using regular expression matching. When an explicit switching instruction is detected, a switch to the target role is directly proposed, the confidence level is marked as high, and subsequent signal analysis is skipped.

[0074] The second category is strong semantic pattern matching, with lower priority. The system predefines several strong semantic regular expression patterns for each domain role, describing highly discriminative user intent structures. For example, the employment role corresponds to patterns like "resume," "mock interview," and "campus recruitment," while the learning role corresponds to patterns like "this question" and "homework." A single strong semantic pattern match triggers a switching proposal for the corresponding role, with high confidence. If multiple roles' strong semantic patterns match simultaneously, the role with the most matching patterns is selected, and pattern conflicts are recorded for subsequent processing.

[0075] The third category is domain keyword scoring, which serves as the basic signal. The system maintains a domain keyword dictionary for each domain role and performs parallel scoring on user input across multiple roles. The score calculation formula is score_i=count(w∈keyword_dict_i:w∈normalize(input)). The routing decision rules are as follows: if the highest score is greater than or equal to the minimum threshold and the lead difference between the highest score and the second highest score is greater than or equal to the lead threshold, then a switch to the highest-scoring role is proposed; if there is a unique scoring role with a score greater than or equal to 1, a switch is proposed with medium confidence; if all role scores are below the threshold or the lead difference is insufficient, no switch is triggered, and the current role handles the process directly.

[0076] Based on the routing results, the system implements differentiated interaction protocols for different access channels:

[0077] The web application uses a human-computer confirmation protocol: the routing result is returned to the front end via REST API, the front end renders a confirmation prompt bar, the user confirms and then sends a role switch request, and then executes the actual dialogue request;

[0078] The IM client uses an automatic switching protocol: routing results directly trigger role switching without user confirmation, and the system appends a switching prompt text to the beginning of the reply; when the user sends a short confirmation message, the system uses a verbal handover detection mechanism to determine whether the previous reply contained a handover intention, and if so, it automatically completes the handover and continues to process user requests.

[0079] III. Two-layer isolation mechanism for student conversations

[0080] This invention constructs a two-layer isolation mechanism of "student-level isolation + session-level isolation" to solve the context pollution problem when multiple users access the site concurrently. The structure is as follows: Figure 5 As shown.

[0081] The first layer is student-level isolation. The system maintains a student session manager, which contains the current service student ID, a student snapshot cache dictionary, and a mapping table between students and session IDs. When an API request switches to the target student, the manager first performs a snapshot save, serializing the current student's agent dialogue history and the underlying large language model client history into a deep copy snapshot and storing it in the cache. If the target student exists in the cache, its snapshot is directly loaded to restore the context; if it does not exist, the student's dialogue records from the last N days are loaded from persistent storage to reconstruct the context. During the loading process, the system performs format validation and repair on the historical records to avoid errors in the large language model API calls due to format incompatibility.

[0082] The second layer is session-level isolation. Building upon student-level isolation, the system assigns unique UUID identifiers to sessions of the same student at different time periods, enabling independent management of multiple sessions. Three session operations are supported: creating a new dialogue, clearing the agent context and assigning a new session UUID, and writing it to the session index table; resuming a session, loading all message records of the corresponding session based on the specified UUID, and reconstructing the agent context; and hiding a session, marking it as hidden without affecting data persistence, only removing it from the front-end view.

[0083] Four- or five-layer memory system

[0084] This invention implements a five-layer memory system for campus scenarios, with the structure as follows: Figure 4 As shown, the characteristics of each layer are as follows:

[0085] hierarchy Semantics Storage format life cycle Update mechanism L0 University Identity Core Markdown Permanent System deployment configuration L1 Student explicit memo Markdown Maintenance on demand Students actively trigger the "memorization" process. L2 Student growth record Markdown 4 years of accumulation Important events are written in real time and archived at the end of the semester. L3 Semester Scene Memory Markdown 1 semester Automatically updated weekly, with complete archiving at the end of the semester. L4 Daily Conversation Log NDJSON append+PostgreSQL 30-day rolling compression Each round of dialogue is updated in real time.

[0086] The memory compression and archiving mechanism includes: after the daily L4 logs exceed 30 days, they are merged and compressed into weekly summaries by a scheduled task to reduce the amount of subsequent reading; at the end of each semester, semester archiving is triggered to archive the current L3 memory as a whole, extract important events and write them into the L2 growth profile, and initialize blank L3 memories for the new semester; the L2 growth profile uses versioned entries with timestamps to support historical tracing in scenarios such as goal changes.

[0087] The memory retrieval uses a priority-based algorithm to control the total number of tokens injected in a single operation: first, the L0 and L1 layers are fully loaded; then, the L2 layer summary is loaded; next, the L3 current semester summary and chapters related to the current query are loaded; then, the L4 summary of conversations from the last 7 days is loaded; finally, the current character's personality cue words are concatenated. For the selection of relevant chapters in L3, a basic keyword matching scheme or an upgraded scheme using vectorized cosine similarity retrieval can be used.

[0088] V. High-concurrency multi-machine expansion architecture

[0089] This invention designs an extended architecture that supports smooth evolution from a single-machine, single-process architecture to a multi-machine, distributed architecture, decoupling stateful agent reasoning from stateless API access. The deployment architecture is as follows: Figure 6 As shown.

[0090] Stateless API layer

[0091] The API layer does not store any agent inference state; it is responsible for user authentication and student identity binding, request parameter validation and standardization, task delivery, and task status query. Multiple API instances are connected in parallel through a load balancer, achieving horizontal scaling of the API layer.

[0092] Message queues partitioned by student ID

[0093] The message queue supports implementations such as RedisStream, RabbitMQ, and Kafka. Using `student_id` as the partition key, it ensures that multiple messages from the same student are processed strictly in order by the same inference worker node, while messages from different students can be distributed to different worker nodes in parallel. The message payload includes information such as student ID, session UUID, role index, user message, access channel, and task ID.

[0094] Inference worker node pool

[0095] Each inference worker node process contains an independent agent instance, capable of context loading, inference execution, and result writing back: loading the target student's conversation history and memory files from the database and object storage; calling the large language model to perform inference and tool distribution; writing the response results to the database and publishing completion events via the Redis publish / subscribe mechanism. The number of inference worker nodes can be dynamically scaled up or down based on message queue depth, and horizontal autoscaling is supported in a container orchestration environment.

[0096] Dual-track storage evolution strategy

[0097] The system employs a unified data access layer, controlling backend storage types via environment variables. It is compatible with both standalone SQLite and distributed PostgreSQL, enabling a smooth migration from the demonstration phase to production without code modifications. Specifically, PostgreSQL stores structured data such as student binding information, session indexes, dialogue messages, and skill call logs; object storage or shared file volumes store student memory files; and Redis stores short-lived session routing information, task status caching, and streaming result publish / subscribe.

[0098] Example 1: Multi-role Collaborative Dialogue on the Web

[0099] In this example, a student interacts with the administrator via a web interface, asking a question related to resume editing. The system triggers intent routing and switches to the career mentor role, as follows: Figure 3 As shown, the specific steps are as follows:

[0100] Step S1: The API layer receives a request sent by the student (student_id="S00001") via POST / api / chat. The message content is "Please check if there are any problems with my resume". The current role index is 0, which is the role of the general manager.

[0101] Step S2: The system calls the intent routing module to analyze the message: it detects explicit switching instructions, but there is no matching content in the message; it performs strong semantic pattern matching, and the message matches the strong semantic pattern "resume" of the employment role, determining that the target role is an employment mentor with a high confidence level; it generates a switching proposal, which includes the target role index, switching reason, and confidence level.

[0102] Step S3: The API layer returns a route proposal to the front end through the interface. The front end renders a confirmation prompt bar at the top of the dialog area, displaying the reason for switching and two operation buttons: "Switch + Send" and "Reply by Manager".

[0103] Step S4: When the user clicks the "Switch + Send" button, the front end first sends a role switching request, the system switches the large language model configuration, injects the employment mentor's personality prompt words and exclusive skill subset, and inserts boundary messages into the dialogue history; then the user message is sent and processed by the employment mentor role.

[0104] Step S5: The reasoning work node performs dynamic prompt word assembly: Load the L0 school identity kernel, load the L2 growth profile summary of S00001, load the employment-related chapters in L3, load the employment mentor personality prompt words, assemble the complete system prompt words, call the corresponding high-ability model to perform reasoning, and activate the resume analysis tool.

[0105] Step S6: The inference result is streamed back to the front end in NDJSON format and rendered in real time. After the inference is completed, the complete response is written to the database dialogue message table and associated with the corresponding student ID, session UUID and role index.

[0106] Example 2: Automatic Role Switching on the IM Client

[0107] In this example, a student sends an emotional message to the "General Manager" role via WeChat. The system automatically switches to the "Emotional Assistant" role. The specific steps are as follows:

[0108] Step S1: The IM adaptation layer receives the Webhook event from WeChat Bot, parses the student_id from the binding table using OpenID, and confirms that the access channel is IM.

[0109] Step S2: The system calls the IM automatic switching function and performs multi-signal fusion routing: the message "I'm under so much pressure and can't sleep" hits the strong semantic pattern of the emotional role and returns a switching proposal with the target role being the emotional assistant and a high confidence level.

[0110] Step S3: The IM client directly executes automatic switching. The system switches to the Emotional Assistant role, loads exclusive prompts and skill subsets for the Emotional Assistant, and excludes irrelevant tools such as those related to academic affairs and employment to avoid accidental triggering.

[0111] Step S4: The large language model generates a reply using the Emotion Assistant personality, and automatically appends the prompt text "[Switched to Emotion Assistant]" to the beginning of the reply.

[0112] Step S5: If the student's next message is a short confirmation, the system calls the verbal handover detection module to determine whether the previous reply contained words indicating a handover intention. If so, the system continues processing with the previous substantive message as input; otherwise, it generates a short response based on the current confirmation.

[0113] Example 3: Session Routing in High-Concurrency Multi-Machine Deployment

[0114] This example illustrates a scenario where thousands of students are online simultaneously during the start of the school year. The system processes concurrent requests on three inference worker node servers. The specific steps are as follows:

[0115] Step S1: Student A and Student B simultaneously send messages via the web interface, and the requests are distributed to the API instance cluster by the load balancer.

[0116] Step S2: After each API instance completes identity authentication, it constructs a task payload and delivers it to the RedisStream message queue. The message queue uses student_id as the partition key. Student A's message is routed to partition 1 and processed by Worker-1, while Student B's message is routed to partition 2 and processed by Worker-2.

[0117] Step S3: After Worker-1 consumes Student A's task, it loads the corresponding session information and recent dialogue messages from the database to reconstruct the agent context; loads Student A's L0 to L3 memory files from object storage; performs inference and generates a response.

[0118] Step S4: If student A sends a second message during the processing of the first message, the message will be routed to the same partition because the partition key is the same. It will be queued in the queue of Worker-1 and will be executed sequentially after the first message is processed, ensuring that the messages are strictly ordered.

[0119] Step S5: After the inference results are written to the database, the completion event is published via Redis publish / subscribe. The API layer subscribes to the event and pushes the response to the student's web client via SSE stream.

[0120] The above description is only for illustrating the concept and specific implementation of the present invention. Those skilled in the art can modify, supplement, or substitute the specific embodiments in a similar manner without departing from the concept or scope of the claims, and all such modifications and additions should fall within the protection scope of the present invention.

Claims

1. A method for collaborative scheduling of multi-role intelligent agents in a campus, characterized in that, Includes the following steps: Receive natural language messages sent by student users through access channels and obtain the current service role identifier and corresponding session context; Perform multi-signal fusion intent routing analysis on the natural language message, detect explicit role switching instructions, strong semantic pattern matching signals, and domain keyword scoring signals in order of priority, and output role switching proposals; A differentiated role switching protocol is executed based on the access channel type: If it is a Web access channel, a role switching proposal is returned to the user, and the role switching is executed after the user confirms it; If it is an IM access channel, automatically perform role switching and output a switching prompt to the user; When switching roles, structured boundary messages are inserted into the dialogue history sequence to preserve the complete dialogue context. Only the currently active role's personality prompts and exclusive skill tools subset are replaced, and the session identifier remains unchanged before and after the switch. The system dynamically assembles system prompts by recalling memory content related to the current request semantics from a pre-defined five-layer memory system. Invoke the large language model configuration bound to the target role to perform inference, generate and return the response result.

2. The campus multi-role intelligent agent cooperative scheduling method according to claim 1, characterized in that, Each service role is defined by a triplet consisting of a role personality cue words, a subset of exclusive skill tools, and a large language model configuration; different roles correspond to different interaction styles, sets of available tools, and parameters of the large language model.

3. The campus multi-role intelligent agent cooperative scheduling method according to claim 1, characterized in that, The intent routing analysis of the multi-signal fusion specifically includes: Prioritize detecting explicit character switching commands, including commands that directly reference character names and commands that contain character handover action words. If a match is detected, output a high-confidence character switching suggestion directly. When no explicit instruction is hit, strong semantic pattern matching is performed. Each service role has a corresponding domain of strong semantic regular expression patterns. If a single pattern is hit, a high-confidence role switching proposal is output. When a strong semantic pattern is not hit or there is a conflict between multiple roles, domain keyword scoring is performed to calculate the keyword hit score for each role. When the highest score meets the threshold and the leading difference between the highest score and the second highest score meets the threshold, a role switching proposal with the corresponding confidence level is output.

4. The campus multi-role intelligent agent cooperative scheduling method according to claim 1, characterized in that, The five-layer memory system, from bottom to top, consists of the school identity kernel layer, the student explicit memo layer, the student growth record layer, the semester situational memory layer, and the daily dialogue log layer. The dynamic assembly system prompts are specifically: splicing the global identity kernel, student growth record summary, relevant situational memory fragments, student explicit memos, and current role personality prompts according to priority.

5. The campus multi-role intelligent agent cooperative scheduling method according to claim 1, characterized in that, It also includes a two-layer session isolation step: Student-level isolation: Maintain the student session manager and cache the current student's conversation context when switching service students; If a cached snapshot of the target student exists, the context is restored directly; otherwise, the context is reconstructed by loading historical records from persistent storage. Session-level isolation: Each session is assigned a unique identifier, supporting the creation of new sessions, restoration of specified historical sessions, and session hiding operations. Multiple sessions of the same student are managed independently through identifiers.

6. A high-concurrency multi-machine expansion method for campus intelligent agents, used in conjunction with the collaborative scheduling method described in claim 1, characterized in that, Includes the following steps: The stateless API layer receives user dialogue requests, completes identity authentication and student identity binding, constructs task payloads and delivers them to the message queue; The message queue uses the student identifier as the partition key for message routing, ensuring that messages from the same student are processed by the same inference worker node in the order they are sent, and messages from different students are distributed to different inference worker nodes in parallel. After consuming the task, the inference worker node loads the target student's conversation history and memory file from the persistent data layer to reconstruct the agent's runtime context; The inference worker node performs dialogue inference to generate response results, writes the results back to the persistent data layer, and notifies the stateless API layer to return a response to the user through a publish / subscribe mechanism.

7. The high-concurrency multi-machine expansion method for campus intelligent agents according to claim 6, characterized in that, The persistent data layer adopts a dual-track storage architecture, which supports switching between a lightweight database in a single-machine environment and a relational database plus object storage in a distributed environment. The backend storage type is configured through environment variables to achieve smooth architecture migration.

8. The high-concurrency multi-machine expansion method for campus intelligent agents according to claim 6, characterized in that, The number of inference worker nodes dynamically expands or shrinks based on the message queue depth; each inference worker node contains an independent agent instance, and nodes do not share runtime states.

9. A campus multi-role intelligent agent collaborative scheduling device, characterized in that, include: The access module is used to receive natural language messages sent by student users through different access channels and obtain the current service role identifier and session context; The intent routing module is used to perform multi-signal fusion intent routing analysis on natural language messages. It detects explicit role switching instructions, strong semantic pattern matching signals, and domain keyword scoring signals in order of priority, and outputs role switching proposals. The role switching module is used to execute differentiated role switching protocols based on the access channel type. When switching, structured boundary messages are inserted into the dialogue history sequence to preserve the complete dialogue context and only replace the role personality prompts and exclusive skill tools subset. The memory retrieval module is used to retrieve memory content related to the semantics of the current request from the five-layer memory system on demand, and dynamically assemble system prompt words; The inference execution module is used to call the large language model configuration bound to the target role to perform inference, generate and return response results.

10. A high-concurrency multi-machine expansion device for campus intelligent agents, characterized in that, include: The stateless API module is used to receive user dialogue requests, complete identity authentication and student identity binding, construct task payloads and deliver them to the message queue, and return inference results to the user. The message queue module is used to route messages using the student identifier as the partition key, ensuring that messages from the same student are processed sequentially and messages from different students are distributed in parallel. The inference worker node pool contains several independent inference worker nodes, which are used to consume message queue tasks, load session history and memory files to reconstruct the context, execute dialogue inference, and write the results back to the persistence module. The persistence module is used to store student identity information, session index, dialogue messages, skill call logs, and student memory files; The publish / subscribe module is used to publish a completion event to the stateless API module after inference is completed, triggering the return of the response result.

Images