【Agent 系统设计】基于大语言模型的智能Agent系统

发布于：2025-08-11 ⋅ 阅读:(17) ⋅ 点赞:(0)

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

基于大语言模型的智能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. 核心流程实现

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

  1. 意图理解 (Intent Understanding)
    • 用户通过自然语言界面输入指令。LLM接收到指令后，进行初步的语义分析，理解用户的核心意图和提取关键参数。
  2. RAG检索 (RAG Retrieval)
    • LLM带着用户的意图，并行地在原子能力工具库和工具调用规则库中进行向量相似度检索，找出与当前任务最相关的“工具说明”和“流程蓝图”。
  3. 动态规划 (Dynamic Planning)
    • LLM综合“用户原始指令”和“RAG检索到的上下文”，生成一个结构化的、包含完整执行步骤和参数映射的行动计划（DAG）。此阶段能灵活应对三种情况：
      • 单点任务: 若用户指令只对应单个原子工具，则直接生成调用该工具的计划。
      • 复杂任务: 若用户指令匹配到工具调用规则库中的某个流程，则以此为模板生成计划。
      • 动态任务: 若用户指令介于两者之间（如执行某个流程的一部分），LLM能基于对工具的理解，动态编排出一个新的、裁剪过的执行计划。
  4. 计划执行 (Plan Execution)
    • 执行引擎接管LLM生成的计划，并严格按照计划中定义的顺序和依赖关系，依次调用原子工具层的API接口，完成与后端系统的实际交互。
  5. 结果反馈 (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,然后卖家同意退货，买家退货，最后卖家同意退款申请。
链路信息：下单—>支付—>发货—>确认收货—>申请退货退款—>同意退货—>退货—>同意退款
五、Agent应用实践

AE测试数据智造Agent应用场景是多方面的。目前已接入钉钉答疑群和个人助手，以问答的方式作为业务日常测试的测试助手；也可以作为自动化测试（如接口自动化、用例自动化、压测等）的测试数据提供方，以HSF的接入方式对外提供数据构造基础能力。

图片

针对对外提供的数据构造基础能力，我们做了以下的系统架构设计来保障数据构造的准确性和稳定性。

5.1外部接入架构设计

图片

5.1.1漏桶算法限流

由于LLM大模型存在token、QPM限制，而上游平台会批量调用触发限流，所以需要做限流方案。

为了解决这一问题，需要对流量整形，限制对AE测试数据智造Agent的请求频率，避免触发LLM服务端限流，保障系统的稳定性。

限流算法选型：漏桶算法

**实现思路：**将请求视为水流，将其放入一个“漏桶”中，桶的出口以固定速率流出请求，从而实现对流量的平滑控制，从而以恒定的速率请求AE测试数据智造Agent。

漏桶容量 = 预估峰值流量 * 1.2)

漏水速率 = LLM每分钟限制 / 60 * 安全系数（如0.8）

5.1.2标准化输出

（1）业务错误场景处理

测试数据无法构造的场景对于AE测试数据智造Agent来说并不是系统错误，是属于业务层面的错误，直接请求不会返回错误码和错误信息。

因此在接口适配层识别这些业务错误的场景，返回对应的业务错误码和错误信息。

（2）标准化错误码

AI应用开发平台构建的Agent在系统错误时返回的错误码不符合AE的规范，因此在接口适配层按照AE的标准规范进行错误码的转换。

（3）输出结果标准化处理

由于上游对数据输出的格式要求严格，如果输出格式只写在AI规则里的话容易因为AI的幻觉导致输出的格式不符合规范。

JSON Schema校验：定义严格的响应结构模板，自动修复或拒绝非法格式（如字段类型错误、多余字段）。

5.1.3日志+监控

通过日志的方式，记录执行链路中的关键数据，并进行监控，分析大模型的执行结果，提供可监控、可分析的稳定性保障能力。

**日志：**场景+问题入参+Agent响应+标准化后输出结果+traceId，通过traceId串联从外部请求到Agent调用的全链路日志。

**基础监控：**Agent的RT和接口成功率。

**业务监控：**监控无法构造出测试数据的场景等。

**执行分析：**对无法构造出测试数据场景进行记录和分析，进行后续测试数据构造功能的迭代。

5.1.4缓存

**目的：**减少重复调用Agent的token开销，提升批量用例执行效率，减少耗时。

**缓存键设计：**对用户输入参数（如场景描述、业务参数）计算唯一哈希值，作为缓存主键。

**缓存策略：**成功结果缓存30分钟，失败结果缓存2分钟（防穿透）。

六、结果

当前Agent已完成8500+次问答（含调试）。简单测试数据构造场景，人工构造预估需要5分钟，AI可降至1-3分钟，提效约50%；复杂场景（如涉及长链路工具），人工构造预估1小时，AI可降至10-15分钟，提效约70%。

当前已完成的核心能力如下：

  • **原子工具调用：**共接入85+原子工具，覆盖交易下单、购物车、订单、营销、支付、逆向、商家、商品、招商等核心场景诉求。
  • **链式数据构造：**打通交易、营销、逆向跨域链式规则执行，实现各类订单状态数据、营销订单数据等的一键全流程构造。
  • **业务域接入友好：**各业务域原子工具和数据链路构造规则可以按照规范直接完成接入，无需感知Agent内部逻辑。
  • **多环境支持能力：**实现环境感知路由机制，支持根据用户需求动态切换线上/预发/项目隔离环境。

图片

七、未来展望

测试数据构造正在经历从"手工操作"到"智能服务"的转型。当各业务域的测试工具完成原子化改造，当大语言模型真正理解业务语义，我们距离"所想即所得"的终极目标将越来越近。未来的测试工程师可以更专注于场景设计而非数据准备，用创造力推动质量保障体系的持续进化。

这种智能化改造的价值不仅限于测试领域，其背后构建的业务语义理解能力和跨域协作机制，为整个研发体系的效能提升提供了新的可能性。或许在不远的将来，我们今天构建的智能助手，将成为新一代研发基础设施的重要组成部分。

流程图原始代码
后端系统
执行层 (确定性引擎)
HRM Agent 核心 (AI大脑)
知识库 (RAG检索)
自然语言指令
RAG检索
RAG检索
提供流程模板
提供工具定义
传递意图与参数
输出精确的执行计划
依次调用工具
执行具体数据库操作
返回操作结果
返回执行状态
返回结构化执行结果
生成人性化回复
最终输出
ERP 后端系统 • 员工数据库 • 薪酬数据库 • 组织数据库
执行引擎 (Orchestrator)
原子工具层 (ERP API 封装)
LLM: 意图识别 & 参数提取
LLM: 生成结构化执行计划 (DAG)
LLM: (可选)总结结果并生成回复
原子能力工具库 • 描述每个工具的功能 • 描述所需参数
工具调用规则库 • 定义业务流程/DAG
用户 (HR/业务经理)

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布