1. 从一张架构图说起AI应用到底该怎么搭这两年我参与过不少AI应用项目的评审和落地发现一个特别普遍的现象很多团队拿到需求就开始堆模型、接API、写Prompt代码写了上万行最后发现整个系统像一团乱麻——模型换了要改几十个文件加一个新工具要动核心逻辑线上出问题根本不知道是哪一层挂了。说到底就是缺一张想清楚的架构图。“图解AI应用架构设计”这个主题核心不是教你画一张好看的PPT而是帮你建立一套从业务需求到技术落地的完整思维框架。它解决的是“AI应用怎么从Demo变成产品”这个关键问题适合正在做AI应用开发的工程师、准备从传统开发转型AI方向的程序员、以及需要把控技术方案的架构师和运维工程师。不管你是刚接触LLM的新手还是已经做过几个Agent项目的熟手这套架构思路都能帮你少走弯路。我自己的体会是AI应用架构和传统Web架构最大的区别在于传统架构里业务逻辑是确定的输入输出可预期而AI应用里LLM本身就是一个不确定的组件它的输出质量取决于Prompt、上下文、模型版本、甚至温度参数。所以架构设计的核心目标就是在不确定的LLM之上构建确定的业务能力。这句话是我做了十几个AI项目之后最深的感悟也是整篇内容的主线。接下来我会从整体设计思路、核心组件拆解、实操落地流程、常见问题排查四个维度把AI应用架构这件事讲透。每个部分都会配上我实际项目中的经验和踩过的坑尽量让你看完就能对照自己的项目动手调整。2. 整体架构设计思路与分层逻辑2.1 为什么AI应用需要分层架构传统CRUD应用的分层Controller-Service-DAO大家都熟但AI应用如果照搬这套很快会遇到问题。我见过最典型的反面案例是一个客服问答系统业务代码里直接调OpenAI的APIPrompt硬编码在Service层工具调用逻辑和业务逻辑混在一起。结果模型从GPT-3.5升级到GPT-4发现输出格式变了整个Service层要重写想加一个知识库检索功能发现没有地方插进去。分层架构的价值在这里就体现出来了。我的经验是AI应用至少要分成四层接入层、编排层、能力层、基础设施层。每一层职责单一层与层之间通过明确定义的接口通信。这样模型换了只动能力层业务逻辑变了只动编排层互不影响。具体来说接入层负责和用户交互处理会话管理、鉴权、限流编排层是AI应用的核心负责Prompt组装、上下文管理、Agent决策循环能力层封装LLM调用、工具执行、知识库检索、记忆存储等原子能力基础设施层提供向量数据库、缓存、日志、监控等支撑。这个分层不是拍脑袋定的而是我在多个项目中反复调整后沉淀下来的核心原则就是变化频率相同的代码放在一起变化频率不同的代码隔离。2.2 编排层Agent的大脑怎么设计编排层是整个AI应用最复杂也最核心的部分。如果你做的是简单的问答编排层可能就是一个Prompt模板加一次LLM调用但如果你做的是Agent编排层就要实现一个完整的决策循环。我用得最多的Agent循环是这样的接收用户输入 → 组装系统Prompt和上下文 → 调用LLM → 解析LLM输出 → 判断是否需要调用工具 → 如果需要执行工具并把结果追加到上下文 → 再次调用LLM → 直到LLM给出最终答案或达到最大轮次。这个循环看起来简单但每个环节都有坑。比如工具调用的解析早期我直接用正则匹配LLM输出里的JSON结果模型偶尔会输出格式不对的JSON导致解析失败。后来改用Function Calling或者结构化输出Structured Output让模型直接返回结构化的工具调用请求稳定性提升了一个数量级。再比如最大轮次的设置设太小会导致复杂任务没完成就退出设太大又可能陷入死循环烧token。我的经验值是普通任务5-8轮复杂任务15-20轮同时要加一个超时机制兜底。还有一个容易被忽略的点是上下文窗口管理。Agent循环每轮都会往上下文里追加内容几轮下来很容易超出模型的上下文限制。我的做法是维护一个滑动窗口保留最近的N轮对话和关键的工具调用结果更早的内容做摘要压缩。这个摘要本身也可以让LLM来做成本很低但效果不错。2.3 能力层LLM、工具、知识库怎么解耦能力层的设计目标是让编排层不关心具体用的是哪个模型、哪个工具、哪个知识库。听起来简单做起来需要一些设计模式。LLM调用这块我建议定义一个统一的LLMProvider接口包含chat、streamChat、embedding等方法。不同的模型OpenAI、Claude、国产模型各自实现这个接口。编排层只依赖接口不依赖具体实现。这样换模型只需要改配置不需要改代码。我试过在一个项目里同时接入了三个模型供应商通过配置切换做A/B测试非常方便。工具执行这块每个工具应该是一个独立的类或函数有明确的名称、描述、参数schema。编排层通过工具注册表来查找和调用工具。这里的关键是工具描述要写清楚因为LLM是根据描述来决定是否调用这个工具的。我踩过的坑是工具描述写得太简略导致LLM该调用的时候不调用不该调用的时候乱调用。后来我把每个工具的描述都写成一段完整的话说明什么场景下用、输入输出是什么准确率明显提升。知识库检索这块核心是向量化相似度搜索。但实际项目中纯向量检索的效果往往不够好我通常会用混合检索向量检索关键词检索然后用RRFReciprocal Rank Fusion融合排序。这样既能处理语义相似又能保证关键词精确匹配。如果对精度要求更高还可以加一个Rerank模型做二次排序。2.4 基础设施层那些容易被低估的支撑组件很多团队做AI应用时把全部精力放在模型和Prompt上基础设施能省则省结果上线后问题频出。我列几个我认为必须有的基础设施组件。日志与追踪AI应用的调试比传统应用难得多因为同样的输入可能得到不同的输出。所以必须记录每次LLM调用的完整信息输入Prompt、输出内容、token消耗、耗时、模型版本。我用LangSmith或者自己搭一套ELK效果都行关键是要有。缓存LLM调用又慢又贵能缓存的必须缓存。我通常做两层缓存一层是精确缓存相同的输入直接返回缓存结果一层是语义缓存相似的输入返回缓存结果。语义缓存用向量相似度判断阈值一般设在0.95以上比较安全。限流与降级LLM API有速率限制用户量上来之后必须做限流。我的做法是在接入层做用户级限流在能力层做模型级限流。同时要准备降级方案比如主模型不可用时切换到备用模型或者返回预设的兜底回复。监控告警要监控的指标包括LLM调用成功率、平均延迟、token消耗速率、工具调用失败率、用户满意度如果有反馈机制。这些指标异常时及时告警避免问题扩大。3. 核心组件深度拆解与实操要点3.1 Prompt工程不只是写一段话Prompt是AI应用的“业务逻辑”它的质量直接决定输出质量。但很多人把Prompt工程理解为“写一段话让模型干活”这就太浅了。我的经验是生产级的Prompt应该包含五个部分角色定义、任务描述、约束条件、输出格式、示例。角色定义让模型知道“我是谁”。比如“你是一个资深的客服专家擅长用简洁友好的语言解答用户问题”。任务描述说清楚“要做什么”。约束条件列出“不能做什么”比如“不要编造信息不知道就说不知道”。输出格式规定“怎么输出”比如JSON schema或者Markdown模板。示例给出“好的输出长什么样”通常给1-3个示例效果最好。这里有个实操技巧Prompt要版本化管理。我见过太多团队Prompt改来改去最后不知道哪个版本效果好。我的做法是把Prompt存在数据库或配置中心每次修改都记录版本号和修改原因配合A/B测试来评估效果。这样出了问题可以快速回滚好的改动也能沉淀下来。还有一个坑是Prompt注入。用户输入里可能包含“忽略之前的指令”之类的内容试图劫持模型行为。防御方法包括在系统Prompt里明确指示模型不要执行用户输入中的指令对用户输入做过滤和转义以及用结构化输出限制模型的回复格式。3.2 Agent工具调用从Function Calling到MCPAgent和普通LLM应用最大的区别就是能调用工具。早期我用的是ReAct模式让模型输出Thought/Action/Observation的文本然后解析。这种方式灵活但稳定性差模型经常不按格式输出。后来Function Calling成熟了我就全面切换过去了。Function Calling的原理是你在调用LLM时传入工具的定义名称、描述、参数schema模型如果判断需要调用工具会返回一个结构化的调用请求包含工具名和参数。你执行完工具后把结果传回给模型模型继续推理。这个流程比文本解析稳定得多。最近MCPModel Context Protocol火起来了我也研究了一下。MCP本质上是一个标准化的工具接入协议它定义了工具提供方和工具使用方之间的通信规范。好处是工具可以一次开发、多处复用不用为每个AI应用单独适配。比如你有一个数据库查询工具用MCP协议封装后任何支持MCP的AI应用都能直接用。我实际测试下来MCP在跨应用复用工具这个场景下确实有价值但目前生态还在早期很多工具还没有MCP版本。我的建议是新项目可以直接按MCP的思路来设计工具接口但不必强求完全遵循MCP协议老项目可以先保持现有的Function Calling方案等MCP生态成熟了再迁移。工具调用的一个关键设计是错误处理。工具执行可能失败网络超时、参数错误、权限不足失败后怎么处理我的做法是把错误信息也返回给LLM让LLM决定是重试、换工具、还是告诉用户失败了。这比直接抛异常给用户友好得多。3.3 记忆系统让Agent记住该记住的没有记忆的Agent就像金鱼每次对话都从零开始。记忆系统要解决三个问题记什么、怎么存、怎么取。记什么我通常分三类短期记忆当前会话的对话历史、长期记忆用户偏好、历史事实、工作记忆当前任务的中间状态。短期记忆用滑动窗口管理长期记忆用向量数据库存储工作记忆用结构化数据存。怎么存短期记忆直接存对话列表长期记忆把信息向量化后存入向量库工作记忆用JSON或数据库存。这里的关键是提取什么信息存入长期记忆。我的做法是让LLM在对话结束后做一次总结提取出值得记住的事实比如“用户喜欢简洁的回答”“用户是Python开发者”然后存入长期记忆。怎么取每次新对话开始时用当前用户输入去向量库检索相关的长期记忆拼接到系统Prompt里。检索数量一般取3-5条太多会占用上下文窗口太少可能漏掉关键信息。我踩过的一个坑是记忆污染。如果LLM总结时提取了错误的信息存入长期记忆后续所有对话都会受影响。所以我在存入长期记忆前会加一道校验让另一个LLM调用判断这条记忆是否准确、是否值得存。虽然增加了一点成本但避免了更大的问题。3.4 知识库与RAG检索增强生成的正确姿势RAGRetrieval-Augmented Generation是AI应用中最常用的技术之一但做好RAG并不容易。我见过很多团队搭了RAG效果却不如直接把文档塞进Prompt。问题通常出在检索环节。文档切分是第一个坑。切太大检索出来的内容包含太多无关信息切太小可能丢失上下文。我的经验是按语义切分而不是按固定字数切分。具体做法是先用规则比如按段落、按标题粗切然后用LLM判断相邻段落是否应该合并。切分后的块大小控制在300-800字之间比较合适。检索策略是第二个坑。纯向量检索对语义相似但关键词不同的情况效果好但对精确匹配比如产品型号、人名效果差。所以我通常用混合检索向量检索取Top 20关键词检索BM25取Top 20然后用RRF融合取Top 10最后用Rerank模型精排取Top 3-5。这套组合拳下来检索准确率能提升不少。还有一个容易被忽略的点是引用溯源。RAG生成的内容应该标注来源让用户知道信息出自哪个文档。这不仅提升可信度也方便排查问题。实现方式是在Prompt里要求LLM输出引用标记然后在后处理时把标记替换成实际的文档链接。4. 完整实操流程从零搭建一个AI应用4.1 环境准备与技术选型假设我们要搭建一个企业知识助手能回答员工关于公司制度、产品文档、技术规范的问题还能调用内部API查询数据。我以这个场景为例走一遍完整的搭建流程。技术选型上我的原则是成熟优先、按需引入。编程语言用Python生态最丰富。Web框架用FastAPI异步支持好适合LLM这种IO密集的场景。LLM先用OpenAI的GPT-4o稳定且Function Calling支持好后续可以加国产模型做备份。向量数据库用Milvus或Qdrant都支持混合检索。编排框架我倾向自己写因为LangChain这类框架抽象层太厚出问题不好排查但可以参考它的设计思路。环境准备的具体步骤先创建Python虚拟环境安装核心依赖fastapi、uvicorn、openai、qdrant-client、rank-bm25等然后配置环境变量管理API Key。我习惯用.env文件加python-dotenv简单直接。数据库和向量库用Docker Compose一键启动方便本地开发。4.2 知识库构建文档处理与向量化知识库构建分四步文档收集、文档解析、文档切分、向量化入库。文档收集就是把公司各种格式的文档PDF、Word、Markdown、Confluence页面收集起来。这一步的坑是格式多样PDF有扫描版和文字版Word有各种样式。我的做法是统一转成Markdown扫描版PDF先用OCR处理。文档解析用unstructured库或者markitdown能把各种格式转成结构化文本。解析后要清洗一下去掉页眉页脚、乱码、重复内容。文档切分我前面说了按语义切分。具体实现是先用RecursiveCharacterTextSplitter粗切chunk_size设800overlap设100然后用LLM对每个chunk判断是否需要和相邻chunk合并。这一步会消耗一些token但值得。向量化用OpenAI的text-embedding-3-small性价比高。每个chunk向量化后存入Qdrant同时把原文和元数据来源、标题、页码也存进去。元数据很重要后面引用溯源和过滤都要用。4.3 核心编排逻辑实现编排逻辑我用一个AgentOrchestrator类来实现核心方法是run接收用户输入返回最终回复。run方法的流程第一步加载会话历史短期记忆和用户长期记忆。第二步用用户输入检索知识库取Top 5相关文档块。第三步组装系统Prompt包含角色定义、任务描述、知识库内容、工具定义、输出格式要求。第四步进入Agent循环调用LLM如果返回工具调用请求执行工具并把结果追加到消息列表继续循环如果返回最终答案退出循环。第五步保存会话历史异步更新长期记忆。工具定义我用Pydantic模型来描述参数schema然后转成OpenAI的Function Calling格式。目前定义了三个工具search_knowledge_base检索知识库、query_database查询业务数据库、create_ticket创建工单。每个工具都有详细的描述说明什么场景下使用。Agent循环的最大轮次设为10超时设为60秒。每轮LLM调用的温度设为0.1保证输出稳定。如果连续两轮LLM都返回相同的工具调用说明可能陷入循环直接中断并返回兜底回复。4.4 接入层与流式输出接入层用FastAPI实现提供/chat接口支持流式输出SSE。流式输出对用户体验很重要尤其是长回复场景用户不用等全部生成完才能看到内容。实现流式输出的关键是LLM调用时开启streamTrue然后逐块返回。但Agent循环里工具调用和流式输出有点冲突因为工具调用需要等LLM完整输出才能解析。我的做法是如果LLM返回的是工具调用就不流式输出等工具执行完再继续如果LLM返回的是最终答案就流式输出。判断方式是先让LLM输出一小段如果是工具调用的JSON开头就切换成非流式模式。接入层还要做鉴权、限流、会话管理。鉴权用JWT限流用Redis做滑动窗口会话管理用Redis存会话状态。这些和传统Web应用差不多就不展开了。4.5 部署与运维要点部署我推荐用Docker Compose做本地开发Kubernetes做生产部署。核心服务包括API服务、向量数据库、Redis、PostgreSQL。API服务至少部署两个副本保证高可用。运维要点我列几个关键的日志要集中收集我用ELK或者Loki重点记录LLM调用的完整信息监控要覆盖关键指标用PrometheusGrafana监控QPS、延迟、错误率、token消耗告警要分级P0告警服务不可用打电话P1告警错误率升高发消息P2告警token消耗异常发邮件。还有一个运维工程师特别要注意的点成本控制。LLM调用是按token计费的如果不加控制月底账单可能吓死人。我的做法是设置每日token预算超过预算自动降级到便宜模型或者限制调用频率。同时定期分析token消耗分布找出消耗大户优化。5. 常见问题与排查技巧实录5.1 LLM调用类问题排查问题一LLM返回格式不符合预期。这是最常见的问题尤其是要求JSON输出时。排查思路先检查Prompt里的格式说明是否清晰最好给一个完整的示例然后检查是否用了结构化输出Structured Output或JSON模式这些能强制模型输出合法JSON最后检查温度参数温度太高会导致输出不稳定格式要求严格时温度设0-0.2。问题二LLM调用超时。LLM调用延迟波动很大尤其是高峰期。排查思路先看是不是模型本身的问题换个模型试试然后看网络尤其是调用海外模型时最后看是不是Prompt太长导致处理慢。解决方案设置合理的超时时间我一般设30-60秒加自动重试最多2次准备降级方案备用模型或兜底回复。问题三token消耗异常高。排查思路先看是不是上下文太长Agent循环每轮都追加内容很容易累积然后看是不是Prompt里有冗余内容比如重复的系统指令最后看是不是有死循环Agent反复调用同一个工具。解决方案上下文做滑动窗口和摘要压缩Prompt精简设置最大轮次和超时。5.2 Agent行为异常排查问题一Agent不调用工具。明明定义了工具LLM却直接回答不调用。排查思路检查工具描述是否清晰LLM是根据描述决定是否调用的检查系统Prompt是否指示了可以使用工具检查用户输入是否真的需要工具。解决方案把工具描述写详细在系统Prompt里明确说明“需要查询数据时请调用工具”给几个调用工具的示例。问题二Agent调用错误的工具。定义了多个工具LLM选了不合适的。排查思路检查工具描述之间是否有重叠导致LLM混淆检查工具名称是否太相似。解决方案让每个工具的描述有明确的区分度说明各自的适用场景工具名称用动词开头清晰表达功能。问题三Agent陷入循环。反复调用同一个工具或者反复输出相同内容。排查思路看工具返回的结果是否让LLM困惑比如返回了错误信息但LLM没理解看最大轮次设置是否太大。解决方案工具返回结果要清晰错误信息要明确设置最大轮次检测到重复调用时中断并返回兜底回复。5.3 知识库检索类问题排查问题一检索不到相关内容。用户问的问题知识库里有但检索不出来。排查思路先看文档切分是否合理可能相关内容被切散了然后看检索策略纯向量检索可能漏掉关键词匹配最后看embedding模型是否适合中文。解决方案优化切分策略用混合检索换更适合中文的embedding模型。问题二检索到无关内容。检索出来的内容和问题不相关导致LLM被误导。排查思路看相似度阈值是否太低看是否有重复或低质量文档看Rerank是否生效。解决方案提高相似度阈值清洗知识库加Rerank模型。问题三引用溯源不准确。LLM标注的来源和实际内容对不上。排查思路看Prompt里的引用格式要求是否清晰看后处理逻辑是否正确。解决方案在Prompt里明确要求引用格式后处理时严格校验。5.4 性能与并发问题排查问题一高并发下响应变慢。用户量上来后响应时间明显增加。排查思路看瓶颈在哪是LLM调用慢、向量检索慢、还是数据库慢看是否有资源竞争。解决方案LLM调用做异步和连接池向量检索加缓存数据库加索引水平扩展API服务副本。问题二流式输出卡顿。流式输出时断时续。排查思路看网络是否稳定看LLM服务端是否限流看API服务是否有阻塞操作。解决方案优化网络加缓冲确保流式输出路径上没有同步阻塞操作。问题三内存泄漏。服务运行一段时间后内存持续增长。排查思路看是否有全局变量累积看是否有未关闭的连接看是否有大对象未释放。解决方案用内存分析工具定位修复泄漏点加定期重启兜底。问题类型典型表现排查方向解决方案LLM格式异常输出非JSON、字段缺失Prompt、结构化输出、温度加示例、用JSON模式、降温度LLM超时请求超过30秒无响应模型、网络、Prompt长度设超时、重试、降级Agent不调工具直接回答不调用工具描述、系统Prompt细化描述、加调用示例Agent循环反复调同一工具工具返回、最大轮次清晰返回、设轮次上限检索不准找不到或找到无关内容切分、检索策略、阈值语义切分、混合检索、Rerank并发变慢响应时间随QPS上升瓶颈定位、资源竞争异步、缓存、水平扩展5.5 我踩过的三个大坑第一个坑是过度依赖框架。早期我用LangChain它的抽象确实方便但出问题时排查很痛苦因为不知道框架内部做了什么。后来我改成自己写编排逻辑代码量多了些但完全可控出问题一眼就能定位。我的建议是可以用框架快速验证想法但生产环境最好自己掌控核心逻辑。第二个坑是忽视Prompt版本管理。有次优化Prompt后效果变差想回滚却发现旧版本没保存只能凭记忆重写。从那以后我所有Prompt都存数据库每次修改记录版本号和效果指标。这个习惯帮我避免了很多次“改坏了回不去”的尴尬。第三个坑是没有做成本监控。有个项目上线后没关注token消耗月底发现账单是预算的5倍。排查发现是Agent循环里有个bug导致偶尔死循环疯狂烧token。后来我加了每日预算和实时监控超过阈值自动告警和降级。这件事让我意识到AI应用的成本控制和性能监控一样重要。6. 架构演进与扩展方向6.1 从单Agent到多Agent协作单Agent能处理的任务有限复杂任务需要多Agent协作。我目前实践过的多Agent架构有两种主从模式和对等模式。主从模式是一个主Agent负责任务分解和调度多个从Agent负责执行具体子任务。主Agent把用户请求拆成子任务分发给从Agent收集结果后汇总回复。这种模式适合任务边界清晰的场景比如“查数据写报告发邮件”。对等模式是多个Agent各自有专长通过消息传递协作。比如一个Agent负责检索一个负责推理一个负责校验。这种模式适合需要多轮讨论的场景比如复杂决策。多Agent的挑战在于通信开销和状态同步。Agent之间传递消息会消耗tokenAgent多了成本上升很快。我的经验是Agent数量控制在3-5个超过这个数管理复杂度会急剧上升。6.2 从RAG到Agentic RAG传统RAG是“检索一次生成一次”Agentic RAG是“检索-评估-再检索-生成”的循环。Agentic RAG能处理更复杂的查询比如需要多跳推理的问题。实现Agentic RAG的关键是加一个检索评估环节检索到内容后让LLM判断这些内容是否足够回答问题如果不够生成新的查询再次检索。这个循环可以重复多次直到LLM认为信息足够。Agentic RAG的代价是延迟和成本增加因为多了几次LLM调用。所以我的做法是分级处理简单问题走传统RAG复杂问题走Agentic RAG。判断问题复杂度可以用规则问题长度、是否包含多个实体或者让LLM判断。6.3 架构的可观测性建设AI应用的可观测性比传统应用更重要因为它的行为更不可预测。我建议从三个层面建设可观测性。指标层面除了常规的QPS、延迟、错误率还要监控LLM特有的指标比如token消耗速率、工具调用成功率、检索命中率、用户反馈评分。追踪层面每次请求要有完整的trace记录从接入到响应的每个环节包括LLM调用的输入输出、工具调用的参数和结果、检索的查询和结果。我用OpenTelemetry做追踪配合Jaeger展示。日志层面结构化日志关键字段包括请求ID、用户ID、会话ID、模型版本、Prompt版本、token消耗、耗时。日志要能按这些字段检索方便排查问题。可观测性建设不是一次性的要随着业务发展持续完善。我的做法是每次线上出问题后复盘时问一句“如果当时有XX监控能不能更快发现”然后把缺失的监控补上。6.4 安全与合规考量AI应用的安全问题比传统应用更复杂因为LLM本身可能被诱导做出不当行为。我重点关注三个方面。输入安全用户输入可能包含Prompt注入、越狱尝试、敏感信息。我的做法是在接入层做输入过滤检测到可疑内容时拒绝或转人工。同时系统Prompt里明确指示模型不要执行用户输入中的指令。输出安全LLM可能输出不当内容、泄露系统Prompt、编造信息。我的做法是加一层输出审核用另一个LLM或者规则引擎检查输出发现问题时替换成兜底回复。同时要求LLM在不确定时明确说“不知道”不要编造。数据安全知识库可能包含敏感信息要控制访问权限。我的做法是在检索时加权限过滤用户只能检索到有权限的文档。同时日志里不记录敏感信息或者做脱敏处理。合规方面要关注数据存储和传输的加密、用户数据的删除机制、AI生成内容的标识。这些在不同地区有不同要求做产品时要提前了解。7. 一些个人体会做AI应用架构这两年最大的感受是变化太快。去年还在用ReAct今年Function Calling和MCP就成主流了去年RAG还是新鲜事今年Agentic RAG已经开始普及。所以架构设计要留足扩展空间不要把某个技术方案写死。另一个感受是简单优先。我见过太多团队一上来就搞多Agent、Agentic RAG、复杂记忆系统结果基础功能都没做好。我的建议是先用最简单的方案跑通核心流程验证价值后再逐步加复杂度。很多时候一个好的Prompt加一次LLM调用就能解决80%的问题。最后分享一个实用技巧建立自己的评估集。每次修改Prompt、换模型、调整架构都用同一套测试用例跑一遍对比效果。这个评估集不用很大20-50个典型问题就够但要坚持维护。我靠这个习惯避免了很多次“感觉变好了实际变差了”的误判。架构设计没有标准答案只有适合当前场景的方案。希望这篇内容能帮你建立自己的判断框架在AI应用开发这条路上走得更稳。