Apache Burr 发布：AI Agent 构建框架的开源新势力

阅读本文后，你将收获：理解 Apache Burr 的设计理念和核心架构——它如何为 AI Agent 开发提供标准化的构建方式；掌握 Burr 与 LangGraph、CrewAI 等主流 Agent 框架的全面对比；了解 Apache 基金会推出 AI Agent 框架的行业意义；获得对 2026 年 Agent 框架竞争格局的独立分析和选型建议。

💡 建议前置阅读：如果你对 AI Agent 框架的生态还不熟悉，建议先阅读本站 agent-007「Agent 框架对比」 和刚刚发布的 agent-074「LangGraph 2026 深度指南」。

2026 年 5 月，Burr 以 Apache 孵化项目身份发布了 v0.42.0-incubating。Burr 最初由 DAGWorks 团队开发，后贡献给 Apache 基金会孵化，标志着开源社区对 Agent 技术战略地位的认可。

Burr 的诞生背景值得深究：2025-2026 年，AI Agent 框架生态出现了「碎片化」问题——LangGraph、CrewAI、AutoGen、LlamaIndex Workflows 等框架各有不同的设计哲学和 API 风格，开发者在选择框架时面临「锁定风险」。Burr 的目标是提供一个状态驱动的、可观测的 Agent 构建框架——开发者用 Step（步骤）定义 Agent 的逻辑，每个步骤声明它读取和写入哪些 State 字段，Burr 负责追踪、持久化和可视化整个执行过程。

Burr 的核心理念是「状态驱动的执行图」：Agent 的工作流被建模为一系列步骤，每个步骤通过 @action 装饰器声明 reads（读取哪些状态字段）和 writes（写入哪些状态字段）。与 LangGraph 的 StateGraph 相比，Burr 更强调可观测性（Observability）和可调试性（Debuggability）——每一步的输入输出都被记录，支持完整的执行回放。

Burr 的关键设计特征：（1）显式状态声明——每个步骤明确声明它读取和写入哪些 State 字段，使得依赖关系一目了然；（2）不可变 State——每个步骤执行后返回新的 State，而不是修改原有 State，便于追踪和回放；（3）生命周期钩子（Lifecycle）——通过 LifecycleAdapter 可以在步骤执行前后注入自定义逻辑（如日志记录、监控、持久化）；（4）内建 UI——Burr 提供 Web UI 来可视化执行流程、查看中间状态、回放历史执行。

Burr 的设计灵感来自状态驱动的工作流模式。这种将复杂流程分解为可追踪、可回放的状态转换步骤的方法，在数据处理和分布式系统中已有广泛应用。Burr 将这一模式引入了 AI Agent 开发领域。

Apache 基金会的孵化为 Burr 带来了独特优势：（1）标准化治理——Burr 的设计和功能变更遵循 Apache 的开放治理流程，不受单一公司的控制。这意味着即使最初核心贡献者的战略方向发生变化，Burr 的方向仍然由社区共同决定；（2）企业级信任——Apache 的品牌为 Burr 提供了企业级合规和长期维护的保障。对于受监管行业（金融、医疗、政府），使用 Apache 项目比使用个人或单一公司维护的开源项目更容易通过合规审查；（3）长期维护承诺——Apache 的 PMC 机制确保项目即使核心贡献者离开也能持续维护。

Apache 治理的具体机制：Burr 由 Apache 的 PMC（项目管理委员会）管理，所有重大功能变更需要通过公开的设计讨论和投票流程。这意味着 Burr 的 API 变更不会像商业项目那样突然发生——所有的变更都需要经过充分的社区讨论和向后兼容性的评估。对于长期维护的企业项目来说，这种可预测性是极其重要的。

Burr 的架构由三个核心概念组成：Step（步骤）、State（状态）和 Action（动作）。理解这三个概念的关系是掌握 Burr 的第一步。

Step（步骤）是 Burr 的最小执行单元。每个步骤定义了三件事：（1）输入——步骤需要什么数据；（2）处理逻辑——步骤如何转换数据；（3）输出——步骤产出什么数据。步骤可以是任意 Python 可调用对象，但 Burr 提供了一组内置步骤类型：LLM 步骤（调用大语言模型）、工具步骤（调用外部工具或 API）、条件步骤（根据条件决定分支）、循环步骤（重复执行直到满足条件）。

State（状态）是步骤之间传递数据的容器。与 LangGraph 的 StateGraph 不同，Burr 的 State 是一个不可变的值对象——每个步骤执行后返回的是一个新的 State，而不是修改原有 State。这种不可变设计使得状态变更的追踪和回滚变得非常简单，特别适合需要审计和调试的生产场景。

Action（动作）是步骤的执行结果。当一个步骤执行完成后，它会产出一个 Action，Action 包含了执行结果（成功/失败）、输出的 State 更新、以及可选的元数据（如执行时间、Token 消耗等）。Burr 的 Action 系统使得 Agent 的执行过程可以被完整记录和回放——这对调试和合规审计至关重要。

执行引擎（Executor）是 Burr 的运行时。Burr 本身不执行步骤，而是由 Burr 的应用引擎（Application）来顺序执行步骤。根据 Burr 的实际代码库，它支持多种集成和持久化后端：（1）本地执行——在本地 Python 进程中顺序执行步骤，适合开发和测试；（2）Ray 集成——通过 Ray 实现分布式执行，适合大规模场景；（3）持久化器（Persisters）——支持 PostgreSQL、AsyncPG、MongoDB、Redis 等后端，实现状态的持久化和恢复。这种「状态可持久化 + 可回放」的设计是 Burr 最独特的架构特征。

状态持久化与可观测性的深远意义：Burr 的核心理念是可观测性——每一步的输入输出都被记录，支持完整的执行回放。这意味着你可以随时查看 Agent 在任何时间点的完整状态，回放到任意步骤重新执行，或者将执行日志用于调试和合规审计。这与 Web 开发中的 Redux DevTools 类似——你可以查看每一步的状态变化。

from burr.core import Application, State
from burr.core.action import action
from burr.lifecycle import LifecycleAdapter

# 定义步骤
@action(reads=[], writes=["research_results"])
def research_step(state: State) -> dict:
    """研究步骤：执行搜索并追加结果"""
    query = state.get("query", "")
    results = search_web(query)
    analyzed = [analyze_source(r) for r in results]
    return {"research_results": analyzed}

@action(reads=["research_results"], writes=["draft"])
def write_step(state: State) -> dict:
    """写作步骤：根据研究结果生成草稿"""
    findings = state["research_results"]
    draft = generate_draft(findings)
    return {"draft": draft}

@action(reads=["draft"], writes=["final_article", "approved"])
def review_step(state: State) -> dict:
    """审核步骤：检查文章质量"""
    draft = state["draft"]
    review_result = llm_review(draft)
    return {
        "final_article": review_result["article"],
        "approved": review_result["approved"]
    }

# 构建应用
app = Application(
    steps=[research_step, write_step, review_step],
    initial_state=State({"query": "2026 AI 趋势"}),
    lifecycle_adapters=[LoggingLifecycleAdapter()]
)

# 执行
final_state, result = app.run()

# Burr 持久化集成示例（PostgreSQL）
from burr.integrations.persister.postgresql import PostgreSQLPersister

# 定义 Burr 步骤图
app = Application(
    steps=[
        research_step,
        write_step,
        review_step,
        publish_step
    ],
    initial_state=State({"query": "最新 AI 进展"}),
    persistence=PostgreSQLPersister.from_values(
        connection_string="postgresql://user:pass@localhost/burr"
    )
)

# 执行并自动持久化状态
final_state, result = app.run()

# 之后可以从任何历史状态回放
# app.from_state(persistence.load(partition_key="my-app", sequence_id=3))

Burr 和 LangGraph 的关系是 2026 年 Agent 框架生态最值得关注的议题之一。表面上看，两者都在做「Agent 工作流编排」——但深入分析后你会发现，它们的设计哲学和适用场景有本质差异。

LangGraph 是「一体化」方案：它同时负责编排（定义图的节点和边）和执行（运行图、管理状态、处理检查点）。LangGraph 的优势在于深度集成——编排和执行之间的零摩擦，以及 LangChain 生态的无缝衔接。缺点是框架锁定——一旦你深度使用 LangGraph，迁移到其他框架的成本极高。

Burr 是「状态驱动 + 可观测」方案：它强调显式的状态声明和完整的执行可观测性。Burr 的优势在于可调试性和可回放性——每一步的输入输出都被记录，支持完整的执行回放和状态恢复。Burr 提供 PostgreSQL/MongoDB/Redis 等持久化器，以及内建的 Web UI 来可视化执行过程。

两者的关系是竞争而非互补：Burr 和 LangGraph 都是独立的 Agent 框架，各自有自己的执行引擎。Burr 没有 LangGraph 执行引擎或 CrewAI 执行引擎——它是独立的运行时。Burr README 中也将 LangGraph 列为竞争对手进行对比。

何时选择 Burr：（1）你需要强大的可观测性和状态回放能力；（2）你需要将 Agent 状态持久化到数据库（PostgreSQL/MongoDB/Redis）；（3）你的组织已经在使用 Ray 分布式计算或 Hamilton 数据处理；（4）你偏好 Apache 项目的开放治理。何时选择 LangGraph：（1）你已经在 LangChain 生态中；（2）你需要检查点、人类审批等深度集成能力；（3）你需要 LangSmith 的监控和调试工具。

Burr 的核心差异化优势在于它的可观测性和持久化能力——这是 LangGraph、CrewAI 等框架需要额外配置才能实现的功能。

内建持久化器（Persisters）：Burr 提供多种持久化后端，支持 Agent 状态的保存和恢复。官方支持的持久化器包括：（1）PostgreSQL（burr.integrations.persister.postgresql）——适合生产环境的关系型数据库存储；（2）AsyncPG——异步 PostgreSQL 驱动，适合高并发场景；（3）MongoDB/PyMongo——文档数据库，适合灵活的状态结构；（4）Redis——内存数据库，适合低延迟的状态读写。持久化使得 Agent 可以在崩溃后从上次保存的状态恢复，也支持跨会话的历史查询。

Ray 分布式执行：Burr 集成了 Ray（ray.py），可以将 Agent 的步骤分布到 Ray 集群上执行。这对于需要大规模并行处理的场景（如批量 Agent 评估、大规模模拟）非常有用。

Streamlit Web UI：Burr 提供了基于 Streamlit 的可视化界面，可以实时查看 Agent 的执行流程、中间状态、历史记录，甚至回放过去的执行。这是 Burr 可观测性能力的核心体现——开发者不需要自己搭建监控面板。

Hamilton 集成：Hamilton 是 DAGWorks 团队开发的数据转换框架。Burr 与 Hamilton 的集成使得数据预处理和后处理可以作为 Agent 管线的一部分无缝衔接。

Haystack 集成：Haystack 是流行的 RAG（检索增强生成）框架。Burr 与 Haystack 的集成使得 Agent 可以直接调用 Haystack 的检索和问答能力。

Bedrock 集成：Burr 集成了 AWS Bedrock，使得 Agent 可以直接调用 AWS 托管的大语言模型。

OpenTelemetry 集成：Burr 支持 OpenTelemetry 标准，可以将 Agent 的执行数据导出到任意的 OpenTelemetry 后端（如 Jaeger、Prometheus、Grafana），实现分布式追踪和监控。

Burr 没有的集成：值得注意的是，Burr 目前没有与 LangGraph、CrewAI、Airflow、Kafka、Spark、Superset、Flink 等框架的直接集成。Burr 的定位是独立的 Agent 框架，而非编排层或胶水层。如果你需要这些集成，需要自行开发适配代码。

我们用一个完整的实战案例来演示 Burr 的价值：构建一个数据驱动的研究 Agent，它从数据库获取数据，进行 AI 分析，生成报告，然后通过邮件发送给用户。这个场景涉及多个系统（数据库、AI 模型、邮件服务）的协调，正是 Burr 擅长的领域。

为什么这个场景适合 Burr：（1）需要从多个系统获取数据（数据库 + 缓存 + 外部 API），适合用多个 Step 分别处理；（2）需要条件分支（如果数据异常则触发告警 Agent），适合用 Burr 的条件步骤；（3）需要审计日志（记录每一步的执行结果），Burr 的 Action 系统天然支持；（4）Burr 的 PostgreSQL 持久化器可以自动保存每一步的状态，支持后续查询和回放。

工作流设计：（1）数据采集步骤：从 PostgreSQL 获取销售数据，从 Redis 获取缓存的指标，从外部 API 获取竞品信息；（2）数据分析步骤：调用 LLM 分析数据趋势，识别异常模式；（3）条件分支：如果检测到异常，触发告警步骤；（4）报告生成：根据分析结果生成结构化报告；（5）分发：通过邮件和 Slack 发送报告。

from burr.core import Application, State
from burr.core.action import action

# 步骤 1：数据采集
@action(reads=[], writes=["sales_data", "metrics", "competitor_data"])
def collect_data(state: State) -> dict:
    sales = query_postgresql("SELECT * FROM sales WHERE date >= '2026-06-01'")
    metrics = redis_cache.get("daily_metrics")
    competitor = fetch_competitor_api()
    return {"sales_data": sales, "metrics": metrics, "competitor_data": competitor}

# 步骤 2：AI 分析
@action(reads=["sales_data", "metrics"], writes=["analysis"])
def analyze_data(state: State) -> dict:
    prompt = f"""分析以下销售数据趋势：
    销售数据：{state['sales_data'][:100]}
    指标：{state['metrics']}
    请识别异常模式并给出建议。"""
    analysis = llm_call(prompt)
    return {"analysis": analysis}

# 步骤 3：条件判断
@action(reads=["analysis"], writes=["alert_triggered", "alert_details"])
def check_anomalies(state: State) -> dict:
    analysis = state["analysis"]
    if "异常" in analysis or "告警" in analysis:
        return {"alert_triggered": True, "alert_details": extract_alerts(analysis)}
    return {"alert_triggered": False, "alert_details": []}

# 步骤 4：报告生成
@action(reads=["sales_data", "analysis"], writes=["report"])
def generate_report(state: State) -> dict:
    report = format_report(
        sales_data=state["sales_data"],
        analysis=state["analysis"]
    )
    return {"report": report}

# 步骤 5：分发
@action(reads=["report", "alert_triggered"], writes=["sent"])
def distribute(state: State) -> dict:
    send_email(report=state["report"])
    if state["alert_triggered"]:
        send_slack_alert(state["alert_details"])
    return {"sent": True}

# 构建应用
app = Application(
    steps=[collect_data, analyze_data, check_anomalies, generate_report, distribute],
    initial_state=State({}),
    lifecycle_adapters=[AuditLogAdapter()]
)

Burr 以 Apache 孵化项目身份发布，给 2026 年 Agent 框架生态带来了新的变量。在此之前，LangGraph 是最成熟的通用 Agent 框架，CrewAI 和 AutoGen 在各自细分领域有优势。Burr 的入场带来了以下变化。

维度一：可观测性标杆。Burr 将「执行过程可追溯、可回放」作为核心设计理念，这在 Agent 框架中是比较少见的。LangGraph 的检查点功能侧重状态保存，而 Burr 的 Action 日志和持久化器提供了更完整的审计能力。对于需要合规审计的企业场景，这种设计有独特价值。

维度二：持久化能力。Burr 官方支持 PostgreSQL、MongoDB、Redis 等多种持久化后端，开箱即用。其他框架通常需要自行配置持久化方案。这是 Burr 在生产环境中的一个实用优势。

维度三：Apache 孵化保障。Apache 的治理流程为 Burr 提供了长期维护的承诺，即使最初的核心贡献者离开，项目的治理结构也能确保持续维护。这对于需要长期维护的企业项目是一个加分项。

格局预判：2026 下半年，我们预计看到以下趋势：（1）LangGraph 可能进一步强化其可观测性和调试能力，回应 Burr 的竞争；（2）企业用户开始评估 Burr 的可观测性和持久化能力，特别是有合规需求的行业；（3）Burr 作为孵化项目，其社区规模和文档成熟度仍需时间来追赶 LangGraph；（4）Apache 基金会可能有更多 AI 相关项目进入孵化。

Burr 以 Apache 孵化项目身份发布，是 2026 年 AI Agent 生态的重要事件。它带来了可观测性和持久化方面的创新。虽然 Burr 目前仍处于孵化阶段，但它的设计理念（状态驱动执行 + 完整可观测性 + 多种持久化后端）代表了 Agent 开发中常被忽视但至关重要的方向。

本站观点：Burr 是 LangGraph 的竞争者，不是补充者。两者都是独立的 Agent 框架，各自有自己的执行引擎和设计理念。对于 2026 年的 Agent 项目，应该根据具体需求评估各自的优劣势。

最终推荐：（1）需要可观测性和状态持久化 → Burr 的 Action 日志 + PostgreSQL/MongoDB 持久化器是亮点；（2）已有 LangChain 生态 → LangGraph 更实用，无缝衔接；（3）企业级合规需求 → Burr 的 Apache 孵化模式可能更容易通过审查；（4）需要快速原型 → LangGraph 的工具链更成熟，开发速度更快。

一个经常被忽视的视角：Agent 框架的选择不仅仅是一个技术决策，更是一个组织决策。框架的选择会影响团队的技能栈、代码审查标准、运维流程和合规策略。因此，在做框架选型时，除了评估技术能力，还需要评估组织适配度——你的团队是否愿意接受新的编程范式？你的合规团队是否认可 Apache 的治理模式？这些非技术因素往往比技术因素更能决定框架选择的成败。

要全面理解 Burr 的价值，需要将其放在 2026 年 Agent 生态的完整竞争格局中进行分析。我们将从五个关键维度对比 Burr 与主要竞争对手，帮助读者做出理性的技术选型决策。

维度一：学习曲线和上手速度。CrewAI 的学习曲线最平缓——它的角色驱动模型非常直观，开发者可以在 30 分钟内搭建一个多 Agent 协作系统。LangGraph 的学习曲线中等——需要理解图结构和 State Reducer 的概念，但官方文档和教程质量很高。Burr 的学习曲线相对较陡——需要理解 @action 装饰器、reads/writes 状态声明、持久化器配置等概念。对于有数据工程经验的开发者来说，Burr 的状态驱动模型并不陌生。

维度二：生产就绪度。LangGraph 是最成熟的生产级方案——它的检查点、人类审批、流式输出、LangSmith 监控等能力经过了大量生产环境的验证。Burr 的核心框架已经稳定（v0.42.0-incubating），持久化器和 Streamlit UI 都已可用，但作为孵化项目，其文档和社区支持仍在完善中。CrewAI 在简单多 Agent 场景下生产就绪，但在复杂工作流控制方面不如 LangGraph。

维度三：生态和集成。LangGraph 深度集成 LangChain 生态（LCEL、LangSmith、LangServe），这是它的最大优势。Burr 集成了 Ray（分布式执行）、Hamilton（数据转换）、Haystack（RAG）、Bedrock（AWS 模型）和 OpenTelemetry（可观测性）。CrewAI 的生态相对独立，但也支持常见的 LLM 提供商和工具。选择哪个框架，在很大程度上取决于你的团队已经在使用哪个生态。

维度四：长期维护保障。Apache 孵化流程为 Burr 提供了较强的长期维护保障——即使最初的核心贡献者离开项目，Apache 的治理机制也能确保项目的持续维护。LangGraph 的维护取决于 LangChain 公司的商业战略。CrewAI 的维护取决于其创始团队的投入——作为相对较小的项目，维护风险最高。

维度五：可观测性和调试能力。Burr 是唯一将「执行可观测性」作为核心设计目标的框架——它的 Action 日志、状态持久化、Streamlit UI 回放功能提供了完整的调试体验。LangGraph 有检查点功能但不提供内建 UI。CrewAI 没有内置的可观测性功能。

综合评估：如果你的项目需要快速上线且只需要一个框架，LangGraph 是最佳选择。如果你的项目需要强大的可观测性和状态持久化，Burr 是最佳选择。如果你的场景是简单的多 Agent 协作，CrewAI 可能更合适。