<!-- title: 经典模式回潮：Agent六栈实测 -->

# 经典模式回潮：Agent六栈实测

2026年最值得关注的Agent基建趋势，不是某个新框架的发布，而是分布式系统经典模式向Agent世界的集体迁移。事件溯源（Event Sourcing）、Saga事务、Actor模型、CQRS读写分离、持久执行（Durable Execution）、发布/订阅事件总线——这六套在微服务时代被反复验证的模式，正在以惊人的速度被移植到多Agent系统中。原因很简单：当Agent从Demo走向生产，遇到的恰好是微服务十年前踩过的同一个坑——状态丢失、部分失败、级联崩溃、不可审计。本文实测六栈在Agent场景下的适配度、迁移成本和实际收益。

## 六栈全景对比

| 模式 | 经典来源 | Agent落地代表 | 核心价值 | 上手成本 | 生产成熟度 |
|------|---------|-------------|---------|---------|-----------|
| Event Sourcing | DDD/CQRS生态 | ESAA(arXiv:2602.23193) | 决策可回放、可审计 | 中 | 论文验证+开源实现 |
| Saga | 微服务分布式事务 | SagaLLM、Microsoft AGT、Katha | 多步失败自动补偿 | 中高 | Microsoft AGT已GA |
| Actor | Erlang/Akka/Orleans | Akka Agents、Ray Actors | 状态隔离、天然并发 | 高 | Akka/Orleans久经考验 |
| CQRS | DDD/读写分离 | Firestore+BigQuery模式 | 读写路径分离优化 | 中 | 已有生产案例 |
| Durable Execution | Temporal/Orkes | Temporal+Agent管道 | 工作流不丢不重 | 中 | Temporal企业级可用 |
| Event-Driven/Pub-Sub | Kafka/NATS | LangGraph事件流、Zylos架构 | Agent间解耦通信 | 低中 | 框架内建支持 |

---

## 一、事件溯源：Agent决策的时间机器

事件溯源的核心思想是把Agent的每一个决策、每一次工具调用、每一次状态变更记录为不可变事件流，而不是只保存最终状态。这意味着你可以把Agent"倒带"到任意时刻——这在审计、调试和合规场景中是杀手级能力。

ESAA（Event Sourcing for Autonomous Agents，arXiv:2602.23193）是第一个系统化地将事件溯源引入LLM Agent架构的论文。它的关键创新在于将Agent系统分为两层：认知层（Cognitive Layer）和执行层（Execution Layer）。认知层是LLM产生意图的地方，执行层是将意图转化为具体操作的地方。事件流记录的不仅仅是"做了什么"，更是"为什么这样做"。

```python
# ESAA风格的事件溯源实现 - 核心事件定义
from dataclasses import dataclass
from datetime import datetime
from typing import Any
import json

@dataclass
class AgentEvent:
    event_id: str
    aggregate_id: str       # Agent实例ID
    event_type: str         # cognition | decision | tool_call | tool_result | state_change
    timestamp: datetime
    payload: dict
    cognitive_context: dict  # LLM的推理上下文（为什么做这个决定）

class AgentEventStore:
    """Agent事件存储 - 支持回放和审计"""
    
    def append(self, event: AgentEvent):
        # 追加写入，不可修改
        self._store.append(event)
    
    def reconstruct_state(self, agent_id: str, up_to: datetime = None) -> dict:
        """从事件流重建Agent在任意时刻的完整状态"""
        state = {}
        for event in self._store.query(agent_id, up_to=up_to):
            if event.event_type == "state_change":
                state.update(event.payload)
            elif event.event_type == "tool_call":
                state["last_tool"] = event.payload["tool_name"]
        return state
    
    def audit_trail(self, agent_id: str) -> list:
        """导出完整审计轨迹：每个决策+推理过程"""
        return [
            {
                "decision": e.payload,
                "reasoning": e.cognitive_context,
                "timestamp": e.timestamp
            }
            for e in self._store.query(agent_id)
            if e.event_type in ("decision", "tool_call")
        ]
```

**实测结论**：事件溯源在Agent场景的适配度极高，但有一个经典问题被放大了——事件膨胀速度远超传统微服务。一个典型的编码Agent每分钟可能产生50-200个事件（每次LLM调用、每次工具执行、每次上下文更新都是事件），一天下来就是数十万条。必须配合快照（Snapshot）机制定期压缩。

**变现路径**：Agent审计合规是2026年企业刚需。金融、医疗、法律行业的Agent部署都面临"你的Agent为什么做了这个决策"的质询。事件溯源+审计报表是可以直接打包成SaaS产品的方向。

---

## 二、Saga模式：Agent失败自动补偿

多Agent协作最大的噩梦不是单个Agent失败，而是前三个Agent成功了、第四个失败了——系统处于一个不一致的半完成状态。Saga模式为每一步"正向操作"配对一个"补偿操作"，失败时按逆序执行补偿，回滚到一致性状态。

2026年有三股力量在推动Saga在Agent场景的落地：

**SagaLLM**（arXiv:2503.11951，来自Stanford）是最重要的学术贡献。它识别了多Agent规划中的四个基础挑战：上下文管理、验证、事务保证和补偿执行。关键创新是双轨验证机制——不仅验证Agent的输出是否正确，还验证补偿操作本身是否安全可执行。

**Microsoft Agent Governance Toolkit**（2026年4月开源）是企业级方案。它在Agent运行时层面实现了Saga编排器，支持LangChain、AutoGen、Semantic Kernel等多个框架的Agent接入。

**Katha**（GitHub: darshjme/katha）是轻量级开源实现。"Katha"取自印度古代故事集Kathasaritsagara，寓意"神圣的故事"——每个Saga都是一个故事。它专注于长时间运行的LLM Agent工作流，零依赖。

```python
# Katha风格的Saga编排 - 多Agent旅行预订
from katha import Saga, Step, Compensation

travel_saga = Saga("book-trip")

@travel_saga.step(
    compensate=lambda ctx: cancel_hotel(ctx["hotel_id"])
)
async def book_hotel(ctx):
    hotel_id = await hotel_agent.book(
        destination=ctx["destination"],
        dates=ctx["dates"]
    )
    return {"hotel_id": hotel_id}

@travel_saga.step(
    compensate=lambda ctx: cancel_flight(ctx["flight_booking_id"])
)
async def book_flight(ctx):
    booking = await flight_agent.search_and_book(
        origin=ctx["origin"],
        destination=ctx["destination"],
        dates=ctx["dates"]
    )
    return {"flight_booking_id": booking.id}

@travel_saga.step(
    compensate=lambda ctx: refund_payment(ctx["payment_id"])
)
async def process_payment(ctx):
    total = ctx["hotel_cost"] + ctx["flight_cost"]
    payment = await payment_agent.charge(
        amount=total,
        method=ctx["payment_method"]
    )
    return {"payment_id": payment.id}

# 执行 - 任何步骤失败自动补偿
result = await travel_saga.run({
    "origin": "Shanghai",
    "destination": "Tokyo",
    "dates": ("2026-07-01", "2026-07-05"),
    "payment_method": "card"
})
```

**实测关键发现**：Agent Saga与传统微服务Saga有一个本质差异——LLM的补偿操作本身不确定。传统系统中"退款"是一个确定性操作，但Agent执行的补偿可能涉及再次调用LLM，其结果不确定。Microsoft AGT的解决方案是补偿操作不允许调用LLM，只允许执行确定性工具。Katha则更激进，允许"最佳努力补偿"——如果补偿也失败了，进入人工干预队列。

**变现路径**：Saga编排能力是Agent平台的差异化壁垒。任何涉及多步、多Agent、有副作用的业务流程（订单处理、理赔流程、法律文书链）都需要它。训练营场景可以直接从"多Agent旅行预订"Demo切入，讲解失败场景和补偿设计。

---

## 三、Actor模型：Agent的天然运行时

Actor模型可能是六栈中与Agent契合度最高的。一个Actor就是一个计算单元，拥有私有状态、通过消息通信、互不共享内存——这几乎就是Agent的定义。2026年的关键进展是几个经典Actor框架正式推出了Agent SDK层。

**Akka Agents**（akka.io/akka-agents）是最成熟的方案。Akka本身有15年历史，JVM生态最成熟的Actor框架。它在2025年底推出了Agent SDK层，允许开发者用声明式Effects API定义Agent。每个Agent内部是一个Akka Actor，天然获得状态隔离、位置透明、容错监督等能力。它还原生支持MCP（Model Context Protocol）工具暴露，以及HTTP/gRPC API自动生成。

```java
// Akka Agents - 声明式Agent定义 (Java SDK)
import akka.javasdk.agent.Agent;
import akka.javasdk.agent.Effects;

public class ResearchAgent extends Agent {
    
    private final String systemPrompt = """
        You are a research analyst agent. Analyze the given topic,
        search for relevant information, and produce a structured report.
        """;
    
    @Override
    public Effects.Effect<String> onMessage(String message) {
        return effects()
            .systemPrompt(systemPrompt)
            .tools("web_search", "document_analyzer")  // MCP工具
            .thenReply(response -> response);
    }
    
    // 自动暴露为HTTP端点
    // POST /agents/research
    // 自动暴露为MCP工具
    // MCP tool: research_agent
}
```

**Microsoft Orleans**走的是虚拟Actor路线。与Akka的显式Actor生命周期不同，Orleans的Grain（虚拟Actor）由运行时自动激活/停用，开发者不需要关心Actor何时创建、在哪台机器上运行。这对于Agent场景特别有吸引力——你可以把每个用户会话、每个任务实例映射为一个Grain，不需要担心成千上万个Agent实例的资源管理。

**Ray Actors**（Anyscale）从AI基础设施角度切入。Ray本身是分布式ML计算框架，其Actor原语被用于管理有状态的模型推理服务。2026年的新进展是Ray Serve正式支持多Agent架构，通过MCP和A2A协议连接Agent，利用Ray的自动扩缩容能力处理Agent的弹性负载。

| Actor框架 | Agent场景优势 | 局限性 |
|----------|-------------|--------|
| Akka Agents | JVM生态成熟、MCP原生、监督树容错 | 学习曲线陡峭、JVM资源开销 |
| Orleans | 虚拟Actor自动管理、C#生态 | .NET绑定、Agent粒度控制弱 |
| Ray Actors | ML原生、自动扩缩容 | Python生态偏ML、通用Agent能力弱 |

**变现路径**：Actor模型是"从Demo到生产"的关键跳板。大量团队在Python框架里跑通了Agent Demo，但一上生产就遇到并发、状态管理、容错问题。Akka Agents定位的就是这个gap。训练营可以设计"Python Agent迁移到Akka Agents"的实操课。

---

## 四、CQRS：Agent的读写双引擎

CQRS（Command Query Responsibility Segregation）将Agent的状态管理分为两个独立路径：命令路径处理Agent的决策和动作（写入），查询路径处理Agent的状态检索和报告（读取）。这对Agent场景的价值在于：LLM推理是慢操作（秒级），而状态查询可能需要毫秒级响应。

一个典型的生产案例是Firestore（写）+ BigQuery（读）模式：

```python
# CQRS for AI Agents - 读写分离模式
class AgentCommandHandler:
    """命令侧：处理Agent的决策和动作"""
    
    def __init__(self):
        self.firestore = FirestoreClient()  # 低延迟写入
        self.event_bus = EventBus()          # 发布事件
    
    async def handle_decision(self, agent_id: str, decision: dict):
        # 1. 写入命令（Firestore保证强一致）
        await self.firestore.collection("agent_commands").add({
            "agent_id": agent_id,
            "decision": decision,
            "timestamp": datetime.utcnow()
        })
        # 2. 发布事件触发读侧更新
        await self.event_bus.publish("agent.decision.made", {
            "agent_id": agent_id,
            "decision_type": decision["type"],
            "result": decision["result"]
        })

class AgentQueryHandler:
    """查询侧：优化过的Agent状态视图"""
    
    def __init__(self):
        self.bigquery = BigQueryClient()  # 分析型查询
        self.cache = RedisClient()          # 热数据缓存
    
    async def get_agent_status(self, agent_id: str) -> dict:
        # 从缓存或物化视图读取（毫秒级）
        cached = await self.cache.get(f"agent_status:{agent_id}")
        if cached:
            return cached
        # 回退到BigQuery物化视图
        result = await self.bigquery.query(
            "SELECT * FROM agent_status_materialized WHERE agent_id = @aid",
            params={"aid": agent_id}
        )
        await self.cache.set(f"agent_status:{agent_id}", result, ttl=60)
        return result
```

**关键陷阱**：经典CQRS引入了最终一致性——写入后可能需要几秒到几分钟才能在查询侧看到。在传统微服务中这是可接受的，但Agent在推理过程中依赖实时状态读取来做下一步决策。Tacnode的研究文章专门分析了这个问题：当Agent成为读侧消费者时，最终一致性可能导致Agent基于过期状态做出错误决策。解决方案是命令侧使用强一致存储（Firestore），查询侧通过事件流实时刷新缓存，将不一致窗口压到毫秒级。

---

## 五、持久执行：Agent工作流不丢不重

Temporal在2026年成为Agent持久执行的事实标准。其核心承诺是：Agent工作流一旦启动，无论进程崩溃、网络中断、服务器重启，都能自动恢复到精确的断点继续执行。

```python
# Temporal + Agent工作流 - 持久化多Agent协作
from temporalio import workflow, activity
from datetime import timedelta

@activity.defn
async def call_research_agent(topic: str) -> dict:
    """可中断、可重试的Agent调用"""
    return await research_agent.run(topic)

@activity.defn
async def call_writer_agent(research: dict) -> str:
    return await writer_agent.run(research)

@activity.defn
async def call_reviewer_agent(draft: str) -> dict:
    return await reviewer_agent.run(draft)

@workflow.defn
class ArticleProductionWorkflow:
    """文章生产流水线 - 保证不丢不重"""
    
    @workflow.run
    async def run(self, topic: str) -> str:
        # Step 1: 研究 - 最多重试3次，每次超时5分钟
        research = await workflow.execute_activity(
            call_research_agent,
            topic,
            start_to_close_timeout=timedelta(minutes=5),
            retry_policy=RetryPolicy(maximum_attempts=3)
        )
        
        # Step 2: 写作
        draft = await workflow.execute_activity(
            call_writer_agent,
            research,
            start_to_close_timeout=timedelta(minutes=10),
            retry_policy=RetryPolicy(maximum_attempts=2)
        )
        
        # Step 3: 审核（可挂起等待人工审批）
        review = await workflow.execute_activity(
            call_reviewer_agent,
            draft,
            start_to_close_timeout=timedelta(minutes=15),
        )
        
        if review["approved"]:
            return draft
        else:
            # 不通过 - 自动回到Step 2带修改意见重写
            return await self.run_with_feedback(topic, review["feedback"])
```

**实测数据**：Temporal官方声称Agent开发速度提升50%，但实际测试发现这个数字有条件——仅适用于"工作流步骤明确、重试策略清晰"的场景。对于需要Agent动态决定下一步做什么的探索性任务，Temporal的工作流即代码（Workflow-as-Code）模型反而增加了复杂度，因为每一步可能的分支路径都需要预先定义。AWS AgentCore + Temporal的集成方案在2026年Q1正式发布，提供了更友好的抽象层。

---

## 六、事件驱动架构：Agent间解耦通信

事件驱动架构（EDA）是六栈中最容易落地的——不需要重写Agent内部逻辑，只需要在Agent之间插入一个事件总线。2026年的主流做法是在Agent框架内建事件机制：

```mermaid
graph TB
    subgraph Event Bus
        EB[Kafka / NATS / Redis Streams]
    end

    subgraph Producer Agents
        A1[研究Agent]
        A2[数据Agent]
    end

    subgraph Consumer Agents
        A3[写作Agent]
        A4[审核Agent]
        A5[发布Agent]
    end

    subgraph Event Store
        ES[事件溯源存储]
    end

    A1 -->|research.completed| EB
    A2 -->|data.available| EB
    EB -->|research.completed| A3
    EB -->|data.available| A3
    A3 -->|draft.ready| EB
    EB -->|draft.ready| A4
    A4 -->|review.approved| EB
    EB -->|review.approved| A5
    EB -->|all events| ES

    style EB fill:#f9f,stroke:#333,stroke-width:2px
    style ES fill:#bbf,stroke:#333,stroke-width:2px
```

Zylos的研究报告（2026-03-02）系统化地分析了Pub/Sub、事件溯源和响应式模式如何成为多Agent通信的骨干。LangGraph的内建事件流是最轻量的实现——每个Graph节点执行后自动发布事件，下游节点通过条件边订阅。适合简单场景，但不支持跨服务的事件广播。

对于需要跨服务、跨部署的Agent通信，Kafka和NATS是主流选择。Kafka的优势是持久化和回放能力（与事件溯源天然互补），NATS的优势是超低延迟和轻量部署。

---

## 六栈架构全景图

```mermaid
graph LR
    subgraph "经典模式层"
        ES[Event Sourcing<br/>事件溯源]
        SG[Saga<br/>分布式事务]
        AC[Actor Model<br/>并发原语]
        CQ[CQRS<br/>读写分离]
        DE[Durable Execution<br/>持久执行]
        ED[Event-Driven<br/>事件驱动]
    end

    subgraph "Agent场景层"
        AUDIT[审计合规]
        COMP[失败补偿]
        SCALE[弹性伸缩]
        PERF[性能优化]
        RELI[可靠执行]
        DECOUP[解耦通信]
    end

    subgraph "工具/框架层"
        ESAA[ESAA]
        KATHA[Katha/agent-saga]
        AKKA[Akka Agents]
        BQ[Firestore+BigQuery]
        TEMP[Temporal]
        KAFKA[Kafka/NATS]
    end

    ES --> AUDIT
    SG --> COMP
    AC --> SCALE
    CQ --> PERF
    DE --> RELI
    ED --> DECOUP

    AUDIT --> ESAA
    COMP --> KATHA
    SCALE --> AKKA
    PERF --> BQ
    RELI --> TEMP
    DECOUP --> KAFKA

    style ES fill:#e1f5fe
    style SG fill:#fff3e0
    style AC fill:#e8f5e9
    style CQ fill:#fce4ec
    style DE fill:#f3e5f5
    style ED fill:#e0f2f1
```

## 综合推荐矩阵

| 你的场景 | 推荐首栈 | 推荐二栈 | 原因 |
|---------|---------|---------|------|
| 金融/医疗Agent | Event Sourcing | Saga | 审计刚需+事务保证 |
| 电商/订单Agent | Saga | Durable Execution | 多步补偿+可靠执行 |
| 内容生产Agent | Event-Driven | Durable Execution | 解耦协作+不丢任务 |
| 企业级Agent平台 | Actor(Akka) | Event Sourcing | 弹性伸缩+审计 |
| 数据分析Agent | CQRS | Event-Driven | 读写分离+异步流水线 |
| 快速MVP验证 | Event-Driven | — | 零依赖，框架内建 |

## 趋势判断：为什么是现在？

分布式经典模式向Agent的迁移不是偶然，而是Agent从"玩具"走向"工具"的必然产物。2025年Agent的焦点是"能做什么"（推理、工具调用、记忆），2026年的焦点变成了"做得有多可靠"（一致性、容错、审计）。六栈恰恰回答的都是可靠性的问题。

值得注意的信号：Microsoft在2026年4月开源Agent Governance Toolkit时，直接把Saga编排作为核心组件——这说明微软认为分布式事务补偿已经是Agent基础设施的标配，而非锦上添花。Akka从JVM中间件公司转型为Agent平台公司，也验证了Actor模型在Agent场景的商业价值。

一个更深层的原因是：Agent的非确定性放大了分布式系统的经典问题。传统微服务的失败模式是可预测的（网络超时、服务宕机），补偿策略可以提前设计。但Agent的失败模式包含LLM幻觉、推理偏移、上下文溢出——这些是传统分布式系统没有遇到过的。六栈提供的不是银弹，而是一套经过十年验证的韧性工具箱，让Agent在面对不确定性时至少有一个结构化的兜底方案。

最后，六栈之间存在天然协同：Event Sourcing是基础（记录一切），Saga是保障（失败补偿），Actor是运行时（并发管理），CQRS是优化（读写分离），Durable Execution是保险（不丢不重），Event-Driven是粘合剂（连接一切）。真正生产级的Agent系统，至少需要三栈以上的组合。2026年下半年的看点是哪个框架能率先把这六栈统一到一个开发者友好的抽象层下——目前看Akka Agents和Microsoft AGT走在最前面。

---

## 参考来源

1. [ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering (arXiv:2602.23193)](https://arxiv.org/abs/2602.23193) — 首篇系统化将事件溯源引入LLM Agent架构的论文，提出认知层/执行层分离模型
2. [SagaLLM: Context Management, Validation, and Transaction Guarantees for Multi-Agent LLM Planning (arXiv:2503.11951)](https://arxiv.org/abs/2503.11951) — Stanford提出的多Agent Saga架构，双轨验证机制
3. [Microsoft Agent Governance Toolkit - Saga Orchestration](https://microsoft.github.io/agent-governance-toolkit/tutorials/11-saga-orchestration/) — 微软2026年4月开源的Agent治理工具包中的Saga编排组件
4. [Katha: Distributed Saga Pattern for Multi-Agent Systems (GitHub)](https://github.com/darshjme/katha) — 轻量级Agent Saga编排库，零依赖，专注长时间运行LLM工作流
5. [Akka Agents: Quickly Create Agents, MCP Tools, and HTTP/gRPC APIs](https://akka.io/blog/akka-agents-quickly-create-agents-mcp-grpc-api) — Akka官方Agent SDK，基于Actor模型+声明式Effects API
6. [Event-Driven Architecture for AI Agent Systems (Zylos)](https://zylos.ai/en/research/2026-03-02-event-driven-architecture-ai-agent-systems) — Pub/Sub、事件溯源、响应式模式在多Agent通信中的系统分析
7. [CQRS for AI Agents: Why Eventual Consistency Breaks Autonomous Systems (Tacnode)](https://tacnode.io/post/cqrs-pattern) — 分析CQRS最终一致性在Agent场景的陷阱与解决方案
8. [Temporal + AI Agents: Durable Execution and Workflow-as-Code](https://callsphere.ai/blog/temporal-ai-agent-workflows-durable-execution-workflow-as-code) — Temporal持久执行在Agent工作流中的实践指南

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)