目录

Dapr Agents

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 框架存在致命的“落地难”问题：

核心实现机制：将 LLM 推理循环转化为“确定性工作流”

在前文中我们提到，Dapr Workflow 利用事件溯源（Event Sourcing）和确定性重放（Deterministic Replay）实现了微服务工作流的不死之身。Dapr Durable Agents 的核心精髓，就是把 Agent 的思考和行动生命周期，完全托管给了 Dapr Workflow。

推理步骤的“Activity 化”

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

状态的“容错重放”

核心架构能力

通过延伸 DurableAgent，Dapr 赋予了 AI Agent 极强的云原生属性：

代码范式与直观感受

在 Dapr Agents 框架中，一个具备耐久性的 Agent 开发通常非常符合直观。以下是一个概念性的伪代码片段：

from dapr.agents import Agent, DurableAgent, Tool

# 定义 Agent 的工具（底层的 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]
        )

# 触发 Agent（底层会自动启动 Dapr Workflow 进行编排托管）
agent = SREAgent()
result = agent.execute("帮我分析本地集群中网关组件的错误并给出修复建议")

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

总结