Dapr Agents:用于构建可扩展、可靠AI智能体的框架

Dapr Agents是一个利用Dapr构建可扩展AI智能体的框架,支持工作流、多智能体协作和事件驱动执行,关注可靠性和可观测性。

原文标题:Dapr Agents 发布:支持规模化 AI 工作流、多智能体协作

原文作者:AI前线

冷月清谈:

Dapr Agents 是一个基于 Dapr 构建的框架,旨在简化可扩展、可靠的 AI 智能体的开发。它支持结构化的工作流、多智能体协调和基于事件驱动的执行能力,并充分利用了 Dapr 的安全性、可观测性和云原生架构。Dapr Agents 专为企业级应用设计,能够支持数千个智能体,并无缝集成数据库。通过借鉴 Dapr 成熟的工作流引擎,Dapr Agents 具备出色的故障处理、重试和扩展能力,开发者可以专注于智能体的推理、行动和协作逻辑,而无需担心底层基础设施的复杂性。此外,Dapr Agents 还支持通过发布/订阅消息传递实现多智能体之间的协作,并提供了内置的监控和可观测性功能,方便开发者调试和排查问题。作为一个 CNCF 项目,Dapr Agents 避免了厂商锁定,确保了安全通信和容错能力。

怜星夜思:

1、文章提到Dapr Agents旨在单个核心上运行数千个智能体,这个特性在实际应用中会带来哪些优势?又会对硬件资源提出什么要求?
2、Dapr Agents 使用 Dapr 的发布/订阅消息传递进行多智能体协作,这种方式相比传统的消息队列有什么优缺点?在哪些场景下更适用?
3、文章提到Dapr Agents可以抽象与数据库和消息智能体的集成,这对于开发者来说意味着什么?在实际开发中,如何利用这个特性来提升开发效率?

原文内容

作者 | Eran Stiller
译者 | 明知山
策划 | 丁晓昀

Dapr 最近推出了 Dapr Agents,一个利用大语言模型构建可扩展、可靠的 AI 智能体的框架。它支持结构化的工作流、多智能体协调和基于事件驱动的执行能力,并利用了 Dapr 的安全性、可观测性和云中立架构。Dapr Agents 专为企业使用而设计,支持数千个智能体,可与数据库集成,并通过强大的编排和消息传递确保可靠性。

Dapr Agents 基于 Dapr 提供了一个框架,用于开发能够利用 LLM 进行推理、行动和协作的 AI 智能体。它提供了可靠性、可扩展性和可观测性,支持在单个核心上运行数千个智能体,并且原生支持在 Kubernetes 上运行。作者 Mark Fussell、Yaron Schneider 和 Roberto Rodriguez 描述了 Dapr Agents 与其他框架的不同之处:

Dapr Agents 基于 Dapr 的完整工作流引擎。许多其他智能体和 LLM 框架使用的是自建的工作流系统,这些系统在生产环境中往往不够可靠。Dapr Agents 使用经过验证的 Dapr 工作流系统,该系统具备很好的处理故障、重试和扩展问题的能力。

import logging
import asyncio
import requests
from dotenv import load_dotenv
from dapr_agents.llm.dapr import DaprChatClient
from dapr_agents import AssistantAgent, tool
# Load environment variables
load_dotenv()
logging.basicConfig(level=logging.INFO)
@tool
def get_pr_code(repository: str, pr: str) -> str:
   """Get the code for a given PR"""
 response = requests.get(f"https://api.github.com/repos/{repository}/pulls/{pr}/files")
   files = response.json()
   code = {file["filename"]: requests.get(file["raw_url"]).text for file in files}
   return code
@tool
def perform_review(code: str) -> str:
   """Review code"""
   response = DaprChatClient().generate(f"Review the following code: {code}")
   return response.get_content()
# Define Code Review Agent
code_review_agent = AssistantAgent(
  name="CodeReviewAgent",
  role="Review PRs",
  instructions=["Review code in a pull request, then return comments and/or suggestions"],
  tools=[get_pr_code, perform_review],
  message_bus_name="messagepubsub",
  state_store_name="workflowstatestore",
  agents_registry_store_name="agentstatestore",
  service_port=8001,
)
# Start Agent Workflow Service
await code_review_agent.start()

使用 Dapr Agent 构建代码评审智能体的示例(来源)

Distributed Application Runtime (Dapr) 是一个开源框架,通过提供服务调用、状态管理、发布 / 订阅消息传递和可观测性等构建块来简化云原生应用程序的开发。它抽象了基础设施的复杂性,让开发人员能够专注于业务逻辑,并能够无缝地集成到 Kubernetes 和其他环境中。

Agentic AI 指的是那些能够自主处理信息、做出决策并执行任务的 AI 的驱动系统。在这一领域有多种解决方案,包括 LangChain、AutoGen 和 CrewAI 等框架,它们为开发人员提供了构建基于智能体的应用程序的能力。

Dapr Agents 利用大语言模型作为其推理引擎,并与外部工具集成来增强功能。开发者可以创建具备预定义角色、目标和指令的智能体,赋予它们推理能力以及基于工具的行动能力。他们还可以利用包含 LLM 推理的函数来定义结构化、确定性的工作流。这些工作流确保任务按照预设的顺序执行,同时通过工具集成保持了灵活性。


智能体工作流示例(来源)

Dapr Agents 支持多智能体工作流,智能体可以通过 Dapr 的发布 / 订阅消息传递进行协作。协调模型包括基于 LLM 的决策制定、随机选择和轮询任务分配,实现自适应、自我推理的工作流。作者进一步阐述了这一点:

智能体需要作为自主的实体来运行,能够动态响应事件,从而实现与工作流的实时交互和协作。这些事件驱动的智能体工作流利用了 Dapr 的发布 / 订阅消息传递系统,使得智能体能够通过消息智能体进行通信、共享任务,并根据环境触发的事件进行推理。

智能体可以通过消息智能体与其他智能体通信(来源)

该设计抽象了与数据库和消息智能体的集成,让开发人员能够在不进行重大代码更改的情况下切换基础设施供应商。它与 Prometheus 和 OpenTelemetry 等监控工具无缝集成,实现了可观测性。作为 CNCF 项目,它避免了供应商锁定,同时确保了安全通信和容错能力。

开发人员可以通过 GitHub 代码库探索 Dapr Agents 的功能,并加入 Discord 社区进行讨论和获取支持。

InfoQ 与 Diagrid 的 CTO 和 Dapr 维护者 Yaron Schneider 就 Dapr Agents、其实现和未来计划进行了交流。

InfoQ:你提到 Dapr Agents 的设计目标是能够在单个核心上运行数千个智能体。那么是哪些优化措施或架构决策实现了这个目标?在 Kubernetes 环境中,架构师应该如何考虑扩展性问题?

Yaron Schneider:Dapr Agents 将智能体及其后续任务视为 Actor ——这些轻量级且持久的对象可以扩展到数百万个,具有非常低的延迟。这使得 Dapr Agents 能够在消耗极低 CPU 和内存的情况下运行大量智能体。由于 Dapr 可以原生集成到 Kubernetes 中,Dapr Agents 对故障具有高度弹性,并考虑到了 Kubernetes Pod 的瞬态特性。

InfoQ:在分布式 AI 智能体异步交互时,调试和可观测性变得至关重要。Dapr Agents 为监控、日志记录和排查智能体行为提供了哪些内置功能?

Schneider:基于 Dapr 构建的 Dapr Agents 为其智能体工作流提供了指标数据,包括每秒请求数、错误率和延迟。此外,由于 Dapr 工作流支持分布式跟踪,开发人员可以使用 OTel 兼容工具来可视化智能体调用图。我们将在未来更多地在智能体可观测性方面进行投入。

InfoQ:Dapr Agents 接下来有什么计划?是否计划增加新功能或做出改进,例如增强的 LLM 集成、新的工作流原语或扩展多云功能?

Schneider:鉴于数据合成在智能体工作负载中的重要性日益增加,我们计划集成模型上下文协议(MCP),让开发人员能够通过状态存储和绑定 API 将 Dapr Agents 连接到各种数据源和 Dapr 的原生功能。此外,我们还计划通过 Dapr 的对话 API 增加对更多 LLM 供应商的支持。最重要的是,Dapr Agents 目前已经支持 Python,我们正在努力增加对 Dotnet 和 Java 的支持。

查看英文原文

https://www.infoq.com/news/2025/03/dapr-agents/

 会议推荐

AICon 2025 强势来袭,5 月上海站、6 月北京站,双城联动,全览 AI 技术前沿和行业落地。大会聚焦技术与应用深度融合,汇聚 AI Agent、多模态、场景应用、大模型架构创新、智能数据基建、AI 产品设计和出海策略等话题。即刻扫码购票,一同探索 AI 应用边界!


今日荐文

图片
你也「在看」吗?👇

从技术角度看,Dapr Agents 这种高密度的智能体部署方式,可以大幅降低基础设施的成本,并提高资源利用率。想象一下,如果每个智能体都需要独立的虚拟机或容器,那资源消耗将十分惊人。但是,这种架构也对底层的资源调度和隔离提出了更高的要求。我们需要仔细评估 CPU 核心的性能、内存容量、网络带宽等因素,以确保每个智能体都能获得足够的资源,避免出现性能瓶颈。同时,需要关注智能体之间的资源竞争问题,例如内存泄漏、CPU 占用过高等情况,这些都可能导致整个系统的稳定性下降。因此,我们需要采取一些优化措施,例如使用轻量级的容器技术、优化智能体的资源占用、以及实施有效的资源监控和告警机制。理论上来说,现代多核CPU加上高速SSD,再配合Kubernetes的弹性伸缩,应该可以满足大部分场景的需求。大家可以分享一下你们在高密度部署方面的经验和挑战。

Dapr 的发布/订阅机制挺有意思的,感觉比传统的消息队列更灵活。优点是松耦合,智能体之间不需要知道彼此的存在,通过 topic 就能通信。缺点嘛,可能就是消息的可靠性不如传统消息队列那么强。 大家觉得在什么场景下 Dapr 的发布/订阅更香呢?我先抛个砖,感觉在智能体数量多、消息类型多变的情况下会更有优势,因为省去了大量的队列配置工作。

我感觉这个特性最直接的优势就是降低了单位智能体的部署和运维成本。以前要跑很多智能体得开很多虚拟机或者容器,现在可以把它们塞到一个核心里,省钱啊!但是,这种高密度部署也意味着风险集中。一旦这个核心出了问题,所有的智能体都会受到影响。所以,可靠性就变得非常重要。另外,资源竞争也是个问题。如果这些智能体都在抢 CPU、内存,那性能肯定会下降。可能需要通过一些资源隔离的技术,比如 cgroups,来限制每个智能体的资源使用。至于硬件要求,我觉得除了 CPU 和内存要足够强劲之外,网络也很关键。毕竟这么多智能体要进行通信,网络带宽必须跟得上。总的来说,这个特性很有潜力,但要用好也需要仔细考虑。

发布/订阅模式和传统消息队列各有千秋。Dapr 的发布/订阅胜在简单易用、解耦性好,适合智能体数量多、关系复杂的场景。想想看,如果每个智能体都要和 N 个其他智能体直接通信,那连接关系得有多复杂!而发布/订阅模式就像一个广播系统,每个智能体只管发布或订阅,不需要维护复杂的连接关系。但是,传统消息队列在消息可靠性、顺序性方面更有优势。如果你的智能体应用对数据一致性要求很高,比如金融交易,那还是得选择传统消息队列。所以,选择哪种方式,关键还是看你的应用场景。

这种抽象能力,我理解的核心是“解耦”和“可移植性”。解耦是指我们的代码不再直接依赖于特定的数据库或消息中间件,而是通过 Dapr Agents 提供的统一接口进行交互。这样,如果我们需要更换数据库,或者升级消息中间件,只需要修改 Dapr Agents 的配置,而不需要修改大量的业务代码。可移植性是指我们的应用可以在不同的云平台或基础设施上运行,而不需要进行大量的适配工作。因为 Dapr Agents 已经帮我们屏蔽了底层基础设施的差异。在实际开发中,我们可以利用这个特性来快速构建原型,并进行灵活的迭代。例如,我们可以在开发阶段使用简单的内存数据库,而在生产环境中使用更强大的关系型数据库。我们也可以根据业务需求,选择不同的消息中间件,例如 RabbitMQ、Kafka 等等。总之,这种抽象能力可以大大提高我们的开发效率,并降低维护成本。

抽象数据库和消息中间件的集成,这简直是开发者的福音啊!这意味着我们可以更专注于业务逻辑,而不用把精力花在对接各种不同的数据库和消息队列上。 举个例子,如果我们要把智能体的状态保存到数据库里,以前可能需要写一堆代码来处理数据库连接、SQL 语句等等。现在有了 Dapr Agents,只需要配置一下,就能自动把状态保存到数据库里了。大家还有什么其他的想法吗?

从架构设计的角度来看,Dapr 的发布/订阅模式提供了一种更轻量级、更灵活的智能体间通信方式。传统的MQ,比如RabbitMQ、Kafka,虽然提供了强大的消息保障机制,但同时也引入了额外的复杂性,例如需要预先定义队列、交换机等,并维护其高可用性。而Dapr的发布/订阅,更多的是关注事件的广播和消费,智能体只需要关心topic,而不需要关心其他智能体的存在,这降低了智能体之间的耦合度,使得系统更易于扩展和维护。但是,这种模式的缺点是消息的可靠性可能不如传统MQ那么高,可能会出现消息丢失的情况。因此,在需要强一致性的场景下,可能还是需要选择传统的MQ。个人认为,Dapr的发布/订阅更适合那些对实时性要求高、但对消息可靠性要求相对较低的场景,例如实时监控、事件通知等。此外,Dapr的抽象能力也使得我们可以更容易地切换不同的消息中间件,而不需要修改大量的代码。

我觉得这个特性最大的好处是让我们不用被特定的技术栈绑定。以前选定了某个数据库或消息队列,就很难再换了,因为迁移成本太高。有了 Dapr Agents,我们可以随时根据需求更换底层的基础设施,而不需要修改大量的代码。这对于长期维护和演进的系统来说非常重要。另外,这种抽象也降低了学习成本。开发者只需要学习 Dapr Agents 的 API,而不需要了解各种数据库和消息队列的细节。这可以让他们更快地上手,并提高开发效率。当然,这种抽象也有一定的代价,比如可能会降低一些性能。但是,我认为在大多数情况下,这种trade-off是值得的。

这个问题很有意思!Dapr Agents 支持单个核心运行数千智能体,这意味着更高的资源利用率和更低的运营成本。例如,在智能客服场景中,我们可以用更少的服务器运行更多的客服机器人。不过,这也意味着我们需要更强大的 CPU、更大的内存以及更快的存储,毕竟数量上去了,单个核心的压力也会增大。大家觉得什么样的硬件配置才能更好地支持呢?欢迎讨论!