为什么我写了一个 AI 工作流引擎
I’m sorry, but I can’t translate the article because the text you’d like me to work on wasn’t included in your message. Please paste the content you want translated (excluding any code blocks or URLs), and I’ll be happy to provide a Simplified Chinese version while preserving the original formatting.
📖 重复的模式
“我一次又一次地构建相同的东西。”
过去几年里，我一直在开发几款应用，它们都有一个共同的主题：
| 应用程序 | 核心需求 |
|---|---|
| Memoir Writing Assistant | 长期运行的对话式工作流，引导用户进行深度个人化的叙事。 |
| Small‑Business Finance App | 业务流程工作流（审批、对账、重复任务），叠加 AI 用于分类和洞察。 |
| Customer Chatbot (current client) | 基于 RAG 的知识库导航、支持处理、零件选择与订购。 |
| Academic Research Assistant | 由 LLM 驱动的研究项目分析与综合。 |
所有这些都需要 我不断从头重建的三件事：
- 持久的工作流编排
- 与 AI 代理的集成
- 对 AI 成本的控制
每个新项目都归结为相同的步骤：
- 将工作排入队列
- 调用 LLM
- 跟踪进度和重试
- 持久化状态
- 通知用户
我知道一定有更好的方法，于是我开始寻找。
🔎 现有工具 – 缺失何处？
| 工具 | 优势 | 弱点（针对 AI 为中心的工作负载） |
|---|---|---|
| Temporal | 金标准的持久执行 | 维护开销大，且不关注 token 使用或 LLM 定价。 |
| Airflow | 成熟的批处理调度器 | 为基于 cron 的 DAG 设计，不适用于事件驱动的交互式流程；Docker 镜像体积大，内存占用高。 |
| LangChain / LangGraph | 面向 AI、功能丰富的 LLM 工具 | 仅限 Python，缺乏原生持久性；生产环境需使用 LangSmith（专有，约每百万次执行 1 千美元）。 |
结论： 现有方案要么 运维负担重且对 AI 不敏感，要么 对 AI 有感知但缺乏持久性和独立性。
💡 核心认识
在 AI 应用中，LLM 成本是一个 应用‑基础设施 的关注点。
当工作流调用 LLM 时，该调用的成本应影响下一步：
- 我能负担 Claude Sonnet 吗，还是应该回退到 Haiku？
- 这个工作流已经耗尽预算了吗？
- 我能复用缓存的结果，而不是再次进行 API 调用吗？
这些决定必须在 执行期间 做出，而不是事后。因此，成本跟踪应嵌入编排器本身，而不是事后的仪表盘。
🚀 介绍 Kruxia Flow
一个 为 AI 应用专门打造的持久化工作流引擎。
| 特性 | 详情 |
|---|---|
| Binary | 单一 Rust 二进制文件（约 7.5 MiB） |
| Persistence | PostgreSQL（无 Kafka、Elasticsearch、Cassandra） |
| Deployment | 一个二进制文件 + 一个数据库 → 小型 Docker 镜像（≈ 63 MiB） |
| Portability | 可在 Raspberry Pi Zero、云 VM 或任何容器主机上运行 |
AI 原生核心特性
-
自动成本追踪
- 实时计数并计价 Token。
- 支持 Anthropic、OpenAI、Google Gemini 以及自托管的 Ollama 模型。
-
预算强制执行
- 为每个工作流或每个活动设置预算。
- 引擎在每次 LLM 调用 之前 检查预算；若超出可中止或发出警报。
-
成本感知模型回退
- 定义回退链（例如 Claude Sonnet → Claude Haiku → Ollama）。
- 编排器选择在剩余预算内最强大的模型。
-
语义缓存
- 相似查询命中缓存而非 API。
- 对常见模式（FAQ、RAG）可将冗余调用减少 50‑80 %。
-
Python SDK
- 使用 Python 定义工作流和自定义工作者。
- 内置支持
pandas,DuckDB,scikit‑learn。
📊 基准测试 (Kruxia Flow vs. Temporal & Airflow)
| 指标 | Kruxia Flow | Temporal | Airflow |
|---|---|---|---|
| 吞吐量 | 93 工作流 / 秒 | 66 工作流 / 秒 | 8 工作流 / 秒 |
| 峰值内存 | 328 MiB | ~1 GiB（变化） | 7.2 GiB |
| Docker 镜像大小 | 63 MiB | > 500 MiB | > 1 GiB |
| 测试硬件 | 2 vCPU，4 GiB RAM（Linux） | 同上 | 同上 |
| Raspberry Pi Zero | ✅ 可运行 | ❌ 过于笨重 | ❌ 过于笨重 |
👥 Kruxia Flow 适合谁？
- AI 初创公司 将代理部署到生产环境，需要 实时成本可视化。
- 小型企业 想要实现工作流自动化，却不想支付五位数的基础设施费用。
- 数据团队 将批处理管道、机器学习训练、自然语言处理和大语言模型代理结合在一起，同时保持 运营轻量化。
如果您符合上述任意情况，Kruxia Flow 正是为 您 而构建的。
📜 许可与可用性
- 核心引擎、LLM 成本追踪、预算强制、多提供商支持、令牌流式传输 – AGPL‑3.0（开源）。
- Python SDK – MIT 许可证。
仓库: https://github.com/kruxia/kruxia‑flow (公开，积极维护)
🛠️ 快速入门 (Quick‑Start)
# 1️⃣ Pull the Docker image (63 MiB)
docker pull ghcr.io/kruxia/kruxia-flow:latest
# 2️⃣ Run PostgreSQL (if you don’t have one already)
docker run -d \
-e POSTGRES_PASSWORD=secret \
-e POSTGRES_USER=kruxia \
-e POSTGRES_DB=kruxia \
-p 5432:5432 \
postgres:15
# 3️⃣ Start Kruxia Flow
docker run -d \
-e DATABASE_URL=postgresql://kruxia:secret@host.docker.internal:5432/kruxia \
-p 8080:8080 \
ghcr.io/kruxia/kruxia-flow:latest
# 4️⃣ Install the Python SDK
pip install kruxia-flow-sdk现在你可以用 Python 定义工作流：
from kruxia import workflow, activity, ModelSelector
@workflow
def memoir_assistant(user_id: str):
# Step 1 – fetch user profile (cached)
profile = await activity(fetch_profile, user_id)
# Step 2 – generate outline (cost‑aware)
outline = await activity(
generate_outline,
profile,
model=ModelSelector(preferred="claude-sonnet", fallback="claude-haiku")
)
# Step 3 – store result
await activity(save_outline, user_id, outline)🎉 结束语
现有的工作流引擎要么 让你背负运营复杂性，要么 忽视大模型使用的成本。
Kruxia Flow 通过提供一个 体积小、基于 Rust、具备 AI 感知的编排器，弥合了这一鸿沟，它能够：
- 实时追踪费用
- 在超出预算前强制限制
- 自动回退到更廉价的模型
- 缓存语义相似的查询
同时保持 轻量化、开源，并且 易于单人开发者或小团队运行。
祝开发愉快！ 🚀
路线图
- 语义缓存、网页仪表盘以及 TypeScript SDK 正在规划中。
我仍在持续构建，前路漫长。但基础已经稳固，我已经在自己的项目中使用它——这正是我最初创建它的初衷。
如果这些内容触动了你，欢迎前往 GitHub 查看代码，或加入 Discord 与我讨论设计、路线图或 AI 的实际应用。