A method and system for multi-path scheduling and sub-agent generation in intelligent agency

By employing a multi-path scheduling mechanism and an intelligent agent system, the security and efficiency issues of the intelligent agent system are resolved. This enables secure and efficient intelligent path selection and hierarchical caching optimization, dynamic isolation and hybrid path execution, thereby improving the system's security and execution efficiency.

CN122285221APending Publication Date: 2026-06-26HANGZHOU MAGIC BYTE TECHNOLOGY CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
HANGZHOU MAGIC BYTE TECHNOLOGY CO LTD
Filing Date
2026-04-01
Publication Date
2026-06-26

Smart Images

  • Figure CN122285221A_ABST
    Figure CN122285221A_ABST
Patent Text Reader

Abstract

This invention discloses a multi-path scheduling and sub-agent generation method and system for intelligent agents, belonging to the field of artificial intelligence. The method provides multiple mutually exclusive scheduling paths: a collaborative agent generation path distributes tasks to agents in the same process or terminal split-screen sessions through a delegation mechanism; a sub-agent derivation path achieves efficient sub-agent creation through context inheritance and hint cache sharing optimization; and a general agent scheduling path achieves flexible scheduling through rule filtering and definition matching. This invention implements hint cache sharing optimization for derivation paths, and by standardizing the processing of tool execution results in parent agent messages, it enables API request prefixes to achieve cache hits, significantly reducing the response time of the first token. It also supports features such as execution environment isolation, recursive derivation protection, and automatic background operation, providing an efficient and flexible scheduling solution for multi-agent collaboration of complex AI tasks.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, specifically to task scheduling and sub-agent generation technology for multi-agent systems, and particularly to an intelligent agent scheduling method and system that supports security verification, intelligent path selection, and hierarchical caching optimization. Background Technology

[0002] With the rapid development of large language model technology, intelligent agent (AI agent) systems based on large language models are able to perform increasingly complex tasks. When dealing with complex tasks, a single agent is often insufficient, and it is necessary to decompose the task into sub-tasks, which are then completed collaboratively by multiple sub-agents.

[0003] The main problems with existing technologies include: First, the creation of sub-agents lacks a secure verification mechanism; once the scheduling system code is leaked, attackers can easily create malicious sub-agents. Second, context inheritance is inefficient; existing technologies typically use a full copy method, resulting in huge token consumption. Third, scheduling path selection is statically fixed and cannot be dynamically optimized according to task characteristics. Fourth, the caching mechanism is simple, only supporting exact matching and unable to utilize caching of similar results. Fifth, the execution isolation level is fixed and cannot be flexibly adjusted according to task sensitivity.

[0004] Therefore, there is an urgent need for a more secure, efficient, and flexible intelligent agent scheduling solution that can support security verification, intelligent path selection, hierarchical caching optimization, and dynamic isolation. Summary of the Invention

[0005] This invention provides a method and system for multi-path scheduling and sub-agent generation in intelligent agents, belonging to the field of artificial intelligence technology, specifically involving task scheduling and sub-agent generation technology in multi-agent systems. This invention supports multiple mutually exclusive scheduling paths and provides security verification, intelligent path selection, and hierarchical caching optimization mechanisms, offering a secure, efficient, and flexible scheduling solution for multi-agent collaboration in complex AI tasks.

[0006] The core of this invention lies in providing three mutually exclusive scheduling path selection mechanisms: when the system receives scheduling parameters, it selects a target scheduling path from multiple mutually exclusive scheduling paths based on parameter type and task characteristics. The first scheduling path is a collaborative agent generation path. When the scheduling parameters include an agent identifier parameter, the system distributes the task to a collaborative agent through a delegation mechanism. This collaborative agent includes agents within the same process or agent instances in a terminal split-screen session, enabling various backend detection and adaptations such as in-process agent reuse, terminal multiplexer split-screen, and terminal emulator split-screen. The second scheduling path is a sub-agent derivation path. When the derivation conditions are met, the system generates a sub-agent based on the parent agent's context information. This generation process includes inheriting the parent agent's dialogue context, normalizing the tool execution results in the context to generate a standardized representation, and optimizing the prompt cache sharing based on this standardized representation. The third scheduling path is a general agent scheduling path. When the scheduling parameters include an agent type parameter, the system determines the target agent definition through rule filtering and definition matching, and executes the scheduling after the dependent services are ready. For missing dependent services such as the MCP server, the system supports a polling waiting mechanism until the service is ready.

[0007] The second scheduling path of this invention also integrates a security verification mechanism to prevent unauthorized use after code leakage. Before generating a sub-agent, the system first authenticates the parent agent using methods such as digital signature verification, token verification, or biometric verification. Upon successful verification, the system generates a time-sensitive execution credential containing a task signature, parent agent identity identifier, and expiration timestamp, stored in encrypted form to prevent tampering. The system embeds the execution credential into the sub-agent's initialization context. Before performing any operation, the sub-agent must verify the validity of the execution credential, checking for expiration, task signature matching, and parent agent legitimacy. If verification fails, the sub-agent refuses execution and returns a security error, without revealing the specific reason for the failure to prevent information leakage attacks. The execution credential is designed for one-time use, automatically expiring after the sub-agent completes, preventing replay attacks.

[0008] This invention employs a dynamic digest algorithm for standardizing tool execution results. The system first identifies the characteristics of the tool execution results, including tool type, output size, and execution duration. Based on these characteristics, the system uses a dynamic digest algorithm to generate standardized placeholders. These placeholders contain a tool identifier hash, execution metadata, and a content digest. The dynamic digest algorithm ensures that the same tool type and similar output characteristics generate the same placeholder prefix, achieving cache hits while preserving other metadata of the message. The content digest can use a hash algorithm, compression algorithm, or feature extraction algorithm, striking a balance between digest size and information retention.

[0009] The scheduling path selection of this invention achieves automated optimization based on an intelligent selection algorithm. The system first extracts the feature vector of the current task, including estimated execution time, file operation frequency, tool call complexity, and historical resource consumption patterns. Based on this feature vector and historical performance data, the system predicts the execution efficiency and resource consumption of each scheduling path using a machine learning model, which can employ algorithms such as decision trees, random forests, or neural networks. The system automatically selects the scheduling path with the optimal predicted efficiency and dynamically adjusts the path selection strategy based on real-time performance indicators during task execution, achieving runtime optimization.

[0010] The cache sharing optimization of this invention adopts a layered caching mechanism, including three collaborative caching layers. The L1 caching layer uses fixed placeholders to achieve precise byte-level matching, suitable for identical requests, with the highest caching efficiency upon a hit. The L2 caching layer uses semantic similarity matching, calculating vector similarity for similar but not identical tool results. When the similarity exceeds a threshold, cached content is partially reused, requiring maintenance of the vector representation of the tool results. The L3 caching layer predicts which sub-proxies might be called subsequently based on task type, pre-warming cached content and optimizing the response time of subsequent requests.

[0011] This invention's context inheritance supports homomorphic encryption to protect the security of sensitive information. The system uses a homomorphic encryption algorithm to encrypt sensitive content in the parent agent's messages. Homomorphic encryption allows computation on the ciphertext, and the decrypted result is identical to the plaintext computation. The child agent processes the encrypted content in the encrypted state, performing content-based operations, such as comparison operations on the ciphertext, without decryption. After the child agent returns the result, it is decrypted by the parent agent or the authorized party; only the authorized party holding the private key can decrypt the result. For non-sensitive content, the system still uses ordinary placeholders to reduce computational overhead.

[0012] The recursive derivation protection of this invention employs a dynamic control mechanism, which is more intelligent and flexible compared to fixed depth limits. The system monitors system resource utilization in real time, including CPU load, memory usage, and the number of active sub-agents; these indicators reflect the current state of the system. The system dynamically adjusts the maximum allowed recursion depth based on resource utilization, allowing deeper recursion when resources are sufficient and tightening the limit to prevent resource exhaustion when resources are scarce. The system also identifies recursive call patterns, distinguishing between legitimate recursive algorithm patterns (such as divide-and-conquer, backtracking, and other algorithms with clear termination conditions and convergence characteristics) and erroneous loop call patterns. The depth limit is relaxed for legitimate recursive algorithm patterns, while erroneous loop patterns are immediately terminated and an error is returned.

[0013] This invention also includes a blockchain auditing mechanism to ensure the immutability and traceability of operation records. Each sub-agent creation and key operation generates an audit record, including the operation type, timestamp, operator identity hash, and operation content summary. The audit record is written to a Merkle tree structure; any modification to the record will result in a change to the root hash. The system periodically anchors the Merkle tree root hash to the blockchain, leveraging the blockchain's immutability to ensure the security of the root hash. Even if the auditing system is attacked, the anchored record cannot be tampered with. The system supports verifying the authenticity of any historical operation based on Merkle proofs.

[0014] The execution environment isolation of this invention employs a dynamic sandbox mechanism, achieving a balance between security and performance. The system first assesses the sensitivity level of the task, considering factors such as the task's origin, the data types involved, the resources requiring access, and historical security records. An isolation strategy is selected based on the sensitivity level: for low-sensitivity tasks, lightweight workspace isolation such as Git Worktree is used; for high-sensitivity tasks, full container isolation is initiated, including network isolation and system call filtering. During task execution, the system dynamically adjusts the isolation level based on actual behavior; if abnormal behavior is detected, the isolation level is immediately escalated or the task is terminated.

[0015] This invention also supports a hybrid path execution mechanism, allowing dynamic switching of scheduling paths within the same task. During task execution, the system monitors the execution status and performance metrics. When it detects that the current path is unsuitable for continued execution (e.g., execution time exceeds expectations, resource consumption is abnormal, unsupported operations are encountered, or performance is severely degraded), it dynamically switches to another scheduling path. During path switching, the system maintains context continuity, ensuring that information such as the state of sub-agents, intermediate results, and execution progress is not lost.

[0016] This invention also provides a multi-path scheduling and sub-agent generation system for intelligent agents, comprising: a path selection module configured to select one of multiple scheduling paths based on input parameters; a collaborative agent module configured to implement multiple backend detections such as same-process agent, terminal multiplexer screen splitting, and terminal emulator screen splitting; a sub-agent derivation module configured to implement context inheritance, cache sharing optimization, and recursive derivation protection; a general agent scheduling module configured to implement rule filtering and dependent service polling; and a security verification module configured to implement identity verification, credential generation, and verification. The security verification module includes an identity authenticator, a credential generator, a credential verifier, and a credential destroyer. The sub-agent derivation module includes a dynamic digest generator, a hierarchical cache manager, and a homomorphic encryptor. The system also includes an intelligent selection module, a dynamic recursive controller, a blockchain auditing module, a dynamic sandbox module, and a hybrid path execution module. Beneficial effects

[0017] Compared with existing technologies, this invention has the following advantages: First, the security verification mechanism prevents unauthorized use after code leakage, and ensures that only legitimate parent proxies can create child proxies through time-sensitive credentials. Second, the dynamic digest algorithm provides more contextual information while maintaining cache hit rate. Third, intelligent path selection automatically optimizes based on task characteristics, improving execution efficiency. Fourth, the hierarchical caching mechanism fully utilizes similar results, further improving caching efficiency. Fifth, homomorphic encryption protects sensitive context, preventing plaintext information from being obtained even if the child proxy is compromised. Sixth, dynamic recursive control prevents resource exhaustion while allowing legitimate recursive algorithms. Seventh, blockchain auditing provides non-repudiable operation records. Eighth, the dynamic sandbox achieves a balance between security and performance. Attached Figure Description

[0018] Figure 1 The overall flowchart of the multi-path scheduling method illustrates the selection logic of three mutually exclusive scheduling paths (first, second, and third scheduling paths). Key decision conditions are highlighted: whether a proxy identifier parameter is provided (first path), whether the sub-proxy derivation condition is met (second path), and whether a proxy type parameter is provided (third path). Example data flow demonstrates the execution methods of different paths.

[0019] Figure 2 : Diagram of collaborative agent scheduling path (first scheduling path). Agent backend detection process (same-process agent, terminal multiplexer screen splitting, terminal emulator screen splitting); task delegation mechanism, including priority sequence detection; response object structure, including execution environment information.

[0020] Figure 3 Detailed process of sub-agent derivation path (second scheduling path): Context inheritance mechanism (inheritance of parent agent message list); Normalization of tool execution results (standardized placeholder replacement); The suggestion is to optimize cache sharing (ensuring cache hits by maintaining consistency in API request prefixes); Recursive derivation protection mechanism (source identifier detection, derivation placeholder scanning).

[0021] Figure 4 Execution logic of the general agent scheduling path (third scheduling path): Proxy definition matching process (rule filtering, definition matching); Depends on a service polling and waiting mechanism (availability detection, timeout control); The scheduling and execution process (task distribution depends on the service being ready).

[0022] Figure 5This diagram illustrates the execution lifecycle management process. It shows: synchronous execution mode (execution within the caller's context); automatic background processing mechanism (timeout threshold detection, asynchronous transition); and asynchronous lifecycle management (cancellation of controllers, independent execution environment).

[0023] Figure 6 : Execution environment isolation mechanism architecture diagram.

[0024] Figure 7 System architecture diagram.

[0025] Core module division: Path selection module (scheduling logic); Collaborative proxy module (same-process proxy, terminal split-screen management); Sub-delegation modules (context inheritance, cache optimization); General proxy scheduling module (rule filtering, dependency management); Execution lifecycle module (synchronous / asynchronous execution management); Environmental isolation module (workspace management); Inter-module interaction relationships (data flow, control flow).

[0026] Figure 8 The example demonstrates the optimization of cache sharing. Comparison of API requests before and after standardized placeholder replacement; Illustration of the effect of improved cache hit rate; Comparison of first token response time optimizations. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0028] One specific implementation case: The implementation of an intelligent agent multi-path scheduling system.

[0029] This embodiment describes in detail a specific implementation of the present invention, demonstrating the complete workflow of multi-path scheduling and sub-agent generation.

[0030] I. System Overall Architecture.

[0031] The system in this embodiment adopts a modular design, with the core scheduling engine responsible for receiving external requests and distributing them to different execution paths. The system defines three mutually exclusive scheduling paths, which are automatically identified and routed based on parameter types.

[0032] II. First scheduling path: Collaborator creation path.

[0033] When the scheduling request contains team identifier parameters and member name parameters, the system enters the first scheduling path, namely the collaborator creation path.

[0034] Parameter definition: `group_identifier`: A unique identifier string for the team; `member_alias`: Member name string; Core processing flow: The system calls the collaborator creation function `createCollaborator()` to perform the following steps: 1. Backend Environment Detection Sequence: The system detects available backend environments in priority order. First, it checks whether in-process collaborator storage is supported (using the asynchronous local storage mechanism `AsyncContextStorage`). If supported, the current process's context environment is reused directly. If not supported, the system then checks whether the split-screen functionality of terminal multiplexers (such as `screenMultiplexer`) and terminal emulators (such as `terminalEmulator`) is available.

[0035] 2. Nested Creation Protection: The system checks whether the collaborator creation process is already underway. If a nested creation request is detected, it will be rejected to ensure that the team list maintains a flat structure and avoid resource management chaos caused by hierarchical nesting.

[0036] 3. Session Identifier Generation: The system generates a unique session identifier for subsequent collaborator status tracking and communication management.

[0037] 4. Output result encapsulation: After successful creation, a `CollaboratorCreationResult` structure is returned, which contains information such as session identifier, backend type, and creation timestamp.

[0038] Pseudocode example: ``` function createCollaborator(groupIdentifier, memberAlias): / / Check nested creation protection if isInCollaboratorCreationProcess(): raise NestedCreationError("Nested collaborator creation is prohibited") / / Detect backend environment by priority backendType = detectAvailableBackend() if backendType == "IN_PROCESS": collaborator = createInProcessCollaborator(groupIdentifier,memberAlias) else if backendType == "SCREEN_MULTIPLEXER": collaborator = createScreenSessionCollaborator(groupIdentifier,memberAlias) else if backendType == "TERMINAL_EMULATOR": collaborator = createTerminalSplitCollaborator(groupIdentifier,memberAlias) else: raise NoBackendAvailableError("No backend environment available") return CollaboratorCreationResult( sessionId = collaborator.sessionId, backendType = backendType, createdAt = getCurrentTimestamp() ) ```.

[0039] III. Second scheduling path: Derived sub-agent path.

[0040] When the experimental feature switch is enabled and no agent type parameter is specified in the scheduling request, the system enters the second scheduling path, namely the derived sub-agent path.

[0041] Parameter definition: `experiment_enabled`: Boolean value for switching experimental features; `agent_category`: Agent type parameter (optional); Core processing flow: The system call to the sub-agent derived function `deriveSubAgent()` performs the following steps: 1. Security Verification Mechanism: Before deriving a sub-agent, the system first verifies the identity of the parent agent. Upon successful verification, a time-sensitive execution token `ExecutionToken` is generated. This token contains a task digest hash, the parent agent's identity identifier, and an expiration timestamp. The token is generated using a cryptographic signature to ensure it cannot be tampered with.

[0042] 2. Context Inheritance Handling: The system calls the context construction function `constructDerivedContext()` to inherit the complete dialog context of the parent agent. The key optimization lies in the normalization of tool execution results: the system iterates through all tool call results in the parent agent's messages and replaces the original tool result content with the normalized placeholder string `[Derivation in Progress - Background Processing]`.

[0043] 3. Hint Cache Sharing Optimization: The normalized context message has the same byte prefix as the original message (except for the tool result part), which allows API requests to reuse existing hint caches, significantly reducing the generation time of the first token.

[0044] 4. Precise inheritance of tool definitions: The system setting `inheritToolDefinitions: true` parameter ensures that the tool definitions of the child agent are completely consistent with those of the parent agent, avoiding execution errors caused by differences in tool definitions.

[0045] 5. Recursive Derivation Protection: The system detects recursive derivation through a dual mechanism: First, it checks the request source identifier `requestOrigin`, and if the identifier is a derived source, it refuses to execute; second, it scans the message history, and if a derivation marker is detected, it triggers the protection mechanism.

[0046] Pseudocode example: ``` function deriveSubAgent(parentContext, taskDescription): / / Security verification if not validateParentIdentity(parentContext): raise AuthenticationError("Parent proxy authentication failed") executionToken = generateExecutionToken( taskHash = computeHash(taskDescription), parentId = parentContext.agentId, expiryTimestamp = getCurrentTimestamp() + TOKEN_VALIDITY_PERIOD ) / / Recursive protection check if detectRecursiveDerivation(parentContext): raise RecursiveDerivationError("Recursive derivation detected, blocked") / / Construct derived context derivedMessages = constructDerivedContext(parentContext.messageHistory) / / Create sub-agent configuration subAgentConfig = SubAgentConfiguration( context = derivedMessages, executionToken = executionToken, inheritToolDefinitions = true, isolationWorkspace = createIsolationWorkspace() ) return launchSubAgent(subAgentConfig) function constructDerivedContext(messageHistory): derivedMessages = [] for message in messageHistory: if message.containsToolResult(): / / Replace tool results with normalized placeholders normalizedMessage = message.copyWithNormalizedContent( placeholder = "[Derivation in progress - Background processing]" ) derivedMessages.append(normalizedMessage) else: derivedMessages.append(message) return derivedMessages ```.

[0047] IV. Third Scheduling Path: General Agent Scheduling Path When the proxy type parameter is explicitly specified in the scheduling request, the system enters the third scheduling path, namely the general proxy scheduling path.

[0048] Parameter definition: `agent_category`: Agent type identifier string Core processing flow: The system calls the generic scheduling function `scheduleGenericAgent()` to perform the following steps: 1. Rule Filtering: The system checks whether a request should be rejected based on a predefined list of rejection rules. Rejection rules include a blacklist of proxy types and detection of sensitive words in the task content.

[0049] 2. Definition Matching: The system searches the agent definition registry for an agent definition `AgentDefinition` that matches the specified agent type. This definition contains information such as the agent's capability description, tool configuration, and execution parameters.

[0050] 3. Dependency Service Readiness Check: The system checks whether the dependent services (such as the model context protocol server) required for agent execution are ready. If the service is not ready, the system starts a polling wait mechanism, with a maximum wait time of 30 seconds by default. During the wait period, the system checks the service status at fixed intervals (such as every second).

[0051] 4. Scheduling and Execution: Once the dependent services are ready, the system creates a proxy instance based on the proxy definition and executes the task.

[0052] Pseudocode example: ``` function scheduleGenericAgent(agentCategory, taskInput): / / Rule filtering if matchesRejectionRules(agentCategory, taskInput): raise RejectionError("Request does not match the rejection rule") / / Define match agentDefinition = resolveAgentDefinition(agentCategory) if agentDefinition is null: raise DefinitionNotFoundError("No delegate definition found") / / Dependency service readiness check for dependency in agentDefinition.dependencies: if not isServiceReady(dependency): waitResult = pollServiceReady( serviceName = dependency, maxWaitSeconds = 30, pollInterval = 1 ) if not waitResult: Raise a DependencyNotReadyError("Dependency service is not ready") / / Create and execute the agent agentInstance = createAgentInstance(agentDefinition) return agentInstance.execute(taskInput) ```.

[0053] V. Implement lifecycle management.

[0054] The system supports both synchronous and asynchronous execution lifecycle modes.

[0055] Synchronous execution mode: The system executes the proxy task in the calling thread. Supports automatic background execution: When the execution time exceeds a threshold (default 120 seconds), the system automatically switches the task to background execution to avoid blocking the caller for an extended period. After being processed in the background, a background task identifier is returned, which the caller can use to query the task status and results. Asynchronous execution mode: The system immediately returns to the asynchronous launch state `async_launched`; Create a separate cancellation controller `TaskAbortController` for each asynchronous task; The caller can abort an ongoing asynchronous task by canceling the controller.

[0056] Workspace isolation: The system creates an independent isolated workspace for each derived sub-agent, using a lightweight working tree mechanism (such as `isolationWorkspace`) to provide file system-level isolation, ensuring that file operations between different sub-agents do not interfere with each other.

[0057] Pseudocode example: ``` function executeWithLifecycle(agentInstance, taskInput,executionMode): if executionMode == "SYNCHRONOUS": / / Execute synchronously, supports automatic background processing abortController = createAbortController() backgroundThreshold = 120 / / seconds result = executeWithTimeout( agentInstance, taskInput, abortController, onTimeout = () => { / / Automatic background process after timeout taskId = moveToBackground(agentInstance, abortController) return BackgroundExecutionResult(taskId = taskId) }, timeout = backgroundThreshold ) return result else if executionMode == "ASYNCHRONOUS": / / Asynchronous execution, independent cancellation control abortController = createAbortController() taskId = generateTaskId() launchAsyncTask( taskId = taskId, agentInstance = agentInstance, taskInput = taskInput, abortController = abortController ) return AsyncLaunchResult( status = "async_launched", taskId = taskId, abortController = abortController ) ```.

[0058] VI. Implementation of Tiered Caching Mechanism The system implements a three-layer caching mechanism to optimize the efficiency of prompt caching.

[0059] L1 cache layer (precise cache): The hash value of the request content is used as the cache key; Achieve precise byte-level matching; Cache the complete response result.

[0060] L2 cache layer (semantic cache): Generate a semantic vector representation of the request content; Calculate the semantic similarity with historical requests; When the similarity exceeds a threshold (e.g., 0.95), some cached content is reused.

[0061] L3 cache layer (predictive cache): Predict the sub-agents that may be needed later based on the task type; Preheat the shared context cache; Reduce response latency for subsequent requests.

[0062] Pseudocode example: ``` class TieredCacheManager: def __init__(self): self.l1Cache = ExactMatchCache() self.l2Cache = SemanticSimilarityCache() self.l3Cache = PredictivePreloadCache() def getOrCompute(self, requestContent, computeFunction): / / L1 exact match cacheKey = computeHash(requestContent) if self.l1Cache.contains(cacheKey): return self.l1Cache.get(cacheKey) / / L2 semantic similarity matching requestVector = generateSemanticVector(requestContent) similarEntry = self.l2Cache.findSimilar(requestVector, threshold =0.95) if similarEntry is not null: result = partialReuse(similarEntry, requestContent) self.l1Cache.set(cacheKey, result) return result / / L3 prediction preloading (executed asynchronously) predictedTasks = predictSubsequentTasks(requestContent) self.l3Cache.preload(predictedTasks) / / Calculate the new result result = computeFunction(requestContent) self.l1Cache.set(cacheKey, result) self.l2Cache.set(requestVector, result) return result ```.

[0063] VII. Implementation of security token verification.

[0064] The system implements a complete security token generation and verification mechanism.

[0065] Token generation: ``` function generateExecutionToken(taskHash, parentId, expiryTimestamp): tokenPayload = { "task_hash": taskHash, "parent_id": parentId, "expiry": expiryTimestamp, "nonce": generateRandomNonce() } serializedPayload = serializeToJson(tokenPayload) signature = signWithPrivateKey(serializedPayload) return ExecutionToken( payload = tokenPayload, signature = signature, createdAt = getCurrentTimestamp() ) ```.

[0066] Token verification: ``` function validateExecutionToken(token, currentTaskHash): / / Check expiration time if getCurrentTimestamp() > token.payload.expiry: return ValidationResult(expired = true, error = "Token has expired") / / Check task hash matching if token.payload.task_hash != currentTaskHash: return ValidationResult(invalid = true, error = "Task mismatch") / / Verify signature if not verifySignature(token.payload, token.signature): return ValidationResult(invalid = true, error = "Signature verification failed") / / Check if a one-time token has been used. if isTokenUsed(token): return ValidationResult(invalid = true, error = "Token has been used") / / Mark token as used markTokenAsUsed(token) return ValidationResult(valid = true) ```.

[0067] 8. Dynamic sandbox isolation is implemented.

[0068] The system implements a dynamic sandbox isolation mechanism based on sensitivity assessment.

[0069] Sensitivity assessment: ``` function assessTaskSensitivity(taskInput, agentDefinition): sensitivityScore = 0 / / Task source assessment if taskInput.source == "EXTERNAL_API": sensitivityScore += 20 elif taskInput.source == "INTERNAL_SERVICE": sensitivityScore += 5 / / Data type evaluation if containsPersonalData(taskInput.content): sensitivityScore += 40 if containsFinancialData(taskInput.content): sensitivityScore += 50 / / Resource Access Assessment requiredResources = agentDefinition.requiredResources if "NETWORK_EXTERNAL" in requiredResources: sensitivityScore += 30 if "FILE_SYSTEM_WRITE" in requiredResources: sensitivityScore += 20 / / Historical security records if hasSecurityIncidents(taskInput.source): sensitivityScore += 25 return sensitivityScore ```.

[0070] Isolation strategy selection: ``` function selectIsolationStrategy(sensitivityScore): if sensitivityScore < 30: return IsolationStrategy( level = "LIGHTWEIGHT", workspace = createLightweightWorkspace(), networkAccess = "FULL", syscallFilter = null ) ELIF sensitivityScore < 70: return IsolationStrategy( level = "STANDARD", workspace = createStandardWorkspace(), networkAccess = "RESTRICTED", syscallFilter = createBasicSyscallFilter() ) else: return IsolationStrategy( level = "CONTAINER", workspace = createContainerWorkspace(), networkAccess = "ISOLATED", syscallFilter = createStrictSyscallFilter() ) ```.

[0071] IX. Implementation of Blockchain Auditing The system implements an audit logging mechanism based on Merkle trees.

[0072] Audit record generation: ``` function createAuditRecord(operationType, operatorId,operationContent): return AuditRecord( recordId = generateUniqueId(), operationType = operationType, timestamp = getCurrentTimestamp(), operatorHash = hashWithSalt(operatorId), contentHash = hashWithSalt(operationContent), previousRecordHash = getLastRecordHash() ) ``` Merkle tree update: ``` function updateMerkleTree(newRecord): merkleTree.addLeaf(newRecord.recordId, hashRecord(newRecord)) / / Regularly anchored to the blockchain if merkleTree.leafCount >= ANCHOR_THRESHOLD: merkleRoot = merkleTree.getRootHash() anchorToBlockchain(merkleRoot) merkleTree.reset() ``` Historical record verification: ``` function verifyAuditRecord(record, merkleProof, anchorRecord): / / Recalculate record hash computedHash = hashRecord(record) / / Verify Merkle's proof if not verifyMerkleProof(computedHash, merkleProof,anchorRecord.merkleRoot): return false / / Verify blockchain anchoring if not verifyBlockchainAnchor(anchorRecord): return false return true ```.

[0073] The above embodiments illustrate in detail the specific implementation of the present invention. Each module and function can be adjusted and expanded according to actual application scenarios.

Claims

1. A method for multi-path scheduling and sub-agent generation of intelligent agents, characterized in that, include: Based on the received scheduling parameters, a target scheduling path is selected from multiple mutually exclusive scheduling paths; When the first scheduling path is selected, the task is distributed to the cooperating agent through a delegation mechanism based on the agent identifier parameter. The cooperating agent includes agents in the same process or agent instances in the terminal split-screen session. When the second scheduling path is selected, a child agent is generated based on the context information of the parent agent. The generation process includes: inheriting the dialogue context of the parent agent, normalizing the tool execution results in the context to generate a standardized representation, and implementing prompt cache sharing optimization based on the standardized representation. When the third scheduling path is selected, the target proxy definition is determined by rule filtering and definition matching based on the proxy type parameter, and the scheduling is executed after the dependent services are ready.

2. The method according to claim 1, characterized in that, The second scheduling path also includes a security verification mechanism: Before generating a sub-agent, the parent agent is authenticated. After successful authentication, an execution credential with a time limit is generated. The credential includes a task signature, the parent agent's identity identifier, and an expiration timestamp. Embed the execution credentials into the initialization context of the sub-agent; Before executing an operation, the sub-agent verifies the validity of the execution credentials. If the verification fails, execution is refused and a security error is returned. The execution certificate is designed for one-time use and expires automatically after the sub-agent is completed.

3. The method according to claim 1 or 2, characterized in that, The standardization process for the tool execution results includes: Identify the tool type, output size, and execution time characteristics of the tool's execution results; Based on the aforementioned features, a dynamic digest algorithm is used to generate standardized placeholders, which include tool identifier hash, execution metadata, and content digest. The dynamic summarization algorithm ensures that the same tool type and similar output features produce the same placeholder prefix, thereby enabling cache hits. Other metadata of the message remains unchanged.

4. The method according to claim 1, characterized in that, The selection of the scheduling path is based on an intelligent selection algorithm: Extract the feature vector of the current task, including estimated execution time, file operation frequency, tool call complexity, and historical resource consumption patterns; Based on the feature vectors and historical performance data, the execution efficiency and resource consumption of each scheduling path are predicted using a machine learning model. Automatically select the scheduling path with the best predicted efficiency; During task execution, the path selection strategy is dynamically adjusted based on real-time performance metrics.

5. The method according to claim 1, characterized in that, The aforementioned cache sharing optimization adopts a tiered caching mechanism: L1 cache layer: Precise caching based on fixed placeholders to achieve byte-level matching; L2 caching layer: Based on semantic similarity matching, it calculates vector similarity for similar but not identical tool results and partially reuses the cache; L3 caching layer: Based on the task type, predict the sub-delegates that may be called later and preheat the cached content.

6. The method according to claim 1, characterized in that, The dialogue context for inheriting the parent proxy includes: Use homomorphic encryption algorithms to encrypt sensitive content in the parent proxy messages; The sub-agent processes encrypted content in an encrypted state and can perform content-based operations without decryption. After the sub-agent returns the result, it is decrypted by the parent agent or the authorizing party.

7. The method according to claim 1, characterized in that, The recursive derivation protection employs a dynamic control mechanism: Real-time monitoring of system resource utilization, including CPU load, memory usage, and number of active sub-agents; The maximum allowed recursion depth is dynamically adjusted based on the system resource utilization rate. Identify recursive call patterns and distinguish between valid recursive algorithm patterns and erroneous circular call patterns; Relax the depth limit for valid recursive algorithm patterns, and terminate immediately for incorrect loop patterns.

8. The method according to claim 1, characterized in that, It also includes a blockchain auditing mechanism: Each sub-agent creation and key operation generates an audit log, including the operation type, timestamp, and operator identity hash; Write the audit records into a Merkle tree structure; The Merkle tree root hash is periodically anchored to the blockchain to ensure the immutability of operation records; It supports verifying the authenticity of any historical operation based on Merkle proofs.

9. The method according to claim 1, characterized in that, Supports mixed path execution: Monitor execution status and performance metrics during task execution; When the current path is detected as unsuitable for continued execution, dynamically switch to another scheduling path; Maintain context continuity during path switching to ensure that task state is not lost.

10. A multi-path scheduling and sub-agent generation system for intelligent agents, characterized in that, include: The path selection module is configured to select one of several scheduling paths based on input parameters. The collaborative proxy module is configured to implement multiple backend detection methods, including same-process proxy, terminal multiplexer split-screen, and terminal emulator split-screen; the sub-proxy derivation module is configured to implement context inheritance, prompt cache sharing optimization, and recursive derivation protection; and the general proxy scheduling module is configured to implement rule filtering and dependent service polling waiting. The security verification module is configured to perform identity verification, credential generation, and verification.