Data processing method and device

Abstract

The embodiment of the invention provides a data processing method and device. The method comprises the steps that a target event is converted into an initial event intermediate representation of a preset event structure; determining an event processing pipeline according to the task type corresponding to the target event; performing transformation processing on the initial event intermediate representation according to a plurality of transformation processing stages to generate candidate event intermediate representations; determining a target model according to the candidate event intermediate representation, and determining a rendering processing stage according to the candidate event intermediate representation and model configuration of the target model; and performing rendering processing on the candidate event intermediate representation according to the rendering processing stage, and generating a target event intermediate representation matched with the target model input format. Through the layered, configurable and dynamically adaptive context construction method, the problem of low context generation quality caused by model capability difference, long-range dependency loss, tool calling complexity and insufficient control constraint is solved, and the adaptability, reliability and execution efficiency of a complex agent system are improved.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of intelligent agent technology, and in particular to a data processing method and apparatus. Background Technology

[0002] Most current intelligent agent systems based on large language models generally treat the construction of model input context as a simple concatenation and truncation of string fragments. Faced with the demands of diverse model capabilities, long-term task dependencies, complex tool calls, and security rule constraints, while the system level may provide dialogue history storage, tool encapsulation, and some prompt word templates, it lacks abstraction and modeling of the context construction process itself, making it difficult to generate an accurate, efficient, and reliable context. This leads to technical problems such as model comprehension bias, tool call errors, loss of key information, and uncontrollable behavior, severely restricting the performance and reliability of complex intelligent agent systems. Summary of the Invention

[0003] In view of the above, the embodiments of this specification provide a data processing method. One or more embodiments of this specification also relate to a data processing apparatus, a computing device, a computer-readable storage medium, and a computer program product, in order to solve the technical defects existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a data processing method is provided, comprising: Convert the target event into an initial intermediate event representation with a preset event structure; Based on the task type corresponding to the target event, an event processing pipeline is determined, wherein the event processing pipeline includes multiple transformation processing stages connected in sequence; The initial intermediate representation of the event is transformed according to the multiple transformation processing stages to generate candidate intermediate representations of the event. The target model is determined based on the intermediate representation of the candidate events, and the rendering process stage is determined based on the intermediate representation of the candidate events and the model configuration of the target model. The intermediate representations of the candidate events are rendered according to the rendering process stage to generate the intermediate representation of the target event, wherein the intermediate representation of the target event matches the input format of the target model.

[0005] According to a second aspect of the embodiments of this specification, a data processing apparatus is provided, comprising: The event conversion module is configured to convert a target event into an initial intermediate event representation with a preset event structure; The pipeline determination module is configured to determine an event processing pipeline based on the task type corresponding to the target event, wherein the event processing pipeline includes multiple transformation processing stages connected in sequence. The transformation processing module is configured to transform the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations. The rendering module is configured to determine the target model based on the intermediate representation of the candidate events, and to determine the rendering processing stage based on the intermediate representation of the candidate events and the model configuration of the target model. The context generation module is configured to perform rendering processing on the intermediate representation of the candidate event according to the rendering processing stage to generate the intermediate representation of the target event, wherein the intermediate representation of the target event matches the input format of the target model.

[0006] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which implement the steps of the above data processing method when executed by the processor.

[0007] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the data processing method described above.

[0008] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described data processing method.

[0009] This specification implements a data processing method in one embodiment. First, the original target event is converted into a standardized initial event intermediate representation. Based on the task type, an event processing pipeline containing multiple configurable processing stages is determined. The initial event intermediate representation is then transformed and enhanced step by step to generate candidate event intermediate representations. Second, based on the candidate event intermediate representation and the model configuration of the target model, the corresponding rendering processing stages are dynamically decided and executed, ultimately generating a context representation that accurately matches the input format of the target model. This hierarchical, configurable, and dynamically adaptable context construction method effectively solves the problem of low-quality context generation caused by differences in model capabilities, loss of long-range dependencies, complex tool calls, and insufficient control constraints, significantly improving the adaptability, reliability, and execution efficiency of complex intelligent agent systems. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a data processing method provided in one embodiment of this specification; Figure 2 This is a schematic diagram of the generation process of the intermediate representation of the initial event in a data processing method provided in one embodiment of this specification; Figure 3 This is a schematic diagram of the generation process of intermediate representations of candidate events in a data processing method provided in one embodiment of this specification; Figure 4 This is a flowchart illustrating the generation of an intermediate representation of a target event in a data processing method provided in one embodiment of this specification. Figure 5 This is a flowchart illustrating the rendering process of an intermediate representation of a candidate event in a data processing method provided in one embodiment of this specification. Figure 6 This is a flowchart illustrating the processing of tool call commands in a data processing method provided in one embodiment of this specification; Figure 7 This is a schematic diagram of the retry strategy of the state machine in a data processing method provided in one embodiment of this specification; Figure 8 This is a flowchart illustrating the generation of intermediate representations by a tool in a data processing method provided in one embodiment of this specification. Figure 9 This is a schematic diagram of the structure of a data processing apparatus provided in one embodiment of this specification; Figure 10 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0011] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0012] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0013] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0014] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0015] In one or more embodiments of this specification, a large model refers to a deep learning model with a large number of model parameters, typically containing hundreds of millions, tens of billions, hundreds of billions, trillions, or even tens of trillions of model parameters. A large model can also be called a foundation model. It is pre-trained using large-scale unlabeled corpora to produce a pre-trained model with hundreds of millions of parameters. Such models can adapt to a wide range of downstream tasks and have good generalization ability. Examples include Large Language Models (LLMs) and multi-modal pre-training models.

[0016] In practical applications, large models only require a small number of samples to fine-tune the pre-trained model before they can be applied to different tasks. Large models can be widely used in fields such as Natural Language Processing (NLP) and Computer Vision. Specifically, they can be applied to computer vision tasks such as Visual Question Answering (VQA), Image Captioning (IC), and Image Generation, as well as natural language processing tasks such as text-based sentiment classification, text summarization, and machine translation. The main application scenarios of large models include digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0017] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0018] IR: Intermediate Representation.

[0019] ContextIR: Context Intermediate Representation.

[0020] JIT: Just-In-Time.

[0021] LLM: Large Language Model.

[0022] LangChain is an open-source framework for building applications based on Large Language Models (LLM). It provides modular components (such as prompt templates, memories, tool calls, etc.) to help developers orchestrate complex workflows more efficiently.

[0023] PromptTemplate: A class in LangChain used to create and manage string-based prompt templates. It allows you to populate the template with variables (such as user input and contextual information) to generate the final prompt text sent to the language model.

[0024] ChatPromptTemplate: A template class in LangChain used to build multi-turn conversational prompts. It organizes prompt content in the form of a "message list" (such as system messages, user messages, assistant messages), and each message can contain variable placeholders. It is suitable for models that support conversational formats (such as the ChatGPT series).

[0025] AutoGPT, or Autonomous GPT, is an open-source autonomous agent framework built on large language models (such as the GPT series). It enables AI (Artificial Intelligence) to automatically decompose tasks, formulate plans, invoke tools, execute operations, and reflect on itself after being given a high-level goal, with minimal reliance on human intervention.

[0026] MetaGPT, or MetaGPT, or Multi-Agent Collaboration Framework for Software Development, is an open-source multi-agent system framework based on Large Language Models (LLM). Its core concept is to decompose complex tasks (especially software development) into multiple roles (such as product managers, architects, programmers, test engineers, etc.), each played by an LLM agent, collaboratively completing tasks through standardized processes.

[0027] JSON: JavaScript Object Notation.

[0028] Pass: An optimization pass, compilation pass, or transformation pass refers to a single analysis, transformation, or optimization operation performed on the intermediate representation (IR) of a program.

[0029] Model paradigm: This can be understood as the interface type or communication protocol of the model, such as OpenAI's ChatML format, Anthropic's Claude format (XML style), and Google's Gemini format. It determines how messages are organized, how tool calls are represented, etc. Model paradigms are usually associated with model providers or model families, but a single provider may have multiple paradigms (but typically a provider has one primary paradigm). Task type can influence the choice of model paradigm, but it is not the only factor.

[0030] Intelligent agent context engineering system: refers to a software system or core framework specifically designed for building, managing and optimizing the context of intelligent agents for large language models. This agent context engineering system can be understood as an independent "agent context engineering system" or "context engine" (a middleware or backend service with a complete data processing pipeline that receives raw interaction events and outputs a highly optimized request context that can be directly sent to various large language model APIs), or a core subsystem or module in an existing agent platform / framework (a specialized module integrated into a broader agent workflow engine or collaboration platform, responsible for context construction and rendering, and collaborating with other modules through clear interfaces (such as event logs and IR structures). This agent context engineering system includes, but is not limited to, an event log manager (responsible for immutably recording and storing all raw events), an IR transformation pipeline (performing standardized transformations from IR0 to IR1, IR2, and IR3), a JIT renderer and decision maker (dynamically selecting and configuring transformation and pruning strategies based on runtime information), a model adapter (converting the final IR into a specific model's API (Application Programming Interface) request format), a tool call state machine (parsing, verifying, and controlling the execution and retry logic of tool calls), and an optimization and analysis module (supporting offline replay, experimental comparison, and strategy tuning based on event logs).

[0031] Most current intelligent agent systems based on large language models treat context engineering as a simple problem of concatenating and truncating several string fragments. While the system level may provide dialogue history storage, tool encapsulation, and some prompt word templates, it lacks abstraction and modeling of the context construction process itself. This exposes several technical bottlenecks as the scale and complexity of intelligent agents continue to increase. Specific technical bottlenecks are as follows: The diversity of model capabilities leads to complex context construction rules: different models vary significantly in terms of whether they support tool calls, structured generation, long contexts, explicit thought chain output, and multimodal support. Existing systems often branch out a set of prompts and concatenation logic for each model at the project level, which becomes increasingly difficult to manage after long-term maintenance. Changing models or using multiple models in combination is almost equivalent to rewriting a set of context engineering or prompts.

[0032] Context length limits the long-term execution of agent tasks: In real-world projects, agents often need to provide reliable conclusions based on earlier decisions or information even after multiple rounds of dialogue, dozens of tool calls, and numerous state transitions. Simply retaining the history of the most recent few rounds of dialogue or summaries often fails to ensure that critical dependencies are not overlooked, while manually writing dedicated summarization logic for each scenario is prone to strong coupling with the workflow and lacks reusability.

[0033] Tool invocation introduces additional complexity: the model needs to generate structured parameters based on the context, the system needs to deserialize the output and perform constraint verification, tool execution may fail and return lengthy results, and subsequent steps may partially depend on these results in multiple iterations. Most existing solutions hardcode this logic around specific tools or nodes, lacking a unified IR and state machine perspective across tools and agents, leading to inconsistent behavior, debugging difficulties, and unpredictable error paths.

[0034] Relying solely on natural language prompts without structural constraints results in very limited control over the execution paths of complex agents: even when the prompts explicitly state rules such as "a tool can only be called once" or "it must abort after three consecutive failures," the model may still deviate from expectations in practice. This is especially true in scenarios involving resource consumption, compliance risks, or security-sensitive operations, where prompt constraints alone are clearly insufficient.

[0035] Currently, there are solutions based on prompt word templates, solutions based on autonomous loops and vector memory, and solutions based on role definitions and standard operating procedures (SOPs).

[0036] Specifically, there are cue word template-based orchestration schemes. The core idea of ​​these frameworks (such as LangChain) is to simplify complex agent processes into a chained or procedural call of a series of "cue word templates." Through abstract classes like PromptTemplate or ChatPromptTemplate, context construction is simplified to variable population of string templates and concatenation of message queues. However, cue word template-based orchestration schemes have two major drawbacks: First, context construction is relatively static. Although it supports some dynamic variables, its core logic is still based on string replacement of predefined templates. It lacks a structured intermediate representation of the context, making it difficult to dynamically adjust rendering strategies at runtime based on token budgets and model capability differences (e.g., automatically switching summary levels, dynamically removing low-priority messages). Second, tool call control is weak, typically relying on an internal ReAct (Reasoning and Acting) loop. The correctness and stopping conditions of tool calls mainly depend on cue words guiding the model to "self-reflect." Without the hard constraints of an external deterministic state machine on the execution path (such as the number of retries and erroneous branches), it is easy to get stuck in an infinite loop or an unexpected state.

[0037] Schemes based on autonomous loops and vector memory: These projects (such as AutoGPT) emphasize the complete autonomy of the agent. They typically maintain a main loop, allowing the model to continuously generate plans, execute actions, and observe results; simultaneously, they utilize vector databases as long-term memory, dynamically injecting relevant history through semantic retrieval. However, schemes based on autonomous loops and vector memory have two core drawbacks: First, the execution path is uncontrollable, heavily reliant on the model's reasoning ability to determine the next action. In complex project scenarios, the model is prone to diverging on incorrect paths. Second, context loss and illusions: relying on vector retrieval for context filling often leads to key causal chains (such as previous erroneous attempts or specific constraints) being missed due to low similarity, causing the model to repeatedly make mistakes and lacking a label-based fine-grained retention strategy.

[0038] Schemes based on role definitions and standard operating procedures (SOPs) (such as MetaGPT) simulate the collaborative processes of human teams by defining "roles" and "actions," attempting to standardize agent behavior through SOPs. However, context engineering is relatively coarse-grained. SOPs primarily operate at the macro-level of role interactions, while at the micro-level of a single model invocation, context construction is often based on fixed role setting templates. It cannot provide fine-grained processing for the specific context or tool results.

[0039] To address the aforementioned technical problems, this specification provides a data processing method in its embodiments. One or more embodiments of this specification also relate to a data processing apparatus, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0040] Specifically, one embodiment of this specification provides a data processing method applied to an intelligent agent context engineering system. The overall implementation of this data processing method is as follows: First, the system (i.e., the agent context engineering system) records all raw interaction events (including user input, agent output, tool call requests and results, workflow state transitions, etc.) in an immutable, append-only manner, forming a complete context event log. Based on this context event log, the system converts each event into a unified initial event intermediate representation (IR0), completing basic content standardization, such as multimodal message decomposition and function call parsing.

[0041] Secondly, the system determines an event processing pipeline consisting of multiple configurable processing stages based on the task type. Multiple transformation processing stages sequentially transform and enhance the initial intermediate representation of each event: in the labeling stage (IR1), event tags are added based on project rules and runtime state to identify key information and processing strategies; in the task structuring stage (IR2), the event sequence is logically reorganized, such as folding multi-round tool calls and injecting process boundaries, forming a context structure oriented towards task execution; in the model adaptation stage (IR3), the structured representation is converted into an intermediate form close to the target model input format, generating candidate event intermediate representations.

[0042] Then, before each actual model call, the Just-In-Time (JIT) renderer dynamically decides the transformation pass to be executed and its parameters based on the target model's capability configuration (e.g., whether it supports tool calls, maximum context length) and current running state (e.g., context budget, historical error records), and calls the model adapter pass to accurately convert the candidate event intermediate representation into the input format supported by the target model, generating the target event intermediate representation.

[0043] Finally, the intermediate representation of the target event is input into the target model to obtain the output of the target model. At this point, the system can control key behaviors such as tool invocation through the tool invocation state machine: the tool invocation command output by the target model is parsed into a structured IR node. If the parsing fails or the constraint is violated, an error feedback IR node is generated and the tool invocation state machine is triggered to make a decision; the tool invocation state machine generates a state transition IR based on the historical IR and the current state, and decides whether to allow retry or switch to an alternative path.

[0044] Furthermore, leveraging the reproducibility of event logs and various levels of IR (In-Representation) capabilities, the system supports replaying the processing of each event in an offline environment. By applying different rendering strategies (such as adjusting the configuration of multiple transformation processing stages in the event processing pipeline, JIT parameters, etc.) and comparing the model output results, the context generation rendering strategy is continuously optimized. The overall implementation of this data processing method decouples context generation into an observable and configurable intermediate representation pipeline, significantly improving the adaptability and reliability of the intelligent agent system in scenarios with multiple models, long tasks, and multiple tools.

[0045] See Figure 1 , Figure 1 This is a flowchart of a data processing method provided in one embodiment of this specification, which specifically includes the following steps.

[0046] Step 102: Convert the target event into an initial intermediate representation of the event using a preset event structure.

[0047] The data processing methods provided in one or more embodiments of this specification can be applied to the field of large language model intelligent agents that require complex, reliable, and long-term operation, including but not limited to complex task-oriented intelligent customer service and virtual assistants (in handling multi-step, cross-system customer service (such as returns, package changes, dispute resolution), the system can ensure that key information (such as order numbers, user requests) is not lost in long conversations, and accurately control the number and order of calls to internal tools (queries, submissions),) and automated project processes and workflow execution (in automated processes such as content creation, data analysis, and code generation, the intelligent agent needs to connect multiple tools and decision points; the system can manage task status and intermediate results in an IR structure to ensure...). The workflow maintains consistency even after dozens of steps, and prevents unlimited resource calls or dangerous operations through state machines. It also includes an agent development platform and debugging analysis (the system provides developers with a highly observable intermediate representation layer, allowing them to replay any failed interaction offline and quickly experiment and optimize by adjusting IR transformation strategies (such as summarization methods and tooltips)). Furthermore, it addresses complex systems involving multiple models and switching (in scenarios where enterprises use multiple LLMs with different capabilities simultaneously, the system acts as a unified "context adaptation layer," dynamically selecting models based on task requirements and automatically generating prompt structures that conform to the characteristics of that model, avoiding the need to maintain independent context splicing logic for each model). These are just a few examples; the list goes on. In short, this data processing method is suitable for any scenario requiring agents to execute reliably in long-term, multi-tool, and high-requirement environments, where their behavior must be predictable, controllable, and optimizable.

[0048] In this context, a target event can be understood as a single interactive unit that needs to be processed during the operation of the agent. Such target events include, but are not limited to, natural language messages input by the user, text replies output by the agent, tool call requests, tool call results, workflow state transition signals, etc.

[0049] For example, the event flow in a coherent interaction is as follows: User-input natural language message: What's the weather like in a certain city today? Workflow state transition signal: The system state changes from idle to processing.

[0050] The agent outputs the following text reply: "Checking the weather for a certain city for you, please wait."

[0051] Tool call request: The model decides to call the get_weather tool (get weather), with the parameter being {"city": "a certain city"}.

[0052] Tool call result: The tool returned "Today in a certain city, sunny, 5-15℃".

[0053] The agent outputs the following text reply: The weather in a certain city is sunny today, with temperatures between 5 and 15 degrees Celsius.

[0054] Workflow state transition signal: The system state changes from processing back to idle, indicating that the task is completed.

[0055] Therefore, based on this example, we can see that each event in the event stream can be the target event.

[0056] The preset event structure can be understood as a standardized event representation format predefined by the system, used to specify how the target event is represented in a standardized way. The preset event structure includes, but is not limited to, fields such as event type (e.g., user_input, agent_output, tool_call, tool_result, workflow_transition), associated roles (e.g., user, assistant, tool), timestamp (the event in which the target event occurred), raw content (the raw data of the target event, such as text input by the user, parameters of the tool call, etc.), and initial tag set (tags assigned to the target event by the system based on preliminary analysis, such as priority, sensitivity, etc.).

[0057] The initial event intermediate representation can be understood as a standardized representation obtained by transforming the target event according to a preset event structure. The specific implementation of transforming the target event according to the preset event structure includes decomposing multimodal messages into text fragments and binary references (such as images, files, etc.) and parsing the JSON function calls of tool requests and model outputs into a unified structure, but no semantic-level summarization or pruning is performed.

[0058] Specifically, the process of converting the target event into an initial intermediate event representation with a preset event structure includes: The target event is determined, wherein the target event is an event in which the user inputs an intelligent agent, or a feedback event during an intermediate execution phase of the intelligent agent; The target event is mapped to an event structure with a preset event structure, wherein the event structure includes the target event and the event type of the target event; The target event is structured according to its event type to obtain an initial intermediate representation of the target event.

[0059] Among them, user-input events of the intelligent agent can be understood as requests or instructions directly initiated by the user, i.e., natural language messages input by the user into the intelligent agent; feedback events during the intermediate execution phase of the intelligent agent can be understood as events generated by the intelligent agent during the workflow execution process that mark the status or progress, i.e., text replies output by the intelligent agent, tool call requests, tool call results, workflow state transition signals, etc.

[0060] The target event can be understood as the raw data of the target event, that is, the raw content mentioned above.

[0061] Event type can be understood as a classification label for the target event. For example, a target event identified as the tool_call type will have its content parsed according to the tool call parameter structure; a target event identified as the user_input type may require multimodal decomposition of its content.

[0062] Structured processing can be understood as the process of applying specific parsing and standardization rules to raw content based on a defined event type. For example, for raw data of a target event of type user_input, text and images are separated; for raw data of a target event of type tool_call, its JSON parameters are parsed into an internally unified call structure.

[0063] The initial event intermediate representation can be understood as the intermediate representation of the target event after "mapping" and "structuring". It can also be called IR0, which is an intermediate representation that conforms to the preset event structure and whose original content has been initially standardized. It provides a unified, stable and project-decoupled input format for subsequent agent processing.

[0064] In practice, the system continuously monitors the agent's operating environment. Once user interaction or agent feedback is detected, it is identified as a target event that needs to be processed. After identifying the target event, it is first mapped to a unified event structure (including event type, role, timestamp, original content, initial tag, etc.). Secondly, the original content of the target event is initially parsed according to the event type and converted into a unified structured representation to generate an initial intermediate event representation.

[0065] See Figure 2 , Figure 2 This is a schematic diagram of the generation process of the intermediate representation of the initial event in a data processing method provided in one embodiment of this specification, which specifically includes the following steps.

[0066] Step 202: Determine the target event.

[0067] Specifically, determining the target event can be understood as obtaining the target event from the context event log.

[0068] Step 204: Normalize event parsing.

[0069] Specifically, standardized event parsing can be understood as follows: First, the target event is encapsulated into a unified event structure, which includes fields such as event type, associated roles, timestamp, original content, and initial tag set. Then, the original content of the target event (such as multimodal content, function calls, or tool calls) is structured according to the event type. This includes breaking down multimodal content into text fragments and binary references, parsing function calls or tool calls into a unified structured representation, and standardizing the format of other event types. Finally, the structured data after structured processing is backfilled into the event structure to generate IR0.

[0070] Step 206: Generate IR0.

[0071] The data processing method provided in one or more embodiments of this specification maps heterogeneous target events (i.e., target events of any source and form, such as text and images sent by users, agent replies, or tool calls and results) into a unified structure, and performs precise structured processing based on event type to generate an initial event intermediate representation, thereby achieving standardization and normalization of data entry points. First, by establishing an immutable, semantically rich initial event intermediate representation, the integrity and traceability of the original content of the target events are ensured, providing a reliable data source for system debugging and playback. Second, when generating this initial event intermediate representation, externally disorganized information formats (such as multimodal content, code instructions, etc.) are pre-sorted and converted into a unique internal standardized format. This allows the system to process only this single format in any subsequent analysis and processing stage, eliminating the need for continuous adjustments and adaptations to multiple external data formats, significantly improving the system's robustness.

[0072] Step 104: Determine the event processing pipeline based on the task type corresponding to the target event.

[0073] The event processing pipeline includes multiple transformation processing stages connected in sequence.

[0074] Task type can be understood as the category of project scenario identified by analyzing the initial intermediate representation and / or historical context of the target event, such as single-turn dialogue, multi-turn tool call chain, structured workflow, multimodal question answering, and other task types.

[0075] An event processing pipeline can be understood as a series of ordered transformation processing stages pre-configured for a specific task type. Each transformation processing stage is an independent transformation processing unit (pass), responsible for performing specific transformation processing on the intermediate representation of the input and outputting an intermediate representation for use by the next transformation processing stage. The event processing pipeline adopts a hierarchical and progressive design. For example, an event processing pipeline includes three transformation processing stages: annotation stage (IR1), task structuring stage (IR2), and model adaptation stage (IR3). The annotation stage performs semantic enhancement on IR0, adding item tags (such as priority and sensitivity), marking key content intervals, injecting control instructions, etc., and outputs IR1. The task structuring stage reorganizes the context according to task logic based on IR1, such as collapsing multi-turn interactions into a single step, inserting virtual stage events, and establishing dependencies between events, and outputs IR2. The model adaptation stage converts IR2 into an intermediate form close to the target model input format, completing adaptation operations such as role mapping and message sequence formatting, while still retaining space for structural adjustments.

[0076] Multiple transformation processing stages are connected sequentially, which can be understood as multiple transformation processing stages being executed in a fixed order. The output of the previous transformation processing stage serves as the input of the next transformation processing stage, forming an event processing pipeline of IR0-IR1-IR2-IR3. Each transformation processing stage can dynamically configure its internal transformation logic and parameters according to the task type. For example, a tool invocation task might enable the "toolchain folding" transformation logic in the IR2 stage, while a dialogue task might enable the "topic segmentation" transformation logic, and so on. In practical applications, different task types correspond to different event processing pipelines, and the number of transformation processing stages and their connection methods will also differ in different event pipelines.

[0077] Specifically, before determining the event processing pipeline based on the task type corresponding to the target event, the process further includes: The intermediate representation of the initial event and the intermediate representation of the historical initial event corresponding to the historical event are parsed to determine the task type corresponding to the target event. The historical event is an event that occurred before the target event in the same agent session as the target event.

[0078] In this context, an agent conversation can be understood as a continuous, stateful interaction process. An agent conversation generally begins with a user initiating a dialogue and ends when the task is completed or the dialogue times out. Any event within an agent conversation is logically and temporally interconnected.

[0079] Historical events can be understood as past events that occurred earlier than the target event in the same intelligent agent dialogue session.

[0080] The intermediate representation of the initial historical events can be understood as the stored IR0 representation corresponding to each historical event.

[0081] Parsing the intermediate representations of initial events and historical initial events can be understood as automatically analyzing and understanding the IR0 of the target event and the IR0 of historical events, including identifying keywords, intents, entities, analyzing the relationship patterns between events, and identifying possible workflows and task structures.

[0082] In practice, the system parses the currently generated target event IRO, representing the current user request or system response, and the historical IRO sequences corresponding to all previous historical events within the same agent session retrieved from persistent storage, to determine the task stage and task type of the target event. For example, it checks whether the current target event's IRO contains explicit tool call instructions, and simultaneously traces back the historical event IROs to see if there are consecutive tool calls and result returns, thus determining whether the current target event's IRO is in a "toolchain execution" task. Alternatively, it analyzes whether the current target event's IRO is an open-ended question, while the historical event IRO sequences are very short, thus classifying it as a new "simple dialogue" task. Through a pre-built rule engine or lightweight machine learning model, the features of the current target event's IRO and the historical event's IRO are matched with known task type features to determine the task type corresponding to the target event, such as "multi-turn information gathering" or "complex workflow advancement."

[0083] The data processing method provided in one or more embodiments of this specification dynamically determines the task type corresponding to the target event by comprehensively analyzing the standardized intermediate representation IRO of the current target event and historical events. This achieves intelligent adaptation of processing strategies and resource optimization, avoiding the need to pre-configure a single, rigid event processing pipeline for all agent dialogues. The system can automatically select an appropriate event processing pipeline based on the actual interaction of the agent dialogue, thereby reducing processing overhead in simple scenarios and enabling advanced functions in complex scenarios, achieving a balance between performance and capability.

[0084] Step 106: Perform transformation processing on the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations.

[0085] Transformation processing can be understood as the specific transformation logic performed on the input data in each transformation processing stage, including but not limited to information enhancement (such as supplementing metadata, adding semantic tags, etc.), structural reorganization (such as folding related events, establishing dependencies, etc.), format conversion (such as mapping the internal structure to the standard message format, etc.), and content optimization (such as performing summarization, pruning, priority sorting, etc.).

[0086] The intermediate representation of a candidate event can be understood as an intermediate representation obtained after multiple transformation and processing stages, such as IR3.

[0087] Specifically, the multiple transformation processing stages correspond to multiple different transformation logics; The step of transforming the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations includes: The different transformation logics corresponding to the multiple transformation processing stages are executed sequentially to transform the intermediate representation of the initial event and the intermediate representation of the historical initial event corresponding to the historical event, thereby generating the intermediate representation of the candidate event.

[0088] The multiple transformation processing stages, each corresponding to a different transformation logic, can be understood as the specific data processing rules, algorithms, or strategies encapsulated within each stage. For example, a labeling stage might include logic for adding tags based on keyword matching and logic for identifying sensitive information based on semantic models. A task structuring stage might include logic for folding tool call sequences and logic for segmenting dialogue topics. In practical applications, each transformation processing stage corresponds to one or more different transformation logics.

[0089] In practice, the system determines an event processing pipeline based on the task type corresponding to the identified target event. This pipeline explicitly defines multiple transformation processing stages that need to be executed sequentially, as well as one or more transformation logics within each stage. At the start of processing, the system sequentially inputs the initial intermediate representation of the target event and the historical initial intermediate representation of historical events into multiple transformation processing stages. These stages then undergo transformation processing through multiple different transformation logics, generating a highly structured, semantically rich candidate intermediate representation of the target event.

[0090] The data processing method provided in one or more embodiments of this specification progressively transforms the initial intermediate representation of a target event by dividing it into processing stages and processing logic. This decomposes complex context processing tasks into multiple independently developable, testable, and optimized sub-units, significantly improving the maintainability and scalability of the system. Furthermore, by incorporating consideration of historical initial intermediate representations into each transformation stage, the system ensures the continuity of key information and task states in long-range dialogues. This allows the generated candidate event intermediate representations to accurately reflect the current stage and dependencies of the dialogue (target event) within the complete task flow, significantly enhancing the accuracy and robustness of complex task processing. In other words, by chaining multiple transformation stages focusing on different dimensions into an event processing pipeline, which progressively processes the initial intermediate representation of the target event with the aid of historical context, the modularization, standardization, and efficiency of the context construction process are achieved.

[0091] In practice, the multiple transformation processing stages include a labeling stage, a task structuring stage, and a model adaptation stage. The process involves sequentially executing multiple different transformation logics corresponding to the multiple transformation processing stages to transform the initial event intermediate representation and the historical event intermediate representation, generating candidate event intermediate representations, including: Execute the label supplementation and adjustment logic corresponding to the labeling stage to supplement and adjust the labels of the initial event intermediate representation and the historical initial event intermediate representation to obtain the first candidate event intermediate representation and the first historical candidate event intermediate representation; Execute the structural adjustment logic corresponding to the task structuring stage to perform structural adjustments on the intermediate representation of the first candidate event and the intermediate representation of the first historical candidate event to obtain the intermediate representation of the second candidate event. The adaptation conversion logic corresponding to the model adaptation stage is executed, and the intermediate representation of the second candidate event is format-converted according to the interface specification of the adaptation model interface to generate the intermediate representation of the candidate event.

[0092] The labeling phase can be understood as the first transformation processing stage in the event processing pipeline. It's used to supplement event tags based on project rules and runtime status, identifying key information and processing strategies. The labeling phase can also be understood as the IR1 phase. In practical applications, during the IR1 phase, the system supplements and adjusts the tags for the target event and the IR0 of historical events based on project configuration and runtime information. For example, it labels high-priority task steps, sensitive information sources, unreliable data segments, or messages requiring special pruning strategies. Tags are also applied at this stage to trigger filtering or other individual processing in subsequent passes.

[0093] The tag supplementation and adjustment logic can be understood as the specific rules or algorithms executed within the tagging stage. By executing this tag supplementation and adjustment logic, the event content (text, structure, etc.) of the target event and historical events can be analyzed. Based on preset project rules, pattern matching, or machine learning models, key information (such as intent, entities, sensitive content, priority signals, etc.) can be identified. Then, new semantic tags can be added to the target event and historical events, existing tags can be modified, or the confidence of tags can be adjusted.

[0094] The intermediate representation of the first candidate event can be understood as the initial intermediate representation of the event. After the labeling and adjustment logic in the annotation stage is used to supplement and adjust the labels, the intermediate representation generated is the IR1 of the target event.

[0095] The intermediate representation of the first historical candidate event can be understood as the intermediate representation of the initial historical event. After the labeling stage, the labeling and adjustment logic is used to supplement and adjust the labels, and the resulting intermediate representation is the IR1 of the historical event.

[0096] The task structuring phase can be understood as the second transformation processing phase of the event processing pipeline, used to logically reorganize the event sequence. This phase can also be understood as the IR2 phase. In practical applications, during IR2, the system reorganizes IR1 around the current task and tool usage scenario. Typical operations include folding a multi-round tool call sequence into a single "toolchain call," aggregating diagnostic and execution events separately, or injecting virtual stage boundary events into a specific workflow. The IR2 generated in this phase makes it easier for the workflow engine to understand and manipulate the context, without having to deal with the raw event details.

[0097] The structural adjustment logic can be understood as the specific rules and algorithms executed within the task structuring phase. By executing this structural adjustment logic, the logical relationship between the target event's IR1 and the historical event's IR1 can be analyzed, and operations such as folding (merging multiple related events into one step), aggregation (grouping similar events), sorting, injecting virtual events (such as stage boundaries), and establishing dependencies can be performed to build a higher-level structured view that reflects the task flow and status.

[0098] The intermediate representation of the second candidate event can be understood as the intermediate representation of the target event generated after the task structuring stage, i.e., the IR2 of the target event.

[0099] The model adaptation stage can be understood as the third transformation processing stage in the event processing pipeline. It is used to convert the structured representation into an intermediate form that is close to the input format of the expected target model type, generating intermediate representations of candidate events. The model adaptation stage can also be understood as the IR3 stage. In practical applications, in the IR3 stage, the system reduces IR2 to a structure close to the final model input format based on the capabilities and interface form of the expected target model type. For example, it maps it to a message sequence structure containing "system prompts + user prompts + tool messages", but at this time, it still retains enough structural information for JIT rendering to further trim and format.

[0100] The adaptation and transformation logic can be understood as the specific rules and algorithms executed within the model adaptation phase. By executing the adaptation and transformation logic, IR2 can be mapped, reorganized, and formatted according to the interface specification (API format) of the expected target model type, converting it into an input format acceptable to the expected target model type.

[0101] The intermediate representation of candidate events can be understood as the final intermediate representation of the target event generated after the model adaptation stage, namely IR3.

[0102] Specifically, the generation of intermediate representations for candidate events is achieved through three transformation processing stages. First, in the labeling stage, by executing label supplementation and adjustment logic, the system performs deep semantic analysis on the IR0 of the target event and the IR0 of historical events, identifying key elements and adding supplementary labels (e.g., marking user intent, identifying sensitive information, marking task priorities, etc.), thereby generating enhanced first candidate event intermediate representations (IR1 of the target event) and first historical candidate event intermediate representations (IR1 of the historical event). Second, in the task structuring stage, by executing structure adjustment logic, the system comprehensively analyzes the IR1 of the target event and historical events, folding historically continuous tool calls and result events into a "completed toolchain" step, or aggregating multi-turn dialogues around the same topic into a logical unit, and possibly inserting virtual events for representation stage transformation. Through this reorganization and abstraction, the task structuring stage outputs a second candidate event intermediate representation (IR2) that clearly reflects the overall structure, state, and dependencies of the task. Finally, in the model adaptation stage, by executing adaptation transformation logic, the system performs adaptation transformation logic according to the interface specification of the pre-selected target model type. This adaptation and transformation logic performs format conversion on the structured IR2, including mapping internal roles to roles specified by the expected target model type, arranging message sequences into an array format required by the expected target model type, and converting tool call information into a format natively supported by the model. After this series of precise conversions, the final candidate event intermediate representation (IR3) is generated, whose format is compatible with the input API of the target model.

[0103] The data processing method provided in one or more embodiments of this specification constructs a standardized and structured processing pipeline from the original target event to the model-ready input through three sequentially executed stages: annotation, task structuring, and model adaptation. By decomposing complex context engineering into three focused sub-tasks—semantic enhancement, logical organization, and interface adaptation—separation of concerns is achieved. This not only allows the logic of each transformation processing stage to be independently optimized and iterated, significantly improving the maintainability and scalability of the system, but also ensures the coherence and integrity of contextual information in long-term and complex tasks through deep integration of historical and current events in the task structuring stage, significantly improving the accuracy and robustness of the agent in handling complex scenarios.

[0104] Furthermore, if the system is configured with long-term memory or monitoring analysis, an IRm can also be generated. Here, IRm is an intermediate representation used for long-term memory and monitoring analysis. The specific implementation method is as follows: Before generating the intermediate representation of candidate events, the method further includes: Based on the long-term memory extraction logic, information is extracted from the intermediate representation of the first candidate event and / or the intermediate representation of the second candidate event to generate an intermediate memory representation. Based on the detection analysis and extraction logic, indicators and events are extracted from the intermediate representation of the first candidate event and / or the intermediate representation of the second candidate event to generate the intermediate representation of the detection.

[0105] The long-term memory extraction logic can be understood as identifying, filtering, and extracting rules or strategies that have lasting value for the agent's long-term operation and continuous learning from the intermediate representations of the event processing pipeline. By executing this long-term memory extraction logic, reusable knowledge or user profiles can be constructed.

[0106] Information extraction can be understood as selectively extracting specific types of data from IR1 and / or IR2, including but not limited to users' explicit preferences (e.g., I like window seats), the final conclusion of task completion (e.g., booking successful, order number **), or recurring error patterns.

[0107] Intermediate representations of memory can be understood as a type of IRm generated through long-term memory retrieval logic. This IRm is a specific type of data extracted from IR1 and / or IR2, organized in a standardized structure (such as entities, relations, attributes, confidence, source context), and stored in a long-term memory bank (such as a vector database or graph database) for retrieval and use in future sessions.

[0108] The detection, analysis and extraction logic can be understood as rules or strategies used to extract in real time from IR1 and / or IR2 that reflect the system's operating status, performance, or abnormal conditions.

[0109] Metrics and event extraction can be understood as extracting quantifiable numerical data, such as tool call latency, message length, frequency of occurrence of specific tags, etc., as well as identifying and recording specific discrete events, such as parsing failure, reaching the call limit, generating sensitive content warnings, etc.

[0110] The detection intermediate representation can be understood as an IRm generated through detection, analysis, and extraction logic. This IRm contains snapshots of the system's real-time health status, sequences of performance indicators, or records of abnormal events. This detection intermediate representation is used to ensure system stability and guide optimization.

[0111] Specifically, after generating the first candidate event intermediate representation (IR1) and the second candidate event intermediate representation (IR2) according to the event processing pipeline, the system determines, based on preset configuration rules (e.g., based on event tags (such as the user_preference tag), task status (such as task completion), or a fixed sampling strategy), whether additional extraction of IR1 and IR2 is needed. If long-term memory needs to be built, the system will initiate long-term memory extraction logic. Executing this long-term memory extraction logic can extract explicitly stated user preferences from IR1, or extract the core conclusions and key decision paths of the task from IR2. Next, the system reorganizes and encapsulates this information to generate a structured intermediate memory representation (IRm-Memory), and stores it in a persistent knowledge base.

[0112] Similarly, if system monitoring and analysis are required, the detection and analysis extraction logic is initiated. Executing this logic continuously captures key signals from IR1 and / or IR2, such as response times for calculated tool calls (metric extraction) or recording an anomaly event upon detecting an error label (event extraction). This real-time data is aggregated and formatted to generate a clear intermediate detection representation (IRm-Monitoring), and continuously streamed to the monitoring backend, providing operations personnel with a real-time view of system health and historical trend analysis.

[0113] See Figure 3 , Figure 3 This is a schematic diagram of the process for generating intermediate representations of candidate events in a data processing method provided in one embodiment of this specification, specifically including the following steps.

[0114] Step 302: Determine IR0.

[0115] Specifically, determining IR0 can be understood as obtaining the initial event intermediate representation IR0 of the target event and the historical initial event intermediate representation IR0 of historical events.

[0116] Step 304: In the annotation stage, perform label supplementation and adjustment logic on IR0 to generate IR1.

[0117] Step 306: In the task structuring phase, perform structural adjustment logic on IR1 to generate IR2.

[0118] Step 308: In the model adaptation phase, perform adaptation transformation logic on IR2 to generate IR3.

[0119] Step 310: Execute the long-term memory extraction logic and the detection and analysis extraction logic to generate the memory intermediate representation IRm and the detection intermediate representation IRm.

[0120] The data processing method provided in one or more embodiments of this specification decouples core project logic from system support functions by establishing a memory and detection information extraction channel independent of the main processing pipeline. This not only avoids interference from non-critical functions with the performance of the main processing pipeline and ensures the real-time performance of task processing, but also, through the extraction of data in a unified format (IR1 or IR2), provides rich contextual sources for the accumulated knowledge (intermediate representation of memory), significantly improving the accuracy and usability of long-term memory. Meanwhile, the real-time extracted indicators and events (intermediate representation of detection) provide the system with high observability.

[0121] Furthermore, when IR1 or IR2 contains long messages, to ensure efficient context generation, a corresponding digest IR can be generated for IR1 or IR2. The specific implementation is as follows: Before generating the intermediate representation of candidate events, the method further includes: If it is determined that the intermediate representation of the first candidate event contains the first content event, the summary generation logic is executed to extract key information from the first content event and generate a first summary intermediate representation of the intermediate representation of the first candidate event, wherein the first content event is an event whose event length meets a preset length threshold. and / or If it is determined that the intermediate representation of the second candidate event contains the second content event, the summary generation logic is executed to extract key information from the second content event and generate a second summary intermediate representation of the intermediate representation of the second candidate event, wherein the second content event is an event whose event length meets the preset length threshold.

[0122] The first content event and the second content event can be understood as specific data units or data blocks that need to be processed, respectively stored in IR1 or IR2. For example, in IR1, the first content event may be a complete long user message, that is, the original content of the target event; in IR2, the second content event may be a logical paragraph folded from a multi-turn dialogue or a lengthy tool execution result.

[0123] The event length meeting the preset length threshold can be understood as a quantitative condition for determining whether to trigger summary generation. Specifically, the system calculates the length of the first or second content event (e.g., the number of text characters, the number of tokens, or the structural complexity) and compares it with a preset threshold. If the length exceeds the threshold, the first or second content event is considered long and requires summary processing.

[0124] The summary generation logic can be understood as the rules, strategies, or models used to automatically extract core information from longer content. It is encapsulated into a callable processing unit, namely the summary generation pass.

[0125] The first or second intermediate summary representation can be understood as an intermediate representation of the summary version generated by compressing and refining the "first content event" or "second content event" through the summary generation pass. The first or second intermediate summary representation is a simplified alternative that retains key information for the first or second content event, and it also has the structure of IR (Information Retrieval).

[0126] In practice, the summary generation pass is embedded in the event processing pipeline as an optional, conditionally triggered processing module. The system continuously monitors the process. After generating the first candidate event intermediate representation (IR1), the system evaluates the length of its internal content units (i.e., the first content event, such as a long user message). If its length exceeds a preset length threshold (indicating the content may be too lengthy), the system triggers the summary generation logic. This logic (e.g., a text summarization model) analyzes the long message, extracting its core intent, key entities, and main conclusions, ultimately generating a simplified first summary intermediate representation. This first summary intermediate representation is then stored as an alternative intermediate representation of the original long message.

[0127] Similarly, when the processing flow reaches the second candidate event intermediate representation (IR2), the system will perform another check. IR2 may contain a logical segment (i.e., the second content event) composed of multiple compressed events. If the logical segment has a complex structure or large content, exceeding a preset length threshold, the system will call the same summary generation logic again to perform an overall summary of this logical segment and generate the second summary intermediate representation. This process can occur independently or simultaneously at the IR1 and IR2 levels, ensuring that whether it is the original event details or the high-level task structure, as long as the content is too long, it can be compressed and refined in a timely manner.

[0128] In practical applications, the intermediate representations of the first and second summaries can not only serve as alternative summaries to replace lengthy original text in the current dialogue, saving valuable model context space; they can also serve as summaries solely for memory and detection purposes. These summaries can be used for memory purposes (persistently stored in long-term memory, such as vector databases or knowledge graphs, so that the system can retrieve and utilize these memories in the future when similar topics or the same user reappear, enabling personalized and coherent services) and for detection purposes (sent to monitoring and analysis systems to analyze agent behavior patterns, model output quality trends, and the reasons for the success / failure of specific tool calls). In other words, the summary generation pass can serve as a specific implementation of long-term memory extraction logic or detection and analysis extraction logic.

[0129] The data processing method provided in one or more embodiments of this specification achieves refined and hierarchical management of long context problems by setting a clear preset length threshold and actively triggering summary generation logic at two levels, IR1 and IR2. First, the lengthy raw input is processed at the IR1 level, controlling the granularity of information from the source. Second, the complex combined structure is compressed again at the IR2 level to ensure the simplicity of the task-level context. This hierarchical summarization mechanism dissolves long content into different levels of abstraction, avoiding information loss or distortion that may be caused by a single-level summary, and providing the subsequent JIT renderer with rich content options of different granularities (original text and summaries at each level). This allows the JIT renderer to make flexible and optimized pruning and replacement decisions based on the actual context budget of the model, thereby preserving the core and logical information of the task to the greatest extent possible within a limited context window.

[0130] Step 108: Determine the target model based on the intermediate representation of the candidate events, and determine the rendering processing stage based on the intermediate representation of the candidate events and the model configuration of the target model.

[0131] Determining the target model can be understood as the system selecting a suitable large language model from the available model pool corresponding to the expected target model type, based on the characteristics of the current task (consisting of a series of target events ordered chronologically and logically) (such as complexity, tool call requirements, multimodal support, etc.) and the features of the intermediate representations of candidate events (such as degree of structure and content type). For example, GPT-4 (Generative Pre-trained Transformer 4) is selected for tasks requiring complex reasoning, and Claude-100K (a version of the Claude large language model series that supports 100,000 (100,000) context tokens) is selected for long text tasks.

[0132] Model configuration can be understood as the static capability description and set of constraint parameters of the target model, including but not limited to the maximum supported long text (Token limit), whether it supports structured output (such as JSON format), whether it has native tool call interface, supported input formats (such as XML format or plain text), role system definition, multimodal support capabilities, etc.

[0133] The rendering process phase can be understood as the JIT renderer dynamically planning and determining a series of rendering steps (passes) and their parameters to be executed before the final model call, based on the characteristics of the intermediate representations of candidate events and the model configuration constraints of the target model. This rendering process phase includes, but is not limited to, a summary replacement phase, a pruning phase, a message sequence order adjustment phase, and a content supplementation phase. Specifically, the summary replacement phase corresponds to summary replacement logic, the pruning phase to pruning logic, the message sequence order adjustment phase to message sequence order adjustment logic, and the content supplementation phase to content supplementation logic.

[0134] Specifically, determining the rendering processing stage based on the intermediate representations of the candidate events and the model configuration of the target model includes: The intermediate representations of the candidate events and the model configuration of the target model are analyzed to obtain the target features of the intermediate representations of the candidate events and the target model parameters of the target model. Based on the target features and the target model parameters, a rendering processing stage is determined, which includes summary replacement logic, pruning logic, and / or content supplementation logic.

[0135] The analysis of the intermediate representation of the candidate events and the model configuration of the target model can be understood as the JIT renderer evaluating and calculating the intermediate representation of the candidate events and the model configuration of the target model.

[0136] The target features of the intermediate representation of candidate events can be understood as key quantitative or attribute indicators related to rendering decisions extracted by analyzing the intermediate representation of candidate events. These target features include, but are not limited to, the estimated total length (number of tokens), the distribution of high-priority content (e.g., key tool calls), the existence of replaceable summary content, and the complexity of structured parts (e.g., tool calls).

[0137] The target model parameters can be understood as the specific numerical values ​​extracted from the model configuration that influence rendering decisions. These target model parameters include the maximum context length, whether the system role is supported, and the specific JSON structure for tool calls, etc.

[0138] Determining the rendering process stage can be understood as the JIT renderer dynamically planning and assembling an execution sequence of rendering processes, containing several specific processing logic (Passes), based on analysis results such as target features and target model parameters. This rendering process stage can be understood as a customized rendering pipeline temporarily generated for this request.

[0139] The summary replacement logic can be understood as a rendering processing logic in the rendering process stage. It replaces the lengthy original content in the candidate event intermediate representation with the first summary intermediate representation / second summary intermediate representation generated in IR1 / IR2 in order to shorten the total length.

[0140] The clipping logic can be understood as another rendering processing logic in the rendering process stage. It is used to remove content blocks that are judged to be low priority and can be discarded in the intermediate representation of candidate events according to the preset priority rules (i.e., combined with the priority tags marked in the IR1 stage) to achieve compression.

[0141] Content supplementation logic can be understood as another type of rendering processing logic in the rendering stage, used to inject additional content into the intermediate representation of candidate events. For example, when multiple parsing failures are detected recently, formatting instructions are automatically appended to the system prompt; or for models that do not support the system role, the system prompt is converted into a special user message, etc.

[0142] In practice, the JIT renderer first performs parallel analysis on the intermediate representations of candidate events and the model configuration of the target model: on the one hand, it deeply scans the intermediate representations of candidate events, calculates the total length of their content, identifies which parts are marked with high-priority tags, which parts already have backup summaries, and evaluates their degree of structure; on the other hand, it accurately reads the model configuration of the target model and extracts its key constraint parameters, such as the upper limit of the context length. Next, the renderer compares and performs conflict detection on these two sets of information, for example, by comparing the calculated total length with the upper limit of the model length.

[0143] Based on the analysis results, the renderer begins to determine the final rendering scheme. If the content is excessively long, it will prioritize using summary replacement logic to replace the long original text with a shorter summary; if it is still too long after replacement or no usable summary is available, it may use pruning logic to discard parts of the content according to priority. Simultaneously, if the analysis reveals a large number of historical errors, it will also use content supplementation logic to insert guiding text into the context. Ultimately, these rendering logics are concretized into an ordered, parameterized rendering processing stage to guide the renderer in performing final, fine-tuned transformations on the intermediate representations of candidate events to generate a better input that meets the requirements of the target model without exceeding its limitations.

[0144] The data processing method provided in one or more embodiments of this specification dynamically determines the rendering strategy by analyzing context features (intermediate representations of candidate events) and model hard constraints (model configuration of the target model) in real time, achieving precise adaptive optimization of context generation under resource-constrained conditions. By transforming the general intermediate representations of candidate events into inputs matching the target model instance, call failures or information truncation caused by excessively long contexts are avoided. This data-driven rendering stage decision-making mechanism enables the system to intelligently balance preserving information integrity with meeting model constraints, ensuring not only the success rate and effectiveness of each call but also automatically improving the quality and stability of model output by enabling logic such as content supplementation, significantly enhancing the robustness and execution efficiency of complex intelligent agent systems overall.

[0145] Step 110: Render the intermediate representation of the candidate event according to the rendering process stage to generate the intermediate representation of the target event.

[0146] The target event intermediate means that it matches the input format of the target model.

[0147] The rendering process of intermediate representations of candidate events based on the rendering process stage can be understood as a rendering pipeline of rendering process stages dynamically determined by the JIT renderer executor, such as executing summary replacement logic, clipping logic, and content supplementation logic in the rendering process stage.

[0148] The intermediate representation of the target event that matches the input format of the target model can be understood as the intermediate representation of the target event that matches the input data structure expected by the target model API.

[0149] See Figure 4 , Figure 4 This is a flowchart illustrating the generation of an intermediate representation of a target event in a data processing method provided in one embodiment of this specification, specifically including the following steps.

[0150] Step 402: Determine the intermediate representation of the candidate event.

[0151] Step 404: Determine the model configuration and inference backend functionality.

[0152] Specifically, determining the model configuration and inference backend functionality can be understood as determining the specific capability parameters of the target model based on its model configuration, such as whether it supports structured output, the format of native tool call interfaces, and the placement of system prompts.

[0153] Step 406: Determine the context budget and constraints.

[0154] Specifically, determining the context budget and constraints can be understood as determining the maximum context length (Token budget) of the target model and other possible constraints (such as length limits for certain fields) based on the model configuration of the target model.

[0155] In practice, steps 402 to 406 can be executed sequentially or in parallel.

[0156] Step 408: Render Pass selection and sorting decisions.

[0157] Specifically, the rendering pass selection and sorting decision can be understood as the system making a comprehensive judgment based on the intermediate representation of candidate events, model configuration and inference backend functions, context budget and constraints, to determine the multiple rendering processing logics included in this rendering stage, as well as the execution order of each rendering processing logic.

[0158] Step 410: Execute the rendering passes in the selected order.

[0159] Specifically, executing rendering passes in the selected order can be understood as the JIT renderer executing each rendering processing logic sequentially according to the order of the rendering pass list generated by the decision in step 408.

[0160] Step 412: Generate intermediate representation of the target event.

[0161] Specifically, the intermediate representation of the target event can be understood as the final output obtained after the JIT renderer executes each rendering processing logic in the order of the rendering pass list generated in step 408.

[0162] See Figure 5 , Figure 5 This is a flowchart of a data processing method for rendering intermediate representations of candidate events, provided in one embodiment of this specification, and specifically includes the following steps.

[0163] Step 502: Determine IR3.

[0164] Step 504: Length estimation.

[0165] Specifically, length estimation can be understood as the JIT renderer calculating the estimated total length (usually in tokens) of the content contained in IR3 (including sequences of system prompts, user messages, tool messages, etc.) after determining IR3.

[0166] Step 506: Start the digest replacement pass.

[0167] Specifically, starting the summary replacement pass can be understood as the JIT renderer comparing the estimated total length with the context budget (i.e., the maximum token limit) of the target model. If the budget is exceeded, the JIT renderer decides to enable the summary replacement pass (i.e., the summary replacement logic).

[0168] Step 508: Output the intermediate representation of the target event.

[0169] Specifically, the intermediate representation of the target event is output, which can be understood as being within the budget, i.e., not exceeding the budget, and IR3 is output as the intermediate representation of the target event.

[0170] Step 510: Perform a digest replacement pass and re-estimate the length.

[0171] Specifically, performing the summary replacement pass and re-estimating can be understood as the system performing the summary replacement pass, replacing the corresponding original long content in IR3 marked as "substitutable for the original text (intermediate representation of the first or second summary)". After completion, the total length of the replaced IR3 is estimated again.

[0172] The total length of the replaced IR3 is compared again with the context budget of the target model. If the budget is met, the process jumps to step 508, and the replaced IR3 is used as the target event representation. If the budget is still exceeded, the JIT renderer decides to enable the clipping pass (clipping logic) and clips the low-priority IR nodes.

[0173] Step 512: Start the cropping pass.

[0174] Specifically, starting the pruning pass can be understood as the system removing parts that meet the conditions based on the preset priority labels (such as "low priority" and "low trust") on the IR node, and performing pruning.

[0175] Step 514: Final length estimation.

[0176] Specifically, the final estimated length can be understood as a final estimate of the total length of the trimmed IR3. If the budget is met: the optimized IR3 is output as the final model input, i.e., the intermediate representation of the target event is output as the final model input. If the budget is still not met (extreme case): the system executes the degraded context logic, generating a degraded context IR node to insert into the IR3 as a system prompt to inform that the model information is incomplete. This event can also be recorded for detection and subsequent optimization. That is, in IR3, there is generally a separate field or a system role message at the beginning of the message sequence. The degraded context logic will append or split a degraded context IR at the end of the system role message, for example, "Due to context length limitations, the dialogue history you see may be incomplete, and some early or minor information has been omitted. Please answer carefully based on the existing information, and do not guess for information that cannot be confirmed."

[0177] Step 516: Generate a degraded context IR.

[0178] After generating the intermediate representation of the target event, it can be input into the target model to obtain the event processing result output by the target model. The specific implementation method is as follows: The generation of the intermediate representation of the target event, wherein after the intermediate representation of the target event is matched with the input format of the target model, further includes: The intermediate representation of the target event is input into the target model to obtain the event processing result output by the target model; If the event processing result is determined to be a tool invocation instruction, the tool invocation instruction is parsed to obtain the parsing result of the tool invocation instruction; If the parsing result indicates that the tool call command failed to be parsed, an intermediate error feedback representation is generated and appended to the event log corresponding to the target event. If the parsing result indicates that the tool call instruction was successfully parsed, an intermediate representation of the tool call is generated and appended to the event log. The target tool corresponding to the tool call instruction is then executed to obtain the tool execution result returned by the target tool.

[0179] The event processing result can be understood as the response content returned by the target model (large language model) after receiving the intermediate representation of the target event as input. This event processing result can be a piece of natural language text or a structured object (such as a JSON-formatted tool call command).

[0180] Tool invocation instructions can be understood as a specific type of model output. Through these instructions, the target model can be identified as expressing its intention to have the system execute a certain external tool, and the tool name and invocation parameters are provided in the form of structured data (such as standard JSON).

[0181] Parsing tool call instructions can be understood as the process by which the system attempts to convert and verify the tool call instructions output by the target model, which may be a mixture of natural language and structure, into an internally unified, executable tool call object. This includes, but is not limited to, syntax checking, structure verification, and parameter constraint verification.

[0182] The analysis results can be understood as the deterministic conclusions of the system after performing structured transformation and validity verification on the tool call instructions output by the target model, including success or failure status and specific content (structured parameter objects in the success status, or error reasons in the failure status).

[0183] Error feedback intermediate representation can be understood as an intermediate representation generated based on the error cause in the case of a failed parsing result. It is an internal state and signal event of the system used to record the cause of the failure (such as JSON syntax error, missing parameters, parameter type mismatch, etc.) and serve as input for subsequent state machine decisions and process control.

[0184] The intermediate representation of a tool call can be understood as an intermediate representation generated based on the structured parameter object in the successful state when the parsing result is successful. This intermediate representation of a tool call is used to record the elements of this tool call, including but not limited to the tool name, parameters, etc., and appends it as a tool call event to the event log corresponding to the target event.

[0185] A target tool can be understood as an external tool specified in the tool invocation instruction that needs to be executed. This target tool can be an API, a function, or a service, etc.

[0186] The execution result of a tool can be understood as the structured data or natural language result returned after the target tool is actually invoked.

[0187] Specifically, the system sends the target event intermediate representation to the target model and retrieves its raw output, i.e., the event processing result. First, the system determines whether the event processing result is a tool invocation command, for example, by checking if the output contains a predefined structured pattern (such as specific JSON keywords). If so, the parsing process is immediately initiated. The parser verifies the format, completeness, and parameters of the tool invocation command to ensure they conform to the constraints defined by the tool (such as type and required fields). If parsing fails, the system generates a structured error feedback intermediate representation. This error feedback intermediate representation records the type, location, and reason for the failure and is appended to the immutable event log of the current target event. This subsequent operation will trigger the state machine listening to the event log, initiating error recovery or retry logic.

[0188] If parsing is successful, the system generates a structured intermediate representation of the tool call and appends it to the event log, recording the event that the target model decides to call a certain tool. The system then calls the corresponding target tool and waits for its execution result. This result is also structured as a new event and appended to the event log, thus closing the loop on the tool call and providing new environmental information for the next step of context generation for the target model.

[0189] Furthermore, if the system determines that the event processing result is not a tool invocation command, it will generate an agent response intermediate representation, which will also be appended to the event log, completing the recording of this round of "think-output" cycle. Secondly, the system will initiate dialogue termination evaluation logic to analyze the current event log (including the recently appended agent response intermediate representation). For example, it might check if the user's latest input is an exit command, or analyze, using a natural language understanding model, whether the agent response intermediate representation has resolved the user's initial intent (task completion). If the evaluation determines that the dialogue should continue, the system will enter a waiting state, ready to receive the user's next input and start a new cycle. If the evaluation meets any termination condition, the system will generate a dialogue termination event and append it as the last event to the event log, completely ending this agent session.

[0190] See Figure 6 , Figure 6 This is a flowchart illustrating the processing of tool call commands in a data processing method provided in one embodiment of this specification, specifically including the following steps.

[0191] Step 602: The target model receives and processes the final input context after rendering: After the intermediate representation of the target event, an output containing the tool invocation intent is generated as a tool invocation candidate.

[0192] Step 604: Parse and Verify. Pass receives the tool call candidates output by the model, attempts to parse them into an internally unified structured format, and performs verification according to a predefined pattern. If parsing is successful and the parameters are compliant, a standard tool call IR is generated; if parsing fails or the parameters violate constraints, an error feedback IR is generated, recording the specific error details.

[0193] Step 606: Once a valid tool call IR is generated, the IR pipeline will append the tool call IR as a formal tool call event to the end of the current session's context event log in chronological order and in an immutable manner to form a persistent record.

[0194] Step 608: After the state machine detects a new tool call IR in the event log, it reviews the tool call IR based on the current workflow status and project rules. If the review is successful, the state machine sends a trigger signal to the system's tool execution engine, notifying it that the corresponding actual tool or API can be executed based on the information encapsulated in the tool call IR.

[0195] Step 610: After the parsing and verification pass generates an error feedback IR, the event log manager inside the IR pipeline appends this error feedback IR as a system feedback event to the end of the context event log in an immutable manner. This operation formally records the error state and triggers the state machine.

[0196] Step 612: After the state machine detects that an error feedback IR has been added to the event log, it will dynamically determine whether and how to retry based on the preset retry strategy (such as error type, number of historical failures, resource limits, etc.) and the current workflow context.

[0197] Step 614: After determining that a retry is allowed, the state machine decides on a specific correction strategy (such as requiring additional parameters) based on the error type and context. Then, it drives the IR pipeline to generate a new system prompt IR containing explicit formatting instructions or constraint reminders, and instructs the event log manager to append it as a formal event to the event log to correct the input context of the subsequent target model (intermediate representation of the target event).

[0198] The data processing method provided in one or more embodiments of this specification performs structured parsing and verification of the tool call intent output by the target model, and uniformly generates intermediate representations (error feedback intermediate representations or tool call intermediate representations) which are then appended to the event log. This ensures that both successful calls and parsing failures are fully recorded in the form of standardized events. This not only provides accurate decision-making basis for the real-time state machine and ensures the controllability of behaviors such as error retries, but also provides an immutable data foundation for post-event auditing, root cause analysis, and strategy optimization of the system.

[0199] In specific implementation, appending the intermediate error feedback to the event log corresponding to the target event further includes: Based on the intermediate representation of the error feedback and the intermediate representation of the historical events in the event log, the retry decision logic is executed using a state machine to obtain the retry decision result; If, based on the retry decision result, it is determined that retries are allowed for errors, an intermediate representation of the state transition is generated; Using the error feedback intermediate representation and the state transition intermediate representation as the initial event intermediate representation, the step of transforming the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations continues; or If, based on the retry decision result, it is determined that erroneous retries are not allowed, an intermediate representation of rejecting the call is generated; Using the error feedback intermediate representation and the call rejection intermediate representation as the initial event intermediate representation, the step of transforming the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations continues.

[0200] Among them, the historical event intermediate representation in the event log can be understood as the intermediate representations (IR0, IR1, IR2, IR3) of each level corresponding to events that occurred earlier than the error feedback event in the same agent session.

[0201] A state machine can be understood as a decision-making and control component in a system. It can analyze error feedback and historical context based on preset project rules (such as the maximum number of retries and a whitelist of error types) and the current workflow state, and make deterministic decisions on whether and how to retry.

[0202] The retry decision logic can be understood as a preset rule or algorithm encapsulated within the state machine, used to evaluate the rationality and method of retry. The input is the intermediate representation of error feedback and the intermediate representation of historical events, and the output is a clear decision result (e.g., "allow retry and provide supplementary parameter format prompts", "reject retry and terminate the process").

[0203] The retry decision result can be understood as the conclusion output by the state machine after executing the retry decision logic. For example, the retry decision result can be a structured object containing action (allow / deny), reason (decision basis), strategy (if allowed, specify the retry strategy, such as "add system prompts"), etc.

[0204] Intermediate representations of state transitions can be understood as a type of control information (IR) generated by a state machine when the retry decision allows retries on errors. An intermediate representation of a state transition records a formal change in the system state (e.g., transitioning from execution failure to waiting for a retry), and may also contain specific instructions that trigger retries (e.g., injecting new guiding system prompts).

[0205] The Reject Call Intermediate Representation can be understood as a control-type IR generated when the retry decision result is that erroneous retries are not allowed. The Reject Call Intermediate Representation records the event that the tool call was rejected by the system, and can also include the reason for rejection (such as reaching the maximum number of retries, or the operation being prohibited by the policy).

[0206] The initial intermediate event representation can be understood as restarting the complete transformation process from the initial intermediate event representation (IR0) based on the updated event log containing these new control events. In practical applications, the system does not only use error feedback IR, state transition IR, and call rejection IR as inputs, but adds them as new events to the event log as history. Then, based on the complete and updated event sequence, a new context, i.e., a new target intermediate event representation, is derived and generated.

[0207] In practice, after a tool call instruction fails to be parsed, the system can achieve a complete closed loop of controlled retries by using state machine decision-driven context reconstruction. The state machine is immediately triggered when the intermediate error feedback is appended to the event log. The state machine reads this intermediate error feedback and, combined with all historical interactions (historical event intermediates) recorded in the event log, executes its built-in retry decision logic. This logic analyzes the nature of the error (whether it's a formatting error or a logical error), checks the number of retries already performed, evaluates whether retrying is allowed in the current task phase, and ultimately generates a clear retry decision.

[0208] If error retries are allowed, the state opportunity-driven system generates a state transition intermediate representation. This intermediate representation not only records state changes but also specifies the retry strategy (e.g., the parameter format needs to be explicitly stated in the system prompt). This new state IR: the intermediate representation of the state transition is appended to the event log. At this point, the event log contains the original interaction history, error feedback, and new retry instructions. The system then uses this updated event log as a new starting point to re-execute the entire event processing pipeline, processing all events in the event log again. This constructs a new context containing lessons learned and corrective guidance—the new target event intermediate representation—and inputs it into the target model, expecting it to output correct tool calls.

[0209] If retries are not allowed, the state machine driver generates a rejected call intermediate representation and appends it to the event log. The system also reruns the entire event processing pipeline based on the updated event log. The new output context allows the target model to know that the current call path is closed, and may instead generate a response explaining to the user or suggesting alternatives.

[0210] See Figure 7 , Figure 7 This is a schematic diagram of the retry strategy of the state machine in a data processing method provided in one embodiment of this specification.

[0211] Figure 7 The document describes a closed-loop process for state machine-based authorization control of tool calls: Upon receiving a tool call IR while idle, the state machine immediately checks the historical call count and the current workflow status. If the historical call count is within limits and the current status allows it, the state machine enters the execution state and drives the system to add an execution log IR and a status update IR to record the authorization. If the limits are exceeded or the current status prohibits it, the state machine transitions to the denial state and adds a denial call IR to the event log, ensuring that each tool call is performed under controlled conditions. These controlled conditions can be understood as a series of preset, verifiable, and structured project rules and system constraints upon which the state machine bases its authorization decisions. In other words, controlled conditions extract the project logic scattered in requirement documents, prompts, or code comments (such as "This tool can be called a maximum of 3 times per day" or "It must be called after step B") into structured rules that the state machine can directly understand and execute, ensuring that each tool call undergoes systematic review rather than relying on the model's self-awareness or the soft constraints of prompts.

[0212] The data processing method provided in one or more embodiments of this specification introduces a state machine to perform structured decision-making on the intermediate representation of error feedback, and injects the decision result (state transition IR or rejection of IR) as a new event into the event log, re-executing the event processing pipeline, thus constructing a rigorous, data-driven self-correcting closed loop. This transforms the originally open and easily uncontrollable prompt-based retry suggestions into system state-controlled retry guaranteed by defined rules, avoiding abnormal behaviors such as infinite retries and ensuring resource security and process controllability. Simultaneously, all decisions and state changes are solidified in the event log in the form of intermediate representations, making the triggering reason, decision basis, and execution path of each retry completely traceable and analyzable. This provides an immutable data foundation for auditing, monitoring, and continuous optimization of system behavior, significantly enhancing the robustness and reliability of complex intelligent agent systems.

[0213] In practical implementation, by treating the context as an information flow (IR) and incorporating it into a state machine, this data processing method achieves a hierarchical control structure in workflow design. The state machine is responsible for defining the stages and rules of the workflow, determining which types of tools are allowed to be called at which stages, the maximum number of allowed calls, the necessary branches for error handling, and the final exit conditions. The model then makes specific decisions within the decision space defined by the state machine, such as selecting the most suitable tool from multiple allowed tools, determining whether sufficient information has been obtained to terminate, and choosing a remedial path after a diagnostic failure.

[0214] The rendering pipeline works in conjunction with the state machine to generate differentiated rendering indicators (IRs) with varying focuses based on the different workflow stages defined by the state machine. For example, error and logging IRs are strengthened in the diagnostic stage; confirmation and safety constraint IRs are emphasized in the execution stage; and conclusions and user-understandable information are focused in the summary stage. These differentiated IR guidance models naturally adjust their behavior and output priorities at the corresponding stages, enabling the rendering pipeline to impose consistent and reliable structural constraints on the overall process based on the rules of the state machine.

[0215] Furthermore, when the returned tool call result is large after execution, a variableization strategy can be applied to the tool call result. The specific implementation is as follows: After obtaining the tool execution result returned by the target tool, the process further includes: If the execution result of the tool meets the preset constraints, a corresponding target variable is assigned to the execution result of the tool, and an intermediate representation of the tool execution is generated based on the target variable and the execution result of the tool, and the intermediate representation of the tool execution is appended to the event log.

[0216] Among them, the preset constraint can be understood as the system's predefined conditions for judging whether the tool's execution result is suitable for variable processing. For example, the preset constraint is that the size of the tool's execution result does not exceed the preset size threshold.

[0217] A target variable can be understood as a unique logical reference identifier assigned by the system to the intelligent result obtained through a large-scale tool. This target variable can be a pointer or key pointing to the complete result stored externally (such as in object storage or a database).

[0218] The tool execution intermediate representation can be understood as a variable, summary-style IR. This tool execution intermediate representation does not contain the complete content of the tool execution result, but records the assigned target variable name, the metadata of the result (such as type, size, hash, etc.), key summaries or outlines (such as the root key of JSON, the number of rows and columns of a table, the first few sentences of the text), and reading tool information for accessing the complete or partial result (such as the tool name and the required variable parameters).

[0219] Specifically, after the tool execution engine returns the tool execution result, the system first evaluates whether it meets preset constraints. If the size of the tool call result is too large, the system initiates a variableization process, generating a unique target variable identifier for the tool call result, and persistently storing the complete tool call result in a dedicated storage service, while associating the target variable with that storage address. Simultaneously, the system can also analyze the tool call result, extract its metadata, and generate a concise content summary (e.g., for a large JSON, extracting its core field structure; for a table, describing its dimensions and examples of the first few rows).

[0220] Secondly, the system uses the target variable, metadata, and content summary to generate an intermediate representation of tool execution. This intermediate representation explicitly informs subsequent systems that a large result exists, its reference being a certain target variable, and details can be retrieved as needed by calling a specified reading tool and passing in the target variable.

[0221] Finally, the system appends the intermediate representation of the tool's execution as a new event to the event log. In subsequent context generation, when the result of this tool call needs to be referenced, the renderer does not expand its full content but instead inserts a descriptive text, thus replacing the massive amount of data with a lightweight reference and description.

[0222] See Figure 8 , Figure 8 This is a flowchart illustrating the generation process of an intermediate representation in a data processing method provided in one embodiment of this specification, specifically including the following steps.

[0223] Step 802: Determine the tool execution result.

[0224] Specifically, determining the execution result of a tool can be understood as the raw output data returned by the tool's execution engine after the external tool (such as an API or database) has finished executing. This execution result may be a large JSON document, a dataset, or a long text.

[0225] Step 804: Metadata extraction and summarization.

[0226] Specifically, metadata extraction and summarization can be understood as the system analyzing the results of the tool's execution, extracting its key metadata (such as data type, size, structure signature, and generation time), and using algorithms to generate a content summary (such as the root field of JSON, the dimensions and sample rows of a table, and key sentences of the text).

[0227] Step 806: Generate the result variable IR.

[0228] Specifically, generating the result variable IR can be understood as performing variable encapsulation based on the metadata and summary extracted in step 804: first, assign a unique logical variable identifier to the tool execution result, and then encapsulate it together with the metadata, content summary, and the reading tool required to access the result to generate a structured result variable IR, which is the intermediate representation of the tool execution.

[0229] Step 808: Write to the event log.

[0230] Specifically, writing to the event log can be understood as the event log manager immutably appending the generated result variable IR as a formal tool result event to the current session's context event log. Simultaneously, the original tool execution result is persistently stored in dedicated storage and associated with a variable identifier.

[0231] Step 810: Read the sub-tool.

[0232] Specifically, the read sub-tool can be understood as a predefined read sub-tool that the target model can invoke when it needs to access details of the tool's execution result in subsequent dialogues, passing the previously assigned target variable (i.e., variable identifier) ​​as a parameter. Upon receiving this call, the tool execution engine retrieves the corresponding complete tool execution result from persistent storage based on the variable identifier and returns all or a specified portion of it for the target model to use in generating a more accurate response.

[0233] The data processing method provided in one or more embodiments of this specification achieves a balance between context resource consumption and information accessibility by variableizing and summarizing the results of large-scale tool executions. This effectively avoids the occupation of expensive model context windows by massive amounts of result data, significantly improving the utilization efficiency of the context budget and enabling the agent to handle more complex task chains. Simultaneously, by structurally recording the metadata, summaries, and access methods (target variables and reading tools) of tool execution results, the system releases context space while still retaining the ability to obtain complete or partial result data on demand, ensuring information integrity and flexibility in subsequent operations.

[0234] Furthermore, after inputting the intermediate representation of the target event into the target model and obtaining the event processing result output by the target model, the method further includes: The processing of the target event is re-executed using different rendering strategies to obtain multiple updated event processing results. The rendering strategy includes the processing configuration of multiple transformation processing stages in the event processing pipeline and the rendering configuration of the rendering processing stage. Based on the results of the multiple update event processing, adjust the processing configuration of multiple transformation processing stages in the event processing pipeline and / or the rendering configuration of the rendering processing stage.

[0235] The rendering strategy can be understood as a complete and configurable context processing strategy, including the processing configuration of multiple transformation processing stages in the event processing pipeline, namely the setting of the enabling status, parameters and rules of each internal Pass (such as summary generation, toolchain folding, and format mapping) in IR1 (annotation stage), IR2 (task structuring stage), and IR3 (model adaptation stage); and the rendering configuration of the rendering processing stage, namely the specific parameter settings of the decision rules of the JIT renderer and the final Pass (such as pruning strategy, content supplementation, and final format conversion).

[0236] Updating event processing results can be understood as replaying the same set of original event logs in an offline environment using different rendering strategies (i.e., different combinations of processing and rendering configurations) to obtain multiple different model output results.

[0237] Optimization can be understood as adjusting and improving the system's overall performance in future tasks by comparing and analyzing the results of multiple update event processing (such as evaluating task completion, response quality, and tool call accuracy) in a data-driven manner, processing the rules and parameters in the configuration and / or rendering configuration.

[0238] Specifically, in the online production environment, after a complete interaction (target event) is processed and the model output is obtained, the system records its complete processing trajectory: including the original immutable event log, the applied rendering strategy configuration, and the final model output, forming a replayable experimental snapshot. Secondly, in the offline experimental environment, the system loads this experimental snapshot. Based on this, the optimization engine automatically generates or selects multiple different rendering strategies. Each strategy fine-tunes or adopts completely different presets for the processing configurations of each transformation stage in the event processing pipeline (such as labeling rules for IR1 and folding logic for IR2) and the rendering configurations of the JIT rendering stage (such as pruning thresholds and summary usage strategies). The system uses these different strategy configurations to re-execute the entire processing process from the original event log to the final model output multiple times. Each replay follows the new rendering strategy and yields a new updated event processing result. By systematically comparing these updated event processing results produced under different rendering strategies (e.g., comparing answer accuracy, task completion steps, and resource consumption), the system can clearly assess the impact of various configuration changes on the final model output. Ultimately, the analysis system will automatically or manually determine the optimal rendering strategy based on preset evaluation metrics (such as success rate, efficiency, and cost), and optimize the processing configuration and rendering logic of the default or specific task type event processing pipeline used by the online system accordingly.

[0239] The data processing method provided in one or more embodiments of this specification achieves secure and continuous iteration of the rendering strategy for agent context engineering by establishing an offline optimization mechanism based on event log replay and strategy comparison. By transforming cue engineering and process optimization into quantifiable and reproducible data-driven experiments, and by systematically testing different combinations of processing and rendering configurations in an isolated environment, the impact of various rendering strategy changes on the final model output can be accurately evaluated, thereby finding the optimal processing and rendering configurations.

[0240] The data processing method provided in one or more embodiments of this specification achieves fundamental improvements by introducing contextual information processing (IR) and just-in-time (JIT) rendering mechanisms. At an abstract level, this method elevates context construction from repetitive text splicing and truncation operations to a clear pipeline from event logs to multi-level IR, making context engineering itself an independently designable, debuggable, deployable, and evolving subsystem. This effectively decouples the project workflow from the model interface. When it is necessary to change the model, adjust the summary strategy, or add a new tool invocation mode, only local adjustments are needed at the IR Pass and JIT strategy layers, without triggering changes at the project logic layer. In terms of control, the solution transforms call count limits, error branch selection, and resource consumption control into verifiable, structured constraints through the collaboration of tool invocation IR, error feedback IR, and deterministic state machines. Even if the model outputs unexpected results, the system can consistently handle them according to rules at the IR and state machine levels, thereby achieving truly trustworthy behavioral constraints in high-reliability and high-risk scenarios.

[0241] Specifically, this data processing method first systematizes the previously scattered context construction rules, which were distributed across templates, code, and configurations, by introducing a multi-level Context IR construction and Pass pipeline. This forms a multi-layered intermediate representation transformation link from event logs to model input. This decouples project logic from model interfaces and supports differentiated context processing strategies for different scenarios and models through a composable Pass system. Secondly, a JIT rendering mechanism combining model capabilities and context budget is constructed. This mechanism dynamically selects and configures the rendering Pass based on real-time runtime status (such as target model specifications, remaining token budget, and content distribution) during each model call. This allows strategies such as summarization, pruning, and format adaptation to make the most appropriate real-time decisions, rather than being hard-coded into fixed processes. Then, the entire tool call process (parsing, feedback, execution) is uniformly incorporated into the IR system. Through the collaboration of tool call IR, error feedback IR, and tool execution IR, tool usage is elevated from functional enhancement at the interface level to structural behavior at the IR layer, making all tool interactions events that can be strictly reviewed and controlled by the state machine. Simultaneously, an IR variableization strategy for large-volume tool results is designed. The system assigns logical variable identifiers to large results and records their metadata, summaries, and access methods in the Information Representation (IR), rather than directly embedding the complete content. This minimizes the impact on the context budget without sacrificing result accessibility and allows for hierarchical retention and on-demand loading through tags. Furthermore, a deterministic tool execution state machine based on IR is constructed. The state machine encodes the allowed tool sets, call limits, error branches, and exit conditions at its own level, transforming the previously "soft constraints" relying on prompt words into verifiable and executable "hard constraints," significantly improving the controllability and security of complex agent execution paths.

[0242] Corresponding to the above method embodiments, this specification also provides data processing apparatus embodiments. Figure 9 A schematic diagram of the structure of a data processing apparatus according to one embodiment of this specification is shown. Figure 9 As shown, the device includes: Event conversion module 902 is configured to convert a target event into an initial intermediate event representation with a preset event structure; The pipeline determination module 904 is configured to determine an event processing pipeline based on the task type corresponding to the target event, wherein the event processing pipeline includes multiple transformation processing stages connected in sequence. Transformation processing module 906 is configured to transform the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations; The rendering module 908 is configured to determine the target model based on the intermediate representation of the candidate events, and to determine the rendering processing stage based on the intermediate representation of the candidate events and the model configuration of the target model. The context generation module 910 is configured to perform rendering processing on the candidate event intermediate representation according to the rendering processing stage to generate the target event intermediate representation, wherein the target event intermediate representation matches the input format of the target model.

[0243] Optionally, the event conversion module 902 is further configured to: The target event is determined, wherein the target event is an event in which the user inputs an intelligent agent, or a feedback event during an intermediate execution phase of the intelligent agent; The target event is mapped to an event structure with a preset event structure, wherein the event structure includes the target event and the event type of the target event; The target event is structured according to its event type to obtain an initial intermediate representation of the target event.

[0244] Optionally, the device further includes: The task type determination module is configured as follows: The intermediate representation of the initial event and the intermediate representation of the historical initial event corresponding to the historical event are parsed to determine the task type corresponding to the target event. The historical event is an event that occurred before the target event in the same agent session as the target event.

[0245] Optionally, the multiple transformation processing stages correspond to multiple different transformation logics; The transformation processing module 906 is further configured as follows: The different transformation logics corresponding to the multiple transformation processing stages are executed sequentially to transform the intermediate representation of the initial event and the intermediate representation of the historical initial event corresponding to the historical event, thereby generating the intermediate representation of the candidate event.

[0246] Optionally, the multiple transformation processing stages include a labeling stage, a task structuring stage, and a model adaptation stage; The transformation processing module 906 is further configured as follows: Execute the label supplementation and adjustment logic corresponding to the labeling stage to supplement and adjust the labels of the initial event intermediate representation and the historical initial event intermediate representation to obtain the first candidate event intermediate representation and the first historical candidate event intermediate representation; Execute the structural adjustment logic corresponding to the task structuring stage to perform structural adjustments on the intermediate representation of the first candidate event and the intermediate representation of the first historical candidate event to obtain the intermediate representation of the second candidate event. The adaptation conversion logic corresponding to the model adaptation stage is executed, and the intermediate representation of the second candidate event is format-converted according to the interface specification of the adaptation model interface to generate the intermediate representation of the candidate event.

[0247] Optionally, the device further includes: The memory detection module is configured as follows: Based on the long-term memory extraction logic, information is extracted from the intermediate representation of the first candidate event and / or the intermediate representation of the second candidate event to generate an intermediate memory representation. Based on the detection analysis and extraction logic, indicators and events are extracted from the intermediate representation of the first candidate event and / or the intermediate representation of the second candidate event to generate the intermediate representation of the detection.

[0248] Optionally, the device further includes: The abstract extraction module is configured as follows: If it is determined that the intermediate representation of the first candidate event contains the first content event, the summary generation logic is executed to extract key information from the first content event and generate a first summary intermediate representation of the intermediate representation of the first candidate event, wherein the first content event is an event whose event length meets a preset length threshold. and / or If it is determined that the intermediate representation of the second candidate event contains the second content event, the summary generation logic is executed to extract key information from the second content event and generate a second summary intermediate representation of the intermediate representation of the second candidate event, wherein the second content event is an event whose event length meets the preset length threshold.

[0249] Optionally, the rendering module 908 is further configured to: The intermediate representations of the candidate events and the model configuration of the target model are analyzed to obtain the target features of the intermediate representations of the candidate events and the target model parameters of the target model. Based on the target features and the target model parameters, a rendering processing stage is determined, which includes summary replacement logic, pruning logic, and / or content supplementation logic.

[0250] Optionally, the device further includes: The tool calls the module and is configured as follows: The intermediate representation of the target event is input into the target model to obtain the event processing result output by the target model; If the event processing result is determined to be a tool invocation instruction, the tool invocation instruction is parsed to obtain the parsing result of the tool invocation instruction; If the parsing result indicates that the tool call command failed to be parsed, an intermediate error feedback representation is generated and appended to the event log corresponding to the target event. If the parsing result indicates that the tool call instruction was successfully parsed, an intermediate representation of the tool call is generated and appended to the event log. The target tool corresponding to the tool call instruction is then executed to obtain the tool execution result returned by the target tool.

[0251] Optionally, the device further includes: The retry module is configured as follows: Based on the intermediate representation of the error feedback and the intermediate representation of the historical events in the event log, the retry decision logic is executed using a state machine to obtain the retry decision result; If, based on the retry decision result, it is determined that retries are allowed for errors, an intermediate representation of the state transition is generated; Using the error feedback intermediate representation and the state transition intermediate representation as the initial event intermediate representation, the step of transforming the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations continues; or If, based on the retry decision result, it is determined that erroneous retries are not allowed, an intermediate representation of rejecting the call is generated; Using the error feedback intermediate representation and the call rejection intermediate representation as the initial event intermediate representation, the step of transforming the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations continues.

[0252] Optionally, the device further includes: The variable module is configured as follows: If the execution result of the tool meets the preset constraints, a corresponding target variable is assigned to the execution result of the tool, and an intermediate representation of the tool execution is generated based on the target variable and the execution result of the tool, and the intermediate representation of the tool execution is appended to the event log.

[0253] Optionally, the device further includes: The optimization module is configured as follows: The processing of the target event is re-executed using different rendering strategies to obtain multiple updated event processing results. The rendering strategy includes the processing configuration of multiple transformation processing stages in the event processing pipeline and the rendering configuration of the rendering processing stage. Based on the results of the multiple update event processing, adjust the processing configuration of multiple transformation processing stages in the event processing pipeline and / or the rendering configuration of the rendering processing stage.

[0254] In practical implementation, this data processing device can be understood as the core implementation component of the aforementioned intelligent agent context system. This data processing device is used to solve the problem of how to process raw events step by step into inputs that adapt to the target model. It is the standardized and reusable core processing engine in the intelligent agent context system responsible for "preparing raw materials for thinking." A complete intelligent agent context system, in addition to this data processing device, may also include an event log storage system (providing immutable event log storage, serving as a shared data source and output destination for all modules of the data processing device), a state machine (interacting with the rendering module and transformation processing module, receiving error feedback (IR), making decisions such as retry and rejection, and driving the generation of new control events (such as state transition (IR))), a tool execution engine (receiving model instructions driven by the context generation module of the data processing device, actually calling the tool, and returning the results to the system), and a policy and configuration manager (managing the mapping relationship between task types and pipelines, parameter configurations for various passes, model configurations, etc., for use by the pipeline determination module and the rendering module), etc.

[0255] The above is an illustrative scheme of the data processing apparatus of this embodiment. It should be noted that the technical solution of this data processing apparatus and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the data processing apparatus, please refer to the description of the technical solution of the data processing method described above.

[0256] See Figure 10 , Figure 10 This is a structural block diagram of a computing device provided in one embodiment of this specification.

[0257] The components of the computing device 1000 include, but are not limited to, a memory 1010 and a processor 1020. The processor 1020 is connected to the memory 1010 via a bus 1030, and a database 1050 is used to store data.

[0258] The computing device 1000 also includes an access device 1040, which enables the computing device 1000 to communicate via one or more networks 1060. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 1040 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0259] In one embodiment of this specification, the above-described components of the computing device 1000 and Figure 10 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 10 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0260] The computing device 1000 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 1000 can also be a mobile or stationary server.

[0261] The processor 1020 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described data processing method.

[0262] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the data processing method described above.

[0263] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described data processing method.

[0264] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the data processing method described above.

[0265] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described data processing method.

[0266] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the data processing method described above.

[0267] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0268] The computer program / instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0269] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0270] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0271] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A data processing method, comprising: Convert the target event into an initial intermediate event representation with a preset event structure; Based on the task type corresponding to the target event, an event processing pipeline is determined, wherein the event processing pipeline includes multiple transformation processing stages connected in sequence; The initial intermediate representation of the event is transformed according to the multiple transformation processing stages to generate candidate intermediate representations of the event. The target model is determined based on the intermediate representation of the candidate events, and the rendering process stage is determined based on the intermediate representation of the candidate events and the model configuration of the target model. The intermediate representations of the candidate events are rendered according to the rendering process stage to generate the intermediate representation of the target event, wherein the intermediate representation of the target event matches the input format of the target model.

2. The data processing method according to claim 1, wherein converting the target event into an initial intermediate event representation with a preset event structure includes: The target event is determined, wherein the target event is an event in which the user inputs an intelligent agent, or a feedback event during an intermediate execution phase of the intelligent agent; The target event is mapped to an event structure with a preset event structure, wherein the event structure includes the target event and the event type of the target event; The target event is structured according to its event type to obtain an initial intermediate representation of the target event.

3. The data processing method according to claim 1, before determining the event processing pipeline based on the task type corresponding to the target event, further includes: The intermediate representation of the initial event and the intermediate representation of the historical initial event corresponding to the historical event are parsed to determine the task type corresponding to the target event. The historical event is an event that occurred before the target event in the same agent session as the target event.

4. The data processing method according to claim 1, wherein the plurality of transformation processing stages correspond to a plurality of different transformation logics; The step of transforming the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations includes: The different transformation logics corresponding to the multiple transformation processing stages are executed sequentially to transform the intermediate representation of the initial event and the intermediate representation of the historical initial event corresponding to the historical event, thereby generating the intermediate representation of the candidate event.

5. The data processing method according to claim 4, wherein the plurality of transformation processing stages include a labeling stage, a task structuring stage, and a model adaptation stage; The process involves sequentially executing multiple different transformation logics corresponding to the multiple transformation processing stages to transform the initial event intermediate representation and the historical event intermediate representation, generating candidate event intermediate representations, including: Execute the label supplementation and adjustment logic corresponding to the labeling stage to supplement and adjust the labels of the initial event intermediate representation and the historical initial event intermediate representation to obtain the first candidate event intermediate representation and the first historical candidate event intermediate representation; Execute the structural adjustment logic corresponding to the task structuring stage to perform structural adjustments on the intermediate representation of the first candidate event and the intermediate representation of the first historical candidate event to obtain the intermediate representation of the second candidate event. The adaptation conversion logic corresponding to the model adaptation stage is executed, and the intermediate representation of the second candidate event is format-converted according to the interface specification of the adaptation model interface to generate the intermediate representation of the candidate event.

6. The data processing method according to claim 5, further comprising, before generating the intermediate representation of candidate events: Based on the long-term memory extraction logic, information is extracted from the intermediate representation of the first candidate event and / or the intermediate representation of the second candidate event to generate an intermediate memory representation. Based on the detection analysis and extraction logic, indicators and events are extracted from the intermediate representation of the first candidate event and / or the intermediate representation of the second candidate event to generate the intermediate representation of the detection.

7. The data processing method according to claim 5, further comprising, before generating the intermediate representation of candidate events: If it is determined that the intermediate representation of the first candidate event contains the first content event, the summary generation logic is executed to extract key information from the first content event and generate a first summary intermediate representation of the intermediate representation of the first candidate event, wherein the first content event is an event whose event length meets a preset length threshold. and / or If it is determined that the intermediate representation of the second candidate event contains the second content event, the summary generation logic is executed to extract key information from the second content event and generate a second summary intermediate representation of the intermediate representation of the second candidate event, wherein the second content event is an event whose event length meets the preset length threshold.

8. The data processing method according to claim 1, wherein determining the rendering processing stage based on the intermediate representation of the candidate events and the model configuration of the target model includes: The intermediate representations of the candidate events and the model configuration of the target model are analyzed to obtain the target features of the intermediate representations of the candidate events and the target model parameters of the target model. Based on the target features and the target model parameters, a rendering processing stage is determined, which includes summary replacement logic, pruning logic, and / or content supplementation logic.

9. The data processing method according to any one of claims 1-8, wherein the generation of the target event intermediate representation, After the intermediate representation of the target event matches the input format of the target model, it also includes: The intermediate representation of the target event is input into the target model to obtain the event processing result output by the target model; If the event processing result is determined to be a tool invocation instruction, the tool invocation instruction is parsed to obtain the parsing result of the tool invocation instruction; If the parsing result indicates that the tool call command failed to be parsed, an intermediate error feedback representation is generated and appended to the event log corresponding to the target event. If the parsing result indicates that the tool call instruction was successfully parsed, an intermediate representation of the tool call is generated and appended to the event log. The target tool corresponding to the tool call instruction is then executed to obtain the tool execution result returned by the target tool.

10. The data processing method according to claim 9, wherein appending the intermediate error feedback representation to the event log corresponding to the target event further comprises: Based on the intermediate representation of the error feedback and the intermediate representation of the historical events in the event log, the retry decision logic is executed using a state machine to obtain the retry decision result; If, based on the retry decision result, it is determined that retries are allowed for errors, an intermediate representation of the state transition is generated; Using the error feedback intermediate representation and the state transition intermediate representation as the initial event intermediate representation, the step of transforming the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations continues; or If, based on the retry decision result, it is determined that erroneous retries are not allowed, an intermediate representation of rejecting the call is generated; Using the error feedback intermediate representation and the call rejection intermediate representation as the initial event intermediate representation, the step of transforming the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations continues.

11. The data processing method according to claim 9, further comprising, after obtaining the tool execution result returned by the target tool: If the execution result of the tool meets the preset constraints, a corresponding target variable is assigned to the execution result of the tool, and an intermediate representation of the tool execution is generated based on the target variable and the execution result of the tool, and the intermediate representation of the tool execution is appended to the event log.

12. The data processing method according to claim 9, after inputting the intermediate representation of the target event into the target model and obtaining the event processing result output by the target model, further comprising: The processing of the target event is re-executed using different rendering strategies to obtain multiple updated event processing results. The rendering strategy includes the processing configuration of multiple transformation processing stages in the event processing pipeline and the rendering configuration of the rendering processing stage. Based on the results of the multiple update event processing, adjust the processing configuration of multiple transformation processing stages in the event processing pipeline and / or the rendering configuration of the rendering processing stage.

13. A data processing apparatus, comprising: The event conversion module is configured to convert a target event into an initial intermediate event representation with a preset event structure; The pipeline determination module is configured to determine an event processing pipeline based on the task type corresponding to the target event, wherein the event processing pipeline includes multiple transformation processing stages connected in sequence. The transformation processing module is configured to transform the initial event intermediate representation according to the multiple transformation processing stages to generate candidate event intermediate representations. The rendering module is configured to determine the target model based on the intermediate representation of the candidate events, and to determine the rendering processing stage based on the intermediate representation of the candidate events and the model configuration of the target model. The context generation module is configured to perform rendering processing on the intermediate representation of the candidate event according to the rendering processing stage to generate the intermediate representation of the target event, wherein the intermediate representation of the target event matches the input format of the target model.

14. A computing device, comprising: A memory and a processor, the memory and the processor being connected via a bus; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the data processing method according to any one of claims 1-12.

15. A computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the data processing method according to any one of claims 1-12.

16. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the data processing method according to any one of claims 1-12.

Images