A constraint execution method and system for agent tool scheduling

Abstract

The present application relates to a kind of constraint execution methods and systems for agent tool scheduling, the method is by the original execution feedback normalization into the original event of uniform format, and from it analysis determines specific failure type, this makes agent when facing different types of failure, can take targeted processing strategy.By introducing scope field in original event and structured environment state record, the state record of different users, different projects, different agents is independent, effectively avoid the failure experience of a certain scope is misused in another scope, solve the common misdisable and misreuse problem in prior art.By persistently storing the state information of tool in structured form, when subsequent task scheduling, agent can directly query these structured information, without repeating environment exploration or history dialogue analysis, thereby reducing planning steps and token consumption, improve overall execution efficiency.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and intelligent agents, and specifically to a constraint enforcement method and system for intelligent agent tool scheduling. Background Technology

[0002] With the rapid development of large language models and intelligent agent technology, various "intelligent assistants" have been widely used in daily office work, software development, data analysis, and other fields. These intelligent agents can understand users' natural language commands, autonomously plan task steps, and call a series of external tools (such as file reading and writing, code execution, API requests, etc.) to complete their goals. For example, an intelligent document assistant called "DocAgent" can help users "import this week's sales data (sales.xlsx) into an analysis script (report.py), generate a quarterly trend chart, and save it as a PDF."

[0003] Behind this seemingly simple task, the agent needs to sequentially invoke the "file reading tool" (open sales.xlsx), the "code execution tool" (run report.py), the "plotting tool" (generate charts), and the "file export tool" (save PDF). Environmental issues at any stage could cause the task to fail.

[0004] To enhance the continuous task capabilities of intelligent agents, existing systems generally incorporate "memory modules" or "experience replay" mechanisms to store user preferences, historical dialogues, task steps, or execution reflections. For example, DocAgent can remember that "the user prefers bar charts to line charts," or "report.py encountered an error on line 5 when the report was last generated." However, this "user- and "task-oriented" memory design reveals serious flaws when facing complex and ever-changing execution environments. A specific case will illustrate this below.

[0005] Case Study: User Xiao Wang uses DocAgent to process quarterly reports on the company intranet. His colleague Xiao Li also has his own project on the same server. One day, Xiao Wang found that DocAgent frequently failed to run report.py, while Xiao Li never encountered this problem. After investigation, it turned out that Xiao Wang's previous task had accidentally deleted a critical dependency library, pandas, while Xiao Li's project directory still had a backup.

[0006] Defect 1: The reasons for failure are recorded in a general way, making it impossible to address them specifically. When DocAgent fails to run report.py on its first attempt, the existing memory system typically only logs a single message: "Failed to call code execution tool." It doesn't further differentiate between reasons such as "missing pandas dependency," "insufficient file permissions," "network timeout," or "code syntax error." Therefore, in subsequent scheduling, DocAgent can only blindly retry or simply abandon the tool. In reality, if the system could identify a "missing dependency," it could automatically trigger `pip install pandas`; if it's an "insufficient permissions," it could request user authorization. However, due to the lack of fine-grained classification, the agent can only adopt a one-size-fits-all "retry" strategy, which not only wastes tokens but may also lead to an infinite loop.

[0007] Defect 2: The state of the same tool is incorrectly reused in different scopes. In the above case, DocAgent recorded "code execution tool unavailable" in Xiao Wang's environment. Because the existing memory system lacks the concept of "scope," this negative state might be incorrectly applied to Xiao Li's session. When Xiao Li asks DocAgent to run his own report.py, the agent might refuse to call it because it "remembers" the tool's previous failure, or inject a large amount of warning information beforehand. However, Xiao Li's environment is actually working perfectly. This is a typical example of "state pollution"—a failed experience from one scope is incorrectly reused in another, leading to unintended disabling or interference. Conversely, if Xiao Wang's environment is later fixed (e.g., dependencies are reinstalled), but the old state record still exists, DocAgent will continue to avoid the tool, causing misuse.

[0008] Defect 3: The state cannot be updated dynamically with changes in the environment. Suppose that after realizing the problem, Xiao Wang manually executed `pip install pandas` to restore the dependencies. At this point, the code execution tool is working normally again. However, the failure records in the existing memory system are not automatically cleared or updated. The next time DocAgent plans a task, it will still see the history of "the code execution tool failed" and tend to choose other alternatives (such as switching to an online service) instead of using the local tool directly. This static memory prevents the agent from perceiving real-time changes in the environment, causing outdated negative information to influence decisions for a long time.

[0009] Defect 4: It only provides a binary judgment of "available / unavailable", lacking quantitative confidence level. Existing systems typically assess tool status using only two options: "available" and "unavailable." However, the reality is far more complex. For example, a tool might fail 19 out of the last 20 calls, while another might fail only once; their reliability levels are drastically different. The former should be highly suspicious, while the latter might simply be an occasional anomaly. However, binary judgments fail to capture this difference. When faced with a tool that has "failed before," DocAgent doesn't know whether to completely disable it (hard-block), perform a lightweight verification (such as checking for dependencies), or simply alert the user. This decision-making approach, lacking quantifiable thresholds, is either overly conservative (frequently disabling useful tools) or overly aggressive (repeatedly trying tools destined to fail).

[0010] Defect 5: Repeated attempts lead to a waste of tokens and resources. Lacking precise memory and dynamic updates regarding the reasons for failures, DocAgent is likely to repeatedly attempt tools with a high probability of failure in subsequent tasks. Each attempt triggers a complete tool call, an LLM (Large Language Model) planning process, and the consumption of a significant amount of tokens. For example, in an unstable environment with 10 candidate tools, without environment state management, the agent might try all tools one by one until a usable one is found. This leads to a large number of invalid calls and wasted tokens. Statistics show that in some scenarios, invalid tool calls account for more than 40% of the total number of calls, significantly reducing task execution efficiency and increasing costs.

[0011] In summary, while existing agent memory schemes can record user preferences and historical tasks, they fail to model and maintain execution environment objects such as tools, dependencies, permissions, and resources as independent structured entities. This makes the agent appear "forgetful" and "sluggish" when facing environmental changes, hindering its ability to make accurate and efficient scheduling decisions. Summary of the Invention

[0012] In view of this, the purpose of this invention is to provide a constraint execution method and system for agent tool scheduling, so as to solve the problems of low tool scheduling accuracy, invalid calls and high token consumption in the prior art, which are caused by the inability of agents to perform structured, updatable and scope-isolated modeling and management of the state of environmental objects.

[0013] According to a first aspect of the present invention, a constraint enforcement method for agent tool scheduling is provided, comprising: Receive raw execution feedback generated by the agent calling tools during task execution; The raw execution feedback is standardized into a raw event in a unified format, and the raw event at least includes the scope of the event, request parameters, and result information; Based on the original event, analyze and determine the type of tool call failure, and generate a structured environment state record corresponding to the tool. The structured environment state record includes at least the scope, tool identifier, failure type, cumulative number of failures, cumulative number of successes, and failure confidence level representing the probability of the same type of failure occurring in the next call. When a new original event is received, the structured environment state record is updated according to the new original event, and the failure confidence is dynamically decayed and updated. In the subsequent task scheduling process, based on the failure confidence level and its preset threshold range in the structured environment state record, a constraint execution strategy is generated for the tool to execute the corresponding scheduling control action before the tool is officially called.

[0014] According to a second aspect of the present invention, a constraint enforcement system for agent tool scheduling is provided, comprising: The execution feedback acquisition module is used to receive raw execution feedback generated by the agent calling tools during task execution; The event normalization module is used to normalize the raw execution feedback into raw events in a unified format; The state maintenance module is used to generate and update a structured environment state record based on the original event. The structured environment state record includes at least the scope, tool identifier, failure type, cumulative number of failures, cumulative number of successes, and failure confidence. The failure confidence is dynamically updated based on time decay and new original events. The constraint execution module is used to generate a constraint execution strategy for the tool based on the failure confidence level and its preset threshold range in the structured environment state record during subsequent task scheduling, and output scheduling control signals.

[0015] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: By standardizing raw execution feedback into raw events in a unified format and analyzing them to determine specific failure types (including missing dependencies, insufficient access permissions, resource non-existence, network failures, and unclassified errors), the traditionally general "call failure" record is refined into distinguishable cause categories. This allows the agent to adopt targeted handling strategies when facing different types of failures: for example, for "missing dependencies," dependency installation can be automatically triggered; for "insufficient access permissions," the user can be guided to grant authorization; and for "network failures," a retry can be attempted after waiting, thereby significantly improving the efficiency and accuracy of fault handling.

[0016] By introducing scope fields (including at least one of tenant identifier, user identifier, agent identifier, and project identifier) ​​into the raw event and structured environment state records, the tool state is strictly limited to a specific context. The state records of different users, different projects, and different agents are independent of each other, effectively avoiding the erroneous reuse of failed experiences from one scope to another, and solving the common problems of mis-disabling and mis-reuse in existing technologies.

[0017] By accumulating the number of failures, the number of successes, and a failure confidence calculation mechanism with time decay, the environment state can be dynamically adjusted according to changes in execution feedback. When dependencies in the environment are installed, permissions are restored, resources are rebuilt, or network failures are resolved, new success events gradually reduce the failure confidence, enabling the agent to promptly perceive environmental recovery and avoid long-term avoidance of available tools due to outdated negative records.

[0018] By persistently storing tool state information in a structured format, including fields such as scope, tool identifier, failure type, number of failures, number of successes, and failure confidence, the agent can directly query this structured information during subsequent task scheduling. This eliminates the need for repeated environment exploration or historical dialogue analysis, thereby reducing planning steps and token consumption and improving overall execution efficiency.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0021] Figure 1 This is a flowchart illustrating an intelligent fault diagnosis and configuration optimization closed-loop method for data platform tasks, according to an exemplary embodiment. Figure 2 This is a schematic block diagram of an intelligent fault diagnosis and configuration optimization closed-loop system for data platform tasks, according to an exemplary embodiment. Detailed Implementation

[0022] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0023] Example 1 Figure 1 This is a flowchart illustrating a constraint enforcement method for agent-oriented tool scheduling according to an exemplary embodiment. See also... Figure 1 The method includes: Step S11: Receive the raw execution feedback generated by the agent calling the tool during the task execution process; Step S12: Standardize the original execution feedback into a unified format of original events, wherein the original events at least include the scope of the event occurrence, request parameters, and result information; Step S13: Based on the original event, analyze and determine the type of tool call failure, and generate a structured environment state record corresponding to the tool. The structured environment state record includes at least the scope, tool identifier, failure type, cumulative number of failures, cumulative number of successes, and failure confidence level representing the probability of the same type of failure occurring in the next call. Step S14: When a new original event is received, update the structured environment state record according to the new original event, and dynamically decay and update the failure confidence. Step S15: In the subsequent task scheduling process, based on the failure confidence level and its preset threshold range in the structured environment state record, a constraint execution strategy is generated for the tool to execute the corresponding scheduling control action before the tool is officially called.

[0024] In practice, referring to Table 1 (in Table 1, if a field is missing, it is recorded as an empty value or a default value), the raw event in the unified format should include at least the following fields: The message includes a unique identifier, scope, request parameters, result information, and event occurrence time; wherein the scope includes at least one of tenant identifier, user identifier, agent identifier, and project identifier.

[0025]

[0026] Table 1 The failure types include at least one of the following: missing dependency, insufficient access permission, resource not found, network failure, and unclassified error.

[0027] It should be noted that: 1. Dependency missing: When executing code scripts locally, dependencies are missing.

[0028] 2. Insufficient access permissions: local file access permissions, HTTP 401 / 403, etc.

[0029] 3. Resource does not exist: Local file does not exist, HTTP 404, etc.

[0030] 4. Network failure: HTTP 5xx, etc.

[0031] 5. Uncategorized Errors: Used to record errors that are not categorized.

[0032] It should be noted that the method provided in this embodiment can be applied to various intelligent agent systems based on large language models. The following uses a specific "intelligent document assistant" scenario as an example for illustration.

[0033] Suppose a company deploys an intelligent document assistant called "DocAgent" to help employees automate tasks such as data reporting, code analysis, and document generation.

[0034] One day, user Xiao Wang asked DocAgent to "read the sales data file sales.xlsx from last week, run the analysis script report.py, generate a quarterly trend chart, and save it as a PDF".

[0035] During execution, DocAgent first successfully retrieves sales.xlsx using a file reading tool. Next, it attempts to run report.py using a code execution tool, but the execution fails. At this point, the method in this embodiment begins to work: Step S11: DocAgent's execution feedback collection module receives error information returned by the code execution tool, such as "ModuleNotFoundError: No module named 'pandas'".

[0036] Step S12: The event normalization module converts the raw feedback into a raw event in a unified format, with the record scope being {tenant_id: "Company A", user_id: "Xiao Wang", agent_id: "DocAgent", project_id: "Quarterly Report"}, the request parameter being the command to run report.py, and the result information being the error stack.

[0037] Step S13: The system analyzes the event, determines the failure type as "dependency missing", and generates a structured environment state record for the "code execution tool": the scope is the same as above, the tool is identified as "code_executor", the failure type is "dependency missing", the cumulative number of failures is increased by 1, the number of successes remains unchanged, and the initial failure confidence (e.g., 0.85) is calculated.

[0038] Step S14: After Xiao Wang manually installed the pandas library, he ran report.py again with DocAgent and succeeded. The new success event entered the system. The status maintenance module retrieved the existing record, incremented its cumulative success count by 1, and recalculated the failure confidence based on time decay and the new evidence weight, reducing it (e.g., to 0.2).

[0039] Step S15: When Xiao Wang requests DocAgent to run report.py again, the constraint execution module, based on the current failure confidence of 0.2 (located in the [0.1, 0.5] interval), decides to perform lightweight verification: first, it checks if the pandas library exists. After the check passes, normal calls are allowed without hard interception or additional prompts.

[0040] Meanwhile, due to scope isolation, when colleague Xiao Li uses DocAgent, the "code execution tool" status record under his scope exists independently and will not be affected by the failure record in Xiao Wang's environment, ensuring the accuracy of status reuse.

[0041] Understandably, this embodiment standardizes raw execution feedback into raw events in a unified format and analyzes them to determine specific failure types (including missing dependencies, insufficient access permissions, resource non-existence, network failures, and unclassified errors), refining the traditionally general "call failure" record into distinguishable cause categories. This allows the agent to adopt targeted handling strategies when facing different types of failures: for example, it can automatically trigger dependency installation for "missing dependencies," guide the user to grant authorization for "insufficient access permissions," and wait and retry for "network failures," thereby significantly improving the efficiency and accuracy of fault handling.

[0042] By introducing scope fields (including at least one of tenant identifier, user identifier, agent identifier, and project identifier) ​​into the raw event and structured environment state records, the tool state is strictly limited to a specific context. The state records of different users, different projects, and different agents are independent of each other, effectively avoiding the erroneous reuse of failed experiences from one scope to another, and solving the common problems of mis-disabling and mis-reuse in existing technologies.

[0043] By accumulating the number of failures, the number of successes, and a failure confidence calculation mechanism with time decay, the environment state can be dynamically adjusted according to changes in execution feedback. When dependencies in the environment are installed, permissions are restored, resources are rebuilt, or network failures are resolved, new success events gradually reduce the failure confidence, enabling the agent to promptly perceive environmental recovery and avoid long-term avoidance of available tools due to outdated negative records.

[0044] By persistently storing tool state information in a structured format, including fields such as scope, tool identifier, failure type, number of failures, number of successes, and failure confidence, the agent can directly query this structured information during subsequent task scheduling. This eliminates the need for repeated environment exploration or historical dialogue analysis, thereby reducing planning steps and token consumption and improving overall execution efficiency.

[0045] Example 2 This embodiment includes the solution of Embodiment 1 above, except that the structured environment state record further includes: The reference to the most recently affected original event; the scope is used to limit the applicability of the state record so that the same tool under different scopes has independent state records.

[0046] In practice, the structured environment state record may include the information shown in Table 2 below, including:

[0047] Table 2 It is understood that, based on Embodiment 1, this embodiment further defines the content of the structured environment state record and the isolation effect of the scope.

[0048] By adding a "reference to the most recently affected original event" field to the structured environment state records, the system can precisely trace back to which original event last updated each state record. When an agent's behavior becomes abnormal or a user questions a scheduling decision, developers or operations personnel can directly locate the latest execution feedback affecting that state and quickly identify the cause of the state change (e.g., which tool call caused the increase or decrease in failure confidence). This feature greatly improves the system's auditability and debuggability, facilitating problem investigation and accountability.

[0049] The reference to the most recent impacting original event can be used not only for tracing but also as a reference for subsequent state updates. For example, when the system needs to determine whether to adopt a new original event to update the state, it can make a comprehensive decision by combining information such as the timestamp of the most recent event and the reliability of its source, avoiding excessive disturbance to the state caused by repeated noisy events in a short period of time. In addition, this reference can also be used to implement a differentiated decay strategy based on the type of the most recent event. For example, if the most recent event is a success event, the confidence level can be reduced at a faster rate.

[0050] This embodiment explicitly defines "the scope to limit the applicability of the state record, so that the same tool under different scopes has independent state records." This means that even if the exact same tool (e.g., the same "code execution tool") is used in two scopes (e.g., different users, different projects), their respective state records are completely independent and do not affect each other. This feature fundamentally solves the problem of accidental disabling or interference caused by failures in cross-domain reuse in existing technologies. For example, if user A's tool fails due to a lack of dependencies, it will not affect user B's normal use of the tool; if user C fails in a project due to insufficient permissions, it will not pollute the user's evaluation of the same tool in other projects.

[0051] Because scope isolation ensures the "purity" of state records, agents can make decisions based on real and independent historical execution feedback within the current scope during subsequent scheduling, without being interfered with by data from other irrelevant scopes. Combined with references to the most recently affected original event, agents can even determine whether the current state is outdated (e.g., the most recent event occurred a long time ago), thus deciding whether to proactively perform an environment probing. This fine-grained state management makes scheduling decisions more accurate and reliable.

[0052] In enterprise applications, a single intelligent agent system often needs to serve multiple tenants, users, and projects. This embodiment naturally supports this multi-dimensional parallel scenario through a scope isolation mechanism. Each tenant, user, and project can have its own independent tool status view, eliminating concerns about data obfuscation or security leaks, and laying the foundation for subsequent personalized configuration and permission management.

[0053] Example 3 This embodiment includes the scheme of Embodiment 1 above, except that the calculation method for the failure confidence is as follows: fail_confidence=old_fail_confidence×time_decay+w i Among them, w i The evidence weight for the current event is obtained by multiplying the source reliability weight and the cause certainty weight; the source reliability weight is determined based on the feedback source. Deterministic feedback from system error codes, exit codes, or HTTP status codes is valued at 1.0, while feedback based on model inference is valued at 0.5. The weight of the degree of clarity of the cause is determined based on the degree of clarity of the cause of failure: Explicit error codes or exception messages are assigned a value of 1.0, while ambiguous errors are assigned a value of 0.5. old_fail_confidence is the old failure confidence, and time_decay is the time decay factor, which is used to weight and decay the old failure confidence. Its value decreases as time increases. λ is a configurable decay coefficient, age is the time interval between the old record and the current time; the failure confidence value ranges from [0, 1].

[0054] In practice, the attenuation coefficient λ is configured differently based on the stability of the failure type: For high-stability failure types such as insufficient access permissions, missing dependencies, and unavailable resources, a smaller decay coefficient is used; For high-volatility failure types such as network failures, a larger attenuation coefficient is used.

[0055] It is understood that, based on Example 1, this embodiment further defines the specific calculation method for the failure confidence and the differentiated configuration strategy for the attenuation coefficient.

[0056] This embodiment assigns the evidence weight w to the current event. i The confidence level is defined as the product of the source reliability weight and the cause clarity weight. The source reliability weight is differentiated based on the feedback source: deterministic feedback such as system error codes, exit codes, or HTTP status codes has a value of 1.0, while fuzzy feedback based on model inference has a value of 0.5. The cause clarity weight is differentiated based on the clarity of the failure cause: explicit error codes or exception information have a value of 1.0, while fuzzy errors have a value of 0.5. This dual-weighting mechanism allows the system to distinguish between "high-confidence evidence" and "low-confidence evidence": a clear HTTP 403 error (source weight 1.0, cause weight 1.0, total weight 1.0) has a far greater impact on confidence than a fuzzy model inference (source weight 0.5, cause weight 0.5, total weight 0.25). Therefore, confidence assessment no longer treats all execution feedback equally but differentiates it based on the credibility of the evidence, significantly improving the reliability of the assessment results.

[0057] This embodiment introduces a time decay factor, causing the confidence level of older failures to decay exponentially over time, allowing the system to "forget" outdated historical information. For example, a failure event that occurred a long time ago will gradually diminish its impact on the current confidence level, while recent execution feedback will dominate. This perfectly aligns with the dynamic nature of the execution environment: once faults in the environment are fixed, old failure records should not permanently drag down the tool's reliability, but should gradually give way to new success evidence over time. This adaptive forgetting mechanism avoids the long-term solidification of outdated negative information.

[0058] This embodiment further proposes that the attenuation coefficient λ should be configured differently based on the stability of the failure type: For high-stability failure types such as insufficient access permissions, missing dependencies, and unavailable resources, a smaller decay coefficient should be used. This is because such failures are usually caused by persistent environment configuration issues (such as permission policies, dependency installation status, and file existence). Once fixed, they tend to remain stable for a long time. Therefore, old records should decay more slowly to avoid prematurely lowering vigilance against potential risks due to short-term successes.

[0059] For highly volatile failure types like network failures, a larger decay coefficient is used. This is because network failures are usually brief and sporadic (such as momentary packet loss or DNS resolution delays), and the environment quickly returns to normal after the failure disappears. Therefore, old records should decay faster to prevent short-term failures from having a long-term impact on tool scheduling.

[0060] This differentiated configuration strategy enables the confidence model to conform to the inherent behavioral patterns of different failure types, neither underestimating persistent problems nor overreacting to transient problems, thus achieving more intelligent and realistic state management.

[0061] Example 4 This embodiment includes the solution of Embodiment 1 above, but differs from Embodiment 1 in that, when a new original event is received, updating the structured environment state record according to the new original event includes: When a new raw event is received, the existing structured environment state record is retrieved based on the scope, tool identifier, and failure type in the raw event. If a matching record is found, the matching record is updated based on the new original event; If no matching record is found, a new structured environment state record is created for the tool. The scope, tool identifier, and failure type are used together as search keywords to uniquely identify a structured environment state record, ensuring that state records corresponding to different scopes, tools, or failure types are independent of each other.

[0062] It is understood that this embodiment, based on Embodiment 1, further defines the update process of the structured environment state record and the design of the search keywords.

[0063] This embodiment specifies that when a new raw event is received, the state maintenance module uses the scope, tool identifier, and failure type as search keywords to perform an accurate match within the existing structured environment state records. Since this combination uniquely identifies a state record, the system can quickly locate the target record without creating multiple duplicate records under the same combination. This avoids state record bloat caused by multiple identical failure events, saves storage space, and ensures the cleanliness and consistency of state data.

[0064] If a matching record is found, the system directly performs incremental updates on the existing record based on the new original event (such as increasing the failure count, updating the failure confidence, and refreshing the most recent event reference), without needing to recreate or fully replace it. This incremental update mechanism avoids redundant calculations and writes, reducing system overhead. Especially in scenarios with high-frequency tool calls, it can significantly improve the real-time performance and efficiency of state maintenance.

[0065] If no matching record is found, the system automatically creates a new structured environment state record for the tool, writing the original information of the new event. This means that the system does not need to predefine the state templates for all tools, but can dynamically discover and record the state of new tools or new failure types at runtime, achieving automatic coverage of unknown scenarios and enhancing the robustness and adaptability of the system.

[0066] By using scope, tool identifier, and failure type as search keywords, this embodiment achieves three-dimensional isolation of state records: Scope dimension: Ensure that the same tool under different tenants, users, agents or projects has independent state records; Tool identification dimension: Ensure that the states of different tools within the same scope do not interfere with each other; Failure type dimension: Ensure that the same tool in the same scope has its own independent status record for different failure types (such as missing dependencies vs. insufficient permissions).

[0067] This multi-dimensional isolation mechanism fundamentally solves the misjudgment problem caused by the mixed use of states across domains, tools, and failure types in existing technologies. For example, a high failure confidence of the same tool in "dependency missing" will not affect its state assessment in "network failure," and the agent can adopt its own appropriate scheduling strategy for different failure reasons.

[0068] Example 5 This embodiment includes the solution of Embodiment 1 above, except that the constraint enforcement strategy includes: When the failure confidence level is in the first interval, within the scope that perfectly matches the structured environment state record, the invocation of the tool is hard-intercepted or an alternative tool is recommended. When the failure confidence level is in the second interval, perform lightweight verification before executing the tool call, or inject the failure information into the agent's prompt word; When the failure confidence level is in the third interval, the tool is not prevented from being invoked; the failure information is only used as a historical reference prompt. The failure confidence is used to characterize the predicted probability of failure occurring again due to the same failure type within the same scope, for the same tool or environment object; The endpoint values ​​of the first, second, and third intervals are adjusted based on the tool type, task risk level, or user configuration.

[0069] For example, the first interval is set to [0.5, 1], the second interval to [0.1, 0.5], and the third interval to [0, 0.1].

[0070] The hard interception refers to: inserting interception logic between the planning module of the agent and the tool executor. When it is detected that the failure confidence of the tool to be called falls into the first interval and the scope is completely matched, the initiation of the tool call is directly prevented, and an interception notification or alternative tool recommendation is returned to the agent. The lightweight verification refers to: performing a quick check on the tool's runtime environment before executing the tool call, including but not limited to at least one of the following: whether dependencies exist, whether files are readable, and whether the network is reachable. The phrase "injecting the failure information into the prompt word of the intelligent agent" refers to: The failure type, number of failures, or failure confidence information from the structured environment state record is appended in text form to the agent's system prompts or context prompts for the agent to refer to during planning.

[0071] It is understood that this embodiment, based on Embodiment 1, further defines the specific hierarchical implementation method of the constraint execution strategy.

[0072] This embodiment divides the failure confidence level into three intervals, corresponding to three different levels of scheduling actions: hard interception, lightweight verification / hint injection, and historical reference hints. This completely changes the binary decision-making model of "available / unavailable" in existing technologies. This hierarchical mechanism enables the system to take differentiated measures based on the severity of the failure risk: decisive interception for high risk, careful verification for medium risk, and reference only for low risk. It avoids both mistakenly eliminating available tools due to excessive conservatism and repeatedly trying tools destined to fail due to excessive aggressiveness, achieving an optimal balance between risk and efficiency.

[0073] When the failure confidence level falls into the first interval (e.g., [0.5, 1]), the system inserts interception logic between the agent's planning module and the tool executor to directly prevent the tool call from being initiated and returns an interception notification or an alternative tool recommendation. This mechanism has the following advantages: Zero invalid consumption: It terminates before the actual call, avoiding any invalid API calls, code execution, or token consumption.

[0074] Instant feedback: The agent can receive interception notifications directly without waiting for timeouts or error returns, thus quickly adjusting the planned path.

[0075] Alternative Recommendations: The system can proactively recommend other available tools to guide the agent towards feasible solutions and improve task completion rates.

[0076] When the failure confidence falls into the second interval (e.g., [0.1, 0.5)), the system performs lightweight validation before executing the tool call, such as checking for dependency existence, file readability, and network reachability. This validation has the following characteristics: Low cost: Verification operations typically take only a few milliseconds, far less than the time and token consumption of a complete tool call.

[0077] High returns: It can quickly eliminate fixable environmental problems (such as missing dependencies) and avoid large-scale failures caused by small issues.

[0078] Dynamic repair: If the verification finds that a dependency is missing, the system can automatically trigger the installation process and then continue to execute the call, thus achieving "verification and repair at the same time".

[0079] When the failure confidence level falls within the second or third interval, the system can inject the failure type, number of failures, or failure confidence level information into the agent's system prompts or contextual prompts in text form. This approach preserves the autonomous decision-making capability of LLM, allowing the agent to refer to historical failure information during planning and weigh whether to invoke the tool, add additional parameters, or take preventative measures. Compared to hard interception, prompt injection is a "soft constraint," more flexible, and suitable for scenarios with high uncertainty.

[0080] This embodiment explicitly defines failure confidence as "the predicted probability of failure occurring again due to the same failure type within the same scope, for the same tool or environment object." This definition binds confidence to specific contexts (scope, tool, failure type), ensuring that each scheduling decision has a clear quantitative basis, rather than relying on the fuzzy judgment of LLM or human experience. Furthermore, since confidence is a probability value, confidence levels across different tools and failure types are comparable, allowing the use of the same threshold system for decision-making.

[0081] Example 6 Figure 2 This is a schematic block diagram illustrating a constraint enforcement system 100 for agent-oriented tool scheduling according to an exemplary embodiment. See also... Figure 2 The system 100 includes: The execution feedback acquisition module 101 is used to receive raw execution feedback generated by the agent calling tools during the execution of tasks; Event normalization module 102 is used to normalize the raw execution feedback into raw events of a unified format; The state maintenance module 103 is used to generate and update a structured environment state record based on the original event. The structured environment state record includes at least the scope, tool identifier, failure type, cumulative number of failures, cumulative number of successes, and failure confidence. The failure confidence is dynamically updated based on time decay and new original events. The constraint execution module 104 is used to generate a constraint execution strategy for the tool based on the failure confidence level and its preset threshold range in the structured environment state record during subsequent task scheduling, and output a scheduling control signal.

[0082] Understandably, this embodiment standardizes raw execution feedback into raw events in a unified format and analyzes them to determine specific failure types (including missing dependencies, insufficient access permissions, resource non-existence, network failures, and unclassified errors), refining the traditionally general "call failure" record into distinguishable cause categories. This allows the agent to adopt targeted handling strategies when facing different types of failures: for example, it can automatically trigger dependency installation for "missing dependencies," guide the user to grant authorization for "insufficient access permissions," and wait and retry for "network failures," thereby significantly improving the efficiency and accuracy of fault handling.

[0083] By introducing scope fields (including at least one of tenant identifier, user identifier, agent identifier, and project identifier) ​​into the raw event and structured environment state records, the tool state is strictly limited to a specific context. The state records of different users, different projects, and different agents are independent of each other, effectively avoiding the erroneous reuse of failed experiences from one scope to another, and solving the common problems of mis-disabling and mis-reuse in existing technologies.

[0084] By accumulating the number of failures, the number of successes, and a failure confidence calculation mechanism with time decay, the environment state can be dynamically adjusted according to changes in execution feedback. When dependencies in the environment are installed, permissions are restored, resources are rebuilt, or network failures are resolved, new success events gradually reduce the failure confidence, enabling the agent to promptly perceive environmental recovery and avoid long-term avoidance of available tools due to outdated negative records.

[0085] By persistently storing tool state information in a structured format, including fields such as scope, tool identifier, failure type, number of failures, number of successes, and failure confidence, the agent can directly query this structured information during subsequent task scheduling. This eliminates the need for repeated environment exploration or historical dialogue analysis, thereby reducing planning steps and token consumption and improving overall execution efficiency.

[0086] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0087] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0088] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0089] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0090] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0091] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0092] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0093] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A constraint enforcement method for agent-oriented tool scheduling, characterized in that, include: Receive raw execution feedback generated by the agent calling tools during task execution; The raw execution feedback is standardized into a raw event in a unified format, and the raw event at least includes the scope of the event, request parameters, and result information; Based on the original event, analyze and determine the type of tool call failure, and generate a structured environment state record corresponding to the tool. The structured environment state record includes at least the scope, tool identifier, failure type, cumulative number of failures, cumulative number of successes, and failure confidence level representing the probability of the same type of failure occurring in the next call. When a new original event is received, the structured environment state record is updated according to the new original event, and the failure confidence is dynamically decayed and updated. In the subsequent task scheduling process, based on the failure confidence level and its preset threshold range in the structured environment state record, a constraint execution strategy is generated for the tool to execute the corresponding scheduling control action before the tool is officially called.

2. The method according to claim 1, characterized in that, The raw event in the unified format includes at least the following fields: The message includes a unique identifier, scope, request parameters, result information, and event occurrence time; wherein the scope includes at least one of tenant identifier, user identifier, agent identifier, and project identifier.

3. The method according to claim 1, characterized in that, The failure types include at least one of the following: missing dependency, insufficient access permission, resource not found, network failure, and unclassified error.

4. The method according to claim 1, characterized in that, The structured environment state record also includes: The reference to the most recently affected original event; the scope is used to limit the applicability of the state record so that the same tool under different scopes has independent state records.

5. The method according to claim 1, characterized in that, The failure confidence level is calculated as follows: fail_confidence=old_fail_confidence×time_decay+w i Among them, w i The evidence weight for the current event is obtained by multiplying the source reliability weight and the cause certainty weight; the source reliability weight is determined based on the feedback source. Deterministic feedback from system error codes, exit codes, or HTTP status codes is valued at 1.0, while feedback based on model inference is valued at 0.

5. The weight of the degree of clarity of the cause is determined based on the degree of clarity of the cause of failure: Explicit error codes or exception messages are assigned a value of 1.0, while ambiguous errors are assigned a value of 0.

5. old_fail_confidence is the old failure confidence, and time_decay is the time decay factor, which is used to weight and decay the old failure confidence. Its value decreases as time increases. λ is a configurable decay coefficient, age is the time interval between the old record and the current time; the failure confidence value ranges from [0, 1].

6. The method according to claim 5, characterized in that, The attenuation coefficient λ is configured differently based on the stability of the failure type: For high-stability failure types such as insufficient access permissions, missing dependencies, and unavailable resources, a smaller decay coefficient is used; For high-volatility failure types such as network failures, a larger attenuation coefficient is used.

7. The method according to claim 1, characterized in that, The step of updating the structured environment state record based on the new original event when a new original event is received includes: When a new raw event is received, the existing structured environment state record is retrieved based on the scope, tool identifier, and failure type in the raw event. If a matching record is found, the matching record is updated based on the new original event; If no matching record is found, a new structured environment state record is created for the tool. The scope, tool identifier, and failure type are used together as search keywords to uniquely identify a structured environment state record, ensuring that state records corresponding to different scopes, tools, or failure types are independent of each other.

8. The method according to claim 1, characterized in that, The constraint enforcement strategy includes: When the failure confidence level is in the first interval, within the scope that perfectly matches the structured environment state record, the invocation of the tool is hard-intercepted or an alternative tool is recommended. When the failure confidence level is in the second interval, perform lightweight verification before executing the tool call, or inject the failure information into the agent's prompt word; When the failure confidence level is in the third interval, the tool is not prevented from being invoked; the failure information is only used as a historical reference prompt. The failure confidence is used to characterize the predicted probability of failure occurring again due to the same failure type within the same scope, for the same tool or environment object; The endpoint values ​​of the first, second, and third intervals are adjusted based on the tool type, task risk level, or user configuration.

9. The method according to claim 8, characterized in that, The hard interception refers to: inserting interception logic between the planning module of the agent and the tool executor. When it is detected that the failure confidence of the tool to be called falls into the first interval and the scope is completely matched, the initiation of the tool call is directly prevented, and an interception notification or alternative tool recommendation is returned to the agent. The lightweight verification refers to: performing a quick check on the tool's runtime environment before executing the tool call, including but not limited to at least one of the following: whether dependencies exist, whether files are readable, and whether the network is reachable. The phrase "injecting the failure information into the prompt word of the intelligent agent" refers to: The failure type, number of failures, or failure confidence information from the structured environment state record is appended in text form to the agent's system prompts or context prompts for the agent to refer to during planning.

10. A constraint enforcement system for agent tool scheduling, characterized in that, include: The execution feedback acquisition module is used to receive raw execution feedback generated by the agent calling tools during task execution; The event normalization module is used to normalize the raw execution feedback into raw events in a unified format; The state maintenance module is used to generate and update a structured environment state record based on the original event. The structured environment state record includes at least the scope, tool identifier, failure type, cumulative number of failures, cumulative number of successes, and failure confidence. The failure confidence is dynamically updated based on time decay and new original events. The constraint execution module is used to generate a constraint execution strategy for the tool based on the failure confidence level and its preset threshold range in the structured environment state record during subsequent task scheduling, and output scheduling control signals.

Images