A foreign trade B2B customer development system and method based on multi-agent cooperation

Abstract

The application discloses a foreign trade B2B customer development system and method based on multi-agent cooperation and belongs to the technical field of foreign trade B2B customer development. The system comprises a user interaction module, a core scheduling module, a customer development Skill module and an external service module. The user interaction module is used for receiving a customer acquisition task request submitted by a user. The customer development Skill module is used for executing a complete customer acquisition process from keyword generation to customer search, official website analysis, mailbox acquisition, mailbox verification, customer scoring, CRM warehousing and development reach. The external service module is used for providing external tools and API calling services for the customer development Skill module. The application solves the technical problems of data island caused by tool fragmentation, low customer acquisition efficiency, lack of scientific basis for customer quality judgment, low mailbox acquisition rate and difficulty in guaranteeing quality, and lack of end-to-end automatic closed loop and state recovery capability in the prior art.

Description

Technical Field

[0001] This invention relates to the field of foreign trade B2B customer development technology, specifically to a foreign trade B2B customer development system and method based on multi-agent collaboration. Background Technology

[0002] With the rapid development of the global digital economy, customer acquisition methods in the B2B foreign trade industry are undergoing profound changes. According to QYResearch data, the global customer acquisition software market reached $2.352 billion in sales in 2025 and is projected to reach $3.862 billion by 2032, representing a compound annual growth rate (CAGR) of approximately 7.6%. Simultaneously, AI Agent technology is evolving from a "passive response tool" to an "autonomous digital employee." Gartner predicts that 40% of enterprise applications will integrate AI Agents by the end of 2026, while IDC predicts the AI ​​Agent market will grow 80 times in five years, with a CAGR of 139%. Multi-agent collaboration has become a core development direction in the AI ​​Agent field. The MCP protocol solves the problem of standardized connection between AI models and external data, tools, and systems, while the A2A protocol achieves a universal collaboration standard for cross-platform and cross-organizational AI Agents.

[0003] Existing technical solutions suffer from the following core flaws: Fragmented tools lead to data silos. Keyword generation, customer search, email acquisition, verification, customer assessment, CRM entry, and outreach are scattered across multiple independent tools or platforms. Salespeople need to switch between 5 to 8 platforms daily, and customer information is scattered across Excel spreadsheets, emails, social media messages, and various SaaS backends, making it impossible to create a unified customer profile. The same customer is recorded repeatedly in different systems, leading to frequent duplicate orders. Historical follow-up records are difficult to retain, and customer resources are lost when salespeople leave.

[0004] Customer acquisition efficiency is low and labor costs are high. Completing a full customer development cycle takes an average of approximately 280 minutes. Even with the use of individual tools, the connection between each step still relies on manual operation; search results must be manually copied to Excel, official websites must be opened and evaluated one by one, and emails must be verified individually. While existing comprehensive platforms have improved efficiency to some extent, their "black box" data recommendation model makes it difficult for sales staff to understand and intervene in the customer acquisition logic. LinkedIn's B2B customer acquisition cost has reached approximately $45 per lead, while traditional B2B platforms have annual fees ranging from 50,000 to 300,000 yuan, with an annual growth rate of 45% in customer acquisition costs.

[0005] Customer quality assessment lacks scientific basis. Judgments on key issues such as whether a customer is a brand client, whether they possess purchasing power, and the degree of product compatibility rely heavily on the salesperson's personal experience, lacking unified and quantifiable evaluation standards. While comprehensive SaaS platforms offer basic screening functions, their scoring dimensions are singular, typically relying on industry tags or company size for rough classification, making it difficult to conduct in-depth semantic matching for specific product categories and target markets. The average response rate for traditional outreach emails is only 2% to 3%.

[0006] Email retrieval rates are low and quality is difficult to guarantee. Even with professional tools like Hunter and Snov, 30% to 40% of potential customers still cannot find valid email addresses. Factors such as official websites only having contact forms, LinkedIn's privacy protections, and incomplete tool databases all limit email retrieval rates. More importantly, current technology lacks a systematic quality verification mechanism for the retrieved emails: whether the format is correct, whether the domain name matches the company, and whether the email address is genuinely reachable. Relying on manual judgment for these judgments is extremely inefficient and prone to errors.

[0007] The lack of end-to-end automated closed-loop and state recovery capabilities is a significant issue. Existing single-agent solutions based on large language models typically employ a synchronous call model. If any step fails, the entire task is interrupted, and completed intermediate results are lost. Furthermore, the agent's behavioral logic is implicitly contained within the Prompt, making it a "probabilistic black box." The execution process is unauditable and unrollable, failing to meet the stability requirements of a production environment.

[0008] The outreach strategy is crude, and the follow-up pace is difficult to control. Existing solutions use fixed templates for mass mailing, resulting in monotonous content that is difficult to personalize based on the client's product relevance and industry characteristics. Controlling the follow-up pace relies entirely on sales staff's memory and Excel records, frequently leading to missed follow-ups or premature, repeated interruptions. While existing email marketing tools support scheduled sending, they lack a mechanism linking them to customer rating and segmentation systems.

[0009] The existing technical solutions lack the ability to handle abnormal states and schedule batch tasks. When faced with a large number of customer acquisition tasks, they lack effective task sharding and resource scheduling mechanisms. Serial execution leads to single points of failure that interrupt the overall task. When encountering abnormal situations such as API rate limiting, network timeouts, and website crawling failures during the execution of each stage, there is a lack of standardized abnormal state definitions and automatic recovery flow rules, making it impossible to achieve unattended automated operation in a production environment.

[0010] Therefore, the present invention aims to provide a foreign trade B2B customer development system and method based on multi-agent collaboration to solve the defects existing in the prior art. Summary of the Invention

[0011] The purpose of this invention is to provide a foreign trade B2B customer development system and method based on multi-agent collaboration, in order to solve the technical problems in the prior art, such as data silos caused by fragmented tools, low customer acquisition efficiency and high labor costs, lack of scientific basis for judging customer quality, low email acquisition rate and difficulty in guaranteeing quality, lack of end-to-end automated closed loop and state recovery capabilities, extensive outreach strategies, and lack of abnormal state handling and batch task scheduling capabilities.

[0012] To solve the above-mentioned technical problems, the present invention provides the following technical solution, specifically including:

[0013] A multi-agent collaborative foreign trade B2B customer development system, the system includes:

[0014] The module consists of a user interaction module, a core scheduling module, a customer development skill module, and an external service module.

[0015] The user interaction module is used to receive customer acquisition task requests submitted by users, and the customer acquisition task requests include product category and target country.

[0016] The core scheduling module is used to realize indirect communication between agents, persistently save and load the execution status of each agent to support the resumption of execution from the breakpoint after the task is interrupted, and decompose customer acquisition tasks into sub-tasks and schedule the execution of each agent through an event distribution mechanism. The core scheduling module also splits the task into multiple shards according to the customer dimension. Different shards are executed in parallel. When a single shard fails, it is only put into the retry queue, and other shards continue to execute. After all executions are completed, the output data of each shard is merged into a unified output.

[0017] The Customer Development Skill module includes multiple agents that work sequentially and collaboratively through event-driven processes to execute the complete customer acquisition process, from keyword generation to customer search, website parsing, email acquisition, email verification, customer rating, CRM database entry, and development outreach.

[0018] The external service module is used to provide external tools and API calling services for the customer to develop Skill modules.

[0019] The core scheduling module includes an event bus kernel, an agent registry, a state manager, and a coordinator head agent. The event bus kernel uses a publish-subscribe model to enable indirect communication between agents; all agents do not communicate directly but instead relay events through the event bus kernel. The agent registry stores the definitions, capability descriptions, and state transition rules of all agents in the system. The state manager persistently saves and loads the execution state of each agent, supporting storage in a local database or external Redis storage. When an agent executes a long-process task, the state manager periodically creates a state snapshot. If the task is interrupted due to network interruption, API failure, or system restart, the agent resumes execution from the last saved state snapshot, without losing completed intermediate results. The coordinator head agent decomposes the user-submitted customer acquisition task into missions, further breaks down missions into a series of ordered grats, distributes them to each Arm agent for execution via the event bus kernel, and monitors the execution progress of each Arm agent.

[0020] The customer development Skill module includes eight sequentially linked ArmAgents that work together in an event-driven manner: Keyword Generation Agent, Customer Search Agent, Official Website Parsing Agent, Email Acquisition Agent, Email Verification Agent, Customer Rating Agent, CRM Database Entry Agent, and Developer Outreach Agent.

[0021] The keyword generation agent is used to generate a list of combined keywords based on the product category and target country input by the user. The agent calls a large language model to perform semantic understanding and expansion of the user-input product category, generating product word variants. It then combines product words with customer type words and geographical limiting words, with the combined keyword calculated as: product word × customer type word × geographical limiting word. The agent outputs a list of at least a preset number of unique combined keywords. The keyword generation agent defines abnormal state transition rules: when the large language model API returns a rate-limiting status code, it triggers an exponential backoff retry; if the retry fails, it switches to a backup large language model or terminates the task; when the large language model expansion result is empty, it uses a local preset thesaurus as a backup to generate basic product words; when the number of valid keywords is insufficient, it relaxes the deduplication rules and re-executes the algorithm.

[0022] The customer search agent is used to discover potential customers through multi-source parallel search based on the keyword list and output a customer list containing company names and official website URLs. The customer search agent calls the Google CustomSearch API, LinkedIn Search API, and customs data platform interface in parallel for multi-source searches. Built-in intelligent filtering rules automatically clean the original search results, filtering out non-commercial target sites such as B2B platform main sites, news media sites, blogs, and government websites, as well as enterprise entries without independent official websites or with incomplete information. When the main search API quota is exhausted or the response is abnormal, it automatically switches to a backup API to achieve seamless fault tolerance.

[0023] The official website parsing agent is used to crawl the content of the client's official website and perform semantic analysis, outputting structured customer information and target customer identification tags. The agent loads the target official website through the Playwright web automation framework, crawls the text content of the homepage, About Us page, and product catalog page, and uses a large language model to perform semantic analysis of product matching, customer type identification, and purchasing capability assessment on the crawled content. If the official website is inaccessible or the content is insufficient to support the judgment, the entry is marked for manual review, and the reason for the anomaly is recorded without blocking subsequent processes.

[0024] The email acquisition agent employs a four-tiered priority strategy to obtain target customer email addresses. The first priority is to crawl publicly available email addresses from the official website's Contact page; the second priority is to call the Hunter.io and Snov.io email mining APIs to query indexed email addresses based on domain names; the third priority is to generate inferred email addresses based on domain names and employee names; and the fourth priority is to retrieve publicly available business email addresses from LinkedIn and Facebook platforms. The email acquisition agent labels each email address with its data source and pre-credibility level.

[0025] The email verification agent performs a three-tiered progressive verification process on the obtained email address, consisting of format validation, domain name matching validation, and reachability testing, outputting the email address's trustworthiness level. The first tier is regular expression format validation based on the RFC5322 standard; the second tier verifies the consistency between the email domain name and the customer's official website domain name; and the third tier verifies the existence of the email account by querying the validity of the MX record through DNS and initiating a connection test via the SMTP protocol. Email trustworthiness level PassLevel = f(V format V domain V setup For each ∈ {High, Medium, Low}, the credibility level is determined by the following criteria: High level is V. format ∧V domain ∧Vsetup Cleared all three levels, Medium level V. format ∧V domain Pass and V setup To be confirmed, Low level is only V. format Successful. When an MX record query times out and receives no response, the email address is marked as dns_timeout and the verification level is temporarily set to Medium. The system's scheduled task will automatically retry DNS resolution later. The verification level will not be downgraded when the SMTP server refuses the connection or the port is blocked. When a potentially catch-all server is detected, the verification level of the email address is set to Medium. When the total time taken for batch verification exceeds a preset threshold, the verification of the remaining email addresses is paused, the verified results are output, and the unverified email addresses are marked as verification_pending and will be verified by a scheduled task when the system is idle.

[0026] The customer rating agent is used to calculate a comprehensive customer rating and output a rating label based on a four-dimensional weighted rating model. Each dimension in the four-dimensional weighted rating model is assigned a preset weight. The product matching degree is calculated through the following steps: the product category text extracted from the official website and the product category text input by the user are processed by word segmentation and stop word removal; a TF-IDF vector is constructed based on a pre-trained industry corpus; and the pre-processed text is input into the Sentence-BERT semantic model to obtain semantic vectors.

[0027] according to Calculate the overall similarity. When the semantic model is unavailable, α=0, degenerating to TF-IDF cosine similarity, and map S_match to a preset score range. The overall score is: Score = w1 × S brand +w2×S product +w3×S country +w4×S email The grading criteria are as follows: Category A is defined as a comprehensive score that reaches the first preset threshold; Category B is defined as a comprehensive score that is lower than the first preset threshold but reaches the second preset threshold; and Category C is defined as a comprehensive score that is lower than the second preset threshold.

[0028] The CRM data entry agent is used to synchronize customer data to the CRM system or export structured files. The CRM data entry agent maps the input customer information to a standard database field structure, performing domain-level and email-level deduplication: the deduplication key DedupKey = normalize(domain) + "|" + normalize(email). When a historical record with the same main domain already exists in the database, if the new record's overall score is higher than the historical record's score by more than a preset difference, an update operation is performed; otherwise, the insertion of the new record is rejected.

[0029] The development outreach agent is used to automatically select email templates, generate personalized outreach email content, and execute automated sending and follow-up sequences based on customer rating levels and product categories. The development outreach agent matches corresponding industry email templates based on the customer's product category, calls a large language model to automatically insert the customer's company name, contact person, and product matching points into the template to generate personalized outreach email content; it executes an automated follow-up sequence of sending the first outreach email on Day 1, the first follow-up email on Day 3, the second follow-up email on Day 7, and the final outreach email on Day 15; when the customer replies at any stage, it is marked as replied and the automatic follow-up sequence stops; for A-class or B-class customers who have not generated any interaction within a preset time, a redevelopment mechanism is automatically triggered.

[0030] The development and outreach agent also defines abnormal status flow rules: when email sending returns a 550 / 554 status code or the SMTP connection is interrupted, the reason for failure and bounce details are recorded. If the email address is invalid (550), the email address level is downgraded to Invalid. If the problem is due to a temporary network issue, an exponential fallback retry is triggered, with a wait time of 30 seconds for the first attempt, 60 seconds for the second, and 120 seconds for the third. If the retry fails after 3 attempts, the email is marked as send_failed and added to the failure queue, without affecting email sending for other customers. When the LLM returns an empty result or a format error when generating email content, a preset simplified template (containing only a greeting, product introduction, and contact information) is used as a backup plan and marked as template_fallback_used. At the same time, an exception log is recorded to notify the user to check the LLM service status.

[0031] The coordinator (Head Agent) is also used to perform task sharding and resource scheduling in large-scale customer acquisition scenarios: the Mission is split into multiple Shards according to the customer dimension, each Shard generates a Grip sequence independently, and the keyword generation results of Stage 1 are shared among the Shards; different Shards are executed in parallel, and the frequency of large language model API calls is limited by the token bucket algorithm to limit the global call rate; when a single Shard fails, it is placed in the retry queue and retried a maximum of preset number of times according to the exponential backoff strategy. If it still fails after the preset limit of retry count is reached, the Shard is marked as partially completed, and the results of the completed Stage are retained; after all Shards are completed, the output data of each Shard is merged according to the customer ID. When the same customer appears in different Shards, the record with the higher score is used. Global domain-level deduplication is performed to generate a Mission-level execution report.

[0032] A method for developing B2B customers in foreign trade based on multi-agent collaboration includes the following steps:

[0033] S1. Users submit customer acquisition task requests containing product categories and target countries through the user interaction module. The coordinator Head Agent receives the task request, encapsulates it into a Mission object, decomposes the Mission into eight sequentially executed Grips, and issues the MISSION through the event bus Kernel. START event.

[0034] S2. After receiving the MISSION_START event, the Keyword Generation Agent calls the large language model to semantically expand the product category, and combines product words with customer type words and geographical qualifiers to generate no less than a preset number of combined keywords. After completion, it issues the STAGE_1_COMPLETED event.

[0035] S3. After listening to the STAGE_1_COMPLETED event, the Customer Search Agent calls the Google Custom Search API, LinkedIn Search API and Customs Data Platform interface in parallel based on the combined keywords to perform multi-source search, filters the search results, outputs a deduplicated list of potential customers, and emits the STAGE_2_COMPLETED event upon completion.

[0036] S4. After the official website parser listens for the STAGE_2_COMPLETED event, it loads the customer's official website through the Playwright headless browser framework, grabs the text content of the homepage, About Us page and product catalog page, calls the large language model to perform semantic analysis of product matching degree and customer type judgment on the grabbed content, outputs structured customer information and target customer judgment tags, and emits the STAGE_3_COMPLETED event after completion.

[0037] S5. After listening to the STAGE_3_COMPLETED event, the Email Acquisition Agent executes a four-level priority progressive email acquisition strategy for the target customer, marks the data source and pre-trustworthiness of each source email, and then issues the STAGE_4_COMPLETED event upon completion.

[0038] S6. After listening to the STAGE_4_COMPLETED event, the email verification agent performs a three-layer progressive verification on the obtained email address, including format verification, domain name matching verification, and MX record query plus SMTP connection test. It outputs the credibility level and sends the STAGE_5_COMPLETED event after completion.

[0039] S7. After listening to the STAGE_5_COMPLETED event, the Customer Scoring Agent calculates the comprehensive customer score based on a weighted scoring model that considers four dimensions: brand strength, product matching, country priority, and email quality, and outputs a level label. Upon completion, it sends out the STAGE_6_COMPLETED event.

[0040] After listening to the STAGE_6_COMPLETED event, the S8 and CRM database entry agents map A-class or B-class customer data to standard database fields, perform domain-level and email-level deduplication checks, write the data to the database or export it to an Excel file, and then issue the STAGE_7_COMPLETED event.

[0041] S9. After the Development Outreach Agent listens for the STAGE_7_COMPLETED event, it filters customers into Class A or Class B based on their customer rating level, matches industry email templates, and calls the large language model to generate personalized development emails. It then sends the first development email via SMTP service and creates a scheduled follow-up plan for customers who have successfully sent the email. Upon completion, it issues the STAGE_8_COMPLETED event.

[0042] S10. After listening to the STAGE_8_COMPLETED event, the Head Agent of the Coordinator updates the global state of the Mission to completed. It extracts outputData from all eight Grips, synthesizes a complete customer profile according to the customer dimension, generates a task report, and pushes it to the user interaction module.

[0043] Compared with the prior art, the beneficial effects achieved by the present invention are:

[0044] Eliminating data silos and achieving a closed-loop customer acquisition process. This invention connects eight StageAgents into a unified pipeline via an event bus kernel. Output data from upstream agents is automatically transmitted to downstream agents via events, completing a closed-loop flow of customer information within the system without manual copying and pasting. The CRM entry agent further synchronizes the final data to the enterprise CRM or exports a structured file. The domain-based intelligent deduplication mechanism effectively avoids duplicate entries and order collisions for the same customer in different batches of searches.

[0045] This invention significantly improves efficiency and reduces labor costs. By using multi-agent parallel execution and automated process concatenation, it compresses the entire customer acquisition process, which traditionally takes about 280 minutes, into approximately 20 minutes. Keyword generation is reduced from 30 minutes to 2 minutes, customer search from 60 minutes to 5 minutes, website parsing from 40 minutes to 3 minutes, email acquisition from 45 minutes to 5 minutes, email verification from 20 minutes to 2 minutes, customer rating from 25 minutes to 1 minute, CRM database entry from 20 minutes to 1 minute, and outreach from 40 minutes to 1 minute.

[0046] This invention establishes a quantitative scoring model for scientific customer segmentation. It designs a customer scoring agent based on a four-dimensional weighted model, quantifying four dimensions—brand strength, product fit, country priority, and email quality—into a comprehensive score and automatically outputting three-tiered classifications: A, B, and C. Product fit has the highest weight, followed by email quality. This allows business teams to focus their limited resources on high-value customers, fundamentally improving the return on investment in customer acquisition.

[0047] Email acquisition and delivery rates are significantly improved. The email acquisition agent of this invention adopts a four-layer priority strategy: crawling the official website contact page, mining with Hunter or Snov tools, inferring naming rules, and supplementing with social media. This four-pronged approach maximizes coverage. The acquired emails then undergo three layers of Stage 5 verification for quality filtering, with only High and Medium level emails entering the development outreach stage. This increases the email acquisition rate from approximately 60% to 85%, and the email delivery rate reaches over 95%.

[0048] State persistence and fault recovery meet production-grade stability requirements. The core scheduling layer of this invention introduces a state manager component to periodically save state snapshots for each executing Agent. Combined with the design concept of Agent as a state machine, the execution logic is transformed from a probabilistic black box into a deterministic and auditable structure. When network anomalies, API rate limiting, or system restarts cause task interruption, the Agent automatically recovers from the last saved state without losing completed intermediate results.

[0049] Personalized outreach and automated follow-up improve email response rates. This invention's outreach agent automatically matches industry templates based on the customer's product category to ensure content relevance to the customer's business. Based on a large language model, it automatically inserts the customer's company name, contact person, and product matching points into the template to generate personalized content tailored to each individual. A standardized automatic follow-up sequence of Day 1, Day 3, Day 7, and Day 15 triggers a re-development mechanism for high-value customers who haven't responded within a preset time, increasing the email response rate by approximately 55% compared to traditional bulk outreach methods. Attached Figure Description

[0050] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0051] Figure 1 This is a schematic diagram of the system module connection of a foreign trade B2B customer development system based on multi-agent collaboration according to the present invention;

[0052] Figure 2 This is a flowchart of the steps of a foreign trade B2B customer development method based on multi-agent collaboration according to the present invention. Detailed Implementation

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

[0054] Please see Figures 1-2 The present invention provides the following technical solution:

[0055] like Figure 1 As shown, the system includes a user interaction module, a core scheduling module, a customer development skill module, and an external service module.

[0056] The system deployment environment in this embodiment is as follows: CPU is an Intel Core i7-12700 eight-core processor, memory is 32GB DDR4, hard disk is 512GB SSD, operating system is Ubuntu 22.04 LTS, and network bandwidth is 100Mbps. The system adopts a hybrid deployment architecture of a private AI Agent platform and a large language model API: the AI ​​Agent platform is privately deployed on the enterprise's local server, and customer data and business information are stored locally to meet data security requirements; the large language model calls mainstream cloud-based large model APIs to provide semantic understanding and content generation capabilities; external service modules access Google CustomSearch API, Hunter.io email mining API, ZeroBounce email verification API, and SMTP email sending service on demand.

[0057] The system comprises a user interaction module, a core scheduling module, a customer development skills module, and an external service module. The user interaction module provides a WebUI interface, allowing sales personnel to submit customer acquisition tasks via a browser. The core scheduling module includes an event bus kernel, an agent registry, a state manager, and a coordinator head agent. The customer development skills module consists of eight sequentially linked Arm agents that work collaboratively through event-driven mechanisms. The external service module includes a large language model API service, a search engine API service, an email mining API service, an email verification API service, and an SMTP email sending service.

[0058] like Figure 2 As shown, the implementation process is broken down as follows:

[0059] S1. Task Initiation and Initialization. Users submit customer acquisition tasks through the WebUI interface, filling in the product category and target country. The Head Agent receives the task request and performs initialization operations.

[0060] The Head Agent first extracts the task parameters submitted by the user and performs existence and format validation: the product category field passes the non-empty validation and the string length is between 2 and 100 characters; the target country field passes the non-empty validation and contains at least one valid country name.

[0061] The Head Agent queries the Agent registry and sequentially verifies that all eight Arm Agents have completed registration and are currently in a ready state, according to their Stage numbers: Stage 1 Keyword Generation Agent, Stage 2 Customer Search Agent, Stage 3 Website Resolution Agent, Stage 4 Email Acquisition Agent, Stage 5 Email Verification Agent, Stage 6 Customer Rating Agent, Stage 7 CRM Database Input Agent, and Stage 8 Developer Outreach Agent. If any Agent is not ready, the Head Agent marks it as 'Waiting', with a maximum waiting time of 60 seconds. If it is still not ready after the timeout, the Head Agent logs an error (error code AGENT_NOT_READY) and notifies the user via the Kernel, terminating the task.

[0062] The Head Agent encapsulates user tasks into Mission objects. A Mission object contains the following fields:

[0063]

[0064] The Head Agent breaks down the Mission into eight sequentially executed Grips. The Grip's data structure contains the following fields:

[0065]

[0066] The Head Agent uses Grip 1 as its first task unit and issues a MISSION_START event via the event bus kernel, carrying complete data for Grip 1 in the event payload. The kernel queries the Agent registry to confirm the Stage 1 keywords, generates an Agent that listens for the MISSION_START event, routes Grip 1 to that Agent, and triggers its state to change from awaiting_keywords to generating_keywords.

[0067] S2. Keyword Generation. The keyword generation agent receives the MISSION. START The event extracts product categories and target countries from the input data of Grip 1.

[0068] The agent calls the large language model API to construct a semantic expansion prompt and sends it to the model. The prompt structure contains the following elements: the role is set as "you are a senior foreign trade keyword research expert", the task description is "based on a given product category, generate multiple English expression variations for that product", the input data is the user's product category, and the output requirement is "a comma-separated list of English product words, each word being 2 to 4 words, avoiding overly broad vocabulary", an example is "babyproducts, baby gear, infant supplies, newborn essentials".

[0069] The expanded results returned by the large language model contain multiple product terms. The agent performs post-processing on the returned results: deduplication to remove items that are exactly the same as existing terms; filtering to remove terms that are too far semantically distant from the original product category; and truncating to retain a maximum of 10 high-quality product terms.

[0070] The Agent loads the customer type thesaurus from the local configuration file `config / keyword_templates.json`. The default thesaurus contains the following terms: brand, distributor, importer, wholesaler, supplier, manufacturer, reseller, dealer, retailer, vendor, trading company, buying office, procurement, sourcing agent, and private label. System administrators can customize the thesaurus by adding or deleting terms in the configuration interface; the Agent automatically loads the latest version when reading the thesaurus.

[0071] The agent converts the target country entered by the user into a set of English geographical qualifiers. The conversion rules are as follows: direct mapping to English country names; regional expansion, such as generating EU, European Union, and Europe when the user enters "Europe"; country segmentation, such as generating the names of major European countries as a supplement when the user enters "Europe"; city-level supplementation, such as generating the abbreviations of major states for the US market.

[0072] The Agent performs a Cartesian product operation to generate all combinations: Keyword combination set = {Product Keywords} × {Customer Type Keywords} × {Geographic Keywords}. The combination follows these format rules: the standard format is product keyword + customer type keyword + geographic keyword; the variant format is geographic keyword + product keyword + customer type keyword; and the simplified format is product keyword + geographic keyword. The Agent performs character-level deduplication to remove identical strings from all generated combinations, and semantic-level deduplication to remove substantive duplicates.

[0073] Finally, output more than 30 unique keyword combinations, and store them in the output data of Grip 1 in JSON array format.

[0074] The keyword generation agent defines the abnormal state transition rules: When the large language model API returns a rate-limiting status code, an exponential backoff retry is triggered, with a wait time of 15 seconds for the first retries, 30 seconds for the second, and 60 seconds for the third. After three failed retries, a backup large language model is switched or the task is terminated. When the large language model expansion result is empty or completely deviates from the original product category, a local preset thesaurus is used as a backup to generate basic product words, and the combination continues, with "fallback_used" marked in the output data. When there are fewer than 30 valid keywords after deduplication, the deduplication rules are relaxed (allowing the coexistence of synonym combinations), and the task is re-executed. If there are still fewer than 30 keywords, the actual number is output and marked "underflow_warning," and the task continues. Abnormal states are written to the errorData field of Grip, and normal output data and errorData are passed downstream in parallel.

[0075] S3, Customer Search. The Customer Search Agent receives the STAGE_1_COMPLETED event and extracts a list of combined keywords from the input data of Grip 2.

[0076] The agent initiates three parallel search requests for each keyword combination. The Google Custom Search API call parameters are set as follows: query keywords are combined keywords, return quantity is 10 (10 results per request, retrieved cumulatively from 3 calls to get the top 30), language is limited to English, and site search filtering excludes specific sites used to filter B2B platforms. The API returns results in JSON format, which the agent parses to extract the title, link, and summary of each result. The LinkedIn Search API call performs fuzzy matching using keywords as company names or industry tags to retrieve the LinkedIn URLs of company homepages. The customs data platform interface call retrieves information on companies with relevant purchasing records within the past year using product keywords. The total timeout for all three searches is set to 5 minutes.

[0077] The agent aggregates the search results from the three sources into a single dataset and performs domain-level deduplication. The deduplication key is the main domain portion of the official website URL. For records with the same domain appearing in multiple search sources, the agent merges them according to the following priority: prioritizing the retention of the company name and official website URL from Google search results, appending supplementary information from LinkedIn and customs data to the same record, and annotating all search sources. Each merged record contains the following fields: company name, complete official website URL, LinkedIn homepage URL, country inference information, and automatic search source annotation.

[0078] The Agent executes filtering rules on each structured result. Rule 1 filters B2B platform main sites: The Agent maintains a blacklist of B2B platform domains, including alibaba.com, made-in-china.com, globalsources.com, dhgate.com, 1688.com, tradekey.com, ec21.com, europages.com, etc. It checks whether the website_url domain of each record matches any item in the blacklist; if it matches, it is directly removed.

[0079] Rule 2 filters non-commercial sites, checking whether the URL belongs to categories such as news media, blog platforms, government websites, and educational research institutions; if a match is found, the site is removed.

[0080] Rule 3 is for information integrity filtering. It checks whether a record simultaneously meets the following conditions: the website_url starts with "http: / / " or "https: / / " and can be parsed via URL; the company_name is not empty and has a length of more than 2 characters. Entries that do not meet these conditions are marked as low-quality and temporarily stored, and will not proceed to subsequent stages.

[0081] Rule 4 is a competitor filtering option (optional). If the company maintains a list of competitor domains in its system configuration, the Agent checks the website. url Check if it matches a competitor's domain. If it does, remove it and record it in the "competitor_filtered" log.

[0082] The agent maintains a local counter to track the number of calls to the Google Custom Search API and the remaining quota for the day. When the daily call count reaches 90% of the quota limit and the API returns an HTTP 429 or HTTP 403 status code, failover is triggered. The agent automatically switches to the backup search API, and the switchover process is transparent to the user. If the backup API is also unavailable, the agent marks currently unsearched keywords as pending_manual_search, and completed search results proceed normally to the next stage without disrupting the overall process.

[0083] After filtering, the Agent counts the number of valid results. If the number of valid results is zero, the Agent sends a STAGE_2_WARNING event to the Kernel, with the payload containing the zero_results flag and the original keyword list. If the number of valid results is greater than zero, the Agent writes the structured list to the Grip 2 output data and sends a STAGE_2_COMPLETED event. The Kernel then routes the outputData into the Grip 3 input data to the Stage 3 official website's parsing Agent.

[0084] S4. Official Website Parsing. The official website parsing agent receives the STAGE_2_COMPLETED event and extracts a list of potential customers from the input data of Grip 3.

[0085] The Agent loads the website_url from each record sequentially. The Agent uses the Playwright headless browser framework to open the webpage, with the following configuration: browser type is Chromium, viewport size is 1920×1080, page load timeout is 30 seconds, and the waiting condition is networkidle, meaning no new network requests within 500 milliseconds.

[0086] After loading, the Agent sequentially fetches the text content of the following pages: On the homepage, it extracts the page title tag content, the `content` attribute of the `meta description` tag, and the first 500 characters of the page body; on the About Us page, it attempts to access common paths such as ` / about`, ` / about-us`, ` / company`, ` / who-we-are`, and ` / our-story`. If a path returns a 200 status code, it extracts the complete text content of that page; on the product catalog page, it attempts to access paths such as ` / products`, ` / product`, ` / catalog`, ` / collection`, ` / shop`, and ` / store` to extract the category names in the navigation bar and the product names in the product list.

[0087] For single-page applications that use JavaScript for dynamic rendering, Playwright automatically waits for asynchronous content to load completely. If the page does not reach the network idle state within 30 seconds, the agent captures the currently loaded content and continues processing, without treating timeouts as fatal errors.

[0088] The Agent extracts the following structured fields from the crawled text using rule templates and regular expressions: Company Name: Primarily extracts the full company name from the first paragraph of the About Us page; if About Us is unavailable, it extracts it from the page title and removes the site name suffix; Country: Extracts the country name from the Contact page address text; if there is no Contact page, it infers the country name from the geographical location description in About Us; if still no country exists, it maps it based on the domain name suffix (.us / .uk / .de, etc.); Product Category: Extracts up to the first 5 categories from the navigation category titles of the product catalog page; Business Scale: Extracts keyword descriptions about the number of employees, annual turnover, and market coverage from the About Us page.

[0089] The agent inputs the extracted product category text and the user-inputted original product category into the large language model, requesting the model to output a semantic matching score between the two. The large language model's Prompt structure is as follows: the role is set as "you are a senior foreign trade product analyst," the task description is "to determine the degree of matching between the following customer's product category and the target product category," the target product category is the product category input by the user, the customer's actual product category is the product category text extracted from the official website, and the output requirement is "output a matching score from 0 to 100, with the scoring criteria being 80 to 100 for high matching (mainly selling similar products), 50 to 79 for moderate matching (some product lines overlap), and 0 to 49 for low matching (different product directions), and explain the reason for the judgment in one sentence," the output format is a JSON object containing score and reason fields. The agent parses the JSON result returned by the large language model and extracts the score field as the product matching score.

[0090] The agent inputs the concatenated text from the About Us page and the homepage content into the large language model, requesting the model to determine the customer's business role. The large language model's Prompt requires the output of one of the following three tags: Brand (brand customer) - possesses its own brand, has product design and development capabilities, displays its own brand logo and product patent information on its official website, and emphasizes product innovation and quality; Trader (intermediary / trader) - does not have its own brand, its official website mainly displays multi-brand products it represents or distributes, emphasizes supply chain integration and trade services, and focuses on price advantages and supply capabilities; Unknown (cannot be determined) - insufficient information to support either of the above two determinations.

[0091] The agent categorizes the processing results of each record. Target customers are categorized as follows: product matching score ≥ 40 points and customer type is Brand or Unknown, marked as is_target=true, and proceed to Stage 4 for email retrieval.

[0092] Non-target customers will not proceed to the next stage if their product match score is less than 40 or their customer type is clearly Trader and their product match score is less than 60. In this case, they will be marked as is_target=false, with reason being low_match or trader_type. They will not proceed to stage 4 but will be retained in the outputData for users to view.

[0093] The conditions for not proceeding to the next stage under the condition of manual review are: the official website returns an HTTP 4xx or 5xx status code, the page loads at a timeout, or the valid text content is less than 100 characters, marked as is_target=null, status is need_smanual_review, exception_reason is the specific reason for the exception, and it will not proceed to Stage 4.

[0094] The Agent writes all processing results to the Grip 3 output data, with the target customer list stored separately in the `target_clients` field. If the `target_clients` list is empty, the Agent issues a `STAGE_3_WARNING` event, with the payload containing a `no_target_clients` flag and a filtered list of non-target customers. If the `target_clients` list is not empty, the Agent issues a `STAGE_3_COMPLETED` event. The Kernel injects the `target_clients` data into the Grip 4's `inputData`, routing to the Stage 4 mailbox to retrieve the Agent.

[0095] S5. Email Acquisition. The Email Acquisition Agent receives the STAGE_3_COMPLETED event and extracts the target customer list from Grip 4's inputData. The Agent then retrieves the website for each target customer. url Perform a deep page traversal. The traversal strategy is breadth-first, prioritizing page paths that are highly likely to contain email addresses.

[0096] The priority order is as follows: the first priority is to access / contact, / contact-us, and / get-in-touch to retrieve the full text of the page and the mailto link;

[0097] Second priority access to retrieve all text from the pages / about, / about-us, and / company;

[0098] Third-priority access to / team, / leadership, and / management retrieves personnel names and email addresses;

[0099] Fourth priority access to / careers, / jobs, and / work-with-us to retrieve recruitment contact emails;

[0100] Fifth priority access: / privacy-policy, / terms retrieve legal contact emails.

[0101] The agent searches both the page's HTML source code and the rendered DOM for strings conforming to the RFC5322 email address format, using the regular expression: [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}. For each found email address, the agent records the URL of the page containing it as the source. It also examines mailto links and extracts the email addresses within them.

[0102] The agent executes email retrieval according to a four-tier priority strategy. The first priority (P1) is to crawl publicly available emails from the official website, directly extracting publicly displayed emails such as info@, sales@, contact@, and support@ from the official website's Contact, About, and Team pages, with a pre-credibility level of high.

[0103] The second priority (P2) is to use professional tools and APIs for mining. The Hunter.io API and Snov.io API are called with the company domain name as the query parameter to obtain the indexed hidden email addresses. The Hunter API returns a list of public email addresses associated with the domain name and their verification status, while the Snov API returns historical email data crawled from the web. The pre-credibility level is medium.

[0104] The third priority (P3) is based on naming conventions. If no email address is obtained from either the first or second priority level, and the employee's name is displayed on the official Team page, then a hypothetical email address is generated in the format firstname.lastname@domain.com, firstname@domain.com, m.lastname@domain.com, or flastname@domain.com. If the employee's name is not displayed, then a generic hypothetical email address is generated: info@domain.com, sales@domain.com, contact@domain.com, or support@domain.com. The pre-confidence level is low.

[0105] The fourth priority (P4) is to supplement the search on social media platforms, searching the LinkedIn company homepage and employee profile pages, extracting publicly visible business emails, and performing the same operation on the Facebook company homepage, with a pre-confidence level of low.

[0106] The execution rules for the acquisition strategy are as follows: once at least one email address is acquired at layer P1, layers P2 to P4 can be optionally executed for the customer to acquire more email addresses; if no email address is acquired at layer P1, the agent continues to execute layer P2; if no email address is acquired at layer P2, the agent executes layer P3; layer P4 is always executed as a supplementary strategy.

[0107] The agent labels metadata for each acquired email address to form a structured email record. The email record contains the following fields: the complete email address, the source channel such as website, hunter, snov, guessed, LinkedIn, Facebook, the specific URL of the page that discovered the email address, the email confidence score (0 to 100) returned by the Hunter API, the pre-confidence level (high / medium / low), and the email acquisition timestamp.

[0108] The Agent strictly adheres to compliance principles during the acquisition process: it only crawls publicly visible web page content and does not attempt to bypass any login verifications, CAPTCHAs, or restricted pages; it does not crawl private information from personal social media accounts and only extracts publicly available email addresses clearly marked for business purposes; the obtained email addresses are used solely for B2B business development and communication purposes and are not used for spam, data selling, or other illegal purposes; it respects the robots.txt protocol of the target website, and if the website explicitly prohibits crawlers from accessing the Contact page, the Agent skips the page and logs the robots_sexcluded log.

[0109] S6. Email Verification. The Email Verification Agent receives the STAGE_4_COMPLETED event and extracts the list of email addresses from Grip 5's inputData.

[0110] The agent performs the first-level format validation, based on the RFC5322 standard, using regular expressions to check the validity of the email string format. Emails with incorrect formats are marked as invalid and do not proceed to subsequent validation layers.

[0111] The agent performs a second-level domain name matching verification, checking whether the domain name portion of the email address matches the customer's official website domain name. If the email domain name does not match the official website domain name, there is a risk of a fake email address or a third-party managed email address, reducing credibility.

[0112] The agent performs a Layer 3 reachability test. It checks the existence and validity of the MX record for the email domain using a DNS query to determine if the domain is capable of receiving emails. If the query returns at least one valid MX record, the MX test passes; if the query returns an empty result (no MX record), it is marked as `mx_missing`; if the query times out (no response within 2 seconds), it is marked as `mx_timeout`; if the query returns `NXDOMAIN` (domain does not exist), it is marked as `domain_not_found`.

[0113] For a High-level mailbox, the Agent performs optional SMTP connection verification: It selects the highest-priority mail server address from the MX records; initiates a TCP connection to that server (port 25 or 587); sends the SMTP handshake command HELO agent-system.local; sends the sender declaration MAIL FROM:verify@system.local; sends the recipient verification command RCPT TO:<target mailbox address>; and parses the server's returned status code: 250 indicates the mailbox exists and verification is successful, 550 indicates the mailbox does not exist and verification failed, other 4xx or 5xx errors indicate verification failure, and connection timeout (5 seconds) is marked as smtp_timeout. Some mail servers are configured with a catch-all policy (accepting all recipient addresses), in which case RCPT TO may always return 250. The Agent attempts to identify catch-all cases by analyzing the detailed content of the SMTP response, and marks them as possible_catch_all if identified.

[0114] The agent integrates the three-layer verification results and the pre-trustworthiness flag from Stage 4 to output the final trustworthiness level. The criteria for a High level are: format validation passes, domain name matches, MX record is valid, and SMTP verification passes. It proceeds directly to Stage 6 scoring and Stage 8 delivery. The criteria for a Medium level are: format validation passes, domain name matches, and MX record query times out or the result is unclear. It proceeds to Stage 6 scoring and Stage 8 delivery, but includes a bounce-back message. The criteria for a Low level are: format validation passes but the domain name does not match, or the source is a speculative email address and MX verification fails. It does not proceed to Stage 8 for automatic delivery; it is only retained as a data record for manual user review. The criteria for an Invalid level are: format validation fails, the MX record is explicitly invalid, or SMTP returns a 550 error. It does not proceed to any subsequent stages; the record is considered an invalid email address.

[0115] The Agent writes the verification result for each email address to the output data of Grip 5 and emits a STAGE_5_COMPLETED event. The Kernel injects the output data of Grip 5 into the input data of Grip 6 and routes it to the Stage 6 customer rating Agent.

[0116] S7. Customer Scoring. The Customer Scoring Agent receives the STAGE_5_COMPLETED event and extracts the customer's structured information and email verification result from the inputData of Grip 6.

[0117] The agent collects the raw data needed for scoring each customer across four dimensions from the input data. The brand strength dimension is collected from the website quality assessment, product line completeness, and company size description output from Stage 3. The product matching dimension is collected from the large language model matching score (0-100) output from Stage 3. The country priority dimension is collected from the user-specified target country list and the customer's inferred country from Stage 3. The email quality dimension is collected from the email verification level (High / Medium / Low) and the number of valid emails output from Stage 5.

[0118] The agent performs independent scoring calculations for each dimension, mapping the raw data to the corresponding score range.

[0119] Dimension 1 Brand Strength Score Calculation: Website Professionalism Score: 0-15 points, based on the completeness of the website's HTML structure: 2 points for the presence of standardized meta tags, 2 points for a complete navigation bar, 3+ product pages, 3+ About Us page with 200+ words, 3+ brand logo and VI (Visual Identity) presence, and 2+ multilingual versions; Social Media Operation Score: 0-5 points, 3 points for a social media link on the website with at least 10,000+ followers on at least one platform, 1 point for a social media link but less than 10,000 followers, and 0 points for no social media link; Product Line Coverage Score: 0-5 points, based on the number of product categories extracted from the website's product catalog: 5+ categories, 3-4 categories, 1-2 categories, and 0 points for no clearly defined categories. Brand Strength Score = Website Professionalism Score + Social Media Operation Score + Product Line Coverage Score, with a maximum of 25 points.

[0120] Dimension 2 Product Matching Score Calculation: The matching score from 0 to 100 points in the large language model output from Stage 3 is used for mapping. When S... match When ≥40, S product =min(30,S match ×0.3); when S match <40 hours, S product =S match ×0.15.

[0121] Dimension 3 Country Priority Score Calculation: 18 to 20 points are awarded if the customer's country is the first country in the user's target country list, with a base score of 18. If the country is among the top 10 most active foreign trade markets, add 2 points. 12 to 16 points are awarded if the customer's country is within the user's target region, with a base score of 12. If the region has ≥3 active markets, add 2 points; if it has ≥5, add 4 points. 10 to 12 points are awarded if the customer's country is among the top 10 most active foreign trade markets but not in the user's target list, with a base score of 10. If the country ranks among the top five in trade activity, add 2 points. 0 to 8 points are awarded if the country is neither a target market nor an active market, with a base score of 5. If the country has a trade agreement with China (such as RCEP or USMCA), add 3 points.

[0122] Dimension 4 Email Quality Score Calculation: At least one High-level email address earns 22 to 25 points, with a base score of 22 points. ≥2 High-level email addresses earn an additional 2 points, and ≥3 earn an additional 3 points. If the High-level email address source includes Hunter / Snov and the hunter_score is ≥80, an additional 2 points are awarded. The highest level email address earns 14 to 21 points, with a base score of 14 points. ≥2 Medium-level email addresses earn an additional 3 points, and ≥3 earn an additional 5 points. No High-level email addresses but multiple Medium-level email addresses earn a maximum of 21 points. The highest level email address earns 5 to 13 points, with a base score of 5 points. ≥2 Low-level email addresses earn an additional 3 points, and ≥3 earn an additional 5 points. No High / Medium-level email addresses but low-level email addresses earn a maximum of 13 points. No valid email addresses earn 0 points.

[0123] The agent sums the independent scores of the four dimensions according to preset weights: Total = S brand ×25%+S product ×30%+S country ×20%+S email ×25%. Among them, S brand S indicates brand strength score product S represents the product matching score. country S represents the country priority score. email This represents the email quality score. The calculated result is rounded to the nearest integer, resulting in a comprehensive score ranging from 0 to 100.

[0124] The agent outputs a customer level based on a comprehensive score.

[0125] For Category A emails with a score ≥ 70, the email is marked as priority_follow_up, enters Stage 7 for database entry, and then proceeds to Stage 8 for delivery, with the email priority set to high.

[0126] Category B (40≤Score<70) is marked as "nurture_and_develop", enters Stage 7 for database entry, and then enters Stage 8 for outreach. The email priority is set to "normal".

[0127] For Category C, a score of <40 is marked as hold_for_batch and enters Stage 7 for data entry, but does not automatically reach Stage 8; it is only retained as a data asset.

[0128] The Agent generates a complete rating report for each customer. The rating report structure is as follows: it includes the customer's unique identifier, company name, official website address, original scores and maximum values, weights and weighted averages for each dimension, overall score, grade, suggested actions, and a rating timestamp. The Agent writes the entire rating report to Grip 6's outputData and emits a STAGE_6_COMPLETED event. The Kernel injects A-class and B-class customer data into Grip 7's inputData, while C-class customer data is synchronously stored in the database but marked as skip_outreach, and routed to the Stage 7 CRM database entry Agent.

[0129] S8, CRM Data Ingestion. The CRM Data Ingestion Agent receives the STAGE_6_COMPLETED event and extracts A-class and B-class customer information from Grip 7's inputData.

[0130] The Agent maps the input customer information to a standard database field structure. The database table contains the following fields: Customer Unique Identifier (automatically generated by the system); Company Name (derived from the company name extracted by the Agent in Stage 3); Website URL (derived from the website address output by the Customer Search Agent in Stage 2); Country (derived from the customer's inferred country in Stage 3); Product Category (derived from the product category extracted in Stage 3); Primary Email (derived from the email address obtained by the Email Acquisition Agent in Stage 4 and verified by the Email Verification Agent in Stage 5); Email Credibility Level (derived from the verification level output in Stage 5); Overall Rating (derived from the rating calculated by the Customer Rating Agent in Stage 6); Customer Level (derived from the A / B / C level output in Stage 6); Data Source (fixed value marked as automatically acquired by AI); Task Creation Time; Follow-up Status (initial value is "new lead"); Record Creation Time and Update Time.

[0131] The selection rules for the primary email address are as follows: If the customer has multiple email addresses, the email address with a verification level of High will be selected first; if there are multiple High-level email addresses, the one with the highest Hunter rating will be selected; if there is no High-level email address, the Medium-level email address will be selected; if there is no Medium-level email address, the first Low-level email address will be selected.

[0132] The agent performs domain-level deduplication checks before writing to the database. The deduplication key is the main domain extracted from the website_url. The agent checks if a record with the same main domain already exists in the database, handling three cases:

[0133] Scenario 1 is for a brand new customer: the main domain name does not exist in the database, the agent performs an INSERT operation to insert a new record, follow_up_status is set to new_lead, and the log records new_lead_inserted.

[0134] Scenario 2 is duplicates within the same batch: Multiple records in the current batch share the same main domain (possibly due to different keywords searching for the same customer). The Agent retains the records with higher overall scores and discards duplicates with lower scores. The log records batch_duplicate_deduplicated and the Grip ID of the discarded records.

[0135] Scenario 3 involves duplicate historical records: Historical records with the same main domain already exist in the database. The Agent compares the overall score of the new record with that of the historical records. If the new record's score is greater than the historical record's score plus 5 points, an UPDATE operation is performed, updating the historical record's score, email, and verification level fields, appending the `updated_by_ai` flag to the remarks field, and setting `updated_at` to the current time. If the new record's score is less than or equal to the historical record's score plus 5 points, the insertion of the new record is rejected, a `duplicate_skipped` log is recorded, and the historical records remain unchanged.

[0136] After domain-level deduplication, the Agent performs a second-level email-level deduplication check on the email_address field. It queries the database to see if a record with the same email_address already exists. If it exists and is associated with different main domains (indicating the same email address is used by different companies, or a company uses multiple brand domains), the Agent records the association with the related_domain tag, associating the two domains with the same account group for manual verification by the user. If it exists and is associated with the same main domain (truly duplicate email addresses), deduplication is performed, retaining only one record.

[0137] If the enterprise system configuration enables CRM API integration, the Agent reads the CRM interface configuration (API endpoint, authentication token, field mapping rules), maps the database records to fields according to the CRM interface specification, and calls the CRM system's customer creation / update API. If successful (HTTP 200 / 201), `crm_sync_success` is recorded; if it fails (HTTP 4xx / 5xx), the reason for failure is recorded (e.g., `invalid_token`, `rate_limited`), and the data is temporarily stored in the local retry queue `pending_crm_sync`, which is retried hourly by a system scheduled task, up to a maximum of 3 retries. If failures continue, the batch of data is exported as an Excel file to the `exports / ` directory for users to import manually. If the enterprise has not configured CRM integration, the Agent skips this step and directly proceeds to the data export process.

[0138] Regardless of whether the CRM integration is successful, the Agent will export all customer data as a structured Excel file and save it to the output directory configured in the system. The Excel file contains all fields from the aforementioned database tables, and the file name format is leads_export_{missionId}_{timestamp}.xlsx.

[0139] S9. Intelligent Development Outreach. The Development Outreach Agent receives the STAGE_7_COMPLETED event and extracts the already stored A and B class customer information from Grip 8's inputData.

[0140] The agent first filters the input customer list: only processing records with customer_grade A or B, skipping C-grade customers; setting email sending priority to high for A-grade customers, so the system prioritizes generating and sending their outreach emails; setting email sending priority to normal for B-grade customers; and checking the customer's follow_up_status. If the status is already contacted_day1 or a follow-up status, it indicates that the customer has been contacted recently, so the agent skips the customer to avoid repeated contact.

[0141] The agent matches the corresponding industry email template based on the product_category field in the customer record. The system's local template library is stored in the templates / email / directory and organized in JSON format. The template includes the following components: email subject line template with variable interpolation support, greeting template, opening paragraph introducing the sender's company, product advantage introduction paragraph (industry differentiation), closing call-to-action paragraph, and signature template.

[0142] The system currently comes pre-loaded with the following two types of industry templates: The example template for maternal and infant products is "FDA-Certified Silicone Baby Products—OEM / ODM Partnership Opportunity | {company_name}", highlighting key product advantages such as BPA-free food-grade silicone material, CPC / CE / FDA multiple safety certifications, innovative leak-proof design, and support for OEM / ODM customization. The example template for kitchenware is "Premium Kitchenware with LFGB & FDACertification — Supplier Proposal for {company_name}", highlighting key product advantages such as high-temperature resistance (-40℃ to 230℃), easy-to-clean non-stick coating, LFGB / FDA food contact certification, and passing durability tests. Users can add or edit industry templates in the system management interface; the Agent reads the latest version each time it runs.

[0143] The Agent calls the Large Language Model API to generate a personalized development email body based on the selected industry template. The Large Language Model's Prompt injects the following variables: the company name is the customer's company name extracted from Stage 3, the contact person is inferred from the primary email address, the product matching point is the product matching analysis result of Stage 3, the sender's company name is the sender's company name configured in the system, and the sender's name is the sender's name configured in the system.

[0144] The development emails generated by the large language model must meet the following quality verification rules: the language should be American business English, the body text should be 150 to 250 words (excluding the signature), the tone should be professional, polite, and neither arrogant nor humble, and the content must contain a clear call-to-action statement. Avoid using obvious template phrases, overly sales-oriented language, and mentioning competitors. The Agent automatically verifies the content generated by the large language model; if it does not meet the above rules, a regeneration is triggered (maximum of 2 retries).

[0145] The agent sends out outreach emails via the enterprise's configured SMTP service. Before sending, a final verification is performed: confirming the recipient's primary email address has a verification level of High or Medium (Low-level and Invalid email addresses are not automatically sent emails); querying the database to confirm that the email address has not been used to send outreach emails in the past 30 days (to prevent duplicate requests); and checking the system blacklist to confirm that the email domain is not on the blacklist. If any verification fails, the agent skips the customer and records the reason for skipping.

[0146] After successful transmission, the Agent performs the following updates in the database: follow_up_status is updated to contacted_day1, last_contact_date is set to the current timestamp, and email_sent_count is incremented by 1.

[0147] The agent creates a scheduled follow-up plan in the database for each customer for whom the first outreach email is successfully sent. The follow-up plan is stored in the `follow_up_schedules` table and contains the following fields: customer UUID (linked to the `leads` table), first email sending time (Day 0, the baseline time), follow-up plan sending time (Day 0 + 3 days), follow-up plan sending time (Day 0 + 7 days), last contact plan sending time (Day 0 + 15 days), and the status is "active" (follow-up sequence status).

[0148] The system's scheduled task (executed daily at 2:00 AM) scans this table. For records with a status of "active" that have reached the scheduled time, it automatically triggers Stage 8 to regenerate and send the corresponding follow-up email.

[0149] The email content strategy for each follow-up stage is as follows: First outreach email (Day 0): Fully introduce the company and products, focusing on company strength, product advantages, and certifications; Follow-up 1 (Day 3): Brief reminder follow-up, mentioning the first email, adding one product highlight, and asking if they are interested; Follow-up 2 (Day 7): Adjust the angle of follow-up, offering sample discounts or sharing successful cases of similar clients; Final outreach (Day 15): Make a final attempt, inquiring about the other party's purchasing plan timeline and expressing a willingness for long-term cooperation.

[0150] The agent detects customer interaction through email reply detection and bounce message detection. Email reply detection: The enterprise email is configured with automatic forwarding rules to forward received reply emails to a dedicated receiving mailbox in the system (e.g., replies@system.local). The agent periodically parses new emails in this mailbox, extracts the Message-ID of the original email, matches it to the corresponding customer record, updates the follow_up_status to "replied", stops all automatic follow-up sequences for that customer, and pushes a customer reply reminder notification to the user.

[0151] Bounce Detection: If an email is bounced, the SMTP service returns a bounce report. The Agent parses the bounce reason: If the reason is "mailbox does not exist," the mailbox level is downgraded to Invalid and a bounce log is recorded; if the reason is "domain not found," the domain is added to the greylist, which will be automatically reviewed after 30 days; if the reason is "mailboxfull," the current level is retained, a log is recorded, and the email will be retried on the next follow-up.

[0152] 30-Day Re-engagement Mechanism: For Category A and Category B customers who have completed the final outreach on Day 15 but have not generated any interaction within 30 days, the Agent triggers a re-engagement process: generating an email with a differentiated subject line (different from the previous one to avoid repetition); the content focuses on new product launches, seasonal promotions, or sharing industry news; a maximum of 3 rounds of re-engagement are executed, with each round spaced 15 days apart; if there is still no response after 3 rounds of re-engagement, follow_up_status is updated to sleeping_lead, and the customer is moved to the low-frequency outreach pool, no longer participating in high-frequency automatic follow-ups, and only included in the quarterly bulk email list.

[0153] S10. Task completion and result summary. After receiving the completion event of Stage 8, the Head Agent first updates the global state of the Mission object: status is updated from running to completed, completedAt is set to the current system timestamp, and completedStages is updated from 7 to 8 (all Stages have been completed).

[0154] If any Stage issues a STAGE_FAILED event during task execution and fails after retrying, the HeadAgent determines the handling strategy based on the position of the failed Stage: If Stages 1 to 2 fail, the entire task is marked as failed, and an error report is returned to the user; if Stages 3 to 5 fail, the results of completed Stages are retained, the task is marked as partially_completed, and the completed stage results are output; if Stages 6 to 8 fail, the results of the first five Stages have generated value, the task is marked as partially_completed, the customer acquisition list is output, but outreach is not performed.

[0155] The Head Agent extracts output data from all eight grats and synthesizes the results according to the customer dimension. After synthesis, each customer's data forms a complete customer profile, including the customer's unique identifier, company name, official website address, country, product category, email list including the address, level and source of each email, overall score, customer level, data source, contact status, first contact date, and follow-up plan.

[0156] The Head Agent generates the final customer acquisition task report, which includes the following sections: Task Overview (including task ID, product category, target country, total task time, and task status); Stage Execution Statistics (including the number of inputs, outputs, execution time, and success rate for each stage); Customer Acquisition Results Summary (including the total number of potential customers discovered, the number of target customers, the number of customers with valid email addresses obtained, and the A / B / C rating distribution); Outreach Results Summary (including the number of successful outreach messages, the number of follow-up plans created, and the number of replies received); Anomaly Records (including a list of official websites awaiting manual review, a list of email addresses that failed to send messages, and a list of CRM synchronization failure records); and Data Export Path (including CRM synchronization status and the path to the Excel export file).

[0157] The Head Agent pushes the final task report to the user interaction layer via the event bus kernel. The WebUI user displays the report on the task details page and provides buttons to download the Excel file and view the customer list.

[0158] This concludes the complete lifecycle of a single customer acquisition task. The system has automatically completed the entire process from keyword generation to outreach. Users can view all customer data in the CRM system or exported Excel files, and monitor customer follow-up status and response in the background.

[0159] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0160] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A foreign trade B2B customer development system based on multi-agent collaboration, characterized in that, include: User interaction module, core scheduling module, customer development skill module, and external service module; The user interaction module is used to receive customer acquisition task requests submitted by users; The core scheduling module is used to realize indirect communication between agents, persistently save and load the execution status of each agent to support the resumption of execution from the breakpoint after the task is interrupted, and decompose the customer acquisition task into sub-tasks and schedule the execution of each agent through an event distribution mechanism; the core scheduling module splits the task into multiple shards according to the customer dimension, and different shards are executed in parallel. When a single shard fails, it is only placed in the retry queue, and other shards continue to execute. After all executions are completed, the output data of each shard is merged into a unified output. The Customer Development Skill module is used to execute the complete customer acquisition process from keyword generation to customer search, official website parsing, email acquisition, email verification, customer rating, CRM database entry, and development outreach. The external service module is used to provide external tools and API calling services for the customer to develop Skill modules.

2. The foreign trade B2B customer development system based on multi-agent collaboration according to claim 1, characterized in that, The core scheduling module includes an event bus kernel, an agent registry, a state manager, and a coordinator headAgent. The event bus kernel uses a publish-subscribe model to enable indirect communication between agents; all agents do not communicate directly but instead relay events through the event bus kernel. The agent registry stores the definitions, capability descriptions, and state transition rules of all agents in the system. The state manager persistently saves and loads the execution state of each agent. When an agent executes a long-process task, the state manager periodically creates a state snapshot. If a task is interrupted due to network interruption, API failure, or system restart, the agent resumes execution from the last saved state snapshot. The coordinator headAgent decomposes the customer acquisition task submitted by the user into a mission, breaks down the mission into a series of ordered grats, distributes them to each Arm Agent for execution through the event bus kernel, and monitors the execution progress of each Arm Agent.

3. The foreign trade B2B customer development system based on multi-agent collaboration according to claim 1, characterized in that, The customer development skill module includes eight sequentially linked Arm Agents that work collaboratively through event-driven mechanisms: Keyword Generation Agent, Customer Search Agent, Official Website Parsing Agent, Email Acquisition Agent, Email Verification Agent, Customer Rating Agent, CRM Database Entry Agent, and Developer Outreach Agent.

4. A foreign trade B2B customer development system based on multi-agent collaboration according to claim 3, characterized in that, The keyword generation agent calls the large language model to perform semantic understanding and expansion on the product category input by the user to generate product word variants. It then arranges and combines product words with customer type words and geographical limiting words. The combined keyword = product word × customer type word × geographical limiting word, and outputs a list of no less than a preset number of unique combined keywords. When the large language model API returns a rate-limiting status code, it triggers an exponential backoff retry. If the retry fails, it switches to a backup large language model or terminates the task. When the large language model expansion result is empty, the local preset thesaurus is used as a backup to generate basic product words; when the number of effective keywords is less than the preset number, the deduplication rules are relaxed and re-executed.

5. A foreign trade B2B customer development system based on multi-agent collaboration according to claim 3, characterized in that, The email acquisition agent employs a four-tiered priority strategy: the first priority is to crawl publicly accessible email addresses by iterating through the official website's Contact page; the second priority is to call the Hunter.io and Snov.io email mining APIs to query indexed email addresses based on domain names; the third priority is to generate inferred email addresses based on domain names and employee names; and the fourth priority is to retrieve publicly accessible business email addresses from LinkedIn and Facebook platforms. When the Hunter.io API is rate-limited, the system switches to the Snov.io API; if both are unavailable, the third priority strategy is implemented. If the official website page traversal exceeds a preset timeout, the current page traversal is terminated, and the already acquired email address is used. If no email address is obtained after executing the four-tiered strategy, the customer is marked as "email_not_found," and the customer record continues to be passed to subsequent agents. If the target website's robots.txt blocks crawling the Contact page, the page is skipped, and other page paths are tried; if all paths are blocked, the subsequent priority strategies are implemented.

6. A foreign trade B2B customer development system based on multi-agent collaboration according to claim 3, characterized in that, The email verification agent executes a three-layer progressive verification mechanism: the first layer is a regular expression format verification based on the RFC5322 standard; The second layer verifies the consistency between the email domain and the customer's official website domain; the third layer checks the validity of the MX record via DNS and initiates a connection test via the SMTP protocol; Email trust level PassLevel=f(V format V domain V setup )∈{High,Medium,Low}, where V format V indicates whether the format validation passed. domain V indicates whether the domain name matching verification passed. setup This indicates whether the SMTP reachability test passed; the criteria for a High rating is V. format ∧V domain ∧V setup Clear all three levels; Medium level requirement is V. format ∧V domain Pass and V setup To be confirmed, the Low rating criteria are only applicable to V-level users. format pass.

7. A foreign trade B2B customer development system based on multi-agent collaboration according to claim 3, characterized in that, The customer rating agent employs a four-dimensional weighted rating model: each dimension is assigned a preset weight; the product matching degree is calculated through the following steps: the product category text extracted from the official website and the product category text input by the user are processed by word segmentation and stop word removal, a TF-IDF vector is constructed based on a pre-trained industry corpus, and the pre-processed text is input into the Sentence-BERT semantic model to obtain semantic vectors, according to... Calculate the overall similarity, where α is a preset fusion coefficient that can be configured within a preset range, and S match Indicates the overall similarity. and These represent the semantic vectors of the product category text input by the user and the product category text extracted from the official website, respectively. and Let S represent the TF-IDF vectors of the product category text input by the user and the product category text extracted from the official website, respectively; when the semantic model is unavailable, α=0 degenerates to TF-IDF cosine similarity, and S... match Mapped to a preset score range; Overall score: Score = w1 × S brand +w2×S product +w3×S country +w4×S email , of which S brand S indicates brand strength score product S represents the product matching score. country S represents the country priority score. email The email quality score is represented by w1, w2, w3, and w4, which represent the preset weights for the brand strength dimension, product matching dimension, country priority dimension, and email quality dimension, respectively. The classification standard is as follows: the comprehensive score reaches the first preset threshold and is classified as A; the comprehensive score is lower than the first preset threshold but reaches the second preset threshold and is classified as B; and the comprehensive score is lower than the second preset threshold and is classified as C.

8. A foreign trade B2B customer development system based on multi-agent collaboration according to claim 3, characterized in that, The CRM entry agent maps customer information to the database's standard field structure, performing domain-level and email-level deduplication: the deduplication key DedupKey = normalize(domain) + "|" + normalize(email). When a historical record with the same main domain already exists in the database, if the new record's overall score is higher than the historical record's score by more than a preset difference, an update operation is performed; otherwise, the insertion of the new record is rejected. If CRM API integration is enabled in the enterprise system configuration, the customer creation or update API of the CRM system is called; if CRM integration is not configured, a structured Excel file is directly exported and saved to the output directory configured in the system.

9. A foreign trade B2B customer development system based on multi-agent collaboration according to claim 2, characterized in that, When the Head Agent performs task sharding, it calculates the number of shards according to ShardCount=⌈N / ShardSize⌉, where N is the total number of target customers and ShardSize is the capacity of a single shard and can be configured within a preset range. The number of resource pool instances P = min(MaxConcurrency, ⌊CPUcore×2 / StageComplexity⌋), where MaxConcurrency is the maximum concurrency configured by the system, CPUcore is the number of local CPU cores, and StageComplexity is the computational complexity weight of each Stage. When a single Shard fails to execute, it is placed in the retry queue and retried a maximum of preset number of times according to the exponential backoff strategy. If it still fails after the preset limit of retry count is reached, the Shard is marked as partially completed, and the results of the completed Stages 1 to Stage k-1 are retained. Here, k represents the Stage number that failed to execute. After all Shards have been executed, the output data of each Shard is merged according to the customer ID. When the same customer appears in different Shards, the record with the higher score is used. After global domain-level deduplication, a Mission-level execution report is generated.

10. A method for developing foreign trade B2B customers based on multi-agent collaboration, characterized in that, Includes the following steps: S1. Users submit customer acquisition task requests containing product categories and target countries through the user interaction module. After receiving the task request, the coordinator Head Agent encapsulates it into a Mission object, decomposes the Mission into eight sequentially executed Grips, and issues the MISSION_START event through the event bus Kernel. S2, Keyword generation Agent receives MISSION START After the event, the large language model is invoked to semantically expand the product category, and the product words, customer type words and geographical qualifiers are combined to generate no less than a preset number of combined keywords. After completion, the STAGE_1_COMPLETED event is issued. S3. After listening to the STAGE_1_COMPLETED event, the Customer Search Agent calls the Google Custom Search API, LinkedIn Search API and Customs Data Platform interface in parallel based on the combined keywords to perform multi-source search, performs filtering on the search results, outputs a deduplicated list of potential customers, and emits the STAGE_2_COMPLETED event after completion. S4. After the official website's Agent listens for the STAGE_2_COMPLETED event, it uses a web automation framework to crawl the text content of the homepage, About Us page, and product catalog page. It calls a large language model to perform semantic analysis of product matching degree and customer type judgment on the crawled content, outputs structured customer information and target customer judgment tags, and then issues the STAGE_3_COMPLETED event. S5. After listening to the STAGE_3_COMPLETED event, the Email Acquisition Agent executes a four-level priority progressive email acquisition strategy for the target customer, marks the data source and pre-trust level of each source email, and then sends the STAGE_4_COMPLETED event after completion. S6. After listening to the STAGE_4_COMPLETED event, the email verification agent performs a three-layer progressive verification on the obtained email address, including format verification, domain name matching verification, and MX record query plus SMTP connection test. It outputs the credibility level and sends the STAGE_5_COMPLETED event after completion. S7. After listening to the STAGE_5_COMPLETED event, the Customer Scoring Agent calculates the comprehensive customer score based on a weighted scoring model of four dimensions: brand strength, product matching degree, country priority, and email quality, and outputs the level label. After completion, it sends the STAGE_6_COMPLETED event. After listening to the STAGE_6_COMPLETED event, the S8 and CRM database entry agent maps A or B class customer data to standard database fields, performs domain-level and email-level deduplication checks, writes the data to the database or exports it to an Excel file, and then issues the STAGE_7_COMPLETED event. S9. After listening to the STAGE_7_COMPLETED event, the Developer Outreach Agent filters customers into Class A or Class B based on their customer rating level, matches industry email templates, and calls the large language model to generate personalized development emails. It sends the first development email via SMTP service and creates a scheduled follow-up plan for customers who have successfully sent the email. After completion, it issues the STAGE_8_COMPLETED event. S10. After listening to the STAGE_8_COMPLETED event, the Head Agent of the Coordinator updates the global state of the Mission to completed. It extracts outputData from all eight Grips, synthesizes a complete customer profile according to the customer dimension, generates a task report, and pushes it to the user interaction module.

Images