Finyuus

嘿，Product Hunt！👋

我在构建 AI 应用时反复遇到同一个问题：AI 逻辑——prompt、工具调用、重试、防护、审批等待——总是和我的应用代码纠缠在一起。有一阵子我不得不在同一个代码库里同时维护 300 行的系统 prompt 和 iPhone 应用的按钮、界面。任何一点小行为改动都意味着要重新构建并重新部署整个应用。

这和应用程序对待数据库的方式有很好的类比。应用通过 SQL 与数据库对话，所以数据逻辑独立于应用代码。我希望 AI 也能有同样的分离：独立于使用它们的应用来定义、版本化、运维和修改智能体、prompt、工具、防护和工作流。

Finyuus 就是我做出来的东西。它是一种基于缩进的、用于组合 AI 工作流的小型 DSL，底层由 Temporal 提供持久执行（重试、取消、长时间等待、子工作流），Langfuse 负责追踪和成本报告，还有一个仪表盘用于编写、运行和审查所有内容。工作流以文本形式存储，所以拥有 Git 历史、PR 和可读的 diff——这些是可视化构建器在大规模时会失去的。

它是开源的，并且通过 Docker 完全在本地运行（Temporal、ClickHouse、MinIO（或 S3）、Langfuse、Redis 都包含在内）。我很想听听大家对 DSL 易用性、治理模型（防护 + 人工审批）以及下一步功能的反馈。

欢迎深入讨论架构的任何部分。🙏

把工作流保留为纯文本，而不是把所有东西都锁进可视化构建器，这可能是我最喜欢的部分。一旦项目变大，Git diff 和 PR review 就很难放弃。

持久性和可 git diff 的执行图才是真正有用的部分，很多 prompt 链工具都缺这个。不过新的 DSL 是我想反驳的部分——Temporal 已经有 Python 和 TypeScript SDK，能让你获得重试、重放和版本管理，而不需要任何人学新的缩进规则。相比在一个轻量 Python wrapper 里包装同样的防护和审批，这门语言到底多给了你什么？除了让解释器的实现面更小之外？“可治理”和“可 diff”并不显然需要新语法，它们需要的是你已经构建好的底层执行模型。

要为跑一个 prompt 而启动 Temporal、ClickHouse、MinIO、Langfuse 和 Redis，这是我要吐槽的点。没人会在周二下午把这一套都拉起来，而这类东西真正被采用恰恰是从某个周二下午开始的。SQL 这个类比其实也反着支持：SQL 之所以赢，是因为它在每种引擎上都是同一种语言；而一种只跑在单一 runtime 上的 DSL，是一种大家能感受到的锁定。我会发布一个单二进制模式，用 SQLite 模拟持久性，这样人们可以在十分钟内写出一个工作流，等真正需要时再遇到 Temporal。