Design and construction method of human-in-the-loop multi-agent microservice system AgentInn

Abstract

The application discloses a kind of human in loop multi-agent microservice system AgentInn design and construction method, including human in loop control module, multi-agent cooperation module, dynamic capability expansion module and task arrangement module.Human in loop control module realizes the control, participation and observation of human to agent by starting confirmation, running intervention, abnormal recovery, human agent registration, cooperation routing and experience feedback;Multi-agent cooperation module realizes cooperation arrangement and load balancing by cooperation space, role load balancing and agent discovery;Dynamic capability expansion module supports on-demand creation and hierarchical exposure of tool service and intelligent service;Task arrangement module manages progress using Cycle-Sprint-Phase three-layer time abstraction, and realizes task flow by combining flow decision and context transmission.The application solves the problems of lack of human participation in multi-agent cooperation, high complexity of cooperation arrangement and limited capability expansion, and realizes multi-agent microservice cooperation.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, specifically to a design and construction method for AgentInn, a human-in-the-loop multi-agent microservice system. Background Technology

[0002] With the rapid development of large language model technology, agent systems based on large language models have been widely used in software engineering, data analysis, and automated operation and maintenance. Multi-agent collaborative systems significantly improve task processing efficiency by decomposing complex tasks and assigning them to multiple agents for parallel execution. However, existing multi-agent collaborative systems still face the following technical challenges in practical applications:

[0003] First, existing systems lack effective mechanisms for human intervention. Traditional automated systems employ a "preset rules + anomaly alarm" model. However, in agent systems driven by large language models, the uncertainty of the model's output makes it difficult to exhaustively list rules and preset anomaly thresholds. If relying solely on post-event alarms, it's difficult to roll back erroneous operations already performed by the agent; if relying solely on preset rules, the system cannot adapt to new scenarios. Multi-agent collaboration faces three types of risk of loss of control: decision-making loss of control manifests as agents choosing incorrect paths at critical branch points; collaboration loss of control manifests as multiple agents getting stuck in ineffective interaction loops; and evaluation loss of control manifests as the system failing to recognize declining execution quality.

[0004] Secondly, multi-agent collaborative orchestration is highly complex. In existing systems, agent instances are dynamically created and destroyed, and collaborators may come online or go offline at any time. Static service address lists cannot adapt to this dynamism, potentially leading to collaboration requests being routed to destroyed agents. Simultaneously, task scheduling typically disregards task semantics, treating all agents as equivalent nodes, resulting in random task assignment and inconsistent output quality. Furthermore, multi-agent parallel collaboration lacks effective organizational mechanisms, making it difficult to manage permission boundaries and integrate concurrent results.

[0005] Furthermore, the system's scalability is limited. Intelligent agents face two types of capability gaps when performing tasks: a gap in deterministic computational capabilities and a gap in non-deterministic analytical capabilities. Traditional solutions require agents to pre-configure all possible tools and collaborators, which limits the agent's adaptability and scalability, making it impossible to create new capability services on demand at runtime.

[0006] To address the aforementioned issues, the applicant proposes a design and construction method for AgentInn, a human-in-the-loop multi-agent microservice system. Summary of the Invention

[0007] The purpose of this invention is to provide a design and construction method for AgentInn, a human-in-the-loop multi-agent microservice system, to solve the problems in the prior art.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a design and construction method for a human-in-the-loop multi-agent microservice system, AgentInn, the system comprising:

[0009] The human-in-the-loop control module includes a start-up control unit, an operation intervention unit, an anomaly recovery unit, a human agent registration unit, a cooperative routing unit, and an experience feedback unit, which are used to enable humans to control, participate in, and observe the intelligent agent system.

[0010] The multi-agent collaboration module includes a collaboration space management unit, a role load balancing unit, and an agent discovery unit, which are used to realize the collaboration orchestration and load balancing among agents;

[0011] The dynamic capability extension module includes a tool service creation unit, an intelligent service lifecycle unit, and an exposure model hierarchy unit, which are used to realize the on-demand creation and discovery of intelligent agent capabilities;

[0012] The task orchestration module includes a task calendar scheduling unit, a flow decision unit, and a context passing unit, which are used to realize the timing planning and flow control of tasks.

[0013] Optionally, the person is in the loop control module:

[0014] The startup control unit is configured as follows: The Keeper Agent loads project planning skills to generate a task tree, analyzes task dependencies through the DAG engine, generates agent creation suggestions, and executes them after human review and approval;

[0015] The operation intervention unit is configured to: realize logical interruption through intervention state machine, and support pause, resume, cancel, inject, overwrite and upgrade operations;

[0016] The anomaly recovery unit is configured to automatically restart and restore the state of the faulty intelligent agent through heartbeat detection;

[0017] The human agent registration unit is configured to register humans as nodes equivalent to intelligent agents, possessing an agent identifier, capability profile, and state field.

[0018] The collaborative routing unit is configured to use a four-level routing strategy—direct specification, professional matching, broadcast push, and optimal selection—to progressively match human collaborative requests in a degraded manner.

[0019] The experience feedback unit is configured to persist corrective, approval, rejection, and suggestion experiences generated by human participation in collaboration and inject them into the context in a Lessons Learned format.

[0020] Optionally, in the multi-agent cooperation module:

[0021] The collaborative space management unit is configured to enable multi-agent collaboration by creating collaborative rooms and defining member roles and message routing strategies.

[0022] The role-based load balancing unit is configured to allocate tasks through a role classification system, a load scoring algorithm, and a semantic scheduling strategy.

[0023] The agent discovery unit is configured to classify agents by labels and inject agent information into the collaborative context using a multi-level injection strategy.

[0024] Optionally, in the collaborative space management unit: the collaborative room defines member roles including owner, admin, member, and observer; message routing strategies include on-mention, batch, keyword, and push-all; and concurrent result merging mechanisms include voting merging, best-choice merging, and fusion merging.

[0025] Optionally, in the role load balancing unit: the load scoring algorithm comprehensively calculates queue load, resource load and availability penalty, where queue load has the highest weight and resource load has a lower weight, adding 30 points to the busy state and 999 points to the offline state.

[0026] Optionally, in the dynamic capability extension module:

[0027] The tool service creation unit is configured to support the dynamic creation of deterministic computing services, creating services and registering them with the Consul service discovery center through template selection, construction, and startup processes.

[0028] The intelligent service lifecycle unit is configured to support the dynamic creation of nondeterministic reasoning services, manage the service lifecycle through runtime instances, and register them with the Keeper agent registry.

[0029] The exposure model hierarchy unit is configured to define four levels of visibility control policies: always, on-demand, skill-only, and discoverable, to implement hierarchical service exposure.

[0030] Optionally, in the task orchestration module:

[0031] The task calendar scheduling unit is configured to manage task progress using a three-layer time abstraction of Cycle-Sprint-Phase. Cycle is driven by manager decisions, Sprint is driven by threshold triggers, and Phase is driven automatically by completion events.

[0032] The workflow decision-making unit is configured to select one of three workflow actions—advance, transfer, or complete—based on the task execution result.

[0033] The context passing unit is configured to pass the task identifier, current stage, completed content, and pending content during task handover.

[0034] Optionally, in the context passing unit: the context message includes phase passing the title and description, input passing the source record, summary and file list, context passing the session and Sprint identifier, and task identifier taskId shared across agents to realize context passing and progress tracking.

[0035] Optionally, in the operation intervention unit, the intervention state machine includes four states: normal operation, pause and wait, resume execution, and cancel termination. The state transition is triggered by pause, resume, cancel, inject, override, and escalate requests.

[0036] Optionally, in the exposure model hierarchy unit: always model is globally visible, on-demand model is injected on demand, skill-only model is visible only when the skill is activated, and discoverable model can be discovered but is not automatically injected.

[0037] Beneficial effects: 1. Enables closed-loop control of intelligent agent systems by humans.

[0038] By employing a three-dimensional human-in-the-loop design, this invention treats humans as a controllable variable in the intelligent agent system. Relying on six units—initiation confirmation, operational intervention, anomaly recovery, human agent registration, collaborative routing, and experience feedback—it constructs a closed-loop mechanism that is "observable, controllable, and participatory." This invention effectively addresses the problems of decision-making out of control, collaboration out of control, and evaluation out of control in multi-agent collaboration, avoids error propagation caused by the uncertainty of large language models, and improves the security and reliability of the system.

[0039] 2. Reduce the complexity of multi-agent collaborative orchestration

[0040] Through a collaborative space management unit, a unified organizational unit is provided for multi-agent parallel collaboration, clearly defining member roles (owner, admin, member, observer) and message routing strategies (on-mention, batch, keyword, push-all), and supporting voting, selection of the best, or merging of concurrent results. Combined with role-based load balancing and agent discovery mechanisms, this invention achieves semantic task allocation and dynamic service discovery, solving problems such as static configuration failure, random task assignment, and ambiguous permission boundaries.

[0041] 3. Supports self-service dynamic expansion of system capabilities.

[0042] Through a dynamic capability extension module, this invention supports agents in creating tool services (deterministic computation) and intelligent services (non-deterministic reasoning) on ​​demand at runtime, and defines a four-level exposure model (always, on-demand, skill-only, discoverable). Compared to traditional solutions that require pre-configuration of all capabilities, this invention significantly improves the adaptability, scalability, and resource utilization efficiency of agents.

[0043] 4. Introduce semantic time abstraction to solve the problem of progress measurement failure.

[0044] By employing a three-layer time abstraction mechanism—Cycle, Sprint, and Phase—semantic time replaces real-world time as the dimension for progress measurement. Cycles are driven by manager decisions, Sprints by threshold triggers, and Phases by automatic completion events. This mechanism effectively adapts to the unpredictable nature of task execution durations in multi-agent systems, achieving stable task progress management and workflow control.

[0045] 5. Improve the efficiency and matching accuracy of human collaborative response.

[0046] Through a four-level collaborative routing strategy (direct assignment, specialized matching, broadcast push, and optimal selection), this invention can progressively downgrade matching based on task requirements and the state of the human agent, ensuring that collaborative requests are responded to in the shortest possible time. Simultaneously, the experience feedback unit persists human experiences such as corrections, approvals, rejections, and suggestions, and injects them into the context of subsequent tasks in a Lessons Learned format, enabling the agent to learn from historical decisions and continuously optimize the quality of collaboration.

[0047] 6. Ensure system stability and load balancing

[0048] Through a role-based load balancing unit, this invention comprehensively calculates queue load, resource load, and availability penalty to perform real-time scoring and optimal allocation of agents. This algorithm prioritizes reflecting the actual waiting time of agents, avoiding task backlog or resource idleness, and triggers the creation of new agents or human intervention when the load is too high or a failure occurs, thereby ensuring the overall throughput and stability of the system. Attached Figure Description

[0049] Figure 1 This is a three-dimensional overall architecture diagram of the human-in-the-loop system in an embodiment of the present invention;

[0050] Figure 2 This is a diagram of the multi-agent microservice system architecture in an embodiment of the present invention;

[0051] Figure 3 This is a flowchart illustrating the project initiation confirmation process in an embodiment of the present invention.

[0052] Figure 4 This is a state machine diagram of the operation intervention in an embodiment of the present invention;

[0053] Figure 5 This is a diagram illustrating the collaborative space message routing strategy in an embodiment of the present invention.

[0054] Figure 6 This is a flowchart of the role load balancing task allocation process in an embodiment of the present invention;

[0055] Figure 7 This is a flowchart illustrating the self-service creation process in an embodiment of the present invention.

[0056] Figure 8 This is a three-layer time progression diagram of the task calendar in this embodiment of the invention;

[0057] Figure 9 This is a flowchart illustrating the task flow decision-making process in an embodiment of the present invention.

[0058] Figure 10 This is a flowchart illustrating the collaborative interaction process between human intelligent agents in an embodiment of the present invention. Detailed Implementation

[0059] The preferred embodiments of the present invention are described below with reference to the accompanying drawings to make the technical content clearer and easier to understand. The present invention can be embodied in many different forms, and the scope of protection of the present invention is not limited to the embodiments mentioned herein.

[0060] This invention provides a design and construction method for AgentInn, a human-in-the-loop multi-agent microservice system. Its core idea is to treat humans as controllable variables within the intelligent agent system. Through a three-dimensional human-in-the-loop design, it enables human control, participation, and observation of the intelligent agent system. Simultaneously, by leveraging collaborative space mechanisms, self-service dynamic expansion mechanisms, and CSP time abstraction mechanisms, it addresses problems in existing multi-agent collaborative systems such as lack of human participation, high complexity in collaborative orchestration, limited capability expansion, and time measurement failures. The technical solution of this invention will be described in detail below, along with a specific system architecture and operational flow.

[0061] First, from the perspective of the overall system architecture, the human-in-the-loop multi-agent microservice system AgentInn constructed in this invention mainly includes four core modules: the human-in-the-loop control module, the multi-agent collaboration module, the dynamic capability expansion module, and the task orchestration module. These four modules cooperate with each other to form a controllable, participatory, and observable multi-agent collaboration closed loop. Specifically, the human-in-the-loop control module is responsible for implementing human control over the intelligent agent system's startup, operation intervention, anomaly recovery, human agent registration, collaborative routing, and experience feedback, forming the foundation for the security and controllability of the multi-agent system. The multi-agent collaboration module is responsible for managing the collaboration space between agents, role load balancing, and agent discovery, solving the organization and scheduling problems of parallel collaboration among multiple agents. The dynamic capability expansion module supports on-demand creation, lifecycle management, and hierarchical exposure of tool services and intelligent services, enabling agents to dynamically expand their capabilities. The task orchestration module, through task calendar scheduling, flow decision-making, and context passing, realizes the timing planning and flow control of complex tasks. The following sections will provide a detailed explanation of each module and its specific implementation.

[0062] In the human-in-the-loop control module, this invention designs a startup control unit, an operation intervention unit, an anomaly recovery unit, a human agent registration unit, a collaborative routing unit, and an experience feedback unit. The startup control unit introduces a human confirmation process before project initiation. Specifically, the Keeper Agent (a managerial agent in the system) loads a skill called "project-planning," which encapsulates relevant task planning tools and methods. The Keeper Agent generates a task tree by calling these tools. The task tree adopts a dynamic hierarchical design, including three levels: Epic, Story, and Task. Epic defines the boundaries of functional modules, Story describes user functional requirements, and Task represents specific technical work units. After the task tree is generated, DAGEngine (a directed acyclic graph engine) analyzes the dependencies between tasks and automatically identifies task groups that can be executed in parallel, thereby improving task execution efficiency. Based on this, DAGEngine also generates agent creation suggestions, which include agent ID, pre-assigned tasks, priorities, and estimated resources. The aforementioned task tree and agent creation suggestions are presented in the human review interface. Humans can intuitively view the task decomposition structure, dependencies, and agent allocation scheme, and choose to approve execution or refuse termination. Only after human approval will the system officially enter the task execution phase, thus ensuring the rationality and security of task planning from the outset.

[0063] The intervention unit is used to enable real-time human intervention in the behavior of the intelligent agent during task execution. This invention abandons the traditional API cancellation method and instead uses an intervention state machine to implement logical interruption. The intervention state machine includes four states: normal operation, paused waiting, resumed execution, and canceled termination. State transitions are triggered by six intervention requests: pause, resume, cancel, inject, override, and escalate. Specifically, when a human issues a pause request, the system changes the current task from a normal running state to a paused waiting state. The pipeline checks for intervention requests at the beginning of each iteration; if a pause request is detected, execution is blocked, and no new stages are scheduled. When a human issues a resume request, the system changes the state from paused waiting back to resumed execution, unblocking and continuing iteration. A cancel request can change any state to cancellation termination, and the system will terminate the session and clean up related resources. An inject request allows humans to inject a user message into the agent's context during normal operation, thereby guiding the agent's behavior. An override request allows humans to override the agent's tool call results; for example, if an agent calls a computing tool and returns an incorrect result, the human can directly provide the correct result for the agent to continue using. An escalate request triggers human takeover when the agent encounters a situation it cannot handle, transferring control of the current task to the human. These intervention mechanisms ensure that humans can intervene at any time during multi-agent collaboration, promptly correcting erroneous paths and preventing agents from falling into invalid loops or producing irreversible errors.

[0064] The anomaly recovery unit is responsible for detecting and handling faults during agent operation. Specifically, Keeper periodically queries the Consul service discovery center to obtain the health status of all agent containers in the cluster. Keeper aggregates this health information to construct a cluster health context and sends this context to Keeper AgentRuntime for analysis. Keeper AgentRuntime determines the appropriate recovery strategy based on the fault type and current system load. For single-container faults, the system automatically restarts the faulty container and retryes up to three times after restarting. If the retry still fails, human intervention is required to decide whether to continue trying or take other measures. For multi-container faults, the system determines whether it is a large-scale fault and adopts migration and reallocation strategies, migrating affected tasks to healthy containers for execution. For resource exhaustion, the system no longer automatically retryes but immediately escalates to human intervention, requesting additional resources or adjusting task load. Through this layered recovery strategy, this invention ensures the system's automatic recovery capability while retaining the final decision-making power of humans over critical anomalies.

[0065] The human agent registration unit elevates the human role to a node at the same level as the agent. In its implementation, users authenticate via WebSocket connection. Upon successful authentication, the system creates an AI agent instance for that user. The agent identifier uses the format "human-{user identifier}", giving it a unique and identifiable identity in the agent registry. This human agent instance also includes a capability profile and status fields. The capability profile includes tags such as role, specialty, and responsibility. For example, a role could be a general assistant, domain expert, approver, or administrator. The specialty tag describes the human's areas of expertise, such as backend development, data analysis, or security auditing. The responsibility tag indicates the typical task type the human performs in collaboration. The status fields include idle, responding, and offline, used for routing decisions. When a human agent is created, the system automatically registers it in Keeper's agent registry. When the human's status changes (e.g., from idle to responding, or from responding disconnected to offline), the system synchronously updates the status information in the registry. In this way, human agents and other agents share the same abstract structure from the system's perspective, allowing for unified scheduling, routing, and collaboration.

[0066] The collaborative routing unit is responsible for rationally allocating collaborative requests from agents to the most suitable human agents. This invention designs a four-level routing strategy, employing a progressively degraded matching approach. The first level is direct assignment, where the collaborative request explicitly specifies a particular user's identifier. The system first checks if the agent instance corresponding to that user is idle; if so, it directly assigns the request; otherwise, it proceeds to the next level. The second level is professional matching, where the system filters candidate agents based on the professional tags carried in the request, and then selects the agent with the shortest response time from all idle and professionally matched human agents for assignment. The third level is broadcast push, where if neither direct assignment nor professional matching finds a suitable human, the system pushes the collaborative request to all online human agents, and the first responding agent takes over the processing. The fourth level is optimal selection, where if there is still no response after broadcast push or if selection from historical records is necessary, the system selects an idle human agent instance with a history of responses and high-quality responses for assignment. Through this four-level progressively degraded strategy, this invention ensures accurate matching of high-priority collaborative requests while avoiding situations where requests remain unprocessed for extended periods due to inaccurate matching.

[0067] The experience feedback unit is used to persist various experiences generated during human collaboration. These experiences include four types: correction, approval, rejection, and suggestion. When humans correct the agent's erroneous behavior through intervention or takeover, the system automatically records the correction experience; when humans review and approve the agent's plan or result, the system records the approval experience; when humans reject the agent's proposal or solution, the system records the rejection experience; and when humans proactively provide optimization suggestions, the system records the suggestion experience. All experiences are stored in a structured format using Lessons Learned and are injected into the agent's context during subsequent task execution. There are three specific generation paths: Phase reflection generates phase prompts, where the system automatically generates a reflection summary as experience after each minimum subtask phase is completed; Task strategy generates task strategy, where the system summarizes reusable strategic experience based on the task execution process after the entire task is completed; and human feedback generates feedback records, which include the four types of experiences directly involving humans. Once these experiences are persisted, subsequent agents can retrieve and refer to previous human decisions when performing similar tasks, thereby avoiding repeating mistakes and improving collaboration efficiency and decision-making quality.

[0068] The multi-agent collaboration module will be described in detail below. This module includes a collaboration space management unit, a role load balancing unit, and an agent discovery unit. The collaboration space management unit achieves orderly collaboration among multiple agents by creating collaboration chambers. Each collaboration chamber is an independent space used to accommodate agents (including human agents) participating in a specific task or sub-task. The collaboration chamber defines member roles and message routing strategies. Member roles include four types: owner, admin, member, and observer. The owner has the final decision-making power, such as the right to adjudicate in case of disagreements and to decide whether to disband the collaboration chamber; the admin is responsible for managing the addition and removal of members and maintaining order within the collaboration chamber; the member is the core member who executes specific tasks and is responsible for completing the sub-tasks assigned to them; the observer only observes the collaboration process without participating in execution and is suitable for auditing, training, or monitoring scenarios. There are four message routing strategies: Under the on-mention strategy, the system only notifies members who are mentioned in the message, suitable for collaborative scenarios with clear task division and precise notification requirements; under the batch strategy, the system accumulates multiple messages to a certain threshold (e.g., 10 messages or waiting 30 seconds) before pushing them to all relevant members in batches, suitable for low-frequency collaboration scenarios to reduce interference; under the keyword strategy, the system matches messages for preset keywords, and if a match is found, pushes the message to all members, suitable for scenarios where important events need to be known by all members; under the push-all strategy, each message is immediately pushed to all members, suitable for high-frequency collaboration scenarios to ensure real-time performance. In addition, the collaboration space management unit also implements a concurrent result merging mechanism, including three strategies: vote (vote merging), best (best-choice merging), and merge (merge merging). The vote method tallies the results of multiple members and selects the solution supported by the majority, which is suitable for decision-making tasks; the best method selects the optimal solution according to predefined scoring indicators (such as accuracy, completeness, etc.), which is suitable for quality-priority tasks; the merge method integrates the key points of multiple members through a large language model to generate a comprehensive result, which is suitable for content integration tasks.

[0069] The role-based load balancing unit comprises a role classification system, a load scoring algorithm, and a semantic scheduling strategy. The role classification system employs a two-layer architecture: Meta roles and Functional roles. Meta roles identify the agent's technical type, such as a reasoning agent based on a large language model, a rule-based tool agent, or a human agent. This role is determined at agent creation and cannot be modified. Functional roles identify the agent's task capabilities, such as a coder, test executor, or documentation writer. This role can be switched as needed during runtime, giving the agent greater flexibility. The load scoring algorithm comprehensively calculates three parts: queue load, resource load, and availability penalty. The formula for calculating queue load is: pendingPhaseCount multiplied by avgPhaseDurationMs divided by 1000, where pendingPhaseCount represents the number of stages the agent is currently waiting to execute, and avgPhaseDurationMs represents the average execution time (in milliseconds) of the agent's historical execution stages. This value reflects the agent's actual waiting time and therefore has the highest weight in the algorithm. The resource load is calculated as: cpuUsage multiplied by 0.4 plus memoryUsage multiplied by 0.6, reflecting the CPU and memory usage of the host machine where the agent resides. This part has a low weight because modern containerized platforms can usually isolate resource impacts well. Availability penalties are applied based on the agent's current state: 30 points are added if the state is busy; 999 points are added if the state is offline (equivalent to infinity, i.e., unselectable). During task allocation, the system first filters candidate agents according to the required roles, then calculates a load score for each candidate agent, sorts them by score from smallest to largest (lower scores indicate more idle time), and selects the optimal agent. If the optimal agent's score is greater than 80 points, it indicates that all candidate agents are under high load, and the system returns a signal that "a new agent needs to be created"; otherwise, it returns the ID of the optimal agent for task allocation. Through this semantically aware load balancing mechanism, this invention achieves precise matching of tasks and agent capabilities, as well as dynamic balancing of the overall system load.

[0070] The agent discovery unit categorizes agents using tags, and the AgentDiscoveryPlugin injects agent information into the agent's system prompts. This plugin employs a multi-level injection strategy, divided into three levels. Level 1 injection uses a hierarchical display strategy: first, it displays an overview of tag categories, allowing the agent to understand the currently available agent types; then, it provides a tool called `find_services`, which the agent can call to further discover specific service details. Level 2 displays Known Agents, i.e., other agent roles and interaction counts recently collaborated with by the current agent, facilitating quick contact with familiar collaborators. Level 3 displays Recently Used Services, i.e., recently used services, their usage counts, and a list of tools, helping the agent quickly reuse frequently used services. Through this hierarchical injection, this invention avoids the problem of excessively long context caused by injecting all service information at once, while ensuring that the agent can efficiently discover the required services and collaborators on demand.

[0071] The dynamic capability extension module includes a tool service creation unit, an intelligent service lifecycle unit, and an exposure model hierarchy unit. The tool service creation unit supports the dynamic creation of deterministic computing services. In its implementation, the Skill provides the "how-to" instruction, defining a series of steps required to create a service (such as template selection, parameter configuration, and build commands), while the CustomServiceManager executes the build process. When an agent needs a deterministic computing service (e.g., data format conversion, mathematical calculation, regular expression matching), it triggers the corresponding Skill. The Skill guides the agent to select a service template (the system pre-sets several commonly used templates), and then the CustomServiceManager executes the build and startup process. After successful service creation, the CustomServiceManager registers it with the Consul service discovery center and writes the service's tools array (indicating a list of tools provided by the service) and tags (for categorization and retrieval) to Consul. Tool services are stateless, with a unified / api / process path as the call endpoint, allowing agents to invoke them at any time. The intelligent service lifecycle unit supports the dynamic creation of non-deterministic reasoning services, such as text generation, classification, and summarization services based on large language models. Unlike utility services, intelligent services require state management. Therefore, the service manager manages the service lifecycle, including startup, pause, resumption, and destruction, through the BunkClient Runtime. After creation, intelligent services are registered in the Keeper agent registry, with three state models: availability: online, busy, and offline. Service information is also injected into the collaboration context via the AgentDiscoveryPlugin, enabling other agents to discover and use the service. The exposure model hierarchy defines four visibility control strategies: In the always model, the service is globally visible and unconditionally injected into the context of all agents, suitable for common services such as logging and monitoring; in the on-demand model, the service is injected only when explicitly requested by an agent, suitable for temporarily created services; in the skill-only model, the service is injected only when a specific skill is triggered, suitable for services dedicated to that skill; and in the discoverable model, the service can be discovered (e.g., queried using the find_services tool) but is not automatically injected into the context, suitable for low-frequency services. Through these four-level strategies, this invention precisely controls the visibility and injection timing of service information, ensuring service accessibility while avoiding context redundancy.

[0072] The task orchestration module includes a task calendar scheduling unit, a flow decision unit, and a context passing unit. The task calendar scheduling unit adopts a three-layer time abstraction of Cycle-Sprint-Phase, replacing real-world time with semantic time as the progress measurement dimension. A Phase is the smallest subtask stage, an indivisible semantic boundary within the task definition, corresponding to one agent call. Each Phase definition includes a phase identifier, its associated task, blocking dependencies, executor, execution status, and execution result. Blocking dependencies are declared through the `blockedBy` field; the system automatically infers sequential and cross-task dependencies within the task, ensuring that Phases are executed in the correct order. A Sprint is an iteration cycle, a node that needs to be synchronized after multi-agent execution, triggered by a threshold. For example, when the completion rate of all Phases within a Sprint reaches 80%, it automatically advances to the next Sprint. A Cycle is the project cycle, manually advanced by the manager; for example, after completing a full functional iteration, the manager manually advances the Cycle to the next planning phase. Through these three layers of abstraction, this invention enables task progress management to no longer rely on unpredictable real-world time, but rather on a more reliable semantic indicator of task completion status. The workflow decision unit selects three workflow actions based on the task execution result: advance, hand over, and complete. If the current stage is successful and there is a subsequent stage, the system selects the advance action to continue executing the next stage; if the current stage is successful but requires the participation of other agents (e.g., the current agent does not possess the capabilities required for the subsequent stage), the system selects the handover action, transferring the task along with its context to the target agent; if the current stage is successful and there is no subsequent stage, the system selects the complete action, ending the task and cleaning up resources. The context delivery unit transmits a context message during task handover, which contains multiple fields. The phase field transmits the title and description of the current stage, enabling the receiving agent to quickly understand the task background; the input field transmits the source record (the inheritedFrom field facilitates tracing the task's origin), a summary (the content field reduces context length), and a file list (the artifacts field allows the receiving agent to directly access relevant files); the context field transmits the session identifier and sprint identifier, maintaining consistency in the timeline. It is important to note that the Phase identifier is generated locally rather than globally unique, but the task identifier (taskId) is shared across agents. Through the taskId, context passing and progress tracking can be achieved during the transition. Even if the task is handed over multiple times, all relevant agents can obtain a consistent global view.

[0073] The following examples illustrate the effectiveness of this invention. In the project launch confirmation scenario, a user initiates a new software development task through the front-end interface. The Keeper Agent automatically loads the project-planning Skill, generating a task tree containing the Epic "User Authentication Module," the Story "User Login Function," the Task "Implement Login Interface," and the Task "Write Login Test Cases." DAGEngine analysis reveals no dependency between the two Tasks and generates a suggestion for parallel execution. Human review deems the task decomposition reasonable and approves execution. The system then creates a backend development agent and a test agent based on the agent creation suggestion, executing the two Tasks in parallel, significantly shortening project launch time. In the runtime intervention scenario, suppose a data analysis agent, due to a misunderstanding of the database structure, generates an inefficient full-table scan query while executing an SQL query. After observing a slowdown in system response, a human sends an override request through the intervention interface, overriding the agent's tool call result and directly providing the optimized SQL statement. The agent receives the overridden query and continues execution, avoiding prolonged resource consumption. In the anomaly recovery scenario, an agent container crashes due to a memory leak. Keeper's heartbeat detection detects a failed container health check and immediately initiates an automatic restart process. After the container restarts, Keeper AgentRuntime restores the agent's previous state and unfinished tasks from persistent storage and continues execution. If three consecutive restarts fail, the system automatically escalates to human intervention, sending an alert to the administrator for investigation. In a human agent collaboration scenario, a code review agent encounters a security vulnerability that is difficult to identify and initiates a collaboration request. The collaboration routing unit first attempts to directly assign security expert Zhang San, but finds that Zhang San is offline, so it downgrades to professional matching, selecting Li Si, the human agent with the shortest response time from among the available agents with the security label, for assignment. After receiving the request, Li Si provides review opinions, and the experience feedback unit records this collaboration as a "correction" experience, which the agent will automatically refer to when similar vulnerabilities occur in the future. In a self-service dynamic scaling scenario, an agent needs to calculate the product of two complex matrices, but it does not have the ability to perform precise calculations of large numbers. The agent triggers the tool service to create a Skill, selects a high-precision mathematical calculation template, and CustomServiceManager builds and starts the service within seconds, registering it with Consul. After discovering the endpoint through service discovery, the agent calls the service to obtain the result. Once the task is completed, the tool service is automatically destroyed to release resources. In a task flow decision-making scenario, a front-end development agent completes the page layout phase. According to the task tree definition, the next phase is back-end interface integration testing, which requires the participation of a back-end development agent.The workflow decision unit identifies a capability mismatch, selects a handover action, and passes a context containing the completed front-end code, interface documentation, and session identifier to the back-end development agent. Upon receiving the context, the back-end development agent can begin integration testing directly without needing to relearn the project background. This scenario demonstrates that the invention can effectively perform functions such as human intervention control, collaborative routing selection, self-service creation and discovery, and task workflow decision-making in actual operation, achieving controllable, participatory, and observable multi-agent microservice collaboration.

[0074] In summary, the human-in-the-loop multi-agent microservice system AgentInn design and construction method provided by this invention effectively solves the problems of insufficient human participation, complex collaboration orchestration, limited capability expansion, and ineffective progress measurement in existing multi-agent collaborative systems through human-in-the-loop three-dimensional design, collaboration space mechanism, self-service dynamic expansion mechanism, and CSP time abstraction mechanism. Those skilled in the art should understand that the above specific embodiments are merely preferred embodiments of this invention and are not intended to limit the scope of protection of this invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for designing and constructing AgentInn, a human-in-the-loop multi-agent microservice system, characterized in that, The system includes: The human-in-the-loop control module includes a start-up control unit, an operation intervention unit, an anomaly recovery unit, a human agent registration unit, a cooperative routing unit, and an experience feedback unit, which are used to enable humans to control, participate in, and observe the intelligent agent system. The multi-agent collaboration module includes a collaboration space management unit, a role load balancing unit, and an agent discovery unit, which are used to realize the collaboration orchestration and load balancing among agents; The dynamic capability extension module includes a tool service creation unit, an intelligent service lifecycle unit, and an exposure model hierarchy unit, which are used to realize the on-demand creation and discovery of intelligent agent capabilities; The task orchestration module includes a task calendar scheduling unit, a flow decision unit, and a context passing unit, which are used to realize the timing planning and flow control of tasks.

2. The design and construction method of AgentInn, a human-in-the-loop multi-agent microservice system according to claim 1, is characterized in that, The person is in the loop control module: The startup control unit is configured as follows: The Keeper Agent loads project planning skills to generate a task tree, analyzes task dependencies through the DAG engine, generates agent creation suggestions, and executes them after human review and approval; The operation intervention unit is configured to: realize logical interruption through intervention state machine, and support pause, resume, cancel, inject, overwrite and upgrade operations; The anomaly recovery unit is configured to automatically restart and restore the state of the faulty intelligent agent through heartbeat detection; The human agent registration unit is configured to register humans as nodes equivalent to intelligent agents, possessing an agent identifier, capability profile, and state field. The collaborative routing unit is configured to use a four-level routing strategy—direct specification, professional matching, broadcast push, and optimal selection—to progressively match human collaborative requests in a degraded manner. The experience feedback unit is configured to persist corrective, approval, rejection, and suggestion experiences generated by human participation in collaboration and inject them into the context in a Lessons Learned format.

3. The design and construction method of AgentInn, a human-in-the-loop multi-agent microservice system according to claim 1, is characterized in that, In the multi-agent cooperation module: The collaborative space management unit is configured to enable multi-agent collaboration by creating collaborative rooms and defining member roles and message routing strategies. The role-based load balancing unit is configured to allocate tasks through a role classification system, a load scoring algorithm, and a semantic scheduling strategy. The agent discovery unit is configured to classify agents by labels and inject agent information into the collaborative context using a multi-level injection strategy.

4. The design and construction method of AgentInn, a human-in-the-loop multi-agent microservice system according to claim 3, is characterized in that, In the collaborative space management unit: the collaborative room defines member roles including owner, admin, member, and observer; message routing strategies include on-mention, batch, keyword, and push-all; and concurrent result merging mechanisms include voting merging, best-choice merging, and fusion merging.

5. The design and construction method of AgentInn, a human-in-the-loop multi-agent microservice system according to claim 3, is characterized in that, In the role-based load balancing unit: the load scoring algorithm comprehensively calculates queue load, resource load, and availability penalty, with queue load having the highest weight and resource load having a lower weight. The busy state adds 30 points, and the offline state adds 999 points.

6. The design and construction method of AgentInn, a human-in-the-loop multi-agent microservice system according to claim 1, is characterized in that, In the dynamic capability extension module: The tool service creation unit is configured to support the dynamic creation of deterministic computing services, creating services and registering them with the Consul service discovery center through template selection, construction, and startup processes. The intelligent service lifecycle unit is configured to support the dynamic creation of nondeterministic reasoning services, manage the service lifecycle through runtime instances, and register them with the Keeper agent registry. The exposure model hierarchy unit is configured to define four levels of visibility control policies: always, on-demand, skill-only, and discoverable, to implement hierarchical service exposure.

7. The design and construction method of AgentInn, a human-in-the-loop multi-agent microservice system according to claim 1, is characterized in that, In the task orchestration module: The task calendar scheduling unit is configured to manage task progress using a three-layer time abstraction of Cycle-Sprint-Phase. Cycle is driven by manager decisions, Sprint is driven by threshold triggers, and Phase is driven automatically by completion events. The workflow decision unit is configured to select one of three workflow actions—advance, transfer, or complete—based on the task execution result. The context passing unit is configured to pass the task identifier, current stage, completed content, and pending content during task handover.

8. The method for designing and constructing AgentInn, a human-in-the-loop multi-agent microservice system according to claim 7, is characterized in that... In the context passing unit: the context message includes phase passing the title and description, input passing the source record, summary and file list, context passing the session and sprint identifier, and task identifier taskId shared across agents to realize context passing and progress tracking.

9. The design and construction method of AgentInn, a human-in-the-loop multi-agent microservice system according to claim 2, is characterized in that, In the operation intervention unit, the intervention state machine includes four states: normal operation, pause and wait, resume execution, and cancel termination. The state transition is triggered by pause, resume, cancel, inject, override, and escalate requests.

10. The design and construction method of AgentInn, a human-in-the-loop multi-agent microservice system according to claim 6, is characterized in that, In the exposure model hierarchy unit: the always model is globally visible, the on-demand model is injected on demand, the skill-only model is visible only when the skill is activated, and the discoverable model can be discovered but is not automatically injected.

Images