Dapr Durable Agents 是 Dapr 社区在 2025 年推出的 AI Agent 开发框架,它将 LLM 的推理与行动能力深度嵌入 Dapr Workflow 运行时,赋予 AI 智能体云原生的耐久性、状态持久化和容错能力。
Dapr 简介
Dapr(Distributed Application Runtime,分布式应用运行时) 是由微软发起并开源、现属于 CNCF(云原生计算基金会)托管的孵化项目。它是一个可插拔的、事件驱动的运行时,旨在让开发人员能够轻松构建弹性、无状态和有状态的微服务应用程序。
为什么需要 Dapr?(痛点与背景)
在传统的微服务架构开发中,开发人员通常会面临以下核心痛点:
- 分布式系统的复杂性(重复造轮子): 构建微服务时,开发人员不得不处理许多共性问题,如服务间调用、状态管理、消息发布/订阅、配置管理、安全认证等。为了解决这些问题,通常需要引入各种 SDK 和第三方库(例如 Spring Cloud 组件、各种消息队列和数据库的特定 SDK)。
- 严重的厂商/技术栈绑定(Vendor Lock-in): 如果代码中直接使用了 AWS DynamoDB 的 SDK 来管理状态,或者使用了 Azure Service Bus 来做消息队列,当企业决定将应用迁移到其他云平台(使用 Redis 或 RabbitMQ)时,需要重构大量的底层代码。
- 多语言支持困难: 许多优秀的分布式框架(如 Spring Cloud)对 Java 支持极好,但如果团队想用 Go、Python 或 Node.js 编写部分微服务,就需要寻找对应语言的生态,或者面临底层基础设施无法复用的困境。
Dapr 的核心出发点是:让开发人员专注于业务逻辑,而将所有分布式的共性需求(如状态、消息、调用)抽离出来,交给运行时来处理。
Dapr 是什么?(核心架构与概念)
Dapr 是一个面向开发人员的、具有自包含 API 的分布式应用运行时。

核心设计模式:Sidecar
Dapr 采用 Sidecar 架构。这意味着 Dapr 作为一个独立的进程(在 Kubernetes 中作为一个独立的容器)与应用程序并行运行。
- 应用程序不需要集成复杂的分布式 SDK,只需要通过轻量级的 HTTP 或 gRPC 标准协议与本地的 Dapr Sidecar 进行通信。
- 无论是 Java、Go、Python、.NET 还是 Rust,只要能发送 HTTP/gRPC 请求,就能直接使用 Dapr 的能力。
核心概念:Building Blocks(构建块)与 Components(组件)
Dapr 将分布式系统的能力抽象成了多个构建块(Building Blocks)。每个构建块对外暴露统一、标准化的 API,而底层则由可插拔的组件(Components)来实现:
- 服务调用(Service-to-Service Invocation): 提供安全、具有重试机制的反向代理与服务发现,让服务之间可以轻松相互调用。
- 状态管理(State Management): 统一的键值对(Key-Value)存储接口。可以用同一套 API 读写数据,底层组件可以自由切换为 Redis、MongoDB、CosmosDB 或 PostgreSQL。
- 发布/订阅(Publish and Subscribe): 统一的消息发布与订阅接口。底层可以自由切换为 Kafka、RabbitMQ、MQTT 或 AWS SNS/SQS。
- 输入/输出绑定(Bindings): 统一触发事件(如定时任务)或与外部系统(如 MySQL、Twilio、GitHub)交互的接口。
- Actors 模式: 专为并发、分布式状态打造的独立计算与状态单元。
- 工作流(Workflows): 编排长期运行的业务流程(Dapr v1.10+ 引入)。
- 配置(Configuration)与密码(Secrets): 统一访问系统配置和敏感凭据(如 HashiCorp Vault、Kubernetes Secrets)。
总结来说: Dapr 是应用与底层基础设施(如数据库、消息队列)之间的“隔离层”或“操作系统”。
怎么使用 Dapr?(开发与落地)
使用 Dapr 的典型流程通常分为本地开发和生产部署两步:
本地开发准备
首先,需要在本地安装 Dapr CLI(命令行工具),并通过初始化命令启动 Dapr 的本地开发环境(通常会默认启动一个 Redis 容器作为状态存储和 pub/sub 代理):
# 安装 Dapr CLI 后初始化
dapr init
编写代码(以状态管理为例)
由于 Dapr 暴露的是标准 HTTP API,代码可以非常简单。
保存状态(Go 示例,纯 HTTP 请求): 不需要引入 Redis SDK,只需要向 Dapr Sidecar 发送一个 POST 请求:
// 假设 Dapr 监听在本地 3500 端口,状态存储组件名为 "statestore" url := "http://localhost:3500/v1.0/state/statestore" jsonData := `[{"key": "weapon", "value": "Death Star"}]` resp, _ := http.Post(url, "application/json", bytes.NewBuffer([]byte(jsonData)))获取状态(使用 Dapr 官方提供的轻量级 SDK - 以 Python 为例): 虽然可以用原生 HTTP,但 Dapr 也为各语言提供了轻量级的 SDK 封装,方便结构化编写:
from dapr.clients import DaprClient with DaprClient() as d: # 获取 key 为 "weapon" 的数据 result = d.get_state(store_name='statestore', key='weapon') print(f"Result: {result.data}")
本地启动应用与 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 框架存在致命的"落地难"问题:
- 执行状态脆弱(Ephemeral Execution): LLM 的思考(Reasoning)和工具调用(Tool Calling)通常是一个多步循环(ReAct 模式)。如果在执行到第 5 步(比如调用某个耗时很长的外部 API)时,服务器节点崩溃或者网络中断,Agent 的整个上下文和执行进度就全丢了,必须从头再来。这在生产中不仅低效,还会白白消耗大量的 Token 成本。
- 缺乏长周期支持(Long-running Gaps): 很多企业级 Agent 的生命周期长达数天甚至数周(例如"等待财务人工审批"或"等待定时器触发")。现有的 Agent 框架很难优雅地在内存中挂起数天,并在被唤醒后精准恢复到当时的状态。
- 缺乏状态一致性与可观测性: 复杂的 Multi-Agent 协作中,Agent 之间的通信状态、记忆(Memory)持久化往往需要开发者手写大量的 Redis/数据库读写胶水代码,且缺乏开箱即用的分布式追踪(Telemetry)。
为什么选择 Dapr Agents?
可扩展的工作流(一等公民)
Dapr Agents 使用持久化执行(Durable Execution) 工作流引擎,保证每个 Agent 任务在网络故障、节点崩溃等破坏性故障面前都能执行到底。开发者无需理解工作流引擎的底层概念——只需编写执行任意数量任务的 Agent,这些任务会被自动分布到集群中。任何任务失败时,它将被重试并从断点恢复状态。
经济高效
Dapr Agents 构建于 Dapr Workflow API 之上,底层使用 Actor 模型——一种线程安全且原生分布式的计算与状态单元,非常适配 Agent 的 Scale-To-Zero 架构。这最大限度地降低了基础设施成本。底层虚拟 Actor 模型允许数千个 Agent 按需在单核机器上运行,从零扩展时延迟仅为双位数毫秒。当 Agent 空闲时,系统回收其资源但保留状态,直到下次被唤醒。这种设计在性能和资源效率之间无需权衡。
数据中心的 AI Agent
Dapr Agents 内置连接 50+ 企业级数据源,高效处理结构化与非结构化数据。从 PDF 提取到大规模数据库交互,它都能以最少的代码变更实现数据驱动的 AI 工作流。Dapr 的 Bindings 和 State Stores 为 Agent 提供了丰富的数据摄取通道。
加速开发
Dapr Agents 提供了一套完整的 AI 特性 API,帮助开发者快速解决常见问题:
- 多 Agent 通信:Agent 之间开箱即用的同步/异步通信机制
- 结构化输出:LLM 输出自动校验与类型约束
- 多 LLM 提供商:通过 Conversation API 统一适配 OpenAI、Gemini、DeepSeek 等
- 上下文记忆:短期与长期记忆自动托管
- 灵活提示词:声明式 Prompt 模板
- 智能工具选择:LLM 驱动的工具路由
- 零配置 MCP 集成:Agent 自动从 Dapr Sidecar 发现 MCPServer 工具
内置安全与可靠性
基于 Dapr 运行时的弹性和安全策略可直接应用于 Dapr Agents:
- Resiliency 策略:超时、重试/退避、熔断器(Circuit Breaker)
- 访问控制:按需将数据库或消息队列的访问范围限定到特定 Agent 应用
- 传输加密:底层通信使用 mTLS 加密
内置消息与状态基础设施
| 构建块 | 作用 |
|---|---|
| 服务调用 | Agent 间直接通信,内置服务发现、错误处理和分布式追踪 |
| 发布/订阅 | 通过消息总线实现松耦合 Agent 协作,支持实时事件驱动 |
| 持久化工作流 | 结合确定性过程与 LLM 决策,编排复杂的多步 Agent 工作流 |
| 状态管理 | 灵活的 KV 存储,Agent 跨交互保留上下文,确保连续性 |
| Actor | 虚拟 Actor 模式,Agent 作为自包含的有状态单元顺序处理消息 |
供应商中立 & 开源
作为 CNCF 孵化项目的一部分,Dapr Agents 完全供应商中立,消除了厂商锁定、知识产权风险或专有限制的顾虑。组织可以获得完全的灵活性和控制权,使用可审计、可贡献的开源软件构建 AI 应用。
核心机制:LLM 推理循环 → 确定性工作流
Dapr Durable Agents 的核心创新是将 Agent 的思考和行动生命周期完全托管给 Dapr Workflow,利用其事件溯源(Event Sourcing)和确定性重放(Deterministic Replay)机制。
容错恢复流程
- 每成功执行一个 Activity,结果写入底层 Workflow Actor 的历史日志
- 崩溃后,编排器从头"重放"
- 重放时不重复消耗 Token,也不重复调用工具——前序 LLM 决策和工具结果直接从日志中读取
- Agent 精准回到崩溃前的那一步继续执行
推理步骤的 Activity 化与容错重放
在 DurableAgent 中,LLM 的每一次提示词生成(Prompt Generation)、每一次大模型推断(LLM Inference)、以及每一次工具调用(Tool Invocation),底层的执行逻辑都会被 Dapr 封装成一个 Dapr Workflow Activity。
- 当 Agent 调用 LLM 决定执行
Tool_A成功后,这个结果会被写入底层隐藏的 Workflow Actor 历史日志中。 - 如果在执行下一步
Tool_B时服务器宕机,Dapr 重新拉起该 Agent 实例后,Agent 的编排器会从头"重放"。 - 重放时,前一步的 LLM 决策和
Tool_A的执行结果会直接从历史日志中读取(不重复消耗 Token,也不重复调用工具),从而让 Agent 神奇地直接回到宕机前的那一步继续往下走。
架构能力
虚拟 Actor 架构
每个 Agent 会话对应一个 Dapr Virtual Actor 实例:
关键能力
- 耐久性与容错:保证任务面对网络抖动、Pod 漂移或节点崩溃时,必定执行到终点
- 透明持久化记忆:短期记忆(上下文窗口)和长期记忆自动托管在 Dapr State Store,无需关心底层数据库配置
- 内置定时与挂起:支持
await timer(2_days)语法,Agent 释放内存,到期精准唤醒;人工介入场景下触发WaitForExternalEvent - 原生 Multi-Agent 编排:开箱支持任务链(Task Chaining)、扇入/扇出(Fan-out/Fan-in)、评审流(Evaluator-Optimizer)
详细实现机制
Dapr Durable Agents 能够实现云原生级的耐久性、长周期挂起与分布式扩展,其底层依赖于 Dapr 运行时的四大核心机制协同:
确定性工作流引擎 (DTFx Replay Engine)
Dapr Durable Agents 将 Agent 的思考-行动循环(ReAct Loop)映射为 Dapr Workflow 编排函数,并将每次 LLM 推理与 Tool 工具调用封装为 Durable Activity:
- Event Sourcing 存储:每次成功调用 Tool 或获取 LLM 响应后,Dapr 运行时会将输入、输出及执行状态作为一个 Task Event 追加写入底层的事件日志表(Event History)。
- 确定性重放 (Deterministic Replay):若执行进程在某步(如 Tool B 执行中)崩溃重启,Workflow 编排器会从头重新运行代码。当重新执行到之前的步骤时,Replay 引擎拦截调用,直接从事件日志中返回已保存的结果,而不会重新发起 LLM 请求或二次触发外部 Tool。
- Token 零浪费:这意味着因网络抖动或容器漂移导致的恢复,绝不会产生额外的 LLM Token 费用与边际调用开销。
虚拟 Actor 封装与状态水合
每一个 Agent 会话(或多租户 Agent 实例)在 Dapr 中均被映射为一个独立的 Virtual Actor:
- 单线程消息处理 (Single-threaded Execution):虚拟 Actor 内部天然保证消息排队与顺序执行,彻底消除了并发竞争对 Agent 上下文窗口和记忆状态的破坏。
- Placement 动态路由与 Scale-To-Zero:Placement Service 负责在集群各节点间动态路由与调度 Actor。当 Agent 闲置时,Dapr 自动将其从内存解绑(Deactivate),但其状态完整保留于 Redis/CosmosDB/PostgreSQL 等后端存储。
- 毫秒级状态水合 (Hydration):当新的事件或用户 Prompt 到达时,Placement 服务就近唤醒/重建 Actor 实例,并透明拉取持久化上下文完成水合(Hydration)。
Sidecar 层 Conversation API (Dapr 1.17+)
Dapr Durable Agents 不直接在 SDK 内部侵入式绑定特定的大模型 SDK,而是统一接入 Dapr 1.17+ 推出的 Conversation API:
- 统一模型抽象:Agent 代码通过 Dapr Sidecar 统一接口发起对话交互,透明适配 OpenAI、Anthropic、Gemini、DeepSeek 及本地 Ollama。
- Sidecar 级运维管控:密钥轮转(Key Rotation)、速率限制(Rate-Limiting)、熔断重试(Circuit Breaking)以及 OpenTelemetry 分布式追踪全部下沉至 Dapr Sidecar 处理,Agent 业务逻辑与平台基础设施完全解耦。
挂起、定时唤醒与人工介入 (Long-Running & HITT)
针对长周期 Agent 流程(如等待人工审批、定时轮询任务):
- 外部事件挂起 (
WaitForExternalEvent):Agent 可以调用挂起方法暂停执行。此时 Agent 不占用任何 CPU/内存资源,底层状态转存,等待外部 Webhook 或 Pub/Sub 事件唤醒。 - 持久化定时器 (
Durable Timers):支持跨节点持续的定时器机制(如timer(7_days)),定时器到期时精确唤醒关联的 Durable Agent 继续运行下一个 ReAct 步骤。
基础设施要求
| 组件 | 要求 | 作用 |
|---|---|---|
state.* | 支持 Transactions API,actorStateStore: "true" | 持久化 Agent 状态与记忆 |
conversation.* | Dapr 1.17+ Conversation API | 统一 LLM 提供商抽象(OpenAI、Gemini、DeepSeek),速率限制与密钥轮转 |
pubsub.* | 事件驱动消息总线 | Agent 间异步通信,触发条件传递 |
关键特性
- 规模与效率:单核可高效运行数千个 Agent。Dapr 透明地将单 Agent 和多 Agent 应用分布到机器集群,并管理其生命周期
- 工作流韧性:自动重试 Agent 工作流,确保任务完成
- Kubernetes 原生:在 K8s 环境中轻松部署和管理 Agent
- 数据驱动 Agent:通过连接数十种数据源,直接与数据库、文档和非结构化数据集成
- 多 Agent 系统:默认安全且可观测,支持 Agent 间协作
- 供应商中立 & 开源:避免厂商锁定,跨云和本地部署灵活选择
- 平台就绪:访问范围和声明式资源使平台团队能够将 Dapr Agents 集成到其系统中
代码示例
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 框架形成了互补协作:
- Dapr(宏观外壳):分布式状态管理、节点通信、崩溃恢复、服务发现、跨 Agent Pub/Sub
- Eino(微观推理):类型安全的 DAG 推理图编排、Prompt 链组装、Tool Call 路由、反思循环
- 平滑降级:在无 Dapr 运行时的环境下(单机/边缘设备),可抛弃 Dapr 外壳,依靠 Eino 本地退化运行(降级为 Go Channels 和 MemoryStore)
总结
- 微服务维度的 Dapr: 改变了微服务的开发范式。它通过 Sidecar 架构 将分布式能力变成了一种公共基础设施,让开发者可以编写云原生、跨语言、平台无关的轻量级微服务,极大降低了分布式系统的开发和运维门槛。
- AI Agent 维度的 Dapr: Dapr Durable Agents 并不是在挑战大模型本身的推理算法,而是在重构大模型应用的分布式运行时。 它将复杂的 AI 智能体应用落地带入了"工业化时代":让开发者能够像写普通的本地循环代码一样写 Agent 逻辑,而把高可用、强一致性状态、长周期挂起以及多智能体分布式通信等所有的"脏活累活",全部交给了底层的 Dapr 运行时。
- 生态协作: 在更复杂的多 Agent 场景中,Dapr 负责宏观分布式外壳(状态、通信、崩溃恢复),Eino 负责微观推理编排(DAG 图、Prompt 链、Tool 路由),二者互补并可平滑降级。