DuraGraph
面向 AI Agent 的持久化工作流编排引擎:事件溯源、可回放、单二进制自托管。
- Star 数
- ★ 161
- 最近更新
- 1 个月前
- License
- Apache-2.0
- 主语言
- Go
- FA 评分
- 50/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 兼容但需适配
- 费用
- 免费,无需付费服务
- 上手难度
- 低 · 几分钟可跑通
- 开始前需要
- 典型场景
- 需要长时间运行的 LLM Agent 团队:Agent 会跑几小时甚至更久,担心 worker 在中途崩溃导致状态丢失,希望重启后从最后一个已提交状态继续。
- 不适合
- 需要开箱即用多租户隔离的团队
- 不想理解事件溯源与CQRS的团队
- 需要生产级Helm图表与工作流版本迁移的团队
- 源码审查
- 50/100 · 缺口较多
这个 Agent 能做什么,适合哪些场景?
DuraGraph 是一个自托管、面向企业场景的 AI 工作流编排系统,核心思路是把每一次状态变更都作为不可变事件写入 PostgreSQL,并与工作本身放在同一个事务里,因此 worker 在工具调用中途崩溃也不会丢状态,整个运行可以从事件日志重放。仓库是 monorepo:cmd/duragraph 是控制平面二进制(引擎 + 内嵌 dashboard + 开发模式引导),internal/ 按 DDD、事件溯源与 CQRS 分层,dashboard/ 是 React + TanStack Router + xyflow 的控制台(含可视化工作流编辑器,构建时嵌入二进制),python/ 与 go-sdk/ 是两类 worker SDK,examples/ 提供 Go 与 Python 参考 Agent,deploy/ 存放 Docker、SQL 迁移与 Helm chart。对外接口是稳定的 REST + SSE API,覆盖 runs、threads、assistants、graphs;worker 通过 SDK 在启动时注册图定义,不需要代码生成或自定义 DSL。部署边界很清晰:开发模式用单个二进制内嵌 PostgreSQL 与 NATS,生产环境可换成外部 Postgres 和 NATS。
运行时,worker 通过 Python 或 Go SDK 连接控制平面并注册图定义;客户端调用 POST /api/v1/threads/:id/runs 创建 run,引擎的图执行引擎按节点、边、条件分支、human-in-the-loop 中断与工具调用逐步推进,并把每个状态迁移作为事件写入 PostgreSQL 事件存储。写事务与工作本身同一事务提交,因此崩溃后可从中断处恢复,且不会重复执行。Outbox relay 把领域事件转发到 NATS JetStream,dashboard 通过 SSE 实时显示节点点亮、图拓扑与可回放的轨迹。读取侧走 CQRS 查询,GET /api/v1/runs/:id 取运行状态,GET /api/v1/threads/:id/runs 列出会话中的 run,GET /api/v1/threads/:id/runs/:run_id/stream 订阅实时执行事件,POST /api/v1/assistants 注册 assistant,GET /api/v1/assistants/:id/graph 读取图结构。此外暴露 OpenTelemetry 友好的 Prometheus 指标。
- 需要长时间运行的 LLM Agent 团队:Agent 会跑几小时甚至更久,担心 worker 在中途崩溃导致状态丢失,希望重启后从最后一个已提交状态继续。
- 需要审计与合规的场景:要把每一次状态变更按时间顺序留痕,并基于事件存储做 eval 与合规视图。
- 被线上失败困扰的开发者:想按产生问题的确切决策序列逐步回放出错 run,而不是只看堆栈和模糊的最后已知位置。
- 想免运维试跑自己的 AI 工作流的个人或小团队:用 duragraph dev 一条命令起引擎和内嵌 Postgres/NATS,从 Playground 发第一条消息。
- 已经在用 Go 或 Python 写 Agent 的工程团队:用 go-sdk 或 python/ 中的 SDK 注册图定义,接入现有代码而不写 DSL。
- 平台团队:需要自托管的控制平面、REST + SSE 接口、Prometheus 指标,并计划在生产替换成外部 Postgres 与 NATS。
如何安装或部署这个 Agent?
README 给出四种安装途径,任选其一:
# Homebrew(macOS、Linux)
brew install Duragraph/tap/duragraph
# 一行安装脚本
curl -fsSL https://duragraph.ai/install.sh | sh
# 从 Go 安装
go install github.com/Duragraph/duragraph/cmd/duragraph@latest
# 或从 Releases 下载预编译二进制
# → https://github.com/Duragraph/duragraph/releases从源码参与开发:
git clone https://github.com/Duragraph/duragraph.git
cd duragraph
task dev # 针对本地 Postgres + NATS 启动引擎与 dashboard
task test # 单元 + 集成测试套件凭据方面:无需预先配置数据库或消息中间件,开发模式内嵌 PostgreSQL 与 NATS;首次启动后使用日志中打印的 bootstrap admin 账号登录 dashboard。生产环境需要外部 PostgreSQL 与 NATS(deploy/ 下提供 Docker 与 SQL 迁移,Helm chart 仍标注为进行中)。
如何使用这个 Agent?
第一步启动服务:
duragraph dev
# → 引擎与 dashboard 监听 http://localhost:8081第二步跑通第一个 Agent:打开 http://localhost:8081,用日志里打印的 bootstrap admin 登录,进入 Playground,选择一个已注册的 assistant,发送一条消息;可以看到工作流实时执行,每个节点依次点亮,并能在 Traces 中查看完整图拓扑与可回放的事件日志。examples/ 下有 RAG、工具调用 Agent、文档处理、eval 等 Go 与 Python 示例,可直接对着 duragraph dev 运行。
第三步接入自己的 Agent:起一个 worker,用 python/ 或 go-sdk/ 里的 SDK 在启动时注册图定义;然后通过 REST + SSE 驱动 run:
POST /api/v1/threads/:id/runs # 创建 run
GET /api/v1/runs/:id # 查询 run 状态
GET /api/v1/threads/:id/runs # 列出某会话的 run
GET /api/v1/threads/:id/runs/:run_id/stream # SSE:实时执行事件
POST /api/v1/assistants # 注册 assistant
GET /api/v1/assistants/:id/graph # 读取图拓扑这个 Agent 有哪些优点和局限?
- 事件溯源 + CQRS + outbox 的组合是真实实现:每个状态迁移与工作在同一事务写入 PostgreSQL,崩溃后从最后提交状态恢复且不重复执行,run 可从事件日志完整重放,便于调试与审计。
- 开发体验门槛极低:单个二进制内嵌 PostgreSQL 与 NATS,duragraph dev 一条命令即可跑起引擎与 dashboard,不需要 docker compose,也不需要先准备基础设施。
- SDK 与语言生态对工程团队友好:提供 Python(PyPI 包 duragraph)与 Go 两个 worker SDK,worker 在启动时注册图定义,无需代码生成或自定义 DSL。
- 运维与集成面完整:稳定的 REST + SSE 接口、React + xyflow 的内嵌 dashboard(含可视化工作流编辑器和 Traces 会话视图)、OpenTelemetry 友好的 Prometheus 指标,以及 Docker 与 SQL 迁移资产。
- Apache-2.0 许可,采用 monorepo 让控制平面、SDK、dashboard 与文档围绕同一份规范一起演进。
- 生产就绪度有限:多租户与 NATS Accounts 隔离、生产 Helm chart、工作流版本管理与迁移都明确标为 in flight,尚未完成。
- 可观测性有缺口:按节点的 REST spans 端点仍未提供,目前只能通过 SSE 获取执行事件。
- 生产部署引入外部依赖:开发模式内嵌 Postgres 与 NATS 很省事,但 README 说明生产环境使用外部 PostgreSQL 与 NATS,等于把数据库与消息中间件的运维成本接了过来。
- 需要理解其架构模型:要真正用好,团队得接受事件溯源、CQRS、outbox relay 这套概念,对只想写线性 Agent 脚本的人属于额外认知负担。
- 仓库未说明支持的 LLM provider 或模型适配层,也没有列出各主流 Agent 运行时之间的迁移路径,选型时这方面的证据缺失。
这个 Agent 与同类方案有什么区别?
README 明确把自己定位为「Temporal for AI agents」,并指出采用的是与 Temporal 相同的持久化工作流架构,只是针对 AI Agent 图的形状(节点、边、条件分支、human-in-the-loop 中断、工具调用)做了专门设计。文中还提到 LangChain 类编排器只保存 run 的当前状态,出问题时只留下堆栈和模糊的最后位置——这是 README 自己给出的对比对象。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| DuraGraph 当前 | 50 · 缺口较多 | 命令行工具免费 | ★ 161 | 1 个月前 | Go | — |
| MUXI AI 应用服务器 | 52 · 缺口较多 | 命令行工具免费 + 模型费 | ★ 178 | 1 个月前 | — | — |
| Statewave 智能体内存运行时 | 72 · 存在缺口 | 自托管服务免费 + 模型费 | ★ 257 | 15 天前 | Python | OpenAI API · Claude API |
| Maze 分布式 LLM Agent 框架 | 62 · 存在缺口 | 命令行工具免费 | ★ 608 | 19 天前 | Python | — |
FollowAgents 如何评估这个 Agent?
查看各维度的扣分理由
README 描述了事件存储、NATS 中继、API 和工作器等主要数据路径,worker 源码也列出连接配置、容量和注销流程,因此数据流有一定可见性(2)。但所给材料没有充分说明权限边界、敏感数据保留或脱敏、外部副作用的确认机制,也没有明确回滚流程;样例 secrets 文件提醒不要提交真实凭据,却没有体现产品运行时的凭据保护。安全报告渠道明确,但发布者身份及其归属未获验证,故来源归属证据有限(其余 1)。
README 和源码都描述事件持久化、重放及 worker 心跳、排空和注销;worker 对缺失或格式错误的配置会返回具体错误,主程序也以非零状态退出(failure_messages 2)。但 README 的 Go 版本徽章与 go.mod 的 Go 1.25.0、Act 环境样例中的 Go 1.23 不一致;README 的可靠性保证在所给源码中没有充分交叉验证。依赖清单虽具体,但材料未说明依赖可用性或故障降级,因此自洽性和依赖可用性为 1。
README 面向构建和运行工作流的开发者,列出 Go/Python SDK、RAG、工具调用、文档处理和评估等场景,并区分内嵌开发数据层与外部生产数据层(audience_and_scenarios、environment_fit 各 2)。它也列出当前缺少的多租户、节点 spans 端点、生产 Helm charts 和工作流版本迁移,能界定部分能力边界(2)。触发条件、适用范围和不适用场景没有系统说明,故 trigger_precision 为 1。
README 通过目录表、架构图、API 示例及 contributing 指引组织信息;安装路径、启动方式和入门步骤较具体,examples 与文档入口也明确(这些项目为 2)。Apache 2.0 完整许可证文件和 README 标注相互吻合,license 为 3。名称虽大体稳定,但主程序与兼容旧入口并存,且样例环境的 Go 版本和 go.mod 不一致,命名稳定性为 1。README 列出进行中的功能,但所给材料没有版本化变更记录或清晰的维护责任人;有安全邮箱和贡献入口,但 publisher 身份未知,故相关分数为 1。
产品提供单二进制开发启动、Python/Go SDK、图执行与可观察性界面,README 给出初次运行路径,具有可用的交付形态和清楚的工作流编排价值(output_usability、marginal_value 各 2)。开发模式嵌入 PostgreSQL 与 NATS 可减少本地配置,但生产仍需外部数据层,且企业适用性中的多租户和生产 Helm 支持仍在进行中;成本与运维收益有合理说明但缺少量化证据,因此 cost_benefit 为 2。
README 的架构图、端点示例、目录说明和安装命令可定位多项主张,worker 源码也能支持部分配置和生命周期描述(claim_traceability 2)。然而核心可靠性、审计与企业就绪主张缺少给定源码或文档的充分佐证,且 README、Go 模块和环境样例的版本信息不一致,交叉佐证为 1。材料没有持续区分已实现事实与尚待验证的主张;“Status”有所区分,但主要保证仍以项目自述呈现,因此 fact_inference_separation 为 1。
- 不要仅凭 README 中的“企业就绪”、故障恢复或审计描述认定生产保障已得到源码证明;所给材料未充分展示权限控制、敏感数据保护和回滚机制。
- 核对实际构建所需的 Go 版本:go.mod 标明 1.25.0,而 CI 环境样例标明 1.23,README 徽章也未在材料中给出可核对的版本值。
- README 将多租户、生产 Helm charts 和工作流版本迁移列为进行中功能;生产部署前应确认这些能力是否已实现。
最近版本
来自该项目 GitHub Releases 的最新发布记录,说明为上游原文摘录,未经本站改写或测试。
-
发布说明摘录
Docker ```bash docker pull duragraph/duragraph:v0.8.1 ``` What's Changed * feat(cmd): wire the rebuilt control plane into the binary by @adwiteeymauriya in https://github.com/Duragraph/duragraph/pull/247 * docs(changelog): correct 0.8.0 and record 0.8.1 by @adwiteeymauriya in https://github.com/Duragraph/duragraph/pull/248 Full Changelog: https://github.com/Duragraph/duragraph/compare/v0.8.0...v0.8.1在 GitHub 查看 ↗ -
发布说明摘录
> [!IMPORTANT] > Correction, added after release. The features listed below are real and are in the repository, but they were not reachable from the binary this release ships. > > The release pipeline builds ./cmd/duragraph, and that command imported none of the controlplane/ packages. If you installed v0.8.0 and ran duragraph serve, you got the previous implementation — in which llm.token, checkpoint.saved and the SSE heartbeat are absent, cron advances its schedule and logs "cron triggered" without creating any run, and completed runs record no output. > …在 GitHub 查看 ↗ -
发布说明摘录
Docker ```bash docker pull duragraph/duragraph:v0.7.7 ``` What's Changed * fix(auth): dashboard auth gate honors /info instead of just localStorage by @adwiteeymauriya in https://github.com/Duragraph/duragraph/pull/208 Full Changelog: https://github.com/Duragraph/duragraph/compare/v0.7.6...v0.7.7在 GitHub 查看 ↗
常见问题
开发模式真的不需要任何外部基础设施吗?
worker 崩溃或工具调用失败时会发生什么?
如何在 dashboard 之外的系统里观察执行过程?
支持哪些 LLM 供应商?
可以用在多人或多租户环境中吗?
谢谢反馈,我们会据此改进页面。