Apache Burr 把 agent 框架重押在状态机和可观测性上
Burr 进入 Apache 孵化器,用状态机、内置 telemetry 和可重放押注:agent 框架的胜负手正从能力转向可靠性。
概述
Apache Burr 进入 Apache 软件基金会孵化器,定位是「构建可靠的 AI agent 和应用」的 Python 框架。它的卖点不是更聪明的提示词,也不是更花哨的多 agent 编排,而是一套老派的工程概念:把应用建模成状态机,给每一步配上内置的可观测性界面,允许把状态持久化到磁盘或数据库,并支持事后重放过去的运行。这套组合在过去两年的 agent 框架热潮里一直被边缘化,如今被一个项目摆到了正中央。
这件事本身比 Burr 这个具体项目更值得看。当一个 agent 框架开始拿「状态可见、可调试、可恢复」当主打,而不是拿「能力更强」当主打,说明这一波框架竞争的重心正在迁移:从「谁能让 LLM 做更多事」转向「谁能让 LLM 做的事在生产环境里不出乱子还能查清楚」。这是一个市场从兴奋期走向落地期的信号。
发生了什么
Burr 官网把自己描述成纯 Python、「没有魔法」的框架:你用 @action 装饰器声明每个动作读哪些状态、写哪些状态,再用 ApplicationBuilder 把动作和动作之间的转移(transition)拼成一台状态机,最后 build() 出一个可运行的应用。没有领域专用语言,没有 YAML,只有 Python 函数和装饰器。官网列出的核心能力包括:简单的 Python API、内置可观测性(Burr UI 可以实时监控、调试、追踪每一步,看到状态如何变化)、持久化与状态管理(自动把状态存到磁盘、数据库或自定义后端,应用可以从中断处恢复)、人在回路(在任意步骤暂停等待人工输入)、分支与并行(并行跑动作、fan out / fan in、组合子应用构成复杂的有向无环图),以及测试与重放(重放历史运行、对单个动作做单元测试、校验状态转移)。
集成方面,官网强调「不锁定」,直接对接 OpenAI、Anthropic、LangChain、Hamilton、Streamlit、FastAPI、Haystack、Instructor、Pydantic、PostgreSQL 等已有工具,定位成编排层而非全家桶。值得一提的是名字:据作者在 Hacker News 上的说明,Burr 取自 Aaron Burr,那位在决斗中杀死 Alexander Hamilton 的美国第三任副总统;而 Hamilton 正是同一团队(DAGWorks)此前开源的另一个库。一个做有向无环图,一个做状态机,这层互文是团队自己埋的梗。名字是玩笑,但「DAG 之外还需要状态机」这个技术主张是认真的,也正是 Burr 区别于一众框架的立足点。
为何重要
过去两年的 agent 框架,卖点几乎都集中在「能力」一侧:更顺滑的提示链、更聪明的工具调用、更复杂的多 agent 协作。Burr 反其道而行,把赌注压在「可靠性与可运维」一侧。状态机让控制流变得显式且可检查,可观测性界面让你能看清每一步发生了什么,持久化让应用能从崩溃处续跑,重放让你能拿历史数据复现和测试。这不是更性感的功能集,但它是把演示原型变成生产系统时真正缺的那一块。
它之所以值得记一笔,是因为精确命中了从业者的痛点。在 Hacker News 那条讨论(167 赞)里,有人说了一句相当中肯的话:用「这就是写一个 agent 的样子」来推销新框架是错的方向,更好的推销应该是「用我们的框架,可观测性、护栏、监控、部署、评测、版本管理、A/B 测试有多容易」。还有长期做 agent 的人补充:难的从来不是 agent 那个循环本身,而是编排、上下文管理、护栏、监控这些围绕它的工程。Burr 的特性清单几乎就是照着这份痛点清单写的,这说明它的产品定位踩在了点上。
不过有一句质疑要补上:把状态机和可观测性做成框架,不等于做好了。状态可见这件事本质上是工程纪律问题,不是框架能替你解决的;一个团队如果不愿意显式建模状态,给它任何框架它都会把状态塞进全局变量里。Burr 提供的是脚手架,不是纪律。
对建设者的影响
如果你正在选 agent 框架,Burr 的出现给了一个具体的评估清单,这份清单比框架本身更有价值。第一,状态是否可见:你能不能在任意时刻打印出应用现在「在哪一步、记得什么」,而不是埋在一堆闭包和隐式上下文里。第二,能否重放:线上出了一个诡异 case,你能不能拿当时的状态原样重跑一遍来定位,而不是靠日志猜。第三,故障恢复:进程崩了、第三步的 LLM 调用超时了,应用能不能从断点续跑,而不是从头再来烧一遍 token。状态可见、可重放、故障恢复这三条,应该是你评估任何 agent 框架的硬指标,而不是看它的多 agent 演示有多炫。
第二个影响和选型同样实际:进 Apache 孵化器这件事,对企业用户有实际分量。Apache 基金会提供的是治理结构、社区延续性和「不会因为某个创业公司倒闭就消失」的保障,对要把框架写进生产代码、需要向合规和安全团队交代依赖来源的团队,这是真实的减分项被抹平。但孵化(Incubating)只是起点不是终点:Apache 历史上有项目毕业成主流,也有项目进了「阁楼」(attic,即归档废弃)。所以这层背书降低的是「项目跑路」风险,不能降低「这个框架是否适配你」的判断成本。
第三,要诚实面对反方意见。HN 上不止一个人表达了对 agent 框架整体的怀疑:有人给客户做 MVP 选择了「不用框架」,让 Claude/Codex 直接写 agent 循环、工具和流式输出,效果不错;还有人说现在打开一个编码助手、直接让它帮你写个 agent,本就不难。这个反方意见是成立的:对小项目、对一次性的 0 到 1 验证,框架的抽象成本可能高于收益。Burr 的价值随着你的应用复杂度、需要长期维护的程度、需要团队协作的程度而上升;它越像一个需要被运维的系统,Burr 这类框架越划算。在你还没确定要做一个「系统」之前,先别急着上框架。
该忽略什么
忽略名字的浪漫包装。Burr 杀 Hamilton 的典故很有趣,但它和「这个框架适不适合你」没有半点关系,别让团队梗影响技术判断。
忽略官网首页那几个被 CSS 动画卡在「0」的指标位(GitHub Stars、PyPI 下载、Discord 成员)。这些数字位在抓取到的页面里都显示为零,显然是前端计数动画没渲染出来的占位,不代表真实采用量;真要评估热度,去看 GitHub 仓库的实际 star 和 release 节奏。这里也有一条值得留意的事实:HN 上有人指出,这个项目两年来版本号还停留在 0.4x 区间,作者本人回应说推进 Apache 流程加上手头其他事,节奏一直偏慢。所以「进了 Apache」不等于「已经成熟」,版本号和发布频率才是更诚实的成熟度信号。
也忽略官网那排客户证言里的「Reddit User」那条。具名的 CTO、创始人、架构师证言有参考价值,但一条匿名 Reddit 用户的「take a look at Burr, thank me later」被排进证言墙,更像凑数,别把它当社会证明。真正有信息量的反而是那些拿 Burr 和 LangChain、CrewAI、AutoGen 直接对比的具名开发者,他们的共同说法是 Burr 在「复杂行为的建模」和「调试」上更省心,这和官网的状态机加可观测性主张是自洽的,可以信但要自己验证。
技术要点
Burr 的核心抽象是三件套:动作(action,用装饰器声明读写哪些状态字段)、转移(transition,定义动作之间怎么跳)、状态(State,显式的、不可变更新的数据载体)。把它们拼成状态机后,控制流就不再藏在提示词或 if-else 里,而是一张能被打印、被可视化、被测试的图。这套设计的真正收益不在于跑得多快,而在于让 agent 的行为变得「可问责」:出了问题你能指着图说清楚是哪一步、读了什么状态、为什么跳到了那里。对于要长期运维的 agent,这种可问责性往往比模型本身聪明几个百分点更值钱。
来源
- Apache Burr: Build reliable AI agents and applications
- Apache Burr: Build reliable AI agents and applications (Hacker News)
无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。