企业官网建设流程全解析

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的API，Prompt硬编码在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该调用的时候不调用，不该调用的时候乱调用。后来我把每个工具的描述都写成一段完整的话，说明什么场景下用、输入输出是什么，准确率明显提升。

知识库检索这块，核心是向量化+相似度搜索。但实际项目中，纯向量检索的效果往往不够好，我通常会用混合检索：向量检索+关键词检索，然后用RRF（Reciprocal 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到MCP

Agent和普通LLM应用最大的区别就是能调用工具。早期我用的是ReAct模式，让模型输出Thought/Action/Observation的文本，然后解析。这种方式灵活但稳定性差，模型经常不按格式输出。

后来Function Calling成熟了，我就全面切换过去了。Function Calling的原理是：你在调用LLM时传入工具的定义（名称、描述、参数schema），模型如果判断需要调用工具，会返回一个结构化的调用请求，包含工具名和参数。你执行完工具后，把结果传回给模型，模型继续推理。这个流程比文本解析稳定得多。

最近MCP（Model 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：检索增强生成的正确姿势

RAG（Retrieval-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设800，overlap设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调用时开启stream=True，然后逐块返回。但Agent循环里工具调用和流式输出有点冲突，因为工具调用需要等LLM完整输出才能解析。我的做法是：如果LLM返回的是工具调用，就不流式输出，等工具执行完再继续；如果LLM返回的是最终答案，就流式输出。判断方式是先让LLM输出一小段，如果是工具调用的JSON开头，就切换成非流式模式。

接入层还要做鉴权、限流、会话管理。鉴权用JWT，限流用Redis做滑动窗口，会话管理用Redis存会话状态。这些和传统Web应用差不多，就不展开了。

4.5 部署与运维要点

部署我推荐用Docker Compose做本地开发，Kubernetes做生产部署。核心服务包括：API服务、向量数据库、Redis、PostgreSQL。API服务至少部署两个副本，保证高可用。

运维要点我列几个关键的：日志要集中收集，我用ELK或者Loki，重点记录LLM调用的完整信息；监控要覆盖关键指标，用Prometheus+Grafana，监控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服务是否有阻塞操作。解决方案：优化网络，加缓冲，确保流式输出路径上没有同步阻塞操作。

问题三：内存泄漏。服务运行一段时间后内存持续增长。排查思路：看是否有全局变量累积；看是否有未关闭的连接；看是否有大对象未释放。解决方案：用内存分析工具定位，修复泄漏点，加定期重启兜底。

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之间传递消息会消耗token，Agent多了成本上升很快。我的经验是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应用开发这条路上走得更稳。