Apache Burr：构建可靠的 AI 代理与应用

原文 ↗ Hacker News 讨论 ↗

项目目的、起源与命名

  • Burr 是一个由 Apache 孵化的、通过状态机来编排 AI 代理的框架。
  • 它源自更早的 Hamilton（一个基于 DAG 的库）工作，作为一种在 DAG 执行之间管理状态的方法，尤其适用于需要循环/递归的场景。
  • 它刻意保持低层级，并采用“自带函数/类”的方式，目标是提供不预设立场的编排能力，而不是完整的代理栈。

与其他框架的定位对比

  • 相比 dspy.ai：被描述为更低层级，不是直接竞争对手。
  • 相比 LangGraph：有些人认为 Burr 非常相似，“就是带有 builder pattern 的 LangGraph”。
  • 相比 Strands / AgentCore：这些被认为更有立场，并且绑定特定云；如果 Burr 成熟起来，它可能会被视为一个替代方案。
  • 同一领域中提到的其他工具：Pi、NanoBot、Nvidia Openshell、Codex、OpenClaw、Jido、Forge；Burr 被看作这个拥挤市场中的又一个参与者。

框架 vs 手写代理

  • 目前很强的一种观点是，简单代理完全可以直接编写（循环 + 工具 + 上下文 + 解析），而定制代码往往更清晰、也更易维护。
  • 反驳观点认为：重新发明工具 schema、序列化和 harness 逻辑等基础原语是浪费；使用 harness 类似于使用 API 客户端，而不是重新实现协议。
  • 共识是，框架的真正价值不在基础代理循环，而在于：
    • 可观测性/追踪
    • 约束与策略
    • 监控、部署、版本管理、评估、A/B 测试。

可靠性、编排与上下文

  • 有人认为“可靠”的代理主要取决于拆解、编排和上下文管理，而不只是状态机。
  • 也有人怀疑是否真的存在完全“可靠的 AI”，或者 Burr 的方法是否真的能解决这个问题。
  • 多个帖子强调：
    • 带有分类器、工具、审批和递归的多步骤工作流会迅速变得复杂。
    • 上下文管理、长期记忆以及“脑子”（例如文件用途摘要、爆炸半径分析）是可扩展代理的关键。
    • 代理群体和规格驱动开发被提出为独立的可靠性策略。

UI、社区与观感

  • 许多人批评落地页是“vibe-coded”/表演式 UI：渐变、动画按钮、Tailwind 风格模板、JavaScript 过重。
  • 有些人觉得这种审美以及以 Discord 为中心的社区让项目看起来仓促，或者对 Apache 来说不够严肃。
  • 也有人指出该网站是用户贡献的，不代表核心技术质量。

提出的开放问题

  • Burr 如何处理代理认证以及像 MCP 这样的协议，从文档里看并不清楚。
  • 关于与 Pydantic 的比较以及详细的安全/认证模式的问题，在讨论串中没有得到回答。