Service execution system, method and device based on AI, medium and equipment

Abstract

The embodiment of the invention discloses an AI-based service execution system, an intelligent agent can agency a user to buy a target commodity conforming to a buying intention, the user does not need to manually search the target commodity by himself or herself, does not need to manually execute a payment process, and only needs to authorize the intelligent agent to agency to buy the target commodity, so that the user experience is improved. According to the method and the system, the operation required by shopping and payment of the user is greatly simplified, and meanwhile, the arbitration server side can automatically determine whether the intelligent agent has an error in understanding the purchase intention of the user to cause the error of the purchased target commodity according to the payment intention voucher and the order placing log stored in the evidence storage database.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to an AI-based business execution system, method, apparatus, medium and device. Background Technology

[0002] With the development of artificial intelligence (AI) technology, large language models (LLM) have been widely applied in various fields.

[0003] Through LLM, users can obtain various information and knowledge as if communicating with real people. In particular, generative LLM can also help users generate images and computer code, greatly simplifying the tedious operations required by users in their daily life and work.

[0004] Therefore, in scenarios where an LLM-based agent purchases goods on behalf of a user, a pressing issue is how to quickly and accurately determine whether a problem arises from the agent's misunderstanding of the user's purchasing intent when issues occur with the purchased goods. Summary of the Invention

[0005] This specification provides an AI-based business execution system, method, apparatus, storage medium, and electronic device to partially address the problems existing in the prior art.

[0006] The embodiments in this specification adopt the following technical solutions: This specification provides an AI-based business execution system, which includes: an intelligent agent, a payment server, an arbitration server, and an evidence storage database; wherein: The intelligent agent is used to interact with the user through a pre-set first large language model (LLM). When the first LLM recognizes that the user has a purchase intention, it generates a payment intention certificate based on the purchase intention and sends the payment intention certificate to the payment server. The payment server is configured to send an authorization inquiry message to the user based on the received payment intent credential, generate a payment token and send it to the smart agent after receiving the authorization confirmation message returned by the user, and persistently store the payment intent credential in the evidence storage database. After receiving the payment token, the intelligent agent searches for target products that match the purchase intent corresponding to the payment intent credential. When a target product is found, it sends an order instruction for the target product to the merchant system corresponding to the target product, uses the payment token to pay the amount corresponding to the target product to the merchant system through the payment server, and persistently stores the order log corresponding to the order instruction in the evidence storage database. The arbitration server is used to, when receiving an arbitration request sent by the user for the target product, retrieve the payment intent certificate and the order log from the evidence storage database, determine the first semantic difference between the payment intent certificate and the order log using a preset second LLM, and determine the breach of contract liability of the intelligent agent based on the first semantic difference.

[0007] This specification provides an AI-based business execution method, the method comprising: The arbitration server receives an arbitration request from a user regarding a target product. The amount corresponding to the target product is determined by the agent receiving a payment token from the payment server. Based on the purchase intent corresponding to the payment intent credential, the agent searches for a target product matching the purchase intent, sends an order instruction for the target product to the merchant system, and uses the payment token to pay the merchant system through the payment server. The payment intent credential is generated by the agent interacting with the user through a pre-set first large language model (LLM). When the first LLM identifies the user's purchase intent, it generates and sends the credential to the payment server. The payment token is generated by the payment server based on the received payment intent credential, sending an authorization query message to the user, and receiving an authorization confirmation message from the user, which is then sent to the agent. The payment intent credential and the order log corresponding to the order instruction are obtained from the evidence storage database; wherein, the payment intent credential is persistently stored in the evidence storage database after the payment server receives the authorization confirmation message returned by the user; the order log is persistently stored in the evidence storage database after the intelligent agent sends an order instruction for the target product to the merchant system corresponding to the target product; The first semantic difference between the payment intent certificate and the order log is determined using a preset second LLM; Based on the first semantic difference, the breach of contract liability of the intelligent agent is determined.

[0008] This specification provides an AI-based business execution device, the device comprising: The receiving module is used to receive arbitration requests sent by users for target products. The amount corresponding to the target product is determined by the intelligent agent after receiving a payment token from the payment server. Based on the purchase intent corresponding to the payment intent credential, when a target product matching the purchase intent is found, the agent sends an order instruction for the target product to the merchant system corresponding to the target product and uses the payment token to pay the merchant system through the payment server. The payment intent credential is generated by the intelligent agent through interaction with the user using a pre-set first large language model (LLM). When the first LLM identifies that the user has a purchase intent, it generates and sends the purchase intent to the payment server. The payment token is generated by the payment server after receiving the authorization query message from the user based on the received payment intent credential and sending it to the intelligent agent. The acquisition module is used to acquire the payment intent certificate and the order log corresponding to the order instruction from the evidence storage database; wherein, the payment intent certificate is persistently stored in the evidence storage database after the payment server receives the authorization confirmation message returned by the user; the order log is persistently stored in the evidence storage database after the intelligent agent sends the order instruction for the target product to the merchant system corresponding to the target product; The semantic difference determination module is used to determine the first semantic difference between the payment intent certificate and the order log using a preset second LLM; The liability determination module is used to determine the breach of contract liability of the intelligent agent based on the first semantic difference.

[0009] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned AI-based business execution method.

[0010] This specification provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the aforementioned AI-based business execution method.

[0011] This specification provides a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned AI-based business execution method.

[0012] The above-described at least one technical solution used in the embodiments of this specification can achieve the following beneficial effects: This specification discloses an AI-based business execution system. When an intelligent agent identifies a user's purchase intention, it generates a payment intention certificate based on this intention and sends it to the payment server. After obtaining authorization from the user, the payment server generates a corresponding payment token based on the payment intention certificate and returns it to the intelligent agent. The payment intention certificate is also persistently stored in a data storage database. Upon receiving the payment token, when the intelligent agent finds a target product that matches the purchase intention, it sends an order instruction for the target product to the corresponding merchant system. On the one hand, the order log corresponding to the order instruction is persistently stored in the data storage database. On the other hand, the intelligent agent uses the payment token to pay the amount corresponding to the target product to the merchant system through the payment server. When the arbitration server receives an arbitration request for the target product, it retrieves the payment intention certificate and the order log from the data storage database and determines the intelligent agent's liability for breach of contract based on the first semantic difference between the payment intention certificate and the order log. Through the above system, the intelligent agent can purchase target products that match the user's purchase intention on behalf of the user. The user does not need to manually search for target products or manually execute the payment process. They only need to authorize the intelligent agent to carry out the purchase on their behalf, which greatly simplifies the user's shopping and payment operations. At the same time, the arbitration server can also automatically determine the responsibility for whether the intelligent agent made a mistake in understanding the user's purchase intention and thus purchased the wrong target products, based on the payment intention vouchers and order logs stored in the evidence database. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings: Figure 1 A schematic diagram of an AI-based business execution system architecture is provided for an embodiment of this specification; Figure 2 A flowchart of an AI-based business execution method provided in the embodiments of this specification; Figure 3 The method for initiating payment by a merchant system is provided in the embodiments of this specification; Figure 4 The method for initiating payment by an intelligent agent is provided in the embodiments of this specification; Figure 5 A schematic diagram of an AI-based business execution device provided in the embodiments of this specification; Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this specification. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0015] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0016] Figure 1 This specification provides a schematic diagram of an AI-based business execution system architecture, which specifically includes: an intelligent agent, a merchant system, a payment server, an arbitration server, and an evidence storage database. Wherein: The intelligent agent has a pre-installed first LLM (Local Level Manager), which interacts with the user through at least one method, such as voice, text, or vision. In one possible embodiment, the intelligent agent's front-end can be deployed on the user terminal, and its back-end can be deployed on a backend server. The first LLM is deployed on the back-end of the intelligent agent, and the user can interact with the first LLM deployed on the back-end of the intelligent agent through the front-end of the intelligent agent on the user terminal. For ease of description, the distinction between the front-end and back-end of the intelligent agent will not be made below.

[0017] The intelligent agent can also integrate a payment software development kit (SDK) corresponding to the payment server. This SDK includes an application programming interface (API) for the payment server, allowing the intelligent agent to interact with it. The SDK can also directly provide at least some of the functionalities of the payment client installed on the user's terminal, enabling users to use these functions directly within the intelligent agent's interface without switching to the client. Furthermore, the intelligent agent can pre-configure APIs corresponding to merchant systems. For example, integrating an e-commerce SDK for the merchant system allows the intelligent agent to interact with it, as the e-commerce SDK contains corresponding APIs.

[0018] A merchant system is used to provide users with online shopping functionality, such as an e-commerce platform, a food delivery platform, or an online ordering platform for a branded coffee shop or fast food restaurant. In traditional online shopping scenarios, a merchant system displays information about the various products it sells. Users can select their desired products and place an order through the merchant system. The merchant system can also activate a payment client, which, along with its corresponding payment server, processes the payment for the user's purchase.

[0019] The payment server, located in the background, is used to collect the triples required for payment, namely the payment account, the receiving account, and the amount to be paid. It generates a payment order based on the triples required for payment and completes the payment for the order according to the triples.

[0020] The arbitration server, also located in the backend, allows users to submit an arbitration request to the product arbitration server when problems arise, such as receiving the wrong item. The server will determine which entity is liable for the breach of contract, for example, whether it is the responsibility of the intelligent agent or the merchant's system.

[0021] The evidence database, also located in the background, is used to store key evidence in the process of intelligent agents purchasing the goods needed by users. This key evidence can provide a basis for the arbitration server to determine liability.

[0022] To enable the intelligent agent to act as a user's proxy, purchasing goods on the user's behalf and automatically completing payments, and to allow the arbitration server to automatically determine liability in case of problems with the goods purchased by the intelligent agent, based on the above... Figure 1 The system shown in this specification provides embodiments as follows: Figure 2 The example shown is an AI-based business execution method.

[0023] Figure 2 The flowchart of the AI-based business execution method provided in the embodiments of this specification specifically includes the following steps: S200: The agent interacts with the user through a pre-configured first LLM.

[0024] In one embodiment provided in this specification, the intelligent agent may include an intelligent agent client located at the front end and an intelligent agent server located at the back end. The first LLM may be pre-deployed on the intelligent agent server at the back end. The user can input one or more forms of interactive information such as text, voice, and vision through the intelligent agent client at the front end. The intelligent agent client then sends the interactive information input by the user to the first LLM deployed in the intelligent agent server at the back end. The first LLM can analyze the interactive information input by the user based on its own reasoning ability and / or a preset knowledge base, and output corresponding response information back to the intelligent agent client at the front end. The intelligent agent client then displays the response information to the user to complete the interaction between the user and the first LLM.

[0025] In another embodiment provided in this specification, the agent may also include only the agent client at the front end. The first LLM is directly deployed in the agent client at the front end. In this case, the agent client provides both the function of directly receiving interactive information input by the user and the function of the agent server in the above embodiment at the front end.

[0026] Regardless of the deployment method of the first LLM, users need to log in to their agent account in the agent in order to interact with the first LLM pre-deployed in the agent in the above manner.

[0027] S201: When the first LLM identifies that the user has a purchase intention based on the interaction with the user, it generates a payment intention certificate based on the purchase intention and sends the payment intention certificate to the payment server.

[0028] When the intelligent agent interacts with the user through the first LLM and identifies the user's intention to purchase a certain product, it can generate a payment intent certificate. The payment intent certificate described in this specification is an electronic certificate authorizing the intelligent agent to purchase the product the user needs. For users, when authorizing the intelligent agent to make purchases, the most important concerns are: whether the product purchased by the intelligent agent is what the user wants; whether the amount paid by the intelligent agent is within the user's budget; whether the intelligent agent purchased the product from a merchant the user prefers; and whether the intelligent agent will "unilaterally" purchase other products for the user after this purchase.

[0029] Therefore, when an intelligent agent recognizes that a user has the intention to purchase a certain product, it can continue to refine the purchase intention through interaction with the user, and determine the user's available payment amount constraints, optional merchant constraints, payment strategy, and product description of the required product based on the refined purchase intention.

[0030] The payable amount constraint is the range of amounts a user is willing to pay to purchase the goods they need, such as not exceeding the maximum acceptable amount specified by the user, or a range centered on the user's expected amount.

[0031] Optional merchant constraints are the merchants that a user is willing to choose when purchasing the goods they need, including at least one merchant specified by the user, or a merchant type specified by the user.

[0032] Payment strategy refers to the payment strategy that a user intends for an intelligent agent to purchase goods on their behalf. This includes allowing the intelligent agent to purchase the goods needed for the current purchase (i.e., allowing the intelligent agent to pay only once), and the validity period for using the intelligent agent to purchase goods on behalf of the user. If the validity period expires, the intelligent agent will not be allowed to continue purchasing goods on behalf of the user, even if it has not yet purchased the goods that match the user's purchase intention.

[0033] The product description of the required product is the description of the product that the user wants to buy, such as a pair of red sneakers from a certain brand.

[0034] Based on the purchase intent, after determining the aforementioned payable amount constraints, optional merchant constraints, payment strategy, and product description of the required goods, the intelligent agent can generate a payment intent voucher containing these constraints. Thus, the payable amount constraint in the payment intent voucher addresses the question of whether the amount paid by the intelligent agent for the purchased goods matches the user's budget; the optional merchant constraint addresses the question of whether the intelligent agent is purchasing goods from a merchant preferred by the user; the payment strategy addresses the question of whether the intelligent agent will continue to purchase other goods for the user without authorization after this purchase; and the product description of the required goods addresses the question of whether the goods purchased by the intelligent agent are goods that the user actually wants to buy.

[0035] After generating the aforementioned payment intent credential, the intelligent agent can send the payment intent credential to the payment server.

[0036] S202: The payment server receives the payment intent credential and sends an authorization request message to the user based on the payment intent credential.

[0037] After receiving the payment intent credential sent by the smart agent, the payment server can first verify the payment intent credential.

[0038] Specifically, the payment server can first verify the payment intent credential sent by the intelligent agent according to the preset standard payment intent credential format and data structure to verify whether the payment intent credential sent by the intelligent agent is forged.

[0039] After determining that the payment intent certificate sent by the agent is not a forged payment intent certificate, it is also possible to verify whether the payment intent certificate sent by the agent contains four parts: payable amount constraint, optional merchant constraint, payment strategy, and product description of the required goods, so as to verify whether the content of the payment intent certificate sent by the agent is complete.

[0040] After confirming that the payment intent credential sent by the intelligent agent contains all four parts mentioned above, it is also possible to verify whether the user's act of entrusting the intelligent agent to purchase goods on their behalf is risky, based on at least one of the payable amount constraints, optional merchant constraints, and the intelligent agent's historical behavior data contained in the payment intent credential.

[0041] If there is no risk, the payment server can display the payment intent credential received by the payment server, which includes the payable amount constraints, optional merchant constraints, payment strategy, and product description of the required goods. The server can also send an authorization inquiry message to the user to ask whether the user confirms that the intelligent agent is authorized to purchase goods on their behalf based on the aforementioned payment intent credential.

[0042] Specifically, after verifying the payment intent credential sent by the agent and confirming successful verification, the payment server generates a page containing the received payment intent credential and authorization query message, and returns it to the agent. Since the agent integrates a payment SDK, which provides at least some of the functionality of the payment client installed on the user's terminal, and users need to use the corresponding agent login account when using the agent, and also need to use the corresponding payment login account when using the payment client to complete identity verification or payment functions, the agent login account and payment login account can be pre-bound.

[0043] After the agent receives the page containing the payment intent credential and authorization inquiry message returned by the payment server, it can use the payment login account bound to the currently logged-in agent login account to start the payment SDK and display the received page through the payment SDK. The page contains at least the authorization inquiry message, a control for returning an authorization confirmation message to the payment server, and the payment intent credential containing the payable amount constraint, optional merchant constraint, payment strategy, and product description of the required goods.

[0044] When a user triggers the control on this page that is used to return an authorization confirmation message to the payment server, the smart agent can verify the user's identity through the payment SDK, and after the identity verification is successful, return an authorization confirmation message to the payment server.

[0045] The identity verification described in this specification includes, but is not limited to, biometric verification such as fingerprints and facial recognition, and this specification does not impose any restrictions on this. Since the payment SDK is already logged into the user's payment login account, when verifying the user's identity, it can query the pre-stored standard identity features corresponding to the currently logged-in payment login account, and simultaneously collect the user's identity features to be verified. Then, based on the standard identity features and the identity features to be verified, the user's identity is verified.

[0046] S2031: After receiving the authorization confirmation message returned by the user based on the authorization inquiry message, the payment server generates a payment token and sends the payment token to the smart agent.

[0047] S2032: After receiving the authorization confirmation message returned by the user based on the authorization inquiry message, the payment server persistently stores the payment intent credential in the evidence storage database.

[0048] In the embodiments of this specification, after receiving the authorization confirmation message returned by the user, the payment server can confirm that the user has authorized the smart agent to purchase goods on behalf of the user based on the payment intent certificate. Thus, it can execute steps S2031 and S2032 in sequence, that is, on the one hand, generate a payment token and return it to the smart agent, and on the other hand, persistently store the payment intent certificate in the evidence storage database.

[0049] Specifically, in step S2031, the payment server can determine the user's payment account based on the user's payment login account (hereinafter referred to as the user identifier), generate a payment token that the user can query based on the user's payment account, and return it to the intelligent agent. Here, the user identifier in this specification refers to the user's payment login account, while the user's payment account is the account used by the user during payment and bound to the user identifier. The user identifier and the payment account are not identical.

[0050] The payment token described in this specification is used by an intelligent agent to make payments on behalf of a user. When an intelligent agent uses this payment token to make a payment, it does not require further confirmation from the user and can directly use the payment token to complete the payment. It should be noted that the payment token described in this specification is a one-time payment token. Once the payment token has been used, the payment server will cancel it, rendering the payment token invalid and unable to be used again.

[0051] In step S2032, since the payment token generated by the payment server corresponds to a unique token identifier, after generating the payment token, the payment server can send the payment intent credential received in step S202 and the token identifier corresponding to the payment token generated in step S2031 to the evidence storage database. The evidence storage database then persistently stores the payment intent credential and the token identifier locally and establishes an association between the payment intent credential and the token identifier.

[0052] Specifically, after receiving the authorization confirmation message returned by the user, the payment server can first use the user's user identifier to sign the payment intent credential, which indicates that the payment intent credential has been confirmed by the user. Then, the signed payment intent credential and the token identifier corresponding to the generated payment token are persistently stored in the evidence storage database.

[0053] S204: After receiving the payment token, the intelligent agent searches for target products that match the purchase intention corresponding to the payment intention credential.

[0054] After receiving the payment token, the intelligent agent can interact with each merchant system through the API of all merchant systems integrated with the intelligent agent. Based on the purchase intent corresponding to the payment intent credential, it can search for target products that match the purchase intent among the products sold by each merchant system.

[0055] Specifically, since the payable amount constraint, optional merchant constraint, and product description of the required goods in the payment intent credential already represent the user's purchase intention, the intelligent agent can search for target goods in each merchant system that satisfy the payable amount constraint and optional merchant constraint and match the product description of the required goods. If the target goods cannot be found at present, the search can continue in real time, periodically, or at subsequent specified times in each merchant system. If more than two target goods are found, the intelligent agent can select one target goods from the multiple target goods for subsequent steps through the reasoning capability of the first LLM itself. Therefore, the user does not need to search for target goods manually, nor does the user need to manually monitor whether the target goods exist in the new products subsequently listed in each merchant system when the target goods cannot be found. The intelligent agent can automatically search for target goods on behalf of the user based on the payment intent credential. In addition, after sending the payment intent credential to the payment server, the intelligent agent does not need to wait to receive the payment token sent by the payment server, and can asynchronously search for target goods that match the purchase intention corresponding to the payment intent credential. Moreover, the embodiments in this specification do not require the intelligent agent to be able to find the target goods immediately.

[0056] S205: When the intelligent agent finds a target product, it sends an order instruction for the target product to the merchant system corresponding to the target product.

[0057] S2061: Using the payment token, pay the amount corresponding to the target product to the merchant system through the payment server.

[0058] S2062: Persistently store the order log corresponding to the order placement instruction in the evidence storage database.

[0059] In the embodiments of this specification, when the intelligent agent finds a target product, it can place an order for the target product. That is, it sends an order instruction for the target product to the merchant system corresponding to the target product, so that the merchant system generates a confirmed fulfillment order, and executes steps S2061 and S2062 in sequence. That is, on the one hand, it uses the payment token received in step S203 to pay the amount corresponding to the target product to the merchant system through the payment server, and on the other hand, it persistently stores the order log corresponding to the order instruction sent to the merchant system in the evidence storage database.

[0060] Using the above method, the intelligent agent, after learning of a user's purchase intention, can purchase target goods that match that intention on behalf of the user. The user does not need to manually search for target goods or manually execute the payment process; they only need to authorize the intelligent agent to perform the purchase, greatly simplifying the user's shopping and payment operations. After learning of the user's purchase intention, the intelligent agent needs to generate a corresponding payment intention credential based on that intention. After the user authorizes, the payment server also generates a one-time payment token for this payment intention credential. After the intelligent agent makes the purchase and pays, the payment token is canceled. The next time the intelligent agent learns of another purchase intention from the user, it needs to generate a corresponding payment intention credential again. This ensures that the user's authorization to the intelligent agent is no longer a vague deduction permission, but a permission to purchase and pay on behalf of the user specifically for that particular purchase intention.

[0061] Regarding the process of the intelligent agent using a token to pay for the target product in step S2061 above, the embodiments in this specification provide the following... Figure 3 and Figure 4 The two methods are shown.

[0062] Figure 3 The method for initiating payment by a merchant system, as provided in the embodiments of this specification, specifically includes the following steps: S20611: When the intelligent agent finds the target product, it sends the payment token to the merchant system.

[0063] When the intelligent agent finds a target product, it can send an order instruction for that target product to the merchant system in step S205 based on the user's user identifier (i.e., the user's payment login account), causing the merchant system to generate a confirmed fulfillment order. It should be noted that this confirmed fulfillment order is used by the merchant system to confirm that the user has purchased the target product and that the product needs to be shipped to the user; it is not a payment order used by the payment server to pay for the target product. This confirmed fulfillment order exists only in the merchant system and not in the payment server. The confirmed fulfillment order may include the user's user identifier, the product information of the target product, and the price of the target product.

[0064] At the same time, in step S20611, the smart agent also needs to send the payment token to the merchant system so that the merchant system can initiate the payment.

[0065] S20612: After receiving the order instruction, the merchant system sends a payment request to the payment server, carrying the user identifier, the amount, the receiving account corresponding to the merchant system, and the payment token, based on the user identifier and the amount corresponding to the target product.

[0066] After receiving the order instruction and payment token, the merchant system can generate the aforementioned confirmed fulfillment order and, on the other hand, generate a payment request containing the user's identifier, the amount of the target product, the merchant system's corresponding payment account, and the payment token. The payment request is then sent to the payment server to formally initiate payment to the payment server.

[0067] S20613: In response to the received payment request, the payment server generates a payment order based on the user identifier, the amount, and the receiving account carried in the payment request, and queries the user's payment account based on the payment token carried in the payment request, and makes payment for the payment order through the queried payment account.

[0068] Since the payment request sent by the merchant system already includes the required receiving account and the amount of the target product in the triplet, and although the user's payment account is not yet included, the payment request carries a payment token. Therefore, in response to this payment request, the payment server can create a payment order containing the user's identifier, the amount of the target product, and the receiving account corresponding to the merchant system. This payment order exists on the payment server and is used to pay for the target product.

[0069] Since the payment order already contains the amount and the receiving account, but the payment account has not yet been collected, the payment server can use the payment token carried in the received payment request to query the user's payment account and then add that payment account to the payment order. At this point, the payment order has the necessary three-part payment set, allowing the payment server to process the payment through the retrieved payment account. In other words, it transfers the amount for the target product from the payment account to the receiving account.

[0070] pass Figure 3 The method shown requires the agent to send a payment token to the merchant system, which then initiates payment for the target product to the payment server, or in other words, initiates a collection.

[0071] Figure 4 The method for initiating payment by an intelligent agent, as provided in the embodiments of this specification, specifically includes the following steps: S20611': After receiving the order placement instruction, the merchant system sends a payment order generation request to the payment server, carrying the user identifier, the amount, and the receiving account corresponding to the merchant system, based on the user identifier and the amount corresponding to the target product.

[0072] and Figure 3 Similar to step S20611 shown, when the agent finds the target product, it still needs to send an order instruction for the target product to the merchant system. However, in step S20611', the agent does not send the payment token to the merchant system.

[0073] Similar to step S20612, after receiving the order instruction, the merchant system still needs to generate a confirmation order. However, in step S20612', since the merchant system cannot know the user's payment account or obtain the payment token, the merchant system cannot directly initiate payment to the payment server. Instead, it generates a payment order generation request carrying the user's identifier, the amount of the target product, and the corresponding collection account of the merchant system, and sends the payment order generation request to the payment server.

[0074] It should be noted that this payment order generation request is only used to request the payment server to generate a payment order that is temporarily missing a payment account, and is not used to request the payment server to execute the corresponding payment operation. Therefore, the payment order generation request sent by the merchant system to the payment server is only a pre-order request, and not a payment initiation request.

[0075] S20612': The payment server generates a payment order based on the user identifier, the amount, and the receiving account carried in the payment order generation request, and returns the order identifier of the payment order to the merchant system.

[0076] Although the payment order generation request only contains the amount and receiving account in the triple, the payment server can still generate a payment order that includes the user's identifier, the amount of the target product, and the receiving account corresponding to the merchant's system. The payment account in the triple can be left empty for the time being.

[0077] Once a payment order is generated, regardless of whether the triples in the payment order are complete, the payment server will assign a unique order identifier to the payment order. Therefore, the payment server can return the order identifier of the pre-generated payment order to the merchant system.

[0078] S20613': The merchant system returns the order identifier to the intelligent agent.

[0079] S20614': The intelligent agent sends a payment request carrying the payment token and the order identifier to the payment server.

[0080] After receiving the order identifier of the pre-generated payment order from the payment server forwarded by the merchant system, the intelligent agent can generate a payment request carrying a payment token and the order identifier, and send the payment request to the payment server to formally initiate payment. This payment request means: requesting to use the payment account corresponding to the payment token to make payment for the payment order corresponding to the order identifier.

[0081] S20615': In response to the received payment request, the payment server queries the user's payment account based on the payment token carried in the payment request, and makes payment for the payment order corresponding to the order identifier carried in the payment request through the queried payment account.

[0082] Once the payment server receives the payment request, it can query the user's payment account based on the payment token carried in the request, and then add the queried payment account to the previously pre-generated payment order. At this point, the payment order contains the necessary three-part payment, allowing the payment server to process the payment through the payment account. In other words, it transfers the amount for the target product from the payment account to the receiving account.

[0083] pass Figure 4 The method shown is such that once the payment token is generated by the payment server and sent to the smart agent, it will not be transferred to other devices. The smart agent will only use the payment token to make payment for the payment order after receiving the order identifier of the payment order pre-generated by the payment server for the merchant system.

[0084] Furthermore, whether through Figure 3 The method shown is for the merchant system to initiate payment, which is still through... Figure 4The payment method shown allows the payment server to verify the payment order before making payment through the user's payment account. Payment is only made if the verification is successful; otherwise, the payment is rejected.

[0085] Specifically, the aforementioned verification includes verification of the payment order and verification of the payment token.

[0086] When verifying a payment order, the payment server first queries the payment intent certificate upon which the payment token is based, i.e., the payment intent certificate corresponding to the payment token. It then verifies whether the amount in the payment order (i.e., the amount of the target product) meets the payable amount constraint contained in the payment intent certificate. It also verifies whether the merchant corresponding to the receiving account in the payment order meets the optional merchant constraint contained in the payment intent certificate. Furthermore, the payment server can query the product information of the target product in the merchant system and verify whether the product information of the target product matches the product description of the required product contained in the payment intent certificate. If the amount in the payment order meets the payable amount constraint, the merchant corresponding to the receiving account meets the optional merchant constraint, and the product information of the target product matches the product description of the required product, then the verification of the payment order is considered successful; otherwise, the verification of the payment order fails.

[0087] During payment token verification, the payment server can verify whether the agent's use of the payment token conforms to the payment strategy contained in the payment intent certificate. Specifically, the payment server can verify whether the payment token has been cancelled, and whether the current time is within the validity period of the payment token as specified by the payment strategy contained in the payment intent certificate. If the payment token has not been cancelled and is still within its validity period, the verification of the payment token is considered successful; otherwise, the verification of the payment token fails.

[0088] The payment server will only allow payment to be processed through the user's payment account if both the payment order and the payment token have passed verification; otherwise, the payment will be rejected. Furthermore, after processing the payment, the payment server must also cancel the payment token to prevent it from being used for any other payments.

[0089] For step S2062 above, the intelligent agent can send the order log corresponding to the order instruction and the token identifier corresponding to the payment token received in step S204 to the evidence storage database, so that the evidence storage database can persistently store the order log and the token identifier and establish the association between the order log and the token identifier.

[0090] At this point, since the payment intent credentials and order logs stored in the evidence storage database are associated with the token identifier of the payment token generated by the payment server in step S2031, the evidence storage database can associate the payment intent credentials and order logs that are associated with the token identifier based on the token identifier.

[0091] S207: When the arbitration server receives the arbitration request sent by the user for the target product, it retrieves the payment intent certificate and the order log from the evidence storage database.

[0092] In the method described in this manual, the selection and payment for the target product are handled by the intelligent agent acting on behalf of the user. The user only needs to authorize the intelligent agent to make the purchase on their behalf, without needing to perform any other operations. However, if the intelligent agent selects a target product that does not actually conform to the purchase intent corresponding to the payment intent voucher due to performance issues of the first LLM, the intelligent agent will be held accountable subsequently. Therefore, when a user believes that the target product they received does not conform to the aforementioned purchase intent, they can send an arbitration request for the target product to the arbitration server.

[0093] If the arbitration request can carry the order identifier of the payment order created by the payment server for the target product, the arbitration server can determine the token identifier corresponding to the payment token used by the agent when making payment for the payment order through the payment server, based on the order identifier carried in the arbitration request, and obtain the payment intent certificate and order log associated with the token identifier from the evidence storage database.

[0094] Since the order instruction sent by the agent to the merchant system in step S205 includes at least the user's identifier, the merchant identifier of the merchant system corresponding to the target product, the product information of the target product, and the amount of the target product, the order log generated by the agent corresponding to the order instruction can also include at least the amount of the target product, the merchant identifier of the merchant system corresponding to the target product, and the product information of the target product.

[0095] S208: Use a preset second LLM to determine the first semantic difference between the payment intent certificate and the order log, and determine the breach of contract liability of the intelligent agent based on the first semantic difference.

[0096] Since the payment intent credential described in this specification includes the user's payable amount constraints, optional merchant constraints, and product description of the required goods, while the order log includes the amount corresponding to the target product, the merchant identifier of the merchant system corresponding to the target product, and the product information of the target product, the arbitration server can use a preset second LLM to encode the payment intent credential and the order log respectively, so as to encode the semantic vector of the payment intent credential and the semantic vector of the order log, and determine the first semantic difference between the payment intent credential and the order log based on the semantic vector of the payment intent credential and the semantic vector of the order log.

[0097] Specifically, the arbitration server can use the payable amount constraint, optional merchant constraint, and product description of the required product as the first, second, and third key fields of the payment intent credential, respectively. The amount corresponding to the target product, the merchant identifier of the merchant system corresponding to the target product, and the product information of the target product can be used as the first, second, and third key fields of the order log, respectively. Then, using a second LLM (Limited Language Management), the first, second, and third key fields in the payment intent credential are encoded to obtain semantic vectors corresponding to each of these three key fields. Finally, the semantic vectors corresponding to these three key fields are fused, such as by direct concatenation or pooling, to obtain the semantic vector of the payment intent credential. Similarly, using a second LLM, the first, second, and third key fields in the order log are encoded to obtain semantic vectors corresponding to each of these three key fields. Finally, the semantic vectors corresponding to these three key fields are fused to obtain the semantic vector of the order log.

[0098] After obtaining the semantic vectors of the payment intent credential and the order log, the second LLM can determine the distance (such as Euclidean distance or cosine distance) between the semantic vectors of the payment intent credential and the order log, as the first semantic difference between the payment intent credential and the order log. The first semantic difference between the payment intent credential and the order log is positively correlated with the aforementioned distance.

[0099] When the first semantic difference between the payment intent credential and the order log exceeds a first preset semantic difference threshold, it indicates that the agent did not send the corresponding order instruction to the merchant system according to the purchase intent corresponding to the payment intent credential. The first LLM within the agent may have misunderstood the user's purchase intent. Therefore, the arbitration server can determine that the agent is in breach of contract. Conversely, when the first semantic difference between the payment intent credential and the order log is not greater than the first preset semantic difference threshold, it indicates that the agent did indeed send the corresponding order instruction to the merchant system according to the purchase intent corresponding to the payment intent credential. Therefore, the arbitration server can determine that the agent is not in breach of contract.

[0100] In other words, in step S2032, the payment server persistently stores the payment intent certificate in the evidence storage database, which can be used to prove the user's purchase intention and the user's authorization to the intelligent agent to purchase on their behalf. In step S2062, the intelligent agent persistently stores the order log in the evidence storage database, which can be used to prove what kind of product the intelligent agent actually ordered, the amount of the target product, and which merchant sold the product.

[0101] Furthermore, if the agent has selected a target product that matches its purchase intent, but the merchant fails to correctly deliver the target product to the user during the logistics process, the merchant will need to be held accountable. Therefore, after receiving the order instruction from the agent, and generating a confirmed fulfillment order that includes at least the user identifier, merchant identifier, product information of the target product, and the amount of the target product, the merchant system can also persistently store the generated confirmed fulfillment order in an evidence database to prove what kind of product the merchant confirmed required fulfillment.

[0102] Specifically, after the agent sends an order instruction to the merchant system, it can generate an order log corresponding to the order instruction and send the order log, the instruction identifier of the order instruction, and the token identifier of the payment token to be used to the evidence storage database. Simultaneously, it also sends the instruction identifier of the order instruction to the merchant system. The merchant system, after generating the aforementioned confirmation of fulfillment, sends the confirmation of fulfillment and the instruction identifier to the evidence storage database. The evidence storage database then persistently stores the received order log, instruction identifier, and token identifier from the agent, establishing a correlation between the order log and the instruction identifier and token identifier. Upon receiving the confirmation of fulfillment and instruction identifier from the merchant system, it can persistently store the received confirmation of fulfillment and instruction identifier, establishing a correlation between the confirmation of fulfillment and the instruction identifier. In this way, the payment intent certificate and order log stored in the evidence storage database are associated based on the token identifier, and the order log and confirmation of fulfillment are associated based on the instruction identifier.

[0103] Of course, after the agent sends the order instruction to the merchant system, it also needs to use a payment token to pay for the target product through the payment server. After creating a payment order for the target product, the payment server can return the order identifier to both the agent and the merchant system. Therefore, upon receiving the order identifier, the agent can also send the order log, token identifier, and order identifier corresponding to the order instruction to the evidence storage database for persistent storage. The evidence storage database then establishes a link between the order log, the token identifier, and the order identifier. Furthermore, after receiving the order identifier of the payment order, the merchant system can send the confirmed fulfillment order and the order identifier to the evidence storage database for persistent storage. The evidence storage database then establishes a link between the confirmed fulfillment order and the order identifier. In this way, the payment intent certificate and order log stored in the evidence storage database are linked based on the token identifier, and the order log and confirmed fulfillment order are linked based on the order identifier.

[0104] Regardless of the method used, as long as the payment intent voucher, order log, and confirmed fulfillment order stored in the evidence database can be linked, it is acceptable.

[0105] When the arbitration server receives an arbitration request from a user for a target product, in addition to performing the liability determination process for the intelligent agent as shown in steps S207-S208 based on the order identifier corresponding to the payment order for the target product carried in the arbitration request, it can also retrieve the confirmed performance order associated with the order log based on the same instruction identifier from the evidence storage database, or directly retrieve the confirmed performance order associated with the order identifier from the evidence storage database based on the order identifier carried in the arbitration request.

[0106] After obtaining the confirmed fulfillment order, the second LLM described above is used to determine the second semantic difference between the order log and the confirmed fulfillment order. In determining the second semantic difference, the semantic vector of the order log can be determined using the same method as in determining the first semantic difference. Similarly, in determining the semantic vector of the confirmed fulfillment order, the amount corresponding to the target product, the merchant identifier of the merchant system corresponding to the target product, and the product information of the target product can be used as the first, second, and third key fields of the confirmed fulfillment order, respectively. Then, the second LLM is used to encode the first, second, and third key fields of the confirmed fulfillment order, obtaining the semantic vectors corresponding to each of these three key fields. Finally, the semantic vectors corresponding to these three key fields are fused to obtain the semantic vector of the confirmed fulfillment order. Finally, the distance (such as Euclidean distance or cosine distance) between the semantic vector of the confirmed fulfillment order and the semantic vector of the order log can be determined using the second LLM, and this distance is used as the second semantic difference between the confirmed fulfillment order and the order log. The second semantic difference between the confirmed fulfillment order and the order log is positively correlated with the aforementioned distance.

[0107] When the second semantic difference between the confirmed order fulfillment and the order log exceeds the second preset semantic difference threshold, it indicates that the merchant system did not provide the user with the corresponding target product according to the order instruction. Therefore, the arbitration server can determine that the merchant system is in breach of contract. Conversely, when the second semantic difference between the confirmed order fulfillment and the order log does not exceed the second preset semantic difference threshold, it indicates that the merchant system did indeed provide the user with the target product according to the order instruction. Therefore, the arbitration server can determine that the merchant system is not in breach of contract.

[0108] In addition, after the payment server uses the user's payment account to process the payment order for the target product, it can also send the payment result and the order identifier of the payment order to the evidence storage database. This allows the database to persistently store the payment result and the order identifier, and establish a relationship between them. The payment result described in this specification includes at least the payment result indicating whether the payment order was successful or failed, and may also include the payment order itself.

[0109] Upon receiving an arbitration request from a user regarding the target product, before using the aforementioned method to determine the breach of contract liability of the intelligent agent and / or merchant system, the arbitration server can also determine the payment order corresponding to the order identifier carried in the arbitration request, which is the payment order used to pay for the target product. Then, it retrieves the payment result of the payment order from the evidence storage database and determines whether the obtained payment result is a successful payment. If so, the aforementioned method can be used to determine the breach of contract liability of the intelligent agent and / or merchant system. Otherwise, it indicates that the payment server did not use the user's user account to pay for the payment order, and therefore the arbitration request sent by the user can be rejected.

[0110] Using the above method, the evidence storage database can store the payment intent certificate, order log, confirmed fulfillment order, and payment result as key information for the purchase of target goods by the user through the smart agent. Specifically, the payment intent certificate and order log can be associated through the token identifier of the payment token; the order log and confirmed fulfillment order can be associated through the instruction identifier corresponding to the order instruction or the order identifier of the payment order; and the payment result is directly associated with the order identifier, thus achieving the association between these four types of key information. Through the aforementioned stored key information, the arbitration server can automatically determine the breach of contract liability of the smart agent and / or merchant system, ensuring the accuracy and efficiency of liability determination in subsequent customer service processes. The evidence storage database described in this embodiment may include a blockchain system to leverage the immutability of the decentralized or weakly centralized blockchain system to ensure the credibility of the stored key information.

[0111] The above describes an AI-based business execution system and method provided in the embodiments of this specification. Based on the same idea, this specification also provides corresponding devices, storage media, and electronic devices.

[0112] Figure 5 This is a schematic diagram of an AI-based business execution device provided in an embodiment of this specification. The device can be applied to an arbitration server and includes: The receiving module 500 is used to receive an arbitration request sent by a user for a target product. The amount corresponding to the target product is determined by the intelligent agent after receiving a payment token from the payment server. Based on the purchase intent corresponding to the payment intent credential, when a target product matching the purchase intent is found, the agent sends an order instruction for the target product to the merchant system corresponding to the target product and uses the payment token to pay the merchant system through the payment server. The payment intent credential is generated by the intelligent agent through interaction with the user using a pre-set first large language model (LLM). When the first LLM identifies that the user has a purchase intent, it generates and sends the purchase intent to the payment server. The payment token is generated by the payment server after receiving the authorization query message from the user based on the received payment intent credential and sending it to the intelligent agent. The acquisition module 501 is used to acquire the payment intent certificate and the order log corresponding to the order instruction from the evidence storage database; wherein, the payment intent certificate is persistently stored in the evidence storage database after the payment server receives the authorization confirmation message returned by the user; the order log is persistently stored in the evidence storage database after the intelligent agent sends the order instruction for the target product to the merchant system corresponding to the target product; The semantic difference determination module 502 is used to determine the first semantic difference between the payment intent certificate and the order log using a preset second LLM; The liability determination module 503 is used to determine the breach of contract liability of the intelligent agent based on the first semantic difference.

[0113] Optionally, the acquisition module 501 is specifically used to: determine the token identifier corresponding to the payment token used by the intelligent agent to pay for the target product through the payment server; and obtain the payment intent credential and order log associated with the token identifier from the evidence storage database; wherein, the evidence storage database pre-establishes an association between the payment intent credential and the token identifier, and the association between the payment intent credential and the token identifier is established by the evidence storage database after the payment server sends the payment intent credential and the token identifier corresponding to the payment token to the evidence storage database; the evidence storage database pre-establishes an association between the order log and the token identifier, and the association between the order log and the token identifier is established by the evidence storage database after the intelligent agent sends the order log corresponding to the order instruction and the token identifier corresponding to the payment token to the evidence storage database.

[0114] Optionally, the payment intent certificate may include at least the user's payable amount constraint, optional merchant constraint, and product description of the required goods; The order log corresponding to the order instruction includes at least: the amount corresponding to the target product, the merchant identifier of the merchant system corresponding to the target product, and the product information of the target product; The liability determination module 503 is specifically used to determine that the intelligent agent has breach of contract liability when the first semantic difference between the payment intention certificate and the order log is greater than a first preset semantic difference threshold, and to determine that the intelligent agent does not have breach of contract liability when the first semantic difference between the payment intention certificate and the order log is not greater than the first preset semantic difference threshold.

[0115] Optionally, the acquisition module 501 is further configured to, after the receiving module 500 receives the arbitration request sent by the user for the target product, retrieve a confirmed fulfillment order from the evidence storage database; the confirmed fulfillment order is generated and persistently stored in the evidence storage database by the merchant system corresponding to the target product after receiving the order placement instruction, and the confirmed fulfillment order at least includes the user's user identifier, the product information of the target product, and the amount of the target product; The semantic difference determination module 502 is further configured to determine the second semantic difference between the order log and the confirmed fulfillment order using a preset second LLM; The liability determination module 503 is further configured to determine that the merchant system has breach of contract liability when the second semantic difference is greater than the second preset semantic difference threshold, and to determine that the merchant system does not have breach of contract liability when the second semantic difference is not greater than the second preset semantic difference threshold.

[0116] Optionally, the liability determination module 503 is further configured to, before determining the breach of contract liability of the intelligent agent based on the first semantic difference, determine the payment order for paying the target product; obtain the payment result of the payment order from the evidence storage database; and determine that the obtained payment result is a successful payment; wherein the payment result is persistently stored in the evidence storage database after the payment server uses the user's payment account to pay for the payment order for paying the target product.

[0117] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can be used to perform the AI-based business execution method described above.

[0118] This specification also provides a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned AI-based business execution method.

[0119] based on Figure 2 , Figure 3 and Figure 4 The AI-based business execution method shown in this specification also provides embodiments. Figure 6 The diagram shows the structure of the electronic device. Figure 6 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile storage, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile storage into memory and then runs it to implement the aforementioned AI-based business execution method.

[0120] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. An AI-based business execution system, the system comprising: Intelligent agent, payment server, arbitration server, and evidence storage database; among which: The intelligent agent is used to interact with the user through a pre-set first large language model (LLM). When the first LLM recognizes that the user has a purchase intention, it generates a payment intention certificate based on the purchase intention and sends the payment intention certificate to the payment server. The payment server is configured to send an authorization inquiry message to the user based on the received payment intent credential, generate a payment token and send it to the smart agent after receiving the authorization confirmation message returned by the user, and persistently store the payment intent credential in the evidence storage database. After receiving the payment token, the intelligent agent searches for target products that match the purchase intent corresponding to the payment intent credential. When a target product is found, it sends an order instruction for the target product to the merchant system corresponding to the target product, uses the payment token to pay the amount corresponding to the target product to the merchant system through the payment server, and persistently stores the order log corresponding to the order instruction in the evidence storage database. The arbitration server is used to, when receiving an arbitration request sent by the user for the target product, retrieve the payment intent certificate and the order log from the evidence storage database, determine the first semantic difference between the payment intent certificate and the order log using a preset second LLM, and determine the breach of contract liability of the intelligent agent based on the first semantic difference.

2. The system as described in claim 1, wherein the payment server is specifically configured to send the payment intent certificate and the token identifier corresponding to the payment token to the evidence storage database; The evidence storage database is specifically used to persistently store the payment intent certificate and the token identifier, and to establish an association between the payment intent certificate and the token identifier; Specifically, the intelligent agent is used to send the order log corresponding to the order instruction and the token identifier corresponding to the payment token to the evidence storage database. The evidence storage database is specifically used to persistently store the order logs and the token identifier, and to establish an association between the order logs and the token identifier; The arbitration server is specifically used to determine the token identifier corresponding to the payment token used by the smart agent to pay for the target product through the payment server, and to obtain the payment intent certificate and order log associated with the token identifier from the evidence storage database.

3. The system as described in claim 1, wherein the intelligent agent is specifically configured to, based on the purchase intention, at least determine the user's payable amount constraint, optional merchant constraint, and product description of the required goods, and generate a payment intention certificate that includes at least the payable amount constraint, the optional merchant constraint, and the product description; The order log corresponding to the order placement instruction includes at least: The amount corresponding to the target product, the merchant identifier of the merchant system corresponding to the target product, and the product information of the target product; The arbitration server is specifically used to determine that the agent has breach of contract liability when the first semantic difference between the payment intention certificate and the order log is greater than a first preset semantic difference threshold, and to determine that the agent does not have breach of contract liability when the first semantic difference between the payment intention certificate and the order log is not greater than the first preset semantic difference threshold.

4. The system of claim 1, further comprising: The merchant system corresponding to the target product; The merchant system is specifically used to generate a confirmed fulfillment order that includes at least the user identifier, the product information of the target product, and the amount of the target product after receiving the order placement instruction, and to persistently store the confirmed fulfillment order in the evidence storage database. The arbitration server is also used to retrieve the confirmed fulfillment order from the evidence storage database, determine the second semantic difference between the order log and the confirmed fulfillment order using a preset second LLM, and determine that the merchant system has breach of contract liability when the second semantic difference is greater than the second preset semantic difference threshold, and determine that the merchant system does not have breach of contract liability when the second semantic difference is not greater than the second preset semantic difference threshold.

5. The system as described in claim 1, wherein the payment server is further configured to, after using the user's payment account to make payment for the payment order for the target goods, persistently store the payment result of the payment order in the evidence storage database; The arbitration server is also used to, after receiving the arbitration request sent by the user for the target product, determine the payment order for the target product before determining the breach of contract liability of the intelligent agent, obtain the payment result of the payment order from the evidence storage database, and determine that the obtained payment result is a successful payment.

6. An AI-based business execution method, the method comprising: The arbitration server receives an arbitration request from a user regarding a target product. The amount corresponding to the target product is determined by the agent receiving a payment token from the payment server. Based on the purchase intent corresponding to the payment intent credential, the agent searches for a target product matching the purchase intent, sends an order instruction for the target product to the merchant system, and uses the payment token to pay the merchant system through the payment server. The payment intent credential is generated by the agent interacting with the user through a pre-set first large language model (LLM). When the first LLM identifies the user's purchase intent, it generates and sends the credential to the payment server. The payment token is generated by the payment server based on the received payment intent credential, sending an authorization query message to the user, and receiving an authorization confirmation message from the user, which is then sent to the agent. The payment intent credential and the order log corresponding to the order instruction are obtained from the evidence storage database; wherein, the payment intent credential is persistently stored in the evidence storage database after the payment server receives the authorization confirmation message returned by the user; the order log is persistently stored in the evidence storage database after the intelligent agent sends an order instruction for the target product to the merchant system corresponding to the target product; The first semantic difference between the payment intent certificate and the order log is determined using a preset second LLM; Based on the first semantic difference, the breach of contract liability of the intelligent agent is determined.

7. The method as described in claim 6, wherein obtaining the payment intent certificate and the order log corresponding to the order placement instruction from the evidence storage database specifically includes: Determine the token identifier corresponding to the payment token used by the intelligent agent to pay for the target product through the payment server; The payment intent credential and order log associated with the token identifier are retrieved from the evidence storage database. The evidence storage database pre-establishes an association between the payment intent credential and the token identifier, which is established by the evidence storage database after the payment server sends the payment intent credential and the token identifier corresponding to the payment token to the evidence storage database. Similarly, the evidence storage database pre-establishes an association between the order log and the token identifier, which is established by the evidence storage database after the agent sends the order log corresponding to the order instruction and the token identifier corresponding to the payment token to the evidence storage database.

8. The method of claim 6, wherein the payment intent certificate includes at least the user's payable amount constraint, optional merchant constraint, and product description of the required goods; The order log corresponding to the order placement instruction includes at least: The amount corresponding to the target product, the merchant identifier of the merchant system corresponding to the target product, and the product information of the target product; Based on the first semantic difference, the breach of contract liability of the intelligent agent is determined, specifically including: When the first semantic difference between the payment intent certificate and the order log is greater than a first preset semantic difference threshold, the agent is determined to have breach of contract liability; when the first semantic difference between the payment intent certificate and the order log is not greater than the first preset semantic difference threshold, the agent is determined not to have breach of contract liability.

9. The method of claim 1, further comprising, after receiving an arbitration request from a user regarding the target product: Retrieve the confirmed fulfillment order from the evidence storage database; The confirmed fulfillment order is generated and persistently stored in the evidence database by the merchant system corresponding to the target product after receiving the order placement instruction. The confirmed fulfillment order includes at least the user's user identifier, the product information of the target product, and the amount of the target product. The second semantic difference between the order log and the confirmed fulfillment order is determined using a preset second LLM; When the second semantic difference is greater than the second preset semantic difference threshold, it is determined that the merchant system has breach of contract liability; when the second semantic difference is not greater than the second preset semantic difference threshold, it is determined that the merchant system does not have breach of contract liability.

10. The method of claim 6, wherein before determining the breach of contract liability of the intelligent agent based on the first semantic difference, the method further comprises: Determine the payment order used to pay for the target goods; Retrieve the payment result of the payment order from the evidence storage database; The obtained payment result is determined to be a successful payment; wherein, the payment result is the payment result of the payment order made by the payment server after using the user's payment account to make payment for the target product, and is persistently stored in the evidence storage database.

11. An AI-based business execution device, the device comprising: The receiving module is used to receive arbitration requests sent by users for target products. The amount corresponding to the target product is determined by the intelligent agent after receiving a payment token from the payment server. Based on the purchase intent corresponding to the payment intent credential, when a target product matching the purchase intent is found, the agent sends an order instruction for the target product to the merchant system corresponding to the target product and uses the payment token to pay the merchant system through the payment server. The payment intent credential is generated by the intelligent agent through interaction with the user using a pre-set first large language model (LLM). When the first LLM identifies that the user has a purchase intent, it generates and sends the purchase intent to the payment server. The payment token is generated by the payment server after receiving the authorization query message from the user based on the received payment intent credential and sending it to the intelligent agent. The acquisition module is used to acquire the payment intent certificate and the order log corresponding to the order instruction from the evidence storage database; wherein, the payment intent certificate is persistently stored in the evidence storage database after the payment server receives the authorization confirmation message returned by the user; the order log is persistently stored in the evidence storage database after the intelligent agent sends the order instruction for the target product to the merchant system corresponding to the target product; The semantic difference determination module is used to determine the first semantic difference between the payment intent certificate and the order log using a preset second LLM; The liability determination module is used to determine the breach of contract liability of the intelligent agent based on the first semantic difference.

12. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 6-10.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method described in any one of claims 6-10.

14. A computer program product comprising a computer program that, when executed by a processor, implements the method described in any one of claims 6-10.

Images