Structured identity-based intelligent agent and enterprise multi-domain collaboration system and method

Abstract

This invention provides an intelligent agent and enterprise multi-domain collaboration system and method based on structured identity, employing a client-server architecture. The server defines the intelligent agent employee identity using eight elements (responsibility text, response boundaries, model parameters, knowledge base scope, tool permissions, memory level, risk level, and action confirmation rules), clearly defining boundaries and constraints. The system implements hierarchical multi-domain memory management in the organizational memory table through hierarchical and status fields, automatically filtering pending confirmation status memories. The system establishes a dual-track quota architecture with parallel global and group authorization, enabling independent quota calculation for token resources; it decouples management permissions from data permissions through a role-based access control model, achieving a three-tiered permission system with five communication levels and group visibility. This invention achieves enterprise-level refined configuration of intelligent employees, memory isolation, multi-dimensional permission control, and a closed-loop security confirmation mechanism.

Description

Technical Field

[0001] This invention relates to the field of enterprise intelligent collaboration technology, specifically to an intelligent agent based on structured identity and an enterprise multi-domain collaboration system and method. Background Technology

[0002] With the rapid development of Large Language Model (LLM) technology, embedding artificial intelligence capabilities into daily enterprise operations and collaborative processes has become an important direction for digital transformation. Currently, various enterprise-level AI-assisted systems have emerged in the industry. However, existing systems reveal systemic flaws in their architectural design and governance mechanisms. The root cause lies in a fundamental misconception of "enterprise-level AI," namely, that AI is still positioned as a stateless question-and-answer tool, rather than a virtual collaborative intelligent agent constrained by an enterprise governance framework. Specific flaws are as follows: First, AI role definitions are crude and lack a structured configuration framework. Existing systems rely solely on natural language descriptions of system prompts or simple label classifications to characterize AI roles, resulting in blurred behavioral boundaries. A complete intelligent agent function should be defined by multiple dimensions, including scope of responsibility, response boundaries, model parameters, knowledge base access scope, tool permissions, memory levels, risk levels, and action confirmation rules. However, existing technologies have not established any multi-element structured configuration system. Furthermore, when enterprises deploy multiple specialized AIs, the system lacks the ability to automatically route and orchestrate cross-domain collaboration based on user intent. Users must manually determine which AI to ask a question to, leading to low collaboration efficiency.

[0003] Second, memory management lacks hierarchical isolation and credibility filtering. Existing systems mix and store information from different conversation scenarios in a unified memory space. Retrieval is based solely on surface relevance without considering the access boundaries of the information source. This leads to cross-domain leakage risks, such as AI referencing private memories in group chats or referencing confidential discussions from other departments in departmental groups. Furthermore, the system indiscriminately persists all conversation history without establishing access control rules based on memory state. This means that unverified or erroneous information, once in the memory, may be cited as fact by AI, severely damaging the credibility of AI as an enterprise information hub.

[0004] Third, automated execution lacks mandatory human confirmation. Existing systems either rely entirely on manual copying and pasting of AI suggestions or on fully automated execution of business operations, lacking a secure intermediate layer of "action draft generation → multi-dimensional verification → human confirmation → formal execution." In high-risk operational scenarios, existing systems cannot force manual approval without significantly sacrificing the smoothness of collaboration. Furthermore, AI-generated visual content commonly suffers from deterministic errors such as garbled text and distorted logos, and lacks the ability to accurately synthesize and format the AI-generated "ambience and background" with brand assets locally on the server.

[0005] Fourth, the access control system suffers from architectural flaws. The token consumption for AI calls directly corresponds to economic costs, and existing systems typically only set a global total limit, failing to allocate quotas independently by department, project, or group. AI-assisted communication between employees lacks dynamically adjustable and real-time effective policy configurations, and cannot immediately block existing conversations after policy changes. Group message visibility policies are simplistic, unable to configure differentiated visibility modes independently for each group. Furthermore, the system generally adopts a flat "super administrator" permission model, violating the principle of least privilege, and sensitive credentials such as external platform account passwords lack a "time-limited, usage-limited, and traceable" one-time viewing mechanism.

[0006] Fifth, collaborative tasks lack a closed-loop execution mechanism that allows for accountability, early warning, and auditing. Existing task management tools are inadequate in areas such as Kanban visibility control, multi-dimensional correlation filtering, mandatory constraint of a single responsible person, overdue judgment criteria, automatic early warning of double deadlines, solidification of approval chains, and prevention of abuse of reminders, making it difficult to achieve closed-loop governance of AI-assisted tasks.

[0007] In summary, existing systems exhibit significant technological gaps in core dimensions such as the structural sophistication of role definitions, layered security governance of memory, risk control of automated execution, refined design of permission models, dynamic management of communication and information visibility, accountability for multi-person collaborative tasks, and governability of visual content generation. Therefore, a systematic solution that fully integrates agent capabilities into the enterprise governance system is urgently needed. Summary of the Invention

[0008] This invention addresses the architectural shortcomings of existing enterprise AI-assisted systems, including coarse AI role definitions, lack of hierarchical isolation and credibility filtering in memory management, absence of manual confirmation nodes in automated execution, overly coarse granular permission governance, lack of control over communication and information visibility among employees, and lack of a traceable execution loop for multi-person collaborative tasks. It proposes a structured identity-based intelligent agent and enterprise multi-domain collaboration system and method. This achieves a traceable, early warning, and auditable execution loop for multi-person collaborative tasks; through a division-of-labor architecture of AI background generation and local precise synthesis of deterministic brand assets, it upgrades visual content production from uncontrollable generation to a manageable pipeline. This invention upgrades AI from a general dialogue tool to a controlled intelligent agent within an enterprise governance framework, providing a configurable, isolating, verifiable, measurable, auditable, and manageable end-to-end technical solution for enterprise AI collaboration.

[0009] The objective of this invention is achieved through the following technical solution: a structured identity-based intelligent agent and enterprise multi-domain collaboration system and method, comprising the following steps: S1: AI Employee Configuration: The server receives the configuration instruction, extracts configuration data from eight configuration elements: responsibility text, answer boundaries, model call parameters, knowledge base access scope, tool permissions, memory scope, risk level, and associated action list, and stores the configuration data in the AI ​​employee configuration table to complete the AI ​​employee definition. S2: Authorization Verification and Quota Reservation: In response to the AI ​​call request initiated by the user, query the AI ​​authorization table to perform permission verification. After the verification is passed, call the quota reservation function to calculate the remaining available quota R=max(0,LUP) based on the total quota L of the authorization record, the number of used tokens U and the number of reserved tokens P. Then, perform reservation condition judgment based on the estimated number of input tokens T_in and the preset minimum output token reservation value O_min. S3: Runtime Context Construction: Construct a dialogue context, retrieve valid memories based on the memory range associated with the AI ​​employee, sort them according to relevance scores, and inject them into the context. Perform permission filtering and document retrieval based on the knowledge base access range associated with the AI ​​employee, and then inject the context. S4: Model Invocation and Usage Settlement: Send the constructed context to the model interface associated with the AI ​​employee. After receiving the response returned by the model, use a three-level degradation value retrieval strategy to obtain the actual consumed Token number U_actual and perform usage settlement. S5: Hierarchical Memory Management: The server stores memory records in the organization memory table. The memory records contain at least a memory level field and a status field. The memory level values ​​include private, personal long-term, group, department, and company. The status values ​​include pending confirmation, confirmed, corrected, and expired. When retrieving memories, records with a status of pending confirmation or expired are automatically filtered. In group chat scenarios, records with a memory level of private are automatically filtered. S6: High-risk action interception and manual confirmation: When a high-risk action type that hits the preset action list is identified in the response returned by the model, the system intercepts the output and generates a corresponding action draft record. The business operation can only be executed after manual confirmation and multiple verifications. S7: Hierarchical access control: The server performs permission verification based on role identifiers, and sets independent access permissions for business session data, AI usage data and sensitive credential data. System management roles do not have access permissions for business data.

[0010] Preferably, the extraction of configuration data from the eight configuration elements in step S1 specifically includes the following sub-steps: S11: Extract the role responsibility text content from the first input command and store it in the responsibility field; S12: Extract the response boundary text from the second input instruction and store it in the boundary field; S13: When the instruction contains an inherited global model configuration identifier, establish a reference association between the AI ​​employee record and the global model configuration record; when the instruction contains an independently specified identifier, extract and store the independent model configuration parameters. S14: Extract the selected target category identifier from the knowledge base access scope selection instruction, traverse the knowledge base classification tree to obtain a list of all subcategories under the category, and associate and store each category identifier with the access permission identifier of the AI ​​employee. S15: Extract the list of selected tool permission options from the tool permission check command and store them in association; S16: Extract the list of selected memory level options from the memory range selection command and store them in association; S17: Extract the selected risk level identifier from the risk level selection instruction, query the corresponding set of behavioral rules from the preset risk level configuration table, and store them in association; S18: In response to the risk level identifier, query the list of actions associated with the risk level from the preset manual confirmation rule base and store them in association. Preferably, in step S2: the quota reservation function is called to calculate the remaining available quota R based on the total quota L of the authorization record, the number of used tokens U, and the number of reserved tokens P, specifically including the following sub-steps: S21: Read the total authorized limit L, the number of used tokens U, and the number of reserved tokens P from the database authorization record, and calculate the remaining available limit R=max(0,LUP); S22: Call the message token estimation function, traverse each message in the message list and perform character-level estimation: T_est=N_cjk+ceil(N_other / 4)+C, where N_cjk is the number of Chinese characters, N_other is the number of non-Chinese characters, C is a fixed cost and takes the value 4, and sum T_est of all messages in the message list to obtain the total input estimated token sum T_in; S23: Check if the remaining quota meets the reservation condition: R≥T_in+O_min, where O_min is the minimum reserved value of the output Token and its value is 16; if it does not meet the condition, intercept the request and return a quota exhaustion error; S24: Calculate the number of output tokens O=min(O_max,R-T_in), where O_max is the default maximum output token value and takes the value 2048; calculate the total number of reserved tokens P_res=T_in+O, update the reserved token field in the database authorization record to P+P_res, and start the timeout timer with a timeout duration D of ten minutes. S25: After the model is invoked, the actual number of Tokens consumed, U_actual, is obtained using a three-level degradation value retrieval strategy. The number of Tokens used is updated to min(L,U+U_actual), and the reserved Token field is restored to its original value P.

[0011] In step S3: Valid memories are retrieved based on the memory range associated with the AI ​​employee, sorted according to relevance scores, and then injected into the context. This specifically includes the following sub-steps: S31: Read the associated memory range list from the AI ​​employee configuration table to determine the set of memory levels that can be retrieved this time; S32: Query candidate memory records from the organization memory table. The query conditions include: the memory level belongs to the set of memory levels, and the status field is neither pending confirmation nor expired. S33: Call the permission verification function for each candidate memory: if the memory level is within a group, verify whether the current user is a member of the source group; if the memory level is personal long-term, verify whether the current user is the owner of the memory; records that fail the verification are filtered out. S34: Calculate the relevance score for each memory that passes the verification: Concatenate the title, content, and category fields of the memory into the search source text and convert it to lowercase. Split the query text according to punctuation marks and spaces, filter words with a length less than L_min (L_min is 2), obtain the query word list, and calculate the score according to the formula M=I_norm×α+Σs_i, where I_norm is the normalized importance and the value ranges from 1 to 5, α is the importance weight coefficient and the value is 0.4, s_i is the score for the i-th hit query keyword and s_i=min(L_i,5), and L_i is the character length of the hit keyword; S35: Sort by score in descending order, take the content of the first K memories and inject them into the AI ​​model context, where K is a preset value and is set to 5.

[0012] Preferably, in step S6: the business operation can only be executed after manual confirmation and completion of multiple verifications, which specifically includes the following sub-steps: S61: Query the source identifier field value of the draft from the action draft table, and check whether the corresponding AI briefing record exists and whether its status is marked as withdrawn or deleted based on the identifier; if the query result is empty or the status is abnormal, the confirmation operation is rejected. S62: Get the creation time field value of the draft, calculate the difference with the current time, and if the difference is greater than the validity period threshold V days, reject the confirmation operation, where V is 7; S63: Query the current user's permission record from the user permission table to confirm that the user has the permission to perform the operation; if the permission has been revoked, reject the confirmation of the operation. S64: Query the status field value of the draft. If the current value is already "confirmed" or "ignored", reject the operation to prevent duplicate creation. S65: After all the above checks pass, execute the business operation and create a formal business record; S66: Update the status field of the draft record to "confirmed", write the confirmation time field to the current timestamp, and write the confirmer field to the current user identifier.

[0013] Preferably, the following steps are also included: S71: Receive the first user's approval operation. After passing the two-factor password verification, create a one-time viewing qualification record in the viewing qualification table. The record includes the granting object identifier, platform identifier, expiration time field and usage flag field. The usage flag field is initially written as unused. S72: Receive the password viewing instruction initiated by the granted user, query the viewing eligibility table for valid records that match the granted object, are marked as unused, and have an expiration time greater than the current time; if a valid record is found, continue execution; S73: Immediately update the usage flag field of the viewing qualification record to "used". The update operation is performed in a database transaction, and row-level locking is used to prevent concurrent reuse. S74: Read the corresponding encrypted account, encrypted password and encrypted remarks field values ​​from the password database table, call the decryption function to decrypt and return plaintext data to the client; S75: After receiving plaintext data, the client starts a countdown timer. The countdown timer checks once per second based on the display deadline timestamp returned by the server (current time plus T seconds), where T is 60. After the countdown ends, the client performs a DOM clearing operation to remove the plaintext data and sends a display end notification to the server. S76: When the usage mark of the viewing qualification record has been used or the expiration time has expired, the query result is empty, and the server returns a response to the client that there is no valid viewing qualification.

[0014] Preferably, the following steps are also included: S81: The server receives the policy update instruction, extracts the new communication mode value from the instruction, verifies that the current user has user management permissions, and updates the communication policy field value in the system configuration table to the new mode value. S82: After the update is completed, the server broadcasts the permission update event to all online clients. The event type is communication strategy change, and the event body contains the updated strategy value. S83: In response to a user's request to create a direct session or send a message, the server calls the private chat permission verification function, reads the current communication strategy field value from the system configuration table, and enters the corresponding condition branch to perform verification based on the communication strategy field value; S84: If the verification result is forbidden, the server refuses to create a session or refuses to send a message, and returns a forbidden access response to the client; S85: For existing direct sessions, the session read permission verification function is called in real time to verify permissions in both the message sending and processing flow and the session history message loading flow. If the verification fails, the operation is rejected. S86: The private chat permission verification function has a built-in role exception rule. When the target user or the current user's role is the highest administrator, it directly returns permission to communicate and is not subject to the five-level policy constraints.

[0015] Preferably, the following steps are also included: S91: The server receives the visibility policy configuration instructions submitted for each group, extracts the visibility mode value, and stores the session identifier and mode value in the session configuration table. The visibility modes include at least real-name visibility for all members, anonymous visibility for all members, and isolated visibility. S92: In response to a user sending a message in a group, the message distribution module queries the visibility policy associated with the group from the session configuration table and calls the message visibility judgment function to perform permission judgment: if the mode is all members real-name or all members anonymous, it returns that all members can see the message; if the mode is isolation, it enters the hierarchical permission judgment logic. S93: In the anonymous visibility mode, the identity tag processing module detects the role relationship between the current viewer and the sender. If both are controlled roles and not the same person, anonymization processing is triggered, and the sender's displayed name is replaced with the desensitized department name tag. S94: In isolated visibility mode, the hierarchical permission judgment logic checks the following in sequence: whether the viewer is the sender, whether the viewer's role is the highest administrator, and whether the viewer's role is a department administrator and the group has department administrator privileges enabled; if any of these conditions are met, viewing is allowed; otherwise, viewing is prohibited.

[0016] Preferably, the following steps are also included: S101: Receive business consultation messages sent by users in the group, perform keyword analysis on the message text: Traverse the configuration records of AI employees whose status is enabled, obtain the keyword list associated with each AI employee, match each keyword in the message text, accumulate scores for the matched keywords by type, and the score is the sum of the weights of the matched keywords; S102: Summarize the scores of all AI employees and perform professional candidate determination: the determination condition is S≥S_min and (N_strong>0 or S≥S_th), where S_min is the minimum score threshold and S_th is the independent score threshold; AI employees who meet the conditions become professional candidates. S103: Perform multi-level sorting on the professional candidate list: the first level is sorted in descending order by score, if the scores are the same, sorted in descending order by strong match number, and if they are still the same, sorted in ascending order by route priority value. S104: Obtain the number of professional candidates N_c. If N_c>1 and the cross-domain threshold condition is met, start multi-AI collaboration and create multiple parallel call tasks to obtain the answers of each AI employee. S105: Obtain the configuration information of the aggregation AI with the highest routing priority, call the model interface of the aggregation AI, take the answers of each AI employee as context input, attach aggregation instructions, generate a structured comprehensive response and return it to the client.

[0017] Preferably, the following steps are also included: S111: The server receives a document upload request, extracts the file data, title, category and access scope settings, stores the file in a secure storage path, creates a record in the knowledge document table, writes the access scope field to the authorized object list, and asynchronously starts a document parsing task to build an inverted index. S112: In response to the user's knowledge base retrieval request, the query text is segmented to obtain a list of query terms. The list of documents that the user is authorized to access is retrieved from the knowledge document table. For each document, the hit status is checked in the knowledge base index table. The retrieval score is calculated and returned in sorted order. S113: In response to the user's query request in the AI ​​chat, the same permission filtering logic as step S112 is executed again when constructing the AI ​​context. At the same time, the access permission scope of the knowledge base associated with the current AI employee is verified. The permission verification is performed independently in two stages. S114: Receive a document version update request, store the new version of the document and create a new record, and update the status field of the old version of the document record to invalid; the knowledge base retrieval function adds the status field as a valid filter condition to the document traversal query conditions.

[0018] A method for multi-AI automatic routing and cross-domain collaborative orchestration, characterized by the following steps: S201: Receive business consultation messages sent by users in the group, and perform keyword analysis on the message text: Traverse the configuration records of AI employees whose status is enabled, obtain the keyword list associated with each AI employee, match each keyword in the message text, and accumulate scores for the matched keywords according to their type. The score is the sum of the weights of the matched keywords. The weight of keywords whose length is within the range of strong keywords (2 to 3 characters) is 2, and the weight of keywords whose length is within the range of ordinary keywords (not less than 4 characters) is 1.5. S202: Summarize the scores of all AI employees and perform professional candidate determination: the determination condition is S≥S_min and (N_strong>0 or S≥S_th), where S_min is the minimum score threshold with a value of 2, N_strong is the number of strong keyword hits, and S_th is the independent score threshold with a value of 3; AI employees that meet the conditions become professional candidates. S203: Perform multi-level sorting on the professional candidate list: the first level is sorted in descending order by score, if the scores are the same, sorted in descending order by the number of strong keyword hits, and if they are still the same, sorted in ascending order by the route priority value. S204: Obtain the number of professional candidates N_c. If N_c>1 and the cross-domain threshold condition is met: S_b≥max(S_min,S_a×r), where S_a is the score of the first candidate, S_b is the score of the second candidate, and r is the proportional coefficient with a value of 0.5, then start multi-AI collaboration, create multiple parallel call tasks to obtain the answers of each AI employee respectively. S205: Obtain the configuration information of the aggregation AI with the highest routing priority, call the model interface of the aggregation AI, take the answers of each AI employee as context input, attach aggregation instructions, generate a structured comprehensive response and return it to the client.

[0019] Preferably, before step S201, the method further includes: if the user explicitly specifies an AI employee in the message, skip the automatic routing and collaborative orchestration process from S201 to S204, and directly read the configuration information of the specified AI employee from the AI ​​employee configuration table to initiate a single AI call; if the AI ​​employee specified by the user is not within its authorized scope, refuse to process the request and return a permission error response.

[0020] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention defines the structured identity of an intelligent agent through eight configuration elements: responsibility text, response boundaries, model parameters, knowledge base scope, tool permissions (S150), memory level, risk level, and a list of associated actions. This ensures that AI employees with different structured identities are completely independent in terms of model interface, knowledge access scope, memory level, and risk response strategy, fundamentally solving the problem of the disconnect between AI capabilities and job responsibilities. Through sub-steps such as token quota reservation, recent dialogue context construction, hierarchical memory retrieval, and knowledge base permission filtering retrieval, a complete business collaboration is completed within a controlled, traceable, and measurable resource framework, realizing the fundamental transformation of AI employees from "general dialogue tools" to "structured identity entities."

[0021] 2. This invention fundamentally isolates untrusted and protected memories through state-driven memory access filtering and a hierarchical cross-domain propagation blocking mechanism. The system categorizes all memories into four states: "Pending Confirmation," "Confirmed," "Corrected," and "Expired." During retrieval, it automatically filters out non-"Confirmed" states, ensuring that only verified factual information enters the AI ​​context. Simultaneously, it dynamically restricts the retrieval level of memories (private, long-term personal, group, departmental, company) based on the conversation scenario; private level memories are unretrievalable in any group chat scenario. This mechanism directly eliminates the possibility of AI employees responding based on unverified messages or the privacy of others, ensuring the credibility and compliance of memory citations from the source of retrieval.

[0022] 3. This invention constructs a hierarchical permission control system covering quotas, communication, and visibility. In the resource dimension, the system establishes a dual-track quota architecture with global authorization and group authorization running in parallel. Group consumption is independent of individual global quotas and does not affect each other. It also supports three management strategies: on-demand clearing, threshold modification, and unlimited exemption, directly achieving controllable allocation of token costs. In the communication dimension, the system has five built-in global communication policies (such as "employees are generally not allowed to communicate with each other," "only A and B are allowed to communicate privately, but A is not allowed to communicate privately with others"). After a policy change, all new session creations and message sending and receiving in existing sessions are verified in real time by the new policy, without requiring service restarts or re-login. This directly achieves centralized and dynamic control over the scope of communication between employees, thus allowing for systematic control of highly confidential personnel in scenarios such as R&D. In the visibility dimension, the system supports independent configuration of policies such as "all employees real-name / all employees anonymous / isolated visibility" by group. In isolation mode, only the sender, the highest-level manager, and the department manager with granted privileges can see the information, directly satisfying the differentiated information receiving permissions of the same user in different groups.

[0023] 4. This invention introduces an action draft intermediate layer and a multi-dimensional verification mechanism to establish a mandatory human confirmation node between AI generation and the actual business system. The system converts all operational intentions involved in AI responses, such as schedule creation, notification issuance, and configuration modification, into draft records, rather than directly calling business interfaces. All drafts must pass four joint verifications—source validity, timeliness, user permissions, and idempotency—before execution; only after passing these verifications can they be converted into formal business entities. This intermediate layer architecture downgrades AI from an "operation executor" to a "suggestion provider," ensuring that high-risk operations such as code merging, version releases, and company-wide notifications must be manually reviewed by authorized personnel before execution, directly eliminating the risks of misoperation and compliance associated with automated execution.

[0024] 5. Building upon the above, this invention completely decouples infrastructure management functions from business data access functions through a role-based access control model, achieving rigid isolation between operational permissions and data permissions at the permission definition level. The system clearly defines that system operators only have permissions for administrative operations such as user management, departmental structure maintenance, and client configuration updates. Their role identifiers are not included in any list of legitimate accessors for business data such as session messages, usage dashboards, and encrypted password libraries. All unauthorized requests are intercepted at the permission verification middleware layer and trigger audit log recording. This design directly ensures that even if operations personnel have high privileges on the database server, they cannot obtain any plaintext business data at the application layer, fundamentally eliminating the possibility of internal personnel unauthorizedly spying on or leaking sensitive corporate information, meeting the deployment requirements of industries with high compliance requirements such as finance and government.

[0025] 6. This invention establishes a multi-AI automatic routing and cross-domain collaborative orchestration mechanism, solving the collaboration efficiency problem of users "not knowing who to ask" among multiple professional AI employees. The system performs multi-keyword weighted scoring on user messages, filters professional candidates from the activated AI employees, and automatically determines the main answering AI after multi-level sorting; when the score of the second candidate meets the cross-domain threshold condition, the system calls multiple AI employees in parallel to obtain answers, and the aggregation AI with the highest routing priority generates a structured comprehensive response. This mechanism liberates users from "manually selecting AI" and realizes multi-agent collaborative answering of complex cross-domain problems.

[0026] 7. This invention constructs a closed-loop task execution system that is accountable, predictable, and auditable through three-dimensional permission control of task dashboards, mandatory constraint of a single responsible person, dual deadline monitoring and automatic red, yellow, and green alerts, a reminder cooling-off mechanism to prevent abuse, and a serial approval snapshot fixation mechanism. The system divides the visibility of the dashboard into three levels: company-wide, departmental, and individual only, and combines four types of relationships—responsible person, publisher, executor, and approver—to achieve precise filtering. For multi-person tasks, a single responsible person is designated, and the final deliverable is only submitted by the responsible person, directly clarifying the attribution of responsibility. The system simultaneously monitors the final deadline and up to 12 stage nodes, automatically turning overdue tasks from green to yellow to provide proactive warnings. The approval snapshot fixes the list of approvers at the time of submission, ensuring that the historical approval chain is not affected by personnel changes. Overdue tasks are compared with the deadline based on the actual submission time of the deliverable, rather than the approval completion time, to avoid misjudging overdue due to lengthy approval processes.

[0027] 8. This invention upgrades visual content production from an uncontrollable AI black box to a manageable enterprise-level production pipeline by employing a framework that integrates AI background and deterministic typesetting, utilizes a model whitelist intersection method, employs idempotent protection via request fingerprints, and traces the solution lineage. The system limits AI capabilities to generating backgrounds and atmospheres; deterministic elements such as logos, titles, prices, and declarations are precisely typeset and synthesized locally on the server, directly eliminating the risk of AI-generated typos and fake logos. Model validity is determined by the intersection of the system directory, the company whitelist, and available supplier models, enabling centralized management. Dual verification using request fingerprints and idempotent keys prevents duplicate billing at the protocol layer. All assets retain complete traceability fields and form a directed graph structure, allowing viewing of the complete evolutionary chain from initial generation to finished product.

[0028] 9. The essential difference between the action draft confirmation mechanism of this invention and the existing workflow approval system lies in the fact that the existing system relies only on static "node-role" preset rules, while the interception rules of this invention are dynamically associated with the risk level identifier in S17. The same action type triggers different confirmation strategies under different risk levels (high risk mandatory confirmation, medium risk with source reference, low risk automatic execution). Furthermore, the four-fold verification (source validity, timeliness, permission, and idempotency) in S61 to S64 is unique to AI scenarios and cannot be covered by general workflow engines. The essential difference between the request fingerprint idempotency protection of this invention and the existing API idempotency design lies in the fact that S5320 to S5330 bind the request fingerprint and the image quota atomic reservation in S5400 to the same database transaction. When the fingerprint is matched, not only is the supplier interface not called repeatedly, but the image generation quota is not deducted repeatedly, realizing the decoupling idempotency of "billing" and "call". This is a proprietary design for the cost-sensitive characteristics of AI generation scenarios, and not a simple application of general idempotency solutions. Attached Figure Description

[0029] Figure 1This is a flowchart of the first embodiment of the present invention; Figure 2 This is a flowchart of the second embodiment of the present invention; Figure 3 This is a flowchart of the third embodiment of the present invention; Figure 4 This is a flowchart of the fourth embodiment of the present invention; Figure 5 This is a flowchart of the fifth embodiment of the present invention; Figure 6 This is a flowchart of the sixth embodiment of the present invention; Figure 7 This is a flowchart of the seventh embodiment of the present invention; Figure 8 This is a flowchart of the eighth embodiment of the present invention; Figure 9 This is a flowchart of the ninth embodiment of the present invention; Figure 10 This is a flowchart of the ninth embodiment of the present invention; Figure 11 This is a flowchart of the tenth embodiment of the present invention; Figure 12 This is a flowchart of the eleventh embodiment of the present invention; Figure 13 This is a flowchart of the eleventh embodiment of the present invention; Figure 14 This is a flowchart of the twelfth embodiment of the present invention; Figure 15 This is a flowchart of the twelfth embodiment of the present invention. Detailed Implementation

[0030] The present invention will be further described below with reference to the embodiments illustrated in the accompanying drawings: This invention provides an intelligent agent and enterprise multi-domain collaboration system and method based on structured identity, employing a client-server architecture. The server is responsible for business logic processing, permission verification, data storage, and AI model invocation; the client includes a Windows PC client and a PC Web client, providing a user interface.

[0031] In the description of the various embodiments of the present invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of the present invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0032] In various embodiments of the present invention, to facilitate the description of differentiated control logic and data isolation rules based on different permission levels, the following user accounts are defined in an exemplary manner: User accounts with the highest system privilege level are defined as the first user (e.g., in an enterprise deployment environment, this privilege level may correspond to the highest administrator account); user accounts with department-level data management privileges are defined as the second user (e.g., may correspond to the department administrator account); user accounts with basic operation privileges are defined as the third user (e.g., may correspond to the ordinary employee account); and user accounts with system operation and maintenance management privileges are defined as the fourth user (e.g., may correspond to the system operation and maintenance personnel account). User accounts with AI strategy configuration permissions are defined as the fifth user (e.g., corresponding to the AI ​​strategy configurator account); user accounts with knowledge asset management permissions are defined as the sixth user (e.g., corresponding to the knowledge asset manager account).

[0033] The naming of the aforementioned user accounts and their correspondence with specific management functions are merely for visually illustrating the differences in the operating subjects under different permission levels of this invention, and do not constitute a limitation on the application scenarios of the technical solution of this invention. The actual operating permissions of each user account in the system are determined by the permission level identifier field stored internally by the system.

[0034] Meanwhile, the system has configured and enabled multiple AI employee objects with different styles and functional scopes, including, for example: cross-industry strategic analyst AI object, capital allocator AI object, board assistant AI object, R&D assistant AI object, and AI knowledge base question-and-answer assistant AI object. Each AI employee object is associated with independent responsibility configuration data, knowledge base access scope data, and memory scope configuration data in the system. The above-mentioned AI employee object names are only used to illustrate the configuration differences under different responsibility divisions and do not constitute a limitation on the type or number of AI employees in this invention.

[0035] The system has pre-stored basic architecture data on the server, including organizational structure identification data (such as the first department identifier, the second department identifier, etc.) and permission level identification data of the aforementioned user accounts, which are used to support permission verification and data isolation operations in subsequent embodiments.

[0036] Please refer to the reference. Figure 1 This is the first embodiment of the present invention. In this first embodiment, the main focus is on detailing how an AI employee is defined through multiple configuration elements, and how the system dynamically constructs the complete context of AI invocation at runtime based on these elements.

[0037] The first embodiment of the present invention specifically includes the following steps: S100: The server receives the "R&D Assistant" role definition instruction submitted by the fifth user through the management interface, parses the configuration data contained in the instruction, and stores the processed definition data in the AI ​​employee configuration table.

[0038] S110: Receive the first input instruction, extract the role responsibility text content as "assist in R&D process, technical data organization, experimental record analysis, and solution organization", and store the text in the responsibility field of the AI ​​employee configuration table.

[0039] S120: Receive the second input instruction, extract the answer boundary text content as "Do not provide financial advice, do not make technical decisions on behalf of the R&D head, and do not disclose unpublished R&D data", and store the text in the boundary field of the AI ​​employee configuration table.

[0040] In steps S110 and S120, the stored responsibilities and boundary text will be injected into the model context as part of the system prompts during subsequent runtime, jointly defining the behavioral guidelines and competency scope of the AI ​​employee.

[0041] S130: Receive the model call parameter selection instruction. When the instruction contains the "inherit global model configuration" identifier, read the stored model supplier interface address, interface access key, and default model name from the global configuration table, and establish a reference association between the AI ​​employee record and the global model configuration record.

[0042] In step S130, the interface access key in the global configuration table is encrypted and stored using a server-side dedicated key, and cannot be read through any client interface. When an instruction is parsed and contains an "independent designation" identifier, the independent model configuration parameters are extracted from the instruction and stored in the configuration record of that AI employee.

[0043] S140: Receive a knowledge base access scope selection instruction. Extract the selected target category identifier "R&D Department" from the instruction, traverse the knowledge base category tree to obtain a list of all subcategories under this category, including "Technical Specifications," "Experiment Record Templates," and "Product Design Documents." Associate each category identifier in the subcategory list with the access permission identifier of the AI ​​employee to generate and store a knowledge base access permission record.

[0044] S150: Receive tool permission selection instruction. Extract the list of selected tool permission options from the instruction, including code repository information read permission and task draft generation permission. Store the tool permission option list after associating it with the AI ​​employee's identifier.

[0045] S160: Receive a memory range selection instruction. Extract a list of selected memory level options from the instruction, the list including "current session context", "personal long-term memory", and "group memory". Associate the memory level option list with the identifier of the AI ​​employee and store it.

[0046] In step S160, the unselected memory level options "Department Memory," "Company Memory," and "Personal Memory" are not included in the association scope. The runtime memory retrieval module determines the range of searchable memory levels based on this association list.

[0047] S170: Receive risk level selection instruction. Extract the selected risk level identifier "Medium" from the instruction. Query the set of behavioral rules corresponding to this level from the preset risk level configuration table. The set of behavioral rules includes: AI-outputted technical solution suggestions must include source citations; suggestions involving code merging and version releases will only generate action drafts and will not be automatically executed. Store the set of behavioral rules after associating it with the identifier of the AI ​​employee.

[0048] S180: In response to the risk level being "medium" stored in step S170, a list of actions associated with this risk level is retrieved from a preset manual confirmation rule base. This list includes code merging suggestions, continuous integration configuration modification suggestions, version release suggestions, and company-wide notification suggestions. The action list is then associated with the AI ​​employee's identifier to establish a trigger condition record.

[0049] In step S180, when the AI ​​output content during subsequent runtime matches any action type in the action list, the system intercepts the output, generates a corresponding action draft record, pauses the automatic execution process, and sends a confirmation request message to the user terminal. If the risk level is "low," the retrieved action list is empty, and no interception occurs.

[0050] S190: After all configuration items are stored, the server calls the model interface test function to assemble a minimal test request and send it to the model interface address associated with the AI ​​employee. The test request includes the interface access key obtained from the global configuration table. The server receives the response message returned by the model interface. If the response status code indicates success, the status flag of the AI ​​employee is updated to "Enabled"; if the response status code indicates failure, the status flag is updated to "Connection Failed" and an error message is returned.

[0051] In step S100, the associated data of the above eight configuration elements together constitute a complete definition of an AI employee, which is stored in the corresponding fields of the AI ​​employee configuration table, and the fields are associated with each other through the AI ​​employee identifier.

[0052] S200: When a third user initiates an AI-powered one-on-one chat with a research assistant, the server executes a runtime dynamic build process.

[0053] S210: Extract the user identifier of the third user and the target AI employee identifier from the session request. Query the AI ​​authorization table to check if there exists an authorization record where the user identifier matches the AI ​​employee identifier and the authorization status is valid. If the search result is empty, refuse the call and return a permission error response to the client.

[0054] S220: Call the quota reservation function, pass in the global authorized quota record of the third user and the estimated message list, and perform Token quota reservation.

[0055] S220a: In multi-AI collaboration scenarios (see S3050-S3060), the quota reservation process from S220 to S225 is still executed only once. The total reservation amount is the sum of the estimated input token values ​​of all parallel AI calls and the estimated input token value of the aggregated AI, which is deducted once as a single reservation operation.

[0056] S221: Read the total global authorization limit L, the number of used tokens U, and the number of reserved tokens P of the user from the authorization record in the database, and calculate the remaining available limit R: R=max(0,LUP).

[0057] Where L defaults to 100,000; U and P are read from the database authorization records. Assuming U=12500 and P=0, then R=87500.

[0058] S222: Call the message token estimation function, iterate through each message in the message list, and perform character-level estimation for each message.

[0059] In step S222, the estimation follows these rules: T_est=N_cjk+ceil(N_other / 4)+C Where T_est is the estimated number of tokens for a single message; N_cjk is the number of Chinese characters in the message (covering basic and extended Chinese character sets), with each Chinese character counting as 1 token; N_other is the number of non-Chinese characters in the message, with every four consecutive non-Chinese characters rounded up as 1 token; C is the fixed cost for each message, with a value of 4. The sum of T_est for all messages in the message list is used to obtain the total estimated tokens T_in. Assume T_in = 59.

[0060] S223: Check if the remaining quota meets the reservation conditions. The judgment condition is: R≥T_in+O_min.

[0061] Where O_min is the minimum reserved value for output tokens, which is 16. Substituting the value, 87500≥59+16=75, the condition is met, and execution continues. If not, a quota exhaustion error message is generated, the request is intercepted, and an error response is returned to the client.

[0062] S224: Calculate the number of output tokens O: O = min(O_max, R-T_in).

[0063] Where O_max is the default maximum output token value, which is 2048. Substituting the value, R-T_in=87441, which is greater than 2048, therefore O=O_max=2048.

[0064] S225: Calculate the total amount of reserved tokens: P_res = T_in + O. Update the reserved token field in the database authorization record to P + P_res. At the same time, start a timeout timer with a timeout duration D of ten minutes. After the timeout, automatically restore the reserved token field to its original value P.

[0065] S230: Call the recent conversation context construction function to retrieve recent messages of the current session from the message table.

[0066] In step S230, the construction parameters include the maximum number of messages N_msg (30 messages), the total character limit C_total (24000 characters), and the single message limit C_msg (1800 characters). The construction process is as follows: initialize the remaining character counter to C_total; query the message records of the current session from the message table in reverse timestamp order, truncate the first C_msg characters of each message, format the truncated content into the format of "sender name plus message body", append it to the context list, and deduct the number of characters of the message from the remaining character counter; stop traversing when the remaining character count is less than or equal to zero or the number of processed messages reaches N_msg; reverse the context list so that the messages are arranged in ascending time order. If the current session is an anonymous group type, the sender name is first processed by a de-identification function before formatting.

[0067] S240: Based on the memory range association list stored in step S160, retrieve available memory data according to priority.

[0068] S241: Query memory records from the organization memory table, with filtering conditions including: the memory status is not "invalid" and not "pending confirmation"; the memory level belongs to the level in the memory range list associated with the AI ​​employee.

[0069] S241a: For the candidate memory records obtained from S241, call the same hierarchical permission verification logic as S242 (see S931 to S934) to remove the records that fail the verification from the candidate set.

[0070] S242: Calculate the relevance score for each valid memory after filtering.

[0071] In step S242, the calculation rules are as follows: extract the title, content, and category fields of the memory, concatenate them into the search source text, and convert it to lowercase; split the query text according to punctuation marks and spaces, filter out words with a length less than L_min (L_min is 2), and obtain the query word list. Calculate a score for each memory entry: M = I_norm×α + Σs_i Where M is the memory score; I_norm is the normalized importance, which is obtained by forcibly constraining the original importance value I within the range of [1,5]; α is the importance weight coefficient, with a value of 0.4; s_i is the bonus for the i-th hit query keyword, s_i=min(L_i,5), where L_i is the character length of the hit keyword. The first K memories are sorted in descending order of M value and injected into the model context.

[0072] S250: Call the knowledge base retrieval function, pass in the query text from the third user, and retrieve the data within the knowledge base access permissions associated in step S140.

[0073] In step S250, the retrieval process is as follows: The query text is converted to lowercase using a word segmentation function, segmented by non-alphanumeric characters, and words shorter than L_min (L_min is 2) are filtered out. The first W words (W is 20) are retrieved. The document list accessible to the AI ​​employee is retrieved from the knowledge base document table. The index content of each document is traversed, and the number of matched query terms is counted as a score, with 1 point awarded for each matched query term. Documents are sorted in descending order of score, and if scores are the same, they are sorted in descending order of document creation time. The first D documents (D is 4) are retrieved, and the position of the first matched word in each document is located. Starting from the B_before characters (80 characters) before that position, B_total characters (360 characters) are extracted as a summary fragment. The retrieval results and their summary fragments are injected into the AI ​​context as source information.

[0074] S260: Assemble the dialogue context constructed in step S230, the memory content retrieved in step S242, and the knowledge base results retrieved in step S250 into a standard dialogue message format, and call the model interface function to send it to the model interface address associated in step S130.

[0075] In step S260, the request body includes the model name (read from the AI ​​employee configuration table), a message list (assembled standard format messages), a temperature parameter τ (set to 0.4), and the maximum output token count O (calculated in step S224). After receiving the response message returned by the model, the system performs usage settlement. The settlement adopts a three-level degradation value retrieval strategy: firstly, the actual consumed token count U_actual is extracted from the usage object in the response message; if this field is missing, the estimated value at the time of reservation is used; if it is still missing, the estimation function in step S222 is called to recalculate. The used token count in the database is updated to min(L,U+U_actual), and the reserved token field is restored to its original value P.

[0076] In step S200, through the above six sub-steps, an intelligent agent (AI employee) with a precise multi-element structure is able to complete a complete business collaboration within a controlled, traceable, and resource-measurable framework.

[0077] Please refer to the reference. Figure 2 The second embodiment of the present invention is described in detail below. The second embodiment primarily details the dual-track AI authorization and Token quota control: the operational mechanism of two independent authorization types—global specific AI authorization and "only this group's AI" authorization—as well as the independent calculation, reservation, deduction, and reset processes of their respective Token quotas.

[0078] The second embodiment of the present invention specifically includes the following steps: S300: The server receives the authorization instruction submitted by the first user on the AI ​​employee authorization management page, and performs corresponding authorization data creation and storage operations according to the instruction type.

[0079] S310: Receives an instruction to assign global AI authorization to the second user. Extracts the list of selected AI employee identifiers and the user identifier of the second user from the instruction.

[0080] S311: Create three authorization records in the authorization table in batches. Each record includes: a user identifier field containing the identifier of the second user, an AI employee identifier field containing the identifier of the corresponding AI employee, a Token limit field with the default value L (L is 100,000), an initial value of zero for the used Token field, an initial value of zero for the reserved Token field, and an authorization scope field set to global. Write the three records to the authorization table in the database.

[0081] In step S311, the authorization scope field of these three authorization records is global, and the Token limit field value is the same. When the system performs limit verification, it will merge all global authorization records of the same user and share a single Token limit.

[0082] S320: Receives an instruction to assign group AI authorization to a third user in the "New Product Development Project Group". Extracts from the instruction a list of selected AI employee identifiers, the third user's user identifier, and the target group's session identifier.

[0083] S321: Generate an authorized AI list based on the extracted AI employee identifier list, which includes the identifiers of two AI employees.

[0084] S322: Create a group authorization record in the authorization table. The record's User Identifier field should contain the identifier of the third user; the AI ​​Employee Identifier field should contain the authorized AI list generated in step S321; the Token Limit field should be the default value L_g (L_g is 50,000); the Authorization Scope field should be set to the group; and the Associated Session Identifier field should contain the identifier of the target group. Write this record to the database authorization table.

[0085] In step S322, group authorization records and global authorization records are distinguished by different values ​​of the authorization scope field. When the quota reservation function is executed, it first matches records with the authorization scope field set to "group" based on the current session identifier; if no match is found, it then queries records with the authorization scope field set to "global". Group authorization is calculated independently for "group plus employees" and does not share the global authorization quota with third-party users.

[0086] S400: Receives AI call requests initiated by the second user in a one-on-one chat with the "R&D Assistant", and performs global authorization calls and usage settlement.

[0087] S410: Extract the user identifier of the second user from the current session, and query the authorization record set in the authorization table where the authorization scope field is global and the user identifier matches. Summarize the quota data of all records in this record set: total quota L is 100,000, total used tokens U is 12,500, and total reserved tokens P is zero. Calculate the remaining available quota: R = LUP = 87,500 S420: Invoke the quota reservation process from steps S220 to S225. It is estimated that this call requires P_needToken to be reserved (P_need is approximately 2200). Update the total amount of reserved Tokens to P+P_need. At this time, the remaining available quota is updated to R-P_need=85300.

[0088] S430: After the model call is complete, perform usage settlement. Extract the actual consumed token count U_actual from the response message returned by the model (assuming U_actual = 1980). Update the total used tokens in the authorization record set: U_new=U+U_actual=14480; P_new=max(0,P_need-U_actual)=220.

[0089] In step S400, when the second user subsequently uses other AI employees with global authorization, the consumption will be deducted from the remaining part of the same quota. When R of a certain call is less than T_in+O_min, the system directly rejects the request in the reservation phase and returns a quota exhaustion error.

[0090] S500: Receive a request from a third user to call the knowledge base question-answering assistant in the "new product R&D project group", and perform group authorized calling and independent quota counting.

[0091] The system preferentially queries the authorization table for authorization records where the authorization scope field is group, the associated session identifier field matches the current group session identifier, and the user identifier field matches the third user identifier. Obtain the quota data of this record: the total quota L_g is 50,000, the used quota U_g is 8,000, and the reserved quota P_g is 0. Calculate the remaining quota: R_g=L_g-U_g-P_g=42000.

[0092] Call the quota reservation process from step S220 to step S225, the current call needs to reserve P_need_g (approximately 1800), and update the reserved field of this group authorization record.

[0093] In step S500, this update operation only affects the value of the reserved field of the group authorization record, and does not affect any field value in the global authorization record of the third user.

[0094] S600: Receive a quota management instruction submitted by the first user, and execute the corresponding quota cycle management operation.

[0095] S610: Receive the "re-authorize and reset to zero" instruction. The system updates both the used Token field and the reserved Token field of the group authorization record to zero, and the Token quota upper limit field can remain unchanged or be updated to a newly set value. The available quota of the third user in this group is restored to the full quota.

[0096] S620: Receive the "modify quota upper limit" instruction. The system only updates the value of the Token quota upper limit field to a new value (for example, from 50,000 to 80,000), keeps the current values of the used Token field (8,000) and the reserved Token field unchanged, and does not trigger a reset-to-zero operation.

[0097] S630: For AI requiring unrestricted use, receive an instruction to set the Token limit to zero. In the limit serialization function, if the system detects that the total limit value L of an authorized record is zero, it sets the unlimited limit flag in the serialization result of that record to true and sets the remaining available limit field to null. At the entry point of the limit reservation function, if the system detects that the unlimited limit flag of the passed-in authorized record is true, it directly returns a null operation result, skipping all subsequent limit checks and reservation steps; the call is not limited by the number of Tokens.

[0098] In step S600, the above three operations are implemented by updating different combinations of fields in the authorization record, providing differentiated control granularity for cost management.

[0099] Please refer to the reference. Figure 3 The third embodiment of the present invention is described in detail below. In this third embodiment, the management and anti-cross-use of hierarchical multi-domain memories are explained in detail: the system stores all memory records in an organizational memory table in the server-side database. This table contains the following key fields: record identifier, title, content, category, memory level (values ​​include private, personal long-term, group, department, company), source session identifier, owner identifier, importance (values ​​range from 1 to 5), status (values ​​include pending confirmation, confirmed, corrected, expired), creator identifier, confirmer identifier, and update time.

[0100] The third embodiment of the present invention specifically includes the following steps: S700: Receives messages sent by the second user in the "R&D Department Work Group", responds to the "Let AI Remember" command executed by the third user, and creates a memory record to be confirmed.

[0101] S710: Based on the message identifier carried in the instruction, extract the message content, sender identifier (second user), session identifier (R&D department work group) and timestamp from the message table.

[0102] S720: Create a new record in the Organization Memory Table. Write the extracted message content into the Content field, "Component Selection Decision" into the Title field, "R&D Decision" into the Category field, "Group Memory" into the Memory Level field, the Session Identifier field into the R&D Department workgroup's session identifier, the Default Value I (I is 3) into the Importance field, "Pending Confirmation" into the Status field, and the Third User's Identifier field into the Creator Identifier field. Save this record to the Organization Memory Table.

[0103] In step S700, the status field value of the memory record is pending confirmation. When performing a retrieval, the memory retrieval module automatically filters records with a status of pending confirmation to ensure that unconfirmed information is not injected into any AI dialogue context.

[0104] S800: Receives the "confirmation" command initiated by the first user for the "parts selection decision" memory record, and performs the review and confirmation operation.

[0105] The system queries the organization memory table for all records with a status of "Pending Confirmation" and returns the results to the client for rendering. Upon receiving a confirmation command, the system updates the status field of the record to "Confirmed," writes the first user's identifier into the confirmer identifier field, and writes the current timestamp into the update time field.

[0106] In step S800, after the status of the memory is changed to confirmed, the memory retrieval module includes it in the searchable range, and the memory content can be used as a formal fact by subsequent AI calls and references.

[0107] S900: Receives query messages sent by a third user in a one-on-one chat with the "R&D Assistant", triggering a hierarchical memory retrieval process.

[0108] S910: Read the list of memory ranges associated with the R&D assistant (personal long-term memory, group memory) from the AI ​​employee configuration table, and combine it with the authorization range of the third user to determine the set of memory levels that can be retrieved this time as {personal long-term memory, group memory}.

[0109] S920: Query candidate memory records from the organization memory table. The query conditions are: (memory level field value is within the group and the source session identifier field value is in the group member list of the third user) or (memory level field value is personal long-term and the owner identifier field value is the third user identifier and the AI ​​employee identifier field value is the R&D assistant identifier); at the same time, the status field value is not expired and not pending confirmation.

[0110] S930: Call the permission verification function for each candidate memory, and perform the verification sequentially according to the following rules: S931: If the memory level is within a group, verify whether the current user is a member of the source group; if the verification fails, filter the user. S932: If the memory level is personal long-term, verify whether the current user is the owner of the memory; if the verification fails, filter it. S933: If the memory level is a department, read the current user's department affiliation field from the user information table and verify whether the department identifier matches the source department identifier of the memory; if the current user has no valid department or the department identifier does not match, the verification fails and the memory is filtered out. S934: If the memory level is a company, verify whether the company identifier of the current user matches the source company identifier of the memory; if they do not match or the current user has no valid company affiliation, the verification fails and the memory is filtered out.

[0111] Records that fail any of the above checks are filtered out and do not proceed to the subsequent relevance scoring stage. S940: Calculate the relevance score for each memory record that passes the checks. First, concatenate the title, content, and category field values ​​of the memory record into the search source text and convert it to lowercase; split the query text according to punctuation marks and spaces, filtering out words shorter than L_min (L_min is set to 2), to obtain the query term list. Calculate the score using the following formula: M = I_norm × α + Σs_i.

[0112] Where M is the memory score; I_norm is the normalized importance, which is the original importance value I is forced to be within the range of [1,5]; α is the importance weight coefficient, with a value of 0.4; s_i is the bonus for the i-th hit query keyword, s_i=min(L_i,5), where L_i is the character length of the hit keyword. Sort in descending order of M value.

[0113] S950: Inject the values ​​of the top-ranked memory fields into the message context of the AI ​​model. The AI ​​model combines this memory information to generate a response, outputting the component model and parameter information.

[0114] S1000: Receives a "private memory" request submitted by a third user, creates a private memory record, and performs isolation filtering in group chat scenarios.

[0115] The system creates a new record in the organization memory table, writes the memory hierarchy field to private, and writes the owner identifier field to the third user identifier.

[0116] In step S1000, when a third user calls upon a research assistant in the R&D department's work group, the system's memory retrieval module identifies the current session type as a group chat in step S910. Based on preset diffusion rules (records with a private memory level are prohibited from responding in any group chat), the system automatically adds a filter condition in step S920 stating that the memory level field value is not equal to "private." Therefore, this private memory record will not be retrieved, and the research assistant's response in the group chat will not contain the third user's private concerns.

[0117] S1100: Receives a "correction" command initiated by the second user for the "component selection decision" memory record, and performs memory correction and version management.

[0118] S1100: Receives a "correction" command initiated by the second user for the "component selection decision" memory record, and performs memory correction and version management.

[0119] S1110: The system does not modify any field values ​​of the original record, but creates a new record: the content field is written with the updated content (new model XT-300 and new parameters), the status field is written with "corrected", the creator identifier field is written with the second user identifier, and the identifier of the original record is written in the associated original record identifier field of the new record.

[0120] S1120: Keep the status field of the original record as confirmed, and write the identifier of the new record into the associated new record identifier field of the original record to establish a two-way version association relationship and form an audit chain.

[0121] S1130: When processing a query, if the memory retrieval module matches a record and the associated new record identifier field of that record is not empty, it will automatically route the query to the latest version of the record. Only the content of the latest version will be injected into the AI ​​context; the old version will only be used for historical tracing and will not directly participate in AI answer generation. Both the original record and the new record are retained in the organization memory table, supporting complete version tracing.

[0122] S1140: Upon receiving the instruction from the second user to mark the old memory as invalid, the system updates the status field of the original record to invalid. Records with an invalid status are automatically filtered in the query conditions of step S920 and are no longer injected with any AI context.

[0123] In step S1100, records with an expired status are automatically filtered out in the query conditions of step S920, and no further AI context is injected. Both the original and new records are retained in the organization memory table, supporting full version tracing.

[0124] Please refer to the reference. Figure 4 The fourth embodiment of the present invention is described in detail in terms of how the system inserts an "action draft" stage between AI output and actual business execution to ensure that high-risk operations must be manually confirmed.

[0125] The fourth embodiment of the present invention specifically includes the following steps: S1200: The server-side scheduled task module triggers the Dongzhu (Dong Assistant) to run, generate an AI briefing, and create a draft of actions to be confirmed.

[0126] In step S1200, for example, the first user enables the Dongzhu's proactive operation briefing function through the personal settings interface, sets the trigger time to 8:00 AM every workday, and the briefing type to "Summary of Decisions to be Made Today". The system stores this setting in the user configuration table.

[0127] S1210: The scheduled task is triggered by the assistant director at a designated time each workday. The assistant director queries the organizational memory table for organizational memory records within the first user's authorized scope that are confirmed and not expired; queries the first user's pending tasks and approval items from the schedule table; and assembles the query results into contextual information.

[0128] S1220: Assistant Dong invokes the AI ​​model, using the context information assembled in step S1210 as input, to generate the briefing content. The response message returned by the model contains multiple suggestions.

[0129] In step S1220, at least one suggestion is: "Based on the discussion at last week's R&D meeting, it is suggested that a mass production review meeting for component XT-200 be held this Wednesday at 2:00 PM. Attendees: First User, Second User, and Third User. It is suggested to create a schedule." S1230: Parse the response message returned by the parsing model and identify the action intent that includes "suggest creating a schedule". The system does not automatically create a schedule record in the schedule table, but instead creates an action draft record in the action draft table.

[0130] In step S1220, the draft record field values ​​include: the type field is written as schedule, the title field is written as "Component XT-200 Mass Production Review Meeting", the suggested time field is written as this Wednesday at 14:00, the suggested participants field is written as a list of identifiers for the first user, the second user, and the third user, the status field is written as pending confirmation, the source field is written as AI briefing, and the source identifier field is written as the identifier of this briefing record. The record is then saved to the action draft table.

[0131] S1240: Send an in-site reminder message to the first user. The message content only contains the prompt text "You have a new assistant director briefing to review" and does not contain the business text content of the briefing.

[0132] S1300: Receives the "Confirm Creation" command initiated by the first user for the "Convene Mass Production Review Meeting" draft, and executes multiple verification and creation processes.

[0133] S1310: Query the source identifier field value of the draft from the action draft table, and check if the corresponding AI briefing record exists and is not marked as withdrawn or deleted based on the identifier. If the query result is empty or the status is abnormal, reject the confirmation operation and return the error message "Source has expired" to the client.

[0134] S1320: Retrieve the creation time field value of the draft and calculate the difference between it and the current time. If the difference is greater than the validity period threshold V days, reject the confirmation operation and return an error message "Validity period expired" to the client. Assuming the draft is still valid, the verification passes.

[0135] In step S1320, V can be set to 7 or other numbers of days.

[0136] S1330: Retrieve the current permission record of the first user from the user permission table to confirm that it has the operation permission to create a schedule for all users. If the permission has been revoked, reject the confirmation operation.

[0137] S1340: Query the status field value of the draft. If the current value is already "confirmed" or "ignored", reject the operation and return a "This suggestion has been processed" message to the client to prevent duplicate creation.

[0138] S1350: After all the above checks pass, create a formal schedule record in the schedule table: write the title field value of the draft title field to the title field, write the suggested time field value of the draft time field to the time field, write the first user identifier to the creator field, and write the suggested attendee field value of the draft participant field to the participant field.

[0139] S1360: Update the status field of the draft record to "confirmed", write the current timestamp to the confirmation time field, and write the first user identifier to the confirmer field.

[0140] S1400: Receives a rejection instruction for the draft or handles source failure scenarios, and performs corresponding status update and interception operations.

[0141] S1410: Received the "Ignore" command from the first user regarding the draft "Adjust Q3 R&D Budget Allocation". The system updates the status field of the draft to "Ignored", without triggering any business entity creation operation.

[0142] S1420: Receive the "Confirm Creation" command initiated again by the first user for the already confirmed "Convene Mass Production Review Meeting" draft. During the idempotency check in step S1340, the system detects that the draft's status field value is already confirmed, refuses to execute, and returns a prompt.

[0143] S1430: Assume that during the source validity verification in step S1310, it was detected that the associated AI briefing record has been withdrawn (the status field value is withdrawn). The system refuses to confirm the operation and returns the message "The source of this suggestion has expired, please re-evaluate".

[0144] In step S1400, the above mechanism uses the action draft table as an intermediate layer to insert a manual confirmation node between the AI-generated suggestions and the creation of business entities. Combined with source verification, timeliness verification, permission verification and idempotency check, it forms a security closed loop for high-risk operations.

[0145] Please refer to the reference. Figure 5 The fifth embodiment of the present invention mainly details the "one-time viewing" security mechanism for account passwords on external platforms.

[0146] The fifth embodiment of the present invention specifically includes the following steps: S1500: Receives platform directory query requests and "request to view" instructions initiated by third-party users, and processes requests to view sensitive information.

[0147] S1510: Receives a platform directory query request. The server queries all platform records from the password database, extracts non-sensitive metadata fields such as platform name, category, and login address for each record, assembles them into a directory list, and returns it to the client. The response data does not contain sensitive fields such as username, password, or remarks.

[0148] S1520: Receives a "Request to View" command from a third user on the target platform. Extracts the target platform identifier, the request reason text, and the third user identifier from the command. The server creates a record in the view request table: the status field is set to "Pending Review," the applicant identifier field is set to the third user identifier, the platform identifier field is set to the target platform identifier, the reason field is set to the request reason text, and the request time field is set to the current timestamp.

[0149] S1600: Receives the review and approval operation submitted by the first user, performs two-factor authentication and views the qualification creation.

[0150] S1610: The first user has been detected entering the verification page. A password verification request is returned to the client.

[0151] S1620: Receive the password information submitted by the first user. Call the password verification function to compare the received password with the hash value of the first user's password stored in the database.

[0152] S1630: After the comparison is successful, update the status field of the application record created in step S1520 to "approved".

[0153] S1640: Create a one-time viewing qualification record in the viewing qualification table: write the third user identifier to the grant object field, write the target platform identifier to the platform identifier field, write the current time plus H hours (H is 24) to the expiration time field, and write "unused" to the usage flag field.

[0154] S1650: Create a log record in the security audit log table: Enter "Password View Approval" in the Operation Type field, "First User Identifier" in the Operator field, "Third User Identifier" in the Target User field, "Target Platform Identifier" in the Target Platform field, and the current time in the Timestamp field. The log record should not contain the password in plaintext.

[0155] S1700: Receives a "view password" command initiated by a third user and performs a time-limited single-view process.

[0156] S1710: Query the qualification table for records where the granted object field is "Third User Identifier", the platform identifier field is "Target Platform Identifier", the usage flag field is "Unused", and the expiration time field is greater than the current time. If a valid record is found, continue execution.

[0157] S1720: Immediately update the usage flag field of the view eligibility record to "used". This update operation is performed within a database transaction, using row-level locking to prevent concurrent reuse.

[0158] S1730: Retrieves the encrypted account, encrypted password, and encrypted remarks field values ​​corresponding to the target platform from the password database table. Calls the decryption function, using a server-side dedicated key stored independently of the business database to decrypt and obtain the plaintext account, password, and remarks.

[0159] S1740: The decrypted plaintext data is returned to the client. Upon receiving it, the client renders the plaintext content on the page and simultaneously starts a T-second countdown timer (T is 60). The countdown timer is based on the display expiration timestamp returned by the server (current time plus T seconds) and checks every second. After T seconds, the client performs a DOM cleanup operation to remove the plaintext data and sends a display end notification to the server.

[0160] S1800: Receives a "view password" command initiated by a third user and performs a rejection process after the user has consumed the viewing privilege.

[0161] In step S1800, the server queries the viewing eligibility table for a third user's valid eligibility record for the target platform. The query conditions include the usage flag field being unused and the expiration time field being greater than the current time. Since the usage flag was updated to used in step S1720, the query result is empty. The server returns a response to the client indicating no valid viewing eligibility. Accordingly, the client does not render the "View Password" button, but only the "Request View" button.

[0162] S1810: Receive an unauthorized access request initiated by a fourth user through a direct call to the cryptographic database query interface, and execute the audit log.

[0163] In step S1810, the server-side permission verification middleware intercepts the request, extracts the role identifier of the fourth user, and matches it against the list of legitimate operation roles in the password library module (top manager, department manager, ordinary employee, knowledge base administrator, AI configuration administrator). If the match fails, a 403 Forbidden response is returned. Simultaneously, an unauthorized access audit record is created in the security audit log table: the operation type field is written as "unauthorized access to the password library," the operator field is written as "fourth user identifier," the target platform field is written as "target platform identifier," the result field is written as "rejected," and the timestamp field is written as the current time.

[0164] In steps S1800 and S1810, a combination of encrypted storage, two-factor password verification, time-limited single-view eligibility, automatic deletion, and unauthorized auditing constitutes a multi-layered security protection for sensitive credential data.

[0165] Please refer to the reference. Figure 6 The sixth embodiment of the present invention mainly details the five-level configuration of the global employee communication strategy, the server-side mandatory verification logic, and the mechanism for immediate effect after strategy changes.

[0166] The sixth embodiment of the present invention specifically includes the following steps: S1900: Receives the policy change command initiated by the first user on the "Contacts → Real Employees → Private Chat Permissions" page and updates the global communication policy configuration.

[0167] S1910: Receive policy query request. The server reads the communication policy field value from the system configuration table and returns it to the client to be rendered as the currently selected state.

[0168] S1920: Receive policy update instruction. Extract the new communication mode value from the instruction (employees are generally not allowed to communicate with each other). After the server verifies that the first user has user management permissions, it updates the communication policy field value in the system configuration table to the new mode. After the update is complete, the server broadcasts a permission update event to all online clients. The event type is "Communication Policy Change," and the event body contains the updated policy value.

[0169] S2000: Receives a request from a third user to create a direct session with another employee in the marketing department, and intercepts the creation of the new session after the policy change.

[0170] S2010: Extract the third-party user identifier and the target user identifier from the request.

[0171] S2020: Call the private chat permission verification function. The function first obtains the role identifiers of the third user and the target user, and determines whether both parties are in controlled roles (ordinary employees or department managers). After confirmation, it reads the current communication policy field value from the system configuration table.

[0172] S2030: Proceed to the corresponding conditional branch based on the communication strategy field value. The current value is "employees are not allowed to communicate with each other in principle," and the validation result returns "prohibited." The server refuses to create a session, returns a 403 Forbidden response to the client, and records this denial event in the audit log table.

[0173] S2100: Receives a request from a third user to send a new message in a direct session that existed before the policy change, and performs an immediate blocking of the existing session.

[0174] S2110: Call the session read permission verification function in the message sending process.

[0175] S2120: When the session read permission verification function handles direct session types, it retrieves the other party member identifier from the session member table and calls the private chat permission verification function in step S2020 again. Because the current policy generally prohibits employees from communicating with each other, the verification returns "prohibited," and the message sending request is rejected.

[0176] In step S2100, when a third user attempts to load the historical message list of the session, the server also calls the session read permission verification function to verify permissions in real time. If the verification fails, the server refuses to return historical messages. After the policy is tightened, all unauthorized existing session channels are immediately closed in both the read and send directions.

[0177] S2200: Receives a request from a third user to send a message to the first user, and performs communication permission verification for the highest administrator as an exception role.

[0178] S2210: The server calls the private chat permission verification function. The function first checks the role identifier of the target user (first user) and determines that it has the highest administrator role.

[0179] S2220: Based on the function's built-in role exception rules, if the target role is the highest-level manager, return "Allow" directly without proceeding to the conditional branch of the five-level strategy. The return result is "Communication Allowed".

[0180] In step S2200, the first user sending a message to the third user is also not restricted by the policy, verifying that the constraint scope of the five-level policy only covers the internal staff system.

[0181] Please refer to the reference. Figure 7 The seventh embodiment of the present invention mainly details how the message visibility policy stored independently for each group operates, and how identity display achieves desensitization under the hierarchical control of group policy and global policy.

[0182] The seventh embodiment of the present invention specifically includes the following steps: S2300: Receives the visibility policy configuration instructions submitted by the first user for each group, and establishes differentiated message visibility policies for different groups.

[0183] S2310: Receives policy configuration instructions for Group A (“All Members Notification Group”, type: Real Group). Extracts the visibility mode as “All Members Visible by Real Name”, and associates the session identifier with the mode value and stores it in the session configuration table.

[0184] S2320: Receives policy configuration instructions for Group B (“Brainstorming Group”, type: Mixed Group). Extracts the visibility mode as “All members anonymously visible”, and associates the session identifier with the mode value and stores it in the session configuration table.

[0185] S2330: Receives policy configuration instructions for Group C (“Internal R&D Group”, type: Real Group). Extracts the visibility mode to the default “Isolated Visibility”, and sets the “Department Administrators Can View All Messages” switch to “On”. Associates the session identifier with the above two configuration values ​​and stores them in the session configuration table. All three groups contain three users: First User, Second User, and Third User.

[0186] S2400: Receives messages sent by third-party users in group A, and handles message sending and identity display in the mode where all members can see the message by real name.

[0187] S2410: Query the visibility policy associated with group A from the session configuration table. The message distribution module calls the message visibility judgment function, passing in the session type (real group) and visibility policy configuration. The function detects that the visibility mode is "all members real-name" and is not equal to the isolation mode, and returns "visible to all members". All members in the group can retrieve the message content.

[0188] S2420: In the message serialization function, the identity tag processing module queries the identity display policy of group A from the session configuration table. If the mode is detected as "All members real-name," no anonymization is performed on the sender's name field; instead, the third-party user's account name is used directly as the sender's display name.

[0189] S2500: Receives messages sent by third-party users in Group B, and handles message sending and identity-de-identified display in an anonymous, visible mode for all users.

[0190] S2510: The message visibility determination function detected that the visibility mode of group B is anonymous for all members, which is not the same as the isolation mode, and returned "visible to all members". Both the second user and the first user can retrieve the message content.

[0191] S2520: The identity tagging module detected that Group B's mode is all-anonymous, and further determined the role relationship between the current viewer (second user, department manager role) and the sender (third user, ordinary employee role). Both parties are controlled roles and are not the same person, triggering anonymization processing.

[0192] S2530: The anonymization processing function obtains the name of the department to which the third user belongs, "R&D Department", calls the department anonymity tag generation function, and returns "R&D Department Colleague" as the anonymized sender display name.

[0193] S2535: Before executing the anonymous de-identification function, first query the number of valid members N_dept in the current department. If N_dept≤3, the "small department protection mechanism" is triggered, and the de-identification label is automatically upgraded to a coarser-grained "company-level colleague" (e.g., "XX company colleague"), or a random temporary alias (e.g., "colleague A", "colleague B") is used. The same sender maintains alias consistency within the same session period to prevent identity from being deduced from the number of department members. If N_dept>3, the de-identification label in the format of "department name + colleague" is output according to the original logic.

[0194] S2540: When the first user (the highest-level administrator) views the same message, the identity tag processing module detects that the viewer's role is the highest-level administrator, skips the anonymization process, and directly uses the third user's real name as the sender's display name.

[0195] In step S2500, a layered desensitization effect was achieved, where the message content is visible to all users, but the sender's identity is displayed differently according to the viewer's role.

[0196] S2600: Receives messages sent by a third user in group C (visibility mode is isolated), and handles role-based hierarchical permission judgment in isolated visibility mode.

[0197] In step S2600, the message visibility judgment function detects that the visibility mode is isolated and enters the hierarchical permission judgment logic.

[0198] S2610: Determine if the viewer is the message sender. If the viewer ID is equal to the third user ID, return "Allow viewing".

[0199] S2620: Determine if the viewer is the top administrator. When the viewer is the first user, the function returns "allow" according to the built-in rule (the top administrator can see all messages by default in isolation mode).

[0200] S2630: Determine if the viewer's role is a department manager and if the group has department manager privileges enabled. When the viewer is a second user, the function queries the session configuration table to see if the department manager privilege switch for group C is enabled, and if the second user's role is a department manager, it returns "Allow".

[0201] S2640: When the viewer is another ordinary employee in the group (neither the sender nor the top manager or department manager), none of the above conditions are met, the function returns "prohibited", and the employee cannot retrieve messages from the third user.

[0202] S2650: The identity tag processing module detected that the visibility mode of group C is "isolated," and backtracked to read the identity display mode field value from the global system configuration table. If the global mode is "real name," then the sender of all visible messages will display their real name.

[0203] S2700: Receives the instruction from the first user to change the visibility mode of group A from all members real-name to all members anonymous, and verifies the independence of message visibility policies between groups.

[0204] The server only updates the mode field value of the visibility policy record associated with the A group session identifier in the session configuration table. After the modification, A group member clients receive a policy update notification, and the identity display of newly sent messages immediately switches to anonymous mode. The policy records of groups B and C in the session configuration table remain unchanged, maintaining their original visibility modes and identity display rules.

[0205] In step S2700, it was verified that the message visibility policy is stored independently in the database with the session identifier as the key, the policy configuration of each group is isolated from each other, and modifying the policy of one group does not affect other groups.

[0206] Please refer to the reference. Figure 8 The eighth embodiment of the present invention mainly details how the system automatically selects the most suitable AI employee to answer questions when the user does not explicitly specify an AI, and how it automatically organizes multi-AI collaboration and summarizes the results by the assistant director in cross-domain scenarios.

[0207] The eighth embodiment of the present invention specifically includes the following steps: S2800: Receives business inquiry messages entered by the first user in the "default AI group", performs keyword analysis on the user messages and calculates scores for each AI employee.

[0208] S2810: Call the AI ​​scoring function to convert the message text to lowercase and use it as the scoring input.

[0209] S2820: Iterate through the AI ​​employee configuration table to read records for each AI employee whose status is enabled, and obtain the keyword list associated with each AI employee. Perform a score calculation for each AI employee: iterate through its keyword list, match each keyword in the message text, and accumulate scores for matched keywords by type. The scoring rule is: S = Σw_i.

[0210] Where S represents the final score of the AI ​​employee; w_i represents the weight of the i-th hit keyword. For keywords within the range of strong keywords (2 to 3 characters), the weight w_s is 2; for keywords within the range of ordinary keywords (not less than 4 characters), the weight w_n is 1.5. Taking key AI roles as examples: the strategic analyst's score S_a is approximately 5.5, the R&D assistant's score S_b is approximately 5.5, and the capital allocator's score S_c is approximately 2.

[0211] S2900: Aggregate the scores of all AI employees and perform professional candidate determination and multi-level ranking.

[0212] S2910: Perform professional candidate determination. The determination condition is: S≥S_min and (N_strong>0 or S≥S_th).

[0213] Wherein, S_min is the minimum score threshold, with a value of 2; N_strong is the number of strong keyword hits; and S_th is the independent score threshold, with a value of 3. Strategic analysts meet the criteria (S_a=5.5, N_strong>0), and R&D assistants meet the criteria (S_b=5.5, N_strong>0), thus becoming professional candidates. Capital allocators, due to S_c=2 and N_strong=0, do not meet the criteria and are not considered professional candidates.

[0214] S2920: Perform multi-level sorting on the professional candidate list. The sorting rules are as follows: Level 1 is sorted in descending order by score S; if scores are the same, they are sorted in descending order by the strong match number N_strong in Level 2; if still the same, they are sorted in ascending order by the routing priority value in Level 3. The strategic analyst has a priority value of 2, and the R&D assistant has a priority value of 5. Since both have the same score and strong match number, they are sorted in ascending order by priority, with the strategic analyst ranked first (primary candidate) and the R&D assistant ranked second.

[0215] S3000: Performs cross-domain decisions and organizes multi-AI collaborative orchestration.

[0216] S3010: Execute cross-domain decision-making logic. Obtain the number of professional candidates N_c=2, N_c>1, which satisfies the basic quantitative conditions for cross-domain collaboration.

[0217] S3020: Perform collaboration intent recognition on user message text and detect whether it contains explicit collaboration trigger words. No collaboration trigger words were detected in the first user's message.

[0218] S3030: Check whether the second candidate score S_b satisfies the cross-domain threshold condition: S_b≥max(S_min,S_a×r).

[0219] Where S_min is 2, and r is the proportionality coefficient with a value of 0.5. Substituting into the calculation: max(2,5.5×0.5)=max(2,2.75)=2.75, S_b=5.5≥2.75, the condition is met.

[0220] S3040: All conditions for cross-domain collaboration are met, and the system decides to initiate multi-AI collaboration. The final number of AIs participating in the collaboration, K: K = min(N_c, K_max).

[0221] Here, K_max represents the maximum number of collaborative AIs, which defaults to 3. In this case, K=min(2,3)=2, selecting a strategic analyst and a research assistant.

[0222] S3050: Create two parallel invocation tasks, each injecting the first user's message text, their respective role prompts, associated knowledge base scope, and associated memory scope into their respective invocation contexts, sending requests to their respective associated model interface addresses, and obtaining their respective responses.

[0223] S3055: The token consumption and billing rules for multi-AI collaboration scenarios are as follows: S3055a: The model call consumption of each specialized AI employee (i.e., all AIs participating in the collaboration except for the summary AI) is deducted from the global authorization quota of each AI for the current user. If any AI employee is not within the current user's authorization range or its remaining quota is insufficient, that AI will not participate in this collaboration, and only the AI ​​that has been successfully called will provide the answer.

[0224] S3055b: The model call consumption of the aggregated AI (i.e., the AI ​​with the highest routing priority) is deducted separately from the current user's global authorization quota. If the current user has not configured aggregated AI authorization, the consumption of aggregated AI will be deducted from the current user's global authorization quota, and the timeout timer in S2 will not be started (automatic failure recovery is canceled), and the overall timeout of the collaborative task will be managed uniformly.

[0225] S3055c: Parallel call tasks share the total amount of Tokens reserved in step S2, instead of reserving them independently.

[0226] In S225, the formula for calculating the reserved value P_res is adjusted to: P_res = Σ(T_in_i + O_i) + T_in_summary, where i iterates through all participating professional AI employees, and T_in_summary is the estimated number of input tokens for the summarized AI. The sum of the above reserved values ​​does not exceed the current user's remaining available quota R.

[0227] S3060: After both AI responses are returned, retrieve the configuration information of "Assistant Dong" (with routing priority 1), call the Assistant Dong's model interface, and use the strategic analyst's and R&D assistant's responses as context input, along with a summary instruction. Assistant Dong integrates the two responses in a logical order: first market analysis, then technical capabilities, and finally budget recommendations, generating a structured comprehensive response. This comprehensive response is then returned as the final response to the first user's client.

[0228] S3100: Detects whether the user has explicitly specified AI and performs route coverage processing.

[0229] S3110: If the first user explicitly specifies "Capital Allocator" in the message via @mention, the system detects the explicit identifier before step S2800, skips all automatic routing and collaborative orchestration processes from S2800 to S3060, directly reads the configuration information of the Capital Allocator from the AI ​​employee configuration table, and initiates a single AI call.

[0230] S3120: If the first user specifies an AI employee identifier that is not within its authorized scope, the system will detect the lack of authorization during the permission verification stage of the message processing pipeline, refuse to process the request, and return a permission error response to the client.

[0231] Please refer to the reference. Figure 9 and Figure 10 This is the ninth embodiment of the present invention. In this ninth embodiment, the complete process of the knowledge base from document uploading, parsing, retrieval to AI referencing is described in detail, as well as how the dual-permission filtering mechanism prevents unauthorized access.

[0232] The ninth embodiment of the present invention specifically includes the following steps: S3200: Receives the document upload request submitted by the sixth user and performs document storage and parsing index establishment.

[0233] S3210: Extract file data from the request, title "Component Selection Specification", category "R&D Department / Technical Specification", and access scope settings ("R&D Department Members" and "Second User").

[0234] S3220: Store the file to a secure storage path and generate a file storage identifier. Create a record in the knowledge document table with the following field values: Title field: "Component Selection Specification", Category field: "R&D Department / Technical Specification", Uploader field: Sixth User Identifier, Version Number field: "V2.0", Access Scope field: List of authorized objects (R&D Department members, Second User), Storage Identifier field: File Storage Identifier, Status field: Valid.

[0235] S3230: Asynchronously start the document parsing task. The task reads the file content from the secure storage path, extracts the text, calls the tokenizer to split the text into a list of terms, creates an inverted index record for each term to the document identifier, and writes them in batches to the knowledge base index table.

[0236] S3240: After parsing, receive the retrieval verification request from the sixth user. Call the knowledge base retrieval function to confirm that the newly uploaded document can be correctly matched.

[0237] S3300: Receives a "Component Sensitivity Standard" search request initiated by a third user on the "Knowledge Base" page, executes the authorized user search, and triggers AI citation sources.

[0238] S3310: Call the knowledge base retrieval function. Perform word segmentation on the query text: convert to lowercase, split by non-alphanumeric characters, filter words shorter than L_min (L_min is 2), and retrieve the top W words (W is 20) to obtain the query term list. Query the knowledge document table for a list of documents accessible to a third user (matching by the access scope field). For each document, query the knowledge base index table for the match status of each query term, and calculate the total number of matches as the retrieval score. Sort by score in descending order, and if scores are the same, sort by document creation time in descending order, and return the top D documents (D is 4).

[0239] S3320: For each search result document, locate the position of the first hit word, extract the B_total characters (360 characters) starting from the B_before characters (take 80) before that position, generate a summary fragment and return it.

[0240] S3330: Receives query requests initiated by third users in one-on-one chats with "R&D Assistant". When constructing the AI ​​context, the aforementioned search results are injected as source information.

[0241] S3340: When the R&D assistant's AI model generates an answer, it provides parameter information based on the document content in the context and adds a source citation. When the third user clicks the source citation, the client requests the original document from the server and renders and displays it.

[0242] S3400: Receives a search request for "component sensitivity standards" from another employee in the marketing department and performs dual-access filtering.

[0243] S3410: First layer of filtering. When the server iterates through the document list in step S3310, it matches the access scope field of the "Component Selection Specification V2.0" document: the authorized objects are "R&D Department Members" and "Second User." The current user being queried belongs to the Marketing Department and is not within the authorized scope. The permission filtering function returns "Not visible," and this document is not included in the search score calculation.

[0244] S3420: Second Filtering. The employee asked the same question in a one-on-one chat with the "AI Knowledge Base Q&A Assistant." When performing a knowledge base search, the system again executes the same permission filtering logic as in step S3410. Simultaneously, it verifies the knowledge base access permissions associated with the current AI employee (Knowledge Base Q&A Assistant) to confirm that the R&D department's technical specification category is not within this range. Both filters fail, and the document content is not injected into the AI ​​context.

[0245] In step S3400, it is verified that permission filtering occurs in the user-initiated retrieval stage and the AI ​​context injection stage, and permission verification is performed independently in the two stages.

[0246] S3500: Receives new document upload requests and old version invalidation instructions submitted by the sixth user, performs document version update, and synchronizes the index with the old version for automatic filtering.

[0247] The server stores the new version of the file (V3.0), creates a new record in the knowledge document table (with the status field written to be valid), and triggers an asynchronous index parsing task. At the same time, the status field of the old version V2.0 document record is updated to invalid.

[0248] In step S3500, the knowledge base retrieval function appends a status field to the document traversal query conditions, which must be a valid filter condition. V2.0 documents with an invalid status are automatically excluded from the search scope. Both V2.0 and V3.0 document records are retained in the knowledge document table, supporting historical version lookup.

[0249] Please refer to the reference. Figure 11 The tenth embodiment of the present invention verifies the permission model that separates system management rights from business data rights primarily through a series of unauthorized access attempts and legitimate management operations.

[0250] The tenth embodiment of the present invention specifically includes the following steps: S3600: Receives an unauthorized access request initiated by a fourth user through direct invocation of the session message query interface, and performs interception processing on the business session data.

[0251] S3610: The session read permission verification function determines whether the session type is a direct session or a real group, and queries the member list of the session. It was detected that the fourth user is not in the member list, and their role is system administrator.

[0252] S3620: According to the access control rules, system administrators who are not members of the business session are prohibited from accessing the system. The function returns "prohibited". The server returns a 403 Access Denied error response to the client.

[0253] S3700: Receives unauthorized access requests initiated by a fourth user through direct calls to the dashboard interface and performs interception processing of AI usage data.

[0254] S3710: The permission verification logic extracts the role identifier (system operator) and permission list of the fourth user and checks whether it has task management permissions. If the permission item is not included in the permission list, the verification fails.

[0255] S3720: Access request denied and a permission error response returned.

[0256] In step S3700, dashboard data access permissions are granted only to the highest-level administrator role and authorized specific administrator roles.

[0257] S3800: Receives an unauthorized access request initiated by a fourth user through a direct call to the cryptographic database query interface, and performs interception processing on sensitive credential data.

[0258] S3810: The password repository module's permission verification middleware intercepts the request, extracts the role identifier of the fourth user (system administrator), and matches it against the password repository module's preset list of legitimate operation roles. The list of legitimate operation roles includes: top administrator, department administrator, ordinary employee, knowledge base administrator, and AI configuration administrator. The system administrator role is not in this list, so the match fails.

[0259] S3820: Returns a 403 Forbidden error response. Simultaneously, creates an unauthorized access audit record in the security audit log table.

[0260] S3900: Receives a legitimate management operation request initiated by the fourth user and executes the corresponding data processing normally.

[0261] S3910: After verifying that it has the corresponding management permissions, it normally performs operations such as creating new users, modifying department structure, and configuring client update policies, and returns a success response.

[0262] In step S3900, through the comparison of the above four scenarios, it is verified that system management rights (user management, department management, system configuration) and business data rights (chat logs, dashboards, password database) are independent of each other in terms of permission model. The system operator role does not have business data access rights, and unauthorized access requests are intercepted and recorded in the audit log.

[0264] Please refer to the reference. Figure 12 and Figure 13 This is the eleventh embodiment of the present invention. In this eleventh embodiment, a closed loop for enterprise task execution that is traceable, predictable, and auditable is mainly achieved through domain-based access control, multi-person collaboration, single-responsibility, dual-cutoff monitoring, red-yellow-green early warning, serial approval snapshots, and event time statistics.

[0265] The eleventh embodiment of the present invention specifically includes the following steps: S4000: Receives task dashboard permission configuration instructions, executes three-dimensional permission configuration and stores them.

[0266] S4010: Receives instructions to configure permissions for the second user (department manager), and writes the extracted permission configuration items into the user permission table and user settings table.

[0267] In step S4010, the permission configuration items for the second user include: setting the task management permission to allow, setting the permission to assign tasks on behalf of others to allow, setting the visibility range of the dashboard to the department range, and setting the identity display mode to the name mode.

[0268] S4020: Receives instructions to configure permissions for a third user (ordinary employee), and writes the extracted permission configuration items into the user permission table and user settings table.

[0269] In step S4020, the third user's permission configuration items include: setting task management permission to disabled and setting the visibility of the dashboard to only be relevant to the user.

[0270] In step S4000, task management permissions are divided into four independent dimensions: whether tasks can be created and managed, whether tasks can be assigned to others, the visibility range of the Kanban board, and the display mode of the participant's identity. Each dimension is independent of the others, thus achieving a fine-grained breakdown of permissions.

[0271] S4100: Receives task list query requests and performs visibility filtering based on relation domains.

[0272] S4110: Extract the current user ID and user permission configuration from the request. If the user role is the highest administrator, return the complete task list directly.

[0273] S4120: If the user's dashboard visibility is configured to be company-wide, return the company-wide task list.

[0274] S4130: If the user's dashboard visibility is configured to be only related to themselves, call the relationship determination function to filter task records that meet the conditions and return them.

[0275] In step S4130, the system determines whether any of the following associations exist between the current user and the task record: the current user is the task owner, the current user is the task publisher, the current user belongs to the execution member set, or the current user belongs to the approver set. If any of these associations are satisfied, the task is determined to be visible to the current user. Let the task owner be denoted as o(t), the task publisher as c(t), the execution member set as A(t), and the approver set as P(t). Then, the relationship determination result V(u,t) is true if and only if any of the following conditions are met: u=o(t), or u=c(t), or u∈A(t), or u∈P(t); Where u is the current user and t is the task record. V(u,t) is true when task t is visible to user u.

[0276] S4140: If the user's dashboard visibility range is configured as department range, perform department range filtering based on step S4130.

[0277] In step S4140, the department scope filtering rule is: additionally filter tasks in the member set that belong to the same department as the user. If the user has no valid department, it automatically falls back to the scope that only relates to the user.

[0278] In step S4100, list queries, historical queries, detail queries, result approvals, and attachment retrieval all use the same visibility condition. When directly requesting details or attachments using a known task identifier, the system re-executes the visibility calculation, without relying on the hidden entry point on the front end.

[0279] S4200: Receives instructions to create a multi-person collaborative task, performs validity checks, and creates a task record.

[0280] S4210: Extract task configuration data from the instruction and call the validity verification function.

[0281] S4220: Verify the size of the execution member set; verification passed.

[0282] In step S4220, the set of execution members after deduplication is denoted as A, and the number of its members satisfies: 1≤|A|≤50; where |A| is the number of elements in set A.

[0283] S4230: Verify the legitimacy of the person in charge; verification passed.

[0284] In step S4230, if the number of execution members is greater than 1, the person in charge r must be explicitly specified, and the person in charge belongs to the set of execution members, that is: r∈A; S4240: Verify the legality of the set of approvers; verification passed.

[0285] In step S4240, the reviewer set P satisfies: 1≤|P|≤5; and the reviewer set is mutually exclusive with the executor member set, that is, A∩P is an empty set.

[0286] S4250: Verify the time configuration of the phase node, and the verification is passed.

[0287] In step S4250, the final delivery deadline is denoted as d_f, and for any phase node k, its deadline is denoted as d_k, which is required to satisfy: now<d_k≤d_f; where now is the current time.

[0288] S4260: After all verifications are passed, create and save a record in the task table.

[0289] In step S4260, the status field of the task record is written as in progress, the progress status field is written as green, and the executor member set, person in charge identifier, ordered reviewer set and phase node configuration are stored at the same time.

[0290] In step S4200, the final delivery permission is limited exclusively to the person in charge: only when the operating user identifier is equal to the task person in charge identifier, is the submission of the final deliverable allowed. The phase report and status update permissions are open to all executor members: the operation can be performed as long as the operating user identifier belongs to the executor member set.

[0291] S4300: Execute the multi-person collaboration and sole person-in-charge submission mechanism.

[0292] S4310: Receive a phase report request submitted by a user belonging to the executor member set. Verify that the operating user identifier belongs to the task executor member set, and if the verification is passed, the submission is allowed.

[0293] S4320: Receive a final deliverable request submitted by the person in charge. Verify that the operating user identifier is equal to the task person in charge identifier, and if the verification is passed, store the deliverable submission timestamp and the deliverable status in the deliverable table.

[0294] S4330: Receive a final deliverable request submitted by a user who is not the person in charge. Verify that the operating user identifier is not equal to the task person in charge identifier, the verification fails, and a permission error response is returned.

[0295] S4400: Execute overdue judgment based on the actual submission time.

[0296] S4410: Obtain the submission timestamp of the currently valid deliverable from the deliverable table, and call the overdue judgment function.

[0297] In step S4410, the deadline for task t is denoted as d_f, the actual submission time of result s is denoted as t_s, the current time is denoted as now, and the overdue judgment result is denoted as W. A valid result refers to a result submitted by the task leader and whose status is pending approval or approved. The overdue judgment rule is as follows: W = No expiration, when task t has no valid deadline; W = No expiration, when there is a valid result s and t_s≤d_f; W = Overdue, when there is a valid result s and t_s > d_f; W = Overdue, when there are no valid results and now > d_f.

[0298] In step S4400, tasks submitted before the deadline and awaiting approval after the deadline are considered within the time limit; tasks submitted after the deadline are considered overdue. The overdue determination is based on comparing the actual submission time of the deliverable with the deadline, rather than the approval completion time, thus separating the execution time from the approval waiting time. The approval waiting time is not included in the overdue delivery determination.

[0299] S4500: Dual deadline monitoring for execution phase nodes and final delivery.

[0300] S4510: Iterate through each stage node of the task configuration and check if the current time exceeds the node's deadline.

[0301] S4520: If a node expires and there is no corresponding stage report record, the node is determined to be a missed report node, and a node warning is triggered.

[0302] In step S4500, each task can have up to 12 stage reporting nodes, and the final delivery time and stage node time form a dual deadline monitoring system.

[0303] S4600: Perform timed automatic early warning scan.

[0304] S4610: Scan task records in the task table that meet preset status conditions.

[0305] In step S4610, the preset state conditions are: the task status is in progress, the progress status is green, and it has not been deleted or archived.

[0306] S4620: Check the delivery trigger conditions for each record. If they are met, trigger an alert.

[0307] In step S4620, the existence of valid on-time deliverables is denoted as V(t), which means: there exists a deliverable submitted by the responsible person, with a status of pending approval or approved, and a submission time earlier than or equal to the deadline. The delivery trigger condition X_1 is true if and only if: d_f ≤ now and V(t) is not true.

[0308] Where d_f is the task deadline and now is the current time.

[0309] S4630: Check node trigger conditions. If met, trigger an alert.

[0310] In step S4630, the existence of the reporting record corresponding to stage node k is denoted as Y(k). The node triggering condition X_2 is true if and only if: there exists a stage node k such that d_k≤now and Y(k) is not true (i.e., the node does not have a corresponding stage reporting record).

[0311] Where d_k is the deadline of stage node k.

[0312] S4640: Perform an atomic update within a database transaction, changing the progress status field of a task record that meets the triggering condition from green to yellow.

[0313] In step S4640, the update condition is accompanied by concurrency protection while the current progress status remains green. Upon successful update, a delayed notification is sent to all executing members and the publisher, and written to the audit log.

[0314] In step S4600, the automatic warning only allows green to be changed to yellow, without overwriting manually set yellow or red, and does not automatically revert to green.

[0315] S4700: Receives a request from the person in charge to submit the final deliverables and creates a serial approval snapshot.

[0316] S4710: Extract the current ordered list of approvers from the task configuration and create a separate approval snapshot for this submission.

[0317] In step S4710, the orderly list of approvers is denoted as [p_1, p_2, ..., p_n], where p_1 is the first approver and p_n is the last approver. The approval snapshot corresponding to the k-th submission is denoted as R_k, and its initial state is: R_k = [(p_1, pending approval), (p_2, waiting), ..., (p_n, waiting)]. The first approver's status is set to "Pending Approval," while the status of the remaining approvers is set to "Waiting." Snapshots are saved in association with the submitted deliverables.

[0318] S4720: Receive approval action from the approver. Verify if the current approver's status in the snapshot is "Pending Approval". If the verification passes, change the current approver's status to "Approved".

[0319] S4730: If a next pending node exists, activate that node as pending approval. If the current node is the last approval node, change the result status to approved, the task is completed, and archived.

[0320] S4740: If any approver returns the application, change the status of the result to rejected and change all subsequent pending nodes to skipped.

[0321] In step S4740, the person in charge may resubmit the application with an increasing number of attempts after it has been rejected, thus creating a new independent approval snapshot.

[0322] In step S4700, the submitter can only withdraw the submission voluntarily while the result is still pending approval and no decision has been made at any stage. Withdrawal does not count towards the rejection count. The approval chain of historical submissions is not affected by subsequent task configurations or personnel changes.

[0323] S4800: Receives reminder requests and performs persistent reminder cooling-off checks.

[0324] S4810: Check if the task is still in progress and has not been archived or deleted. If not, return an error response.

[0325] S4820: Retrieve the most recent reminder time for this task from the reminder record table. If the cooldown condition is met, return a restricted access response.

[0326] In step S4820, the most recent reminder time for the task is denoted as t_u, the preset cooldown time is denoted as C (with a value of 24 hours), and the current time is denoted as now. The cooldown condition U(t) is true if and only if the following three conditions are met simultaneously: the task is still in progress; the task has not been archived or deleted; there is no historical reminder record, or now ≥ t_u + C. When the cooldown condition is met, a restricted access response is returned, with the next available reminder time attached to the response.

[0327] S4830: When the cooldown period has expired or there is no historical reminder record, check the last reminder time in the database transaction and insert a new reminder record, and send a reminder notification to all execution members.

[0328] In step S4800, the cooling check and new record insertion are completed in the same database transaction to prevent concurrent bypassing of the cooling limit.

[0329] S4900: Perform performance indicator calculations based on sole responsible party attribution.

[0330] S4910: Obtain the set of tasks with the target user as the sole responsible party, and statistically analyze performance-related variables.

[0331] In step S4910, the statistical variables include: T is the number of still valid responsible tasks, D is the number of completed tasks, R is the total number of times non-withdrawn results were rejected, and O is the number of overdue tasks.

[0332] S4920: Calculate the completion rate and overdue rate using the following formula: C_rate = D / (T+R) × 100%; O_rate = O / T × 100%; Where C_rate is the completion rate and O_rate is the overdue rate. The result is rounded to one decimal place, and the result is zero when the denominator is zero.

[0333] In step S4900, failed archiving tasks are counted in T but not in D. Cancelled tasks that are normally completed or softly deleted by the top administrator are not counted in T. Each non-withdrawn rejected result increases R by 1; actively withdrawn results do not increase R. Tasks submitted on time and awaiting approval are not included in O.

[0334] Please refer to the reference. Figure 14 and Figure 15 The twelfth embodiment of the present invention. In the twelfth embodiment, a manageable enterprise-level visual content production process is achieved mainly through structured briefings, constraint hints arrangement, model whitelists, idempotent billing, multi-reference graph panelization, scheme genealogy, division of labor between AI background and deterministic layout, manual review, and local protected storage.

[0335] The twelfth embodiment of the present invention specifically includes the following steps: S5000: Receives instructions to create creative projects and stores structured briefing data.

[0336] S5010: Extract structured briefing data from the instructions and store it in the project table.

[0337] In step S5010, the structured briefing data includes: project type, purpose, target audience, distribution channels, core information, visual direction, mandatory requirements, and prohibited content.

[0338] S5020: Verify the user's project visibility settings and perform range convergence processing.

[0339] In step S5020, the scope convergence rule is as follows: if the user is not the highest-level manager and the scope is set to the entire company, the server automatically converges to the individual scope. If the user has no valid department and the scope is set to the department, it automatically converges to the individual scope.

[0340] S5100: Receive reference diagrams and perform multi-reference diagram deterministic numbering panelization.

[0341] S5110: Get the number of reference images uploaded by the user. If the number of reference images is 1, use the original reference image copy directly.

[0342] S5120: If the number of reference drawings is greater than 1, synthesize a numbered reference board according to the preset grid layout.

[0343] In step S5120, the number of reference images is denoted as n, the canvas width as W_c, and the canvas height as H_c. The compositing rules are as follows: arranged in a 2-column grid, W_c is 2048 pixels; when n does not exceed 2, H_c is 1152 pixels, and when n is 3 to 4, H_c is 2048 pixels. Each cell uses a proportionally scaled and centered reference image, with numbered labels starting from 1, and output at JPEG quality 86.

[0344] In step S5100, a maximum of four input graphs are used in a single generation. The parent scheme is placed first in the reference set when further optimization or variants are performed.

[0345] S5200: Performs reference graph adaptive compression processing.

[0346] S5210: Calculate the volume of the reference image after transmission. If it does not exceed the preset limit, use the original image directly.

[0347] S5220: If the preset limit is exceeded, try compression sequentially according to the preset size-quality gradient.

[0348] In step S5220, the size quality gradients are as follows: 84 for a side length of 2400 pixels, 78 for a side length of 2048 pixels, 72 for a side length of 1600 pixels, and 66 for a side length of 1280 pixels. Each compression uses proportional scaling to maintain image integrity. If all attempts still exceed the limit, an "oversized content" error response is returned. Only a transfer copy is generated; the original enterprise file is not overwritten.

[0349] S5300: Receives generation requests, performs model whitelist intersection and requests fingerprint idempotent protection.

[0350] S5310: Call the model validity calculation function to calculate the set of valid models.

[0351] In step S5310, the model set in the system directory is denoted as M_s, the model set configured in the company whitelist is denoted as M_c, and the available model set returned in real time by the supplier token is denoted as M_t. The effective model set M is the intersection of the three, that is: M = M_s ∩ M_c ∩ M_t; when the supplier directory reading fails, M is the intersection of M_s and M_c, and an alarm without a key is recorded.

[0352] S5320: Construct a request specification object and calculate the request fingerprint.

[0353] In step S5320, the request specification object is denoted as Q, which includes the project identifier, final prompt word, negative prompt, size, quantity, reference diagram identifier list, parent scheme identifier, generation mode, and model. The request fingerprint F is the SHA-256 hash value of the serialized string Q, i.e.: F=SHA256(Q); Let the creator identifier be denoted as u, the client request identifier be denoted as r, and the idempotent key I_k is composed of the two, that is: I_k=(u,r); S5330: Perform idempotency check.

[0354] In step S5330, if the same client request identifier and fingerprint already exist for the same user, the existing task result is returned, and the supplier is not called again. If the same request identifier corresponds to different fingerprints, a conflict error response is returned.

[0355] S5400: Perform atomic reservation of image quota.

[0356] S5410: Query the user's image-generated credit limit by daily and monthly cycles.

[0357] In step S5410, the daily cycle key uses the date format of the Asia-Pacific Shanghai time zone, and the monthly cycle key uses the year-month format. The daily limit is denoted as L_d (a value of 0 indicates no limit), the monthly limit is denoted as L_m, the number of images reserved or used on the current day is denoted as U_d, the number of images reserved or used in the current month is denoted as U_m, and the planned number of images to be generated is denoted as n (a value ranging from 1 to 4).

[0358] S5420: Check quota constraints.

[0359] In step S5420, the credit limit constraint conditions are: both the daily credit limit condition and the monthly credit limit condition are satisfied. Specifically, the daily credit limit condition is either L_d=0 or U_d+n≤L_d; the monthly credit limit condition is either L_m=0 or U_m+n≤L_m. If either credit limit condition is not met, the request is rejected.

[0360] S5430: Create a generation task record within a database transaction, set its status to "Running," and its quota status to "Reserved." Replaying requests from the same client will not add new quotas.

[0361] S5500: Performs structured prompt word arrangement and invokes AI generation.

[0362] S5510: Select a strategy template based on the project type.

[0363] In step S5510, different types correspond to different strategic focuses: e-commerce main images emphasize the separation of the product subject and background, social media emphasizes visual impact and thumbnail readability, and industrial design emphasizes structural clarity and material reproduction.

[0364] S5520: Concatenate the final positive and negative prompts in sequence.

[0365] In step S5520, the final positive prompt is denoted as P_f, which is concatenated in the following order: P_f = S_t + T_p + B_s + G_r + G_i + B_b + U_p + C_d + C_s; Wherein, S_t represents the type strategy, T_p represents the project title, B_s represents the structured briefing content, G_r represents the semantic guidance of the reference diagram, Gi represents the iteration guidance, B_b represents the brand rule constraints, U_p represents the user's supplementary prompts, C_d represents the delivery constraints, and C_s represents the security constraints. Negative prompts are merged from user-inputted negative prompts and prohibited content in the project. In iteration mode, all identities, proportions, structures, and compositions that have not been required to be modified are preserved during optimization; in iteration mode variants, the identifiable subject and design language of the parent scheme are preserved.

[0366] S5530: Send the assembled prompts, reference image panels, and model parameters to the image supplier's interface and receive the generated results.

[0367] S5600: Securely reads and stores the results of external image processing locally.

[0368] S5610: Perform a security check on the image URLs returned by the supplier.

[0369] In step S5610, the security checks include: protocol check (only HTTPS is allowed by default), internal network address check (local addresses, local domain names, and protected internal network IPs are prohibited), and DNS resolution check. HTTP redirection uses manual mode with a timeout of 600 seconds and a file size limit of 25MB.

[0370] S5620: Based on the file magic number recognition format, after successful verification, download to the local protected directory. In step S5620, recognizable formats include PNG, JPEG, and WebP. Subsequent reads re-verify item permissions.

[0371] S5700: Performs AI background and deterministic typesetting division of labor synthesis.

[0372] S5710: Receives the user-selected AI background image and compositing configuration.

[0373] In step S5710, the composition configuration includes page layout, Chinese main title, subtitle, price, action information, and legal notice.

[0374] S5720: Load brand package resources and calculate text panel size and position based on layout.

[0375] In step S5720, the original image width is denoted as W_i, the original image height as H_i, the panel width as W_p, the panel height as H_p, and the panel inner margin as P_in. The brand package resources include the logo, primary color, accent color, and font. The layout calculation rules are as follows: W_p = 0.46 × Wi (when the page position is on the left or right); H_p = 0.44 × H_i (when the page position is at the bottom); P_in=0.085×min(W_p,H_p); where min represents taking the smaller value.

[0376] S5730: Calculate the title font size and logo scaling.

[0377] In step S5730, the title font size is calculated hierarchically according to the canvas reference size, and line breaks are estimated. The main title is limited to a maximum of 2 lines. The logo is scaled proportionally to the safe area of ​​the panel without changing the original proportions.

[0378] S5740: Synthesize and save the final image locally on the server.

[0379] In step S5740, the finished product retains the original background image width and height, is saved in PNG format, and records the source background identifier, logo identifier, text content, layout, and color tone.

[0380] In step S5700, AI is responsible for generating the background, scene, product atmosphere, and visual orientation, while the server locally synthesizes the company's accurate logo, Chinese title, price, action information, and legal statement, reducing the risk of AI generating typos and fake logos.

[0381] S5800: Establish scheme lineage tracing relationships when saving generated assets.

[0382] S5810: Save a traceability field for each generated asset.

[0383] In step S5810, the traceability fields include: generation task identifier, parent asset identifier, reference map asset identifier set, generation mode (new, optimized, or variant), model used, version number, and revised prompt word.

[0384] S5820: Establish a parent asset association for the finished product synthetic asset.

[0385] In step S5820, the finished synthetic asset uses the selected AI background as the parent asset and records the associated Logo asset identifier. The finished synthetic asset can no longer be used as a source of AI iteration.

[0386] In step S5800, all assets form a directed graph structure, and any authorized user can view the complete traceability link from the original generation to the final product.

[0387] S5900: Execute the creative project status flow and review closed loop.

[0388] S5910: Project status flows according to the preset state machine.

[0389] In step S5910, the state machine includes: draft, generating, selecting, modifying, pending review, approved, and archived.

[0390] S5920: Received approval action submitted by the reviewer. The project status changes from pending review to approved, and can then be archived.

[0391] S5930: Received a request for revision from the reviewer. The project status changes from "Pending Review" to "Requires Modification." The user modifies or regenerates the project and resubmits it for review.

[0392] S5940: Exception recovery from supplier failure or result saving failure.

[0393] In step S5940, if the project already has historically generated assets, it returns to the selection state; otherwise, it returns to the draft state. Failed tasks record error codes and release image credits. Model errors do not automatically switch models and trigger re-billing; user confirmation is required.

[0394] The above twelve embodiments together constitute the complete intelligent collaboration system of this invention. It features server-side mandatory verification, a closed loop of AI generation and manual confirmation, traceability of business objects, authorization down to data reading, and concurrent security under transaction protection.

[0395] The specific embodiments described herein are merely illustrative of the spirit of the invention. Those skilled in the art to which this invention pertains may make various modifications or additions to the described specific embodiments or use similar methods to replace them, without departing from the spirit of the invention or exceeding the scope defined by the appended claims.

Claims

1. A structured identity-based intelligent agent and enterprise multi-domain collaboration system and method, characterized in that, Includes the following steps: S1: The server receives the configuration instruction, extracts the configuration data from eight configuration elements: responsibility text, answer boundary, model call parameters, knowledge base access scope, tool permissions, memory scope, risk level and related action list, and stores the configuration data in the AI ​​employee configuration table to complete the definition of AI employees. S2: In response to the AI ​​call request initiated by the user, query the AI ​​authorization table to perform permission verification. After the verification is successful, call the quota reservation function to calculate the remaining available quota R=max(0,LUP) based on the total quota L of the authorization record, the number of used tokens U and the number of reserved tokens P. Then, perform reservation condition judgment based on the estimated number of input tokens T_in and the preset minimum output token reservation value O_min. S3: Construct a dialogue context, retrieve valid memories based on the memory range associated with the AI ​​employee, sort them according to relevance scores, and inject them into the context; perform permission filtering and document retrieval based on the knowledge base access range associated with the AI ​​employee, and then inject the context. S4: Send the constructed context to the model interface associated with the AI ​​employee. After receiving the response returned by the model, use a three-level degradation value retrieval strategy to obtain the actual number of consumed Tokens U_actual and perform usage settlement. S5: The server stores memory records in the organization memory table. The memory records contain at least a memory level field and a status field. The memory level values ​​include private, personal long-term, group, department, and company. The status values ​​include pending confirmation, confirmed, corrected, and expired. When retrieving memories, records with a status of pending confirmation or expired are automatically filtered. In group chat scenarios, records with a memory level of private are automatically filtered. S6: When a high-risk action type that hits the preset action list is identified in the response returned by the model, the system intercepts the output and generates a corresponding action draft record. The business operation can only be executed after manual confirmation and multiple verifications. S7: The server performs permission verification based on role identifiers, and sets independent access permissions for business session data, AI usage data and sensitive credential data. The system management role does not have access permissions for business data.

2. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity according to claim 1, characterized in that, The extraction of configuration data from the eight configuration elements in step S1 specifically includes the following sub-steps: S11: Extract the role responsibility text content from the first input command and store it in the responsibility field; S12: Extract the response boundary text from the second input instruction and store it in the boundary field; S13: When the instruction contains an inherited global model configuration identifier, establish a reference association between the AI ​​employee record and the global model configuration record; when the instruction contains an independently specified identifier, extract and store the independent model configuration parameters. S14: Extract the selected target category identifier from the knowledge base access scope selection instruction, traverse the knowledge base classification tree to obtain a list of all subcategories under the category, and associate and store each category identifier with the access permission identifier of the AI ​​employee. S15: Extract the list of selected tool permission options from the tool permission check command and store them in association; S16: Extract the list of selected memory level options from the memory range selection command and store them in association; S17: Extract the selected risk level identifier from the risk level selection instruction, query the corresponding set of behavioral rules from the preset risk level configuration table, and store them in association; S18: In response to the risk level identifier, query the list of actions associated with the risk level from the preset manual confirmation rule base and store them in association.

3. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity according to claim 1, in step S2: calling the quota reservation function to calculate the remaining available quota R based on the total quota L of the authorization record, the number of used tokens U, and the number of reserved tokens P, specifically includes the following sub-steps: S21: Read the total authorized limit L, the number of used tokens U, and the number of reserved tokens P from the database authorization record, and calculate the remaining available limit R=max(0,LUP); S22: Call the message token estimation function, traverse each message in the message list and perform character-level estimation: T_est=N_cjk+ceil(N_other / 4)+C, where N_cjk is the number of Chinese characters, N_other is the number of non-Chinese characters, C is a fixed cost and takes the value 4, and sum T_est of all messages in the message list to obtain the total input estimated token sum T_in; S23: Check if the remaining quota meets the reservation condition: R≥T_in+O_min, where O_min is the minimum reserved value of the output Token and its value is 16; if it does not meet the condition, intercept the request and return a quota exhaustion error; S24: Calculate the number of output tokens O=min(O_max,R-T_in), where O_max is the default maximum output token value and takes the value 2048; calculate the total number of reserved tokens P_res=T_in+O, update the reserved token field in the database authorization record to P+P_res, and start the timeout timer with a timeout duration D of ten minutes. S25: After the model is invoked, the actual number of Tokens consumed, U_actual, is obtained using a three-level degradation value retrieval strategy. The number of Tokens used is updated to min(L,U+U_actual), and the reserved Token field is restored to its original value P.

4. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity according to claim 1, in step S3: retrieving valid memories according to the memory range associated with the AI ​​employee and injecting them into the context after sorting according to the relevance score, specifically includes the following sub-steps: S31: Read the associated memory range list from the AI ​​employee configuration table to determine the set of memory levels that can be retrieved this time; S32: Query candidate memory records from the organization memory table. The query conditions include: the memory level belongs to the set of memory levels, and the status field is neither pending confirmation nor expired. S33: Call the permission verification function for each candidate memory: if the memory level is within a group, verify whether the current user is a member of the source group; if the memory level is personal long-term, verify whether the current user is the owner of the memory; records that fail the verification are filtered out. S34: Calculate the relevance score for each memory that passes the verification: Concatenate the title, content, and category fields of the memory into the search source text and convert it to lowercase. Split the query text according to punctuation marks and spaces, filter words with a length less than L_min (L_min is 2), obtain the query word list, and calculate the score according to the formula M=I_norm×α+Σs_i, where I_norm is the normalized importance and the value ranges from 1 to 5, α is the importance weight coefficient and the value is 0.4, s_i is the score for the i-th hit query keyword and s_i=min(L_i,5), and L_i is the character length of the hit keyword; S35: Sort by score in descending order, take the content of the first K memories and inject them into the AI ​​model context, where K is a preset value and is set to 5.

5. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity according to claim 1, in step S6: business operations can only be executed after manual confirmation and completion of multiple verifications, specifically including the following sub-steps: S61: Query the source identifier field value of the draft from the action draft table, and check whether the corresponding AI briefing record exists and whether its status is marked as withdrawn or deleted based on the identifier; if the query result is empty or the status is abnormal, the confirmation operation is rejected. S62: Get the creation time field value of the draft, calculate the difference with the current time, and if the difference is greater than the validity period threshold V days, reject the confirmation operation, where V is 7; S63: Query the current user's permission record from the user permission table to confirm that the user has the permission to perform the operation; if the permission has been revoked, reject the confirmation of the operation. S64: Query the status field value of the draft. If the current value is already "confirmed" or "ignored", reject the operation to prevent duplicate creation. S65: After all the above checks pass, execute the business operation and create a formal business record; S66: Update the status field of the draft record to "confirmed", write the confirmation time field to the current timestamp, and write the confirmer field to the current user identifier.

6. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity according to claim 1 further includes the following steps: S71: Receive the first user's approval operation. After passing the two-factor password verification, create a one-time viewing qualification record in the viewing qualification table. The record includes the granting object identifier, platform identifier, expiration time field and usage flag field. The usage flag field is initially written as unused. S72: Receive the password viewing instruction initiated by the granted user, query the viewing eligibility table for valid records that match the granted object, are marked as unused, and have an expiration time greater than the current time; if a valid record is found, continue execution; S73: Immediately update the usage flag field of the viewing qualification record to "used". The update operation is performed in a database transaction, and row-level locking is used to prevent concurrent reuse. S74: Read the corresponding encrypted account, encrypted password and encrypted remarks field values ​​from the password database table, call the decryption function to decrypt and return plaintext data to the client; S75: After receiving plaintext data, the client starts a countdown timer. The countdown timer checks once per second based on the display deadline timestamp returned by the server (current time plus T seconds), where T is 60. After the countdown ends, the client performs a DOM clearing operation to remove the plaintext data and sends a display end notification to the server. S76: When the usage mark of the viewing qualification record has been used or the expiration time has expired, the query result is empty, and the server returns a response to the client that there is no valid viewing qualification.

7. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity according to claim 6 further includes the following steps: S81: The server receives the policy update instruction, extracts the new communication mode value from the instruction, verifies that the current user has user management permissions, and updates the communication policy field value in the system configuration table to the new mode value. S82: After the update is completed, the server broadcasts the permission update event to all online clients. The event type is communication strategy change, and the event body contains the updated strategy value. S83: In response to a user's request to create a direct session or send a message, the server calls the private chat permission verification function, reads the current communication strategy field value from the system configuration table, and enters the corresponding condition branch to perform verification based on the communication strategy field value; S84: If the verification result is forbidden, the server refuses to create a session or refuses to send a message, and returns a forbidden access response to the client; S85: For existing direct sessions, the session read permission verification function is called in real time to verify permissions in both the message sending and processing flow and the session history message loading flow. If the verification fails, the operation is rejected. S86: The private chat permission verification function has a built-in role exception rule. When the target user or the current user's role is the highest administrator, it directly returns permission to communicate and is not subject to the five-level policy constraints.

8. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity according to claim 7 further includes the following steps: S91: The server receives the visibility policy configuration instructions submitted for each group, extracts the visibility mode value, and stores the session identifier and mode value in the session configuration table. The visibility modes include at least real-name visibility for all members, anonymous visibility for all members, and isolated visibility. S92: In response to a user sending a message in a group, the message distribution module queries the visibility policy associated with the group from the session configuration table and calls the message visibility judgment function to perform permission judgment: if the mode is all members real-name or all members anonymous, it returns that all members can see the message; if the mode is isolation, it enters the hierarchical permission judgment logic. S93: In the anonymous visibility mode, the identity tag processing module detects the role relationship between the current viewer and the sender. If both are controlled roles and not the same person, anonymization processing is triggered, and the sender's displayed name is replaced with the desensitized department name tag. S94: In the anonymous visibility mode, if the number of people in the current department is less than or equal to the preset threshold, the de-identified label will be upgraded to a company-level label or a temporary alias, and the same sender will keep the alias consistent within the same session period; S95: In isolated visibility mode, the hierarchical permission judgment logic judges the following in sequence: whether the viewer is the sender, whether the viewer's role is the highest administrator, and whether the viewer's role is a department administrator and the group has department administrator privileges enabled; if any of the conditions are met, it returns "allow viewing"; otherwise, it returns "prohibit".

9. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity according to claim 8 further includes the following steps: S101: Receive business consultation messages sent by users in the group, perform keyword analysis on the message text: Traverse the configuration records of AI employees whose status is enabled, obtain the keyword list associated with each AI employee, match each keyword in the message text, accumulate scores for the matched keywords by type, and the score is the sum of the weights of the matched keywords; S102: Summarize the scores of all AI employees and perform professional candidate determination: the determination condition is S≥S_min and (N_strong>0 or S≥S_th), where S_min is the minimum score threshold and S_th is the independent score threshold; AI employees who meet the conditions become professional candidates. S103: Perform multi-level sorting on the professional candidate list: the first level is sorted in descending order by score, if the scores are the same, sorted in descending order by strong match number, and if they are still the same, sorted in ascending order by route priority value. S104: Obtain the number of professional candidates N_c. If N_c>1 and the cross-domain threshold condition is met, start multi-AI collaboration and create multiple parallel call tasks to obtain the answers of each AI employee. S105: Obtain the configuration information of the aggregation AI with the highest routing priority, call the model interface of the aggregation AI, take the answers of each AI employee as context input, attach aggregation instructions, generate a structured comprehensive response and return it to the client.

10. The intelligent agent and enterprise multi-domain collaboration system and method based on structured identity as described in claim 9, further... The process includes the following steps: S111: The server receives the document upload request, extracts the file data, title, category and access scope settings, stores the file in a secure storage path, creates a record in the knowledge document table, writes the access scope field to the authorized object list, and asynchronously starts the document parsing task to build an inverted index; S112: In response to the user's knowledge base retrieval request, the query text is segmented to obtain a list of query terms. The list of documents that the user is authorized to access is retrieved from the knowledge document table. For each document, the hit status is checked in the knowledge base index table. The retrieval score is calculated and returned in sorted order. S113: In response to the user's query request in the AI ​​chat, the same permission filtering logic as step S112 is executed again when constructing the AI ​​context. At the same time, the access permission scope of the knowledge base associated with the current AI employee is verified. The permission verification is performed independently in two stages. S114: Receive a document version update request, store the new version of the document and create a new record, and update the status field of the old version of the document record to invalid; the knowledge base retrieval function adds the status field as a valid filter condition to the document traversal query conditions.

11. A method for multi-AI automatic routing and cross-domain collaborative orchestration, characterized in that, Includes the following steps: S201: Receive business consultation messages sent by users in the group, and perform keyword analysis on the message text: Traverse the configuration records of AI employees whose status is enabled, obtain the keyword list associated with each AI employee, match each keyword in the message text, and accumulate scores for the matched keywords according to their type. The score is the sum of the weights of the matched keywords. The weight of keywords whose length is within the range of strong keywords (2 to 3 characters) is 2, and the weight of keywords whose length is within the range of ordinary keywords (not less than 4 characters) is 1.

5. S202: Summarize the scores of all AI employees and perform professional candidate determination: the determination condition is S≥S_min and (N_strong>0 or S≥S_th), where S_min is the minimum score threshold with a value of 2, N_strong is the number of strong keyword hits, and S_th is the independent score threshold with a value of 3; AI employees that meet the conditions become professional candidates. S203: Perform multi-level sorting on the professional candidate list: the first level is sorted in descending order by score, if the scores are the same, sorted in descending order by the number of strong keyword hits, and if they are still the same, sorted in ascending order by the route priority value. S204: Obtain the number of professional candidates N_c. If N_c>1 and the cross-domain threshold condition is met: S_b≥max(S_min,S_a×r), where S_a is the score of the first candidate, S_b is the score of the second candidate, and r is the proportional coefficient with a value of 0.5, then start multi-AI collaboration, create multiple parallel call tasks to obtain the answers of each AI employee respectively. S205: Obtain the configuration information of the aggregation AI with the highest routing priority, call the model interface of the aggregation AI, take the answers of each AI employee as context input, attach aggregation instructions, generate a structured comprehensive response and return it to the client.

12. The multi-AI automatic routing and cross-domain collaborative orchestration method according to claim 11, characterized in that, Before step S201, the process also includes: if the user explicitly specifies an AI employee in the message, the automatic routing and collaborative orchestration process from S201 to S204 is skipped, and the configuration information of the specified AI employee is directly read from the AI ​​employee configuration table to initiate a single AI call; if the AI ​​employee specified by the user is not within its authorization scope, the request is refused to be processed and a permission error response is returned.

13. A method for permission-based domaining and multi-user collaboration management of an enterprise task dashboard, characterized in that, Includes the following steps: S400: Receives task board permission configuration instructions, and splits task management permissions into four independent dimensions: creating and managing tasks, assigning tasks to others, board visibility range, and participant identity display mode, and configures and stores them respectively. S410: Receives a task list query request, filters task records visible to the current user based on user role and dashboard visibility configuration, and determines the relationship domain; S420: Receives instructions to create a multi-person collaborative task, performs legality checks on the set of executors, the person in charge, the set of approvers, and the deadline of each stage node, and creates a task record after all checks are passed; S430: Implement a multi-person collaboration and a single responsible person submission mechanism. Stage reports are open to all members, but the final deliverables can only be submitted by the task leader. S440: Implement overdue judgments based on actual submission time, separating execution time from approval waiting time; S450: Dual deadline monitoring for execution phase nodes and final delivery, triggering early warnings for missed reporting nodes; S460: Performs timed automatic early warning scans, updates the progress status of tasks that meet the trigger conditions from green to yellow, and sends a delayed notification; S470: Implement a serial approval snapshot mechanism. When the person in charge submits the final deliverable, an independent approval snapshot containing an ordered list of current approvers is created and approved in serial order. S480: Perform persistent reminder cooling check to limit repeated reminders within a preset cooling period; S490: Perform performance indicator calculations based on sole responsible person attribution, and count the number of responsible tasks, the number of completed tasks, the number of rejected tasks, and the number of overdue tasks, and calculate the completion rate and overdue rate.

14. The method for permission-based domaining and multi-user collaboration management of enterprise task dashboards according to claim 13, characterized in that, In step S460, the delivery trigger condition is: the task deadline has passed and there is no valid on-time result; the node trigger condition is: the deadline of a stage node has passed and there is no corresponding stage report record; the automatic warning only allows the progress status to change from green to yellow, and does not cover the manually set yellow or red.

15. An enterprise-level visual content generation and governance method, characterized in that, Includes the following steps: S500: Receives instructions to create creative projects and stores structured briefing data; S510: Receive reference images. If the number of reference images is greater than 1, synthesize a numbered reference board according to the preset grid layout. S520: Perform adaptive compression processing based on the reference image, and attempt to compress the volume according to the preset size-mass gradient until the volume meets the requirements; S530: Execute the intersection of the whitelist of execution models to calculate the set of valid models, and construct the request fingerprint to perform idempotent protection; S540: Perform atomic reservation of image quota, check quota constraints on a daily and monthly basis, and create a generation task record in the transaction after the constraints are met; S550: Select a strategy template based on the project type, concatenate the final prompt words in sequence, and call AI to generate them; S560: Securely reads external image results, and downloads them to a local protected directory after protocol checks, internal network address checks, and DNS resolution checks; S570: Receives AI background image and compositing configuration, loads brand package resources, calculates text panel size and position, and composites the final product image locally on the server. S580: When saving generated assets, establish a scheme genealogy containing traceability fields to form a directed graph structure for authorized users to view the complete traceability chain; S590: Execute the creative project status transition and review closed loop, and manage the project lifecycle according to the preset state machine.

16. The enterprise-level visual content generation and governance method according to claim 15, characterized in that, In step S550, when the iteration mode is optimization, all identities, proportions, structures, and compositions that have not been required to be modified are retained; when the iteration mode is variant, the identifiable subject and design language of the parent scheme are retained. In step S570, AI is responsible for generating the background and visual direction, and the server local synthesis is responsible for the precise layout of the logo, title, price, and legal statement.

Images