Method for driving flow switching of travel text and multi-view synchronization
By combining front-end natural language input and semantic parsing of a multi-agent framework with back-end automated tools to generate a multi-view synchronization method, the problems of data inconsistency and cumbersome operations in the itinerary planning system are solved. This enables the driven generation of itinerary text and enterprise-level data synchronization, improving user interaction experience and data processing efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGZHOU CHINA AIR SERVICE LTD
- Filing Date
- 2026-04-17
- Publication Date
- 2026-06-12
AI Technical Summary
Existing itinerary planning systems lack dynamic interactive capabilities, making it difficult to confirm and adjust itinerary details in real time. The lack of synchronization mechanisms between different views leads to inconsistent data and cumbersome operations, making it difficult to meet the needs of modern enterprises for automated generation and cross-system reuse of itinerary documents.
Natural language input is collected through the front-end chat interface. Semantic parsing and entity extraction are performed using the AutoGen multi-agent framework and the OpenAI large language model to generate structured itinerary data. This data is then streamed to the front end via Server-Sent Events. The back end uses the Jinja2 template engine and Playwright tool to automatically generate contract documents and promotional images. The unified data source is synchronized to the enterprise business system to achieve multi-view synchronization and automatic updates.
It enables driven generation and streaming switching of itinerary text, improves user interaction experience and data processing efficiency, ensures data consistency and accuracy, and supports unified data source and data reuse under access control for enterprise-level business processes.
Smart Images

Figure CN122197836A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, specifically to a method for streaming switching and multi-view synchronization of driven process text. Background Technology
[0002] In the field of intelligent trip planning and document generation, traditional trip processing systems typically adopt a linear process of "input-generation-output," lacking dynamic interaction capabilities between users and the system, making it difficult to achieve real-time confirmation and adjustment of trip details; In addition, existing systems typically process different views such as itinerary text, contract documents, and promotional images independently when processing itinerary data. There is a lack of synchronization mechanism between these views. When itinerary information changes, each view needs to be repeatedly edited and updated, which is not only cumbersome but also prone to data inconsistency. For example, after a user adjusts flight information, the corresponding clauses in the contract document and the itinerary card in the promotional image often cannot be automatically updated and require manual intervention, which seriously affects the continuity and accuracy of business processes. On the other hand, existing itinerary planning systems mostly use a single data source and a fixed output format, lacking the real-world need for deep integration of technologies such as multi-agent collaboration, streaming interaction, and multi-view synchronization, making it difficult to meet the needs of modern enterprises for automated generation, batch processing, and cross-system reuse of itinerary documents. Therefore, there is an urgent need for a method that can achieve iterative text-driven generation, streaming switching, and multi-view synchronization to improve the intelligence level of iterative planning and data processing efficiency. Summary of the Invention
[0003] In order to solve the problems existing in the prior art, the purpose of this application is to provide a method for streaming switching and multi-view synchronization of driven process text.
[0004] The method for streaming switching and multi-view synchronization of driven trip text described in this application includes: S101, the front end collects trip-related information input by the customer in natural language through the chat interface, the back end receives the request based on the FastAPI framework, uses the AutoGen multi-agent framework to call the OpenAI large language model to perform semantic parsing and entity extraction on the input content, and converts the unstructured information into a standardized trip data structure that conforms to the definition of the Pydantic model to form an initial trip data object; S102. The backend passes the initial itinerary data object to the AutoGen intelligent agent, which combines the user's historical preferences and destination resource information obtained by the XServer2 business service to generate itinerary suggestions. The suggestions are then streamed to the frontend via Server-Sent Events to obtain an itinerary confirmation form for user confirmation. After the user completes the detailed confirmation on the frontend, the backend verifies the data integrity through Pydantic, calls the XServer2 SDK to persist the final itinerary data to the MySQL database, and uses the Upyun SDK to store the attachments uploaded by the user to cloud storage, forming the solidified formal itinerary data. S103. Based on the solidified formal itinerary data, the backend uses the Jinja2 template engine to render the contract template, generates a Word version of the contract document through python-docx, and combines the Playwright browser automation tool to render the HTML template into a PDF file. After batch generating standard contract files, they are uploaded to UPYUN CDN and a downloadable access link is returned. S104. The backend calls Playwright to generate visual itinerary cards, itinerary posters and other promotional images based on the solidified official itinerary data, or the frontend uses Tailwind CSS and Ant Design component library to build the layout and then the backend renders and captures the generated promotional images, stores them in Upyun and returns the address. S105. The solidified formal itinerary data is synchronized to the enterprise's internal business systems such as contract management, customer relations, and financial settlement through the XServer2 SDK, forming a unified data source for enterprise-level business processes. The front end uses the ReactRouter and OpenID Connect authentication mechanism for data reuse and display under access control, supporting subsequent itinerary iteration, replication, and expansion.
[0005] Preferably, in step S101, the front-end interface obtains the user's natural language input and stores it as raw text. The back-end receives the raw text and transmits it to the multi-agent system for semantic parsing and key unit identification to obtain structured semantic results. Entity extraction generates preliminary trip elements, and the missing parts are supplemented by the system in combination with the context. The complete elements are mapped to the standard data model to generate trip objects, which are then checked by a verification tool to output the final standardized trip data.
[0006] Preferably, in step S102, for structured data, combined with historical preferences and destination resources, the AutoGen agent integrates and generates preliminary itinerary suggestions, which are then streamed to the front end via SSE. After obtaining user confirmation details, the data module processes and provides feedback to complete the final adjustments. The suggestions are then verified and completed by Pydantic, stored in MySQL using the XServer2 SDK, and the attachments are stored in the cloud service via the Upyun SDK to obtain the official itinerary document.
[0007] Preferably, in step S103, for the solidified itinerary document data, the Jinja2 template engine is used to match the contract template to generate an HTML format contract, which is then converted into Word and PDF files using python-docx and Playwright. After unified archiving, the files are uploaded to UPYUN CDN storage, an accessible link is generated and bound to the itinerary data in the database, and the validity of the link is checked periodically. If the link is unreachable, a backup link is generated and the record is updated.
[0008] Preferably, in step S104, key fields are extracted and categorized for the core information of the formal itinerary data. Playwright is used to dynamically generate visual cards and promotional posters. After front-end layout adjustment, screenshots are rendered to complete the image material production. The images are then format-checked and standardized. They are uploaded in batches to the distributed storage system. An encrypted access address is generated according to the storage path, associated and bound to the itinerary documents, and persistently stored to obtain associated data records.
[0009] Preferably, in step S105, the latest itinerary information is synchronized through the XServer2 SDK and distributed to the business systems of contract management, customer relations and financial settlement. Mapping rules are constructed for association, access is restricted through permission control, the front end adapts to display the information visible to each system, subsequent itinerary data is dynamically updated through extended interfaces and persistently stored in the business systems.
[0010] The method for driving the streaming switching and multi-view synchronization of itinerary text described in this application has the advantage that it collects the user's natural language input through the front-end chat interface, uses the AutoGen multi-agent framework and OpenAI large language model for semantic parsing and entity extraction, converts unstructured information into structured itinerary data in real time, and pushes itinerary suggestions to the front end in real time through Server-Sent Events streaming transmission technology to form a "confirmation slip" for the user to confirm dynamically. The user can intervene and adjust at any time, and the system responds in real time, realizing the driving generation and streaming switching of itinerary text, which significantly improves the user interaction experience and the accuracy of itinerary planning. This invention uses the solidified itinerary data as a unified data source. The unified data source automatically generates contract documents and promotional images through the Jinja2 template engine, python-docx, and Playwright tools, ensuring that all output views originate from the same itinerary data. When itinerary information changes, only the data source needs to be updated, and the system can automatically generate updated contract documents and promotional images, eliminating the need for manual re-editing. This effectively avoids data inconsistency issues between multiple views and significantly improves document generation efficiency and accuracy. This invention uses the XServer2 SDK to synchronize the solidified itinerary data to the enterprise's internal contract management, customer relations, and financial settlement business systems, forming a unified data source for enterprise-level business processes. The front end uses React Router and OpenID Connect authentication mechanisms to achieve data reuse and display under access control, supporting subsequent itinerary iteration, replication, and expansion. This breaks down the barriers in traditional systems where itinerary data is difficult to flow across systems, and enhances the utilization value of data assets. This invention is based on a front-end and back-end separation architecture, containerized deployment, and GitLab CI / CD automated pipeline. It realizes fully automated processing from information collection, intelligent suggestions, confirmation and solidification, multi-format output to data reuse, reduces the cost of manual intervention, improves system maintainability and scalability, and is suitable for batch processing scenarios of large-scale itinerary documents. Attached Figure Description
[0011] Figure 1 This is the flow chart of a method for streaming switching and multi-view synchronization of driven process text as described in this application. Figure 1 ; Figure 2 This is the flow chart of a method for streaming switching and multi-view synchronization of driven process text as described in this application. Figure 2 . Detailed Implementation
[0012] like Figures 1-2 As shown, this application describes a method for streaming switching and multi-view synchronization of driven process text.
[0013] like Figures 1-2 As shown, in step S101, the front end collects the trip-related information input by the customer in natural language through the chat interface. The back end receives the request based on the FastAPI framework, uses the AutoGen multi-agent framework to call the OpenAI large language model to perform semantic parsing and entity extraction on the input content, and converts the unstructured information into a standardized trip data structure that conforms to the definition of the Pydantic model to form the initial trip data object.
[0014] Furthermore, in step S101, the natural language content input by the user is obtained through the front-end interface and chat collection mechanism and stored as raw text data; Based on the original text data, the backend framework is used to process the received requests and transmit the text content to the multi-agent system for initial distribution. Within a multi-agent system, semantic parsing is performed on the transmitted text content to identify key semantic units and obtain structured semantic results. Based on the semantic results, entity extraction is performed to extract specific entities related to the itinerary information, forming a preliminary set of itinerary elements; If there are missing or incomplete parts in the set of trip elements, the complete trip elements are determined by supplementary logic within the multi-agent system and inference from the context. Based on the complete itinerary elements, map them to the standard data model to generate itinerary data objects that conform to the predefined format; For the generated itinerary data objects, a verification tool is used to check the data integrity and determine whether it meets the standard data requirements, thus obtaining the final standardized itinerary data.
[0015] Specifically, in step S101, in the front-end chat interface, the user is pre-selected to input natural language to describe the trip information, such as "flying from Shanghai to Beijing at 3 pm tomorrow, staying for two nights, budget 5000 yuan". The front-end transmits the user input to the back-end in real time through WebSocket-based real-time communication technology. The back-end builds an API endpoint based on the FastAPI framework, receives the input string, and records the request timestamp, such as 2023-10-15 14:23:45, for subsequent log analysis. The FastAPI endpoint forwards the input text to the AutoGen multi-agent framework, which includes a semantic parsing agent and an entity extraction agent. The semantic parsing agent calls the OpenAI model GPT-4 to analyze the sentiment and intent of the text, calculates the sentiment score of the input text (e.g., 0.75, set to a range of 0 to 1), judges it as a positive intent, and extracts the key time point "tomorrow at 3 pm" and converts it into the standard time format 2023-10-16 15:00, and infers the corresponding date of "tomorrow" based on the context. The entity extraction agent identifies the locations "Shanghai" and "Beijing" and maps them to standard geocoding: Shanghai SHA and Beijing PEK. The straight-line distance between the two locations is calculated to be approximately 1200 kilometers to verify the rationality of the itinerary. At the same time, the extraction of "staying for two nights" is converted into an accommodation duration of 48 hours, and the budget of "5000 yuan" is standardized to the value 5000.00. The AutoGen framework integrates the parsed results into structured data objects that conform to the Pydantic model. For example, the trip start point is "Shanghai", the destination is "Beijing", the departure time is "2023-10-16 15:00", the accommodation duration is "48 hours", and the budget is "5000.00". It also uses a validation algorithm to ensure data integrity, checking whether the time is a future time and whether the budget is greater than 0. If the validation passes, the initial trip data object is generated. If data is missing, such as the return time not being provided, the backend AI agent can estimate the return time as 15:00 on October 18, 2023 based on the length of stay, and associate it with business rules, including recommending budget hotels within a budget of 5,000.00 yuan, calculating the maximum cost of accommodation per night as 1,500.00 yuan, to obtain a complete logical chain, and confirm that the data is used for subsequent itinerary planning.
[0016] Specifically, in step S101, the sentiment tendency and intent of the analyzed text are determined, and the sentiment score of the input text is calculated.
[0017] Where E is the text sentiment score, with a value range of [0,1]. The closer it is to 1, the more positive the sentiment. w t Let t be the t-th word in the input text; sentiment(w t (w) represents the word w in the pre-trained emotion lexicon. t The emotional intensity value, taking values [0,1]; n is the total number of words after text segmentation; The process involves extracting the key time point '3 PM tomorrow' and converting it to the standard time format 2023-10-16 15:00, then inferring the corresponding date based on the context; and calculating the straight-line distance between the two locations to approximately 1200 kilometers to verify the trip's rationality, using the following date inference formula:
[0018] Among them, T std This is the converted standard timestamp; T now This is the current system timestamp; Δt is the time offset described in natural language. In the example, "tomorrow" corresponds to 24 hours and "3 pm" corresponds to 3:00 pm. The formula for calculating spherical distance is used to verify the rationality of the travel distance:
[0019] Where d is the straight-line distance between the two locations, in km; R is the Earth's average radius, taken as 6371 km; 1, 2 represents the latitude of the starting and ending points, in radians; λ1 and λ2 are the longitudes of the starting and ending points, in radians; In the conversion of accommodation duration, the formula for calculating accommodation duration is as follows:
[0020] Where H represents the duration of accommodation, in hours; N is the number of nights of accommodation entered by the user; If data is missing, including the return time not being provided, the backend AI agent will estimate the return time as 15:00 on October 18, 2023, based on the length of stay. Formula for calculating return time:
[0021] Among them, T return This is the estimated return time; T departure This refers to the departure time; H represents the duration of accommodation, in hours; In verifying the compliance of expenses, whether the total cost is within the budget amount:
[0022] Cost total Total cost of the trip, unit: yuan; B total Total user budget, unit: yuan.
[0023] like Figures 1-2 As shown, in step S102, the backend provides the structured data to the AutoGen intelligent agent, which combines the user's historical preferences and destination resource information obtained by the XServer2 business service to generate itinerary suggestions. The suggestions are then streamed to the frontend via Server-Sent Events to obtain an itinerary confirmation form awaiting user confirmation. After the user completes the detailed confirmation on the frontend, the backend verifies the data integrity through Pydantic, calls the XServer2 SDK to persist the final itinerary data to the MySQL database, and uses the Upyun SDK to store the attachments uploaded by the user to cloud storage, forming the solidified official itinerary data.
[0024] Furthermore, in step S102, the structured data is integrated using the AutoGen intelligent agent system, taking into account historical preferences and destination resources, to generate preliminary itinerary suggestions. Based on the generated itinerary suggestions, Server-Sent Events technology is used for streaming transmission, pushing the data to the front-end interface in real time to obtain itinerary documents that users can view; Based on the itinerary information displayed on the front-end interface, obtain the confirmation details entered by the user, organize the user feedback through the data collection module, and determine the final itinerary adjustment information; Based on the final itinerary adjustment information, the Pydantic tool is used to verify the data integrity. If data is missing during the verification process, the missing fields are filled in using the preset completion logic to obtain complete data records. For the complete data record, call the XServer2 SDK interface to persist the data content to the MySQL database and confirm that the data has been successfully written to the database; Based on the attachment content uploaded by the user, the attachment data is stored in the cloud storage service through the Upyun SDK interface, and a confirmation message of successful storage is obtained; The data persistently stored in the database and the attachment information in the cloud storage service are integrated through the data association module to obtain the final official itinerary document content.
[0025] Specifically, in step S102, after receiving the structured itinerary data, the backend uses the AutoGen agent in conjunction with the XServer2 business service to query the user's historical preference data. The system pre-detects that the user prefers mid-range hotels and tends to choose locations in city centers. Based on the destination "Guangzhou," the agent filters a list of hotels that meet the criteria from the resource database and calculates a comprehensive score for each hotel. The scoring formula is as follows: Location convenience accounts for 40%, with a score of 1.0 corresponding to being less than 5 kilometers from the city center; Price matching accounted for 30%, with prices between 800.00 and 1200.00 yuan per night scoring 1.0. User reviews account for 30%, with a score of 1.0 corresponding to a rating higher than 4.5. Hotel A, with the highest overall rating of 0.92, was ultimately selected, and preliminary itinerary suggestions were provided, including check-in time 14:00 on November 1, 2023, check-out time 12:00 on November 3, 2023, and a total cost of 2200.00 yuan. The itinerary suggestions are pushed to the front end via Server-Sent Events technology in a streaming manner. The status of the suggestions is updated every 2 seconds to ensure data real-time performance. If the network delay exceeds 5 seconds, the connection will be automatically retried. After the front end receives the complete suggestion, the back end uses the Pydantic model to verify the completeness of the data confirmed by the user. For example, it verifies whether the total cost of 2200.00 yuan is within the budget of 3000.00 yuan and whether the number of nights is 2. If the verification passes, it proceeds to the next step; otherwise, the agent adjusts the hotel selection based on the difference. The verified data is persisted to the MySQL database via the XServer2 SDK, resulting in a unique trip number GZ20231101001. The stored fields include user ID, destination "Guangzhou", and cost details. The storage space usage is calculated and is estimated to be 0.5MB, which will not affect database performance. Using the UPYUN SDK, user-uploaded trip-related attachments, including electronic tickets, are stored in cloud storage. The file size is limited to 10MB, and the upload speed is controlled at 2MB / s. A unique file identifier, UPY20231101002, is generated and associated with the trip number for data traceability, as well as subsequent queries and analysis.
[0026] Specifically, in step S102, a comprehensive score is calculated for each hotel:
[0027] Where S represents the hotel’s overall rating, which ranges from [0,1]. A higher value indicates that the hotel better meets user preferences. w1, w2, and w3 represent the weighting coefficients for location convenience, price matching, and user reviews, respectively, satisfying w1 + w2 + w3 = 1w. In this embodiment, w1 = 0.4, w2 = 0.3, and w3 = 0.3. P location For location convenience scoring, a score of 1.0 is given if the hotel is less than 5 kilometers from the city center, otherwise... Calculations, with distances in kilometers; P price The price matching score is calculated as follows: 1.0 if the hotel's nightly price falls within the user's budget range [Bmin, Bmax], otherwise... Calculation, where ; P rating The rating is calculated based on user reviews. A rating higher than 4.5 is assigned a score of 1.0; otherwise, it is assigned a lower score. calculate.
[0028] like Figures 1-2As shown, in step S103, the backend uses the Jinja2 template engine to render the contract template based on the solidified itinerary data, generates a Word version of the contract document using python-docx, and uses the Playwright browser automation tool to render the HTML template into a PDF file. After batch generating standard contract files, they are uploaded to UPYUN CDN and a downloadable access link is returned.
[0029] Furthermore, in step S103, the solidified itinerary data is matched with a preset contract template, and the template content is dynamically filled using the Jinja2 template engine to generate an initial HTML format contract document, thus obtaining structured contract text data. Based on the generated HTML format contract text data, the python-docx tool is used to convert the content into a Word format document. At the same time, the Playwright automation tool is used to render the HTML content to obtain a PDF format file output. For the obtained Word and PDF documents, the batch processing module organizes the files in a unified manner, and the file classification logic is used to archive the files of different formats to determine a standardized file set; Based on the standardized file set, the files are transferred in batches to the cloud storage service through the file upload interface. The files are then distributed and stored using Upyun CDN service, and confirmation information of successful file storage is obtained. For file data stored in the cloud, the storage path is mapped through the access link generation module to generate a unique accessible link address, thus determining the validity and reachability of the link. Based on the generated access link address, the link information is bound to the corresponding itinerary document data through the data association module, and the link and document information are persistently stored in the database record method to obtain a complete association record; For associated records in persistent storage, automated tools are used to periodically verify the record content. If the link address is found to be inaccessible, the backup link generation logic is triggered to obtain a new link address and update the record, thus determining the integrity and consistency of the record.
[0030] Specifically, in step S103, the backend starts the contract generation process based on the solidified itinerary data. It loads a preset contract template through the Jinja2 template engine. The preset template includes fields for user name, itinerary number, and total cost. Taking itinerary number BJ20231201003 as an example, the system extracts the corresponding data from the database. The corresponding data includes user name Zhang San, total cost of 3500.00 yuan, and itinerary dates from 2023-12-05 to 2023-12-08. The data is automatically filled into the template to obtain the initial contract content. The python-docx library is used to convert the filled content into a Word document. The document font is set to SimSun, the font size is 12, and the page margins are 2.54 cm to ensure that the format meets the standard. A temporary file with a file size of about 0.3 MB is generated. Using Playwright browser automation tools, a preset HTML contract template was loaded, and the page layout was adjusted with CSS styles. The page layout included setting the A4 paper size and the margin to 1.5 cm. The HTML content was then converted into a PDF file using the built-in rendering engine, with the file resolution set to 300 dpi. The resulting PDF file was approximately 1.2 MB in size. The system batch processes the generated Word and PDF files, calculates the total file size to be 1.5MB, verifies the file integrity, and then uploads the files at a rate of 1.5MB / s through the Upyun CDN upload interface. If a network interruption occurs during the upload process, the system will automatically retry up to 3 times, with an interval of 10 seconds between each retry, to ensure successful upload. After the upload is complete, a unique access link is generated. The access link is valid for 30 days and is associated with the trip number and stored in the database for subsequent business tracking and user downloads. At the same time, the system records the upload time as 15 seconds for subsequent performance optimization analysis.
[0031] Specifically, in step S103, a temporary file of approximately 0.3MB is generated, a file of approximately 1.2MB is generated, the total file size is 1.5MB, and the file is uploaded at a rate of 1.5MB / s. The upload time is calculated using the following formula:
[0032] Among them, T upload Upload time, in seconds; S file File size, in MB; Rate upload Upload speed, unit: MB / s.
[0033] like Figures 1-2As shown in step S104, the backend calls Playwright to generate visual itinerary cards, itinerary posters and other promotional images based on the itinerary data, or the frontend uses Tailwind CSS and Ant Design component library to build the layout and then the backend renders and captures it, stores the generated promotional images in Upyun and returns the address.
[0034] Furthermore, in step S104, for the core information in the itinerary document, the backend processing module extracts key fields, and the data is classified and organized using a structured parsing method to obtain a classified itinerary information set; Based on the categorized itinerary information set, the Playwright tool is used to dynamically generate the content of visual cards and promotional posters, and the information is filled with preset template styles to determine the content of the generated image materials; For the generated image materials, the styles of visual cards and promotional posters are adjusted by combining the front-end layout module with the page design logic. The rendering screenshot technology is used to capture images of the page and obtain the final image files. By performing format verification on the final image file, if the file format is found to be inconsistent with the storage service requirements, the format conversion process is triggered to complete the standardization of the file format and obtain image resources that meet the specifications. For image resources that meet the specifications, the file upload interface is called to transmit the image resources in batches to the storage service system. Distributed storage logic is used to segment and save the files, and the integrity of the uploaded files is checked. Based on the storage path after the file is uploaded, the path information is encrypted by the access address generation module to generate a unique access address record, thus determining the reachability and uniqueness of the address. For the generated access address records, the address information is bound to the corresponding itinerary document through the data association module, and the association information is saved in a persistent storage manner to obtain complete binding data.
[0035] Specifically, in step S104, during the backend process of generating promotional images based on itinerary data, the system first extracts itinerary-related information from the database, such as itinerary number SH20231115007, which includes key fields such as user nickname Li Ming, destination Hangzhou, itinerary duration of 3 days, and departure date 2023-11-20. The system analyzes the proportion of itinerary days through algorithms, calculates that the daily itinerary density is 33.33%, and automatically matches a suitable theme color based on the destination characteristics. For example, the RGB value of green corresponding to Hangzhou is (34,139,34), which is used as the background color of the poster. The Playwright tool is used to load a preset HTML promotional template. Combined with the responsive layout designed using Tailwind CSS and the card styles provided by the Ant Design component library, the image size is automatically adjusted to 1080x1920 pixels and the resolution is set to 72dpi to ensure that the output image is suitable for social media sharing. When generating itinerary cards, the system dynamically arranges the daily itinerary points according to the user's itinerary data, calculates the display height ratio of each time point to be 25%, and embeds the user's nickname and date tags to create a personalized effect. The backend uses Playwright's screenshot function to save the rendered HTML content as a PNG image, with each image being approximately 2.5MB in size. The images are then further compressed using a lossless compression algorithm, reducing the file size to 1.8MB with a compression rate of 28%, while also verifying the integrity of the images. The system uploads the generated promotional images through the UPYUN CDN interface, with the upload rate controlled at 2.0MB / s. If network fluctuations occur during the upload process, the system automatically switches to a backup node to retry, with a maximum of 2 attempts and a 5-second interval between each attempt. After a successful upload, an access link is generated, with the access link valid for 60 days. The link is then associated with the trip number and stored in the database. The upload time of 8 seconds is also recorded for subsequent system optimization and analysis.
[0036] Specifically, in step S104, the formula for calculating a daily travel density of 33.33% is as follows:
[0037] Among them, D i The travel density for day i is expressed as a percentage. N represents the total number of days in the trip, in days; The formula for calculating the compression ratio when it reaches 28% is as follows:
[0038] Where R is the image compression ratio, expressed as a percentage; S original Original image file size, in MB; S compressed The compressed image file size is expressed in MB. The formula for calculating the display height percentage at each time point, which is 25%, is as follows:
[0039] Among them, H point The percentage of height in the vertical layout at a single point in time; M represents the total number of travel points for the day; The formula for calculating the number of pixels when automatically resizing an image to 1080x1920 pixels and setting the resolution to 72 dpi is as follows:
[0040] Among them, P total This represents the total number of pixels in the image. W represents the image width in pixels; H represents the image height in pixels.
[0041] like Figures 1-2 As shown in step S105, the solidified itinerary data is synchronized to the enterprise's internal business systems such as contract management, customer relations, and financial settlement through the XServer2 SDK, forming a unified data source for enterprise-level business processes. The front end uses the React Router and OpenID Connect authentication mechanism to achieve data reuse and display under access control, supporting subsequent itinerary iteration, replication, and expansion.
[0042] Furthermore, in step S105, the XServer2 SDK is used to perform data synchronization on the itinerary documents, obtain the latest itinerary information from the source system, and determine the integrity of the synchronized data; Based on the synchronized itinerary information, a distribution mechanism is used to transmit it to business systems such as contract management, customer relations, and financial settlement, so as to obtain unified data shared among the systems. To address the application of unified data across various business systems, data mapping rules are constructed to associate itinerary documents with relevant records in contract management and to determine the accuracy of the association. If the association results meet the preset matching conditions, the data display range will be restricted through the permission control module to obtain the restricted access permission list; Based on the defined access permission list, the front-end display logic is used to adapt to data reuse scenarios and determine the user's visible itinerary information in different business systems; The function extension interface is used to dynamically update the itinerary documents for subsequent iterations and obtain the updated data content. For the updated data, a persistent storage mechanism is used to save it to the business system, and the completion status of the save operation is determined.
[0043] Specifically, in step S105, during the implementation of synchronizing the solidified itinerary data to multiple business systems within the enterprise via the XServer2 SDK, the system first packages the itinerary data in JSON format, including key fields such as itinerary number (TR20231201001), customer ID (CUST12345), and total cost (15800.50 yuan), and pushes it to the contract management system at a transmission rate of 5MB per second through the API interface of the XServer2SDK. The contract management system dynamically allocates bandwidth based on the data volume. If the data volume exceeds 10MB, it will be automatically segmented and processed, with each segment controlled to be 2MB in size. During transmission, the CRC32 check algorithm is used to ensure data integrity. If the check fails, it will automatically retransmit, with a maximum of 3 retries, each with an interval of 2 seconds. After success, a synchronization log is generated to record the time taken, such as 3.5 seconds. When data is synchronized to the customer relationship system, the system matches customers based on their customer IDs, analyzes the number of customers' historical trips (e.g., 5 trips), and calculates the customer loyalty score. The scoring formula is the number of historical trips multiplied by a weight of 0.6 plus the percentage of the most recent purchase amount of 0.4. If the score is 85.5, the customer is automatically marked as a high-value customer, and the notification module is triggered to push a reminder to the sales team. The notification delay is controlled within 1 second. Meanwhile, when the data flows into the financial settlement system, the system automatically breaks down the cost percentages based on the total cost field. The algorithm is as follows: transportation costs account for 40%, which is 6320.20 yuan; accommodation accounts for 35%, which is 5530.18 yuan; and other costs account for 25%, which is 3950.12 yuan. A settlement details table is generated, and the total amount error is checked through internal verification rules. If the error is less than 0.01 yuan, it is approved, and the data is automatically archived to the financial database. The archiving time is recorded as 2.8 seconds. The system links synchronization status with front-end access control. Through the routing configuration of React Router combined with the OpenIDConnect authentication mechanism, it automatically verifies user role permissions. Users with role levels higher than 3 can access the trip iteration function. The system analyzes the reuse rate based on user operation records, such as 62.5%, and generates extension suggestion data, which is automatically stored in the extension library.
[0044] Specifically, in step S105, the customer loyalty score calculation formula is used:
[0045] Where L is the customer loyalty score, with a value range of [0, 100]; α and β are the weights for historical frequency and recent consumption amount, respectively, satisfying α+β=1. In this embodiment, α=0.6 and β=0.4. C is the normalized value of the number of historical trips, calculated as follows: ; A represents the percentage of the most recent purchase amount, calculated as follows: If the value exceeds 100, it will be counted as 100. In the automatic cost percentage breakdown, the cost percentage calculation formula is as follows:
[0046] Among them, R category This refers to a specific expense category, including transportation, accommodation, and other expenses, as a percentage of the total cost. Cost category The amount for this expense category is in yuan. TotalCost is the total cost of the trip, in yuan. If the data size exceeds 10MB, it will be automatically fragmented, with each fragment no larger than 2MB. During transmission, a CRC32 checksum algorithm is used to ensure data integrity. If the checksum fails, automatic retransmission will occur, with a maximum of 3 retries, each with a 2-second interval. The formula for calculating the number of fragments is as follows:
[0047] Where, N part This refers to the number of fragments; S data Total size of data to be transmitted, in MB; S part This represents the upper limit of the data size per chip, in MB. To round up; The standard CRC32 algorithm is used, with a polynomial of 0x04C11DB7 and a check value of a 32-bit integer, which is used to verify the integrity of transmitted data. The total amount error is checked against internal verification rules. If the error is less than 0.01 yuan, it passes. The formula for calculating the total amount error is as follows:
[0048] Where, Δ cost The absolute error between the total cost and the sum of the itemized costs is expressed in yuan. TotalCost is the total cost of the trip, in yuan. Cost category The amounts for each expense category are in yuan.
[0049] In one embodiment, the physical meaning of the English words and abbreviations used in this invention specifically includes: The first category is technical frameworks and tools: FastAPI: A high-performance asynchronous web framework based on Python, used to quickly build API interfaces. It is the core framework for the backend to receive frontend requests and process business logic. AutoGen: A multi-agent framework used to enable multiple agents to work together to complete tasks such as semantic parsing, entity extraction, and route suggestion generation. OpenAI: Large language models are being used for semantic parsing and intent recognition processing of natural language; Pydantic: A Python library for data validation and serialization, used to define standardized data models and verify the integrity and standardization of travel data; XServer2 SDK: The Software Development Kit for XServer2 business services, which provides interfaces for calling backend services and is used for persistence of trip data and cross-business system synchronization operations; Jinja2: A Python template engine used to render contract templates and dynamically populate itinerary data to generate standardized contract text; python-docx: A Python library for processing Word documents, used to convert rendered contract content into Word format documents; Playwright: A browser automation tool that supports webpage rendering, screenshotting, and PDF generation. It is used to convert HTML templates to PDF and generate itinerary promotional images. React Router: A front-end routing management library based on the React framework, used to implement front-end page route configuration, page navigation, and page access under permission control; OpenID Connect (OIDC): An identity authentication protocol based on OAuth 2.0, used to implement unified identity authentication and user role permission verification in the system; Tailwind CSS: An atomic CSS framework used for front-end page style design and layout adjustment, adapting the front-end display of promotional images and itinerary documents; Ant Design: An enterprise-grade UI design language and component library that provides various components needed for front-end development, used to build front-end pages for itineraries, chat interfaces, etc. Server-Sent Events (SSE): Server-pushed event technology, a one-way streaming technology used by the backend to push event suggestions to the frontend in real time for dynamic interaction; WebSocket: A full-duplex network communication protocol used by the front end to transmit user natural language input to the back end in real time, ensuring the real-time nature of information collection; The second category is data storage and transmission: MySQL: A relational database management system used for persistent storage of finalized formal itinerary data and records linking itineraries to contracts or promotional materials; JSON: A lightweight data exchange format used for structured storage of trip data, front-end and back-end data interaction, and cross-system data synchronization. HTML: HyperText Markup Language, used to build front-end display templates for contract templates and promotional images, and is the basic format for template rendering; PDF: A standardized document format used to generate uniform itinerary contract documents, ensuring consistency in document presentation; PNG: Portable Web Graphics, a lossless compressed image format used to store generated itinerary cards, posters, and promotional images; CDN: Content Delivery Network, used for distributed storage of contract documents and promotional image files to improve file access speed and stability. In this application, it is UPYUN CDN. CRC32: Cyclic Redundancy Check, a data verification algorithm used to verify the integrity of cross-system synchronized data and prevent errors during data transmission; RGB: Red, Green, and Blue color model, used to define the theme color and other visual styles of promotional images. Different colors are presented by combining the values of the three color channels. In this application, Hangzhou corresponds to RGB(34,139,34). API: Application Programming Interface, used for interactive calls between different systems or frameworks, such as the interfaces built with FastAPI and the interfaces of the XServer2 SDK.
[0050] If the technical solution of this application involves the collection, processing or application of personal information, the relevant products have fully and clearly informed the individuals of the processing rules in accordance with the current laws and regulations such as the Personal Information Protection Law of the People's Republic of China before carrying out any personal information processing activities, and obtained their independent and explicit consent. If sensitive personal information is involved, the product has obtained the individual's separate consent before processing, and such consent is made in an explicit manner. For example, prominent signs are set up in the area where information collection devices such as cameras are located, clearly indicating that "entering is considered as consent to the collection of personal information". Alternatively, through pop-up windows, checkboxes, or user-initiated uploads, users can actively complete the authorization process, provided that the identity of the processor, the purpose of the processing, the processing method, and the type of information are clearly listed. The above mechanism ensures that all personal information processing activities are based on legal authorization and fully comply with national compliance requirements regarding personal information protection.
[0051] For those skilled in the art, various other corresponding changes and modifications can be made based on the technical solutions and concepts described above, and all such changes and modifications should fall within the protection scope of the claims of this application.
Claims
1. A method for streaming switching and multi-view synchronization of driven process text, characterized in that, include: S101. The front end collects the user's natural language input itinerary information, and the back end uses a multi-agent framework to call a large language model to perform semantic parsing and entity extraction on the input content, converting unstructured information into a standardized itinerary data structure to obtain the initial itinerary data object. S102. The backend combines the initial itinerary data object with the user's historical preferences and destination resource information to generate itinerary suggestions, and pushes them to the frontend through streaming transmission technology to generate itinerary documents to be confirmed. After the user completes the details confirmation, the backend performs integrity verification on the itinerary documents, persists the final itinerary data to the database, and stores the user's attachments to the cloud storage to obtain the solidified official itinerary data. S103. Based on the solidified itinerary data, the backend uses a template engine to render the contract template, generates the contract document, and combines it with browser automation tools to generate PDF files. After batch generating standard contract files, they are uploaded to cloud storage and an access link is returned. S104. The backend generates a visual promotional image based on the solidified itinerary data, stores the generated promotional image in cloud storage, and returns the address. S105. The solidified itinerary data is synchronized to multiple business systems to obtain a unified data source. The front end uses an authentication mechanism for data reuse and display under access control.
2. The method for streaming switching and multi-view synchronization of driven text according to claim 1, characterized in that, The process of converting unstructured information into a standardized travel data structure includes: performing semantic parsing on the user's natural language input, identifying key semantic units, performing entity extraction operations to extract travel-related entities, obtaining a preliminary set of travel elements, supplementing missing parts by inferring from the context, mapping to a standard data model, and then using a verification tool to detect and obtain standardized travel data.
3. The method for streaming switching and multi-view synchronization of driven text according to claim 1, characterized in that, The solidified formal itinerary data includes: combining itinerary data with user historical preferences and destination resource information, obtaining itinerary suggestions through multi-agent integration, pushing them to the front end through streaming transmission technology, obtaining user confirmation details, verifying and completing data integrity, persisting the itinerary data to the database, and storing attachments to cloud storage to obtain formal itinerary data.
4. The method for streaming switching and multi-view synchronization of driven text according to claim 1, characterized in that, Also includes: The access links to the generated contract documents are periodically verified. If a link is unreachable, a backup link is generated and the record is updated.
5. The method for streaming switching and multi-view synchronization of driven text according to claim 1, characterized in that, The process of generating contract documents includes: using a template engine to match contract templates, generating HTML format contracts, then converting the files using document conversion tools and browser automation tools, uploading them to cloud storage after unified archiving, generating accessible links, and binding them to the database with itinerary data.
6. The method for streaming switching and multi-view synchronization of driven process text according to claim 1, characterized in that, The process of generating visual promotional images includes: extracting key fields from itinerary data and categorizing them; dynamically generating visual cards and promotional posters using browser automation tools; rendering screenshots after front-end layout adjustments; uploading the images to a distributed storage system after format verification and standardization; and generating an encrypted access address based on the storage path and associating it with the itinerary data.
7. The method for streaming switching and multi-view synchronization of driven text according to claim 1, characterized in that, The synchronization to multiple business systems includes: synchronizing the latest itinerary information through a software development kit, distributing it to business systems such as contract management, customer relations, and financial settlement, constructing mapping rules for association, limiting access scope through permission control, adapting the front end to display the information visible to each system, and dynamically updating subsequent itinerary data through extended interfaces and persistently storing it in the business systems.
8. The method for streaming switching and multi-view synchronization of driven text according to claim 1, characterized in that, The multi-agent framework includes a semantic parsing agent and an entity extraction agent. The semantic parsing agent is used to analyze the sentiment and intent of the text and extract key time points, while the entity extraction agent is used to identify location information and verify the rationality of the itinerary.
9. The method for streaming switching and multi-view synchronization of driven text according to claim 1, characterized in that, The streaming technology is Server-Sent Events, which is used to push trip suggestions to the front end in real time and automatically retry the connection when the network latency exceeds a preset threshold.
10. The method for streaming switching and multi-view synchronization of driven text according to claim 1, characterized in that, The front end uses routing configuration and authentication mechanisms for data reuse and display under access control. It determines the scope of accessible trip functions based on the user's role and permission level, and generates extended suggestion data to be stored in the extension library.