L2层:数据处理与意图解析
L2层架构定位: L2层(意图处理层)作为智能采购平台的数据中枢,负责将L1层采集的原始意图转化为结构化数据并进行解析处理。主要职责包括:
- 数据模型设计:定义采购意图、执行工单、订单凭证等数据结构
- 意图标准化:将不同平台的商品信息转化为统一数据格式
- 数据验证:对采集数据进行合法性、完整性、一致性检验
- 状态管理:管理采购意图的全生命周期状态流转
- 业务逻辑:实现基础的业务规则校验和数据转换
技术特点:
- 采用规范化的数据模型设计,保障数据完整性
- 使用JSON字段存储灵活的扩展数据
- 支持基于状态机的流程管理
- 提供RESTful API接口供其他层调用
4.1 数据模型设计
4.1.1 统一采购意图模型
Intent 表结构与字段说明:
| 字段名 | 数据类型 | 约束 | 必填 | 描述 | 示例值 |
|---|---|---|---|---|---|
| id | TEXT | PK | Y | 采购意图唯一标识(CUID) | “clx1w2y3z0000abcdef123456” |
| userId | TEXT | INDEX | Y | 发起用户ID | ”user_123” |
| platform | TEXT | INDEX | Y | 电商平台标识 | ”TAOBAO”, “JD”, “PDD” |
| productUrl | TEXT | - | Y | 商品原始链接 | ”https://detail.tmall.com/item.htm?id=123 ” |
| title | TEXT | - | Y | 商品标题 | ”Apple iPhone 15 Pro 256GB 深空黑色” |
| price | DECIMAL(10,2) | CHECK>0 | Y | 商品单价(元) | 8999.00 |
| quantity | INT | CHECK>0 | Y | 采购数量 | 2 |
| recipientName | TEXT | - | Y | 收货人姓名 | ”张三” |
| address | TEXT | - | Y | 收货详细地址 | ”北京市朝阳区xxx路xx号” |
| phone | TEXT | - | Y | 收货人联系电话 | ”13800138000” |
| status | TEXT | INDEX | Y | 内部处理状态 | ”DRAFT”, “SUBMITTED”, “PROCESSING”, “COMPLETED”, “FAILED” |
| createdAt | TIMESTAMP | DEFAULT NOW() | Y | 创建时间 | ”2024-12-08 14:30:25” |
| updatedAt | TIMESTAMP | AUTO UPDATE | Y | 更新时间 | ”2024-12-08 15:45:10” |
| remarks | TEXT | - | N | 备注信息 | ”急用,请优先处理” |
4.1.2 执行工单模型
Order 表结构与字段说明:
| 字段名 | 数据类型 | 约束 | 必填 | 描述 | 示例值 | 关联关系 |
|---|---|---|---|---|---|---|
| id | TEXT | PK | Y | 执行工单唯一标识(CUID) | “clx1w2y3z0001abcdef123456” | - |
| intentId | TEXT | FK, INDEX | Y | 关联的采购意图ID | ”clx1w2y3z0000abcdef123456” | → Intent.id |
| priceTolerance | DECIMAL(5,2) | DEFAULT 10.00 | Y | 价格容错百分比 | 10.00 | - |
| assignedAgent | TEXT | - | N | 分配的AI代理 | ”agent_taobao_01” | - |
| status | VARCHAR(20) | INDEX | Y | 执行状态 | ”PENDING”, “EXECUTING”, “SUCCESS” | - |
| startedAt | TIMESTAMP | - | N | 开始执行时间 | ”2024-12-08 16:00:00” | - |
| completedAt | TIMESTAMP | - | N | 完成时间 | ”2024-12-08 16:15:30” | - |
| executionLog | JSON | - | N | 执行步骤日志 | {"steps": [{"action": "login"}]} | - |
| errorMessage | TEXT | - | N | 执行失败原因 | ”商品库存不足” | - |
| retryCount | INT | DEFAULT 0 | Y | 重试次数 | 1 | - |
| createdAt | TIMESTAMP | DEFAULT NOW() | Y | 创建时间 | ”2024-12-08 15:45:10” | - |
4.1.3 发票与凭证模型
Receipt 表结构与字段说明:
| 字段名 | 数据类型 | 约束 | 必填 | 描述 | 示例值 | 关联关系 |
|---|---|---|---|---|---|---|
| id | TEXT | PK | Y | 记录唯一标识(CUID) | “clx1w2y3z0002abcdef123456” | - |
| intentId | TEXT | FK, INDEX | Y | 关联的采购意图ID | ”clx1w2y3z0000abcdef123456” | → Intent.id |
| orderId | TEXT | FK, INDEX | Y | 关联执行工单ID | ”clx1w2y3z0001abcdef123456” | → Order.id |
| platformOrderNo | TEXT | INDEX | Y | 电商平台订单号 | ”TB202412085566778” | - |
| paymentId | TEXT | - | Y | 支付流水号 | ”2024120821001001570” | - |
| paidAmount | DECIMAL(10,2) | CHECK>0 | Y | 实际支付金额 | 17998.00 | - |
| paymentMethod | TEXT | - | N | 支付方式 | ”支付宝”, “微信支付” | - |
| invoiceType | TEXT | - | N | 发票类型 | ”电子发票”, “纸质发票” | - |
| invoiceNumber | TEXT | - | N | 发票号码 | ”23442000000123456” | - |
| invoiceUrl | TEXT | - | N | 发票文件下载链接 | ”https://xxx.com/invoice.pdf ” | - |
| invoiceTitle | TEXT | - | N | 发票抬头 | ”北京某某科技有限公司” | - |
| trackingNumber | TEXT | - | N | 物流单号 | ”SF1234567890” | - |
| logisticsCompany | TEXT | - | N | 物流公司 | ”顺丰速运” | - |
| status | VARCHAR(20) | INDEX | Y | 订单状态 | ”PAID”, “SHIPPED”, “DELIVERED” | - |
| orderTime | TIMESTAMP | - | Y | 下单时间 | ”2024-12-08 16:10:25” | - |
| deliveryTime | TIMESTAMP | - | N | 发货时间 | ”2026-02-10 09:30:00” | - |
| completedAt | TIMESTAMP | - | N | 完成时间 | ”2026-02-12 14:20:15” | - |
| createdAt | TIMESTAMP | DEFAULT NOW() | Y | 记录创建时间 | ”2026-02-09 16:15:30” | - |
数据模型拆分设计理念: 将数据模型拆分为三个独立的表,主要基于以下业务和技术考量:
| 拆分维度 | Intent | Order | Receipt | 设计原因 |
|---|---|---|---|---|
| 业务阶段 | 意图采集与审批 | 执行控制与监控 | 结果记录与归档 | 不同阶段有不同的数据特征和操作需求 |
| 数据生命周期 | 创建频繁,读取多 | 执行期间频繁更新 | 一次写入,长期存储 | 不同的访问模式需要不同的优化策略 |
| 权限控制 | 用户可见可编辑 | 系统内部控制 | 财务档案只读 | 不同角色对不同数据有不同权限需求 |
| 数据完整性 | 必须完整才能提交 | 允许渐进式更新 | 执行完成后才创建 | 不同阶段对数据完整性要求不同 |
| 系统解耦 | 前端交互层 | 执行引擎层 | 企业集成层 | 便于不同系统模块独立开发和维护 |
| 扩展性 | 字段相对稳定 | 执行日志复杂多变 | 发票物流信息多样 | 不同类型的数据有不同的扩展需求 |
核心设计考量:
- 时序分离:采购意图 → 执行工单 → 订单记录,体现业务的自然时序
- 职责单一:每个表专注一个业务环节,便于理解和维护
- 状态独立:各表状态完全独立,采购意图状态(DRAFT/SUBMITTED/PROCESSING/COMPLETED/FAILED)仅反映内部处理进度,不与企业审批系统状态耦合,避免外部系统变更影响内部数据一致性
- 查询优化:按业务场景分表,提高查询效率(如财务只查Receipt)
- 审计追踪:分离设计便于追踪每个环节的数据变更历史
数据模型设计原则:
- 合理的表结构:基于业务需求设计表结构,平衡规范化与查询效率
- 核心字段优先:保留业务必需的字段,确保数据完整性
- 扁平化设计:优化查询性能,便于开发和维护
- 状态驱动:通过状态字段管理业务流程,保证流程可控
- JSON存储:灵活的JSON字段存储结构化数据,适应业务变化
4.2 L2层数据处理流程
4.2.1 意图数据标准化流程
标准化处理要点:
- 价格统一:将不同平台的价格格式统一为标准数值
- 地址规范:收货地址按标准格式解析和验证
- 商品分类:自动识别商品类别并分配对应的业务规则
- 重复检测:检查是否存在重复的采购意图
4.2.2 状态流转管理
状态流转关系与触发条件的详细说明,确保业务流程的完整性和可控性。
4.3 L2层内部服务设计
4.3.1 核心服务组件
L2层定位:作为数据处理和意图解析的内部服务层,不对外暴露HTTP接口,通过内部服务调用处理业务逻辑。
采购意图处理服务 (IntentService):
interface IntentService {
// 创建采购意图
async createIntent(data: CreateIntentRequest): Promise<Intent>;
// 提交并验证采购意图
async submitIntent(
intentId: string,
options: SubmitOptions
): Promise<SubmitResult>;
// 开始处理采购意图
async processIntent(
intentId: string,
processor: string
): Promise<ProcessResult>;
// 完成处理
async completeIntent(
intentId: string,
notes: string
): Promise<void>;
// 标记失败
async failIntent(
intentId: string,
error: ProcessError
): Promise<void>;
// 查询采购意图
async getIntent(intentId: string): Promise<Intent>;
async queryIntents(filter: QueryFilter): Promise<Intent[]>;
}
// 数据类型定义
interface CreateIntentRequest {
platform: string;
productUrl: string;
title: string;
price: number;
quantity: number;
recipientInfo: RecipientInfo;
remarks?: string;
}
interface SubmitOptions {
submitNotes: string;
validationRules: string[];
}
interface SubmitResult {
success: boolean;
validationErrors?: ValidationError[];
intentId?: string;
}执行工单管理服务 (OrderService):
interface OrderService {
// 创建执行工单
async createOrder(
intentId: string,
agentId: string,
tolerance: number
): Promise<Order>;
// 开始执行
async startExecution(
orderId: string,
executionPlan: string[]
): Promise<ExecutionResult>;
// 记录执行步骤
async logStep(
orderId: string,
step: ExecutionStep
): Promise<void>;
// 完成执行
async completeExecution(
orderId: string,
orderDetails: OrderDetails
): Promise<void>;
// 执行失败
async failExecution(
orderId: string,
error: ExecutionError
): Promise<void>;
}
// 执行步骤数据结构
interface ExecutionStep {
stepName: string;
status: 'success' | 'failed' | 'pending';
timestamp: Date;
details: string;
metadata?: Record<string, any>;
}
interface OrderDetails {
orderNumber: string;
paidAmount: number;
completionDetails: string;
}4.3.2 服务调用关系
L2层服务调用模式:
// L1层 → L2层服务调用示例
class L1IntentCollector {
constructor(
private intentService: IntentService,
private orderService: OrderService
) {}
async handleUserSubmission(data: UserIntentData): Promise<void> {
// 1. 创建采购意图
const intent = await this.intentService.createIntent({
platform: data.platform,
productUrl: data.url,
title: data.title,
price: data.price,
quantity: data.quantity,
recipientInfo: data.recipient,
remarks: data.remarks
});
// 2. 提交并验证
const result = await this.intentService.submitIntent(intent.id, {
submitNotes: "用户确认提交",
validationRules: ["price_check", "address_format"]
});
if (!result.success) {
throw new ValidationError(result.validationErrors);
}
// 3. 自动开始处理
await this.intentService.processIntent(intent.id, "system_auto");
}
}L2层 → L3层服务调用:
// L2层处理完成后调用L3层执行
class L2IntentProcessor {
constructor(
private executionService: L3ExecutionService,
private orderService: OrderService
) {}
async onIntentProcessing(intentId: string): Promise<void> {
// 创建执行工单
const order = await this.orderService.createOrder(
intentId,
"agent_taobao_01",
0.1
);
// 触发L3层执行
await this.executionService.executeOrder(order.id);
}
}4.4 L2层数据验证与质量保证
4.4.1 多层验证机制
输入数据验证:
- 必填字段检查:确保关键业务字段不为空
- 格式验证:价格、电话、网址等格式正确性校验
- 数值范围检查:价格、数量等业务合理性校验
- 业务规则验证:采购金额限制、商品类别限制等
数据一致性保证:
- 事务完整性:使用数据库事务保证数据一致性
- 并发控制:防止同一意图被重复处理
- 数据备份:关键操作前后的数据快照
- 审计追踪:完整记录数据变更历史