这次我们来看一个非常贴合实战的 LangChain 多智能体项目婚礼策划师。它不玩概念而是把 Python、LangChain、Streamlit 完整串起来用多个智能体分工完成一套婚礼方案的策划。你可以把它当成多智能体架构的入门练手项目也可以基于这套骨架去扩展自己的垂直应用。这个项目最值得关注的点有两个。第一它不是单个 Prompt 直接输出结果而是让不同角色的智能体分别负责预算、场地、菜单、流程最后合成一份完整方案能真实感受到多智能体的协作方式。第二它用 Streamlit 做 Web 界面不需要自己写前端启动以后像填表单一样操作适合快速演示和二次开发。本文会用一套完整的部署思路来拆解从环境准备、智能体编排、Streamlit 界面、功能测试、API 封装到批量任务全部跑通。硬件方面这个项目不依赖本地 GPU推理在远端大模型 API 完成普通笔记本就能跑显存占用约等于零。1. 核心能力速览能力项说明项目类型LangChain 多智能体 Streamlit Web 应用技术栈Python、LangChain、LangChain Agent、Streamlit主要功能婚礼预算分配、场地推荐、风格设计、菜单建议、流程时间线生成硬件要求无 GPU 依赖普通 CPU 笔记本可运行显存占用不涉及本地推理约为 0启动方式streamlit run app.py命令启动是否支持 API支持可将策划逻辑封装为 FastAPI 服务是否支持批量任务支持通过脚本批量生成多套婚礼方案推荐模型需具备工具调用能力的 LLM如 GPT-4o mini、Claude 或其他兼容 API适合场景多智能体教学、方案生成工具、中型垂直应用原型这个表格的边界要从两个方向理解硬件要求低是这类“本地编排 远端推理”项目的通用特征具体的模型名、API 地址、token 消耗则要根据你使用的模型服务商来定。2. 多智能体婚礼策划师架构设计先讲架构再讲代码这样往下读的时候不会乱。婚礼策划天然适合多智能体拆分。一场婚礼涉及预算、场地、餐饮、流程、风格五个维度任何一个环节单独写进一个 Prompt 都会变糊。拆成多个智能体以后每个智能体只干一件事结果更容易控制。一个经典的分工模型如下智能体角色职责输入输出主管智能体接收用户需求拆分任务组织其他智能体预算、人数、城市、风格偏好结构化任务清单预算智能体根据总预算分配费用总预算、宾客人数预算分配表场地智能体根据城市、人数、风格推荐场地城市、人数、风格2-3 个场地建议及价格区间菜单智能体根据口味和预算推荐菜单人数、预算、饮食禁忌冷菜/热菜/甜品方案流程智能体生成婚礼当天时间线仪式时间、环节偏好分时段流程表汇总智能体合并各智能体结果生成完整策划书以上全部输出Markdown 或 JSON 方案在 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注意不要提交到 GitOPENAI_API_KEYyour-api-key-here OPENAI_API_BASEhttps://your-api-endpoint MODEL_NAMEgpt-4o-mini如果你的模型服务使用自定义接口地址需要把OPENAI_API_BASE指到对应地址并确认接口兼容 OpenAI 的/chat/completions格式。5. 安装部署与启动方式依赖装好、环境变量配好之后项目的核心文件通常有这几个wedding-planner/ ├── app.py # Streamlit 前端入口 ├── agents.py # 多智能体编排逻辑 ├── prompts.py # 各智能体提示词 ├── requirements.txt # 依赖清单 └── .env # API Key 配置先写一个最小的requirements.txtlangchain0.2.0 langchain-openai0.1.0 streamlit1.30.0 python-dotenv1.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( modelgpt-4o-mini, temperature0.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_namechat_history), (human, {input}), MessagesPlaceholder(variable_nameagent_scratchpad), ]) tools [budget_planner, venue_recommender, menu_advisor, timeline_generator] agent create_openai_functions_agent(llm, tools, prompt) executor AgentExecutor( agentagent, toolstools, max_iterations5, verboseTrue, ) def run_wedding_planner(query: str) - str: 供 Streamlit 或 API 调用的统一入口 result executor.invoke({input: query, chat_history: []}) return result[output]max_iterations5很关键。多智能体场景下模型偶尔会反复调用同一个工具设置上限可以防止死循环和 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_titleLangChain 多智能体婚礼策划师, layoutwide) st.title(LangChain 多智能体婚礼策划师) with st.sidebar: st.header(策划参数) total_budget st.number_input(总预算元, min_value10000, value100000, step5000) guest_count st.number_input(宾客人数, min_value10, value100, step10) city st.text_input(城市, value杭州) style st.selectbox(婚礼风格, [户外草坪, 欧式教堂, 中式传统, 极简现代]) dietary st.text_input(饮食禁忌, value无) ceremony_time st.text_input(仪式开始时间, value16: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)这样跑起来以后侧边栏输入参数点击按钮就能看到多个智能体协作的结果。因为verboseTrue终端里还能看到主管智能体依次调用了哪些工具非常适合教学演示。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_modelWeddingResponse) def plan_wedding(req: WeddingRequest): output run_wedding_planner(req.query) return WeddingResponse(outputoutput)启动 APIuvicorn 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, jsonpayload, timeout120) 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, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)批量任务必须加日志和失败重试。真实场景里一次调 100 个请求很可能因为 API 限流而失败建议每次请求之间加时间间隔或者引入重试机制。下面是一个带重试的简化版import time import random def call_with_retry(query, max_retry3): for i in range(max_retry): try: return run_wedding_planner(query) except Exception as e: print(f第{i1}次失败: {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_workers3) as executor: return list(executor.map(lambda fn: fn, tasks))需要注意并行调用会同时消耗多个 API 请求需要确认模型服务商的限流策略。10. 常见问题与排查方法多智能体 Streamlit 的排查链路不复杂按照“环境 - 单工具 - 编排 - 界面”的顺序查一般能很快定位问题。问题现象可能原因排查方式解决方案安装依赖时报错Python 版本过低或包版本冲突检查python --version和依赖列表升级 Python或使用虚拟环境重装依赖启动后页面打不开端口被占用或服务未启动查看终端日志检查 8501 端口更换端口streamlit run app.py --server.port 8600界面能打开但点击按钮无响应后端函数抛异常但前端没显示查看终端堆栈日志先把报错堆栈贴出来按异常类型定位API Key 配置无效.env文件路径不对或 Key 过期打印环境变量确认是否加载检查.env位置确认load_dotenv()已执行模型返回内容为空上下文过长被截断或模型不支持工具调用检查 API 返回日志确认模型版本换支持函数调用/工具调用的模型或精简 Prompt主管智能体不调用工具Prompt 表述不清或模型能力不足开启verboseTrue观察日志在 Prompt 中明确要求“必须调用工具”多智能体调用死循环缺少迭代上限查看日志是否反复调用同一工具设置max_iterations5或更小值局域网访问不了Streamlit 默认绑定 127.0.0.1检查启动参数用--server.address 0.0.0.0启动并确认网络安全API 调用超时模型响应慢或网络不佳用 curl 单独测试接口延迟增加timeout参数或换更快模型批量任务中途失败API 限流或网络抖动查看失败时的错误码加重试机制和日志记录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 走一遍。下一步选一个小场景把这套模板改造成你自己的垂直应用会是最好的练习方式。