GustoBot 菜谱知识客服

用多智能体问答连接菜谱、食材、烹饪知识与饮食文化。

Star 数
★ 409
最近更新
1 个月前
License
Apache-2.0
主语言
Python

30 秒速览

运行形态
自托管服务网页应用
可在哪里用
兼容但需适配
费用
软件免费,模型调用费用自付
上手难度
高 · 需要较重的基础设施
开始前需要
Python 3.10Node.js 16+DockerDocker ComposeNeo4jMySQLPostgreSQL pgvectorMilvusRedisShell / 命令行网络访问本地文件系统
典型场景
菜谱平台团队希望让用户用自然语言查询菜品、食材、菜系或烹饪步骤。
不适合
  • 不需要自建多数据库和服务的轻量问答团队
  • 需要可核验完整数据出处的生产部署

这个 Agent 能做什么,适合哪些场景?

GustoBot 是一个基于 LangGraph 的菜谱知识问答与多模态服务系统,提供 React 前端和 FastAPI 后端。主路由将问题分发给知识库或 GraphRAG 多工具子图,后者可调用 Neo4j、MySQL、PostgreSQL pgvector、Milvus 和外部检索 API。系统通过 Text2SQL、Cypher 查询、向量检索和 LightRAG 检索整合结果,并可生成带来源的回答;README 还描述了菜品图片识别与生成、文件分析和 Redis 会话管理。快速开始采用 Docker Compose 启动后端,并在本地运行前端。它适合需要可迁移的垂直领域客服模板、且愿意配置多项数据服务的团队。

用户提交文本问题、图片或文件后,LangGraph 主工作流先运行 analyze_and_route_query,并根据意图选择通用回答、知识库查询、GraphRAG 查询、图片处理或文件处理。多工具子图会执行 Guardrails 检查,必要时由 Planner 拆解任务,再选择 cypher_query、predefined_cypher、microsoft_graphrag_query 或 text2sql_query 等工具。知识库流程优先查 PostgreSQL pgvector,无结果时以 Milvus 兜底,并可通过 reranker 和外部检索补充结果。系统汇总检索或数据库结果,生成带来源的回答;图片能力使用 Vision Model 和 CogView-4,文件流程支持 Excel、TXT、Markdown、JSON。README 未给出可核验的 API 路径或首个请求示例。

  1. 菜谱平台团队希望让用户用自然语言查询菜品、食材、菜系或烹饪步骤。
  2. 饮食文化编辑希望检索菜品典故、历史背景,并融合本地知识库与外部搜索结果。
  3. 数据团队希望用自然语言查询菜谱统计、排行榜或聚合数据,再由 MySQL 执行 SQL。
  4. 希望分析用户上传的 Excel、TXT、Markdown 或 JSON 菜谱资料的运营团队。
  5. 希望根据菜品图片识别菜品,或按描述生成菜品图片的产品团队。

如何安装或部署这个 Agent?

快速开始要求 Python 3.10、Node.js 16+、Docker 和 Docker Compose。README 展示了克隆仓库、复制环境文件、启动 Docker 后端及本地启动前端的步骤。还需编辑 .env 配置必要的 API 密钥;README 没有列出所有必填变量、密钥提供方或每个数据库服务的初始化步骤。

git clone https://github.com/skygazer42/GustoBot.git
cd GustoBot
cp .env.example .env
# 编辑 .env 文件,配置必要的 API 密钥
docker-compose up -d
cd web
npm install
npm run dev

如何使用这个 Agent?

启动后,在浏览器打开 http://localhost:5173 使用前端;README 将后端 API 地址列为 http://localhost:8000,并说明可通过 VITE_PORT 修改前端端口。文档没有提供具体 API 路径、请求格式或可复制的首个 API 调用。要使用查询、图片或外部检索能力,还需在 .env 中配置相应服务和 API 密钥。

前端:http://localhost:5173
后端 API:http://localhost:8000

这个 Agent 有哪些优点和局限?

优点
  • LangGraph 三层架构将路由、子图编排和原子工具分开,README 说明可通过替换知识源与图谱 Schema 迁移到其他垂直领域。
  • GraphRAG 子图支持 Cypher、预定义 Cypher、LightRAG 和 Text2SQL 工具,并可拆分任务后并行执行。
  • 知识库检索采用 PostgreSQL pgvector 优先、Milvus 兜底的策略,并可选 reranker 和外部搜索。
  • README 描述了图片识别与生成、文件分析、来源标注和 Redis 会话管理等能力。
局限
  • 部署涉及 Docker Compose、前后端运行环境及 Neo4j、MySQL、PostgreSQL pgvector、Milvus、Redis 等服务,配置负担较重。
  • 需要自行配置必要的 API 密钥;README 没有完整列出变量、提供方、价格或各项服务的初始化细节。
  • README 提到部分历史饮食文本和 8 条 pgvector 示例记录缺少可核验的上游出处,不适合直接作为有完整数据血缘要求的知识库。
  • 虽然 README 提及带来源回答,但没有提供具体 API 路径、请求示例或服务失败时的完整行为说明。

这个 Agent 与同类方案有什么区别?

与相关度最高的同类 agent 并排比较关键指标。

Agent 源码审查 形态 / 费用 Star 最近更新 主语言 完整支持的平台
GustoBot 菜谱知识客服 当前 45 · 缺口较多 自托管服务免费 + 模型费 ★ 409 1 个月前 Python —
Yuxi(语析)——可私有部署的多租户知识智能体平台 41 · 缺口较多 自托管服务免费 + 模型费 ★ 7.4k 3 天前 Python OpenAI API
WrenAI GenBI 53 · 缺口较多 命令行工具免费版 + 付费版 ★ 18k 今天 Python Codex · Claude Code
WhoDB 51 · 缺口较多 自托管服务免费版 + 付费版 ★ 5k 今天 Go —

FollowAgents 如何评估这个 Agent?

FollowAgents 源码审查 · FARS-2.1
缺口较多
45/ 100 五分制 2.3 / 5
信任安全 10/29
可靠稳定 5/14
适用触发 9/18
规范维护 10/18
有效结果 7/13
证据核验 4/8
查看各维度的扣分理由
信任安全10 / 29 · 1.7/5

README 描述了多类数据源、外部搜索、图片与文件处理,并称答案附来源;数据来源说明也指出部分历史文本及 8 条 pgvector 示例记录缺少可核验上游出处,因此数据流有一定可见性但来源覆盖不完整(2)。Guardrails、Schema 检查和可选 Cypher 验证有说明,但没有用户确认、回滚机制或敏感数据存储与保留控制的证据(分别为 0、0、1);依赖多数固定版本但 LightRAG 使用开放版本范围,且没有漏洞处置证据(1)。最小权限和外部副作用控制未有实现证据(1、1)。

可靠稳定5 / 14 · 1.8/5

README、pyproject.toml 与 requirements.txt 对 Python 版本存在 3.10、>=3.9 和未统一依赖声明等差异,且 README 的 PostgreSQL 优先兜底描述与部分架构叙述不完全一致,故自洽性仅部分(1)。Docker 快速启动有步骤,但需多种数据库、模型和外部 API,依赖可用性与配置完整性未充分证明(1)。代码/API 错误路径仅在测试脚本中展示捕获或错误事件,缺少一致、面向用户的恢复指引(1)。

适用触发9 / 18 · 2.5/5

菜谱客服场景、查询类别、多模态能力和垂直领域迁移方向均有具体说明,支持常见用途评估(2);领域边界与拒绝策略有描述,但安全边界的执行证据有限(2)。启发式加 LLM 路由和示例用例展示了意图触发方式,但没有阈值或误路由处理细节(1)。环境说明列出 Python、Node、Docker,却与项目元数据的 Python 版本不一致,也未给出完整外部服务配置(1)。

规范维护10 / 18 · 2.8/5

README 按架构、功能、流程和启动说明组织,结构清楚但篇幅较长(2)。快速开始有基本命令和 .env 提示,缺少所需变量及服务配置细节(1)。模块与路由名称有示例,但版本要求不一致且部分命名在描述中混用(1)。功能表、架构图和路由用例提供了较实用的例子,但没有 FAQ(2)。数据出处 caveat 与 Security Policy 的支持范围说明了部分限制(2)。仓库含完整 Apache-2.0 许可证文本(3)。有 pyproject 版本号和 SECURITY.md 的分支维护说明,但未见变更日志或发布历史信息(1)。安全报告渠道与最新 develop 分支支持承诺明确,但作者元数据仍为占位文本,责任主体有限(1)。

有效结果7 / 13 · 2.7/5

系统承诺输出答案、来源及会话历史,多源检索和统计/图谱/多模态能力针对菜谱客服有明确用途,但输出格式质量未由可核验结果支撑(2)。相较普通问答,结构化查询、知识图谱和文件/图片能力能提供领域增量价值,惟多项为文档陈述(2)。部署依赖众多数据库、模型和外部 API,配置与运维成本偏高且未提供成本估算(1)。

证据核验4 / 8 · 2.5/5

README 将不少功能映射到模块、工具、数据源,并对缺少上游出处的数据作出披露,主张有一定追踪线索但实现证据有限(2)。LICENSE、依赖清单、测试脚本及安全政策可交叉支持部分项目事实,不过核心能力主要由 README 自述,测试文件不能证明执行结果(1)。数据来源说明明确区分可核验来源与未保留出处的演示数据,且安全机制多以设计描述呈现,事实与主张有部分区分(2)。

风险与缓解建议
  • 源码中未见:执行前用户确认开启或自行加上执行前确认;先在沙箱或测试环境跑通,确认行为后再接入真实数据。
  • 源码中未见:回滚或恢复路径运行前先备份,或在 git 分支、快照上操作,确保改动可以撤销。
  • 部署前核对 Python 版本与依赖配置,并确认 PostgreSQL、Milvus、Neo4j、MySQL、Redis 及模型/API 所需配置。
  • 不要将缺少可核验上游出处的历史文本和 pgvector 示例数据视为已确认来源;上传文件、对话及外部 API 的数据处理与保留方式未在所给材料中充分说明。
证据充分度:低 评估于 2026年10月13日 审查版本 09fadecd87d7
查看完整评分方法 →

常见问题

使用它会产生哪些费用?
仓库采用 Apache License 2.0,但 README 没有说明 API 或模型服务的价格。必要的 API 密钥可能对应外部服务费用,部署者应核对所选服务的计费方式。
部署前需要准备什么?
快速开始列出 Python 3.10、Node.js 16+、Docker 和 Docker Compose。架构还使用 Neo4j、MySQL、PostgreSQL pgvector、Milvus 和 Redis,并要求在 .env 中配置必要的 API 密钥。
它能回答非菜谱领域的问题吗?
默认系统面向菜谱服务,并通过 Guardrails 检查问题范围。README 将迁移到其他领域描述为替换知识源与图谱 Schema 的模板用法,并非无需改造即可直接覆盖其他领域。
内置数据适合直接用于生产吗?
README 表示菜谱主数据来自 OpenKG RecipeGraph;部分历史饮食文本和 8 条 pgvector 示例记录没有保留可核验的上游出处,仅适合链路演示。
在 GitHub 查看 ↗ 安装 ↓

相关 Agents