Chat system for performing a task comprising multiple rounds

Abstract

The present invention relates generally to computer systems utilizing computational models, and specifically to a chat system for performing a task comprising multiple turns. A chat system for performing a task comprising multiple turns includes a state manager, computational resources, a workflow, base operators, and an intervention component. The state manager is configured to structure environment variables associated with the task. The workflow invokes the computational resources to perform operations associated with a current turn of the task. The base operators invoke the computational resources to provide a graphical user interface to a human user. The intervention component invokes the computational resources to intervene in the performance of a subsequent subtask based on completion of a preceding task. The chat system according to embodiments facilitates a reproducible, controllable, and verifiable interaction process between multiple principals, including a human user and an agent, in a multi-turn task.

Description

Technical Field

[0001] This invention generally relates to computer systems utilizing computational models, and more specifically to chat systems for performing tasks involving multiple rounds. Background Technology

[0002] In interaction scenarios involving multiple agents (e.g., human-to-human, human-to-machine, and machine-to-machine interactions), especially in multi-round interactions, input from one agent can influence input from another. In this sense, existing technologies provide online interaction platforms for purposes such as online chat, social experiments, and business or investment analysis. With the development of artificial intelligence, these online interaction platforms may further incorporate intelligent agents based on large language models as one or more agents within the interaction scenario.

[0003] Some existing solutions offer multi-agent social experiment systems involving only human subjects, such as Social Lab (see *Social Lab User Guide*, Cambridge University Press, 2021). These systems simulate group behavior and are essentially closed experimental platforms supporting only interactions between human subjects. However, they do not involve intelligent agents participating in social experiments as interacting subjects, and therefore cannot simulate scenarios of "human-machine hybrid interaction."

[0004] Several existing solutions offer chatbot applications, such as ChatGPT (see the OpenAI Platforms documentation, 2025). These chatbot applications can perform natural language processing and reasoning based on human input, primarily involving dialogue between a specific human subject and a specific intelligent agent. However, such chatbots struggle to achieve group interaction and cannot be used to simulate social experimental conditions; they can only serve as data generation and collection platforms.

[0005] Some existing solutions provide general-purpose chat systems that can involve both intelligent agents and human subjects (such as Discord, see the Discord Developer's Manual (2023)). While these general-purpose chat systems support multi-agent interaction, it is difficult to configure agents to assume different roles and be constrained by those roles accordingly. This makes it difficult for agents to follow role-specific logic and execute standardized processes corresponding to those roles. Furthermore, such general-purpose chat systems do not impose constraints on output, only supporting output in natural language rather than structured output. These general-purpose chat systems suffer from the core obstacles of being "unreproducible, uncontrollable, and unverifiable," making it difficult to trace and reproduce the entire process of online chat, social experiments, business or investment analysis, to dynamically intervene in the process at runtime, and to verify the results of experiments or analyses.

[0006] In summary, there is a need to provide a system that supports interaction between multiple agents, enabling reproducible, controllable, and verifiable interaction processes between multiple agents, including humans and intelligent agents. Summary of the Invention

[0007] This invention is provided to provide a better interaction process between multiple entities in multi-round task execution.

[0008] One aspect of the present invention provides a chat system for performing a task comprising multiple rounds, each round comprising chat between multiple subjects, each subject being pre-assigned a role in each round, the subjects including human users or intelligent agents, the task comprising multiple subtasks, each subtask being pre-configured with a unique identifier for a prerequisite task to be completed before that subtask, wherein the prerequisite task is a subtask among the multiple subtasks, the chat system comprising: a state manager for configuring environment variables associated with the task in a structured form, the environment variables including: a first decision result of the human user associated with the round, a second decision result of the intelligent agent associated with the round, a settlement result associated with the round, and a settlement result accumulated from the start of the task to the current round; and computing resources; a workflow implemented as a state machine associated with the current round, the workflow calling the computing resources to: read the environment variables associated with the previous round; rewrite the environment variables of the previous round based on the role assigned to the subject in the current round; and execute the current round based on the rewritten environment variables. The decision-making process includes: determining the outcome of the current round's decision based on the first and second decision outcomes of the current round; performing settlement on the current round based on the outcome of the current round's decision; updating environmental variables associated with the current round based on the settlement outcome associated with the current round, wherein the settlement outcome associated with the current round and the accumulated settlement outcome from the start of the task to the current round are updated in the environmental variables associated with the current round; and a basic operator that invokes the computing resources to provide a graphical user interface to the human user in the current round, wherein the graphical user interface is used to enable the human user to interact with the agent, enable the human user to input the first decision outcome, and present feedback to the human user on the first decision outcome; and an intervention component that invokes the computing resources to: detect a unique identifier of a prerequisite task associated with a subtask to be executed; and, in response to the detection result indicating that the prerequisite task is not completed, add a lock record to prevent the human user or the agent from executing the subtask.

[0009] In the chat system described above, the state manager is used to configure each item of the environment variable through key-value pairs, wherein the data type, value range, and validation rules of the value associated with the key are predetermined.

[0010] In a chat system as described in any of the above, the task is associated with an experiment, the session is associated with a complete experiment, multiple rounds are associated with a session, the environment variables include experiment-level environment variables, session-level environment variables, and round-level environment variables, and the state manager is used to configure independent keys and lifecycles for the experiment-level environment variables, the session-level environment variables, and the round-level environment variables.

[0011] As in any of the chat systems described above, the workflow invokes the computing resources to: write environment variables associated with the current round via atomic transactions.

[0012] In a chat system as described in any of the above, the workflow invokes the computing resources to: initiate the atomic transaction; and perform checks based on the version number associated with the optimistic lock.

[0013] If the result of the check indicates a hit, the atomic transaction is completed, and the version value associated with the optimistic lock is updated; if the result of the check indicates a miss, a retry is performed.

[0014] As described in any of the above-described chat systems, the environment variables further include a tracking identifier associated with the execution of a settlement, and the workflow invokes the computing resources to: determine whether a tracking identifier obtained through a retry exists in the environment variables associated with the current round; and, in response to determining that a tracking identifier obtained through a retry exists in the environment variables associated with the current round, refuse to perform a write in the atomic transaction.

[0015] As described in any of the above-described chat systems, the environment variables further include variables associated with the execution of the subtask in the current round; changes in state associated with updates to the environment variables are maintained via an event log, and the workflow invokes the computing resources to: generate records of events associated with the state changes; write the records of the events to an event stream in the event log in an append-only manner; and write variables associated with the execution of the subtask in the current round and the accumulated settlement results from the start of the task to the current round to the event log.

[0016] As described in any of the above chat systems, the workflow invokes the computing resources to: periodically generate snapshots of event logs associated with updates to the environment variables.

[0017] As described in any of the above chat systems, the workflow includes an orchestrator and a plurality of execution tools, the orchestrator invoking one or more of the plurality of execution tools according to the state machine to execute a subtask in the current round.

[0018] In a chat system as described in any of the foregoing, the orchestrator is configured to: be allowed to read the snapshot only in read operations; be allowed to invoke a whitelisted tool among the plurality of execution tools only in scheduling operations, the whitelisted tool excluding the large language model invoked by the agent; be allowed to update the event log only in an append-only manner in write operations; and be allowed to evaluate the termination conditions of the task only in control operations and signal to terminate the task in response to the termination of the task.

[0019] As described in any of the above chat systems, the plurality of execution tools include a decision tool for invoking a large language model to perform decisions based on the roles assigned to the agent.

[0020] In any of the chat systems described above, the decision-making tool is configured to: perform few-shot training on a large language model to be invoked using structured prompts based on the role assigned to the agent; and invoke the trained large language model to perform a decision based on the role assigned to the agent.

[0021] In any of the chat systems described above, the decision tool is configured to instruct the invoked large language model to generate output in accordance with the specifications of JSON data structures and constraints.

[0022] In any of the chat systems described above, the decision-making tool is configured to grant permission to read the environment variables to the large language model to be invoked.

[0023] The chat system described in any of the above further includes: an audit component that invokes the computing resources to: analyze a snapshot of the event log; and generate a report based on the results of the analysis.

[0024] The chat system as described in any of the above, the workflow includes the Dify workflow, and / or the tasks include social experiments and business scenario tasks.

[0025] The chat system according to embodiments of the present invention facilitates a reproducible, controllable, and verifiable interaction process among multiple subjects, including human users and intelligent agents, in multi-round tasks. Attached Figure Description

[0026] Various embodiments of the present invention are described in conjunction with the accompanying drawings.

[0027] Figure 1This is a schematic block diagram of a chat system for performing tasks involving multiple rounds, according to some embodiments of the present invention.

[0028] Figure 2 This is a flowchart of a first process associated with the control of subtask execution by a chat system according to some embodiments of the present invention.

[0029] Figure 3 This is a flowchart of a second process associated with the updating of environment variables by a chat system according to some embodiments of the present invention.

[0030] Figure 4 This is a flowchart of a third process associated with the updating of environment variables by a chat system according to some embodiments of the present invention.

[0031] Figure 5 This is a flowchart of a fourth process associated with the updating of environment variables by a chat system according to some embodiments of the present invention.

[0032] Figure 6 The diagram illustrates an orchestration process for a round of tasks using a workflow, according to some embodiments of the present invention.

[0033] Figure 7 Details of an experimental design for performing a task in one round, according to some embodiments of the present invention, are shown.

[0034] Figure 8 A first interface associated with role configuration and a second interface associated with environment variable configuration are shown according to some embodiments of the present invention.

[0035] Figure 9 A third interface associated with human users making decisions is shown according to some embodiments of the present invention.

[0036] Figure 10 A fourth interface is shown, including environmental variables in a round, according to some embodiments of the present invention.

[0037] Figure 11 A fifth interface is shown, including environmental variables in another round, according to some embodiments of the present invention.

[0038] Figure 12 A sixth interface associated with the execution of the basic operators is shown according to some embodiments of the present invention.

[0039] Figure 13 A seventh interface associated with the execution of the basic operators is shown according to some embodiments of the present invention.

[0040] Figure 14An eighth interface associated with the execution of basic operators is shown according to some embodiments of the present invention. Detailed Implementation

[0041] Exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings, wherein, unless otherwise expressly stated, the same or similar reference numerals in different drawings denote the same or similar elements. Furthermore, it should be noted that exemplary embodiments of the present invention may perform the steps of the corresponding methods in a different order than that shown and described in the specification. In some embodiments of the present invention, the method may include more or fewer steps than those described in the specification and shown in the accompanying drawings. Moreover, a single step used in some embodiments of this specification may be broken down into multiple steps in other embodiments, or multiple steps used in some embodiments of this specification may be combined into a single step in other embodiments.

[0042] Numerous specific details are set forth in the following description. However, it should be understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description.

[0043] References to "an embodiment," "an embodiment," "an exemplary embodiment," etc., in the specification indicate that the described embodiment may include a specific feature, structure, or characteristic; however, not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in connection with an embodiment, it is believed that the influence of such feature, structure, or characteristic on such feature, structure, or characteristic in conjunction with other embodiments, whether explicitly described or not, is within the knowledge of those skilled in the art.

[0044] For the purposes of this invention, the phrase "A and / or B" means (A), (B), or (A and B). For the purposes of this invention, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0045] In this application, the term "agent" refers to an agent capable of perceiving its environment and taking actions to perform specific goals. An agent primarily refers to software code. An agent can be executed by the computing resources of a computing device. An agent can invoke corresponding models through an Application Programming Interface (API) and call appropriate tools (e.g., document readers, code interpreters, calculators, etc.) to interact with various forms of input or to implement corresponding functions.

[0046] In this application, the term "task" can refer to a complete process involving multiple subjects chatting over multiple rounds to reach a final decision. Typical examples of a "task" in this invention, as an example, could include social experiments, business and investment analysis, mock trials, and so on.

[0047] In this application, the term "subtask" can refer to a portion of a task. As an example, a subtask can be associated with a round. For instance, a subtask can be associated with one round, or a subtask can be associated with multiple rounds, or a round can be associated with multiple subtasks.

[0048] In some embodiments of the present invention, a chat system is provided.

[0049] Figure 1 A schematic block diagram of a chat system 100 for performing tasks comprising multiple rounds, according to some embodiments of the present invention, is shown. For illustrative purposes, Figure 1 The document also illustrates multiple entities for interaction via the chat system 100, which may include human users or intelligent agents.

[0050] As an example, Figure 1 The multiple entities shown include a first entity 102, a second entity 104, a third entity 106, and a fourth entity 108. As an example, the first entity 102 and the second entity 104 can be human users, while the third entity 106 and the fourth entity 108 can be intelligent agents. It should be understood that the entities that can interact via the chat system 100 can be, in comparison to… Figure 1 The number of subjects shown may be more or fewer, and the number of human subjects and / or intelligent agents may also be related to... Figure 1 The quantities shown may be the same or different.

[0051] In some embodiments, each agent can invoke a corresponding model via an API to act as a chatbot and chat with other agents and / or human users. As examples, the model may include a large language model, a multimodal model, a multimodal language model, etc. In some embodiments, multiple models invoked by multiple agents may be deployed locally on the chat system 100. In some embodiments, multiple models invoked by multiple agents may be deployed remotely on the chat system 100, for example, in the cloud. In some embodiments, some of the models invoked by agents may be deployed locally on the chat system 100, while others may be deployed remotely. In some embodiments, each agent can invoke various tools to interact with various forms of input or to perform corresponding functions. For example, an agent may invoke a PDF reader to read PDF documents. An agent may invoke a Python interpreter to interact with Python code. An agent may invoke a calculator to perform calculations.

[0052] According to an embodiment of the present invention, the chat system 100 can be used to perform a task comprising multiple rounds, each round of which includes chat between multiple subjects. Each round may include... Figure 1 The chat between some or all of the four main entities shown is illustrated. Each entity can be pre-assigned a role to play in the task execution before the task is performed. The task executed by the chat system 100 can include multiple subtasks, each subtask being pre-configured with a unique identifier indicating a prerequisite task to be completed before that subtask. A prerequisite task is also a subtask among multiple subtasks. As an example, the unique identifier of a prerequisite task can be a task identifier (ID), task name code, or other unique identifier that uniquely indicates the prerequisite task. The set of unique identifiers for prerequisite tasks can be pre-configured by the chat system 100 based on the task to be performed.

[0053] In some embodiments, the chat system 100 may include a state manager 110. The state manager 110 may be used to configure task-related environment variables in a structured manner. Environment variables may include: a first decision result of a human user associated with a round, a second decision result of an agent associated with a round, a settlement result associated with a round, and a cumulative settlement result from the start of the task to the current round. Those skilled in the art will understand that environment variables may also include other variables used to indicate the execution state of the task during the execution of the task by the chat system 100.

[0054] In some embodiments, the chat system 100 may further include computing resources 120. Computing resources 120 may include a central processing unit (CPU), a graphics processing unit (GPU), and various other processing units or cores (e.g., arithmetic logic units, integer units, floating-point units, tensor units, ray tracing cores, etc.).

[0055] In some embodiments, the chat system 100 may further include a workflow 130. The workflow 130 may be implemented as a state machine associated with the current round of task execution. The workflow 130 may invoke computing resources 120 to execute individual subtasks and manage and maintain environment variables.

[0056] In the current round of task execution, workflow 130 can read the environment variables associated with the previous round of task execution and rewrite the environment variables of the previous round based on the role assigned to each agent in the current round. Workflow 130 can also execute the decision for the current round based on the read and rewritten environment variables. The result of the decision executed by workflow 130 in the current round can be determined based on the first decision result of the human user and the second decision result of the agent in the current round. Workflow 130 can also perform settlement for the current round based on the result of the decision and update the environment variables associated with the current round based on the writing of the settlement result associated with the current round. In the environment variables associated with the current round, the settlement result associated with the current round and the settlement result accumulated from the start of the task to the current round are updated.

[0057] In some embodiments, the chat system 100 may further include a basic operator 140. The basic operator 140 may invoke computing resources 120 to provide a graphical user interface (GUI) to a human user in the current round. The human user can interact with the agent via the GUI and input a first decision result via the GUI. Additionally, the GUI may present feedback to the human user regarding the first decision result. This feedback may include feedback from the agent to the first decision result made by the human user, or feedback from other human users to the first decision result made by that human user.

[0058] In some embodiments, the chat system 100 may further include an intervention component 150. The intervention component 150 may invoke computing resources 120 to detect a unique identifier of a prerequisite task associated with the subtask to be executed, and, in response to the detection result indicating that the prerequisite task is incomplete, add a lock record to prevent a human user or intelligent agent from executing the subtask to be executed. The intervention component 150 controls the execution of the subtask by adding a lock record. The control of the subtask execution by the intervention component 150 is described below. Figure 2 Further detailed description.

[0059] The chat system 100 according to some embodiments of the present invention can support interaction between multiple subjects, including human users and intelligent agents, and each subject can be pre-assigned a role to be played in task execution. Through the configuration of environment variables, each subject is subject to specific constraints of its assigned role during task execution, and each subject records its task execution status by updating the environment variables during task execution; the execution of the task in the current round depends on the environment variables associated with the previous round. This makes the interaction between multiple subjects controllable. Furthermore, by recording the environment variables, the interaction process between multiple subjects can be reproduced by retrieving the environment variables after the task is completed, which is beneficial for verifying the interaction process. In addition, intelligent agents or other human users can provide feedback on the decisions made by human users, which further facilitates the verification of the interaction results.

[0060] In some embodiments, workflow 130 may include a Dify workflow. This facilitates breaking down complex tasks into multiple subtasks to reduce the complexity of task execution. It also helps reduce the agent's reliance on prompts when performing tasks and lowers the requirements on the agent's reasoning capabilities for its calls to large language models. Additionally or alternatively, tasks that can be performed via chat system 100 may include, but are not limited to, social experiments and business scenario tasks. These social experiments and business scenario tasks can be configured into chat system 100 by configuring environment variables, allowing human users and / or agents to assume specific roles and make decisions for these tasks through multiple rounds of interaction.

[0061] As an example, social experiments can include the Iowa Gambling Task (IGT). The IGT is a classic psychological experiment that assesses people's decision-making ability in uncertain situations.

[0062] As an example, social experiments could include the Heinz moral dilemma experiment. This experiment introduces a simulated trial scenario, referencing the trial procedures of Anglo-American law, where participants take on roles such as judge, juror, and witness, representing different ethical stances to participate in the trial process, complete debates and trial-related tasks, and ultimately determine whether Heinz is guilty.

[0063] As an example, business scenario tasks may include market research.

[0064] In some embodiments, the state manager 110 can configure each item of an environment variable using key-value (KV) pairs. The data type, value range, and validation rules of the value associated with the key are predetermined. Environment variables are associated with tasks, which may correspond to an experiment executed over multiple rounds, each round corresponding to a session, and a session corresponding to a complete experiment. This defines three scopes for environment variables: task, session, and round. Environment variables can include experiment-level, session-level, and round-level environment variables. The state manager 110 can configure independent keys and lifecycles for experiment-level, session-level, and round-level environment variables. This strongly typed key-value pair configuration allows the state manager 110 to configure task-associated environment variables in a structured manner, which facilitates the maintenance and validation of environment variables, thereby promoting control over the entire interaction process.

[0065] In some embodiments, workflow 130 can maintain environment variables through atomic transactions. This helps avoid repeated writing to environment variables and isolates task execution from environment variable updates, thereby saving computing resources 120 and ensuring task reliability. The process of maintaining environment variables in workflow 130 is described below. Figures 3 to 5 Let me describe it in more detail.

[0066] In some embodiments, the chat system 100 may optionally include an audit component 160. The audit component 160 may invoke computing resources 120 to analyze snapshots of the event logs and generate reports based on the analysis results. The event logs are associated with updates to environment variables in workflow 130 and can specifically reflect these updates.

[0067] By using snapshots of event logs, the specific process of task execution status changes for multiple entities can be reflected. Furthermore, by employing audit component 160 to analyze the snapshots and generate reports, the entire task execution process can be understood more conveniently.

[0068] In some embodiments, workflow 130 may include multiple components. In some embodiments, workflow 130 may include an orchestrator 132 and multiple execution tools 134. The orchestrator 132 may invoke one or more of the multiple execution tools 134 according to a state machine or orchestration process to execute subtasks in the current round.

[0069] In some embodiments, orchestrator 132 may be permitted to read only snapshots of the event log in read operations, but not user-identifiable information (PII) or global environment variables affecting the entire task. Additionally or alternatively, orchestrator 132 may be permitted to invoke only whitelisted tools among multiple execution tools 134 in scheduling operations. Whitelisted tools may exclude large language models invoked by agents interacting via chat system 100. Additionally or alternatively, in some embodiments, orchestrator 132 may be permitted to update the event log only in an append-only manner in write operations, and not modify the event log for updates. Furthermore, in write operations, orchestrator 132 may only be able to write values ​​of environment variables for specific scopes through invoked whitelisted tools. Additionally or alternatively, orchestrator 132 may be permitted to evaluate task termination conditions only in control operations and signal the termination of the task in response to its termination. As an example, in terms of control operations, the orchestrator 132 is only allowed to evaluate whether the number of rounds the task has been executed has reached a preset round threshold, and in response to determining that the number of rounds has reached the preset round threshold, issues a "end task" signal, but is not allowed to modify the task's execution rules. By restricting the orchestrator 132's permissions in task execution and environment variable maintenance, it can be ensured that task execution and environment variable updates are safe and reliable.

[0070] In some embodiments, the plurality of execution tools 134 may include decision tools.

[0071] In some embodiments, the decision-making tool can invoke a large language model to perform decisions based on the agent's assigned role. The decision-making tool can perform few-shot training on the large language model to be invoked, using structured cue words based on the agent's assigned role. The trained large language model obtained through this few-shot training can then be invoked by the decision-making tool, enabling it to perform decisions based on the agent's assigned role. This helps the decision-making tool provide more reliable output in a stable format, reducing formatting error rates. By providing preferred inference strategies in the training samples, policy alignment of the decision-making tool can be achieved, reducing deviations and illusions. Providing examples in the training samples also enables the model to make consistent decisions even in anomalous situations. Furthermore, by providing white-box examples in the samples, the decision-making tool can additionally provide the reasons for making decisions when invoking the trained large language model, which improves the controllability and auditability of the decision-making process and results.

[0072] In some embodiments, the decision-making tool can also instruct the invoked large language model to generate output in accordance with the specifications of JSON data structures and constraints. This helps to constrain the decision-making tool to output in a structured form that meets its role requirements.

[0073] In some embodiments, the decision-making tool may also grant the large language model to read environment variables. This allows the large language model to directly read environment variables and make decisions based on those variables, which helps save communication resources and enables the large language model to make reliable decisions.

[0074] Figure 2 The illustration depicts a first process associated with the control of subtask execution in a chat system according to some embodiments of the present invention. The first process may be... Figure 1 The intervention component 150 in the invention is executed, but the scope of the invention is not limited thereto.

[0075] like Figure 2 As shown, the first process may include step 210: submitting the subtask to be executed.

[0076] As an example implementation, human users can submit subtasks to be executed by inputting information through buttons, input boxes, area dragging, etc. on the graphical user interface.

[0077] In some embodiments, the first process may include step 220: determining whether all the preceding tasks associated with the subtask have been completed.

[0078] A prerequisite task refers to another subtask that must be completed before a subtask can be executed. A subtask can be associated with one or more prerequisite tasks. For example, in a mock court scenario, when an agent acting as the defendant performs the cross-examination subtask, a human user or agent acting as the plaintiff is required to first complete the evidence presentation subtask. In this case, the evidence presentation subtask can be considered a prerequisite task for the cross-examination subtask. As an exemplary implementation, since each subtask is pre-configured with a unique identifier for a prerequisite task to be completed before that subtask, the current state of each prerequisite task for that subtask can be determined using this unique identifier. The execution status of a task can be indicated by environment variables. If the current state of all prerequisite tasks indicates that execution has been completed, it can be determined that all prerequisite tasks associated with that subtask have been completed. If the current state of one or more prerequisite tasks associated with the subtask to be executed indicates that they are being executed or have not yet been executed, it can be determined that not all prerequisite tasks associated with that subtask have been completed.

[0079] In some embodiments, in response to determining in step 220 that the prerequisite tasks have not all been completed (i.e., there are still prerequisite tasks associated with the subtask to be executed that have not been completed), the first process may include step 230: inserting a lock record to prevent the execution of the subtask to be executed.

[0080] If one or more of the preceding tasks associated with the subtask to be executed have not yet been completed, the execution of the subtask can be prevented by inserting a lock record into the subtask until all its preceding tasks have been completed.

[0081] In some embodiments, in response to determining in step 220 that all preceding tasks have been completed, the first process may include step 240: executing the subtask to be executed.

[0082] The subtask can be executed only after all the prerequisite tasks associated with it have been completed.

[0083] In some embodiments, the first process may include step 250: updating environment variables.

[0084] After a subtask is executed, the environment variables associated with that subtask's execution can be updated accordingly. This can be done by writing to the environment variables. Further details on updating environment variables are provided below. Figures 3 to 5 Let me describe it in detail.

[0085] In some embodiments, in response to the completion of a subtask to be executed, if other subtasks that use that subtask as a prerequisite task are locked due to that task, those other subtasks can be unlocked accordingly.

[0086] In some embodiments, the first process may include step 260: notifying the subject that the subtask to be executed has been executed.

[0087] In some embodiments, WebSocket can be used to push messages to the entities performing the task.

[0088] Figure 3 This illustrates a second process associated with updating environment variables in a chat system according to some embodiments of the present invention.

[0089] In some embodiments, the second process may include step 310: writing environment variables associated with the current round via an atomic transaction.

[0090] Step 310 can separate the updating of environment variables from the execution of tasks, so that the computations, reasoning, etc. associated with the task are completed outside the atomic transactions used for updating environment variables.

[0091] In some embodiments, the second process may include step 320: periodically generating snapshots of event logs associated with updates to environment variables.

[0092] An event log can include one or more entries, each indicating a record of an event generated in response to an update of environment variables. These event records indicated by the entries in the event log can form an event stream, which reflects changes in the task execution state. By periodically generating snapshots of the event log, the task execution state at that time can be recorded. When it is necessary to reproduce the interaction process, the task execution state at any point in time can be reconstructed by replaying the snapshot.

[0093] In low-concurrency scenarios, session-level serialization can also be used. By binding a session to an executor, the execution of subtasks and the updating of variables can be carried out sequentially using a single thread or a queue.

[0094] In scenarios with high concurrency and reliability requirements, using this atomic transaction combined with optimistic locking for updating environment variables is particularly advantageous. On one hand, atomic transactions allow for a one-time write to environment variables, effectively reducing the computational, storage, and communication overhead associated with environment variable updates. On the other hand, optimistic locking ensures the consistency of environment variables, thereby improving the reliability of task execution.

[0095] Figure 4 This illustrates a third process associated with the updating of environment variables in a chat system according to some embodiments of the present invention. The third process is referenced above. Figure 3 The described step 310 is related, but the process of the present invention is not limited thereto.

[0096] In some embodiments, the third process may include step 410: initiating an atomic transaction.

[0097] As an example, an atomic transaction can be triggered in response to the completion of a subtask to write environment variables associated with the execution of that subtask.

[0098] In some embodiments, the third process may include step 420: performing a check based on the version number associated with the optimistic lock to determine whether the version number associated with the optimistic lock is hit.

[0099] As an example implementation, the hit status of the version number associated with the optimistic lock can be determined by whether the version number associated with the optimistic lock conflicts with the recorded version number. For example, a version number conflict can be used to determine that the version number associated with the optimistic lock has not been hit, and a version number non-conflict can be used to determine that the version number associated with the optimistic lock has been hit.

[0100] In some embodiments, in response to determining in step 420 that the version number associated with the optimistic lock has been matched, the third process may include step 430: completing the atomic transaction and updating the version value associated with the optimistic lock.

[0101] The version number associated with an optimistic lock is linked to the execution of an atomic transaction (i.e., the writing of environment variables). As an example implementation, after the corresponding atomic transaction is completed, the version value associated with the optimistic lock can be incremented by a predetermined value (e.g., 1).

[0102] In some embodiments, in response to determining in step 420 that the version number associated with the optimistic lock was not hit, the third process may include step 440: performing a retry.

[0103] As an example implementation, the execution of the corresponding subtask can be retried in response to the determination in step 420 that the version number associated with the optimistic lock has not been hit. Alternatively, the execution of the atomic transaction initiated in step 410 can be abandoned in response to the determination in step 420 that the version number associated with the optimistic lock has not been hit.

[0104] In some embodiments, the environment variable may also include a tracking identifier associated with performing a settlement once in the current round of task execution, and step 440 may be implemented based on the tracking identifier.

[0105] In some embodiments, step 440 may include step 441: determining whether a trace identifier obtained from execution retry exists in the environment variables associated with the current round of task execution.

[0106] References above Figure 3 The environment variables written via an atomic transaction in step 310 may include a field indicating a tracking identifier. If the tracking identifier indicated in the environment variables written via an atomic transaction matches the tracking identifier indicated in the environment variables for the current round, this indicates that the corresponding state change has been recorded in the environment variables. If the tracking identifier indicated in the environment variables written via an atomic transaction does not match the tracking identifier indicated in the environment variables for the current round, this indicates that the corresponding state change has not yet been recorded in the environment variables.

[0107] In some embodiments, in response to determining that a trace identifier obtained from execution retry exists in an environment variable associated with the current round, step 440 may include step 442: rejecting the write in an atomic transaction.

[0108] If a trace identifier obtained through retry exists in the environment variables associated with the current round, writes to the environment variables can be refused within an atomic transaction because the corresponding state changes have already been recorded in the environment variables. This helps avoid duplicate writes to environment variables.

[0109] In some embodiments, in response to determining that a trace identifier obtained by performing a retry does not exist in the environment variables associated with the current round, step 440 may include step 443: performing a write in an atomic transaction.

[0110] In some embodiments, environment variables may also include variables associated with the execution of the subtask in the current round. Changes in state associated with updates to environment variables can be materialized as an event, and such state changes can be maintained through an event log.

[0111] Figure 5 A fourth process associated with the updating of environment variables in a chat system is illustrated according to some embodiments of the present invention. This fourth process may be associated with tracking changes in state associated with the updating of environment variables via events.

[0112] In some embodiments, the fourth process may include step 510: generating a record of events associated with a state change.

[0113] As an example implementation, event logging can be used to track changes in task execution state, thereby enabling the tracking and recording of environment variable updates. As an example implementation, an event record can be generated each time the task execution state changes (e.g., each time a subtask is executed). The generated event record can include multiple fields indicating the session identifier, round identifier, timestamp, changed content, executor of the corresponding subtask, etc., associated with the task execution state change. The event record can be signed by the executor of the corresponding subtask to prevent tampering and facilitate event record verification.

[0114] In some embodiments, the fourth process may include step 520: writing the event record to the event stream in the event log in an append-only manner.

[0115] Writing event records to the event log in an append-only manner, without allowing modification or deletion of existing event records in the event log, is beneficial for reflecting changes in the task execution status during the entire interaction through the event stream.

[0116] In some embodiments, the fourth process may include step 530: writing variables associated with the execution of the subtask in the current round and the accumulated settlement results from the start of the task to the current round into the event log.

[0117] In addition to recording events in the event log's event stream, variables associated with the execution of subtasks in the current round that triggered the task's execution can also be written to the event log, causing changes in the task's execution state. Furthermore, the accumulated settlement results from the task's start to the current round can also be written to the event log. This allows the event log to more comprehensively reflect the interaction process between subjects, improving the traceability of the interaction process.

[0118] The following describes the execution details of a chat system according to some embodiments of the present invention, in conjunction with IGT. For IGT, the chat system according to some embodiments can use multi-role, multi-process modules in a human-AI hybrid chat room to set up a complete experimental interaction process and environment, thereby extending traditional single-person experiments to human-computer interaction scenarios. By setting two roles (human subject, intelligent agent) and environmental variables, in multiple rounds of structured interaction, the human subject reacts and updates the environmental variables to explore, under human-computer group decision-making, the characteristics of the large language model itself when facing multi-round continuous decision-making, whether the performance of the large language model in executing IGT is superior to human task performance, how to improve task performance, and whether changes in the Iowa deck sequence affect the task performance of the large language model, etc.

[0119] In some embodiments, the state manager can configure and manage environment variables at three levels: experiment level, session level, and round level. A session can correspond to a complete experiment, and a session can include a set of rounds; that is, a round can be a cycle of interaction within a session.

[0120] In some embodiments, environment variables may include one or more of the following: session information, round information, decision results of human users associated with rounds, decision results of agents associated with rounds, settlement results associated with rounds, and settlement results accumulated from the start of the task to the current round.

[0121] In some embodiments, for IGT, environment variables may include session_id, round, bankroll, deck_seed, decks, human_choice, agent_advice{deck, confidence, reason}, outcome{gain, penalty, net}, cum_gain, and trace_id.

[0122] `session_id` is the session identifier, which can be session information in the IGT. `round` is round information, which can be round information in the IGT.

[0123] `bankroll` is the current funds / balance, indicating the available amount accumulated across rounds (e.g., a decimal / int value), and is a task-specific (i.e., IGT-specific) environment variable. `deck_seed` is a fixed random seed used to generate the payout sequences for each deck, ensuring reproducibility (e.g., bytes32 / uint128+ value), and is also a task-specific (i.e., IGT-specific) environment variable. `decks` are the machine parameters / distribution configuration of the deck sets in the experiment (e.g., the win / loss structure of A / B / C / D) (e.g., an array).<deck_cfg> (array structure).

[0124] human_choice is the deck identifier (e.g., an A|B|C|D enum) chosen by the subject in the current round, which can be the decision outcome of a human user associated with the round in the IGT.

[0125] `agent_advice{deck, confidence, reason}` is the suggestion given by the large language model for the current round, which can be the decision result of the agent associated with the round in the IGT. Here, `deck` is the recommended deck, `confidence∈[0,1]` is the confidence of the recommendation, and `reason(struct)` is the brief reason for the recommendation.

[0126] outcome{gain, penalty, net} is the actual settlement result for the current round, which can be the settlement result associated with the round in the IGT. Here, gain is the benefit, penalty is the penalty, and net = gain - penalty(struct) is the net value.

[0127] cum_gain is the cumulative net gain from the start of the experiment to the current round (e.g., a decimal / int value), which can be the cumulative settlement result in the IGT from the start of the task to the current round.

[0128] trace_id is an idempotent and audit final identifier for a settlement / request, used for deduplication and replay location (e.g., UUID / string).

[0129] The environment variables listed above are merely non-limiting examples of environment variables configured for a single round of the IGT. Those skilled in the art can configure more, fewer, and different environment variables according to the requirements of the IGT, and can also configure more, fewer, and different environment variables according to the requirements of other tasks.

[0130] In some embodiments, the state manager configures and manages environment parameters as three independent scopes: experimental, session, and round, allowing reading and writing of the corresponding environment variables only within the corresponding scope.

[0131] In some embodiments, the state manager configures and manages environment variables across three scopes using strongly typed key-value pairs. Experimental, session, and round scopes are used as namespaces, and the data type, value range, and validation rules associated with each key are pre-defined, allowing read and write access to environment variables only within the corresponding scope. Therefore, instead of generating any arbitrary string-to-string dictionary, a key-value store with a schema is produced, where the schema represents the specification of the data structure and constraints. For the three independent scopes of experimental, session, and round, independent keys and lifecycles can be configured for each.

[0132] In some embodiments, for IGT, performing a complete task (experiment) may include the following components.

[0133] Initialization is first performed by the chat system. During initialization, trace_id is generated, deck_seed and read-only configuration are fixed, randomized benefit table is loaded, and anonymized subject metadata is recorded.

[0134] Next, the chat system executes each round. The following section will further describe the operational process in each round in conjunction with the workflow.

[0135] Next, after reaching the preset number of rounds, the chat system will perform the cleanup. During the cleanup process, CSV / JSON / Parquet and reproducible experimental packages (seed + version hash + audit trail) can be exported, and questionnaires and subjective evaluations can be merged.

[0136] During IGT execution, safeguards can be implemented by the chat system to ensure security and reliability. For example, the chat system can perform sandboxing and rate limiting, injection protection, data anonymization, and access auditing. The chat system can also perform automatic rollback on failures and idempotent retries across nodes. Furthermore, the chat system can support Webhook / queue push and pre-registration scheme verification.

[0137] The following describes the execution process and details of using a workflow to execute each round of the IGT.

[0138] As an example, DifyWorkflow can be used, which can be implemented by calling an external workflow service through DifyWorkflowFacade.

[0139] In some embodiments, a workflow may be associated with a state machine of the current round. Since the state machine associated with a task's round is configurable depending on the specific task and round, a workflow associated with the current round can be implemented based on a state machine configured according to the current round.

[0140] In some embodiments, a workflow may include an orchestrator and multiple execution tools. The orchestrator can orchestrate the execution of subtasks in the current round by each execution tool according to a predetermined orchestration flow, thereby implementing a state machine associated with the current round. The following will combine... Figure 6 Describe the orchestration flow associated with the rounds of IGT execution, and combine Figure 7 Describe the specific workflow.

[0141] In some embodiments, the workflow for implementing IGT rounds may include StateReader, Advisor, Critic, Payoff, StateWriter, and Orchestrator. The Orchestrator may be an orchestrator, while the others may be execution tools.

[0142] StateReader can be used to process incoming environment variables to facilitate the execution of the current round.

[0143] Advisor is a decision-making tool in the IGT that performs decisions in the current round. Advisor can be used to read environment variables (e.g., round, gains from the previous round, historical decision information, etc.), assemble the read information into a context, call the corresponding large language model API to make decisions based on this context, output code that the chat system can recognize after the decision, and iteratively update the environment variables in the dialogue.

[0144] In some embodiments, the Advisor can access Retrieval Augmented Generation (RAG) to obtain experimental rules, ethics, prompts, etc. from relevant sources to generate corresponding prompts, which are then provided to the large language model to be invoked for decision-making.

[0145] In some embodiments, the Advisor can be trained with few samples. As an example, when the Advisor generates prompts, a template can be constructed as follows: [System: Role / Prohibited Items / JSON Schema] + [Context: Session Snapshot (Read-only): bankroll, round, feedback from the previous round…] + [Examples: K example pairs (state → advice JSON)] + [User: “Based on the above, give advice for this round”].

[0146] By employing few-shot training, the output of the large language model being used can be made more stable. For example, it can enable the large language model to generate structured fields more reliably (e.g., {deck, confidence∈[0,1], reason≤N}), thereby reducing the error rate in formatting. As an example, the number of samples in few-shot training can be less than 10, less than 9, less than 8, less than 7, less than 6, less than 5, less than 4, less than 3, less than 2, or it can be 1.

[0147] Few-shot training can improve strategy alignment in large language models during decision-making. By incorporating styles such as "risk aversion / exploration-exploitation balance / ethical constraints" into examples, deviations and illusions in the decision-making process of large language models can be reduced. Few-shot training also enables contextual generalization. For example, "similar situation examples" can prompt large language models to make consistent decisions even under atypical rounds / abnormal feedback. Furthermore, few-shot training can enhance the controllability and auditability of task execution. For instance, the provided examples can be white-box, versionable, and A / B tested, making variations in output more interpretable.

[0148] In some embodiments, the Advisor can force the large language model to produce JSON Schema output. JSON Schema can be used to define JSON data structures and constraints. For example, it can define field names, types, required fields, value ranges, enumerations, formats (e.g., UUID / URI), nested objects, etc., so that the output of the large language model can be automatically validated by the program.

[0149] As an example, for the current turn in the IGT, the Advisor can request the output generated by the large language model as follows:

[0150] - Top floor:

[0151] -- task (such as "advisor" / "settlement"), trace_id(uuid), round_idx(int);

[0152] - Recommendation stage:

[0153] -- agent_advice: { deck: enum[A,B,C,D], confidence: number[0,1],reason: string<=512};

[0154] - Selection / Settlement:

[0155] -- human_choice: enum[A,B,C,D];

[0156] -- outcome: { gain:int, penalty:int, net:int};

[0157] -- updates: { bankroll:number>=0, cum_gain:number};

[0158] - Control signals:

[0159] -- needs_clarification(bool), error_code(enum), policy_tag(enum).

[0160] By forcing large language models to generate JSON Schema output, machine-based validation of the output becomes possible. For example, middleware can use the Schema to validate the output of the large language model; if the format is incorrect, it can be rolled back and retried, thus avoiding dirty writes. Forcing large language models to generate JSON Schema output also decouples orchestration. For example, the Orchestrator can route the output of the large language model to the appropriate execution tools (e.g., write status, settlement, logs, etc.) based on Schema fields. Forcing large language models to generate JSON Schema output also enables security and constraints. For example, enumerations / ranges can be used to restrict unauthorized values ​​(e.g., only A~D, confidence∈[0,1] are allowed). Forcing large language models to generate JSON Schema output also promotes the observability and versioning of task execution. For example, the Schema can be set with a version number ($id / version), facilitating A / B testing and audit reproduction.

[0161] In some embodiments, the Advisor can be trained using zero-shot training. Compared to few-shot training, zero-shot training saves more tokens and is easier to transfer, but it is not as good as few-shot training in few-shot scenarios, boundary states, and style consistency.

[0162] In some embodiments, the Advisor can switch between few-shot training and zero-shot training when performing tasks. As an example, the Advisor can use few-shot training when performing complex tasks. For example, it can use the top 3 to 5 samples, combined with a strict schema; while switching to zero-shot training during low-load or exploratory phases.

[0163] Some implementations utilize Advisors to guide the invoked large language model with prompts and output requirements, enabling the large language model to perform interpretable reasoning, adapt to different contexts, and have its reasoning process and results auditable and reproducible. This allows for a more "human-like" adversary in task execution. Compared to simple scripts or chatbots, the key is not just conversational skills, but the ability to generate structured strategy outputs, possess controlled memory and tool usage capabilities, thereby enabling collaboration / competition with human users while maintaining experimental rigor.

[0164] In some embodiments, the Advisor may grant the invoked large language model permission to read environment variables. This allows the large language model to obtain the user's decisions in the current round and the settlement results associated with the current or previous round, thereby enabling the large language model to better execute its reasoning decisions within the context of the current round and enhancing its cooperation or adversarial interactions with human users.

[0165] Critic can perform validation on the output of large language models, such as consistency checks, privilege escalation checks, or privacy checks, or one or more of these. Only the results of the validations performed by Critic are written to update environment variables.

[0166] Payoff can be designed according to experimental rules to calculate payoff. As an example, for IGT, Payoff can use a deterministic pseudorandom number generator (PRNG) (seed=deck_seed∥round) to generate IGT payoff.

[0167] StateWriter can be used to write to and update environment variables.

[0168] In some embodiments, StateWriter can write environment variables associated with the current round through atomic transactions. An atomic transaction is an indivisible transaction in computer execution that is either executed completely or not at all.

[0169] In some embodiments, for low-concurrency execution, StateWriter may employ session-level serialization (e.g., execution tool / single-thread / queue). For example, an execution tool may be bound to each session_id, and all writes may be processed sequentially (single-thread or the same partition queue).

[0170] In some embodiments, for executions with high concurrency and high reliability requirements, StateWriter can combine atomic transactions and optimistic locking. StateWriter can initiate atomic transactions. StateWriter can perform checks based on the version number associated with the optimistic lock (e.g., WHERE version=v). If the check results in a hit, the write operation is completed in one go, and the version number is updated (e.g., the version is incremented). If the check results in a miss, a rollback and retry / abandonment can be performed.

[0171] In some embodiments, the workflow can be coordinated (e.g., by an Orchestrator) to complete all thinking (decision-making) and calculations outside of the write transaction as much as possible, thereby ensuring the consistency of environment variables and minimizing the time spent holding locks, thus promoting the efficiency of task execution.

[0172] In some embodiments, the StateWriter can update the event sourcing log in an append-only manner. Changes in state associated with updates to environment variables can be maintained through the event log.

[0173] As an example, for each state change, the StateWriter can generate an event record (e.g., containing event type, session ID, round_idx, change / increment, old version, new version, timestamp, executor, trace_id). The StateWriter can only append this event record to the event stream in the event log; it is not allowed to update or delete existing event records. The StateWriter can write the event record and the associated aggregate state in the current round (e.g., roundroll, cum_gain, etc.) within the same atomic transaction. As an example, the aggregate state can be a variable associated with the execution of a subtask in the current round. The StateWriter can write the event record first, then write the aggregate state. If either write fails, the entire process is rolled back.

[0174] In some embodiments, each entry in the event log may have a signature / hash chain (prev_hash → curr_hash) to ensure immutability and verifiability.

[0175] In some embodiments, snapshots of the event log may be generated periodically. In some embodiments, snapshots of the event log can be used to quickly perform rollback and recovery when a subtask fails. In some embodiments, snapshots of the event log can be used to replay subsequent events from the snapshot when reproduction is required, thereby reconstructing the state at any point in time.

[0176] In some embodiments, deduplication can be performed using the trace_id when handling idempotency / retry. For example, if an event with the same trace_id already exists, writing again is rejected.

[0177] In some embodiments, the event log is read-only and is used solely for auditing and analysis. The statistics backend can perform asynchronous calculations and reporting by subscribing to event streams.

[0178] In some embodiments, the Orchestrator can be configured to orchestrate execution tools with minimal privileges, thereby achieving a predetermined orchestration process. The following will combine... Figure 6 Further details on how the orchestration execution tools implement the orchestration process.

[0179] As an example, orchestration with least privileges in terms of read operations can be reflected in the fact that the Orchestrator is only allowed to read snapshots (e.g., round_idx, bankroll, summaries of the previous round, etc.). In contrast, the Orchestrator is not allowed to read PIIs and cannot read / modify experimental read-only items (e.g., deck_seed, config_hash).

[0180] As an example, orchestration with least privileges in scheduling operations can be manifested in the Orchestrator only being allowed to call whitelisted tools within the execution tools. For example, whitelisted tools might include StateReader, Payoff, StateWriter, and fixed entry points for Advisor and Critic. However, the Orchestrator is not allowed to directly call large language models.

[0181] As an example, orchestration with least privileges can be manifested in scheduling operations by allowing the Orchestrator to only update the event log in an append-only manner. In some embodiments, the Orchestrator is only allowed to update a limited set of keys (outcome, bankroll, cum_gain, round_idx, agent_advice) and is subject to schema and version validation constraints.

[0182] As an example, orchestration with least privileges can be manifested in terms of control operations by allowing the Orchestrator to only evaluate the termination conditions of a task and signal the termination of the task in response to its termination. The Orchestrator is not allowed to modify rules or parameters.

[0183] As an example, permissions that the Orchestrator should not hold beyond the minimum permissions may include experimental-level administrative permissions: creating / closing experiments, modifying n_rounds, payoff_model, and deck_seed.

[0184] Other permissions may include data maintenance permissions: export / delete raw data, access the full event stream, and replay sessions. Other permissions may include policy management permissions: change Advisor hints / sample libraries, and adjust RAG indexes. Other permissions may include security compliance permissions: view / decrypt anonymized fields, and access PII. Other permissions may include system maintenance permissions: change schemas / migration scripts, and modify audit and rate limits.

[0185] It is important to note that the Orchestrator and various execution tools (StateReader, Advisor, Critic, Payoff, StateWriter, etc.) in the workflow described above in conjunction with IGT are abstractions and summaries specific to IGT tasks. Those skilled in the art can implement the described items based on their execution processes and functional descriptions, using basic execution tools from existing workflows (e.g., the Dify workflow). Furthermore, those skilled in the art can abstract basic workflows based on the requirements and characteristics of other types of tasks and implement them using basic execution tools from existing workflows.

[0186] Figure 6 The diagram illustrates an orchestration flow for one round of an IGT (Integrated Game Threat) implemented via a workflow, according to some embodiments of the present invention. As an example, Figure 6 The orchestration process shown can be associated with one round of executing the IGT as described above.

[0187] In some embodiments, the orchestration process may include consultation 610, decision 620, settlement 630, and termination 640. The orchestration process may be associated with an IGT task to be performed. For example, each stage of the orchestration process may be set based on the requirements of the IGT task. Those skilled in the art will understand that orchestration processes with more stages, fewer stages, and different stages can be set based on the IGT task. Orchestration processes with more stages, fewer stages, and different stages can also be set based on the requirements of different types of tasks. Those skilled in the art can also implement a state machine based on the established orchestration process, thereby implementing the orchestration process or state machine using a workflow.

[0188] Figure 6The document also illustrates the relationships between the various stages of the orchestration process and the components of the workflow (e.g., how each stage is implemented by the workflow orchestrator or other execution tools). As an example, for the execution of a round in the IGT, the implementation details of each stage of the orchestration process are described based on the orchestrator and related execution tools described above.

[0189] The purpose of Consultation 610 is to obtain advice. Consultation 610 can be performed using StateReader 651, Advisor 652, Critic 653, and StateWriter 654. StateReader 651 reads environment variables. Advisor 652 generates a context based on environment variables and provides the context to the large language model to be invoked, causing the large language model to generate output containing the suggested agent_advice. Critic 653 performs consistency / exception checks on the output of the large language model. If the checks pass, StateWriter 654 writes the agent_advice to environment variables.

[0190] The purpose of Decision 620 is to enable human-machine decision-making. When a human user is in control, Orchestrator 655 performs validations to check if the session status is unsettled, rounds are consistent, and time windows are valid. In this stage, Orchestrator 655 only performs validity checks and sequence control.

[0191] The purpose of settlement 630 is to calculate and post transactions. Settlement 630 can be performed using Payoff 656, Orchestrator 655, and StateWriter 654. Payoff 656 generates deterministic results. Orchestrator 655 performs a packaged transaction commit. StateWriter 654 writes outcome, bankroll, cum_gain, and round_idx++ to environment variables.

[0192] The purpose of Termination 640 is to close and archive the round. Termination 640 can be performed using Orchestrator 655 and StateWriter 654. Orchestrator 655 performs termination condition checks and issues a task termination signal when the termination condition is met. In response to the task termination signal, StateWriter 654 writes a termination flag and an end event.

[0193] Figure 7 An experimental design for performing a task in one round is illustrated according to some embodiments of the present invention. As an example, Figure 7The experimental design shown can be associated with one round of performing the IGT as described above.

[0194] This experimental design may include five elements: role allocation, experimental intervention, workflow, basic operators, and data collection. Each element is distinguished by the different symbols shown. The process by which these elements are formed constitutes one round of the process for performing the IGT. The subject indicated by the arrows between the elements—"user" or "collaborator"—represents the action of the latter element (i.e., the element pointed to by the arrow) on that subject.

[0195] The role configuration may include a first role configuration 711 and a second role configuration 712. The first role configuration 711 is used to configure the user (subject) for the current round of the IGT task. The second role configuration 712 is used to configure the collaborator (model robot) for the current round of the IGT task. Figure 8 The first interface 810 associated with the first role configuration 711 and the second role configuration 712 is shown.

[0196] The primary function of experimental interventions is to additionally display multimedia elements (e.g., text, audio, video, etc.) during experimental rounds to alter the psychological state of human users (subjects) or as reminders within the experimental process. Experimental interventions may include a first experimental intervention 721 and a second experimental intervention 722. The first experimental intervention 721 may indicate "Round Start". The second experimental intervention 722 may indicate "Wait 1 between rounds". As an example, the second experimental intervention 722 may be a combination of the above... Figure 1 The described intervention component 150 provides a specific example of how to perform an intervention, or it can be a combination of the above. Figure 2 A specific example of the first process described.

[0197] The main purpose of workflow is to follow a predetermined orchestration process (e.g., as described above). Figure 6 The described orchestration process uses an orchestrator or various execution tools to execute the current round of the task. The workflow may include a first workflow 731, a second workflow 732, a third workflow 733, and a fourth workflow 734.

[0198] The first workflow 731 can instruct "text_1 rewrite (role) (role)", which instructs the rewriting of the role's environment variables text_seq and result. The second workflow 732 can execute "IGT-llm first decision (role)", which instructs the execution of the collaborator's first decision. The third workflow 733 can instruct "text_1 rewrite (global) (global)", which instructs the rewriting of the global environment variables text_seq and result. The fourth workflow 734 can instruct "profit calculation (historical + user decision) (global)", which instructs the execution of profit calculation.

[0199] The basic operators include elements for presentation to human users and "wait" instructions. The basic operators may include a first basic operator 741, a second basic operator 742, a third basic operator 743, a fourth basic operator 744, a fifth basic operator 745, a sixth basic operator 746, a seventh basic operator 747, an eighth basic operator 748, and a ninth basic operator 749.

[0200] The first basic operator 741 can indicate "display (text_content)". The second basic operator 742 can indicate "option (4)". The following will combine... Figure 12 A sixth interface associated with the first basic operator 741 and the second basic operator 742 is shown and described.

[0201] The third basic operator 743 can indicate "wait", which corresponds to prompting the human user to wait on the interface.

[0202] The fourth basic operator 744 indicates "display (llm_choice)". The fifth basic operator 745 indicates "display (user_choice)". The sixth basic operator 746 indicates "display (text_content)". The seventh basic operator 747 indicates "option (4)". The following will combine... Figure 13 The seventh interface associated with the fourth basic operator 744, the fifth basic operator 745, the sixth basic operator 746, and the seventh basic operator 747 is shown and described.

[0203] The eighth fundamental operator 748 indicates "display (user_choice_final)". The ninth fundamental operator 749 indicates "display (result)". The following will combine... Figure 14 The eighth interface associated with the eighth fundamental operator 748 and the ninth fundamental operator 749 is shown and described.

[0204] Data collection 750 can indicate "Feedback for this round", which indicates the feedback of the results of the current round's execution.

[0205] Figure 8 A first interface 810 associated with role configuration and a second interface 850 associated with environment variable configuration are shown according to some embodiments of the present invention.

[0206] The first interface 810 displays the configurations for "User" and "Smart Assistant". These can be configured separately with... Figure 7 The first role configuration 711 and the second role configuration 712 are associated.

[0207] The second interface 850 shows the interface for configuring environment variables.

[0208] Figure 9 A third interface associated with human users making decisions is shown according to some embodiments of the present invention.

[0209] The left side of the third interface displays the "game introduction" for the current round associated with IGT. Point 4 indicates that the "user" and "cooperator" need to make independent decisions first. Point 6 indicates that after both parties have made independent decisions, the "user" must make a second decision based on the decisions made by themselves and the "cooperator" as the final decision for this round.

[0210] The right side of the third interface displays the current environment variables. The environment variables include the current round (round 2), the prompt status (both parties have completed their selections, and the "user" needs to click the button below the middle dialog box again to make a second selection as the final selection for this round), and the gains for this round.

[0211] The third interface displays a dialog box between the "User" and the "Collaborator" in the middle, showing the results of the first selection by the "User" and the "Collaborator" in the current round. Below, four options, "Company A", "Company B", "Company C" and "Company D", are displayed for the "User" to make a second selection.

[0212] Figure 10 A fourth interface is shown, including environmental variables in a round, according to some embodiments of the present invention.

[0213] The fourth interface displays the current round (round 1), status prompts, and the rewards for this round on the right side.

[0214] Figure 11 A fifth interface is shown, including environmental variables in another round, according to some embodiments of the present invention.

[0215] The fifth interface displays the current round (round 2), status indicator, and rewards for this round on the right. Compared to... Figure 10 On the fourth screen, the turn information in the environment variables has changed.

[0216] Figure 12 A sixth interface associated with the execution of the basic operators is shown according to some embodiments of the present invention.

[0217] The content displayed in the first box on the right ("Current round: 1. You and your partners will make decisions in tandem. Please select the companies to invest in this round") can be combined with the above text. Figure 7 The execution of the first basic operator 741 described is related. The content displayed in the lower middle section ("Company A", "Company B", "Company C", "Company D") can be combined with the above text. Figure 7 The execution of the second basic operator 742 described is associated with this.

[0218] Figure 13 A seventh interface associated with the execution of the basic operators is shown according to some embodiments of the present invention.

[0219] The content displayed on the left side of the middle dialog box ("Partner Company A") can be combined with the above text. Figure 7 The execution of the fourth fundamental operator 744 is described in relation to this. The content displayed on the left side of the middle dialog box (“User Company A”) can be combined with the above. Figure 7 The execution of the fifth basic operator 745 is described in relation to this. The content displayed in the second box on the right (“Round Status - Hints…”) can be combined with the above text. Figure 7 The execution of the sixth fundamental operator 746 is described in relation to this. The content displayed in the lower middle section (“Company A”, “Company B”, “Company C”, “Company D”) can be combined with the above text. Figure 7 The execution of the seventh basic operator 747 described is associated with this.

[0220] Figure 14 An eighth interface associated with the execution of basic operators is shown according to some embodiments of the present invention.

[0221] The content displayed in the lower right corner of the middle dialog box (“User Company A”) can be combined with the above text. Figure 7 The execution of the eighth basic operator 748 is described in relation to this. The content displayed in the third box on the right ("This round's profit...") can be combined with the above text. Figure 7 The execution of the ninth fundamental operator 749 described is associated with this.

[0222] For tasks involving multiple rounds, existing typical Discord bots lack standardized logic and state machine / process orchestration (e.g., the orchestration process for rounds of IGT execution according to some embodiments: consultation → decision → settlement → termination). Typical Discord bots exhibit weak and unreproducible states, rely on ad-hoc contexts, lack strongly typed key-value deterministic public-resolved generation (PRNG), and are difficult to replay. The output format of typical Discord bots is unstable; their output is in natural language, and the output results cannot be machine-determined or directly executed. Typical Discord bots exhibit unauthorized access or deviations during execution, cannot minimize permissions, and are prone to mixing "rules / configurations" into prompts, thus allowing model tampering. Intervention in typical Discord bots is uncontrollable; it is difficult to adjust prompts and difficulty in real-time and quantitatively based on global variables, and audit trails are lacking.

[0223] Some embodiments of the present invention improve upon at least one of the above aspects.

[0224] Some implementations employ strongly typed states and auditing to achieve strong state and reproducibility of agent task execution. A three-scope strongly typed key-value pair (KV) is used at the experimental, session, and round levels, with environment variables such as bankroll, deck_seed, agent_advice, and outcome fixed. Deterministic payoffs are used to generate costs or penalties, supporting reproducibility and blind auditing. An event sourcing mechanism based on append-only and snapshot-based methods ensures that the execution process is replayable and comparable.

[0225] Some implementations employ process orchestration and least privilege to ensure that agents have standardized logic when performing tasks and to avoid privilege escalation and drift. For example, the Orchestrator orchestrates StateReader→Advisor→Critic→Payoff→StateWriter by state machine, and the Orchestrator only performs the orchestration with least privilege.

[0226] Some implementations employ executable / verifiable outputs, making the results of large language models machine-determined or executable. For example, Advisor can use strongly constrained JSON Schema outputs (e.g., {deck, confidence, reason}). Critic, for instance, performs automatic checks on structure, privilege escalation, and ethics, retrying or downgrading for non-compliance.

[0227] Some implementations employ human-like strategies and adaptations. For example, the retrieval method uses few-shot training and retrieval enhancement generation to obtain "similar situation examples" from an example / rule base, thereby aligning with human strategic styles (exploitation-exploitation, risk preference, etc.). Another example is intervention driven by global variables, using global keys such as `intervention_level`, `nudging_polilcy`, and `history_summaries` to dynamically adjust the intensity / phrase / displayed information at the round-level, achieving real-time, quantitative "cue intervention".

[0228] Some implementations provide security and experimental controls. For example, an audit time (e.g., including trace_id, new / old version, latency) is generated for each action of the agent. For example, unbalanced / hierarchical randomization (controlled randomization of card positions / colors / orders) is employed. For example, rate limiting and cue injection protection are used to ensure consistent subject conditions.

[0229] In summary, compared with existing chatbots, such as the typical Discord bot, some implementations have achieved standardized processes, structured output, reproducibility, and dynamic intervention, overcoming the core obstacles of general chatbots such as "unreproducibility, uncontrollability, and unverifiability".

[0230] Although some embodiments of the invention have been described primarily in conjunction with IGT, those skilled in the art will understand that chat systems according to some embodiments can be equally applied to other social experiments (e.g., Heinz moral dilemma experiments) or other types of tasks (e.g., business scenario tasks, etc.).

[0231] As an example, the Heinz moral dilemma experiment can be extended to specific scenarios through a multi-agent chatroom module, allowing agents based on large language models to interact with human participants. A simulated trial scenario is introduced, referencing Anglo-American legal procedures, where participants take on roles such as judge, juror, and witness, representing different ethical stances in the chatroom trial process. They debate with the agents and complete a series of tasks, ultimately deciding on Heinz's guilt or innocence. This function provides an important avenue for analyzing the dynamics of moral reasoning. By recording detailed logs of agent interactions, a persistent bias towards fairness can be discovered in the agents' decisions, contrasting with the diverse responses exhibited by human participants.

[0232] As an example, for market research in business scenarios, a multi-agent system is designed, consisting of static data retrieval, dynamic autonomous evolutionary discussion, and expert knowledge injection, for market research and business report generation. It aims to assist human business decision-making, providing comprehensive reference and prediction, and saving the cost of large-scale research. Specifically, users can input the market research task topic through a set of environmental variables. In designated rounds, Participant 1 (human participant) assumes the expert role to perform the sub-task "providing inspiration"; Participant 2 (Planner) assumes the task planning role to perform the sub-task "reporting the overall plan"; Participant 3 (Retriver) assumes the information retrieval role to perform the sub-tasks "web search," "database retrieval," and "document retrieval"; Participant 4 (Actor) assumes the dynamic discussion role to perform the sub-tasks "simulating social effects" and "discussing consensus"; Participant 5 (Generator) assumes the information aggregation role to perform the sub-tasks "summarizing and generating," "data visualization," and "memory retrieval"; and Participant 6 (Reflector) assumes the reflection role to perform the sub-tasks "optimizing workflow," "updating tasks," and "optimizing generated content."

[0233] Embodiments of the present invention have been described with reference to the accompanying drawings. These embodiments are illustrative and not restrictive.

Claims

1. A chat system for performing tasks comprising multiple rounds, each round comprising chat between multiple subjects, each subject being pre-assigned a role in each round, the subjects including human users or intelligent agents, the task comprising multiple subtasks, each subtask being pre-configured with a unique identifier for a preceding task to be completed before that subtask, wherein, The prerequisite task is a subtask among the plurality of subtasks, characterized in that the chat system includes: A state manager is used to configure environment variables associated with the task in a structured manner. These environment variables include: a first decision result of the human user associated with a round, a second decision result of the agent associated with a round, a settlement result associated with a round, and a cumulative settlement result from the start of the task to the current round; and Computing resources; The workflow, implemented as a state machine associated with the current round, invokes the computing resources to: Read the environment variables associated with the previous round; The environment variables of the previous round are rewritten based on the role assigned to the subject in the current round. The decision for the current round is executed based on the rewritten environment variables, wherein the result of the decision for the current round is determined based on the first decision result and the second decision result of the current round; The current round is settled based on the result of the decision made in the current round; The environment variables associated with the current round are updated based on the settlement results associated with the current round, wherein the settlement results associated with the current round and the accumulated settlement results from the start of the task to the current round are updated among the environment variables associated with the current round; and A basic operator invokes the computing resources to provide a graphical user interface to the human user in the current round, wherein the graphical user interface is used to enable the human user to interact with the agent, enable the human user to input the first decision result, and present feedback to the human user on the first decision result; An intervention component, which invokes the computing resources, to: Detect the unique identifier of the preceding task associated with the subtask to be executed; In response to the detection result indicating that the preceding task has not been completed, a lock record is added to prevent the human user or the intelligent agent from executing the subtask.

2. The chat system as described in claim 1, characterized in that, The state manager is used to configure each item of the environment variable via key-value pairs, wherein the data type, value range, and validation rules of the value associated with the key are predetermined.

3. The chat system as described in claim 2, characterized in that, The tasks are associated with experiments, sessions are associated with complete experiments, and multiple rounds are associated with a single session. The environment variables include experimental-level environment variables, session-level environment variables, and round-level environment variables, and The state manager is used to configure independent keys and lifecycles for the experimental-level environment variables, the session-level environment variables, and the round-level environment variables.

4. The chat system as described in claim 1, characterized in that, The workflow invokes the computing resources to: Write the environment variables associated with the current round through atomic transactions.

5. The chat system as described in claim 4, characterized in that, The workflow invokes the computing resources to: Initiate the atomic transaction; Perform checks based on the version number associated with the optimistic lock; In response to a hit result from the check, the atomic transaction is completed, and the version value associated with the optimistic lock is updated; If the result of the check indicates a failure, a retry is performed.

6. The chat system as described in claim 5, characterized in that, The environment variables also include a tracking identifier associated with performing a settlement. The workflow invokes the computing resources to: Determine whether a trace identifier obtained from a retry exists in the environment variables associated with the current round; as well as In response to the determination that a tracer identifier obtained from execution retry exists in the environment variables associated with the current round, writes are refused to be performed in the atomic transaction.

7. The chat system as described in claim 5, characterized in that, The environment variables also include variables associated with the execution of the subtask in the current round; Changes in state associated with updates to the aforementioned environment variables are maintained via an event log. The workflow invokes the computing resources to: Generate records of events associated with state changes; The event is written to the event stream in the event log in an append-only manner; as well as The variables associated with the execution of the subtask in the current round and the accumulated settlement results from the start of the task to the current round are written to the event log.

8. The chat system as described in claim 1, characterized in that, The workflow invokes the computing resources to: Periodically generate snapshots of the event logs associated with the updates to the environment variables.

9. The chat system as described in claim 8, characterized in that, The workflow includes an orchestrator and multiple execution tools, the orchestrator invoking one or more of the multiple execution tools according to the state machine to execute subtasks in the current round.

10. The chat system as described in claim 9, characterized in that, The orchestrator is configured to be at least one of the following: Only the snapshot is allowed to be read in terms of read operations; In terms of scheduling operations, only whitelisted tools among the plurality of execution tools are allowed to be called, and the whitelisted tools exclude the large language model called by the agent; Write operations are only permitted to update the event log in an append-only manner. In terms of control operations, only the termination conditions of the task are allowed to be evaluated, and a signal to terminate the task is issued in response to the termination of the task.

11. The chat system as described in claim 9, characterized in that, The plurality of execution tools include a decision tool that invokes a large language model to perform decisions based on the role assigned to the agent.

12. The chat system as described in claim 11, characterized in that, The decision-making tool is configured to: Based on the role assigned to the agent, the large language model to be invoked is trained using structured prompts with few samples. as well as The trained large language model is invoked to make decisions based on the roles assigned to the agent.

13. The chat system as described in claim 11, characterized in that, The decision-making tool is configured to: Instructs the invoked large language model to generate output in accordance with the specifications of JSON data structure and constraints.

14. The chat system as described in claim 11, characterized in that, The decision-making tool is configured to: Grant the large language model to be invoked permission to read the environment variables.

15. The chat system as described in claim 8, characterized in that, Also includes: An audit component, which invokes the computing resources, to: Analyze a snapshot of the event log; as well as Reports are generated based on the results of the analysis.

16. The chat system according to any one of claims 1-15, characterized in that, The workflow includes the Dify workflow, and / or The tasks include social experiments and business scenario tasks.

Images