LangChain多智能体实战：用Streamlit快速搭建婚礼策划师

这次我们来看一个非常贴合实战的 LangChain 多智能体项目：婚礼策划师。它不玩概念，而是把 Python、LangChain、Streamlit 完整串起来，用多个智能体分工完成一套婚礼方案的策划。你可以把它当成多智能体架构的入门练手项目，也可以基于这套骨架去扩展自己的垂直应用。

这个项目最值得关注的点有两个。第一，它不是单个 Prompt 直接输出结果，而是让不同角色的智能体分别负责预算、场地、菜单、流程，最后合成一份完整方案，能真实感受到多智能体的协作方式。第二，它用 Streamlit 做 Web 界面，不需要自己写前端，启动以后像填表单一样操作，适合快速演示和二次开发。

本文会用一套完整的部署思路来拆解：从环境准备、智能体编排、Streamlit 界面、功能测试、API 封装到批量任务，全部跑通。硬件方面，这个项目不依赖本地 GPU，推理在远端大模型 API 完成，普通笔记本就能跑，显存占用约等于零。

1. 核心能力速览

这个表格的边界要从两个方向理解：硬件要求低是这类“本地编排 + 远端推理”项目的通用特征；具体的模型名、API 地址、token 消耗则要根据你使用的模型服务商来定。

2. 多智能体婚礼策划师架构设计

先讲架构，再讲代码，这样往下读的时候不会乱。

婚礼策划天然适合多智能体拆分。一场婚礼涉及预算、场地、餐饮、流程、风格五个维度，任何一个环节单独写进一个 Prompt 都会变糊。拆成多个智能体以后，每个智能体只干一件事，结果更容易控制。

一个经典的分工模型如下：

在 LangChain 里实现这种协作有两种主流方式。

一种是 LangChain AgentExecutor 搭配 Tool，把预算智能体、场地智能体、菜单智能体封装成工具，由主管智能体决定何时调用哪个工具。这种方式实现简单，适合教学，也是本文示例采用的方式。

另一种是用 LangGraph 的 StateGraph，把每个智能体定义为一个节点，用状态对象在节点之间传递数据。LangGraph 的好处是可编程地控制流程分支，调试更直观，适合生产级应用。两者的差异点在于：LangChain AgentExecutor 的编排逻辑更偏“模型自主决策”，LangGraph 则允许你显式画出状态流转图，对流程可控性要求高的场景更合适。

3. 适用场景与使用边界

这个项目适合三类人。

第一类是刚接触 LangChain 的开发者。只看官方文档容易绕晕，直接跑一个多智能体 Demo，能更快理解 Agent、Tool、Prompt 之间的关系。

第二类是想做垂直应用的工程师。婚礼策划只是壳，把智能体换成“活动策划师”“装修顾问”，同一套架构可以直接复用。

第三类是产品经理或运营，想验证“多智能体能给业务带来什么”。用 Streamlit 界面演示给团队看，比 PPT 更有说服力。

边界也要说清楚。

套餐推荐、价格区间这类输出本质上是模型基于常识生成的参考信息，不能当作真实商家报价。如果要接入真实场地、真实菜单，需要额外加数据源，比如本地数据库、第三方 API 或 RAG 检索。

隐私方面，婚礼策划会涉及宾客名单、预算、日期等敏感信息。如果你把数据发送给第三方大模型 API，需要确认服务商的隐私政策，并进行必要的脱敏处理。

合规方面，如果后续从“生成方案”扩展为“自动订酒店”“自动联系商家”，必须接入真实服务商的合规接口，并征求用户明确授权。

4. 环境准备与前置条件

先列一套通用环境检查清单，不同系统下稍有差异，但思路一致。

• 操作系统：Windows 10/11、macOS、Linux 均可。
• Python：建议 3.9 或更高版本，64 位。
• 包管理：pip 或 conda。
• 模型 API：需要一个支持 OpenAI 兼容接口的大模型服务，并准备好 API Key。
• 磁盘空间：项目本身很小，安装依赖后约 2-3GB，主要是 Python 包占用。
• 端口：Streamlit 默认 8501，如果被占用会自动递增或需要手动指定。

确认 Python 版本：

python --version

建议新建独立虚拟环境，避免和系统 Python 包冲突：

python -m venv .venv # Windows .venv\Scripts\activate # macOS/Linux source .venv/bin/activate

然后安装依赖：

pip install langchain langchain-core langchain-openai streamlit python-dotenv

如果你的 LangChain 版本较新，可能需要按实际的包名安装。比如langchain-openai用来接 OpenAI 风格接口，langchain-anthropic用来接 Claude。安装完以后可以用pip list看版本：

pip list | grep langchain pip list | grep streamlit

创建.env文件保存 API Key，注意不要提交到 Git：

OPENAI_API_KEY=your-api-key-here OPENAI_API_BASE=https://your-api-endpoint MODEL_NAME=gpt-4o-mini

如果你的模型服务使用自定义接口地址，需要把OPENAI_API_BASE指到对应地址，并确认接口兼容 OpenAI 的/chat/completions格式。

5. 安装部署与启动方式

依赖装好、环境变量配好之后，项目的核心文件通常有这几个：

wedding-planner/ ├── app.py # Streamlit 前端入口 ├── agents.py # 多智能体编排逻辑 ├── prompts.py # 各智能体提示词 ├── requirements.txt # 依赖清单 └── .env # API Key 配置

先写一个最小的requirements.txt：

langchain>=0.2.0 langchain-openai>=0.1.0 streamlit>=1.30.0 python-dotenv>=1.0.0

安装依赖：

pip install -r requirements.txt

启动 Streamlit 前端：

streamlit run app.py --server.port 8501

启动后终端会输出本地访问地址。浏览器打开http://localhost:8501，看到页面说明服务已经起来了。端口冲突时可以换端口：

streamlit run app.py --server.port 8600

这里要注意：Streamlit 默认有 CORS 和 XSRF 保护，本地调试通常不用改。如果要让局域网内其他设备访问，可以加--server.address 0.0.0.0，但要确认网络安全边界，不要随意暴露到公网。

6. 核心代码实现

这一节直接给核心代码模板。项目规模不大，代码量不需要很多，关键是理解多智能体怎么协作。

6.1 定义各智能体工具

在agents.py里，先定义几个工具函数，每个函数对应一个专业智能体。

# agents.py from langchain_core.tools import tool from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_openai_functions_agent from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder llm = ChatOpenAI( model="gpt-4o-mini", temperature=0.3, ) @tool def budget_planner(total_budget: int, guest_count: int) -> str: """根据总预算和宾客人数，生成婚礼预算分配方案。""" # 这里可以先做规则兜底，比如人均费用估算 # 也可以直接把参数交给 LLM 生成详细分配表 prompt = f"总预算 {total_budget} 元，宾客 {guest_count} 人，请给出预算分配方案。" return llm.invoke(prompt).content @tool def venue_recommender(city: str, guest_count: int, style: str) -> str: """根据城市、宾客人数和婚礼风格，推荐合适的酒店或场地。""" prompt = f"在{city}，宾客{guest_count}人，风格{style}，推荐3个婚礼场地并说明价格区间。" return llm.invoke(prompt).content @tool def menu_advisor(guest_count: int, budget: int, dietary: str = "") -> str: """根据人数、预算和饮食禁忌，推荐婚礼菜单。""" prompt = f"宾客{guest_count}人，餐饮预算{budget}元，饮食禁忌{dietary}，推荐一份菜单。" return llm.invoke(prompt).content @tool def timeline_generator(ceremony_time: str, style: str) -> str: """根据仪式开始时间和风格，生成婚礼当天流程时间线。""" prompt = f"仪式开始时间{ceremony_time}，风格{style}，生成一份完整婚礼时间线。" return llm.invoke(prompt).content

可以看到，每个工具内部就是一段带上下文的 Prompt 调用。这样做的好处是方便替换：如果某个智能体要接真实数据，把工具内部的llm.invoke换成数据库查询或第三方接口即可。

6.2 主管智能体编排

主管智能体要能识别用户意图，并把任务分发给上面的工具。

# agents.py prompt = ChatPromptTemplate.from_messages([ ("system", "你是一名婚礼策划主管，负责拆解用户需求并调用专业工具。"), MessagesPlaceholder(variable_name="chat_history"), ("human", "{input}"), MessagesPlaceholder(variable_name="agent_scratchpad"), ]) tools = [budget_planner, venue_recommender, menu_advisor, timeline_generator] agent = create_openai_functions_agent(llm, tools, prompt) executor = AgentExecutor( agent=agent, tools=tools, max_iterations=5, verbose=True, ) def run_wedding_planner(query: str) -> str: """供 Streamlit 或 API 调用的统一入口""" result = executor.invoke({"input": query, "chat_history": []}) return result["output"]

max_iterations=5很关键。多智能体场景下，模型偶尔会反复调用同一个工具，设置上限可以防止死循环和 token 浪费。

6.3 Streamlit 前端

app.py尽量做到薄：只负责收集用户输入，调用后端函数，展示结果。

# app.py import os import streamlit as st from dotenv import load_dotenv from agents import run_wedding_planner load_dotenv() st.set_page_config(page_title="LangChain 多智能体婚礼策划师", layout="wide") st.title("LangChain 多智能体婚礼策划师") with st.sidebar: st.header("策划参数") total_budget = st.number_input("总预算（元）", min_value=10000, value=100000, step=5000) guest_count = st.number_input("宾客人数", min_value=10, value=100, step=10) city = st.text_input("城市", value="杭州") style = st.selectbox("婚礼风格", ["户外草坪", "欧式教堂", "中式传统", "极简现代"]) dietary = st.text_input("饮食禁忌", value="无") ceremony_time = st.text_input("仪式开始时间", value="16:30") run_btn = st.button("生成婚礼方案") if run_btn: query = ( f"请帮我策划一场婚礼：总预算{total_budget}元，宾客{guest_count}人，" f"城市{city}，风格{style}，饮食禁忌{dietary}，仪式开始时间{ceremony_time}。" ) with st.spinner("多个智能体正在协同策划，请稍候..."): result = run_wedding_planner(query) st.markdown("## 完整方案") st.write(result)

这样跑起来以后，侧边栏输入参数，点击按钮，就能看到多个智能体协作的结果。因为verbose=True，终端里还能看到主管智能体依次调用了哪些工具，非常适合教学演示。

7. 功能测试与效果验证

部署和代码都有了，接下来要验证它到底能不能正常协作。

7.1 启动服务验证

先确认 Streamlit 服务能正常启动。启动命令：

streamlit run app.py

启动后终端出现You can now view your Streamlit app说明前端正常。如果启动直接报错，优先检查依赖是否装全。

7.2 单智能体工具测试

在 Streamlit 界面点按钮之前，建议先用 Python 脚本单独测每个工具，避免问题都堆到界面层。

# test_tools.py from agents import budget_planner, venue_recommender, menu_advisor, timeline_generator print(budget_planner(50000, 50))

执行：

python test_tools.py

这一步能验证 API Key、模型调用、工具函数链是否正常。如果这里就报错，不需要继续测界面。

7.3 多智能体协作测试

用最小参数跑一次主管智能体：

from agents import run_wedding_planner query = "在杭州办一场100人户外婚礼，总预算10万元，帮我生成完整方案。" result = run_wedding_planner(query) print(result)

判断成功的标准有三个：

• 输出包含预算分配、场地建议、菜单、时间线等结构化信息。
• 终端日志显示主管智能体实际调用了多个工具，而不是一次性生成全文。
• 输出在 30-60 秒内返回，没有超时或死循环。

如果输出没有调用工具，说明模型没有识别出工具调用场景。可以检查 Prompt 是否写清楚，或换一个工具调用能力强一些的模型。

7.4 异常输入测试

再测试极端输入：

• 预算 1 万元、宾客 500 人的矛盾场景。
• 城市填空字符串。
• 非常规风格名。

测试目的不是追求输出正确，而是看系统是否稳定，有没有异常崩溃。对于明显矛盾的需求，主管智能体如果能主动提示“预算不足以支撑 500 人”，说明 Prompt 和模型表现都不错。

8. 接口 API 与批量任务扩展

Streamlit 适合交互演示，如果要把这套多智能体能力接进其他系统，最好把核心逻辑封装成 API。

8.1 FastAPI 封装

新建api.py：

# api.py from fastapi import FastAPI from pydantic import BaseModel from agents import run_wedding_planner app = FastAPI() class WeddingRequest(BaseModel): query: str class WeddingResponse(BaseModel): output: str @app.post("/plan", response_model=WeddingResponse) def plan_wedding(req: WeddingRequest): output = run_wedding_planner(req.query) return WeddingResponse(output=output)

启动 API：

uvicorn api:app --host 127.0.0.1 --port 8000

调用示例：

curl -X POST http://127.0.0.1:8000/plan \ -H "Content-Type: application/json" \ -d '{"query": "在杭州办一场100人户外婚礼，预算10万"}'

8.2 Python 调用示例

import requests url = "http://127.0.0.1:8000/plan" payload = {"query": "在杭州办一场100人户外婚礼，预算10万"} resp = requests.post(url, json=payload, timeout=120) print(resp.json())

8.3 批量任务设计

如果要批量测试多种预算方案，可以写一个脚本，循环读取参数并调用策划函数：

# batch_planner.py import json from agents import run_wedding_planner cases = [ {"query": "杭州，50人，预算5万，简约风"}, {"query": "上海，200人，预算30万，欧式"}, {"query": "成都，80人，预算12万，中式"}, ] results = [] for case in cases: print(f"正在处理: {case['query']}") output = run_wedding_planner(case["query"]) results.append({"query": case["query"], "output": output}) with open("wedding_plans.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2)

批量任务必须加日志和失败重试。真实场景里，一次调 100 个请求很可能因为 API 限流而失败，建议每次请求之间加时间间隔，或者引入重试机制。下面是一个带重试的简化版：

import time import random def call_with_retry(query, max_retry=3): for i in range(max_retry): try: return run_wedding_planner(query) except Exception as e: print(f"第{i+1}次失败: {e}") if i == max_retry - 1: raise time.sleep(random.uniform(2, 5))

9. 资源占用与性能观察

这个项目的计算主要在远端模型 API，本机只承担 Python 进程、Streamlit 服务和网络请求，所以性能观察重点不在显存，而在以下几项：

• 内存：Python 解释器 + Streamlit 服务，通常在几百 MB 以内，不会成为瓶颈。
• CPU：本地不跑模型，CPU 占用主要来自依赖库初始化，运行过程中很低。
• 网络延迟：一次完整策划需要多次 LLM 调用，实际等待时间取决于模型接口速度。
• Token 消耗：每次调用会产生 Prompt 和 Completion 两部分的 token 费用，多智能体调用次数多，建议在代码里记录每次调用的 token 数，便于估算成本。

如果要降低响应时间，可以用更轻量、速度更快的模型，或者把工具内部的多步调用改成并行。例如预算、场地、菜单这三个智能体之间没有强依赖，可以在主管智能体拿到任务后，用 Python 的ThreadPoolExecutor并行调用，最后再汇总。

并行调用的一个示例思路：

from concurrent.futures import ThreadPoolExecutor def run_parallel_tools(tasks): with ThreadPoolExecutor(max_workers=3) as executor: return list(executor.map(lambda fn: fn, tasks))

需要注意，并行调用会同时消耗多个 API 请求，需要确认模型服务商的限流策略。

10. 常见问题与排查方法

多智能体 + Streamlit 的排查链路不复杂，按照“环境 -> 单工具 -> 编排 -> 界面”的顺序查，一般能很快定位问题。

11. 最佳实践与使用建议

多智能体应用容易“Demo 五分钟，上线两小时”，想稳定用起来，建议从下面几点入手。

第一，第一次运行先用最小参数测试。不要一上来就做 200 人的完整方案，先用 10 人、1 万元、极简风格的组合，验证链路通不通。

第二，保留一套最小可运行配置。把经过验证的 Python 版本、依赖版本、模型名称记录在requirements.txt和 README 里，避免换环境后找不到原因。

第三，输入素材、输出结果分目录管理。这个项目的“素材”主要是测试用例和生成的方案，建议用inputs/、outputs/分开存放，批量任务脚本每次生成带时间戳的目录。

第四，API Key 要安全保存。使用环境变量或.env，不要硬编码在代码里，更不要提交到公开 Git 仓库。如果 Key 泄露，立即到平台吊销并重新生成。

第五，观察 token 消耗。多智能体相比单轮 Prompt 调用次数更多，成本更高。可以在代码中显式记录每次请求的 usage 数据，定期统计。

第六，确认输出内容合法性。方案中的商家推荐、预算数字均由模型生成，只是参考，不能代替真实报价。涉及真实婚礼的日期、宾客信息，要脱敏处理。

第七，涉及真实业务时，要把“模型自主决策”改成“模型建议 + 人工确认”。比如主管智能体给出场地方案后，由用户在界面上确认，再进入下一步，避免模型在关键决策上直接代替人。

12. 总结与下一步

这个项目最值得尝试的点，是它让你在一套完整应用中看到多智能体的价值：预算、场地、菜单、流程各自独立，又被主管智能体统一调度，最后形成一个可用方案。相比单个 Prompt 的“大而全”，这种分工输出的结果更清晰，也更接近真实项目里模块化组织的思路。

最先要验证的功能不是界面，而是单工具调用。先跑通budget_planner，再跑通主管智能体的完整编排。只要这条链路稳了，Streamlit 界面只是套壳。

最容易踩的坑有三个：一是 API Key 没加载成功，导致界面报错；二是模型不支持工具调用，导致主管智能体不调工具；三是没有设置max_iterations，导致 Agent 无限循环。这三个问题在日志里都能看到，关键是多看终端输出。

后续可以扩展的方向很明确：给每个智能体接入真实数据源，比如场地数据库、婚宴菜单库；用 LangGraph 重构编排层，把状态流转显式画出来；把方案输出改成结构化 JSON，方便业务系统对接；再加一层用户反馈，让多智能体根据用户修改意见二次调整方案。

如果只是学习多智能体架构，这套“Python + LangChain + Streamlit”的组合已经足够支撑你从概念到 Demo 走一遍。下一步选一个小场景，把这套模板改造成你自己的垂直应用，会是最好的练习方式。