zxy的个人博客

写在前面前几篇记录了智能旅行规划助手的后端接口、工具调用、多 Agent 协作和结构化输出。最后一步是前端可视化和线上部署。 一个 AI 项目如果只能在本地跑通，还不能算真正完成。只有部署到公网，让别人能访问、能填写表单、能生成结果，才更接近真实项目。 前端页面设计前端使用 Vue3，主要分成两个页面： 表单页：收集用户旅行需求 结果页：展示结构化旅行计划 表单页重点是让用户输入尽量结构化：

写在前面做 AI 应用时，模型能不能回答不是唯一问题，更重要的是：模型输出能不能被系统稳定消费。 在智能旅行规划助手里，前端需要展示每日行程、景点、餐饮、住宿、交通、预算等结构化内容。如果模型输出一段自然语言，前端就无法稳定渲染。 所以这一篇记录结构化输出解析和兜底机制。 为什么必须做结构化输出旅行计划的展示不是普通文本，而是多个模块： 行程概览 景点卡片 餐饮安排 酒店信息 交通方式 天气建议

写在前面智能旅行规划助手的核心不是简单调用一次模型，而是把复杂旅行规划任务拆成多个相对清晰的子任务。 如果让一个 Prompt 同时完成景点筛选、天气分析、酒店推荐、行程编排、预算估算和 JSON 输出，模型很容易顾此失彼。所以我把它拆成多 Agent 协作流程。 多 Agent 拆分思路项目里主要拆成四类 Agent： 1234景点搜索 Agent -> 天气分析 Agent ->

写在前面在旅行规划场景里，模型最容易出现的问题就是“编”。它可以生成很流畅的行程，但景点、地址、酒店、天气这些信息如果没有真实数据支撑，就很难让用户信任。 所以这个项目的第三步是接入高德地图 API，把外部工具返回的真实数据作为 LLM 的上下文输入。 为什么要接地图 API如果只依赖大模型，可能会出现这些情况： 景点名称不准确 地址不真实 景点之间距离不合理 酒店推荐没有依据 天气建议泛泛而谈

写在前面上一篇记录了智能旅行规划助手的需求拆解和整体架构。这一篇主要记录后端接口设计，重点是 FastAPI 和 Pydantic 在这个项目里的作用。 做 AI 应用时，很多人容易把注意力全部放在 Prompt 上，但实际开发中，接口和数据结构同样重要。因为前端、后端、工具 API、LLM 输出最终都要围绕一套稳定的数据格式协作。 为什么先设计 Schema如果后端只返回一段文本，前端展示会非常

写在前面最近完成了一个智能旅行规划助手项目。这个项目不是简单地调用一次大模型 API，然后把结果展示出来，而是尝试把一个真实的 AI 应用从需求拆解、外部工具接入、Agent 协作、结构化输出、前端展示到服务部署完整跑通。 这篇文章先记录第一阶段：我如何理解这个项目的需求，以及为什么最后选择了“FastAPI 后端 + LLM Agent + 高德地图工具 + Vue3 前端”的整体架构。 为什么

高山仰止，景行行止，虽不能至，心向往之

写在前面虽然我的主方向是 Java 后端，但做 AI 项目和博客后台时，经常需要写一点前端逻辑。JavaScript 的异步编程是绕不开的基础。 这篇文章记录 Promise 和 async/await 的基本理解。 PromisePromise 用来表示一个未来才会完成的操作。 1234567function fetchUser() { return new Promise

写在前面最近一直在思考一个问题：掌握Python基础、会用LangChain框架、能写Prompt、会处理JSON和CSV数据，这样的技能组合能否应对大部分AI开发工作？ 这是我自己的错觉，还是我真的太水了？今天想和大家聊聊这个话题。 我的技能现状先说说我目前的技能栈： ✅ Python基础：语法熟练，能写脚本处理日常任务 ✅ LangChain框架：会用Chains、Agents、Memory

写在前面我主方向是 Java 后端，所以学习 AI 应用时会自然关注 Spring AI。它的意义是让 Java 项目更方便地接入大模型、Embedding、向量库和工具调用。 这篇文章只记录基础用法和我目前的理解。 模型调用最基础的是文本生成： 1234String result = chatClient.prompt() .user("帮我总结这段文本") .c