一篇阿里博文引发的思考和探索。

基于大语言模型的智能Agent系统

1. 系统核心思想

核心思想是构建一个以大语言模型（LLM）为“大脑”的智能代理（Agent），旨在解决将人类的自然语言指令高效、准确地转化为机器可执行的自动化任务。系统通过LLM + RAG (检索增强生成) + Tools的组合，让用户仅需通过一句话，即可驱动系统完成原本需要跨多个应用、执行多个步骤的复杂操作，实现“所想即所得”。更通顺的说，以对话的交互方式代替之前复杂ERP系统的流程交互。

ERP系统人力流程样例：

在这里插入图片描述

2. 核心组件定义

系统主要由三大核心组件构成，分别扮演“大脑”、“记忆”和“双手”的角色。

2.1. 大语言模型 (LLM) - “大脑”
- 定义: 系统的中央处理器和决策核心。它负责理解用户的模糊意图、进行逻辑推理、制定行动计划、并以人性化的方式反馈结果。
2.2. 知识库 (Knowledge Base) - “记忆”
- 定义: LLM的外部知识源，通过RAG技术为LLM提供决策所需的、实时的、精确的上下文信息。它包含两个关键部分：
  - 2.2.1. 原子能力工具库 (Atomic Tool Library)
    - 定义: 一份关于**“所有可用工具”的详细说明书**。它精确定义了每一个独立的、最小颗粒度的功能（即“原子工具”），包括其功能描述、所需参数、使用范例等。它回答了“我有什么具体能力？”的问题。
  - 2.2.2. 工具调用规则库 (Tool Call Rule Library)
    - 定义: 一本关于**“如何完成复杂任务”的流程蓝图（菜谱）**。它定义了各种业务场景下，需要按什么顺序、组合调用哪些原子工具来完成任务。它回答了“要达成一个大目标，分几步走？”的问题。
2.3. 执行引擎 (Execution Engine) - “双手”
- 定义: 一个确定性的、非AI的程序。它负责接收并严格执行由LLM大脑规划好的行动计划，调用原子工具，并管理任务状态。

3. 核心流程实现

系统的工作流程可以分解为以下五个关键步骤：

意图理解 (Intent Understanding)
- 用户通过自然语言界面输入指令。LLM接收到指令后，进行初步的语义分析，理解用户的核心意图和提取关键参数。
RAG检索 (RAG Retrieval)
- LLM带着用户的意图，并行地在原子能力工具库和工具调用规则库中进行向量相似度检索，找出与当前任务最相关的“工具说明”和“流程蓝图”。
动态规划 (Dynamic Planning)
- LLM综合“用户原始指令”和“RAG检索到的上下文”，生成一个结构化的、包含完整执行步骤和参数映射的行动计划（DAG）。此阶段能灵活应对三种情况：
  - 单点任务: 若用户指令只对应单个原子工具，则直接生成调用该工具的计划。
  - 复杂任务: 若用户指令匹配到工具调用规则库中的某个流程，则以此为模板生成计划。
  - 动态任务: 若用户指令介于两者之间（如执行某个流程的一部分），LLM能基于对工具的理解，动态编排出一个新的、裁剪过的执行计划。
计划执行 (Plan Execution)
- 执行引擎接管LLM生成的计划，并严格按照计划中定义的顺序和依赖关系，依次调用原子工具层的API接口，完成与后端系统的实际交互。
结果反馈 (Result Feedback)
- 执行引擎将最终的执行结果返回。LLM可以（可选地）对技术性的结果进行总结，以通俗易懂的自然语言向用户汇报任务成果。

4. 数据结构样例

以下是两大知识库的核心数据结构及其JSON样例。

4.1. 原子能力工具库 (Atomic Tool Library)

作用: 定义“零件”的规格。
样例: 定义“创建员工档案”工具。

{"tool_name": "create_employee_record","description": "用于在人力资源系统中为一名新员工创建基础的个人档案。成功执行后会返回新创建员工的唯一ID（employee_id）。","parameters": [{"name": "full_name","type": "string","description": "员工的法定全名","required": true},{"name": "national_id","type": "string","description": "员工的身份证号码","required": true}]
}# 数据结构 (Data Structure)
{"tool_name": "string",          // 工具的唯一标识符，像函数名一样"description": "string",        // 详细描述工具的功能、用途和适用场景，写给LLM看"parameters": [                 // 工具所需的参数列表{"name": "string",           // 参数名"type": "string",           // 参数类型 (e.g., 'string', 'integer', 'boolean')"description": "string",    // 参数的详细描述"required": "boolean"       // 该参数是否为必填项}],"examples": [                   // (可选但推荐) 调用该工具的用户提问示例{"user_query": "string","extracted_params": {"param_name": "value"}}]
}

4.2. 工具调用规则库 (Tool Call Rule Library)

作用: 提供“组装图纸”。
样例: 定义“新员工入职流程”。

{"rule_name": "new_hire_onboarding_process","description": "一个完整的新员工入职流程，涵盖了从创建档案到分配部门的全过程。","dag_definition": [{"step_id": 1,"tool_name": "create_employee_record","description": "第一步：为新员工创建个人档案。","dependencies": [],"parameter_mapping": {"full_name": { "source": "initial_query", "value": "full_name" },"national_id": { "source": "initial_query", "value": "national_id" }}},{"step_id": 2,"tool_name": "assign_department","description": "第二步：为新员工分配部门和职位。","dependencies": [1],"parameter_mapping": {"employee_id": { "source": "step_output", "step_id": 1, "value": "employee_id" },"department": { "source": "initial_query", "value": "department" }}}]
}# 数据结构 (Data Structure)
{"rule_name": "string",        // 规则的唯一标识符，代表一个完整的业务流程"description": "string",      // 对整个业务流程的宏观描述"trigger_phrases": [          // (可选但推荐) 可能会触发此规则的用户常用短语"string"],"dag_definition": [           // 定义工作流的有向无环图 (DAG){"step_id": "integer",     // 步骤的唯一ID"tool_name": "string",    // 此步骤需要调用的原子工具名称 (必须与工具库中的tool_name对应)"description": "string",  // 对这一步骤的人性化描述"dependencies": [         // 此步骤依赖的前置步骤的step_id列表，为空则代表是起始步骤"integer"],"parameter_mapping": {  // 定义此步骤工具的参数来源"param_name": {"source": "string",   // 来源类型: 'initial_query' (来自用户原始提问), 'step_output' (来自前置步骤的输出)"value": "string"     // 如果来源是'initial_query'，这里是参数名；如果是'step_output'，这里是来源步骤的输出键名 (e.g., 'employee_id')}}}]
}

【转发】别再手搓测试数据了！AE测试数据智造系统揭秘

本文介绍如何通过构建基于大语言模型的测试数据智造Agent，解决AliExpress跨境电商测试中数据构造复杂、低效的问题，推动测试效率提升与智能化转型。

{% quot el:h8 引言 icon:default %}

在AliExpress跨境电商的复杂业务场景下，复杂业务模式（例如跨境、本地）、多类型物流方式、分国家运营策略、多币种、多语言等各因子叠加，测试经常面临测试数据构造复杂且困难、学习成本高、耗时长等问题。测试用例的初衷是验证业务逻辑，却被数据构造的“脏活累活”绑架了。

如今，大语言模型与原子工具库的结合，可以重新定义测试数据构造的工作模式。我们构建的测试数据智造助手，让"生成一个命中单品补贴的pop待评价订单"这样的复杂需求，只需一句自然语言描述即可自动完成全链路数据构造。

一、核心痛点

以构造一个包含业务类型、组合营销优惠、物流线路等多种条件的测试数据为例：测试往往需要辗转于测试商家后台、营销运营工作台、各业务域的测试工具平台等多个系统，记忆各种参数规则，耗时费力地拼接出一个完整的测试场景。

随着业务的快速扩张，测试数据的复杂性和多样性持续增长，更加暴露出了传统的数据构造模式存在以下痛点：

**多域依赖：**测试数据构造依赖交易、支付、营销等多个业务域，工具分散于不同平台，操作链路冗长；
**协作成本高：**跨域工具使用需多团队协调，理解成本和重复工作量巨大；
**效率瓶颈：**人工构造复杂场景（如各状态订单、组合优惠等）耗时高达小时级，增加了测试执行的时间。

二、破局思路

通过引入AI智能聚合编排测试数据构造能力，构建统一调度中台，可以有效解决这些问题，提高测试数据构造的效率和质量。

**核心思想：**通过LLM大模型+RAG技术实现自然语言驱动，结合多业务域原子工具单点调用和链式调用，实现全链路测试数据"所想即所得"。

三、目标

从0-1建设AE测试数据智造Agent，统一测试工具AI接入方式，聚合多业务域测试原子能力，解决测试数据构成本高、造耗时长等问题，实现“提效”、“降本”、“提升覆盖率”，在自动化场景中实际运用。

**提效：**将复杂场景（如跨境订单、组合优惠）的测试数据构造耗时从小时级缩短至分钟级。
**降本：**减少开发&测试时在数据构造的理解成本和重复工作量。
**覆盖率：**覆盖订单生命周期，支持多个核心业务域的复杂场景。

四、智造Agent实现方案

4.1设计思路

用户以自然语言提出询问时，Agent 会依据用户输入的内容，在 RAG 测试工具知识库中进行信息检索。RAG技术能帮助 Agent 精准匹配到与用户问题相关的信息。
Agent 将用户提出的问题以及从知识库中检索到的信息，一同输入到 LLM 大语言模型中。大语言模型凭借其强大的语言理解能力，对用户的意图进行识别和分析，并将用户意图分为测试信息查询、原子数据构造和链路数据构造这几类。
基于识别出的用户意图，Agent 会匹配相应的一个或多个原子工具，以及链路调用工具的规则。这些原子工具是实现数据构造的基础组件，各自具备特定的数据处理功能。同时，Agent 会从用户问题里提取出原子工具必要的关键参数。
依据知识库中的业务规则、数据模板和相关知识，使用提取出来的参数调用工具库中的原子能力生成符合用户需求的测试数据。最后，Agent 将生成的测试数据进行合理组装，以清晰、易懂的格式回复给用户，完成整个测试数据生成与反馈的流程。

举个🌰

用户指令：给商品id为123456（示例ID，非真实数据）的商品生成一笔退货退款的订单。

Agent处理流程：

1.使用用户的问题去匹配知识库中的场景，与“退货退款”链路的背景内容关联度最高。

2.将用户问题和知识库匹配结果共同传入大模型，识别用户意图为通过退货退款链路构造测试数据，该链路涉及的原子工具及调用顺序规则为：下单—>支付—>发货—>确认收货—>申请退货退款—>同意退货—>退货—>同意退款。

3.提取必要参数商品id：123456（示例ID，非真实数据），将其作为入参传给下单原子工具。然后将下单工具生成的订单id传给支付工具，之后按照按照顺序调用原子工具。

4.将状态推进成功的订单回复给用户。

4.2Agent架构设计

**前端交互：**提供自然语言输入界面，用户通过描述需求（如“构造一个使用平台券的pop商品订单”）触发流程。
**语**义解析：**结合RAG从知识库中匹配工具链规则信息和原子工具信息，再通过LLM大模型解析用户意图。
**原子工具调度：**根据工具链规则信息和原子工具信息调用原子工具服务（HSF/HTTP请求），实现原子工具间的依赖关系与参数传递，生成用户想要的测试数据。

因此可以抽象为三层系统架构，具体如下：

4.2.1规则抽象层

通过构建《原子能力工具库》、《工具调用规则库》的知识库实现。

原子能力工具库：每个原子工具定义工具描述、提问示例、参数说明以及原子工具维度的参数映射规则。

工具调用规则库：将业务场景抽象成原子工具调用规则，再通过DAG有向无环图的方式进行规则的定义。

4.2.2执行调度层

工具链调用：编写数据智造prompt提示词使大模型能够根据规则生成对应的执行计划。

参数透传：在工具链上的规则输出的结果会根据参数语义透传给后续工具，不需要人工进行干预。

失败重试策略：工具调用失败自动触发重试，重试超过5次触发断点，需要人工确认。

4.2.3原子工具层

通过AI应用开发平台的工具箱能力执行原子工具的真实调用，从而实现测试数据的自动构造。

4.3关键实现模块解析

4.3.1AI应用开发平台

基于AI应用开发平台进行对话型AI智能体设计，在Agent中调用RAG知识库、LLM大语言模型、自定义工具等能力实现AE测试工具构造功能。


# Role: AE测试数据构造助手——全链路测试数据生成专家## Profile
- **Author**: AE测试团队
- **Version**: V0.1.1
- **Language**: 中文  
- **Description**: 专注通过自然语言交互，自动化生成覆盖交易、支付、营销等全业务域的复杂测试数据，实现"所想即所得"。
## 核心原则
1. **三源数据优先级**  `用户输入参数 > 常用测试数据 > 原子工具默认值
2. **文档引用规范**  - 链路流程 → 《工具调用规则库》  - 工具定义 → 《原子能力工具库》  - 默认数据 → 《常用测试数据》## Core Capabilities
1. **意图精准识别**  - 支持识别7大场景类型：  `基础订单生成 | 营销活动构造 | 逆向流程推进 | 跨境场景模拟 | 用户资产管理 | 数据状态查询 | 异常场景构造`  2. **参数深度提取**  - **常规参数**：商品ID、用户ID、订单ID - **场景扩展参数**：  {"营销活动": ["活动类型", "优惠门槛", "叠加规则"],"逆向流程": ["纠纷类型", "退款原因", "风控等级"],"跨境场景": ["关税模式", "物流渠道", "货币类型"]}
3. **动态链路生成** 基于目标状态自动裁剪工具链（如"已支付"状态仅调用创建+支付工具）
A[输入解析] --> B{是否跨域?}  B -->|是| C[组合规则引擎]  B -->|否| D[单域规则匹配]  C & D --> E[工具链执行]  E --> F[结果聚合]## Workflow (严格遵循)
1.**提取请求参数**
...2. **工具调度阶段**  
环境适配 → 根据用户输入的环境特征选择对应工具版本
链式执行 → 按《工具调用规则库》定义的工具顺序执行
参数桥接 → 自动将上游工具出参映射为下游工具入参
状态演进 → 每个工具执行后必须推进业务状态到目标阶段3. **异常处理机制**  
...## Output Format(强制规范)
...

4.3.2原子能力工具库构建

梳理研发测试过程中测试数据构造&测试数据查询的原子操作进行封装和抽象，并在AI应用开发平台的工具空间对工具封装成API。

4.3.3测试工具知识库建设

为了让 AI 智能体能够精准识别用户意图，并使用正确参数调用工具组件，因此通过结构化工具描述文档搭建 RAG 测试工具知识库。该知识库是 AI 智能体理解用户需求和执行任务的关键基础。

需要维护的测试工具知识库涵盖两大部分：

原子测试工具描述文档：将原子测试工具的使用背景、使用说明以及使用范例整理后录入知识库。AI 智能体在识别到具体业务场景时，就能快速匹配到对应的原子工具，进而实现数据构造和数据查询。

工具名称：请填写工具名称。
工具描述：请填写工具描述、使用场景，方便大模型理解工具。
提问示例：请填写提问相关的示例，支持多条。
参数说明：参数名称-参数描述（是否必填）以及参数枚举

数据构造链路描述文档：把数据构造链路的背景信息、原子工具的调度链路以及具体原子工具名称都输出到知识库中。如此，AI 智能体在面对特定业务场景时，便能准确对应到具体的数据构造链路，然后依照链路顺序调用原子工具，完成数据构造任务。

链路名称：退货退款链路
链路背景：售后退货退款是指买家在下单支付完成，货物确认收货后买家申请退货退款，卖家同意退款的链路。用户用淘宝账号购买指定itemId的商品并且支付生成淘宝订单号orderId。在买家确认收货后的时候买家提交退货退款申请，生成退款单，退款单号disputeid,然后卖家同意退货，买家退货，最后卖家同意退款申请。
链路信息：下单—>支付—>发货—>确认收货—>申请退货退款—>同意退货—>退货—>同意退款