🚀 AI Experiments Suite：一个人用 LangChain + Groq + Streamlit 搭了一套 AI 应用全家桶

图1：AI Experiments Suite 项目首页

一、当 HR 抱怨「每天筛简历看到吐」的时候

2025年2月，一位名叫 Vivek Pathania 的开发者在 GitHub 上传了一个名为 AI Experiments Suite 的仓库。和那些动辄数万 star 的明星项目不同，这个仓库刚上线时只有几十个 star，但它解决的是一个真实到不能再真实的问题——

"我每天要处理几十份简历和职位描述，有没有办法让 AI 帮我做初步筛选？"

Vivek 并不是什么科技巨头的高级工程师。他和大多数独立开发者一样，一边写代码，一边摸索 AI 能力的边界。他没有选择去卷大模型微调，而是把目光投向了更务实的方向：如何用现有的 LLM API，在最短时间内搭建一套真正能用的 AI 应用。

这个思路非常朴素，但恰恰戳中了 2025 年 AI 应用开发的痛点：大模型的能力已经足够强，缺的不是底层技术，而是把技术组装成产品的人。AI Experiments Suite 就是这样一套「组装指南」——它把 LangChain、Streamlit、Groq API、Tavily 等工具串起来，做成了 9 个可以直接运行的子项目，涵盖 NLP 对话、数据库查询、旅行规划、电商搜索、HR 筛选等真实场景。

截至2025年中期，该仓库已积累 173 star，虽然体量不大，但它代表的「独立开发者用 LLM API 快速搭建垂直场景应用」的思路，在 AIGC 应用爆发的大背景下具有相当的代表性。

---

二、技术栈拆解：为什么 Vivek 选了这些工具？

2.1 三角核心：LangChain + Groq + Streamlit

这套项目的技术选型非常务实，可以用一句话概括：用 Streamlit 快速搭界面，LangChain 编排 LLM 工作流，Groq 提供高速推理底座。

Streamlit 是这个技术栈中最「前台」的部分。它是 Python 生态中最流行的数据应用框架，允许开发者用纯 Python 代码（几乎不需要前端知识）快速构建带交互界面的 Web 应用。对独立开发者来说，这意味着不需要雇佣前端工程师，一个人就能把 AI 能力「包装」成一个可分享的产品。

在 AI Experiments Suite 中，Streamlit 承担了几乎所有的 UI 层职责：Chatbot 对话界面、PDF 文件上传、侧边栏参数配置、结果展示等。以 HR Application（简历与职位描述分析）为例，用户上传 JD（职位描述）和 CV（简历）两个 PDF 文件，后端用 PyMuPDF 提取文本，再调用 LLM 进行匹配度评分，整个过程在 Streamlit 的 chat_message UI 中以流式输出呈现。

LangChain 是连接层，也是这个项目中技术含量最高的部分。Vivek 大量使用了 LangChain 的核心组件：ChatPromptTemplate 定义提示词模板，RunnablePassthrough 传递上下文变量，StrOutputParser 解析 LLM 输出，以及最重要的——LCEL（LangChain Expression Language）管道语法，将多个步骤串联成一个可执行的 Chain。

以 SQL Chatbot 为例，这是一个将自然语言转换为 SQL 查询的工具。用户输入「哪些订单金额超过1000元的客户？」，这个请求会经过以下流程：

用户问题 → 获取数据库 Schema → 拼入 Prompt 模板 → 发送给 Groq LLM → 解析为 SQL → 执行 SQL → 将结果拼入响应 Prompt → 再次调用 LLM → 自然语言回答

这个流程在 LangChain 中被优雅地表达为：

full_chain = (
    RunnablePassthrough.assign(query=sql_chain)
    .assign(
        schema=get_schema,
        response=lambda x: run_query(x["query"]),
    )
    | prompt_response
    | llm
    | StrOutputParser()
)

这就是 LangChain 的魅力所在——它把一个多步骤的 AI 工作流，变成了像管道一样可组合、可调试的代码。相比自己写一堆 if-else 和函数调用，LangChain 让这个过程变得声明式、可复用。

Groq 是推理底座。选择 Groq 而不是 OpenAI 或 Anthropic，是这个项目的一个有趣决策。Groq 的 LPU（Language Processing Unit）芯片主打低延迟推理，在某些场景下响应速度明显快于传统云服务。更重要的是，Groq 提供了免费 tier，对独立开发者和小团队来说成本可控。项目中使用的模型是 llama-3.3-70b-versatile，在 Groq 的加速下，跑起来的体验相当流畅。

不过，Groq 的劣势也很明显：生态不如 OpenAI 丰富，API 稳定性偶尔有问题，模型版本更新节奏也不如主流平台快。所以项目中也预留了切换到 OpenAI 的选项——在 Travel Agent 等项目中，用户可以选择用 Groq 或 OpenAI 作为 LLM 底座。

2.2 子项目技术细节

AI Experiments Suite 不是一个大一统的单体项目，而是 9 个相对独立的子项目，每个子项目解决一个具体问题：

子项目	核心功能	技术亮点
SQL Chatbot	自然语言 → SQL → 自然语言回答	LangChain + SQLDatabase，Schema-aware
HR Application	JD/CV 匹配度分析	PyMuPDF 提取 PDF，Groq LLM 评分
Travel Agent	个性化旅行规划	多 Agent 协作（Tavily/SerpApi 搜索）
E-commerce Shopping Assistant	产品搜索、比价、图片搜索	Groq + Tavily + Firecrawl 多工具链
Learning Coach ThinkTool	个性化学习路径	Agent 架构，streamlit_ui + agents 模块化
MCP (Model Context Protocol)	LLM 数据库交互协议	MCP 标准协议实现，支持多种数据库
MCP SQL Chatbot & Dashboard	SQL 对话 + 可视化仪表盘	MCP + Tailwind CSS 响应式仪表盘
Prompt Caching	LLM 响应缓存优化	Redis/本地缓存，降低 API 成本
Storybook CrewAI	多 Agent 协作故事生成	CrewAI 多智能体框架，协同创作

其中有几个子项目值得特别关注：

Travel Agent 是整个套件中架构最复杂的项目。它采用了多 Agent 协作模式：一个 TripConversationAgent 负责理解用户意图（出发地、目的地、人数、预算、特殊需求），然后 ItenaryGeneratorWorkflow 调度多个子 Agent 分别查询航班、酒店、景点、餐饮信息，最后汇总成一份结构化的旅行行程。所有外部搜索都通过 Tavily 或 SerpApi API 实时抓取，确保信息的时效性。

E-commerce Shopping Assistant 则引入了 Firecrawl——一个新兴的网页抓取工具。相比传统的 BeautifulSoup + Selenium 方案，Firecrawl 可以直接爬取 SPA（单页应用）和 JavaScript 渲染的电商页面，大幅降低了爬虫开发成本。这是 2025 年 AI 应用开发的一个新趋势：AI 不仅在「思考」层面变得更强，也在「感知」层面（网页抓取、API 调用）获得了更趁手的工具。

2.3 依赖管理：uv 的引入

值得注意的是，部分较新的子项目（Learning Coach、MCP Agent Experiment、Storybook CrewAI）使用了 uv 作为依赖管理工具。uv 是 Rust 编写的 Python 包管理器，安装速度比 pip 快 10-100 倍，在 2025 年已经从小众工具变成了很多 Python 项目的首选。

从 uv.lock 文件的存在可以推断，这些项目已经完成了依赖锁定的规范化操作。pyproject.toml 作为项目元数据声明文件，uv.lock 保证每次安装的依赖版本完全一致——这是一个健康的工程实践，说明项目维护者对代码质量有一定追求。

---

三、深度功能解析：每个子项目怎么工作的？

3.1 SQL Chatbot：把数据库变成会说话的助手

SQL Chatbot 解决的是非技术人员查询数据库的问题。在企业中，运营、产品、市场等角色经常需要从数据库中提取数据，但 SQL 语法对他们来说是一道门槛。传统解决方案是让工程师写脚本或建报表系统，但响应速度慢、灵活性差。

SQL Chatbot 的方案是：用户说人话，AI 翻译成 SQL，执行，返回结果，再翻译成人话。整个流程的关键在于 Schema-aware 提示词设计：

基于以下表结构，写一个能回答用户问题的 SQL 查询：
{schema}

用户问题：{question}

通过 db.get_table_info() 获取数据库的完整 Schema（表名、字段、类型、关系），将其注入 Prompt，让 LLM 在生成 SQL 时「看到」数据库的结构。这避免了 LLM 瞎编表名或字段名的常见问题。

3.2 HR Application：简历筛选的 AI 助手

HR Application 有两种工作模式：Hiring（招聘方） 和 Candidate（候选人）。

在招聘模式下，用户上传职位描述（JD）和候选人简历（CV）两个 PDF，AI 会分析简历与职位的匹配度，给出一个 0-100 的评分，以及具体的匹配理由和待改进点。

在候选人模式下，AI 会针对简历中与 JD 不匹配的段落给出具体建议——比如「你的简历缺少 XX 项目经验，建议补充」。

这个应用的核心挑战在于多文档理解：PDF 提取需要处理各种格式（扫描件、表格、图片嵌入文字），LLM 需要理解两个长文档之间的语义关联。这是一个典型的 RAG（Retrieval-Augmented Generation）应用雏形。

3.3 Travel Agent：从「我想去玩」到完整行程

Travel Agent 是整个套件中最「Smart」的项目。它的对话流程大致如下：

第一步：意图提取。用户说「我想带孩子去成都玩3天，预算5000」，TripConversationAgent 会提取结构化参数：目的地=成都、人数=3（含儿童）、天数=3、预算=$5000。如果参数不全，会追问（「您计划几号出发？」）。

第二步：查询增强。有了结构化参数后，ItenaryGeneratorWorkflow 启动多个并行的 Web 搜索任务：查询成都三日游经典路线、查找适合亲子的酒店、获取航班价格区间、搜索必吃美食和景点门票价格。所有搜索都通过 Tavily 或 SerpApi API 完成。

第三步：行程生成。将搜索结果汇总后，LLM 会综合考虑用户偏好（亲子、预算、美食偏好等），生成一份详细的每日行程，包含：景点推荐 + 开放时间 + 门票、交通路线、餐饮建议、住宿选择。

第四步：多轮对话修正。用户可以对行程提出修改意见（「第二天不要去熊猫基地，换成武侯祠」），Agent 会理解变更意图，局部更新行程，保留其他已确认的内容。

这个流程体现了 Agentic AI 的核心特征：多步骤规划、外部工具调用、上下文记忆、多轮修正。Travel Agent 虽然没有用专门的 Agent 框架（如 LangChain Agents 或 CrewAI），而是用 LangChain 的 Chain 手工编排了一个近似 Agent 的流程，但在实际效果上已经具备了相当程度的自主性。

3.4 MCP 协议：让 LLM 安全地操作数据库

MCP（Model Context Protocol） 是这个项目中一个值得关注的技术探索。MCP 是一个让 LLM 与外部工具（特别是数据库）安全交互的协议标准。

在传统的 LangChain SQL Agent 中，LLM 生成的 SQL 是直接执行的——如果 LLM 被诱导执行危险操作，后果不堪设想。MCP 通过一个中间协议层，对 LLM 发出的「工具调用请求」进行校验和限制：LLM 只能调用 MCP Server 暴露的、受限的工具（如 get_schema、execute_query），而无法直接执行任意 SQL。

Vivek 的 MCP 实现还支持多种数据库类型（MySQL、SQLite 等），并通过标准化的协议接口，让不同的 LLM 都能以统一的方式与数据库交互。这是 2025 年 AI 工具化基础设施的一个有趣方向。

---

四、部署体验：一个人能跑起来吗？

4.1 部署流程

AI Experiments Suite 的部署非常直接：

# 克隆仓库
git clone https://github.com/vivekpathania/ai-experiments.git
cd ai-experiments

# 进入子项目目录
cd sqlchatbot  # 或 hrapp, travel-agent 等

# 安装依赖（uv 或 pip）
uv sync
pip install -r requirements.txt

# 配置环境变量
cp .env.example .env
# 编辑 .env，填入 GROQ_API_KEY 等

# 启动
streamlit run app.py

整个过程不需要 Docker，不需要 Kubernetes，不需要云服务商。只要有一台能跑 Python 3.9+ 的电脑，加上一个 Groq API Key，10-15 分钟内就能跑起来。

4.2 依赖配置复杂度

不过，「简单」也是相对的。项目中涉及的外部 API Key 包括：

• Groq API Key（必须）：用于 LLM 推理
• Tavily API Key（部分子项目）：用于 Web 搜索
• SerpApi Key（部分子项目）：替代 Tavily 的搜索后端
• OpenAI API Key（部分子项目可选）：作为 Groq 的替代
• Firecrawl API Key（电商助手）：用于网页抓取
• 数据库 URI（SQL Chatbot）：MySQL/SQLite 连接字符串

对于普通用户来说，管理这么多 API Key 是一个门槛。更理想的设计是将这些 Key 统一配置在 .env 文件中，通过 Streamlit 的 secrets 或环境变量注入。项目中确实也这样做了（.env.example 模板存在），但实际使用中偶尔会遇到 Key 配置错误导致的报错信息，对非技术用户不够友好。

4.3 硬件需求

得益于 Groq API 的远程推理架构，所有子项目都不需要本地 GPU。实测在 4GB RAM + 4 核 CPU 的虚拟机上，各子项目运行流畅，Groq LLM 的响应延迟在 1-3 秒（取决于查询复杂度）。

4.4 容器化支持

目前根目录没有 Dockerfile，这是一个比较明显的短板。对于希望将应用容器化部署到云服务（Vercel、Railway、Render 等）的用户来说，需要自己编写 Dockerfile 或使用 Cloudflare Pages + Streamlit 官方镜像。

考虑到项目本身是「AI Experiments」的定位——强调快速迭代和实验性质——缺少 Dockerfile 也许是刻意的选择：保持轻量，鼓励 fork 和修改，而不是一键部署后就不管了。如果未来项目成熟，作者很可能会补充容器化支持。

---

五、代码质量评估

5.1 架构设计

整个项目的代码结构采用了**「Monorepo + 子目录独立应用」**的架构：一个仓库包含 9 个子项目，每个子项目是独立可运行的 Streamlit 应用。这种设计的好处是：共享一部分底层代码（如 prompts.py、scripts.py），同时保持子项目的松耦合。

具体来看，各子项目的代码组织有差异：

• 较成熟的子项目（Travel Agent、HR App）：有明确的模块划分（app.py 负责 UI，workflow.py/scripts.py 负责业务逻辑，instructions.py 负责提示词模板），代码可读性良好。
• 较早期的子项目（SQL Chatbot）：代码相对简单，所有逻辑集中在一个文件中，适合学习但不适合大规模扩展。

5.2 LangChain 使用方式

Vivek 对 LangChain 的使用属于中高级水平。他熟练运用了：

• LCEL 管道语法（RunnablePassthrough、PromptTemplate、LLM、OutputParser 串联）
• Chain 的 .assign() 方法实现条件分支
• 环境变量注入 API Key（而不硬编码）
• ChatPromptTemplate 的多角色消息（System/User/Assistant）

但也有一些可以改进的地方：

• 错误处理不够健壮：部分子项目的 run_query 函数在 SQL 执行失败时只是返回错误字符串，没有区分不同情况
• 缺少流式输出：大多数应用等待 LLM 完全生成后才显示结果
• 缺少重试机制：API 调用失败时没有自动重试逻辑

5.3 文档质量

项目 README 写得很清晰，每个子项目都有独立的 README.md，包含功能描述、技术要点和使用说明。不过，缺少 API 文档和部署文档是一个遗憾。

---

六、局限性与挑战

6.1 多 Agent 协作的脆弱性

Travel Agent 和 E-commerce Shopping Assistant 涉及多 Agent 协作——当外部 API（Tavily/SerpApi）响应慢或返回无关结果时，整个流程的输出质量会明显下降。这不是 Vivek 代码的问题，而是 2025 年所有 AI 应用面临的共同挑战：LLM 的「思维链」再强，也依赖外部数据的质量。

6.2 安全风险

SQL Chatbot 允许用户通过自然语言执行 SQL 查询，这是一个固有的安全风险。在生产环境中，必须配合数据库权限控制（如只读用户、查询超时）使用，而不仅仅是依赖 LLM 的「道德判断」。

6.3 API 依赖性

所有子项目都依赖 Groq API 和各种搜索 API。这意味着如果 Groq 服务宕机，所有应用都无法使用。一个务实的建议是：对于核心功能，生产部署时应该考虑接入多个 LLM 供应商（Groq + OpenAI + Anthropic），通过简单的配置切换避免单点故障。

6.4 缺少测试

从代码仓库来看，没有发现测试文件（pytest/unittest）。这对于一个「AI Experiments」项目来说是可接受的——实验性项目强调快速迭代，测试会增加维护负担。但随着项目走向成熟，补齐测试套件是必要的一步。

---

七、行业意义：独立开发者的 AI 应用范式

7.1 「Prompt Engineer」到「AI Application Builder」的转变

AI Experiments Suite 代表的不是某个具体算法的突破，而是一种 AI 应用开发范式的确立：在 LLM API 能力已经足够强大的 2025 年，核心竞争不再是「谁能把模型调得更好」，而是**「谁能更高效地把 AI 能力组装成用户真正需要的产品」**。

Vivek 的项目没有训练自己的模型，没有做 RLHF，甚至没有微调 LoRA。他做的事情本质上是：Prompt Engineering + 工作流编排 + 界面包装。这给独立开发者和小型团队传递了一个重要信号：不需要百亿参数的大模型，不需要千卡的 GPU 集群，用 Groq + LangChain + Streamlit，一个人就能做出有价值的产品。

7.2 LangChain 的成熟度验证

LangChain 曾经因为 API 频繁变更、文档不完善而被诟病。但在 2025 年，LangChain 已经大幅成熟。AI Experiments Suite 使用 LangChain 构建了 SQL 查询、PDF 分析、多 Agent 协作等复杂工作流，代码的简洁性和可维护性都达到了生产可用水平。

特别是 LCEL（LangChain Expression Language） 的引入，让多步骤 AI 流程的代码变得像数学公式一样清晰。这种「声明式」的设计哲学，是 LangChain 在竞争中站稳脚跟的关键。

7.3 多 Agent 协作的趋势

在 Storybook CrewAI 子项目中，Vivek 引入了 CrewAI 框架——一个专门用于多 Agent 协作的框架。CrewAI 让多个 AI Agent 扮演不同角色（如「作家」「编辑」「校对」），协同完成复杂任务。

这代表了 2025 年 AI 应用的一个前沿方向：单 Agent → 多 Agent 协作。当一个 Agent 无法独立完成复杂任务时，可以引入多个专业化 Agent，每个 Agent 负责一个子任务，通过协作完成整体目标。

7.4 Star 增长与社区活跃度

截至分析时，AI Experiments Suite 已获得 173 star，在 GitHub 的 AI 实验项目中属于中等水平。考虑到项目上线时间较短（2025年2月），且作者 Vivek 是一名独立开发者（非全职开源维护），这个增长速度是健康的。

项目的 fork 数与 star 数比例反映了较高的复用价值——有相当数量的开发者 fork 了该项目进行二次开发或学习参考。Issue 区有一些功能请求和 bug 报告，但整体活跃度不高，说明项目处于「持续维护但不爆炸增长」的稳定状态。

---

八、总结与建议

核心价值

AI Experiments Suite 是一个高质量的 LangChain + Groq + Streamlit 应用合集，它证明了独立开发者可以用最少的资源（Python + API Key），快速搭建出真正能解决实际问题的 AI 应用。9 个子项目覆盖了 NLP、数据库、多 Agent 协作等多个维度，每个子项目都可以独立运行或作为学习素材。

适用人群

• 独立开发者：想快速验证 AI 应用想法，直接 fork 子项目修改
• AI 学习者：学习 LangChain LCEL 语法、Chain 编排、多 Agent 协作
• 产品经理：了解 AI 能力边界，找到可以落地的垂直场景
• 中小企业：快速部署 HR 筛选、SQL 查询等内部工具

不适合的场景

• 需要严格数据安全的企业环境（涉及 API Key 和数据外传）
• 需要高并发、大规模部署的生产系统
• 完全离线的无网环境

改进建议

1. 补充 Dockerfile：添加官方的 Streamlit + Python 镜像配置，方便一键容器化部署
2. 增加流式输出：使用 LangChain 的 stream() 方法，提升对话体验
3. 健壮错误处理：区分不同类型的错误（API 超时、SQL 语法错误、权限问题），给出不同的用户提示
4. 补齐测试套件：用 pytest + pytest-asyncio 覆盖核心 Chain 逻辑
5. 添加 API 文档：用 FastAPI 包装核心功能，方便其他系统集成

---

本报告基于 GitHub 仓库 vivekpathania/ai-experiments 的公开代码和文档生成，分析日期：2025年中期。