Dapr Durable Agents 是 Dapr 社区在 2025 年推出的 AI Agent 开发框架,它将 LLM 的推理与行动能力深度嵌入 Dapr Workflow 运行时,赋予 AI 智能体云原生的耐久性、状态持久化和容错能力。

Dapr 简介

Dapr(Distributed Application Runtime,分布式应用运行时) 是由微软发起并开源、现属于 CNCF(云原生计算基金会)托管的孵化项目。它是一个可插拔的、事件驱动的运行时,旨在让开发人员能够轻松构建弹性、无状态和有状态的微服务应用程序。

为什么需要 Dapr?(痛点与背景)

在传统的微服务架构开发中,开发人员通常会面临以下核心痛点:

Dapr 的核心出发点是:让开发人员专注于业务逻辑,而将所有分布式的共性需求(如状态、消息、调用)抽离出来,交给运行时来处理。

Dapr 是什么?(核心架构与概念)

Dapr 是一个面向开发人员的、具有自包含 API 的分布式应用运行时。

核心设计模式:Sidecar

Dapr 采用 Sidecar 架构。这意味着 Dapr 作为一个独立的进程(在 Kubernetes 中作为一个独立的容器)与应用程序并行运行。

D2 Diagram
qtopie.github.io

核心概念:Building Blocks(构建块)与 Components(组件)

Dapr 将分布式系统的能力抽象成了多个构建块(Building Blocks)。每个构建块对外暴露统一、标准化的 API,而底层则由可插拔的组件(Components)来实现:

总结来说: Dapr 是应用与底层基础设施(如数据库、消息队列)之间的“隔离层”或“操作系统”。

D2 Diagram
qtopie.github.io

怎么使用 Dapr?(开发与落地)

使用 Dapr 的典型流程通常分为本地开发和生产部署两步:

本地开发准备

首先,需要在本地安装 Dapr CLI(命令行工具),并通过初始化命令启动 Dapr 的本地开发环境(通常会默认启动一个 Redis 容器作为状态存储和 pub/sub 代理):


# 安装 Dapr CLI 后初始化

dapr init

编写代码(以状态管理为例)

由于 Dapr 暴露的是标准 HTTP API,代码可以非常简单。

本地启动应用与 Dapr Sidecar

使用 Dapr CLI 来拉起应用进程和 Dapr 边车进程:

dapr run --app-id myapp --app-port 5000 --dapr-http-port 3500 python app.py

配置底层组件(无侵入切换)

Dapr 的精髓在于,如果想把底层的 Redis 换成 MySQL,完全不需要修改任何一行代码,只需要修改一个 YAML 配置文件(components/statestore.yaml):

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
spec:
  type: state.redis  # 如果想换成 MySQL,只需改为 state.mysql 并配置对应连接串

  version: v1
  metadata:
    - name: redisHost
      value: localhost:6379
    - name: redisPassword
      value: ""

生产部署(通常在 Kubernetes 中)

在 Kubernetes 环境中,Dapr 提供了 Sidecar Injector 控制器。只需要在部署应用的 Deployment YAML 中加入简单的 Annotations(注解)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
        dapr.io/enabled: "true"       # 告诉 Dapr 注入 Sidecar

        dapr.io/app-id: "myapp"       # 服务唯一标识

        dapr.io/app-port: "5000"      # 应用监听的端口

Kubernetes 会自动把 Dapr 容器和应用容器打包在同一个 Pod 里,无缝接管所有的分布式流量与能力。

Dapr Durable Agents

Dapr Agents(以及其核心的 DurableAgent 类)是 Dapr 社区在 2025 年前后推出的、专门针对 AI Agent 场景的开源开发框架(目前首发主要支持 Python)。

简单来说,它是将 LLM 的推理/行动能力(Agentic AI)Dapr 强大的云原生分布式基础设施(特别是 Dapr Workflow) 进行深度融合的产物。旨在解决当前主流 AI 智能体框架(如 LangChain、CrewAI)在生产环境中普遍存在的脆弱性、缺乏状态持久化、难以应对长周期和节点崩溃等痛点。

以下从核心痛点、实现原理和架构优势三个维度为您拆解 Dapr Durable Agents:

为什么需要 Dapr Durable Agents?

在构建生产级的 AI Agent(如自动化代码审计、长流程跨境电商供应链调度)时,开发者会发现传统的 Agent 框架存在致命的"落地难"问题:

为什么选择 Dapr Agents?

可扩展的工作流(一等公民)

Dapr Agents 使用持久化执行(Durable Execution) 工作流引擎,保证每个 Agent 任务在网络故障、节点崩溃等破坏性故障面前都能执行到底。开发者无需理解工作流引擎的底层概念——只需编写执行任意数量任务的 Agent,这些任务会被自动分布到集群中。任何任务失败时,它将被重试并从断点恢复状态。

经济高效

Dapr Agents 构建于 Dapr Workflow API 之上,底层使用 Actor 模型——一种线程安全且原生分布式的计算与状态单元,非常适配 Agent 的 Scale-To-Zero 架构。这最大限度地降低了基础设施成本。底层虚拟 Actor 模型允许数千个 Agent 按需在单核机器上运行,从零扩展时延迟仅为双位数毫秒。当 Agent 空闲时,系统回收其资源但保留状态,直到下次被唤醒。这种设计在性能和资源效率之间无需权衡。

D2 Diagram
qtopie.github.io

数据中心的 AI Agent

Dapr Agents 内置连接 50+ 企业级数据源,高效处理结构化与非结构化数据。从 PDF 提取到大规模数据库交互,它都能以最少的代码变更实现数据驱动的 AI 工作流。Dapr 的 Bindings 和 State Stores 为 Agent 提供了丰富的数据摄取通道。

加速开发

Dapr Agents 提供了一套完整的 AI 特性 API,帮助开发者快速解决常见问题:

内置安全与可靠性

基于 Dapr 运行时的弹性和安全策略可直接应用于 Dapr Agents:

内置消息与状态基础设施

构建块作用
服务调用Agent 间直接通信,内置服务发现、错误处理和分布式追踪
发布/订阅通过消息总线实现松耦合 Agent 协作,支持实时事件驱动
持久化工作流结合确定性过程与 LLM 决策,编排复杂的多步 Agent 工作流
状态管理灵活的 KV 存储,Agent 跨交互保留上下文,确保连续性
Actor虚拟 Actor 模式,Agent 作为自包含的有状态单元顺序处理消息

供应商中立 & 开源

作为 CNCF 孵化项目的一部分,Dapr Agents 完全供应商中立,消除了厂商锁定、知识产权风险或专有限制的顾虑。组织可以获得完全的灵活性和控制权,使用可审计、可贡献的开源软件构建 AI 应用。

核心机制:LLM 推理循环 → 确定性工作流

Dapr Durable Agents 的核心创新是将 Agent 的思考和行动生命周期完全托管给 Dapr Workflow,利用其事件溯源(Event Sourcing)和确定性重放(Deterministic Replay)机制。

D2 Diagram
qtopie.github.io

容错恢复流程

  1. 每成功执行一个 Activity,结果写入底层 Workflow Actor 的历史日志
  2. 崩溃后,编排器从头"重放"
  3. 重放时不重复消耗 Token,也不重复调用工具——前序 LLM 决策和工具结果直接从日志中读取
  4. Agent 精准回到崩溃前的那一步继续执行

推理步骤的 Activity 化与容错重放

DurableAgent 中,LLM 的每一次提示词生成(Prompt Generation)、每一次大模型推断(LLM Inference)、以及每一次工具调用(Tool Invocation),底层的执行逻辑都会被 Dapr 封装成一个 Dapr Workflow Activity

架构能力

虚拟 Actor 架构

每个 Agent 会话对应一个 Dapr Virtual Actor 实例:

D2 Diagram
qtopie.github.io

关键能力

详细实现机制

Dapr Durable Agents 能够实现云原生级的耐久性、长周期挂起与分布式扩展,其底层依赖于 Dapr 运行时的四大核心机制协同:

D2 Diagram
qtopie.github.io

确定性工作流引擎 (DTFx Replay Engine)

Dapr Durable Agents 将 Agent 的思考-行动循环(ReAct Loop)映射为 Dapr Workflow 编排函数,并将每次 LLM 推理与 Tool 工具调用封装为 Durable Activity

虚拟 Actor 封装与状态水合

每一个 Agent 会话(或多租户 Agent 实例)在 Dapr 中均被映射为一个独立的 Virtual Actor

Sidecar 层 Conversation API (Dapr 1.17+)

Dapr Durable Agents 不直接在 SDK 内部侵入式绑定特定的大模型 SDK,而是统一接入 Dapr 1.17+ 推出的 Conversation API

挂起、定时唤醒与人工介入 (Long-Running & HITT)

针对长周期 Agent 流程(如等待人工审批、定时轮询任务):

基础设施要求

组件要求作用
state.*支持 Transactions API,actorStateStore: "true"持久化 Agent 状态与记忆
conversation.*Dapr 1.17+ Conversation API统一 LLM 提供商抽象(OpenAI、Gemini、DeepSeek),速率限制与密钥轮转
pubsub.*事件驱动消息总线Agent 间异步通信,触发条件传递

关键特性

代码示例

from dapr.agents import Agent, DurableAgent, Tool

# 定义工具(底层对应 Dapr Workflow Activity)

@Tool
def fetch_system_logs(component: str) -> str:
    # 获取日志的业务逻辑

    return "error inside middleware..."

# 声明一个具备耐久能力的 Agent

class SREAgent(DurableAgent):
    def __init__(self):
        super().__init__(
            name="SREAgent",
            instructions="你是一个资深的云原生运维专家",
            llm_config={"model": "gpt-4o"},
            tools=[fetch_system_logs]
        )

# 执行(底层自动启动 Dapr Workflow)

agent = SREAgent()
result = agent.execute("分析网关错误并给出修复建议")

调用 agent.execute 时,Dapr 在后台创建一个持久化工作流。即使 fetch_system_logs 执行期间网络卡死,Dapr 的重试策略和弹性机制也会接管,确保 Agent 恢复后不丢进度地继续分析推理。

生态整合:Dapr Outside, Eino Inside

在更复杂的多 Agent 场景(如 Domour 项目)中,Dapr Durable Agents 与字节跳动的 Eino 框架形成了互补协作:

总结