Dapr Agents v1.0 GA — 让 AI Agent 在 Kubernetes 上永不宕机的方法

昨天在 KubeCon Europe 2026 阿姆斯特丹，Dapr Agents v1.0 GA 正式发布了。

说实话，刚听到消息的时候我的第一反应是”又一个 Agent 框架？“。LangGraph、CrewAI、AutoGen、OpenClaw…… 现在数 Agent 框架有多少个本身就毫无意义了。但仔细研究 Dapr Agents 的发布内容后，我发现这个东西的方向不太一样。它关注的不是 Agent 的”智能”，而是”存活”。 核心卖点是：即使进程被 kill、节点重启、网络中断，Agent 也能接着干之前没干完的活儿。

为什么又要搞一个新框架

大多数 Agent 框架都聚焦在 LLM 调用逻辑上。Prompt chaining、工具调用、多 Agent 对话 —— 全都是在回答”Agent 该做什么”这个问题。但如果你真的在生产环境跑过 Agent，大概率遇到过这些情况：

• LLM API 调用中途超时，整个 workflow 直接挂掉
• Agent 三步任务跑到第二步，Pod 重启了，只能从头来过
• 同时跑 10 个 Agent，内存直接爆掉

Dapr Agents 用 Dapr 运行时的基础设施构建块来解决这些问题。CNCF 项目 Dapr（GitHub 34K+ stars）早已在微服务领域验证过的分布式系统模式 —— state management、pub/sub、service invocation —— 直接搬到了 Agent 上。

核心：Durable Agent 是什么

最引人注目的是 DurableAgent 类。和普通 Agent 有什么区别？所有 LLM 调用和工具执行都会作为检查点持久化保存。即使在 workflow 执行过程中 kill 掉进程，重启后也会从最后一个保存点继续执行。

from dapr_agents import DurableAgent
from dapr_agents.workflow.runners import AgentRunner

weather_agent = DurableAgent(
    name="WeatherAgent",
    role="Weather Assistant",
    instructions=["Help users with weather information"],
    tools=[get_weather],
    llm=DaprChatClient(component_name="llm-provider"),
)

runner = AgentRunner()
runner.serve(weather_agent, port=8001)

用 Dapr CLI 启动：

dapr run --app-id weather-agent --app-port 8001 \
  --resources-path ./components -- python agent.py

底层基于 Dapr 的 Virtual Actor 模型运行。每个 Agent 表示为一个 Actor，Actor 是线程安全的，并且在分布式环境中自动放置。你可以在单台机器上跑数千个 Agent，也可以分散到 Kubernetes 集群上。

我觉得这个思路相当合理。与其让 Agent 框架自己重新发明分布式系统，不如直接站在已经验证过的基础设施上。LangGraph 在实现自定义 checkpointing，CrewAI 在搞自己的内存系统，而 Dapr Agents 不管你用 Redis、PostgreSQL 还是 DynamoDB —— 直接对接已有的 30 多种数据库作为状态存储，即插即用。

Scale-to-Zero 与性能

Virtual Actor 模型最有吸引力的部分是 scale-to-zero。Agent 空闲时会从内存中卸载，但状态会保留。再次调用时几毫秒内就能激活。根据 Diagrid 的 benchmark 数据，Actor activation latency tp90 约 3ms，tp99 约 6.2ms。

传统框架要让 100 个 Agent 常驻待命，内存占用非常可观。而 Dapr Agents 只在有请求时激活，完事就释放。像 serverless 函数一样运行，但又不会丢失状态。

那框架该怎么选

	Dapr Agents	LangGraph	CrewAI
核心优势	基础设施级耐久性	复杂 workflow 图编排	基于角色的团队协作
故障恢复	自动（durable workflow）	手动 checkpointing	有限
Kubernetes	原生支持（sidecar）	需额外配置	需额外配置
弹性伸缩	Scale-to-zero，自动	手动	手动
状态管理	30+ 数据库插件	内存/自定义	内存
学习曲线	中等（需要 Dapr 知识）	较高（图论基础）	较低
语言支持	仅 Python	Python	Python

说实话，Dapr Agents 不是万能药。

只支持 Python。 都 v1.0 了，C# 和 Java SDK 还没出。企业里跑 JVM 体系的团队，短期内很难用上。GitHub star 也就 630 左右，社区还很小。和 LangGraph、CrewAI 的生态比起来，插件和示例都少得多。

而且依赖 Dapr 运行时本身就是双刃剑。如果团队已经在用 Dapr，把 Agent 无缝接入现有基础设施自然是顺理成章。但如果团队没接触过 Dapr，光是为了跑一个 Agent 就得学 sidecar 架构、组件 YAML 配置、Dapr CLI…… 完全可能出现”Agent 逻辑 10 行 + 基础设施配置 100 行”的局面。

我的判断

我认为 Dapr Agents 在”Agent 框架大战”中占据了一个独特的位置。大部分框架都在追求”更聪明的 Agent”，而 Dapr Agents 专注于”不会挂掉的 Agent”。如果你真的在生产环境运营过 Agent，你会理解这个方向的价值。

ZEISS 在 KubeCon 主题演讲中展示了用 Dapr Agents 实现光学参数文档提取的案例，也令人印象深刻。这充分说明了在业务关键型工作负载中，Agent 的”不宕机”有多重要。

不过如果现阶段考虑引入的话，有两个前提条件。第一，团队得已经在跑 Kubernetes。第二，Agent 的场景不是”跑一次就完事”，而是需要长时间运行的 durable workflow。如果只是简单的 RAG pipeline 或一次性工具调用，LangGraph 或 CrewAI 要轻量得多。

CNCF 官方背书，加上构建在 Dapr 这个经过验证的运行时之上 —— 我认为这两点会成为 Dapr Agents 长期最大的竞争力。Agent 框架遍地开花，但 cloud-native Agent 运行时，目前只有这一个。