An agent supervision settlement method and system based on task-level consumption envelope

Abstract

The application discloses an agent supervision settlement method and system based on task-level consumption envelope, relates to the technical field of artificial intelligence service resource account management, and comprises the following steps: receiving a user Token resource source to generate a Token quota account; receiving a target agent task request to generate task supervision boundary information and showing the user; after the user confirms, generating a supervision envelope, coupling payment responsibility, model routing, data exposure, content review, quota pre-occupation, usage binding, separate settlement and risk disposal rules into a closed-loop control object; a trusted proxy consumption gateway performs pre-checking based on the envelope, pre-occupies the quota after calling, and calls an upstream model without exposing the original user credentials; after obtaining the actual usage, the Token is deducted and the pre-occupied quota is released; and according to the separate settlement instruction, a developer value account book is generated or frozen based on the review result, the task state, the user confirmation, the quality evaluation and the risk event. The application realizes the closed-loop controllability of the safe consumption of user Token resources by a third-party agent.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence service resource account management technology, and more specifically to an intelligent agent supervision and settlement method and system based on task-level consumption envelopes. Background Technology

[0002] Large-scale intelligent agents can perform services such as contract analysis, paper summarization, code review, knowledge base question answering, data analysis, automated office work, and multi-step task execution. These services typically require multiple calls to the upstream large model, and the call cost is directly related to the model type, context length, output length, tool calls, multimodal content, and concurrency.

[0003] Existing intelligent agent services typically involve intelligent agent developers or service platforms uniformly calling upstream large model services, with the developers or platforms bearing the corresponding token consumption costs. As third-party intelligent agent services are called by a large number of users, the token consumption generated by input, output, multimodal, caching, and tool calls will continue to increase, causing developers or platforms to bear unpredictable variable computing power costs.

[0004] On the other hand, users or enterprises may already possess token resource packages, application interface quotas, enterprise model quotas, or platform agent token balances provided by model service providers, cloud service providers, telecommunications operators, enterprise model gateways, or platform agents. Users wish to use their own token resources to call third-party intelligent agent services but do not want to directly hand over their original application interface keys, access tokens, or enterprise model credentials to the intelligent agent developers.

[0005] Even if credentials are not directly disclosed, third-party intelligent agents may still send enterprise documents, knowledge base content, contracts, code, or customer information to unauthorized models, unauthorized model service providers, unauthorized regions, or external models not approved by the enterprise without the user's knowledge, and the user's token limit account will bear the consumption. Third-party intelligent agents may also use user tokens to perform irrelevant tasks, generate illegal content, extract sensitive data, perform malicious automation, or engage in fraudulent traffic calls, resulting in the improper consumption of the user's limit and causing compliance risks.

[0006] When credential escrow, API gateway, content moderation, quota control, usage statistics, and settlement ledger exist as independent technologies, they can only solve partial problems. For example, credential escrow can reduce the risk of key leakage, but it cannot determine whether a user should pay for a particular model call; content moderation can determine whether content is in violation of regulations, but it cannot directly determine whether to deduct user tokens or settle accounts with developers; usage statistics can record consumption, but it cannot determine whether the consumption is compliant, whether it is bound to a specific agent task, or whether it should trigger developer value settlement.

[0007] Therefore, how to provide a task-level closed-loop mechanism for third-party intelligent agents using user-provided tokens in special scenarios is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0008] In view of the above problems, the present invention is proposed to provide an agent-supervised settlement method and system based on task-level consumption envelopes to overcome or at least partially solve the above problems.

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

[0010] In a first aspect, embodiments of the present invention provide an agent-supervised settlement method based on task-level consumption envelopes, comprising: S1. Receive the Token resource source bound or configured by the user and generate the user's Token quota account; S2. Receive and analyze the task request initiated by the target intelligent agent for the target task, generate task supervision boundary information corresponding to the target task, and display the task supervision boundary information to the user; S3. After the user receives and confirms the task supervision boundary information, a token consumption supervision envelope uniquely bound to the target task is generated, which couples the token payment responsibility strategy, model routing supervision strategy, data exposure control strategy, content review strategy, quota pre-occupancy rule, actual usage binding rule, separate settlement instruction and risk handling rule into the same closed-loop control object. S4. The trusted proxy consumption gateway receives the model invocation request initiated by the target intelligent agent and performs verification based on the Token consumption supervision envelope before the model invocation. S5. After the verification is passed, calculate the expected token consumption of the model call request, pre-allocate the token quota account based on the quota pre-allocation rule, and call the upstream model service without exposing the user's original credentials to the target intelligent agent. S6. Obtain the actual usage information returned by the upstream model service or obtained by local recalculation, and deduct the actual token consumption from the user's token quota account based on the pricing rule version and the token payment responsibility strategy, and release the unconsumed pre-allocated quota. S7. In accordance with the separate settlement instructions, and based on the results of request content review, response content review, task completion status, user confirmation information, quality evaluation, and risk events, generate or freeze the developer value ledger.

[0011] Furthermore, it also includes binding rules based on actual usage, associating and binding actual usage information with target tasks, target smart agents, user token quota accounts, and upstream models called.

[0012] Furthermore, it also includes converting the saved amount into developer reward value according to the user authorization rules if the actual token consumption is lower than the pre-allocated amount and the task quality meets the conditions; If content review fails, user complaints are upheld, or fraudulent data usage or abnormal usage is discovered, the developer's value ledger will be frozen, deducted, or adjusted, and the user's credit limit will be restored or a dispute resolution record will be generated according to the rules.

[0013] Furthermore, the fields in the Token consumption supervision envelope include at least the user identifier, Token quota account number, target agent identifier, developer identifier, task identifier, Token payment responsibility strategy number, maximum Token consumption quota, pre-allocated quota, allowed model service provider set, allowed model set, geographical scope, data sensitivity level, content review strategy number, quota pre-allocation rule number, actual usage binding rule number, separate settlement instruction number, dispute period, risk handling rules, and envelope status; The status of the envelope includes at least the following: pending confirmation, confirmed, pre-occupied, executed, actual usage filled, content review passed, content review abnormal, deducted, difference released, developer pending settlement, dispute frozen, and settlement completed.

[0014] Furthermore, the trusted proxy consumption gateway determines, based on the envelope status, whether to allow new model call requests, whether to allow deduction of user token quota accounts, whether to allow release of response content, and whether to allow release of developer value ledgers.

[0015] Furthermore, the S3 token payment liability strategy includes: the entity responsible for computing power, the account providing computing power, the priority of computing power usage, the maximum liability amount, the proportion of liability borne by users, the proportion of liability borne by intelligent agent developers, the proportion of platform subsidies, and the rules for liability transfer and rebate under risk events.

[0016] Furthermore, the model routing supervision strategy in S3 includes: allowed model service provider set, allowed model set, prohibited model set, geographical scope, enterprise intranet model priority, model price cap, data sensitivity level, and whether external models are allowed to process the original text.

[0017] Furthermore, the data exposure control policy in S3 determines the rules for sending user data or enterprise data in the form of original text, summary, anonymized content, enterprise intranet model processing, or secondary confirmation, based on data sensitivity level, enterprise compliance rules, user confirmation scope, and anonymization rules.

[0018] Furthermore, the content review strategy in S3 includes: pre-request review rules and post-response review rules. Pre-request review rules are used to identify illegal generation, sensitive data extraction, malicious automation, irrelevant tasks, or traffic-boosting calls. Post-response review rules are used to identify illegal output, unauthorized data leakage, off-topic tasks, or abnormal consumption patterns. When the results of the pre-request review or the post-response review trigger a risk event, at least one of the following will be executed: refuse to consume user token quota, suspend deduction from user token quota account, mark the deducted quota as disputed, release unconsumed pre-owned quota, freeze developer value ledger, deduct developer reward quota, or transfer the corresponding consumption to the agent developer account or platform risk account.

[0019] Secondly, embodiments of the present invention provide an agent-based monitoring and settlement system based on task-level consumption envelopes, comprising: Token Quota Account Management Module: Receives the Token resource source bound or configured by the user and generates the user's Token quota account; Task receiving and analysis module: Receives and analyzes task requests initiated by the target agent for the target task, generates task supervision boundary information corresponding to the target task, and displays the task supervision boundary information to the user; Token Consumption Supervision Envelope Generation Module: After the user receives and confirms the task supervision boundary information, a Token consumption supervision envelope uniquely bound to the target task is generated, which couples the Token payment responsibility strategy, model routing supervision strategy, data exposure control strategy, content review strategy, quota pre-occupancy rule, actual usage binding rule, separate settlement instruction and risk handling rule into the same closed-loop control object. Trusted Proxy Consumption Gateway Module: The Trusted Proxy Consumption Gateway receives model invocation requests initiated by the target intelligent agent and performs verification based on the Token consumption supervision envelope before the model invocation; Model service call module: After verification, calculate the expected token consumption of the model call request, pre-allocate the token quota account based on the quota pre-allocation rule, and call the upstream model service without exposing the user's original credentials to the target intelligent agent. Quota deduction and release module: Obtain actual usage information returned by upstream model service or obtained by local recalculation, and deduct actual token consumption from user's token quota account based on pricing rule version and token payment responsibility strategy, and release unused pre-allocated quota; Separate Settlement Module: Based on the separate settlement instructions and the results of request content review, response content review, task completion status, user confirmation information, quality evaluation, and risk events, generate or freeze the developer value ledger.

[0020] The beneficial effects of the above-described technical solutions provided in the embodiments of the present invention include at least the following: 1. By using a token consumption supervision envelope, payment responsibility, model routing, content review, quota pre-allocation, actual usage binding, and separate settlement are forcibly coupled into the same task-level closed loop, avoiding the simple splicing of conventional modules.

[0021] 2. User tokens are not exposed to intelligent agents, and user or enterprise data will not be sent by intelligent agents to unknown models, unauthorized suppliers, or unauthorized regions without confirmation.

[0022] 3. Violations or misuse of content will not automatically consume user tokens or trigger developer settlements. Risk events can have a reverse impact on deductions, releases, disputes, and the developer's value ledger.

[0023] 4. Each actual usage is linked to the user, token quota account, target intelligent agent, developer, task, request, model, supplier, and content review result.

[0024] 5. The underlying token consumption and the value of smart agent functions and services are separated, and the developer's income is linked to task quality, user confirmation, content review results, risk events and savings.

[0025] 6. The third-party intelligent agent service model with user-provided tokens has the technical foundation for scalability, auditability, recalculation, and dispute resolution. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0027] Figure 1 This is a flowchart of the method provided in the embodiments of the present invention; Figure 2 This is a diagram showing the binding relationship between the token consumption monitoring envelope provided in this embodiment of the invention. Figure 3 This is a flowchart of the pre-call supervision envelope verification provided in an embodiment of the present invention; Figure 4 This is a settlement diagram showing the separation of actual usage attribution and functional services provided in this embodiment of the invention; Figure 5 This is a diagram illustrating the linkage between risk events and billing and developer settlement provided in this embodiment of the invention. Figure 6 This is a system flowchart provided in an embodiment of the present invention. Detailed Implementation

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

[0029] This invention discloses an agent-supervised settlement method and system based on task-level consumption envelopes, such as... Figure 1 As shown, it includes: S1. Receive the Token resource source bound or configured by the user and generate the user's Token quota account; S2. Receive and analyze the task request initiated by the target intelligent agent for the target task, generate task supervision boundary information corresponding to the target task, and display the task supervision boundary information to the user; S3. After the user receives and confirms the task supervision boundary information, a token consumption supervision envelope uniquely bound to the target task is generated, which couples the token payment responsibility strategy, model routing supervision strategy, data exposure control strategy, content review strategy, quota pre-occupancy rule, actual usage binding rule, separate settlement instruction and risk handling rule into the same closed-loop control object. S4. The trusted proxy consumption gateway receives the model invocation request initiated by the target intelligent agent and performs verification based on the Token consumption supervision envelope before the model invocation. S5. After the verification is passed, calculate the expected token consumption of the model call request, pre-allocate the token quota account based on the quota pre-allocation rule, and call the upstream model service without exposing the user's original credentials to the target intelligent agent. S6. Obtain the actual usage information returned by the upstream model service or obtained by local recalculation, and deduct the actual token consumption from the user's token quota account based on the pricing rule version and the token payment responsibility strategy, and release the unconsumed pre-allocated quota. S7. In accordance with the separate settlement instructions, and based on the results of request content review, response content review, task completion status, user confirmation information, quality evaluation, and risk events, generate or freeze the developer value ledger.

[0030] The specific implementation of this invention is as follows: The four roles and boundaries in this implementation are as follows: The user or user agent is used to propose task objectives, select third-party agents, confirm the source of token resources, task scope, data scope, model scope, budget, validity period, and payment responsibility; The third-party agent is used to organize execution steps, prompts, tool calls, or model call requests according to the task objectives; The Token Exchange platform is used to host or map user token resources, generate token consumption monitoring envelopes, issue short-term proxy call credentials, and perform monitoring, deduction, release, attribution, dispute resolution, and settlement before and after the platform proxy call; The model or upstream service is used to provide underlying model capabilities, tool capabilities, or multimodal processing capabilities under the platform proxy call, and return responses and actual usage information.

[0031] Without employing this invention, third-party intelligent agent services can typically be implemented in the following ways: First, the intelligent agent developer or service platform uniformly holds the upstream model credentials and advances all token costs, then charges users through subscription fees, service fees, or platform revenue sharing; Second, users directly provide their application interface keys, access tokens, enterprise model accounts, or token quota credentials to the third-party intelligent agent, which then calls the upstream model itself; Third, a regular gateway or credential hosting service forwards model requests on behalf of the intelligent agent, but only performs interface authentication, rate limiting, or billing statistics; Fourth, the intelligent agent interconnection protocol completes intelligent agent discovery, identity authentication, capability declaration, and task dialogue, and the selected intelligent agent resolves model calls and cost sharing itself.

[0032] The above methods cannot solve the complex problems addressed by this invention. The developer-managed prepayment method cannot securely use users' existing token resources for third-party intelligent agent tasks, and developers also bear the unpredictable costs of the underlying model as the user base grows. Users directly providing credentials can easily lead to the original credentials being saved, copied, leaked, or used beyond their scope, and it cannot guarantee that enterprise data will not be sent to unknown models, unknown service providers, or unauthorized regions. While ordinary gateways or credential escrow methods can reduce the risk of plaintext credential exposure, they typically cannot bind payment responsibility, task semantic boundaries, model routing, data exposure, content review, actual usage attribution, and developer settlement to the same task object. Intelligent agent interconnection protocols can solve discovery, identity, connectivity, and task collaboration issues, but they do not manage user token quota accounts, do not determine who pays for the underlying tokens, do not perform quota pre-allocation and actual usage deduction, do not assess whether response risks affect user billing, and do not create a separate settlement ledger for underlying token consumption and intelligent agent functional service value.

[0033] After adopting this invention, the user or user agent, after selecting a third-party agent, submits or confirms to the Token Exchange platform the source of token resources, task objectives, scope of data to be processed, set of allowed model service providers, set of allowed models, geographical scope, maximum token amount, validity period, allowed uses, prohibited intent, content review strategy, risk handling rules, and functional service value rules. The source of token resources can be a model service provider token package, cloud service interface quota, enterprise model quota, platform agent token balance, quota provided by operators or resource service providers, or it can be access credentials or equivalent resource rights hosted by the platform.

[0034] The Token Exchange platform generates a user's token quota account based on the user's confirmation information, or maps existing token resources, enterprise budgets, interface quotas, platform balances, and escrow credentials to the user's token quota account. The platform does not hand over the user's original access credentials, application interface keys, access tokens, or enterprise model accounts to third-party smart agents. Instead, it stores the credentials or quota mapping relationship on the platform side and only temporarily reads or uses them after the platform agent's verification is passed.

[0035] like Figure 2 As shown, the platform generates a Token consumption supervision envelope with the target agent task as the smallest control unit. This envelope is not a separate authorization order, task order, or ledger, but rather binds the user identifier, Token quota account, third-party agent identifier, developer identifier, task identifier, Token payment responsibility strategy, task-level Token consumption authorization record, model routing supervision strategy, data exposure control strategy, content review strategy, quota pre-allocation rules, actual usage binding rules, separate settlement instructions, risk handling rules, and envelope status into the same task-level control object. The Token consumption supervision envelope is a unified control object formed by the platform around a single agent task, binding the user's Token quota account, agent, task, short-term proxy call credential, and various supervision / settlement rules into the same task closed loop.

[0036] The platform returns a task context summary, platform proxy entry, short-term proxy invocation credentials or their reference, task scope summary, available model scope, data scope, limit, and validity period to the user or user agent. The user or user agent then delivers the task objective, non-sensitive data reference, platform proxy entry, and short-term proxy invocation credentials to a third-party agent. The third-party agent can only request proxy invocation from the Token Exchange platform; it cannot directly obtain the user's original credentials, directly control the user's token limit account, or delegate the proxy credentials to other agents or external services.

[0037] After the third-party intelligent agent begins to execute the task, it organizes prompt words, tool call requests, model parameters, input file references or data fragment summaries according to the user's task objectives, and sends a model call request to the trusted proxy consumption gateway, carrying short-term proxy call credentials, task identifier, intelligent agent identifier, request identifier, target model, expected token consumption, and request content.

[0038] Before reading or using any original upstream user credentials, the trusted proxy consumption gateway performs pre-call joint verification based on the token consumption supervision envelope. For example... Figure 3 As shown, the verification content includes at least the following: whether the short-term proxy call credential is valid, expired, or revoked; whether the requesting agent is consistent with the third-party agent bound to the envelope; whether the task is in an executable state; whether the token payment responsibility policy is valid; whether the user's token quota account or other computing power provider account is available; whether the expected token consumption exceeds the maximum amount or the remaining amount; whether the target model, model service provider, and region comply with the model routing supervision policy; whether the range of data to be processed and the data sensitivity level allow the model to process it; whether the request content complies with the task objective, permitted uses, and content review policy; and whether the separate settlement state allows continued execution.

[0039] If the pre-call validation fails, the platform will not initiate an upstream model call, nor will it read the user's original credentials. The platform can return understandable errors based on the envelope rules, such as insufficient limit, task out of bounds, model disallowance, data range disallowance, content risk, need for secondary user confirmation, or unusable credentials, and record the risk event and audit summary. The user or user agent can then choose to stop the task, narrow the task scope, switch model scope, add token limits, adjust payment responsibilities, or revoke the short-term proxy call credentials. This anomaly and adjustment process is still monitored by the same token consumption oversight envelope, which records status changes.

[0040] If the pre-call validation passes, the platform calculates the estimated token consumption based on the target model, input length, maximum output length, modality type, tool call cost, caching strategy, and the pricing rule version locked at the time of call. It then pre-allocates the corresponding computing power providing account according to the quota pre-allocation rules. Pre-allocation can be applied only to the user's token quota account, or it can be combined among user accounts, developer accounts, platform subsidy accounts, or resource service provider equity accounts according to priority, proportion, or upper limit, based on the token payment responsibility strategy.

[0041] After pre-acquisition, the trusted proxy consumption gateway, without exposing the user's original access credentials, application interface keys, access tokens, or token quota account control to third-party agents, invokes permitted models or upstream services according to the model routing supervision policy. If enterprise data is marked as not to be sent externally in its original form, the platform can route the request to the enterprise model gateway, intranet model, designated whitelist model, or only send a de-identified digest; if a third-party agent requests an unknown model, an unauthorized service provider, an unauthorized region, or a model exceeding the price limit, the platform will refuse to invoke the request, switch to an permitted model, or require the user to confirm again.

[0042] After the model or upstream service returns a response, the platform obtains the actual usage information returned from the upstream or recalculated locally, including the usage corresponding to input, output, multimodal, cache, tool calls, context length, and pricing rule version. The platform then performs response content review and data exposure checks to determine whether the response contains unauthorized output, unauthorized sensitive information, out-of-bounds data references, content inconsistent with the task objective, or abnormal consumption patterns.

[0043] like Figure 4 As shown, when the request content review or response content review is passed, the platform binds the actual usage to the user identifier, Token quota account, third-party intelligent agent identifier, developer identifier, task identifier, request identifier, model service provider, target model, data range summary, request summary, response summary, content review result, and risk event identifier according to the actual usage binding rules. The platform deducts the actual Token quota based on the actual usage, the pricing rule version locked at the time of invocation, and the Token payment responsibility strategy, releasing any unused pre-allocated quota, and generating Token consumption records, intelligent agent usage binding records, developer function service value records, and resource rights settlement records.

[0044] When a request for or response to content review triggers a risk event, such as Figure 5 As shown, the platform will process the transaction according to the risk handling rules and payment responsibility strategies outlined in the envelope. Processing methods may include refusing to consume the user's token limit, suspending the final deduction, marking the deducted amount as disputed, releasing unused pre-allocated limits, freezing the value of developer features and services, deducting developer reward amounts, transferring the relevant consumption to the developer account or platform risk account, requiring secondary confirmation from the user, or initiating manual review.

[0045] In typical task scenarios such as contract analysis, paper summarization, and data analysis, the platform focuses on accurately linking actual usage to users, agents, tasks, models, and developers. Actual consumption is deducted from the user's token account, while the value of services provided by the agent, such as contract analysis, summary generation, and risk identification, is recorded in the developer's value ledger. Thus, the underlying token consumption and the value of agent functional services are no longer mixed up, and developers do not need to advance the cost of the user's underlying model in the long term.

[0046] In scenarios involving enterprise knowledge bases, contract repositories, code repositories, or customer data processing, the platform focuses on using model routing supervision and data exposure control as admission criteria for token consumption, rather than simply as model scheduling strategies. The platform only pre-allocates tokens and calls the appropriate model when the target model, supplier, region, enterprise intranet priority, data sensitivity level, and whether external models are allowed to process the original text all comply with the encapsulation policy; otherwise, the platform refuses to call the model, switches to an enterprise-allowed model, or requires user confirmation. Therefore, enterprise data will not be exposed to unauthorized models without the user's knowledge due to third-party agents selecting models on their own.

[0047] In high-risk task scenarios such as code review, security analysis, and automated generation, the platform focuses on bringing content review forward to before token consumption and linking the review results with billing and developer settlement. If the agent transforms the user-authorized code quality review task into attack script generation, credential extraction, batch scanning, malicious automation, or traffic-boosting calls, the platform can refuse to consume the user's token before initiating the upstream call; if unauthorized output or overstepping of boundaries is discovered during the response phase, the platform can freeze user billing and developer value settlement.

[0048] In user auditing, enterprise review, and dispute resolution scenarios, the platform focuses on using a ledger to specify which user, token quota account, third-party intelligent agent, developer, task, request, model, service provider, data range, and content review result each token consumption corresponds to. Users can query task usage summaries, pre-allocated release differences, review results, and developer settlement status. In case of disputes, the platform can recalculate actual usage based on the same set of documents and ledger, restore user quotas, freeze or deduct developer value, and create a resource rights settlement record.

[0049] This implementation does not simply add gateways, audits, or ledgers outside the intelligent agent interconnection link. Instead, it compresses the user's own token payment responsibility, proxy call access, model and data exposure supervision, content risk, actual usage attribution, user deduction, developer function service value, and four-party resource rights settlement into the same task-level token consumption supervision envelope, which is continuously executed by the Token Exchange platform before, during, after, and during the dispute stage.

[0050] Based on the same inventive concept, embodiments of the present invention also provide an agent-based monitoring and settlement system based on task-level consumption envelopes, such as... Figure 6 The following are included: Token Quota Account Management Module: Receives the Token resource source bound or configured by the user and generates the user's Token quota account; Task receiving and analysis module: Receives and analyzes task requests initiated by the target agent for the target task, generates task supervision boundary information corresponding to the target task, and displays the task supervision boundary information to the user; Token Consumption Supervision Envelope Generation Module: After the user receives and confirms the task supervision boundary information, a Token consumption supervision envelope uniquely bound to the target task is generated, which couples the Token payment responsibility strategy, model routing supervision strategy, data exposure control strategy, content review strategy, quota pre-occupancy rule, actual usage binding rule, separate settlement instruction and risk handling rule into the same closed-loop control object. Trusted Proxy Consumption Gateway Module: The Trusted Proxy Consumption Gateway receives model invocation requests initiated by the target intelligent agent and performs verification based on the Token consumption supervision envelope before the model invocation; Model service call module: After verification, calculate the expected token consumption of the model call request, pre-allocate the token quota account based on the quota pre-allocation rule, and call the upstream model service without exposing the user's original credentials to the target intelligent agent. Quota deduction and release module: Obtain actual usage information returned by upstream model service or obtained by local recalculation, and deduct actual token consumption from user's token quota account based on pricing rule version and token payment responsibility strategy, and release unused pre-allocated quota; Separate Settlement Module: Based on the separate settlement instructions and the results of request content review, response content review, task completion status, user confirmation information, quality evaluation, and risk events, generate or freeze the developer value ledger.

[0051] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0052] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for agent-supervised settlement based on task-level consumption envelopes, characterized in that, include: S1. Receive the Token resource source bound or configured by the user and generate the user's Token quota account; S2. Receive and analyze the task request initiated by the target intelligent agent for the target task, generate task supervision boundary information corresponding to the target task, and display the task supervision boundary information to the user. S3. After the user receives and confirms the task supervision boundary information, a Token consumption supervision envelope uniquely bound to the target task is generated, which couples the Token payment responsibility strategy, model routing supervision strategy, data exposure control strategy, content review strategy, quota pre-occupancy rule, actual usage binding rule, separate settlement instruction and risk handling rule into the same closed-loop control object. S4. The trusted proxy consumption gateway receives the model invocation request initiated by the target intelligent agent and performs verification before the model invocation based on the Token consumption supervision envelope; S5. After the verification is passed, calculate the expected token consumption of the model call request, pre-allocate the token quota account based on the quota pre-allocation rule, and call the upstream model service without exposing the user's original credentials to the target intelligent agent. S6. Obtain the actual usage information returned by the upstream model service or obtained by local recalculation, and deduct the actual token consumption from the user's token quota account based on the pricing rule version and the Token payment responsibility strategy, and release the unconsumed pre-allocated quota. S7. In accordance with the aforementioned separation settlement instruction, and based on the request content review results, response content review results, task completion status, user confirmation information, quality evaluation, and risk events, generate or freeze the developer value ledger.

2. The method as described in claim 1, characterized in that, Also includes: Based on the actual usage binding rules, the actual usage information is associated and bound with the target task, the target intelligent agent, the user token quota account, and the upstream model invoked.

3. The method as described in claim 1, characterized in that, Also includes: If the actual token consumption is lower than the pre-allocated amount and the task quality meets the conditions, the saved amount will be converted into developer reward value according to the user authorization rules. If content review fails, user complaints are upheld, or fraudulent data usage or abnormal usage is discovered, the developer's value ledger will be frozen, deducted, or adjusted, and the user's credit limit will be restored or a dispute resolution record will be generated according to the rules.

4. The method as described in claim 1, characterized in that, include: The fields in the Token consumption monitoring envelope include at least the user identifier, Token quota account number, target agent identifier, developer identifier, task identifier, Token payment responsibility strategy number, maximum Token consumption quota, pre-allocated quota, allowed model service provider set, allowed model set, geographical scope, data sensitivity level, content review strategy number, quota pre-allocation rule number, actual usage binding rule number, separation settlement instruction number, dispute period, risk handling rules, and envelope status. The envelope status includes at least the following statuses: pending confirmation, confirmed, reserved, executed, actual usage filled, content review passed, content review abnormal, deducted, difference released, developer pending settlement, dispute frozen, and settlement completed.

5. The method as described in claim 4, characterized in that, include: The trusted proxy consumption gateway determines, based on the envelope status, whether to allow new model call requests, whether to allow deduction of the user's token quota account, whether to allow release of response content, and whether to allow release of the developer's value ledger.

6. The method as described in claim 1, characterized in that, The token payment liability strategy described in S3 includes: the entity responsible for computing power, the account providing computing power, the priority of computing power usage, the maximum liability amount, the proportion of liability borne by users, the proportion of liability borne by intelligent agent developers, the proportion of platform subsidies, the rules for liability transfer and rebate under risk events.

7. The method as described in claim 1, characterized in that, The model routing supervision strategy described in S3 includes: allowed model service provider set, allowed model set, prohibited model set, geographical scope, enterprise intranet model priority, model price cap, data sensitivity level, and whether external models are allowed to process the original text.

8. The method as described in claim 1, characterized in that, The data exposure control strategy described in S3 determines the rules for sending user data or enterprise data in the form of original text, summary, anonymized content, enterprise intranet model processing, or secondary confirmation, based on data sensitivity level, enterprise compliance rules, user confirmation scope, and anonymization rules.

9. The method as described in claim 1, characterized in that, The content review strategy described in S3 includes: pre-request review rules and post-response review rules. The pre-request review rules are used to identify illegal generation, sensitive data extraction, malicious automation, irrelevant tasks, or traffic-boosting calls. The post-response review rules are used to identify illegal output, unauthorized data leakage, off-topic tasks, or abnormal consumption patterns. When the pre-request review result or the post-response review result triggers a risk event, at least one of the following will be executed: refuse to consume user token quota, suspend deduction from user token quota account, mark the deducted quota as disputed, release unconsumed pre-owned quota, freeze developer value ledger, deduct developer reward quota, or transfer the corresponding consumption to the agent developer account or platform risk account.

10. An agent-supervised settlement system based on a task-level consumption envelope, used to implement the optimized acquisition method for optical signals based on a fiber optic spectrometer as described in any one of claims 1-9, characterized in that, include: Token Quota Account Management Module: Receives the Token resource source bound or configured by the user and generates the user's Token quota account; Task receiving and analysis module: Receives and analyzes task requests initiated by the target agent for the target task, generates task supervision boundary information corresponding to the target task, and displays the task supervision boundary information to the user; Token Consumption Supervision Envelope Generation Module: After the user receives and confirms the task supervision boundary information, a Token consumption supervision envelope uniquely bound to the target task is generated, which couples the Token payment responsibility strategy, model routing supervision strategy, data exposure control strategy, content review strategy, quota pre-occupancy rule, actual usage binding rule, separate settlement instruction and risk handling rule into the same closed-loop control object. Trusted Proxy Consumption Gateway Module: The Trusted Proxy Consumption Gateway receives the model invocation request initiated by the target intelligent agent and performs verification based on the Token consumption supervision envelope before the model invocation; Model service call module: After verification, calculate the expected token consumption of the model call request, pre-allocate the token quota account based on the quota pre-allocation rule, and call the upstream model service without exposing the user's original credentials to the target intelligent agent; Quota deduction and release module: Obtain actual usage information returned by upstream model service or obtained by local recalculation, and deduct actual token consumption from the user's token quota account based on the pricing rule version and the Token payment responsibility strategy, and release the unused pre-allocated quota. Separate Settlement Module: In accordance with the separated settlement instructions, and based on the request content review results, response content review results, task completion status, user confirmation information, quality evaluation, and risk events, generate or freeze the developer value ledger.

Images