A domain self-adaption skill group generation method for large language model agent

Abstract

The application belongs to the field of artificial intelligence, and discloses a domain self-adaptive skill group generation method for a large language model agent, comprising: receiving a feature vector input of a target domain; determining a skill group architecture level based on the feature vector through complexity scoring and decision tree routing, constructing a four-dimensional closed-loop data flow and a progressive latching mechanism; automatically deriving a knowledge evolution pipeline dimension and generating a database table structure; configuring adaptive behavior depth control logic and generating a timing task blueprint; outputting a skill group engineering file and automatically generating a runnable code infrastructure; automatically generating a perception layer connector skeleton code for each data source; and converting each step decision log into a directed acyclic graph structure. The application can automatically generate a complete skill group containing a multi-skill collaborative architecture, a knowledge evolution pipeline and an adaptive control mechanism according to domain features, thereby significantly reducing the engineering cost of deploying a large language model agent in multiple business domains.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, and more particularly to a method for generating domain-adaptive skill sets for large language model agents. Background Technology

[0002] In recent years, with the rapid development of large language model technology, intelligent agents based on large language models have been widely deployed in enterprise applications. Intelligent agents typically use "skills" as capability encapsulation units. Each skill packages business knowledge, operational processes, and reasoning logic for a specific domain into an independent module that can be loaded and executed by the agent on demand. However, different business domains have drastically different requirements for the number, division of labor, and collaboration methods of skills: simple scenarios can be completed with only a single skill, moderately complex scenarios require collaboration between skills, while complex business domains require a hierarchical collaborative architecture of multiple skills. How to efficiently build a complete skill system adapted to the business characteristics of a new domain has become a key issue restricting the large-scale deployment of large language model agents.

[0003] Currently, capability management solutions for large language model agents mainly fall into three categories. The first category, represented by LangChainAgent and Anthropic Skills, adopts a single-skill flat architecture, encapsulating task-related knowledge and processes into independent skill units that are loaded on demand by the Agent. This type of solution has a simple structure but cannot handle complex business scenarios requiring multi-skill collaboration. The second category consists of scaffolding generators, which can automatically generate the engineering skeleton (including skill description files, method files, and evaluation sets) of individual skills based on business scenario descriptions. However, they only support single-skill granularity and do not involve the design of collaborative architectures between skills. The third category, represented by AutoGPT Forge, possesses self-improvement loops and persistent memory capabilities, but its monolithic architecture couples all capabilities into a single Agent, making it difficult to decompose, reuse, and evolve independently. These existing technologies all have significant shortcomings when facing complex business domains that require multi-level collaboration: On the one hand, the design of multi-skill collaborative architectures relies entirely on human experience, requiring a manual design cycle of 2 to 3 weeks for each new domain, and is prone to overlooking key components; on the other hand, large language models are stateless, starting from scratch for each session, and cannot retain the knowledge and feedback signals accumulated in previous interactions. Existing solutions either rely entirely on external database storage but lack signal aggregation and threshold triggering mechanisms, or hard-encode historical information in prompts but are limited by the length of the context window; in addition, the depth of agent behavior processing lacks parameterized control, and requests of different complexities are treated equally, resulting in a waste of computing resources or insufficient processing depth. Summary of the Invention

[0004] The technical problem to be solved by this invention is: how to provide a method that can automatically generate a complete skill set including a multi-skill collaborative architecture, a knowledge evolution pipeline, adaptive behavior control and self-improvement mechanism based on the feature description of the target domain.

[0005] Specifically, the present invention provides a domain-adaptive skill set generation method for large language model proxies, comprising the following steps: S1. Receive feature vector input from the target domain. The feature vector contains structured description information of data source dimension, interaction mode dimension, knowledge feature dimension, quality requirement dimension and execution feature dimension. S2. Based on the feature vector, a complexity score is calculated using a complexity scoring algorithm. The architectural hierarchy of the skill group is determined through decision tree routing based on the score. When the score is below a first threshold, a single-skill architecture is selected. When the score is between the first and second thresholds, a two-layer architecture is selected, and the second-layer role is determined. When the score is above the second threshold, a three-layer architecture including a metacognitive control layer, a knowledge evolution layer, and a data perception layer is selected. The data flow direction is derived based on the dependencies between the determined roles at each layer, where the data flow between the metacognitive control layer and the knowledge evolution layer is bidirectional, constructing a four-dimensional closed-loop data flow architecture. A progressive latching hierarchy is determined based on cross-session requirements, feedback signal density, and architectural hierarchy. S3. Based on the feature vector and the architecture hierarchy determined in step S2, automatically deduce the number of dimensions of the knowledge evolution pipeline, generate corresponding database table structures and index definitions for each dimension, and select the corresponding confidence evaluation model according to the structured nature of the data source. S4. Based on the skill group architecture hierarchy determined in step S2 and the database table structure features generated in step S3, automatically configure adaptive behavior depth control logic, including evaluation dimension selection, depth level definition, and action clipping strategy corresponding to each depth level. S5. Based on the skill group architecture hierarchy determined in step S2, the knowledge evolution pipeline configuration generated in step S3, and the adaptive behavior configuration generated in step S4, automatically generate a scheduled task blueprint, including task type selection and frequency calculation. Scheduled tasks are not generated for single skill architectures. S6. Output the generation results of steps S2 to S5 as a skill group project file containing skill group topology configuration, knowledge evolution pipeline configuration, adaptive behavior configuration and timed task blueprint. S7. Based on the skill group project file output in step S6, automatically generate a runnable code infrastructure, including a shared configuration module, a database initialization script, a phased knowledge base command line tool, and a project management command line tool, wherein the phased knowledge base command line tool uses a directed acyclic graph to manage the execution dependencies between commands. S8. Based on the feature description of the data source dimension in step S1, automatically generate the corresponding type of perception layer connector skeleton code for each data source, and generate the connector registry and unified degradation infrastructure module. S9. Convert the decision logs generated in steps S2 to S8 from a flat structure to a directed acyclic graph structure, perform integrity verification, and output the directed acyclic graph of decision logs.

[0006] A domain-adaptive skill set generation device for large language model agents includes: a processor and a storage medium; the processor loads and executes instructions and data in the storage medium to implement a domain-adaptive skill set generation method for large language model agents.

[0007] The beneficial effects of this invention are as follows: The domain-adaptive skill group generation method and system proposed in this invention for large language model agents automatically determine the architectural hierarchy of the skill group by receiving structured domain feature vector input, using a complexity scoring algorithm and decision tree routing, and further generating a knowledge evolution pipeline, adaptive behavior configuration, and scheduled task blueprint, ultimately outputting a complete skill group project containing runnable code infrastructure. This invention achieves end-to-end automated generation of skill group architecture, shortening the design cycle of new domains from 2 to 3 weeks to several minutes. Simultaneously, it ensures that simple scenarios avoid over-engineering and complex scenarios possess complete knowledge evolution capabilities through a complexity adaptive mechanism. It systematically solves the problem of cross-session knowledge accumulation in stateless large language models through a four-dimensional closed-loop data flow architecture and a three-layer progressive latching mechanism. It achieves differentiated processing of requests with different complexities through parameterized behavior depth control. The final generated code infrastructure includes a phased knowledge base command-line tool and a perception layer connector, which can be directly deployed and run. This invention provides a systematic engineering solution for the large-scale deployment of enterprise-level large language model agents. Attached Figure Description

[0008] Figure 1 This is a simplified flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the hardware device of the present invention. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0010] Before formally describing the present invention, a general description of the solution of the present invention will be given first to facilitate understanding.

[0011] Please refer to Figure 1 This invention provides a domain-adaptive skill set generation method for large language model proxies, comprising the following steps: S1. Receive feature vector input from the target domain. The feature vector contains structured description information of data source dimension, interaction mode dimension, knowledge feature dimension, quality requirement dimension and execution feature dimension. As one embodiment, in step S1 of the present invention, the feature vector is a structured JSON object containing a five-dimensional feature description. Specifically: Data source dimensions include: data source type (e.g., database, document, API, file, stream, table), degree of structuring (structured, semi-structured, unstructured), data volume (low, medium, high), whether it contains attachments, and whether external validation is required.

[0012] Interaction mode dimensions include: interaction type (query, analysis, reporting, monitoring, creation), frequency (low, medium, high), processing depth (lightweight, standard, in-depth), and latency tolerance. For example, the interaction mode for a procurement contract analysis scenario can be represented as: json "interaction_patterns": [ {"type": "query", "frequency": "high", "depth": "light", "latency_tolerance": "low"}, {"type": "analysis", "frequency": "medium", "depth": "deep", "latency_tolerance": "medium"}, {"type": "report", "frequency": "low", "depth": "deep", "latency_tolerance": "high"} ] Knowledge characteristic dimensions include: whether it has timeliness dependence, whether it needs cross-session memory, feedback signal density (low, medium, high), knowledge evolution speed (slow, medium, fast), domain-specific external information source list, and domain classification system.

[0013] Quality requirements include: error tolerance (zero, low, medium, high), whether internal and external evidence is required, whether working papers are required, and expected output format.

[0014] Execution characteristics include: whether parallel execution is required, maximum acceptable latency, and whether project lifecycle management is required.

[0015] S2. Based on the feature vector, a complexity score is calculated using a complexity scoring algorithm. The architectural hierarchy of the skill group is determined through decision tree routing based on the score. When the score is below a first threshold, a single-skill architecture is selected. When the score is between the first and second thresholds, a two-layer architecture is selected, and the second-layer role is determined. When the score is above the second threshold, a three-layer architecture including a metacognitive control layer, a knowledge evolution layer, and a data perception layer is selected. The data flow direction is derived based on the dependencies between the determined roles at each layer, where the data flow between the metacognitive control layer and the knowledge evolution layer is bidirectional, constructing a four-dimensional closed-loop data flow architecture. A progressive latching hierarchy is determined based on cross-session requirements, feedback signal density, and architectural hierarchy. As one embodiment, step S2 of the present invention is specifically implemented through the following sub-steps: S2a: Complexity Score. The complexity score is calculated based on 8 feature dimensions (0-13 points): multiple data sources (≥3, add 3 points), unstructured data or attachments (add 2 points), external data verification required (add 2 points), deep analysis interaction exists (add 2 points), cross-session memory is required (add 1 point), knowledge has timeliness (add 1 point), high feedback signal density (add 1 point), parallel execution is required (add 1 point).

[0016] S2b: Architecture-level routing. Decision tree routing based on complexity scores: 0-3 points → single-layer architecture (monolithic harness); 4-6 points → two-layer architecture (harness + memory or harness + perception); 7 points and above → three-layer architecture (harness + memory + perception).

[0017] S2c: Role Determination. For a two-tier architecture, the roles of the second layer are determined through requirements analysis: the perception layer is selected when unstructured data or attachments are the main source of complexity; the memory layer is selected when cross-session memory and high feedback density are the main sources of complexity; and the memory layer is prioritized when both are needed (perception logic can be embedded in the harvester's query steps). For a three-tier architecture, the harvester layer is responsible for metacognitive control and judgment framework, the memory layer is responsible for knowledge base management and signal accumulation, and the perception layer is responsible for data acquisition and external search.

[0018] S2d: Data Flow Direction Derivation. Data flow direction is automatically generated based on the dependencies between roles. The harvester layer and memory layer have a bidirectional data flow, constructing a four-dimensional closed-loop data flow architecture: First dimension, core business data flows from the perception layer to the memory layer for persistent storage; second dimension, business knowledge flows from the memory layer to the harvester layer for business judgment and decision-making; third dimension, user preferences flow from the memory layer to the harvester layer for personalized behavior tailoring; fourth dimension, agent behavior feedback flows back from the harvester layer to the memory layer, triggering incremental updates in the knowledge evolution pipeline. In this four-dimensional closed loop, if the data flow in any dimension is interrupted, the system automatically degrades to a three-dimensional or two-dimensional closed-loop mode.

[0019] S2e: Latch Level Decision. A 0-3 layer progressive latch mechanism is determined based on cross-session requirements, feedback density, and architectural hierarchy. When cross-session memory is required, a first layer (session-level latch) is established: all interaction records and signal data of the current session are persisted in an SQLite database. When the feedback density is medium or high, a second layer (periodic latch) is established: periodic signal aggregation analysis is performed on the data latched in the first layer using a Cron scheduled task, extracting high-confidence signals and promoting them to the shared knowledge layer. When the architectural hierarchy is three layers, a third layer (architectural latch) is established: based on the principle of "reading signals but not recording signals," a one-way signal reading channel is established between the harness layer and the memory layer to prevent evaluation signals from being mistakenly recorded as business data. The three layers of latches form a progressive dependency: the first layer of latch provides raw data to the second layer of latch, and the output of the second layer of latch is read by the harness layer through the one-way channel of the third layer of latch, forming a complete latch chain of data acquisition → signal analysis → knowledge consumption.

[0020] S2f: Knowledge Sharing / Isolation Strategy. The multi-skill architecture adopts a hybrid strategy: objective data (business records, extraction results, external benchmarks) are shared globally; subjective analysis (benchmarking conclusions, business judgments) is isolated by project.

[0021] Each sub-step records a decision log, including the evaluated options, the selection result, the reason for the selection, and the rejected options.

[0022] Taking procurement contract analysis as an example, its feature vector includes three data sources, unstructured attachments, requires external verification, involves deep analytical interaction, requires cross-session memory, has time sensitivity, high feedback density, and requires parallel execution. The complexity score is 3+2+2+2+1+1+1+1=13 points, routing to a three-tier architecture (harness+memory+perception). In terms of data flow, business data from the SAP procurement system flows from the perception layer to the memory layer, contract analysis knowledge flows from the memory layer to the harness layer for procurement decisions, user preferences are personalized at the harness layer, and procurement suggestions generated by the agent flow back to the memory layer to trigger knowledge evolution. Regarding latching, all three layers of latching are enabled: SQLite persistent session records, Cron daily analysis feedback signals, and a "read signal, don't record signal" approach to prevent evaluation pollution.

[0023] S3. Based on the feature vector and the architecture hierarchy determined in step S2, automatically deduce the number of dimensions of the knowledge evolution pipeline, generate corresponding database table structures and index definitions for each dimension, and select the corresponding confidence evaluation model according to the structured nature of the data source. As one embodiment, step S3 of the present invention is specifically implemented through the following sub-steps: S3a: Automatic discovery of knowledge dimensions. The number of dimensions for knowledge loop closure is derived from domain characteristics (1-5 dimensions): Core business data dimension (required for all domains); Business knowledge dimension (when there are structured data sources or multiple interaction types); User preference dimension (when cross-session memory is required); Agent behavior dimension (when feedback signal density is medium or high); External benchmark dimension (when external data verification or dual evidence is required).

[0024] S3b: Database Schema Derivation. Automatically generates SQLite table structures based on knowledge dimensions, including: core business data tables (containing field-level confidence JSON, source tracking, and expiration time fields); feedback signal tables (containing signal type, target type, session ID, severity, and resolution status fields); and external benchmark tables (containing source levels L1-L5, comparability descriptions, and candidate / adoption / archived status fields). Each table automatically generates corresponding index definitions.

[0025] S3c: Confidence assessment model selection. Fully structured data source → field-level relative quantile model; fully unstructured data source → document-level scoring model; mixed data source → weighted mixed strategy (structured data weight 0.6, unstructured data weight 0.4).

[0026] For example, in the field of procurement contract analysis, the data source includes structured databases and semi-structured documents, which is a mixed data source. Therefore, a weighted mixed strategy is selected, where the confidence weight of structured data (SAP procurement system) is 0.6, and the confidence weight of unstructured data (contract PDF attachments) is 0.4. The system automatically generates three SQLite tables: the `business_data` table stores the core business fields of the procurement contract (contract number, supplier, amount, signing date, etc.) and their field-level confidence JSON; the `feedback_signals` table stores user feedback signals on the procurement analysis results; and the `external_references` table stores external benchmark data such as CCI index and futures prices. Each table automatically creates a corresponding index (e.g., the contract number index in the `business_data` table and the session ID index in the `feedback_signals` table).

[0027] S4. Based on the skill group architecture hierarchy determined in step S2 and the database table structure features generated in step S3, automatically configure adaptive behavior depth control logic, including evaluation dimension selection, depth level definition, and action clipping strategy corresponding to each depth level. As one embodiment, step S4 of the present invention is specifically implemented through the following sub-steps: S4a: Evaluation Dimension Selection. Knowledge Base Maturity Dimension (enabled when using a multi-skill architecture, weight 0.3); Data Quality Dimension (enabled when there is a structured data source, weight 0.25); Interaction Intent Complexity Dimension (enabled in all domains, weight 0.35); User Knowledge Profile Dimension (enabled when cross-session memory is required, weight 0.1).

[0028] S4b: Depth Level Definition. Lightweight (All Domains): Only performs queries and low-confidence field supplementation, excluding full field extraction, knowledge accumulation, and external search; Standard Level: Adds full field extraction and standard presentation, excluding external search and field discovery; Depth Level (When there is in-depth analysis interaction or multi-skill architecture): Adds field discovery, knowledge accumulation, formal reports, dual evidence verification (condition), working papers (condition), and project lifecycle management (condition).

[0029] S4c: Presentation rule generation. Based on the output format fields required for quality, automatically generate presentation adaptation rules (tabular data → Excel, formal report → Word, trend analysis → chart), and attach general rules (low confidence level source labeling, working papers not presented, backend behavior transparent to users).

[0030] For example, in the field of procurement contract analysis, the skill set architecture is three-layered (with knowledge base maturity dimension enabled, weight 0.3), has structured data sources (with data quality dimension enabled, weight 0.25), enables interaction intent complexity dimension in all domains (weight 0.35), and requires cross-session memory (with user knowledge profile dimension enabled, weight 0.1). In the depth level definition, for lightweight queries such as "querying the historical contract prices of a supplier," only database queries and result returns are performed; for standard analyses such as "analyzing procurement cost trends over the past three years," full field extraction and trend chart presentation are performed; for deep tasks such as "generating an annual procurement strategy report," field discovery, knowledge accumulation, formal report generation, dual evidence verification (internal SAP data + external CCI index), and working paper generation are performed. Regarding presentation rules, tabular data is automatically rendered in Excel format, formal reports are rendered in Word format, and trend analysis is rendered as charts.

[0031] S5. Based on the skill group architecture hierarchy determined in step S2, the knowledge evolution pipeline configuration generated in step S3, and the adaptive behavior configuration generated in step S4, automatically generate a scheduled task blueprint, including task type selection and frequency calculation. Scheduled tasks are not generated for single skill architectures. As one embodiment, step S5 of the present invention is specifically implemented through the following sub-steps: S5a: Task type selection. Single-skill architecture → 0 scheduled tasks (avoid over-engineering); Multi-skill architecture → On-demand generation: Knowledge enhancement tasks (personal knowledge → shared knowledge, all multi-skill architectures); Consistency check tasks (field definition conflict detection, when there is a memory layer); Obsolescence check tasks (expired knowledge marking, when there is a time-sensitive dependency); Self-improvement review tasks (feedback signal accumulation → threshold → patch suggestions, when there are ≥2 latch layers).

[0032] S5b: Frequency is automatically calculated. The frequency of knowledge enhancement is determined by the speed of knowledge evolution: slow → weekly, medium → every 3 days, fast → daily. The frequency of self-improvement review is determined by the density of feedback signals: high → weekly, medium → every 2 weeks, low → monthly.

[0033] For example, in the field of procurement contract analysis, the skill set is a three-layer multi-skill architecture with a memory layer, time-dependent dependencies, and a latch layer of 3 layers (≥2). Therefore, four scheduled tasks are generated: (1) Knowledge enhancement task - executed every 3 days due to the "medium" knowledge evolution speed, to enhance personal-level procurement analysis knowledge to shared knowledge; (2) Consistency check task - executed weekly to check for conflicts in procurement contract field definitions; (3) Obsolescence check task - executed every 2 weeks to mark expired price benchmark data; (4) Self-improvement review task - executed weekly due to the "high" feedback signal density, to generate patch suggestions after the accumulated feedback signals reach the threshold.

[0034] S6. Output the generation results of steps S2 to S5 as a skill group project file containing skill group topology configuration, knowledge evolution pipeline configuration, adaptive behavior configuration and timed task blueprint. In one embodiment, step S6 of the present invention outputs the results of steps S2-S5 as structured JSON files: topology.json (skill group topology configuration, including architecture hierarchy, role division, data flow direction, and latch hierarchy), evolution.json (knowledge evolution pipeline configuration, including knowledge dimensions, database schema, confidence model, and feedback signal classification), adaptive.json (adaptive behavior configuration, including evaluation dimensions, depth levels, and presentation rules), and cron.json (scheduled task blueprint, including task type and frequency). Optionally, the JSON output is populated into a predefined skill template skeleton through a template rendering engine to generate a SKILL.md file that can be directly loaded by the Agent at runtime.

[0035] In the field of procurement contract analysis, the output topology.json contains a three-tier architecture configuration, a four-dimensional closed-loop data flow definition, and a three-tier latch configuration; evolution.json contains complete schema definitions for 5 knowledge dimensions and 3 SQLite tables (including field names, data types, and index definitions), a mixed confidence model configuration, and 6 types of feedback signal definitions; adaptive.json contains 4 evaluation dimensions and their weights, 3 levels of action pruning rules, and Excel / Word / chart presentation adaptation rules; cron.json contains 4 scheduled tasks and their Cron expressions (such as "0 2"). "3" indicates that knowledge enhancement will be performed every Wednesday at 2:00 AM.

[0036] S7. Based on the skill group project file output in step S6, automatically generate a runnable code infrastructure, including a shared configuration module, a database initialization script, a phased knowledge base command line tool, and a project management command line tool, wherein the phased knowledge base command line tool uses a directed acyclic graph to manage the execution dependencies between commands. As one embodiment, step S7 of the present invention is specifically implemented through the following sub-steps: S7a: Generates a shared configuration module. It generates a `config.py` file containing domain-specific path constants (knowledge base path, project path, cache extraction path, etc.) and database connection factory functions (WAL mode, foreign key constraints, busy timeout settings). All skills obtain unified paths and connections via `import config`.

[0037] S7b: Database initialization script generation. Based on the schema derivation results in step S3b, init_db.py is automatically generated, creating all SQLite tables (including indexes) defined in step S3b, as well as metadata tables (schema_registry field registry, config_kv configuration key-value pairs, users table) and project tables (business_projects project lifecycle).

[0038] S7c: Knowledge base CLI phased generation. Generates knowledge_db.py, containing 20 commands across 5 phases: Phase 0 (basic commands, 6): init (database initialization), report (health report, including maturity assessment), feedback (feedback signals for adding, deleting, querying, and modifying data), query-data (structured data query, including whitelist security checks), config (configuration key-value pair management), and schema (field registry management).

[0039] Phase 1 (Extraction commands, 4): extract (field extraction requirement analysis), extract-apply (extraction result writing), text-extract (attachment text extraction skeleton), text-check (extraction dependency check).

[0040] Phase 2 (summary commands, 2): summarize-session (constructing the knowledge distillation prompt) and summarize-apply (writing the distillation results).

[0041] Phase 3 (promotion commands, 2): promote-shared (build personal knowledge upgrade prompt) and promote-apply (write upgrade results).

[0042] Phase 4 (Orchestration + Maintenance Commands, 6): workflow-plan (execution plan generation, including parallel_groups), workflow-query (extraction plan generation), benchmark-check (evidence set integrity verification), staleness-check (expired knowledge marking), consistency-check (field conflict detection), and backfill (missing extraction detection).

[0043] Commands are generated in stages, with each stage reading existing files and inserting new commands into the argparse parser and command dispatch table. Commands rely on a DAG to ensure they are executed in topological order. For example, when a user executes extract-apply, the system automatically checks if extract has already been executed; if not, it executes extract first.

[0044] S7d: Generates the project management CLI. It generates projects_cli.py, which contains five commands: project creation (automatically creating the project working directory), project list, project details, appending conclusions, and closing the project.

[0045] For example, in the field of procurement contract analysis, the system automatically generates config.py, where KNOWLEDGE_DB_PATH points to " / data / purchase / knowledge.db" and PROJECTS_DB_PATH points to " / data / purchase / projects.db"; generates init_db.py to create three tables: business_data, feedback_signals, and external_references, and their indexes; generates knowledge_db.py containing all 20 commands, where the extract-apply command has a dependency declaration of depends_on=["extract"], so the system automatically executes extract first when the user executes extract-apply; and generates projects_cli.py to support the creation of the "2026-Q2-Procurement Optimization" project and automatically creates the project working directory.

[0046] S8. Based on the feature description of the data source dimension in step S1, automatically generate the corresponding type of perception layer connector skeleton code for each data source, and generate the connector registry and unified degradation infrastructure module. As one embodiment, step S8 of the present invention is specifically implemented through the following sub-steps: S8a: Data source type routing. Iterates through the data_sources array of domain feature vectors and routes to the corresponding connector template based on the type field of each data source: type "api" → REST connector; type "database" → database query connector; type "document" → document parsing connector.

[0047] S8b: REST API connector generation. Generates connector classes containing unified fetch / parse / cache / status interfaces, with built-in authentication placeholders (bearer / cookie modes), pagination logic (parameterized page_size), a retry mechanism (exponential backoff after 3 attempts), error classification (auth / network / parse / rate_limit categories), and an adaptive degradation mechanism (automatically degrading to a local cached data source after 3 consecutive failed retries). The connector can be run directly via command line.

[0048] S8c: Database query connector generation. Generates connector classes containing query / cache_result / get_cached interfaces, with built-in features including read-only query enforcement (disabling INSERT / UPDATE / DELETE), result caching (TTL parameterization), query parameterization (preventing SQL injection), and an adaptive degradation mechanism (automatically degrading to a pre-cached query result set when a database connection timeout is detected).

[0049] S8d: File parsing connector generation. Generates connector classes containing the detect_format / extract_text / get_metadata interfaces, with built-in automatic format detection (PDF / DOCX / XLSX), text extraction (via pandoc or Python standard library), metadata management, extraction caching (avoiding duplicate parsing), and an adaptive degradation mechanism (automatically downgrading to OCR based on a large language model or format conversion alternatives when the target file format cannot be parsed).

[0050] S8e: Connector registry generation. Generates connector_registry.py, which automatically discovers and lists all available connectors in the current domain, along with their types, statuses, and descriptions.

[0051] S8f: Generates the connector adaptive degradation module. It generates `connector_fallback.py`, implementing a unified degradation infrastructure, including: `FeedbackSignalsStore` (persistently stores degradation events in the `feedback_signals` table based on SQLite, recording failure, degradation, and recovery events), `FallbackCache` (a local cache of successful request results, including TTL expiration management and hash key deduplication), `FailureTracker` (a cross-session consecutive failure counter, persisted based on SQLite, with parameterized thresholds; by default, degradation is triggered after 3 consecutive failures), and `FallbackManager` (a central degradation manager that coordinates the above three components and provides a unified interface). All degradation data is marked with `degraded=true`, `data_age_days`, `fallback_reason`, and `cached_at` fields.

[0052] Each connector is a standalone, runnable Python script implemented using a pure standard library (without third-party dependencies), and all output is in JSON format.

[0053] For example, in the field of procurement contract analysis, data_sources contains three data sources: (1) SAP procurement system (type is database) - generate db_connector.py, connect to SAP database, read-only query the procurement order table, TTL cache 300 seconds; (2) CCI index API (type is api) - generate rest_connector.py, use bearer authentication, paginate to get index data, 3 retries, after 3 consecutive failures, downgrade to local cache; (3) Contract PDF attachment (type is document) - generate file_connector.py, automatically detect PDF format, extract contract text, cache extraction results. connector_fallback.py uniformly manages the fallback events of the three connectors. When the CCI index API fails 3 times in a row, FailureTracker triggers fallback, FallbackManager returns the most recent successful data in the cache, and FeedbackSignalsStore records the fallback event to the feedback_signals table.

[0054] S9. Convert the decision logs generated in steps S2 to S8 from a flat structure to a directed acyclic graph structure, perform integrity verification, and output the directed acyclic graph of decision logs.

[0055] As one embodiment, step S9 of the present invention is specifically implemented through the following sub-steps: S9a: Decision Node Modeling. Each decision is a node, containing the fields node_id, parent_id, depth, and type (root / stage / decision). The root node (ROOT) has a depth of 0, and the step nodes (S2-S8) are stage nodes with a depth of 1. The specific decision nodes have depths of 2-4. Each node contains name, description, depends_on (dependencies), and children_ids (a list of child nodes).

[0056] S9b: Automatic DAG construction. Read the flat decision log (decisions.json) from steps S2-S8, and automatically assign parent_id and depth according to the ID prefix mapping rules: S prefix → child nodes of ROOT (depth=1); D prefix → child nodes of S2; E prefix → child nodes of S3; A prefix → child nodes of S4; C prefix → child nodes of S5. Establish dependencies between steps: S3 depends_on S2, S4 depends_on S2, S5 depends_on S3+S4.

[0057] S9c: DAG integrity verification. Perform three verifications on the constructed DAG: depth limit check (maximum depth does not exceed 5 levels), connectivity check (all nodes are reachable from the ROOT), and acyclic check (no circular dependencies exist).

[0058] S9d: Reverse tracing capability. Starting from any decision node, trace back along the parent_id link to the ROOT to generate a complete decision reasoning chain for auditing and interpretability analysis (XAI).

[0059] S9e: Decision Log DAG Output. The DAG structure is output as decisions_dag.json, which contains metadata such as total_nodes, total_decisions, total_stages, depth_distribution, and a complete list of nodes.

[0060] For example, in the field of procurement contract analysis, the decision node D-001 (complexity scoring decision) in step S2 includes the 8 dimensions of evaluation and their scores, the selection result (13 points), the reasons for selection (multiple data sources + unstructured data + external validation + in-depth analysis, etc.), and the rejected solutions (the 11-point solution was rejected because it did not include external validation). The decision node E-001 (knowledge dimension decision) in step S3 depends on D-001 and selects a 5-dimensional solution. Step S9 constructs all 18 decision nodes into a DAG with a maximum depth of 5 layers, passing the integrity verification. From any node (such as E-003 "confidence model selection"), the parent_id link can be traced: E-003 → E-001 (knowledge dimension decision) → D-001 (complexity scoring) → ROOT, fully demonstrating the decision reasoning chain from complexity scoring to confidence model selection.

[0061] Example 2 The determination of the progressive latch level in step S2 specifically includes: S21. When cross-session memory is required, establish the first-level latch and persist all interaction records and signal data of the current session based on the SQLite database. For example, when the "requires cross-session memory" field in the domain feature vector is true, the system automatically creates a `session_records` table in the SQLite database, containing fields such as `session_id`, `interaction_time`, `user_query`, `agent_response`, and `signal_data`. After each interaction between the agent and the user, the system automatically persists all interaction records and signal data for that session to this table. For instance, in procurement contract analysis, if a user queries "historical quotes from a certain supplier," the agent's query process and returned results are fully recorded for later session review.

[0062] S22. When the feedback signal density is medium or high, a second layer of latch is established. Based on the Cron timer task, the data of the first layer of latch is periodically aggregated and analyzed to extract signals that meet the confidence threshold and promote them to the shared knowledge layer. For example, when the feedback signal density is "medium" or "high," the system automatically configures a Cron scheduled task (e.g., executed daily at 3 AM) to periodically scan and aggregate the data in the first-level latch. Specifically, the system statistically analyzes the frequency of occurrence of various types of feedback signals (e.g., correction, discrimination, confusion, etc.), calculates the signal confidence score, and extracts signals with scores higher than a preset threshold (e.g., 0.7) and elevates them to the shared knowledge layer. For instance, in procurement contract analysis, if multiple users submit corrections (correction signals) to the "price benchmark" data over several consecutive days, the system automatically aggregates these signals, elevates the corrected price benchmark to shared knowledge, and makes it available for use by all subsequent sessions.

[0063] S23. When the architecture has three layers, a third-layer latch is established. Based on the principle of "reading signals but not recording signals", a one-way signal reading channel is established between the metacognitive control layer and the knowledge evolution layer to prevent evaluation signals from being mistakenly recorded as business data. The first-layer latch provides raw data for the second-layer latch, and the output of the second-layer latch is read by the metacognitive control layer through the unidirectional channel of the third-layer latch. The three-layer latch constitutes a complete latch chain from data acquisition, signal analysis to knowledge consumption.

[0064] For example, in a three-tier architecture, the system establishes a one-way signal reading channel between the harness layer and the memory layer. The memory layer can read evaluation signals generated by the harness layer (such as user satisfaction ratings, task completion rates, etc.), but the harness layer cannot write these evaluation signals into the business data table of the memory layer. This design prevents evaluation signals from being mistakenly recorded as business data, ensuring that the knowledge base stores objective facts rather than subjective evaluations. For instance, if a user gives a "dissatisfied" evaluation signal for a procurement analysis report, this signal can be read by the memory layer to improve the analysis algorithm, but it will not be written into the business_data table as a basis for procurement decisions.

[0065] The three-layer latching mechanism constitutes a complete data acquisition → signal analysis → knowledge consumption chain. For example, in a procurement contract analysis scenario: the first layer persists the interaction records of each procurement query in SQLite (data acquisition); the second layer uses Cron tasks to analyze feedback signals daily, elevating high-confidence price adjustments to shared knowledge (signal analysis); the third layer, a one-way channel, ensures that the harness layer can read the shared knowledge when making procurement recommendations, but will not mistakenly record user satisfaction ratings as procurement data (knowledge consumption).

[0066] Example 3 The construction of the four-dimensional closed-loop data flow architecture described in step S2 specifically includes: S31. First dimension: Core business data flows from the data perception layer to the knowledge evolution layer for persistent storage. S32. The second dimension is that business knowledge flows from the knowledge evolution layer to the metacognitive control layer, and is used for business judgment and decision-making. S33. The third dimension is that user preferences flow from the knowledge evolution layer to the metacognitive control layer, which is used for personalized behavior tailoring. S34. Fourth dimension: Agent behavior feedback flows back from the metacognitive control layer to the knowledge evolution layer, triggering incremental updates to the knowledge evolution pipeline; In the four-dimensional closed loop, if the data flow in any dimension is interrupted, it will automatically degrade to a three-dimensional or two-dimensional closed loop mode.

[0067] As one embodiment, the four-dimensional closed-loop data flow architecture in step S2 of the present invention is specifically implemented as follows: S31: First Dimension – Business Data Flow. The data perception layer is responsible for obtaining raw data from external data sources. After parsing and standardization, the data flows to the knowledge evolution layer (memory layer) for persistent storage. Specifically, the perception layer calls the connectors generated in step S8 (such as database connectors, REST connectors, and file parsing connectors) to obtain data, converts the data into a unified format, and writes it to the core business data table in the memory layer. For example, in procurement contract analysis, the perception layer obtains purchase order data through the SAP database connector, market index data through the CCI index API connector, and extracts contract text through the PDF parsing connector. All data is standardized and then written to the business_data table in the memory layer.

[0068] S32: Second Dimension – Business Knowledge Flow. The knowledge evolution layer flows verified and accumulated business knowledge to the metacognitive control layer (harness layer) for business judgment and decision-making. Specifically, the memory layer extracts high-confidence business knowledge (such as "the historical average price of supplier A is X yuan") from the business_data table and transmits it to the harness layer through a two-way data flow channel. The harness layer uses this knowledge as a basis for decision-making. For example, in procurement contract analysis, after receiving "the historical average price of supplier A" and "the current market CCI index," the harness layer comprehensively judges whether the current price is reasonable.

[0069] S33: The Third Dimension – User Preference Flow. The knowledge evolution layer directs user preference data to the metacognitive control layer for personalized behavior tailoring. Specifically, the memory layer maintains the `user_preferences` table, recording each user's query habits, areas of interest, and historical interaction preferences. The harness layer reads this preference data and dynamically adjusts the depth and presentation of behaviors. For example, if a purchasing manager prefers chart-based presentation, the harness layer will automatically render the data as a chart instead of a table when generating a purchasing analysis report.

[0070] S34: The Fourth Dimension – Agent Behavior Feedback Flow. Agent behavior feedback flows back from the metacognitive control layer to the knowledge evolution layer, triggering incremental updates in the knowledge evolution pipeline. Specifically, evaluation signals generated by the harness layer during task execution (such as task execution logs, user satisfaction, error rates, etc.) are written to the feedback_signals table in the memory layer through the feedback channel, triggering the update process of the knowledge evolution pipeline (such as the knowledge dimension re-evaluation in step S3, the scheduled task adjustment in step S5, etc.). For example, if the harness layer repeatedly returns low-confidence results in the "price benchmark query" task, this feedback signal, after flowing back to the memory layer, triggers the knowledge evolution pipeline to re-evaluate the external benchmark dimension and add new data sources.

[0071] The four-dimensional closed-loop automatic degradation mechanism: When the data flow in any dimension is interrupted due to network failure, database anomaly, or other reasons, the system automatically detects and degrades its operation. For example, if the second dimension (business knowledge flow) is interrupted, the harness layer cannot obtain business knowledge from the memory layer, and the system automatically degrades to the three-dimensional mode—the harness layer directly calls the perception layer to obtain the raw data, skipping the knowledge accumulation stage, ensuring that the core query function is available. If the first and third dimensions are interrupted simultaneously, the system degrades to the two-dimensional mode—only the Agent behavior feedback flow is retained, and the harness layer writes the execution log to the memory layer, and knowledge accumulation is carried out uniformly after the data flow is restored.

[0072] Example 4 The complexity scoring algorithm described in step S2 specifically includes: a weighted summation based on eight dimensions: number of data sources, existence of unstructured data or attachments, external data verification requirements, existence of deep analysis interactions, cross-session memory requirements, knowledge timeliness dependence, feedback signal density, and parallel execution requirements, to obtain a complexity score; when the score is lower than or equal to 3 points, the system routes to a single-skill architecture; when the score is between 4 and 6 points, the system routes to a two-layer architecture; and when the score is higher than or equal to 7 points, the system routes to a three-layer architecture.

[0073] As one embodiment, the complexity scoring algorithm in step S2 of the present invention is as follows: The scoring rules for the eight dimensions are shown in Table 1: Table 1 Scoring Rules

[0074] Example of scoring calculation: Procurement contract analysis area: 3 data sources (+3 points), including unstructured attachments (+2 points), requiring external verification (+2 points), requiring in-depth analysis (+2 points), requiring cross-session memory (+1 point), having timeliness (+1 point), high feedback density (+1 point), requiring parallelism (+1 point), total score = 13 points ≥ 7 points → three-tier architecture.

[0075] Equipment maintenance and management: 3 data sources (+3 points), including semi-structured records (+2 points), no external verification required (+0 points), in-depth diagnostics (+2 points), cross-session memory required (+1 point), time-sensitive (+1 point), medium feedback density (+0 points), parallelism required (+1 point), total score = 10 points ≥ 7 points → three-tier architecture.

[0076] Simple FAQ domain: 1 data source (+0 points), no attachments (+0 points), no external verification required (+0 points), no in-depth analysis (+0 points), no cross-session memory required (+0 points), no timeliness (+0 points), low feedback density (+0 points), no parallelism required (+0 points), total score = 0 points ≤ 3 points → single skill architecture.

[0077] The principle of threshold setting in this invention is as follows: a score of 0-3 points corresponds to a single data source and a scenario without complex processing requirements, in which a single-skill architecture is sufficient; a score of 4-6 points corresponds to a medium-complexity scenario, which requires the addition of a memory or perception layer but does not need to have all three; a score of 7 points or above corresponds to a complex scenario with multiple heterogeneous sources and a need for complete knowledge evolution capabilities, in which a three-layer architecture can provide complete metacognitive control, knowledge evolution, and data perception capabilities.

[0078] Example 5 The phased knowledge base command-line tool described in step S7 uses a directed acyclic graph to manage the execution dependencies between commands, specifically including: S71. Label the set of preceding commands that each command depends on, and construct a directed acyclic graph of command dependencies; S72. Determine the topological execution order of each command based on the directed acyclic graph; S73. When a user executes any command, the system automatically checks whether all its dependent commands have been executed. If not, it automatically executes the dependent commands in the topological order. S74 generates 20 commands in stages. The first stage generates basic commands including database initialization, health reporting, feedback signal management, data querying, configuration management, and field registration. The second stage generates extraction commands including field extraction requirement analysis, extraction result writing, attachment text extraction, and dependency checking. The third stage generates summary commands including knowledge distillation prompt word construction and distillation result writing. The fourth stage generates enhancement commands including personal knowledge upgrade prompt word construction and upgrade result writing. The fifth stage generates orchestration and maintenance commands including execution plan generation, extraction plan generation, evidence set verification, expired knowledge marking, field conflict detection, and missing extraction detection. Each stage is appended by reading the generated files and inserting new commands into the parameter parser and command dispatch table.

[0079] As one embodiment, the command-dependent DAG in step S7 of the present invention is specifically implemented as follows: S71: Dependency Annotation. Each command is annotated with the set of preceding commands it depends on when it is generated. For example, the dependency declaration of the extract-apply command is depends_on=["extract"], which means that extract must be executed before extract-apply can be executed; the dependency of summarize-apply is depends_on=["summarize-session"]; and the dependency of promote-apply is depends_on=["promote-shared"].

[0080] S72: Topology Sort. The system automatically constructs a Directed Acyclic Graph (DAG) based on the dependencies of all commands and calculates the topology execution order. For example, if the command dependencies are: extract → extract-apply, summarize-session → summarize-apply, promote-shared → promote-apply, and workflow-plan depends on extract and summarize-session, the topology sort result is: init → schema → extract → extract-apply → summarize-session → summarize-apply → promote-shared → promote-apply → workflow-plan.

[0081] S73: Automatic Dependency Detection and Execution. When a user executes any command, the system automatically checks whether all its dependent commands have been executed. For example, if a user directly executes `extract-apply`, the system detects that `extract` has not yet been executed, automatically executes `extract` first, and then executes `extract-apply` after `extract` has successfully executed. If a dependent command fails to execute, the system reports an error and terminates the execution of the current command.

[0082] S74: Staged append generation. 20 commands are generated in 5 stages. Each stage appends commands by reading already generated files and inserting them into the argparse parser and command dispatch table. Phase 0 (Basic Commands): init, report, feedback, query-data, config, schema; Phase 1 (Extraction commands): extract, extract-apply (depending on extract), text-extract, text-check; Phase 2 (summary commands): summarize-session, summarize-apply (depends on summarize-session); Phase 3 (promotion commands): promote-shared, promote-apply (depends on promote-shared); Phase 4 (Organization + Maintenance Commands): workflow-plan, workflow-query, benchmark-check, staleness-check, consistency-check, backfill; For example, in a procurement contract analysis scenario, users need to execute a complete knowledge extraction and summarization process. The user executes the command `python knowledge_db.py workflow-plan --project=procurement optimization-2026`. The system first checks the dependency chain of `workflow-plan`: `workflow-plan` depends on `extract` and `summarize-session`. `extract` has no dependencies and can be executed directly, while `summarize-session` depends on `extract`. The system executes the following in topological order: `extract` (extracts procurement contract fields) → `summarize-session` (performs knowledge distillation on the extracted results) → `workflow-plan` (generates the execution plan). The entire execution process is transparent to the user; the user only needs to issue a single command to complete the execution of the complete dependency chain.

[0083] Example 6 The generation of the unified degradation infrastructure module in step S8 specifically includes: S811, Generate feedback signal storage component, based on SQLite to persist degradation events to feedback signal table, record three types of events: failure events, degradation events and recovery events; S812, Generate a degraded cache component to cache successful request results locally, including time-to-live expiration management and hash key deduplication; S813: Generate a failure tracking component, based on SQLite persistent cross-session continuous failure counter, using parameterized thresholds, with a default of triggering degradation after 3 consecutive failures; S814. Generate a central degradation manager to coordinate the feedback signal storage component, degradation cache component, and failure tracking component, and provide a unified degradation interface; All downgraded data is labeled with a downgrade identifier, data age in days, reason for downgrade, and cache time field.

[0084] As one embodiment, the unified degradation infrastructure module in step S8 of the present invention is specifically implemented as follows: S811: Feedback SignalsStore. It persists degradation events to the `feedback_signals` table using SQLite. This table contains the following fields: `signal_id` (primary key), `signal_type` (for failure, degradation, and recovery events), `source_connector` (name of the connector that caused the degradation), `timestamp` (event occurrence time), `error_message` (error message), and `stack_trace` (stack trace). For example, when the REST connector fails to make three consecutive requests to the CCI index API, the system records an event with `signal_type` "failure"; when the system successfully switches to the local cache, it records a "degradation" event; and when the API recovers, it records a "recovery" event.

[0085] S812: FallbackCache component. It caches successful request results locally, including TTL (Time-to-Live) expiration management and hash key deduplication. The cache key is the hash value of the request parameters (e.g., the API request URL + MD5 hash of the parameters), and the cache value is the successful response result. The default TTL is 300 seconds (5 minutes), which can be parameterized. For example, the first successful request result for the CCI index API is cached with the MD5 hash of "cci_index_2026_Q2" as the key and the index data JSON as the value, with a TTL of 300 seconds. Within 5 minutes, identical requests directly return the cached result to avoid duplicate requests.

[0086] S813: Failure Tracking Component (FailureTracker). Based on SQLite, it persists a cross-session consecutive failure counter. This component maintains a `failure_count` table containing fields such as `connector_name`, `failure_count`, `last_failure_time`, and `reset_time`. The default threshold is three consecutive failures to trigger degradation, and this threshold can be parameterized. For example, if the REST connector fails on the first request to the CCI index API → `failure_count=1`; fails on the second → `failure_count=2`; fails on the third → `failure_count=3`, reaching the threshold → triggering degradation. If a request succeeds, `failure_count` is automatically reset to 0.

[0087] S814: Central Fallback Manager. Coordinates the above three components and provides a unified fallback interface. When a connector initiates a request, the execution flow of FallbackManager is as follows: (1) Call FailureTracker to check if the connector is in a fallback state; (2) If it is in a fallback state, directly call FallbackCache to return the cached result; (3) If it is not in a fallback state, execute the actual request; (4) If the request is successful, update FallbackCache and reset FailureTracker; (5) If the request fails, update FailureTracker, and if the threshold is reached, trigger fallback; (6) All events are persisted through FeedbackSignalsStore.

[0088] Degraded data annotation: All degraded data is annotated with the following fields: degraded=true (indicating that the data is degraded), data_age_days (data age in days, such as cached data generated 3 days ago), fallback_reason (degradation reason, such as "API failed 3 times in a row"), and cached_at (cache timestamp).

[0089] In a procurement contract analysis scenario, the CCI index API failed three consecutive requests due to a network failure. The FailureTracker recorded the failure count as reaching the threshold of 3, triggering a degradation. The FallbackManager automatically switched to the FallbackCache, returning the most recently successfully cached CCI index data (marked with degraded=true, data_age_days=2, fallback_reason="API failed 3 times consecutively", cached_at="2026-06-28 10:00:00"). The FeedbackSignalsStore recorded the degradation event. Two hours later, the API recovered, the next request succeeded, the FailureTracker was reset to 0, and the FeedbackSignalsStore recorded the recovery event.

[0090] Example 7 Step S8, which involves automatically generating corresponding type of perception layer connector skeleton code for each data source, specifically includes: S821. Traverse the data source array of the data source dimension in the feature vector, and route to the corresponding connector template according to the type field of each data source. When the type is an application programming interface, route to the REST connector template; when the type is a database, route to the database query connector template; when the type is a document, route to the file parsing connector template. S822. For REST connector templates, generate connector classes that include unified request interfaces, parsing interfaces, caching interfaces, and status interfaces. It has built-in two authentication modes: bearer token and cookie, pagination logic with parameterized page size, a three-stage exponential backoff retry mechanism, and four error categories: authentication errors, network errors, parsing errors, and rate limiting errors. It also has a built-in adaptive degradation mechanism. S823. For the database query connector template, generate a connector class that includes a query interface, a result caching interface, and a cache retrieval interface. It has built-in read-only query enforcement that prohibits data manipulation languages, a result caching mechanism with time-to-live parameterization, a parameterized query anti-SQL injection mechanism, and an adaptive degradation mechanism. S824. For the file parsing connector template, generate a connector class that includes a format detection interface, a text extraction interface, and a metadata acquisition interface. It has built-in automatic detection of PDF, DOCX, and XLSX formats, text extraction and extraction caching mechanisms, and an adaptive degradation mechanism.

[0091] As one embodiment, the generation of the perception layer connector skeleton code in step S8 of the present invention is specifically as follows: S821: Data source type routing. The system iterates through the data_sources array of domain feature vectors and routes to the corresponding connector template based on the type field of each data source.

[0092] S822: REST connector generation. The generated REST connector class contains the following core interfaces: fetch(params): Initiates an HTTP request, supporting GET / POST methods, with built-in bearer and cookie authentication modes; parse(response): Parses the JSON / XML response and extracts the target data fields; cache(result): Writes the successful result to the FallbackCache; status(): Returns the connector health status (normal / degraded / failed); The pagination logic is controlled by the `page_size` parameter, supporting both page number-based and cursor-based pagination modes. The retry mechanism employs an exponential backoff strategy: after the first failure, it waits 1 second before retrying; after the second failure, it waits 2 seconds before retrying; and after the third failure, it waits 4 seconds before retrying. Error categories include: `auth` (authentication failure, such as token expiration), `network` (network timeout or connection refused), `parse` (response parsing failure), and `rate_limit` (rate limit, such as 429 status code).

[0093] S823: Database query connector generation. The generated database query connector class contains the following core interfaces: query(sql, params): Executes a read-only query, forcibly checking whether the SQL statement contains INSERT / UPDATE / DELETE statements; if it does, an exception is thrown. cache_result(sql, result): Caches the query results, with TTL parameterized (default 300 seconds); get_cached(sql): Retrieves the cached result; returns None if the cache has expired. Query parameterization uses the '?' placeholder to prevent SQL injection attacks. For example: query("SELECT ... FROM purchase_orders WHERE supplier = ?", ["Supplier A"]).

[0094] S824: File parsing connector generation. The generated file parsing connector class contains the following core interfaces: detect_format(file_path): Detects file format (PDF / DOCX / XLSX) by file extension and magic number. extract_text(file_path): Extracts the text content of a file. For PDFs, use pypdf or pdfplumber; for DOCXs, use python-docx; and for XLSXs, use openpyxl. get_metadata(file_path): Extracts file metadata (author, creation time, number of pages, etc.); Extraction caching mechanism: Generate hash keys for parsed files, cache extraction results, and avoid repeatedly parsing large files.

[0095] In the procurement contract analysis scenario, the system generates three connectors: (1) cci_rest_connector.py — connects to the CCI index API, uses bearer authentication (token is read from config.py), page_size=100, 3 index backoff retries, and after 3 consecutive failures, it is downgraded to the local cache; (2) sap_db_connector.py — Connects to the SAP purchasing system database, performs read-only queries on the purchase_orders table, TTL=600 seconds (10 minutes), parameterized queries prevent SQL injection; (3) contract_file_connector.py — Parses contract PDF attachments, automatically detects PDF format, extracts full text, and caches the extraction results (the hash key is the MD5 of the file path).

[0096] Example 8 Step S9, which involves converting the decision log from a flat structure to a directed acyclic graph structure, specifically includes: S91. Treat each decision as a node. Each node contains a node identifier, a parent node identifier, a depth field, and a type field. The root node has a depth of 0, the step node has a depth of 1, and the specific decision node has a depth of 2 to 4. S92. Automatically assign parent node identifier and depth based on node identifier prefix mapping rules; S93. Perform three integrity checks on the constructed directed acyclic graph: depth constraint check, connectivity check, and acyclicity check. S94. Supports tracing back from any decision node along the parent node identifier link to the root node, generating a complete decision reasoning chain for interpretability analysis.

[0097] As one embodiment, the generation of the decision log DAG structure in step S9 of the present invention is as follows: S91: Decision Node Modeling. Each decision node contains the following fields, see Table 2: Table 2 Field Descriptions

[0098] The root node ROOT has a depth of 0 and a type of "root"; the step nodes (S2-S8) have a depth of 1 and a type of "stage"; the specific decision nodes (D-001, E-001, etc.) have a depth of 2-4 and a type of "decision".

[0099] S92: Automatic DAG Construction. The system reads the flat decision log (decisions.json) from steps S2-S8 and automatically assigns parent_id and depth according to the id prefix mapping rules (see Table 3): Table 3 Mapping Rules

[0100] Dependencies between steps: S3 depends on S2, S4 depends on S2, S5 depends on S3+S4, S7 depends on S2-S5, S8 depends on S1, and S9 depends on S2-S8.

[0101] S93: DAG Integrity Verification. The system performs three verifications on the constructed DAG: Depth limit check: Maximum depth does not exceed 5 layers. If the depth of a node is greater than 5, the system will issue an alarm and adjust the parent node allocation.

[0102] Connectivity check: All nodes are reachable from the ROOT. If an isolated node is found, the system will issue an alarm and automatically connect to the ROOT.

[0103] Cycle check: No circular dependencies exist. If a cycle is detected (e.g., A→B→C→A), the system will issue an alert and indicate the conflicting dependency.

[0104] S94: Reverse Tracing. Starting from any decision node, trace back along the parent_id link to ROOT to generate a complete decision reasoning chain. For example, starting from node E-003 (confidence model selection): E-003→E-001 (knowledge dimension decision)→S3→D-001 (complexity score)→S2→ROOT, fully demonstrating the decision path from complexity score to confidence model selection.

[0105] In the field of procurement contract analysis, decisions_dag.json contains 18 nodes with a maximum depth of 5 layers. Tracing back from node E-003 "Confidence Model Selection" (selecting a mixed confidence model with a structured weight of 0.6): E-003 → E-001 (Knowledge Dimension Decision: Selecting a 5-dimensional solution) → S3 (Knowledge Evolution Pipeline Generation Step) → D-001 (Complexity Score: 13 points) → S2 (Topology Generation Step) → ROOT. The complete decision reasoning chain is: Domain Features → Complexity Score 13 points → Three-layer Architecture → 5-dimensional Knowledge Evolution Pipeline → Mixed Data Source → Mixed Confidence Model (structured weight 0.6). This reasoning chain can be used for auditing and interpretability analysis, helping users understand why the system selected a specific confidence model.

[0106] Example 9 Please see Figure 2 , Figure 2 This is a schematic diagram of the hardware device in operation according to an embodiment of the present invention. The hardware device specifically includes: a domain-adaptive skill group generation device 401 for large language model agents, a processor 402, and a storage medium 403.

[0107] A domain-adaptive skill set generation device 401 for large language model agents: The device 401 implements the domain-adaptive skill set generation method for large language model agents.

[0108] Processor 402: The processor 402 loads and executes the instructions and data in the storage medium 403 to implement the domain-adaptive skill group generation method for large language model agents.

[0109] Storage medium 403: The storage medium 403 stores instructions and data; the storage medium 403 is used to implement the domain adaptive skill group generation method for large language model agents.

[0110] Example 10 To verify the technical effectiveness of the present invention, two sets of experimental data from the fields of procurement contract analysis and equipment maintenance management were used to verify the method of the present invention.

[0111] The experimental setup is as follows: 1. Experimental Environment: Hardware: Intel Xeon Gold 6248 CPU @ 2.50GHz × 2, 256GB RAM, NVIDIA Tesla V100 GPU × 1; Software: Python 3.10, SQLite 3.38, Ubuntu 22.04 LTS; LLM Backend: Qwen-72B-Chat (for Agent inference). 2. Experimental dataset, see Table 4: Table 4 Dataset

[0112] 3. Evaluation indicators: Architecture generation accuracy: consistency between the generated skill group architecture (single-layer / two-layer / three-layer) and the annotations by human experts; Configuration integrity: The integrity rate of key components (latch mechanism, closed-loop data flow, scheduled tasks, etc.) in the generated configuration file; Code Executability: The success rate of the first execution of the generated code infrastructure (CLI commands, linkers); End-to-end time: The total time from feature vector input to complete skill set output; 4. Experimental results, see Table 5: Table 5 Experimental Results

[0113] 5. Ablation test To verify the effectiveness of the core features of this invention, ablation experiments were conducted on dataset A, as shown in Table 6: Table 6 Ablation Experiment

[0114] Ablation experiment analysis: (1) The four-dimensional closed-loop data flow has the greatest impact on the accuracy of architecture generation (it dropped from 96.0% to 78.0% after removal), indicating that the automatic deduction of the data flow direction is a key factor in determining the rationality of the architecture. Without the definition of four-dimensional closed loop, the system cannot accurately determine the data dependencies between layers.

[0115] (2) The three-layer progressive latch has the greatest impact on configuration integrity (removed from 98.0% to 80.0%), indicating that the latch mechanism is a core component of the knowledge evolution pipeline. The absence of latch will lead to the inability to realize knowledge accumulation and cross-session memory functions.

[0116] (3) The command dependency DAG has the greatest impact on code executable rate (it dropped from 94.0% to 72.0% after removal), indicating that the management of dependencies between commands is crucial to the usability of the generated code. Without DAG management, users frequently fail to execute dependent commands due to the lack of prior data.

[0117] (4) The adaptive degradation of the connector also has a significant impact on the code executable rate (it dropped from 94.0% to 76.0% after removal), indicating that in the actual network environment, the fault tolerance capability of the connector directly affects the first execution success rate of the generated code.

[0118] (5) The decision log DAG has a relatively small impact on the three indicators, but its value is mainly reflected in interpretability and audit traceability, rather than direct technical performance indicators.

[0119] 6. Comparative experiments with artificially designed experiments are shown in Table 7: Table 7 Comparative Experiments

[0120] Experimental results show that the method of this invention, while ensuring high accuracy and completeness, reduces the design time of skill groups from 2-3 weeks to just a few minutes, significantly improving design efficiency. Furthermore, the decision log DAG provides complete traceability capabilities for technical decisions, which is difficult to achieve systematically through manual design.

[0121] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A domain-adaptive skill set generation method for large language model proxies, characterized in that: Includes the following steps, S1. Receive feature vector input from the target domain. The feature vector contains structured description information of data source dimension, interaction mode dimension, knowledge feature dimension, quality requirement dimension and execution feature dimension. S2. Based on the feature vector, a complexity score is calculated using a complexity scoring algorithm. The architectural hierarchy of the skill group is determined through decision tree routing based on the score. When the score is below a first threshold, a single-skill architecture is selected. When the score is between the first and second thresholds, a two-layer architecture is selected and the second-layer role is determined. When the score is above the second threshold, a three-layer architecture including a metacognitive control layer, a knowledge evolution layer, and a data perception layer is selected. The data flow direction is derived based on the dependencies between the determined roles at each layer, where the data flow between the metacognitive control layer and the knowledge evolution layer is bidirectional, thus constructing a four-dimensional closed-loop data flow architecture. The progressive latch hierarchy is determined based on cross-session requirements, feedback signal density, and architectural hierarchy. S3. Based on the feature vector and the architecture hierarchy determined in step S2, automatically deduce the number of dimensions of the knowledge evolution pipeline, generate corresponding database table structures and index definitions for each dimension, and select the corresponding confidence evaluation model according to the structured nature of the data source. S4. Based on the skill group architecture hierarchy determined in step S2 and the database table structure features generated in step S3, automatically configure adaptive behavior depth control logic, including evaluation dimension selection, depth level definition, and action clipping strategy corresponding to each depth level. S5. Based on the skill group architecture hierarchy determined in step S2, the knowledge evolution pipeline configuration generated in step S3, and the adaptive behavior configuration generated in step S4, automatically generate a scheduled task blueprint, including task type selection and frequency calculation. Scheduled tasks are not generated for single skill architectures. S6. Output the generation results of steps S2 to S5 as a skill group project file containing skill group topology configuration, knowledge evolution pipeline configuration, adaptive behavior configuration and timed task blueprint. S7. Based on the skill group project file output in step S6, automatically generate a runnable code infrastructure, including a shared configuration module, a database initialization script, a phased knowledge base command line tool, and a project management command line tool, wherein the phased knowledge base command line tool uses a directed acyclic graph to manage the execution dependencies between commands. S8. Based on the feature description of the data source dimension in step S1, automatically generate the corresponding type of perception layer connector skeleton code for each data source, and generate the connector registry and unified degradation infrastructure module. S9. Convert the decision logs generated in steps S2 to S8 from a flat structure to a directed acyclic graph structure, perform integrity verification, and output the directed acyclic graph of decision logs.

2. The domain-adaptive skill set generation method for large language model proxies as described in claim 1, characterized in that, The determination of the progressive latch level in step S2 specifically includes: S21. When cross-session memory is required, establish the first-level latch and persist all interaction records and signal data of the current session based on the SQLite database. S22. When the feedback signal density is medium or high, a second layer of latch is established. Based on the Cron timer task, the data of the first layer of latch is periodically aggregated and analyzed to extract signals that meet the confidence threshold and promote them to the shared knowledge layer. S23. When the architecture has three layers, a third-layer latch is established. Based on the principle of reading signals but not recording signals, a one-way signal reading channel is established between the metacognitive control layer and the knowledge evolution layer to prevent evaluation signals from being mistakenly recorded as business data. The first-layer latch provides raw data for the second-layer latch, and the output of the second-layer latch is read by the metacognitive control layer through the unidirectional channel of the third-layer latch. The three-layer latch constitutes a complete latch chain from data acquisition, signal analysis to knowledge consumption.

3. The domain-adaptive skill set generation method for large language model proxies as described in claim 1, characterized in that, The construction of the four-dimensional closed-loop data flow architecture described in step S2 specifically includes: S31. First dimension: Core business data flows from the data perception layer to the knowledge evolution layer for persistent storage. S32. The second dimension is that business knowledge flows from the knowledge evolution layer to the metacognitive control layer, and is used for business judgment and decision-making. S33. The third dimension is that user preferences flow from the knowledge evolution layer to the metacognitive control layer, which is used for personalized behavior tailoring. S34. Fourth dimension: Agent behavior feedback flows back from the metacognitive control layer to the knowledge evolution layer, triggering incremental updates to the knowledge evolution pipeline; In the four-dimensional closed loop, if the data flow in any dimension is interrupted, it will automatically degrade to a three-dimensional or two-dimensional closed loop mode.

4. The domain-adaptive skill set generation method for large language model proxies as described in claim 1, characterized in that, The complexity scoring algorithm described in step S2 specifically includes: a weighted summation based on eight dimensions: number of data sources, existence of unstructured data or attachments, external data verification requirements, existence of deep analysis interactions, cross-session memory requirements, knowledge timeliness dependence, feedback signal density, and parallel execution requirements, to obtain a complexity score. When the score is 3 or lower, the route is to a single-skill architecture; when the score is between 4 and 6, the route is to a two-tier architecture; and when the score is 7 or higher, the route is to a three-tier architecture.

5. The domain-adaptive skill set generation method for large language model proxies as described in claim 1, characterized in that, The phased knowledge base command-line tool described in step S7 uses a directed acyclic graph to manage the execution dependencies between commands, specifically including: S71. Label the set of preceding commands that each command depends on, and construct a directed acyclic graph of command dependencies; S72. Determine the topological execution order of each command based on the directed acyclic graph; S73. When a user executes any command, the system automatically checks whether all its dependent commands have been executed. If not, it automatically executes the dependent commands in the topological order. S74. Generate 20 commands in stages. The first stage generates basic commands including database initialization, health reporting, feedback signal management, data querying, configuration management, and field registration. The second stage generates extraction commands including field extraction requirement analysis, extraction result writing, attachment text extraction, and dependency checking. The third stage generates summary commands including knowledge distillation prompt word construction and distillation result writing. The fourth stage generates enhancement commands including personal knowledge upgrade prompt word construction and upgrade result writing. The fifth stage generates orchestration and maintenance commands including execution plan generation, extraction plan generation, evidence set verification, expired knowledge marking, field conflict detection, and missing extraction detection. Each stage appends to the generated files by reading them and inserting new commands into the parameter parser and command dispatch table.

6. The domain-adaptive skill set generation method for large language model proxies as described in claim 1, characterized in that: The generation of the unified degradation infrastructure module in step S8 specifically includes: S811, Generate feedback signal storage component, based on SQLite to persist degradation events to feedback signal table, record three types of events: failure events, degradation events and recovery events; S812, Generate a degraded cache component to cache successful request results locally, including time-to-live expiration management and hash key deduplication; S813: Generate a failure tracking component, based on SQLite persistent cross-session continuous failure counter, using parameterized thresholds, with a default of triggering degradation after 3 consecutive failures; S814. Generate a central degradation manager to coordinate the feedback signal storage component, degradation cache component, and failure tracking component, and provide a unified degradation interface; All downgraded data is labeled with a downgrade identifier, data age in days, reason for downgrade, and cache time field.

7. The domain-adaptive skill set generation method for large language model proxies as described in claim 1, characterized in that: Step S8, which involves automatically generating corresponding type of perception layer connector skeleton code for each data source, specifically includes: S821. Traverse the data source array of the data source dimension in the feature vector, and route to the corresponding connector template according to the type field of each data source. When the type is an application programming interface, route to the REST connector template; when the type is a database, route to the database query connector template; when the type is a document, route to the file parsing connector template. S822. For REST connector templates, generate connector classes that include unified request interfaces, parsing interfaces, caching interfaces, and status interfaces. It has built-in two authentication modes: bearer token and cookie, pagination logic with parameterized page size, a three-stage exponential backoff retry mechanism, and four error categories: authentication errors, network errors, parsing errors, and rate limiting errors. It also has a built-in adaptive degradation mechanism. S823. For the database query connector template, generate a connector class that includes a query interface, a result caching interface, and a cache retrieval interface. It has built-in read-only query enforcement that prohibits data manipulation languages, a result caching mechanism with time-to-live parameterization, a parameterized query anti-SQL injection mechanism, and an adaptive degradation mechanism. S824. For the file parsing connector template, generate a connector class that includes a format detection interface, a text extraction interface, and a metadata acquisition interface. It has built-in automatic detection of PDF, DOCX, and XLSX formats, text extraction and extraction caching mechanisms, and an adaptive degradation mechanism.

8. The domain-adaptive skill set generation method for large language model proxies as described in claim 1, characterized in that: Step S9, which involves converting the decision log from a flat structure to a directed acyclic graph structure, specifically includes: S91. Treat each decision as a node. Each node contains a node identifier, a parent node identifier, a depth field, and a type field. The root node has a depth of 0, the step node has a depth of 1, and the specific decision node has a depth of 2 to 4. S92. Automatically assign parent node identifier and depth based on node identifier prefix mapping rules; S93. Perform three integrity checks on the constructed directed acyclic graph: depth constraint check, connectivity check, and acyclicity check. S94. Supports tracing back from any decision node along the parent node identifier link to the root node, generating a complete decision reasoning chain for interpretability analysis.

9. A domain-adaptive skill set generation device for large language model proxies, characterized in that: include: A processor and a storage medium; the processor loads and executes instructions and data in the storage medium to implement the domain-adaptive skill group generation method for large language model agents as described in any one of claims 1 to 8.

Images