A multi-agent-based college student project education simulation method and system

Abstract

The application discloses a kind of university student project education simulation method and system based on multi-agent.It includes: obtaining project creation request, creating project directory and initializing session manager and version controller, session manager maintains finite state machine, the state space of finite state machine includes three stages of system initialization, collaborative construction period and game defense period;In the collaborative construction period stage, each step is executed in turn, after completion, automatically promote state and carry out persistence, after completing review modification and auxiliary writing, enter the game defense period;In the game defense period stage, three experts parallel review and conflict detection, proposal revision based on expert opinion and final report chapter generation and cross-platform file export step are executed in turn, after proposal revision and audit pass, final report adopts the chapter independent generation strategy, and the PDF format file of Markdown and cross-platform adaptation is output.

Description

Technical Field

[0001] This invention relates to the fields of computer technology and educational informatization, and more specifically to a multi-agent-based project-based education simulation method and system for university students. Background Technology

[0002] Currently, with the popularization of innovation and entrepreneurship training, undergraduate scientific research training and competition projects in universities, project-based education has become an important organizational form for cultivating students' engineering practice and scientific research writing abilities.

[0003] However, existing technical solutions for project-based learning (PBL) and competition project management for university students mostly rely on general project management platforms, online document editors, learning resource platforms, or single "intelligent writing / question-answering" tools. These solutions still have significant technical shortcomings in terms of engineering implementation and a complete, feasible closed-loop process. Firstly, existing systems generally fragment the processes of "project naming, team building, solution development, research roadmap and task scheduling, material collection, manuscript writing, review and revision, and final output" into independent tools or manual processes. The lack of a unified process state machine and a structured management mechanism for stage deliverables leads to repeated data entry on both the client and server sides, unstable reuse of stage documents, and difficulty in automating and tracing the process, thus affecting overall operational efficiency and reliability.

[0004] Secondly, existing technologies typically lack computational mechanisms for multi-role / interdisciplinary collaboration: on the one hand, role division relies heavily on human experience, making it difficult to dynamically match expert capability models and generate complementary solutions in parallel based on project themes and user input; on the other hand, the review process often adopts a single evaluation perspective or human comments, lacking calculable quality gates (such as thresholding scores for key text outputs and generating problem lists), making it difficult to prevent low-quality inputs from wasting subsequent computational resources in the early stages, and also making it difficult to form executable modification paths and iterative constraints, thus causing repeated rework, direction drift, and quality fluctuations.

[0005] Secondly, existing systems lack sufficient support for "chain of evidence and consistency." Most solutions fail to incorporate the retrieval, verification, structured accumulation, and citation generation of academic literature / policy evidence into a unified data model and document system, resulting in scattered citation sources, poor traceability, and difficulty in automatically binding them to the main text sections. Furthermore, the lack of parallel review and conflict detection mechanisms for heterogeneous constraints such as cost / supply chain, technical security, and compliance ethics makes it impossible to perform structured alignment, conflict identification, and version recording of multi-source review opinions on the server side. Ultimately, this makes it difficult for generated proposals or reports to consistently meet standards in terms of feasibility, completeness, and risk coverage.

[0006] Therefore, how to solve the problem of how to form an implementable closed loop of "end-side interaction - cloud computing - documented output - version iteration - multi-perspective review - final draft export" on networked computing devices in the existing technology, and how to simultaneously meet the technical requirements of process controllability, evidence traceability, quality gatekeeping and consistency of multiple constraints are problems that urgently need to be solved by those skilled in the art. Summary of the Invention

[0007] In view of the above problems, the present invention is proposed to provide a multi-agent-based project-based education simulation method and system for college students that overcomes or at least partially solves the above problems.

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

[0009] In a first aspect, embodiments of the present invention provide a multi-agent-based project-based education simulation method for university students, comprising the following steps: S1. Obtain the project creation request, create the project directory and initialize the session manager and version controller. The session manager maintains a finite state machine. The state space of the finite state machine includes three stages: system initialization, collaborative construction period and game-theoretic defense period. S2. During the collaborative construction phase, the following steps are executed in sequence: project naming, team leader information collection, dynamic generation of AI virtual teammates, division of labor and quality gate control, research route and task planning, proposal summarization, and review, modification and writing assistance. After each step is completed, the status is automatically advanced and persisted. After the review, modification and writing assistance are completed, the game defense phase begins. S3. During the game defense period, the following steps are executed in sequence: three-expert serial review and conflict detection, proposal revision based on expert opinions, and final report generation by chapter and cross-platform file export. After the proposal is revised and approved, the final report is generated by the document coordination agent in one go based on the expert review history and version evolution record, and Markdown and cross-platform adapted PDF format files are output at the same time.

[0010] Furthermore, in step S1, after the initialization is completed, the server persists the project metadata, session state, and version control information to the project directory in JSON format. The client realizes the synchronous linkage between the front-end interaction and the back-end state based on the current stage identifier of the state machine.

[0011] Furthermore, in step S1, the project directory is a unique directory with a timestamp as its unique identifier, and the state space of the finite state machine is further subdivided into: topic selection, team division of labor, knowledge planning, task planning, document integration, expert review, and completion sub-states, and the state switching is automatically executed by the server-side program.

[0012] Furthermore, the project naming step in S2 is as follows: the user submits a preliminary project name and core description, the server activates a naming consultant agent to generate candidate names, the final name is confirmed after multiple rounds of human-machine negotiation and optimization, and the status is automatically advanced and persisted after completion.

[0013] Furthermore, the AI ​​virtual teammate dynamic generation step in S2 is as follows: the server generates two interdisciplinary virtual teammates based on project information and instantiates a general dynamic teammate intelligent agent; if the model output parsing fails, a keyword fallback mechanism is triggered to match professional directions.

[0014] Furthermore, the division of labor and quality gate control steps in S2 include: structured scoring of user technical solutions, generation and review of virtual teammate solutions, asynchronous prefetching of academic literature and policy evidence, and blocking the process and returning optimization suggestions if the preset quality threshold is not met.

[0015] Furthermore, the research route and task planning steps in S2 are as follows: the server activates multi-agents to generate a research outline, task scheduling tree, and coverage analysis report; and the retrieved evidence is deduplicated by DOI, verified by authoritative domain names, and then stored in a structured manner.

[0016] Furthermore, the proposal aggregation step in S2 specifically involves: the server integrating the solution to generate a structured material package, injecting authoritative evidence and generating a writing scaffold, and simultaneously creating a version control initial version for the scaffold.

[0017] Furthermore, in the review, modification, and auxiliary writing steps in S2, the server provides four auxiliary functions: polishing, expansion, checking, and idea generation. These functions are executed in a lightweight calling mode. After editing, the initial proposal is persisted and enters the game defense period.

[0018] Secondly, embodiments of the present invention provide a multi-agent-based project-based education simulation system for university students, comprising: The client is used to collect project information input by the user and display the project process status; The server-side component implements the following modules: A multi-agent collaboration engine, which is used for the unified management, scheduling and large language model invocation of all agents; Finite state machine and stage-driven module are used to ensure that the project process proceeds automatically in a predetermined order and supports breakpoint resume; The quality gate control module is used to automatically score intermediate products at key nodes, and low-quality inputs are not allowed to pass through. The dynamic interdisciplinary teammate matching and parallel solution generation module is used to automatically generate interdisciplinary virtual teammates based on the project theme, and each virtual teammate independently generates a specialized solution from their own perspective, forming a multi-perspective complementary solution. The evidence retrieval and verification integration module is used to retrieve, verify, and consolidate academic literature and policy evidence, and integrate them into the writing process; The version control and audit history module is used to record all document versions and audit history, providing a complete evolution trajectory; The multi-expert parallel review and conflict detection module is used to review proposals sequentially from three heterogeneous dimensions: cost, technology, and compliance, and automatically identify conflicting requirements. The module for generating chapter-by-chapter final drafts and exporting files across platforms is used to integrate the revised proposals with expert review records and version evolution history, generate a standardized final report through a large language model, and support cross-platform export. The project persistent storage module is used to uniformly manage the file storage and read / write operations of all projects.

[0019] As can be seen from the above technical solution, compared with the prior art, the present invention discloses a multi-agent-based project-based education simulation method and system for college students, which has the following beneficial effects: 1. This invention achieves a complete nine-step closed-loop process from project creation to final output, driven entirely by a server-side finite state machine. Each step automatically proceeds to the next, supporting breakpoint resumption and historical recovery. Compared to existing methods that use separate tools for each stage, this invention provides structured management of status, data, and files within a unified project directory, eliminating repetitive manual operations and data migration costs across different systems.

[0020] 2. This invention integrates academic literature retrieval (via the Semantic Scholar API), DOI cross-validation (via the Crossref validator), policy evidence retrieval (via authoritative sources limited by domain whitelists), structured storage (JSON-versioned literature pools and policy repositories), and writing citations (automatic injection of material packages and scaffolding) into a unified evidence pipeline. Compared to the fragmented approach of manually collecting citations, this invention ensures the verifiability and traceability of each citation and automatically reuses verified evidence repositories between steps, avoiding duplicate searches. The asynchronous prefetching mechanism of the background daemon thread further reduces user waiting time. Attached Figure Description

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

[0022] Figure 1 This is a flowchart of the project-based education simulation method provided in this embodiment of the invention; Figure 2 This is a structural diagram of the project-based education simulation system provided in this embodiment of the invention. Detailed Implementation

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

[0024] This invention discloses a multi-agent-based project-based education simulation method for university students, such as... Figure 1 As shown, the specific steps include: S1. Obtain the project creation request, create the project directory and initialize the session manager and version controller. The session manager maintains a finite state machine. The state space of the finite state machine includes three stages: system initialization, collaborative construction period and game-theoretic defense period. S2. During the collaborative construction phase, the following steps are executed in sequence: project naming, team leader information collection, dynamic generation of AI virtual teammates, division of labor and quality gate control, research route and task planning, proposal summarization, and review, modification and writing assistance. After each step is completed, the status is automatically advanced and persisted. After the review, modification and writing assistance are completed, the game defense phase begins. S3. During the game defense period, the following steps are executed in sequence: parallel review and conflict detection by three experts, revision of proposals based on expert opinions, and generation of the final report by chapters and export of cross-platform files. After the proposal is revised and approved, the final report adopts a strategy of generating independent chapters and outputs Markdown and cross-platform compatible PDF files.

[0025] This invention achieves a complete nine-step closed-loop process from project creation to final output, driven entirely by a server-side finite state machine. Each step automatically proceeds to the next, supporting breakpoint resumption and historical recovery. Compared to existing methods that use separate tools for each stage, this invention provides structured management of status, data, and files within a unified project directory, eliminating repetitive manual operations and data migration costs across different systems.

[0026] The following is a detailed description of each of the above steps: In step S1, the project directory is created and initialized; Users send a project creation request to the server via a browser terminal (HTTP POST / api / v1 / projects). The server-side ProjectManager creates a timestamp-identified project directory in local persistent storage, such as proj_20260305_143022, and initializes the SessionManager and VersionControl. The SessionManager maintains a finite state machine whose state space includes enumeration values ​​such as: Initialization (INIT), Topic Selection (PHASE1_TOPIC), Team Assignment (PHASE1_TEAM), Knowledge Planning (PHASE1_KNOWLEDGE), Task Planning (PHASE1_TASK), Document Integration (PHASE1_DOCUMENT), Expert Review (PHASE2_REVIEW), and Completion (COMPLETED). After each step is completed, the server automatically advances the state and persists it to metadata files (metadata.json, session.json, version_control.json) in the project directory. Based on the current phase identifier (current_phase) and step number (current_step) returned by the server, the client drives the synchronous rendering of the sidebar and main content area in the front-end workbench (WorkbenchPage) through the phase-step mapping table (PHASE_TO_STEP_KEY), realizing the three-layer linkage of "front-end interaction - back-end state machine - file system".

[0027] In step S2, the collaborative construction period; During the collaborative build phase, specific configurations are performed via the server, completing the following steps: Step 1: Project Naming (Multi-turn Dialogue Optimization). The user submits initial name ideas and a core project description through the browser's input component. The front-end encapsulates the data into a JSON request body and sends it to the server-side naming interface ( / flow / naming / start). The server-side delays the initialization of the naming advisor agent (NamingAdvisor), which inherits from the unified base class (BaseAgent) and internally encapsulates the system role suggestion word (NAMING_ADVISOR_SYSTEM) and the optimized suggestion word template (NAMING_ADVISOR_OPTIMIZE). Core keyword template details The following are the actual prompt words defined in the code, arranged in the order of their invocation: ① Naming Advisor System Role Prompt (NAMING_ADVISOR_SYSTEM) You are an advisor with extensive experience in naming innovation and entrepreneurship projects. Your responsibilities are: 1. Analyze the naming patterns by referencing the names of 120 outstanding real-world innovation and entrepreneurship projects. 2. Recommend 3-5 candidate project names based on user descriptions. 3. The name should be concise and powerful (8-16 characters), reflecting innovation and professionalism. 4. Supports multi-turn dialogues until the user is satisfied. ② Name suggestion template (NAMING_ADVISOR_OPTIMIZE) Refer to the following naming examples and tips: [NAMING_REFERENCE] (Naming reference corpus, excerpt of the first 30 examples + naming tips) Please optimize the project name based on the following information: Initial version title: [INITIAL_NAME] Project Description: [PROJECT_DESCRIPTION] Please provide 3-5 candidate names, with an explanation for each name: 1. Naming logic (Why choose it this way?) 2. Applicable Scenarios (Suitable for which tracks / judges' preferences) 3. Suggestions for improvement (how can it be further adjusted?) ③ Quality gate scoring prompt (QUALITY_GATE_SCORE_PROMPT) You are the "Innovation and Entrepreneurship Project Quality Reviewer". Your role is to review and score the output of the [STAGE_NAME] stage.

[0028] Scoring dimensions: completeness / feasibility / risk control / verifiability / resource fit / clarity (0-5 points each) If the overall score is ≥80, it is recommended to proceed to the next step; if the score does not meet the standard, a list of issues and suggestions for improvement will be provided.

[0029] Output pure JSON, including: overall_score, dimension_scores, top_issues, missing_evidence, and highlights.

[0030] ④ Cost / Supply Chain Expert System Prompt (COST_EXPERT_SYSTEM) You are a professional and impartial cost and supply chain expert, reviewing undergraduate innovation and entrepreneurship projects.

[0031] Passing criteria: Basic budget classification, key material list, identification of major supply chain risks, and total budget ≤ 20,000 yuan.

[0032] Rejection criteria (rejection only for the following serious issues): complete lack of budget information, order-of-magnitude cost errors, complete lack of supply considerations for critical materials, and severe budget overruns without explanation.

[0033] During the review, first affirm the strengths, then point out the weaknesses; the output JSON includes approved, budget_analysis, bom_analysis, and supply_chain_risks.

[0034] ⑤ Conflict detection hint (CONFLICT_DETECTOR_PROMPT) Comparing the opinions of the three experts, only the actual contradictions are reported (one requested the addition of a certain function, while the other requested its reduction to control costs, etc.).

[0035] If experts have different focuses but their directions are not contradictory, then it is not considered a conflict; conflicts must not be fabricated.

[0036] Output JSON: conflicts_detected(bool), conflicts list (including expert1 / expert2 / conflict_type / severity), resolution_suggestions, overall_recommendation.

[0037] ⑥ Document Coordination and Writing Scaffolding Tips (DOCUMENT_COORDINATOR_SYSTEM) You are the scaffolder for writing the innovation project.

[0038] Core principle: Outputting continuous, complete narrative text (paragraphs with more than 3 sentences) is prohibited; only headings, bullet points, table templates, placeholders, and citations are allowed.

[0039] Output types include: structural skeleton, fill-in prompts [fill in: xxx], key points bullet (2-3 ideas), table template (empty structure + column headers), and data placeholders [data: xx indicator, source: xxx].

[0040] Students organize their knowledge and write the main text themselves, with the AI ​​acting as a "scaffolding" rather than a "ghostwriter," and loading a pre-built naming reference corpus. The base class calls the large language model via APIModel: when calling the large language model, the core parameters are set as follows: the model uses GPT-4o (gpt-4o), the generation temperature is set to 0.7 to balance creativity and consistency, the maximum generation length (max_tokens) is 4096, and the interface call is automatically retried up to 5 times if it fails. For policy retrieval scenarios that require low randomness, the temperature is reduced to 0.3 to improve citation accuracy. A three-part suggestion structure of "system role + dialogue history (last 10 rounds of sliding window) + current question" is constructed to obtain multiple candidate name suggestions returned by the model. After the suggested text is sent back to the browser terminal via HTTP response, it is presented in the form of clickable tags. Users can directly select, edit, or submit text feedback to trigger a new round of optimization ( / flow / naming / feedback), forming a closed loop of "human-machine multi-round negotiation". After the user confirms the final name ( / flow / naming / confirm), the server writes the project name into the ProjectInfo data structure of the session manager and advances the step counter to the next step.

[0041] Step 2: Team Leader Information Collection. A structured form is displayed in the browser terminal, collecting the user's name, professional background, and weekly available time. The front-end submits the data to the ` / flow / user-info` interface. The server writes the user information into a `TeamMember` data object and registers it in the session manager's team member list, while also persisting it to project storage, providing input parameters for subsequent agent role matching and task scheduling.

[0042] Step 3: Dynamic Generation of AI Virtual Teammates. The front-end triggers a teammate generation request ( / flow / teammates / generate), activating the server-side teammate generator agent (TeammateGenerator). This agent reads the confirmed project name, description, and user information, and uses a dedicated prompt word template (TEAMMATE_GENERATOR_CREATE) to initiate an inference request to the large language model, requesting the model to output information about two interdisciplinary virtual teammates (including their professional fields, skill lists, personality traits, and job descriptions) in structured JSON format. The server parses the returned JSON data. If the model output parsing fails, a fallback mechanism based on keyword matching (_fallback_teammates) is triggered, selecting the two most relevant professional directions from a preset field-skill mapping table based on the field keywords in the project name. The information of the two virtual teammates is then used to instantiate a general dynamic teammate agent (DynamicTeammate). The system prompt words for each instance are injected with the teammate's professional, skill, personality, and role information through a template variable replacement mechanism, allowing the same agent class to adapt to any field. Teammate information is synchronously registered to the session manager and persisted.

[0043] Step 4: Division of Labor and Quality Control. This step consists of three sub-steps: (4a) User Technical Solution Submission and Review. Users fill in their technical solutions in the text editing area of ​​their browser and submit them to the / flow / work / tech-plan interface. The server-side DocumentCoordinator populates the project name, description, and user technical solution into the technical solution scoring prompt template (TECH_PLAN_SCORE_PROMPT) and sends a scoring request to the large language model. The model returns structured JSON data containing the overall score (overall_score), scores for each dimension (technical depth / innovation / feasibility / completeness / clarity), a list of highlights, a list of issues, and missing parts. The server obtains the values ​​through JSON parsing and the safe score extraction function (safe_get_score). If the overall score is lower than the preset threshold (default 80 points), the system simultaneously generates technical advisor feedback (using the TECH_DISCUSSION_OPTIMIZE template) and returns the scoring results, the list of issues, and optimization suggestions to the browser. Users can supplement the content and resubmit ( / flow / work / tech-plan / supplement), triggering the add-re-evaluation process. This quality gate mechanism blocks low-quality inputs early in the computation process, preventing the waste of subsequent computational resources.

[0044] (4b) Parallel generation and review of virtual teammate solutions. After the user's technical solution passes the gate, the front-end request triggers two DynamicTeammate agents to generate professional solutions in their respective fields in turn. Each teammate agent receives the project name, description, user's technical solution, and the existing solution of another teammate as context input, and generates solution text through its exclusive prompt word template (DYNAMIC_TEAMMATE_WORK). The server saves the solution text as separate files, such as material_plan.md and design_plan.md, and calls the review function (_review_teammate_plan) for each solution. The review dimensions include alignment with the user's solution, completeness, feasibility, and quality, and a threshold-based scoring method is also used. If the score does not meet the standard, the system supports up to three rounds of automatic iterative modification. In each iteration, the review feedback from the previous round is injected into the teammate agent's next generation request.

[0045] (4c) Teammate work confirmation. After all solutions have passed review or reached the maximum number of iterations, the front end requests the confirmation interface ( / flow / work / teammate-work / confirm), the server advances the step counter and simultaneously starts the literature and policy evidence prefetching task (_prefetch_evidence) in the background thread to perform time-consuming network search operations in advance in an asynchronous manner.

[0046] Step 5: Research route and task planning. This step involves sequentially invoking three functional agents on the server side: (5a) The KnowledgeMentor receives the project topic, team member skill matrix and role division information, and uses a dedicated prompt word template (KNOWLEDGE_MENTOR_PLAN) to generate a structured research outline (research_outline). The outline is divided into chapters according to the project document framework. Each chapter is marked with key issues, required evidence types and argumentation paths. The output is in JSON format and persisted to research_outline.json.

[0047] (5b) The ProjectManager agent generates a task scheduling tree based on the research outline, which includes milestones, task breakdown, responsibility assignment, duration estimation and deliverable definition.

[0048] (5c) The Agile Coach agent performs coverage analysis on the existing materials (user technical solutions, teammate solutions) and research outline, calculates the completion rate of each chapter, and identifies high-priority gaps.

[0049] The above three results are cached and then merged to generate a planning review document (planning_review.md), which users can view and edit in their browser. The system then performs evidence retrieval: the academic literature retrieval module performs keyword searches via the SemanticScholar API (SemanticScholarClient.search_papers / search_by_keywords), deduplicates the returned papers by DOI, and then uses the CrossrefVerifier to cross-validate the validity of the DOI and the integrity of the metadata. Finally, the validated documents are stored in a structured JSON format in the literature pool file (literature_pool.json); the policy evidence retrieval module obtains policy documents through a network search method using a limited domain whitelist (gov.cn and the official websites of major ministries), and stores them in a structured manner in the same way. After a user finishes editing a planning review document, a quality gate review ( / flow / planning / quality-gate) can be triggered. The system uses dedicated scoring prompts (QUALITY_GATE_SCORE_PROMPT) to score the document content from multiple dimensions and updates the coverage analysis simultaneously. If the score is below the threshold, a list of issues is returned for the user to modify. The review can be iterated up to three times.

[0050] Step 6: Summarize Proposals (Generate Writing Scaffold and Material Package). The front-end triggers the summarization interface ( / flow / integration / generate), and the server-side DocumentCoordinator executes two generation tasks: First, using the work integration prompt template (WORK_INTEGRATION_PROMPT), it integrates the user's technical solution and the solutions of the two teammates into a structured material package (materials_pack.json), which synchronously injects a verified list of academic literature citations and policy evidence entries; Second, using the document drafting prompt template (DOCUMENT_COORDINATOR_DRAFT), it combines the research outline, task schedule, and team information to generate a writing scaffold (writing_scaffold_v1.0.md), which contains placeholders for each chapter, argument slots, and evidence citation tags. After the scaffold is generated, an initial version (v1.0) under version control is created, and its content and change notes are written to the version history.

[0051] Step 7: Review and Revision & Assisted Writing. Users edit the writing scaffolding in their browser. The system provides four assisted writing functions ( / assist / writing): "polish," "expand," "check," and "hints." Each function corresponds to different hint words, executed by the document coordination agent in a lightweight call mode (simple_chat) without system role hint words. After the user completes editing, the review completion interface ( / flow / review / complete) is triggered. The server reads the scaffolding content filled in by the user, persists it as proposal_v1.0.md, and advances the session state to the second stage.

[0052] In step S3, the defense game period; During the defense and negotiation phase, specific configurations are performed via the server, completing the following steps: Step 8: Parallel Review and Conflict Detection by Three Experts. The front-end triggers the expert review interface ( / flow / expert-review), and the server sequentially activates the cost / supply chain expert agent (CostExpert), the technology security expert agent (TechSecurityExpert), and the compliance and ethics expert agent (ComplianceExpert). All three expert agents inherit from the review base class (ReviewAgent), each possessing its own exclusive system role prompts, such as COST_EXPERT_SYSTEM, review prompt templates, such as COST_EXPERT_REVIEW, and a preset rejection criteria list (rejection_criteria). Each expert receives the full text of the current version of the proposal, initiates a review request to the large language model, and obtains a structured JSON result containing the review conclusion (approved / rejected), overall evaluation, list of concerns, list of modification requirements, and explanation of advantages. The three review results are then fed into the ConflictDetector, which uses a conflict detection prompt template (CONFLICT_DETECTOR_PROMPT) to format the three review comments before submitting them to a large language model for cross-comparison. This model identifies conflicting requirements among experts regarding cost versus security, security versus compliance, and outputs a conflict description, severity, involved parties, and suggested solutions. All review records (ExpertReview) and conflict records (ConflictRecord) are written to the current version's review history in the version controller, achieving complete review documentation.

[0053] Step 9: Proposal Revision Based on Expert Opinions. If any experts fail to approve the proposal, users can view the structured list of modification requirements and edit the proposal in their browser terminal, or trigger the automatic revision interface ( / flow / revise). The server-side document coordination agent summarizes all the evaluations and modification requirements from the experts who failed to approve the proposal to form feedback input. Combined with the user's supplementary explanations, it calls the proposal refinement method (refine_proposal) to generate the revised proposal text. The version controller creates a new version for the revised content, such as v2.0, and records the change description along with the review history. The revised proposal can trigger the expert review in Step 8 again, forming an iterative closed loop of "review—revision—re-review" until all three experts approve it.

[0054] Step 10: Final Report Generation and Export. After all reviews are approved, the front-end triggers the final report generation interface ( / flow / final-report). The server-side adopts a chapter-based generation strategy: First, the full text of the revised proposal is split into chapter texts according to regular expression rules (_split_proposal_into_chapters). Then, the following steps are executed sequentially: summary generation (FINAL_REPORT_ABSTRACT_PROMPT), chapter-by-chapter text generation (FINAL_REPORT_CHAPTER_PROMPT, 9 chapters in total, each chapter independently calls the large language model to ensure sufficient token space for a single inference), reference chapter generation (FINAL_REPORT_REFERENCES_PROMPT), and Appendix A (Engineering Feasibility Assessment Report, FINAL_REPORT_APPENDIX_PROMPT, injecting version evolution history and expert review records). The generated results of each part are concatenated on the server side and saved as final_report.md. The system then attempts to invoke the file conversion toolchain (pandoc + xelatex). First, it automatically detects available Chinese and English fonts on the operating system (_detect_pdf_fonts, supporting Windows / macOS / Linux platforms). It then performs LaTeX macro replacement preprocessing on Unicode special characters in the Markdown text (_normalize_markdown_for_pdf). Next, it generates a PDF file by combining a custom LaTeX header file with a Lua filter via the pandoc command line. Finally, the final review report files in Markdown and PDF formats are returned to the browser terminal as a downloadable URL for user archiving. The session state progresses to COMPLETED, and the entire process loop is complete.

[0055] Version control is implemented across all document production steps. Each production or modification creates a version snapshot (ProposalVersion), recording the version number, content summary, change description, and review history. It also supports backtracking and querying version evolution summaries (get_evolution_summary). The ProjectStore layer centrally manages JSON configuration files, Markdown documents, document pools, and resource packages within the project directory. This ensures that intermediate and final deliverables from each step are persistently stored as tangible files on the server's storage medium and can be read, saved, and downloaded via the file operation interface ( / files / {filename}). The entire system's agent scheduling, state progression, quality scoring, and file access are all executed automatically in a programmed manner on the server-side processor, forming a complete hardware and software collaborative solution with client interaction devices and server storage devices.

[0056] Based on the same inventive concept, embodiments of the present invention also provide a multi-agent-based project-based education simulation system for university students, such as... Figure 2 As shown, it includes: The client is used to collect project information input by the user and display the project process status; The server-side component implements the following modules: A multi-agent collaboration engine, which is used for the unified management, scheduling and large language model invocation of all agents; Finite state machine and stage-driven module are used to ensure that the project process proceeds automatically in a predetermined order and supports breakpoint resume; The quality gate control module is used to automatically score intermediate products at key nodes, and low-quality inputs are not allowed to pass through. The dynamic interdisciplinary teammate matching and parallel solution generation module is used to automatically generate interdisciplinary virtual teammates based on the project theme and generate multi-perspective complementary solutions. The evidence retrieval and verification integration module is used to retrieve, verify, and consolidate academic literature and policy evidence, and integrate them into the writing process; The version control and audit history module is used to record all document versions and audit history, providing a complete evolution trajectory; The multi-expert parallel review and conflict detection module is used to review proposals in parallel from three heterogeneous dimensions: cost, technology, and compliance, and automatically identify conflicting requirements. The module for generating chapter-by-chapter final drafts and exporting cross-platform files is used to convert revised proposals into standardized final reports and supports cross-platform export. The project persistent storage module is used to uniformly manage the file storage and read / write operations of all projects.

[0057] This invention integrates academic literature retrieval (via the Semantic Scholar API), DOI cross-validation (via the Crossref validator), policy evidence retrieval (via authoritative sources limited by domain whitelists), structured storage (JSON-versioned literature pools and policy repositories), and writing citations (automatically injecting material packages and scaffolding) into a unified evidence pipeline. Compared to the fragmented approach of manually collecting citations, this invention ensures the verifiability and traceability of each citation and automatically reuses verified evidence repositories between steps, avoiding redundant searches. The asynchronous prefetching mechanism of the background daemon thread further reduces user waiting time.

[0058] The system described in this invention adopts a layered architecture of "browser client + server-side computing platform". The browser client is implemented based on the React component framework, and the server is implemented based on the Python FastAPI asynchronous framework. The two communicate with each other via a network interface through the HTTP / JSON protocol.

[0059] The client-side layer (front-end) is deployed in the user's browser and maintains six page paths through the BrowserRouter: Home ( / ), Dashboard ( / dashboard), Project List ( / projects), Project Creation ( / projects / create), Collaboration Workbench ( / workbench / :projectId), and Defense Page ( / defense / :projectId). The Collaboration Workbench is the core interaction platform. Internally, it uses a phased sidebar component (WorkbenchSidebar) to present the progress status of two main phases and nine steps. The main content area carries the independent interactive components corresponding to each step (Step1Naming, Step2LeaderInfo, Step3Teammates, Step4TaskAllocation, Step5Planning, Step6ProposalDraft, Step7FinalReview, Step2Step1ExpertReview, Step2Step2Revision). The discussion panel component (WorkbenchChat) displays real-time human-computer dialogue records and agent responses. The client maintains a "phase-step mapping table" (PHASE_TO_STEP_KEY), mapping the current phase enumeration values ​​returned by the server, such as phase1_naming and phase2_expert_review, to the corresponding step highlights and completion status markers in the sidebar, achieving front-end and back-end state synchronization. All data interactions with the server are completed through a unified encapsulated HTTP request adaptation layer (callFlow). This adaptation layer maps the combination parameters of "phase number + step number + flow number + selection item + user input" to the corresponding RESTful endpoint path and request body, and converts the server response into a unified {step, stage, flow, resultStr} format and returns it to each component for rendering.

[0060] The server layer (backend) uses the FastAPI application as the entry point and registers four sets of routing modules: project management route ( / api / v1 / projects), workflow route ( / api / v1 / projects / {project_id} / flow), accessibility route ( / api / v1 / projects / {project_id} / assist), and file operation route ( / api / v1 / projects / {project_id} / files). A globally configured CORS middleware supports cross-origin requests. Each project is managed by an independent ProjectService instance, retrieved via dependency injection (get_project) in the route handling function.

[0061] II. Multi-agent cooperation engine The system defines a unified base class for intelligent agents (BaseAgent), which is inherited by all functional and auditing intelligent agents. The base class encapsulates the following core mechanisms: (1) Unified Large Language Model Call Interface. The base class holds an APIModel instance, which initiates an HTTP request to the external large language model service through the OpenAI compatible protocol based on the model name in the configuration file, such as gpt-4o, API key, and API address. APIModel supports adaptation to multiple model backends: calling DeepSeek series models using the OpenAISDK client method; calling other OpenAI compatible models using the standard HTTP POST method. Automatic retry is performed up to 10 times when the call fails.

[0062] (2) Three-part prompt construction method (_build_prompt). The input of each inference request is assembled into a concatenated text consisting of three parts: "system role prompt + dialogue history (sliding window, retaining the most recent 10 rounds) + current question", to ensure that the agent maintains contextual coherence in multi-round interactions.

[0063] (3) Prompt template filling method (generate_prompt). It accepts a template string and a parameter dictionary, and generates the final prompt through a placeholder replacement mechanism (replacing [KEY] in the template with the value corresponding to KEY in the parameter dictionary). The system predefines more than 40 dedicated prompt template constants, covering all aspects such as naming optimization, teammate generation, dynamic teammate proposal writing, research route planning, task scheduling, coverage analysis, writing scaffolding, material package integration, technical solution review, quality gate review, three-expert review, conflict detection, final report chapter generation, literature keyword extraction, literature review generation, and auxiliary writing (polishing / expansion / checking / ideas).

[0064] (4) Lightweight call mode (simple_chat). Bypassing the system role prompts and dialogue history, it directly sends plain text requests to the large language model for computational tasks that do not require role-playing context, such as review scoring and coverage analysis, thus avoiding the interference of role prompts on the objectivity of scoring.

[0065] (5) Review Agent subclass. Based on the base class, add personality traits, rejection criteria list and review history container to provide a unified review interface paradigm for the three expert agents in the second stage.

[0066] In the first phase, the system deployed the following agents: NamingAdvisor, TeammateGenerator, DynamicTeammate (which can be instantiated in any domain), KnowledgeMentor, ProjectManager, AgileCoach, and DocumentCoordinator. In the second phase, the system deployed: CostExpert, TechSecurityExpert, ComplianceExpert, and ConflictDetector. All agents were deferred initialization (_init_agents) upon first use in the project to avoid unused agents consuming memory.

[0067] III. Finite State Machines and Stage-Driven Mechanisms The system defines a session phase enumeration class (SessionPhase), containing eight states: INIT → PHASE1_TOPIC → PHASE1_TEAM → PHASE1_KNOWLEDGE → PHASE1_TASK → PHASE1_DOCUMENT → PHASE2_REVIEW → COMPLETED. The SessionManager holds the current phase, current step number (current_step, integer 0~7+), a list of messages, and a project information data structure (ProjectInfo). Each step's service method, after executing its logic, calls set_step() and set_phase() to advance the state, and then calls save() to serialize the session data, version control data, and metadata into session.json, versions.json, and metadata.json respectively, writing them to the project directory. When the client enters the workbench page, it reads the project details through the / projects / {id} interface, parses the current_phase field, and restores the sidebar progress and main content area components through a mapping table, enabling breakpoint resume.

[0068] IV. Quality Gate Control Mechanism The system sets threshold-based quality gates in three stages: technical solution submission (step 4), teammate solution review (step 4), and research plan review (step 5). Taking the technical solution review as an example, its technical implementation is as follows: The document coordination agent fills the project name, description, and user technical solution into the technical solution scoring prompt template (TECH_PLAN_SCORE_PROMPT). This template instructs the large language model to return the review results in structured JSON format, including the overall score (0-100 points), scores for five dimensions (technical depth, innovativeness, feasibility, completeness, and clarity, each 0.5 points), a list of highlights, a list of issues (top_issues, each item including an issue description, reason, and suggested fix), and a list of missing parts (missing_parts). The server uses the JSON parsing function (extract_json_object) to locate and extract the first complete JSON object from the free text returned by the model, and then uses the safe score extraction function (safe_get_score) to obtain the numerical score. If the total score is below the 80-point threshold, the system will return the review results and improvement suggestions to the client. The user can then supplement the content and resubmit, triggering the "addition + re-evaluation" process. The Quality Gate Review (QUALITY_GATE_SCORE_PROMPT) also applies in step 5, and simultaneously performs coverage analysis (CONTENT_COVERAGE_ANALYSIS_PROMPT) to calculate the completion percentage of each section, identify high-priority gaps, and update the analysis results to the cache file (_planning_outline_cache.json). The Teammate Solution Review (TEAMMATE_PLAN_REVIEW_PROMPT) adds an "alignment" dimension with the user's technical solution and "collaboration issue" detection, supporting up to three rounds of automatic iterative modifications.

[0069] V. Dynamic Interdisciplinary Teammate Matching and Parallel Solution Generation Mechanism After receiving the project name, description, and user information, the virtual teammate generator agent sends a structured generation request (TEAMMATE_GENERATOR_CREATE) to the large language model, requesting the model to analyze the core domains involved in the project and output JSON descriptions of two interdisciplinary teammates (including their majors, skills, personalities, roles, and responsibilities). The returned results are parsed using a JSON deep matching extraction algorithm (locating the outermost curly braces in the text and extracting the complete JSON object by nesting depth). When the model output parsing fails, the system activates a keyword-based fallback matching mechanism: based on the domain keywords appearing in the project name (six major categories including battery / energy, NLP / text, agriculture / planting, medical / health, finance / economics, and education / learning, as well as the default category), the system selects the two most matching professional directions from a predefined "domain → major / skill / role" mapping table to ensure that teammate generation is not interrupted due to model error returns.

[0070] Each virtual teammate is mapped to a generic dynamic teammate agent instance (DynamicTeammate). During instantiation, the system prompts for each teammate are replaced by template variables that substitute for the teammate's name, major, personality, and role (placeholders for [TEAMMATE_NAME], [TEAMMATE_MAJOR], [TEAMMATE_PERSONALITY], and [TEAMMATE_ROLE] in DYNAMIC_TEAMMATE_SYSTEM), allowing the same agent class to play roles in any professional field. During solution generation, the first teammate receives the user's technical solution as a context reference, while the second teammate simultaneously receives both the user's technical solution and the first teammate's generated solution, forming a multi-perspective fusion generation mode of "serial context passing." Each solution is independently saved as a Markdown file in the project directory after generation.

[0071] VI. Evidence Retrieval and Verification Integration Mechanism The system has built-in academic literature retrieval pipeline and policy evidence retrieval pipeline, both of which are asynchronously prefetched by the background daemon thread after step 4 is completed.

[0072] The academic literature retrieval pipeline is as follows: First, the large language model extracts Chinese and English search keywords (KEYWORD_EXTRACTION_PROMPT) based on the project title; then, multi-keyword retrieval is performed through the Paper Bulk Search interface of the Semantic Scholar Academic Graph API client (SemanticScholarClient), requesting fields including paper ID, title, abstract, author, publication channel, year, citation count, and DOI; the search results are deduplicated by DOI; subsequently, if configured to be enabled, the Crossref DOI verifier performs metadata cross-validation on each paper to confirm DOI validity and metadata integrity; finally, the verified documents are written to the literature pool file (literature_pool.json) in structured JSON format, with version numbers marked for subsequent citations. Configuration options control whether incremental supplementation is enabled, whether forced refresh is enabled, minimum number of documents, and year range, among other strategies.

[0073] The policy evidence retrieval pipeline uses a domain whitelist mechanism (POLICY_ALLOWED_DOMAINS, covering official website domains of central and ministerial departments such as gov.cn, miit.gov.cn, ndrc.gov.cn, and most.gov.cn) to limit the search scope, ensuring the authority and traceability of policy sources. Search results are also stored in a structured JSON format in the policy evidence file (policy_evidence.json).

[0074] In the proposal aggregation stage of step 6, the document coordination agent automatically injects the verified academic citation list (verified_academic_references) and policy evidence entries from the literature pool into the JSON material pack file (materials_pack.json) when generating the material pack. This allows each chapter in the writing scaffold to directly cite verified evidence, forming a closed-loop evidence chain of "retrieval → verification → structured accumulation → chapter citation".

[0075] VII. Version Control and Audit Tracking Mechanism The system implements a version control for proposal documents. Its data model includes three core structures: (1) ProposalVersion, which records the version number, such as "1.0", "2.0", content summary, change description list, review record list and creation timestamp; (2) ExpertReview, which records the expert name, review status (four enumeration values: PENDING / APPROVED / REJECTED / REVISION), evaluation text, modification requirement list, concern list and timestamp; (3) ConflictRecord, which records the two experts involved in the conflict, conflict description, the proposal version, solution and whether it has been resolved.

[0076] The version controller creates an initial version (v1.0) when generating the writing scaffold in step 6, and creates a new version (v2.0) after each revision based on expert opinions in step 9. The review and conflict records for each version are serialized and stored along with the version data. A version evolution summary (get_evolution_summary) can be injected into the appendix when the final report is generated, providing a complete audit trail of the project's iterative improvement process.

[0077] VIII. Multi-expert parallel review and conflict detection mechanism The second phase, expert review, sequentially activates three review agents, each with its own professional system prompts and review templates: the cost / supply chain expert focuses on budget details, BOM list rationality, and supply chain risks (COST_EXPERT_REVIEW); the technology security expert focuses on technical solution feasibility, architectural security, and technical risks (TECH_SECURITY_EXPERT_REVIEW); and the compliance and ethics expert focuses on regulatory compliance, privacy protection, and ethical issues (COMPLIANCE_EXPERT_REVIEW). Each expert independently sends a review request containing the complete proposal text to the large language model, obtaining a structured JSON result including a "pass / fail" judgment, overall evaluation, key points, modification requirements, and advantages.

[0078] The three review results are then fed into the conflict detection agent. This agent uses a dedicated conflict detection prompt template (CONFLICT_DETECTOR_PROMPT) to format the three review comments into a unified text input. The large language model is required to identify the substantial conflicts between the experts in dimensions such as cost versus security, security versus compliance, and cost versus compliance. The output is a structured JSON result containing the conflict type, the parties involved, the conflict description, the respective requirements of each party, the severity, and a solution suggestion and trade-off explanation. After the conflict record is written to the version controller, it is returned to the client along with the review results of the three experts, providing the user with a focused direction for modification.

[0079] IX. Mechanism for Generating Chapter-by-Chapter Final Drafts and Exporting Files Across Platforms The final report was generated using a "chapter-by-chapter independent call" strategy. The server first used regular expression rules to split the full text of the revised proposal after game theory into a text dictionary of each chapter (_split_proposal_into_chapters) in the format "### N. chapter title". Then, following the predefined nine-chapter configuration table (FINAL_REPORT_CHAPTERS, each item containing chapter number, title, title row, source chapter key, and writing guidance), the following steps are executed sequentially: Abstract generation (individual call, FINAL_REPORT_ABSTRACT_PROMPT) → Chapter-by-chapter text generation (independent call for each chapter, FINAL_REPORT_CHAPTER_PROMPT, filling the template with the chapter's source text, project information, writing guidance, and expert review context, ensuring sufficient token space for each call) → References chapter generation (FINAL_REPORT_REFERENCES_PROMPT) → Appendix A generation (FINAL_REPORT_APPENDIX_PROMPT, injecting version evolution history and expert review record summary), totaling 12 independent inference calls. The results of each part are concatenated on the server side and saved as final_report.md.

[0080] The file export process enables cross-platform automatic conversion from Markdown to PDF. The system first checks if the pandoc and xelatex toolchains are installed on the local machine, then performs automatic font detection (_detect_pdf_fonts): on Windows, it queries the set of font filenames in the system font directory (%WINDIR%\Fonts); on macOS, it obtains the font list using the system_profiler command; and on Linux, it obtains the font family list using the fc-list command. Available fonts are selected from the candidate font list (divided into three groups: main text, Chinese, and monospace) according to priority. Subsequently, the Markdown text undergoes Unicode symbol preprocessing (_normalize_markdown_for_pdf), replacing special characters with corresponding LaTeX macros (e.g., \ensuremath{\ge}, \ding{51}, \ensuremath{\alpha}), and inserting the \allowbreak{} macro at forward slashes in long paths to allow automatic line breaks. Finally, the custom LaTeX header file (header.tex), the Lua table line wrapping filter (wrap_tables.lua), and the detected font parameters are combined using the pandoc command to generate a PDF file. Both the Markdown and PDF files are stored in the project directory and returned to the client as a downloadable URL via a file operation interface.

[0081] 10. Project Persistent Storage System The system uses the ProjectStore to centrally manage file read / write operations for all projects. The default root directory is . / data / projects / , and each project corresponds to a subdirectory identified by a timestamp. The ProjectStore provides atomic operations such as JSON serialization / deserialization (save_json / load_json), plain text read / write (save_text / load_text), file list query (list_files), and project deletion (delete_project). After a typical project is completed, the following file list appears in its directory: metadata.json (project metadata), session.json (session state snapshot), versions.json (version control data and review records), tech_plan_input.txt (user technical solution), material_plan.md (first teammate's solution), design_plan.md (second teammate's solution), research_outline.json (research roadmap structure), literature_pool.json (verified academic literature pool), policy_evidence.json (policy evidence library), materials_pack.json (structured material pack), writing_scaffold_v1.0.md (writing scaffold), planning_review.md (completed planning review draft), proposal_v1.0.md (initial proposal), proposal_v2.0.md (revised proposal after negotiation), final_report.md (final report Markdown version), final_report.pdf (final report PDF version), and process log files such as conversation_log. All of the above documents are stored on the server storage medium in a human-readable open format, forming a complete and traceable project archive.

[0082] Example 1: Interactive Implementation Based on Command Line Terminal The preferred implementation described above employs a separate architecture between the browser client and the Web API server. Alternatively, this invention also provides an interactive implementation based on a command-line terminal (CLI) (corresponding to the main_dachuang.py entry point in the system). In this implementation, the user interacts with the system through standard terminal input / output. The system presents step options in the form of a text menu in the terminal, such as "Please select [1 / 2]". The user inputs numerical options to drive the process forward. Stage outputs are written to the project directory as local files. The user opens and edits these files using a text editor, such as tech_plan_input.txt, planning_review.md, and writing_scaffold_v1.0.md. After saving, the user returns to the terminal and presses Enter to trigger the system to read the updated file content and continue the subsequent process. This implementation shares the same intelligent agent engine, quality gate, evidence retrieval pipeline, and version control mechanism as the Web API implementation. The only difference is that the user interaction layer is replaced by standard terminal I / O communication instead of browser HTTP communication, making it suitable for standalone use cases or development and debugging scenarios that do not require the deployment of Web services.

[0083] Example 2: Implementation of Multi-Model Backend Adaptation In a preferred embodiment, the system calls an external large language model service through the APIModel class. The APIModel of this invention implements an automatic adaptation mechanism for multiple model backends, including three calling paths: (a) for DeepSeek series models, using the OpenAI Python SDK Client instance with the chat.completions.create method; (b) for other OpenAI-compatible relay services or self-built models, using the standard HTTP POST method to send a request body (including model name, message list, and temperature parameters) to the configured API address, and parsing the choices[0].message.content field in the JSON response; (c) for Anthropic Claude series models, calling through the Anthropic Python SDK (imported as an optional dependency in the system). Users can switch model backends by modifying the API_KEY, API_URL, and MODEL_CONFIG.default_model parameters in the configuration file (config.py), without modifying the agent or business logic code. Furthermore, the system also reserves an adaptation interface for locally deployed Transformer models (through optional import of the torch and transformer libraries). Different model backends only affect inference quality and response speed, without changing the system's flow control logic and document output structure.

[0084] Example 3: Configurable Implementation of Evidence Retrieval Strategy In a preferred embodiment, cross-validation is performed using the Crossref DOI validator after academic literature retrieval. This invention provides several optional strategy combinations through the evidence base configuration item (EVIDENCE_CONFIG): (a) Skip Crossref Verification Mode: When skip_crossref_verification is set to True, the system directly writes the results to the literature pool after the Semantic Scholar search is completed, without performing DOI cross-validation. This mode reduces the literature search time from about 200 seconds to about 10 seconds, and is suitable for scenarios with limited network conditions or low requirements for verification accuracy.

[0085] (b) Incremental Literature Supplementation Mode: When incremental_literature is set to True, the system allows newly retrieved literature to be added to the existing literature pool during the review and modification stage in step 7, instead of completely reusing the literature pool from step 5. This mode is suitable for scenarios where users find they need more literature from other fields to support their editing process.

[0086] (c) Forced Refresh Mode: When force_refresh_literature or force_refresh_policy is set to True, the system ignores the existing cached literature pool / policy library and re-executes the full search in step 5. This mode is suitable for scenarios where the evidence library needs to be updated after a significant change in the project topic.

[0087] (d) Evidence Reuse Mode: When reuse_literature and reuse_policy_evidence are set to True (default value), the literature pool and policy database generated in Step 5 are directly referenced in Step 6 (summarizing proposals) and Step 7 (reviewing and modifying), avoiding duplicate searches. This mode is the default recommended strategy, saving computational and network resources while ensuring evidence consistency.

[0088] Switching to the above strategy only involves modifying configuration parameters; the internal retrieval pipeline and file storage structure of the system remain unchanged.

[0089] Example 4: Two Implementation Methods for Splitting and Merging Planning Generation Interfaces In the preferred embodiment, step 5, the research planning, is initiated by calling four sub-interfaces in sequence: (1) generate_planning_outline generates the research roadmap, task schedule, and coverage analysis; (2) search_literature performs academic literature retrieval; (3) search_policy performs policy evidence retrieval; and (4) finalize_planning completes the planning summary and generates the planning_review.md file. This decomposition method allows the front-end to provide timely progress feedback to the user after each sub-step is completed and allows for independent retrying of failed sub-steps.

[0090] Alternatively, the system retains the merge interface (generate_planning), which executes the four sub-steps sequentially within a single call and returns the complete result. This implementation is suitable for CLI modes or batch processing scenarios with lower requirements for real-time interface feedback, reducing the number of front-end and back-end communications. Both methods call the same agent method and storage logic on the server side, resulting in identical file content.

[0091] Example 5: Implementation of Asynchronous Evidence Prefetching and Synchronous Retrieval In a preferred embodiment, after the teammate's work is confirmed in step 4, the system asynchronously starts a prefetching task of literature and policy evidence in the background through a Python daemon thread (_prefetch_evidence). This allows the server to perform time-consuming network retrieval operations in parallel in the background while the user views the teammate's proposal review results on the browser. By the time the user enters step 5, the evidence is ready, significantly reducing the user's perceived waiting time.

[0092] As an alternative implementation, the prefetching mechanism can be disabled, and the retrieval can be performed synchronously after the user explicitly triggers it in step 5. This implementation is simpler to implement and suitable for environments with limited server computing resources where parallel execution of background tasks is not advisable. The evidence files produced by both methods are identical in content; the only difference lies in the waiting time at the user experience level.

[0093] Example 6: Multiple Implementation Methods for File Export Formats In the preferred embodiment, the final report outputs both Markdown and PDF files. PDF export relies on the pandoc and xelatex toolchains, and the system automatically detects whether they are installed at runtime: if both are available, the complete Unicode preprocessing, font detection, and PDF generation process is executed; if the toolchain is unavailable, the system only outputs Markdown files, without interrupting the main process or throwing exceptions due to missing tools.

[0094] In addition, the system handles automatic line wrapping for wide tables by introducing a custom Lua filter (wrap_tables.lua) into the pandoc command, and injects additional typesetting control commands through the LaTeX header file (header.tex). In environments without a Lua filter, the system automatically skips this parameter and generates PDFs using basic typesetting.

[0095] The configuration option SYSTEM_CONFIG.export_pdf allows administrators to globally disable the PDF export function. In this case, the system only generates Markdown files, which is suitable for lightweight deployment scenarios without a LaTeX environment.

[0096] Example 7: Implementation methods for private deployment and cloud deployment The server-side application of this invention runs on FastAPI + Uvicorn and supports the following deployment methods: (a) Local standalone deployment: Run api_server.py directly on a computer with a Python runtime environment installed. The front-end and back-end communicate via localhost. Suitable for personal use or educational demonstrations.

[0097] (b) On-campus server deployment: The backend is registered as a system daemon process through the systemd service unit file (dachuang-api.service), and Nginx reverse proxy (nginx.conf) is used to uniformly route and distribute frontend static resources and backend API requests. The deployment script (setup.sh) automatically completes dependency installation, service registration, and reverse proxy configuration. Suitable for scenarios that provide services to all faculty and students.

[0098] (c) Cloud Host / Containerized Deployment: The backend application is packaged into a Docker container image, the frontend is built as static resources and deployed on CDN or object storage, and the backend container is connected through the cloud platform's load balancer. Suitable for large-scale concurrent access scenarios.

[0099] The three deployment methods described above share the same application code and configuration structure, differing only in the network topology and process management methods of the runtime environment. Project data is stored in the . / data / projects / directory of the server's local file system. When persistence is required, this directory can be mounted to a network storage volume or backed up to object storage periodically.

[0100] Example 8: Extended Implementation of Assistive Writing Tools In a preferred embodiment, the system provides four writing assistance functions (polishing, expansion, checking, and thought process), each corresponding to an independent prompt template (WRITING_POLISH_PROMPT, WRITING_EXPAND_PROMPT, WRITING_CHECK_PROMPT, WRITING_HINTS_PROMPT), and uses a unified writing assistance interface ( / assist / writing) with the `assist_type` parameter to distinguish the call type. This interface is designed for scalability: when adding a new writing assistance function, only a new prompt template constant needs to be defined and the corresponding `assist_type` value added to the branch logic of the interface; no modification to the agent base class or front-end routing structure is required. For example, it can be extended to include "translation" (translating a specified paragraph into an English abstract), "citation suggestions" (recommending validated references based on paragraph content), and "formatting standards" (checking whether chapter title numbers, table numbers, and citation formats conform to standards). All functions are executed through a lightweight call mode (simple_chat) of the document coordination agent, without introducing additional agent instances.

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

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

Claims

1. A simulation method for project-based education for university students based on multi-agent systems, characterized in that, Includes the following steps: S1. Obtain the project creation request, create the project directory and initialize the session manager and version controller. The session manager maintains a finite state machine. The state space of the finite state machine includes three stages: system initialization, collaborative construction period and game-theoretic defense period. S2. During the collaborative construction phase, the following steps are executed in sequence: project naming, team leader information collection, dynamic generation of AI virtual teammates, division of labor and quality gate control, research route and task planning, proposal summarization, and review, modification and writing assistance. After each step is completed, the status is automatically advanced and persisted. After the review, modification and writing assistance are completed, the game defense phase begins. S3. During the game defense period, the following steps are executed in sequence: three-expert serial review and conflict detection, proposal revision based on expert opinions, and final report generation by chapter and cross-platform file export. After the proposal is revised and approved, the final report is generated by the document coordination agent in one go based on the expert review history and version evolution record, and Markdown and cross-platform adapted PDF format files are output at the same time.

2. The multi-agent-based project-based education simulation method for university students as described in claim 1, characterized in that, In step S1, after the initialization is completed, the server persists the project metadata, session state, and version control information to the project directory in JSON format. The client realizes the synchronization and linkage between the front-end interaction and the back-end state based on the current stage identifier of the state machine.

3. The multi-agent-based project-based education simulation method for university students as described in claim 1, characterized in that, In step S1, the project directory is a unique directory with a timestamp as the unique identifier. The state space of the finite state machine is further subdivided into: topic selection, team division of labor, knowledge planning, task planning, document integration, expert review, and completion sub-states. The state transitions are automatically executed by the server-side program.

4. The multi-agent-based project-based education simulation method for university students as described in claim 1, characterized in that, The project naming steps in S2 are as follows: the user submits a preliminary project name and core description, the server activates a naming consultant agent to generate candidate names, the final name is confirmed after multiple rounds of human-machine negotiation and optimization, and the status is automatically advanced and persisted after completion.

5. The multi-agent-based project-based education simulation method for university students as described in claim 1, characterized in that, The AI ​​virtual teammate dynamic generation step in S2 is as follows: the server generates two interdisciplinary virtual teammates based on project information and instantiates a general dynamic teammate intelligent agent; if the model output parsing fails, a keyword fallback mechanism is triggered to match professional directions.

6. The multi-agent-based project-based education simulation method for university students as described in claim 1, characterized in that, The division of labor and quality gate control steps in S2 include: structured scoring of user technical solutions, generation and review of virtual teammate solutions, asynchronous pre-fetching of academic literature and policy evidence, and blocking the process and returning optimization suggestions if the preset quality threshold is not met.

7. The multi-agent-based project-based education simulation method for university students as described in claim 1, characterized in that, The research route and task planning steps in S2 are as follows: the server activates multi-agents to generate a research outline, task scheduling tree, and coverage analysis report; and the retrieved evidence is deduplicated by DOI, verified by authoritative domain names, and then stored in a structured manner.

8. The multi-agent-based project-based education simulation method for university students as described in claim 1, characterized in that, The summary proposal step in S2 is as follows: the server integrates the solution to generate a structured material package, injects authoritative evidence and generates a writing scaffold, and at the same time creates a version control initial version for the scaffold.

9. The multi-agent-based project-based education simulation method for university students as described in claim 1, characterized in that, The review, modification, and auxiliary writing steps in S2 include four auxiliary functions provided by the server: polishing, expansion, checking, and idea generation. These functions are executed in a lightweight calling mode. After editing, the initial proposal is persisted and enters the game-theoretic defense period.

10. A multi-agent-based project-based education simulation system for university students, characterized in that, include: The client is used to collect project information input by the user and display the project process status; The server-side component implements the following modules: A multi-agent collaboration engine, which is used for the unified management, scheduling and large language model invocation of all agents; Finite state machine and stage-driven module are used to ensure that the project process proceeds automatically in a predetermined order and supports breakpoint resume; The quality gate control module is used to automatically score intermediate products at key nodes, and low-quality inputs are not allowed to pass through. The dynamic interdisciplinary teammate matching and parallel solution generation module is used to automatically generate interdisciplinary virtual teammates based on the project theme, and each virtual teammate independently generates a specialized solution from their own perspective, forming a multi-perspective complementary solution. The evidence retrieval and verification integration module is used to retrieve, verify, and consolidate academic literature and policy evidence, and integrate them into the writing process; The version control and audit tracking module is used to record all document versions and audit history, providing a complete evolution trajectory; The multi-expert parallel review and conflict detection module is used to review proposals sequentially from three heterogeneous dimensions: cost, technology, and compliance, and automatically identify conflicting requirements. The module for generating chapter-by-chapter final drafts and exporting files across platforms is used to integrate the revised proposals with expert review records and version evolution history, generate a standardized final report through a large language model, and support cross-platform export. The project persistent storage module is used to uniformly manage the file storage and read / write operations of all projects.

Images