AI 驱动的分布式事务补偿策略自动生成：从异常模式到智能回滚方案

一、补偿策略的"经验黑箱"：分布式事务的人工决策瓶颈

分布式事务的补偿策略设计是微服务架构中最依赖经验的环节之一。当 Saga 事务中的某个参与方失败时，需要为已成功的步骤设计补偿操作。补偿操作不仅要恢复数据状态，还要考虑幂等性、并发安全和业务语义一致性。传统做法依赖架构师根据业务场景逐一设计补偿逻辑，面对数十个微服务、上百个事务分支时，人工设计补偿策略既耗时又容易遗漏边界条件。

更棘手的是，补偿策略往往在事故复盘时才被发现有缺陷。一个订单取消流程中，库存服务已扣减但补偿操作未考虑预占库存与实际库存的区别，导致超卖。这类问题在代码审查中难以发现，因为补偿逻辑的正确性取决于对业务语义的深度理解。

二、基于 LLM 的补偿策略推导：从事务拓扑到补偿图的自动构建

AI 辅助补偿策略生成的核心思路是：将分布式事务的执行拓扑和业务语义输入大模型，由模型推导每个参与方的补偿操作，并生成补偿图。

flowchart LR
    A[事务定义: TCC/Saga] --> B[参与方拓扑提取]
    B --> C[业务语义标注]
    C --> D[LLM 补偿推导]
    D --> E[补偿图生成]
    E --> F[幂等性检查]
    F --> G[补偿代码模板]

    subgraph 事务拓扑
        T1[订单创建] --> T2[库存扣减]
        T2 --> T3[支付扣款]
        T3 --> T4[物流创建]
    end

    subgraph 补偿图
        C1[订单取消] --> C2[库存恢复]
        C2 --> C3[支付退款]
        C3 --> C4[物流取消]
    end

补偿策略推导的关键约束包括：补偿操作必须是幂等的（同一补偿可安全执行多次）、补偿顺序必须与正向操作相反、补偿操作不能引入新的不一致状态。这些约束作为 Prompt 的一部分输入模型，引导其生成符合工程要求的补偿方案。

三、生产级代码实现与最佳实践

/**
 * AI 补偿策略生成服务
 * 将事务定义转换为 Prompt，调用 LLM 推导补偿方案
 */
@Service
@Slf4j
public class CompensationStrategyService {

    private final LlmClient llmClient;
    private final ObjectMapper objectMapper;

    /**
     * 根据事务定义自动生成补偿策略
     * 输出包含每个参与方的补偿操作描述和补偿代码模板
     */
    public CompensationPlan generateCompensation(SagaDefinition saga) {
        String prompt = buildCompensationPrompt(saga);

        // 使用低温度确保输出稳定性
        LlmResponse response = llmClient.chat(prompt, 0.05);

        try {
            CompensationPlan plan = objectMapper.readValue(
                response.getContent(), CompensationPlan.class
            );
            // 自动校验补偿策略的完整性
            validateCompensationPlan(saga, plan);
            return plan;
        } catch (Exception e) {
            log.error("补偿策略解析失败: {}", e.getMessage());
            throw new CompensationGenerationException("AI 生成的补偿策略格式异常", e);
        }
    }

    /**
     * 构建补偿推导 Prompt
     * 关键：将业务语义和工程约束同时注入
     */
    private String buildCompensationPrompt(SagaDefinition saga) {
        StringBuilder sb = new StringBuilder();
        sb.append("你是一个分布式事务补偿策略设计专家。\n");
        sb.append("请为以下 Saga 事务设计补偿策略，要求：\n");
        sb.append("1. 每个正向操作必须有对应的补偿操作\n");
        sb.append("2. 补偿操作必须幂等\n");
        sb.append("3. 补偿顺序与正向操作相反\n");
        sb.append("4. 补偿操作不能引入新的不一致\n\n");
        sb.append("事务定义：\n");

        for (SagaStep step : saga.getSteps()) {
            sb.append(String.format("- 步骤%d: %s (服务: %s, 操作: %s)\n",
                step.getOrder(), step.getName(),
                step.getService(), step.getAction()));
            sb.append(String.format("  语义: %s\n", step.getSemanticDescription()));
        }

        sb.append("\n请以 JSON 格式输出补偿策略。");
        return sb.toString();
    }

    /**
     * 校验补偿策略的完整性
     * 即使 AI 生成，仍需程序化校验基本约束
     */
    private void validateCompensationPlan(SagaDefinition saga,
                                            CompensationPlan plan) {
        // 检查每个正向步骤都有对应补偿
        for (SagaStep step : saga.getSteps()) {
            boolean hasCompensation = plan.getCompensations().stream()
                .anyMatch(c -> c.getStepName().equals(step.getName()));
            if (!hasCompensation) {
                throw new CompensationValidationException(
                    "步骤 " + step.getName() + " 缺少补偿操作");
            }
        }

        // 检查补偿顺序是否与正向操作相反
        List<String> forwardOrder = saga.getSteps().stream()
            .map(SagaStep::getName).toList();
        List<String> compensationOrder = plan.getCompensations().stream()
            .map(CompensationAction::getStepName).toList();

        List<String> reversed = new ArrayList<>(forwardOrder);
        Collections.reverse(reversed);
        if (!compensationOrder.equals(reversed)) {
            log.warn("补偿顺序与正向操作不完全相反，需人工确认");
        }
    }
}

/**
 * 补偿执行引擎
 * 按 AI 生成的补偿策略顺序执行，支持重试和跳过
 */
@Service
public class CompensationExecutor {

    /**
     * 执行补偿计划
     * 逐个执行补偿操作，单个失败不阻断后续补偿
     */
    public CompensationResult execute(CompensationPlan plan, SagaContext context) {
        List<CompensationResult.StepResult> results = new ArrayList<>();

        for (CompensationAction action : plan.getCompensations()) {
            try {
                // 幂等执行：先查询是否已补偿
                if (isAlreadyCompensated(action, context)) {
                    results.add(CompensationResult.StepResult.skipped(action));
                    continue;
                }

                // 执行补偿调用
                compensatingCall(action, context);
                results.add(CompensationResult.StepResult.success(action));

            } catch (Exception e) {
                // 单个补偿失败记录但不中断
                // 后续由人工介入或定时任务重试
                results.add(CompensationResult.StepResult.failed(action, e));
                log.error("补偿操作失败: step={}", action.getStepName(), e);
            }
        }

        return new CompensationResult(results);
    }
}

四、AI 生成补偿策略的局限：语义理解边界与验证鸿沟

业务语义理解边界。LLM 对补偿策略的推导基于 Prompt 中的语义描述。如果描述不够精确（如未区分"预占库存"和"实际扣减"），模型可能生成语义错误的补偿方案。AI 生成的是"建议"而非"保证"，必须经过人工审核。

验证鸿沟。补偿策略的正确性无法通过单元测试完全验证，因为补偿逻辑的正确性取决于运行时的业务状态。AI 生成的补偿代码模板需要适配具体的持久化层和并发控制机制，这一步仍需人工完成。

幻觉风险。模型可能为不存在的服务或操作生成补偿方案，或在补偿链中引入循环依赖。程序化校验（如拓扑完整性检查）可以过滤部分幻觉，但无法覆盖所有情况。

适用边界：AI 补偿策略生成适用于参与方数量较多、补偿逻辑相对模式化的 Saga 事务。对于补偿逻辑高度定制化、涉及复杂业务规则的事务，AI 的价值主要在于提供初始方案和发现遗漏，而非替代人工设计。

五、总结

AI 驱动的分布式事务补偿策略生成，通过将事务拓扑和业务语义输入 LLM，自动推导补偿操作和执行顺序，显著降低了人工设计的工作量。但 AI 生成的补偿方案存在语义理解边界和幻觉风险，必须结合程序化校验和人工审核。工程实践中，建议将 AI 定位为"补偿策略的初稿生成器"，配合幂等执行引擎和补偿结果审计，形成"AI 生成 + 人工审核 + 引擎保障"的三层防线。