做了一个求婚智能体起因其实很简单准备求婚那段时间我发现自己同时要搞定戒指预算、场地布置、亲友邀约、台词措辞、应急方案脑子完全不够用。翻遍攻略又发现答案太散每一篇都说得好像很对放到自己身上又不成立。于是干脆用业余时间搭了一个专门处理求婚全流程的 AI 智能体帮自己把“求婚”这件事从感性冲动拆成了可执行的项目。它现在可以生成策划方案、写求婚词、列倒计时清单、处理现场突发状况也能通过接口批量生成不同预算和场景下的方案。这篇文章就把这个智能体从需求拆解、平台搭建、Python 独立开发到接口调用、批量任务和排错经验完整写一遍。做这个项目的核心收获不在于求婚本身而在于“智能体怎么从聊天玩具变成能干活的工作流”。如果你正在做智能体开发或者想知道 Coze 这类平台搭建和 Python 自己构建到底差多少这篇文章可以直接参考。两种路线我都会写路线 A 用 Coze 工作流快速搭路线 B 用 Python LangChain 自己写 Agent 并封装 SSE 流式接口。贴上你的业务场景思路是一样的。1. 求婚智能体核心能力速览能力项说明项目类型垂直场景 AI 智能体覆盖文案、策划、任务管理、应急问答核心功能求婚策划、个性化求婚词、倒计时待办、突发状况建议、多方案批量生成开发路线 ACoze 平台搭建使用工作流、知识库、条件分支、API 发布开发路线 BPython LangChain 构建 ReAct AgentFastAPI 提供 SSE 接口硬件要求平台路线无需本地 GPUPython 路线用大模型 API普通开发机即可显存占用没有本地模型推理时几乎不占显存若接本地模型需按模型实际测试支持平台Web、API 均可Python 版可部署到服务器或本地启动方式平台版云端发布Python 版命令行启动 FastAPI是否支持 API支持均提供 HTTP 接口Python 版支持流式返回是否支持批量任务支持可批量生成不同预算、场景、风格的求婚方案适合场景个人筹备求婚、活动策划、文案工作者、智能体技术演示先明确一个边界本文不讨论“求婚后的事情”也不提供情感咨询。它解决的是信息整理、方案生成、任务拆解和文案输出这几类能用结构化方法处理的问题。涉及个人关系、隐私信息、场地授权、肖像使用等现实事务仍然需要真人确认和合规授权。2. 适用场景与使用边界2.1 适合谁用这个智能体的目标用户非常具体正在筹备求婚但缺乏系统思路的人需要快速生成文案与流程的人以及想把智能体开发跑通的开发者。在真实使用里它能回答这几类高频问题“预算 3000 元想在周末晚餐后求婚帮我想一个完整流程。”“写一段 60 秒的求婚词语气轻松一点不要土味情话。”“已经买好戒指离求婚还有 5 天帮我列清单。”“正在餐厅求婚戒指突然掉地上了该怎么圆场”智能体不是替代你做决定而是把模糊需求变成可执行内容减少你从零开始的信息检索和文案成本。2.2 不适合什么场景涉及真实感情决策时不建议完全依赖生成结果生成内容只作为参考。涉及对方喜好、家庭关系等隐私信息时不要把敏感个人信息直接传入公开 API。涉及商业用途的定制策划需要人工核验版权、肖像、场地授权不能拿生成结果直接商用。平台版的知识库内容来自公开资料整理不能替代专业婚庆公司的线下执行。2.3 合规与隐私提醒无论用平台版还是 Python 版都要注意数据边界。用户在对话中输入的求婚地点、对方姓名、亲友信息、预算金额都属于个人隐私。建议在系统提示词里明确告知“请勿提供真实身份证号、家庭住址、公司内部信息”本地运行时把日志脱敏接口服务限制访问来源。涉及人脸、声音或照片处理的功能如果后续扩展必须获得当事人授权确保内容合规。3. 搭建前的需求拆解与智能体架构设计智能体不能一开始就写代码。先拆用户需求再设计两条任务链路。3.1 将求婚诉求拆成可控子任务我把“求婚困扰”拆成四类子任务用户输入输出产物方案策划预算、时间、场景、偏好完整流程方案文案生成风格、时长、对象特征求婚词、朋友圈文案任务管理剩余天数、待办项倒计时清单应急问答现场突发状况应对建议每一类对应智能体里的一个子工作流而不是把所有逻辑塞进一个提示词。3.2 智能体架构设计统一架构如下用户输入 - 意图识别 - 条件路由 - 子任务处理 - 结果返回意图识别由大模型完成配置输出格式为 JSON字段包含 task_type 和 params。条件路由根据 task_type 分流到策划、文案、清单、应急四个处理单元。每个处理单元使用独立提示词模板可以单独调试。结果返回时统一包装成 Markdown 或 JSON方便前端渲染和 API 调用。这个架构在 Coze 平台用工作流节点实现在 Python 版里用 Agent 的 ReAct 循环实现。3.3 提示词模板示例求婚词生成提示词模板可以在两种路线中复用你是一位擅长策划惊喜活动的文案编辑。请根据以下参数生成一段求婚词 - 场景{scene} - 风格{style}温馨/浪漫/轻松/正式 - 时长目标{duration}秒 - 对象特征{partner_description} - 禁用内容土味情话、低俗比喻、身世夸张 输出要求 1. 第一句直接进入主题不要铺垫天气或时间。 2. 包含一个具体回忆点使用用户提供的真实细节如果没有则不虚构。 3. 结尾落到“你愿意嫁给我吗”不提前泄露。 4. 输出为纯文本不做多余解释。4. 环境准备与前置条件4.1 两条路线的环境对比路线环境语言/工具是否需要 GPUCoze 平台版浏览器访问平台无需本地依赖可视化工作流否Python 版Python 3.10pip 环境Python LangChain FastAPI否API 模式4.2 Python 版环境准备先确认 Python 版本python --version建议用虚拟环境隔离python -m venv .venv source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate安装依赖pip install fastapi uvicorn langchain langchain-openai python-dotenv大模型调用采用 OpenAI 兼容接口。因为本项目测试时使用兼容国内大模型服务的 OpenAI 格式地址所以只需要配置环境变量# .env 文件 OPENAI_API_KEYyour_api_key_here OPENAI_BASE_URLhttps://your-llm-endpoint/v1 OPENAI_MODEL_NAMEgpt-4o-mini LANGFCHAIN_TRACINGfalse如果没有兼容接口可以换成 LangChain 支持的其他模型提供商例如 DashScope、Moonshot 等只改 ChatOpenAI 的 base_url 和 api_key 即可。4.3 磁盘与端口检查Python 版需要约 500MB 空间安装依赖不含模型下载。如果后续接本地模型磁盘空间需按模型实际大小预留。启动 FastAPI 默认端口是 8000先检查端口lsof -i :8000 # macOS/Linux netstat -ano | findstr :8000 # Windows端口被占用时可以替换启动端口的参数uvicorn main:app --host 127.0.0.1 --port 80105. 路线 ACoze 平台搭建求婚智能体如果你没有编程基础或者想最快时间验证智能体效果直接走 Coze 平台路线。5.1 搭建智能体的基本步骤进入 Coze 平台创建智能体命名为“求婚智囊”。配置思路是“工作流优先”新建一个工作流命名为 proposal_workflow然后按照下面的节点顺序配置。节点作用关键配置开始节点接收用户输入参数message类型为 String意图识别节点将输入归类为策划/文案/清单/应急使用 LLM 节点输出 JSON条件分支节点按 task_type 分流四条分支策划子流程节点调用策划提示词模板传 budget、scene、style文案子流程节点调用求婚词生成模板传 style、duration、partner_description清单子流程节点生成倒计时待办传 days、items应急子流程节点返回场景应对建议传 emergency_desc结束节点统一返回 Markdown 结果拼接子流程输出5.2 意图识别节点提示词意图识别节点使用 LLM出参为 JSON{ task_type: planning | copywriting | checklist | emergency, params: {} }LLM 提示词你是求婚助手的路由模块。根据用户输入识别任务类型 - planning用户需要完整求婚方案 - copywriting用户需要求婚词或文案 - checklist用户需要待办清单 - emergency用户描述现场突发状况 只输出 JSON不要解释。5.3 知识库配置为策划子流程准备一个知识库上传公开渠道收集的求婚场景灵感、流程清单、常见错误案例。注意知识库内容不能包含用户隐私也不能包含可能侵权的策划方案。知识库的目的是给生成模型提供结构化背景而不是照搬某个人的真实求婚故事。5.4 发布与验证工作流跑通后发布。平台会生成 API 接口可以接入飞书机器人、微信客服或其他客户端。这里要提一句平台版适合快速验证但如果你的业务需要高度定制、数据完全私有、离线部署平台版会受限。此时应该看路线 B。6. 路线 BPython LangChain 构建求婚智能体平台版优点是快缺点是调试时看不到内部过程、无法完全控制流式输出。如果你需要把求婚智能体放进自己的服务里用 Python 构建是更彻底的做法。6.1 直接用 Agent 还是硬编码工作流前期我试过两种做法。第一种是写死路由根据用户输入的关键词做 if-else 分支第二种是用 LangChain 的 ReAct Agent让模型自己决定调用哪个工具。结论是意图固定时用 if-else 更可控意图开放时用 Agent 更灵活。求婚智能体最终采用 ReAct Agent因为用户问法非常随机比如“她最近说想要一只小猫我求婚的时候要不要把这个加进去”这类输入关键词路由很难覆盖。6.2 创建 ReAct Agent创建一个 base.pyimport os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.prompts import PromptTemplate load_dotenv() llm ChatOpenAI( modelos.getenv(OPENAI_MODEL_NAME, gpt-4o-mini), api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), temperature0.7, ) react_prompt PromptTemplate.from_template( 你是一位镇定的求婚策划专家。请使用工具一步步完成任务。 你有这些工具可供使用 {tools} 工具名称列表{tool_names} 任务{input} 你的回答必须以“最终结果”开头给出完整可执行的建议。 思考过程 ) agent create_react_agent(llmllm, toolstools, promptreact_prompt) agent_executor AgentExecutor( agentagent, toolstools, verboseTrue, max_iterations5, )这里 tools 变量需要先定义下面补上。6.3 定义求婚工具ReAct 模式下工具就是 Action。先做一个待办清单工具它负责把生成的求婚计划写入本地文件from langchain.tools import BaseTool import datetime class ProposalChecklistTool(BaseTool): name: str proposal_checklist description: str ( 根据策划方案创建求婚待办清单。 输入为包含任务项和截止日期的文本每行一个待办。 当用户需要清单时使用这个工具。 ) def _run(self, task_items: str) - str: today datetime.date.today().isoformat() with open(proposal_todo.md, w, encodingutf-8) as f: f.write(f# 求婚待办清单生成日期{today}\n) f.write(task_items) return 已保存求婚待办清单到 proposal_todo.md tools [ProposalChecklistTool()]再做一个方案保存工具用于批量任务时把不同场景方案写入独立文件class ProposalPlanTool(BaseTool): name: str proposal_plan_saver description: str 保存完整求婚策划方案输入包含方案名和方案正文。 def _run(self, plan_text: str) - str: with open(fplans/{datetime.date.today().isoformat()}.md, a, encodingutf-8) as f: f.write(plan_text \n\n---\n\n) return 方案已保存工具数量不建议起步就做很多。保持 2 到 3 个工具让 Agent 先能跑通再逐步加搜索、日历、天气等外部 API。6.4 封装 SSE 流式接口FastAPI 主文件 main.pyfrom fastapi import FastAPI from fastapi.responses import StreamingResponse from pydantic import BaseModel from base import agent_executor app FastAPI(title求婚智能体 API) class ChatRequest(BaseModel): message: str session_id: str | None None app.post(/v1/agent/plan) async def plan(req: ChatRequest): async def event_stream(): # 流式转发 Agent 中间输出 for step in agent_executor.stream({input: req.message}): if output in step: content step[output] yield fdata: {content}\n\n yield event: done\ndata: [DONE]\n\n return StreamingResponse(event_stream(), media_typetext/event-stream) app.get(/health) async def health(): return {status: ok}启动服务uvicorn main:app --host 127.0.0.1 --port 8000启动后访问 http://127.0.0.1:8000/docs 可以看到 Swagger 接口文档直接测试 /v1/agent/plan。7. 功能测试与效果验证7.1 测试目标跑通以下用例就算成功输入“预算 3000 元晚餐后求婚”返回完整流程。输入“写一段轻松风格的求婚词60 秒”输出无土味情话。输入“离求婚还有 3 天帮我列待办”生成清单并保存文件。输入“餐厅里戒指掉了怎么办”返回应急建议。批量输入 3 组不同预算场景得到 3 个方案。7.2 用 curl 测试流式接口curl -N -X POST http://127.0.0.1:8000/v1/agent/plan \ -H Content-Type: application/json \ -d {message: 预算3000元想在客厅求婚风格温馨}预期输出是流式文本以data:开头逐段输出。7.3 用 Python 调用接口import requests url http://127.0.0.1:8000/v1/agent/plan payload {message: 写一段轻松风格的求婚词60秒内讲完} with requests.post(url, jsonpayload, streamTrue, timeout180) as resp: for line in resp.iter_lines(): if line: text line.decode(utf-8) if text.startswith(data: ): print(text[6:])判断成功的标准请求不超时、按句输出、最终出现完成标记生成内容不包含“土味情话”“网恋梗”等低质量表达。7.4 失败时排查什么现象排查方向输出为空白检查 API Key 和模型名是否正确中途断流检查 keep alive 设置模型是否触发上下文截断工具调用报错打开 verboseTrue 看 ReAct 循环日志中文乱码检查终端编码为 UTF-88. 接口 API 与批量策划任务8.1 接口设计总结Python 版对外暴露两个接口接口方法作用/v1/agent/planPOST单次智能体对话SSE 流式返回/healthGET健康检查接口设计时把求婚任务参数统一化后续扩展其他垂直场景只需替换提示词模板。8.2 批量生成求婚方案求婚筹备往往需要备选方案。批量任务可以循环调用接口将结果写入文件import requests, time scenarios [ {budget: 1000元, scene: 居家晚餐, style: 温馨}, {budget: 5000元, scene: 海边黄昏, style: 浪漫}, {budget: 20000元, scene: 小礼堂, style: 正式}, ] for sc in scenarios: prompt f预算{sc[budget]}场景{sc[scene]}风格{sc[style]}生成完整求婚方案 with requests.post(http://127.0.0.1:8000/v1/agent/plan, json{message: prompt}, streamTrue, timeout180) as resp: lines [] for line in resp.iter_lines(): if line: text line.decode(utf-8) if text.startswith(data: ): lines.append(text[6:]) result .join(lines) with open(fplan_{sc[scene]}.md, w, encodingutf-8) as f: f.write(result) print(f已完成{sc[scene]}) time.sleep(1)批量任务必须加三个东西任务日志记录每个场景的请求时间、结果长度、是否成功。失败重试单次场景失败后自动重试 2 次。输出隔离每个结果写入独立文件不与历史结果混在一起。8.3 批量任务目录结构建议保持如下目录结构proposal-agent/ ├── main.py ├── base.py ├── tools.py ├── plans/ │ ├── 2025-01-01.md │ └── 2025-01-02.md ├── logs/ │ └── batch.log └── .env9. 资源占用与性能观察9.1 显存与 CPU本项目在 API 模式下不加载本地模型所以 CPU、内存占用很低主要开销在依赖进程。显存占用视情况而定不接本地模型无显存占用。接本地大模型如 Qwen、GLM 等开源模型的本地推理显存占用取决于模型参数量、量化格式和上下文长度需要用实际环境跑一次再看不能拍脑袋写。如果后面想完全离线选择 7B 以内并做 4bit 量化对普通家用显卡更友好但显存数字必须以实际 nvidia-smi 结果为准。9.2 性能影响因素影响响应速度的因素因素影响大模型响应质量模型越大越慢API 模式受服务商限流影响上下文长度输入越长首字延迟越大工具调用次数ReAct 每多调用一个工具就多一次推理批量并发数并发太大会触发限流或超时9.3 降低响应延迟的建议请求前先做关键词路由简单的应急问答不走完整 ReAct 循环。为 Agent 设置 max_iterations避免模型陷入多轮无效工具调用。SSE 流式返回先让首字出来用户体验远好于等待完整结果。大模型请求设置合理超时建议 180 秒以上。9.4 观察耗时的命令time curl -N -X POST http://127.0.0.1:8000/v1/agent/plan \ -H Content-Type: application/json \ -d {message: 预算3000元求婚方案}也可以直接在 /health 接口加上进程启动时间做粗粒度监控。10. 常见问题与排查方法问题现象可能原因排查方式解决方案启动报 ModuleNotFoundError依赖未安装或虚拟环境未激活检查 pip list重新执行 pip install -r requirements.txt接口请求报 401API Key 错误或过期查看服务日志更新 .env 中的 API Key模型输出混入奇怪内容提示词模板没有限制输出格式打印完整 prompt增加更明确输出约束降低 temperature流式接口卡住不返回模型服务限流或网络超时临时改为非流式测试增加超时降低并发改用更长响应窗口Agent 陷入工具反复调用工具描述不清或 max_iterations 太大打开 verbose 日志精简工具数量把 max_iterations 调小批量任务中途失败某个场景触发了限流查看 logs/batch.log增加重试和 sleep 间隔平台版工作流节点报错参数变量名配置不一致检查节点传参映射统一变量命名使用调试模式逐节点验证输出文件乱码编码问题file 命令检查文件编码写入时指定 encodingutf-8端口被占用其他服务占用 8000lsof/netstat 查看换端口启动11. 最佳实践与使用建议11.1 先小参数验证再完整生成第一次测试不要直接跑完整方案。先用“写一句求婚词”这种轻量输入验证模型链路是否通畅再逐步加长输入和工具调用。调试效率会高很多。11.2 保留最小可运行配置跑通后把以下内容复制到独立目录形成模板一个可用的大模型 API Key 配置一个最小提示词模板一个可以单测的样例输入一个批量脚本后续做新场景直接复制修改不用重新从零开始。11.3 数据与隐私边界求婚智能体涉及大量个人隐私。我在设计时做了几件事系统提示词里写“请勿输入身份证号、家庭住址、工作单位等敏感信息”。本地日志只记录请求时间、模型名、结果长度不记录完整对话。批量任务产生的方案文件默认保存在本地目录不自动上传到任何云服务。如果未来接入对话收集服务必须提示用户并做数据加密。如果你部署到公网接口务必加鉴权不要把服务直接暴露在公网裸奔。可以加 token 校验或放在内网网关后面。11.4 生成结果必须人工复核无论生成方案多完整最终执行是真人。生成内容里的场地建议、时间规划、亲友协助安排都应该在落地前复核一遍。尤其是文案部分要根据真实关系修改细节不要照抄模型生成内容。这也是智能体使用的红线生成内容只能作为辅助不能直接替代现实生活中的真实沟通和决策。12. 总结与下一步这个求婚智能体最值得尝试的点在于它把一个用户“很慌、很乱、不知道怎么办”的开放问题拆成了意图识别、工具调用、内容生成、任务输出的完整链路。无论你用的是 Coze 工作流还是 Python LangChain核心架构是一致的。先跑通最小的意图分流再加知识库再加工具最后批量生成。最先应该验证的功能是文案生成因为它最直观能快速确认模型输出风格是否符合预期。最容易踩的坑反而是路由设计如果意图识别不准后面的策划和清单都会跟着错所以一定要先调好意图识别。如果你的下一步是想把这个智能体做得更通用可以继续扩展接日历事件生成倒计时提醒、接地图接口推荐求婚定位、加语音输出让求婚词直接生成音频、把待办清单同步到自己的协作工具。也可以把同样的工作流换成“生日策划”“周年纪念策划”等其他垂直场景架构完全复用只需要替换提示词模板和知识库内容。碰到模型服务限流或输出不稳定时优先从提示词约束、超时设置、并发控制这三个方向调整基本能解决大部分线上问题。建议把整套代码和工作流备份到自己的仓库后续迭代时能明显节省时间。