状态管理与事务性是 Skills 工程化的分水岭

一个订单处理 Skill 的崩溃，往往从一句“请稍后重试”开始。
2026 年初的某个深夜，某电商平台促销期间，一个负责下单的 Skill 在执行“扣库存 → 创建订单 → 扣款 → 发送通知”四步流程时，在第二步成功后因 LLM 超时引发进程重启。重启后的 Skill 没有保留任何中间状态，直接从头再次执行，导致同一用户被重复扣款、库存被超额扣减。事后复盘时，开发团队意识到：他们面对的不再是一个可以随意重启的脚本，而是一个需要持久化状态、并发控制与事务恢复的工程系统。
这正是一道分水岭——当 Skill 需要长时间运行、多步骤协作时，状态管理与事务性保障便成为生产可用性的硬门槛。

从脚本到工程，Skill 的开发复杂度并不是线性增长的。根据当前社区调研，大量 LangGraph 或 CrewAI 项目在原型阶段只需几十行代码，但一旦进入生产环境，为了处理持久化、并发和回滚，代码规模与架构考量至少膨胀 2–3 倍。这背后反映的正是本章要解决的核心问题：面向长时间运行的 Skill，如何设计安全的状态持久化方案、如何避免并发竞争破坏数据、以及如何用事务思想将多步骤操作从崩溃中优雅恢复。

1. 现象与背景：工程化 Skill 正在强制补上“状态”这一课

AI Agent 社区在 2025–2026 年间达成了一个清晰共识：持久状态与事务语义是生产级 Agent 的基础能力（参考《AI Agent Engineering in 2026》）。LangGraph 在 2025 年将 checkpointing（检查点）作为一级原语引入，让开发者可以随时保存工作流状态并在故障后从断点续跑；OpenAI 的 Agents SDK 也在同一时期强化了与外部存储的集成。但无论在哪个框架下，一个尖锐的矛盾始终存在——LLM 调用本身是昂贵、缓慢且非确定性的，而围绕它的操作越来越多地要求强一致性和低延迟。

调研资料里提得最多的两大工程痛点，恰好都落在本章话题内：

• 长流程中状态的“锈蚀”：一个 Skill 可能需要执行数分钟乃至数小时，期间任何一步的网络抖动、模型速率限制或外部服务故障都会打断流程。若中间状态未被可靠保存，整个流程就只能重头再来，浪费算力不说，副作用带来的数据混乱几乎是必然的。
• 并发下状态的“踩踏”：当同一个订单被用户多次点击、或被上游消息队列重复投递时，多个 Skill 实例可能同时修改同一份数据。在没有锁机制的情况下，扣库存、发券等操作极易被重复执行。

这两点让“状态管理”与“事务性”不再是架构师的可选餐后甜点，而是 Skill 能否走出 PoC 阶段的最低准入标准。

2. 核心维度一：Skill 实例的状态模型设计

2.1 无状态与状态化 Skill 的边界在哪里？

先通过一张对比表格看清两类 Skill 的本质差异：

解读：
脚本级 Skill 适用于单一 API 调用的短任务，比如“分析这段文本的情绪”或“翻译这句话”。但一旦出现“分析后存入数据库、再发送邮件通知”这种多步骤序列，无状态设计就会立刻暴露缺乏恢复能力的致命缺陷。工程化的第一步是把 Skill 的执行逻辑包装成一个可序列化、可回放的状态机，这就是 LangGraph 中 StateGraph 的思想：每一步结束后，框架自动触发一次状态快照，写入用户指定的 checkpointer 存储。

2.2 选择合适的状态存储介质

在 LangGraph 生态中，checkpointer 的选型直接决定了持久化的可靠性和性能。以下是截至 2026 年中的常见选择：

选择逻辑：如果一个 Skill 的生命周期超过一次 HTTP 请求，就必须选择支持持久化的存储；如果它同时被超过一个并发请求访问同一数据实体，就必须选择支持事务和锁的存储。这直接导向 PostgreSQL 作为默认生产选择。

3. 核心维度二：并发调用下的状态竞争与锁机制

3.1 为什么并发会让 Skill 状态“悄悄被篡改”

假设一个库存扣减 Skill 的状态结构包含 {"sku": "ABC", "stock": 10}。两个并发请求几乎同时读取到 stock=10，各自执行 stock-1，然后写回。如果没有任何并发控制，最终库存可能只被扣减 1，而不是 2——经典的丢失更新问题。

在 LangGraph 的 StateGraph 中，状态的每次写入都会生成一个新的 checkpoint_id，这为乐观锁提供了天然的基础。但需要特别指出：社区正在探索利用 checkpoint_id 实现乐观锁的并发控制方案，当前 LangGraph 尚未内置此机制，2025 年的 Feature Request 表明这仍是待实现特性。
换言之，眼下要靠开发者自己在应用层实现并发安全。

3.2 两种主要锁模式的权衡

实现示例：在 PostgreSQL 中，可以直接在自定义 reducer 函数里使用 SELECT ... FOR UPDATE 对状态行加锁，再利用 LangGraph 的自定义 checkpointer 回调在每次保存时检查 checkpoint_id 版本。若版本不匹配，可抛出异常让框架重跑当前节点。

# 伪代码：使用 PostgreSQL 行锁确保并发安全
def reduce_inventory(state, update):
    with db.transaction():
        row = db.execute("SELECT stock FROM inventory WHERE sku=%s FOR UPDATE", (state.sku,))
        new_stock = row['stock'] - update.count
        if new_stock < 0:
            raise InsufficientStock()
        db.execute("UPDATE inventory SET stock=%s WHERE sku=%s", (new_stock, state.sku))
    return {"stock": new_stock}

要提醒的坑：使用 LLM 调用做状态决策时，锁的持有时间会变得难以预测（因为模型响应可能长达数秒甚至数十秒）。建议将锁的粒度控制在数据操作层，而不要让锁覆盖整个 LLM 调用。

4. 核心维度三：事务性操作与 Saga 模式入门

4.1 多步骤 Skill 的“多米诺骨牌”效应

前面提到的订单流程（扣库存→创建订单→扣款→发通知）是一个典型的多步骤事务。在传统关系型数据库中可以用 ACID 跨表事务，但 AI Agent 的工作流往往涉及多个异构系统——库存服务、支付网关、邮件服务——无法用一个数据库事务包裹。这时候需要的是最终一致性，而非强一致性。

Saga 模式正是为此而生：将一个长生命周期的业务事务拆分为一系列局部事务，每个局部事务都有一个对应的补偿操作。如果中途某一部失败，则按逆序执行已成功步骤的补偿，让系统回到最初的一致状态。

4.2 使用 LangGraph 节点编排简化 Saga

LangGraph 的图结构天然适配 Saga 模式：每个业务步骤是一个节点，节点之间通过条件边连接正常流程和补偿流程，并通过 checkpoint 保存执行进度。

# 演示：一个带补偿的 Saga 订单处理图（示意）
from langgraph.graph import StateGraph, END

class OrderState(TypedDict):
    step_history: list[str]  # 记录已成功步骤，用于补偿
    # ... 其他订单字段

def reserve_inventory(state):
    # 扣库存，若失败则无事发生
    return {"step_history": state["step_history"] + ["inventory"]}

def create_order(state):
    # 创建订单
    return {"step_history": state["step_history"] + ["order"]}

def charge_payment(state):
    # 扣款，可能失败触发补偿
    if not payment_success:
        raise PaymentFailed()
    return {"step_history": state["step_history"] + ["payment"]}

def notify_user(state):
    # 发送通知（补偿时通常只需记录失败日志）
    return {"step_history": state["step_history"] + ["notify"]}

# 补偿函数
def compensate(state):
    steps = state["step_history"]
    if "payment" in steps:
        refund_payment()   # 回退扣款
    if "order" in steps:
        cancel_order()    # 取消订单
    if "inventory" in steps:
        restore_inventory() # 回补库存
    return {"step_history": []}

# 构建图时加入错误边，指向补偿节点
builder = StateGraph(OrderState)
builder.add_node("reserve", reserve_inventory)
builder.add_node("create", create_order)
builder.add_node("charge", charge_payment)
builder.add_node("notify", notify_user)
builder.add_node("compensate", compensate)
builder.add_conditional_edges("charge", lambda s: "compensate" if s.get("error") else "notify")
# ... 其他边和编译

在实际工程中，补偿操作需要实现幂等性——因为补偿本身也可能被重复调用（比如在恢复检查点时）。常见的做法是为每个步骤分配一个业务唯一键（如订单号+步骤名），在数据库中记录执行状态，补偿前先查询是否已执行。

4.3 Saga 与非 Saga 方案的对比

小结：多数 Skills 的工程化会先经过“无状态重试”阶段，发现脏数据后升级到手动补偿逻辑，最后才抽象成标准 Saga。建议从一开始就为每个步骤设计对应的补偿动作，即使暂时用不到。因为补偿是一种业务知识，而非纯技术补丁。

5. 结论与场景推荐

状态管理与事务性设计并非越多越好，过度引入会大幅抬高开发与维护成本。从实践出发，可以按以下决策矩阵选择方案：

最终结论：

• 状态持久化是长时间运行 Skill 的安全带——即使整个系统崩溃，也能让流程回到正确的中断点。
• 并发控制是放牧一群 Skill 实例的牧羊犬——防止它们踩踏同一条数据。
• 事务性设计（Saga）是多步骤 Skill 的后悔药——当某一步失败，让系统优雅退回，而不是留下一地狼藉。

这三者共同构成了工程化 Skill 与脚本级 Skill 之间的分水岭。越过这道坎，开发者就具备了构建全天候、高可用、数据一致的 AI 系统的能力。

6. 迈向多个 Agent 的协同

至此，我们已经覆盖了单个 Skill 在错误处理、状态管理和事务性上的所有关键设计。但当业务需要多个 Skill 甚至多个 Agent 对话协作时，问题会从“一个流程的持久化”升级为“多条生命线之间的消息路由与共识维护”——这正是下一章《多 Agent 协作不是简单拼接，而是一种系统设计》将要深入探讨的内容。如何设计通信协议、如何避免代理间的消息风暴、如何实现分布式调试，都会一一拆解。

（正文完）