flowcraft
Go 原生 AI Agent 框架,支持长期记忆、多 Agent 编排和实时语音交互,一行命令部署为静态守护进程
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
Go 原生 AI Agent 框架,支持长期记忆、多 Agent 编排和实时语音交互,一行命令部署为静态守护进程
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
你有没有想过,如果能把 AI 助手像乐高积木一样嵌入到自己的 Go 后端服务里——不需要 Python、不需要 FastAPI、不需要 Docker,只需要一个静态二进制文件和几行 YAML——会是什么体验?FlowCraft 正是为这个目标而生。它是一个纯 Go 编写的 AI Agent 开发工具包,提供了从 LLM 调用、多 Agent 编排、长期记忆到实时语音交互的全套能力,部署形态灵活,可以作为 Go 库、守护进程,也可以作为实时数据管道运行。

图1:FlowCraft 整体架构(分层设计,sdk 为基础层)
FlowCraft 由 GizClaw 团队开发,GitHub 创建于 2026 年 4 月。虽然项目本身较新,但增长势头强劲,在不到三个月的时间里已积累超过 500 颗星,显示出社区对 Go 原生 AI Agent 框架的强烈需求。
项目的核心设计哲学是**"严格分层、职责分离"**:SDK 的 engine 包是一个叶子包(leaf package),不依赖上层的 agent、graph、llm 等模块;而 memory 模块则反过来依赖 SDK 的合约而非反向耦合。这种架构设计确保了模块的可测试性和可替换性——你可以单独使用 memory 的检索能力,而不需要引入整个 agent 运行时。
FlowCraft 采用了清晰的五层架构,从下往上依次是:
sdk 是整个项目的基础层,包含:
agent:Agent 运行时,驱动 DAG 执行、管理工具调用、控制对话循环graph:DAG 定义和节点工厂,支持通过 node.Factory + llmnode.Register 构建工作流图engine:执行引擎核心,提供 Subject 路由的事件总线(每个步骤发出结构化信封),支持 Checkpoint 持久化和 Interrupt/Wait 语义,与 context.Context 完美组合llm:LLM 合约抽象,定义与具体模型无关的调用接口tool:工具注册和执行框架event:事件驱动基础设施telemetry:集成 OpenTelemetry(OTel),提供完整的链路追踪和指标采集sdk 依赖 Bleve(BM25 全文搜索)、Gojieba(中文分词)、Tiktoken(OpenAI tokenizer)、HNSW 向量索引(通过 coder/hnsw)等组件,构建了一个功能完整的检索和嵌入能力库。
sdk 的能力被 memory 模块进一步扩展,提供:
memory/recall:混合记忆检索系统,这是 FlowCraft 最引以为傲的特性之一。采用三路检索(BM25 + 向量 + 实体识别),通过 RRF(Reciprocal Rank Fusion,K=60) 融合结果,再经过实体重叠度加权、超链接衰减和时间衰减重新排序。支持谓词语义归一化——也就是说,"favourite color" 和 "favorite colour" 会被视为同一个记忆。后端可插拔:内置 In-memory、SQLite(modernc.org/sqlite)和 PostgreSQL(pgvector)三种存储引擎。memory/history:对话历史窗口管理memory/knowledge:知识库管理和知识图谱memory/retrieval:可扩展的检索索引抽象memory/text:文本处理流水线sdkx 提供了即插即用的 AI 供应商实现,包括:
这意味着同一套 Agent 代码可以在不同 LLM 供应商之间无缝切换,只需要修改一行 YAML 配置。
vessel 是进程内的 Agent 运行时,提供了生产级的生命周期管理能力:
vesseld 则是 vessel 的独立守护进程版本,将 YAML 声明式配置转化为 HTTP + SSE 控制平面。它是一个单静态二进制,不需要 Python、不需要 Docker、不需要任何运行时。部署方式极其简洁:
vesseld run --config ./config -R
守护进程支持 Unix Socket 和 TCP 两种访问方式,后者需要配置 bearer token 认证。

图2:FlowCraft 官方资源展示
voice 模块提供了完整的实时语音 AI 能力:
底层依赖 pion/webrtc/v4 实现 WebRTC 通信,sdkx 中的任何 STT/TTS 供应商都可以直接接入。
FlowCraft 的 sdk/kanban 模块提供了一种独特的 Agent 协作模式——将任何 Agent 作为工具注册给其他 Agent 调用。这消除了传统多 Agent 系统所需的复杂图 DSL(领域特定语言),composition 变成了纯粹的方法调用。
例如,一个 triage dispatcher Agent 可以将特定类型的任务委托给 support Agent 或 billing Agent,就像真实的客服团队一样自然。
FlowCraft 拥有令人印象深刻的测试基础设施:
tests/e2e/vesseld 提供黑盒端到端测试,测试 vasseld 二进制与内存 OpenAI 模拟服务器的集成测试设计有一个巧妙之处:没有配置文件的 provider 测试会自动跳过(self-skip),所以 make test 在没有 API 密钥的机器上也可以完整通过编译检查。
尽管 FlowCraft 设计精良,仍有几个值得关注的局限:
第一,依赖 GitHub 生态:所有工具均通过 Go modules 管理,对习惯 Python pip 或 npm 的开发者有一定门槛。Gojieba 中文分词依赖需要 CGO,可能在某些受限环境中编译困难。
第二,多 Agent 协作仍偏底层:sdk/kanban 的 tool-based 委托模式虽然简洁,但缺乏可视化的流程编排能力,对于复杂的 Agent 协作场景(例如条件分支、并行执行)需要手动构建 DAG。
第三,Voice 模块相对年轻:voice 模块依赖 pion WebRTC SDK,整体功能丰富但文档示例相对有限,WebRTC 在生产环境中的稳定性需要实际验证。
第四,记忆召回精度依赖调优:RRF 融合的参数(K=60)和各类衰减系数对不同场景的效果差异较大,需要结合实际数据进行参数搜索。
FlowCraft 的出现填补了 Go 生态中缺乏生产级 AI Agent 框架的空白。在它之前,Go 开发者如果想接入 AI 能力,通常只能直接调用 OpenAI SDK,然后自己实现对话管理、记忆存储等基础设施——工作量巨大。FlowCraft 将这些基础设施标准化了。
更重要的是,FlowCraft 提出的分层架构理念(engine 是叶子包、memory 反向依赖 SDK 合约)是一种经过生产验证的架构设计范式,值得其他 AI Agent 框架借鉴。它还通过 vasseld 证明了"不需要 Docker 也能实现可靠的微服务化部署"——这在 Serverless 时代有着重要的现实意义。
随着 Go 1.25+ 在云原生领域的持续普及,FlowCraft 有望成为 Go 后端接入 AI 能力的事实标准框架之一。