1. 从一张架构图说起为什么AI应用架构值得单独拎出来讲很多人第一次接触AI应用开发脑子里想的都是调个API就完事了。我刚开始也是这么想的——拿个大模型接口套个前端页面能对话就算跑通了。直到真正接手一个要上线的项目才发现事情远没有这么简单模型响应忽快忽慢、多轮对话上下文爆炸、工具调用动不动就超时、多个Agent之间互相甩锅……这些问题没有一个能靠调API解决它们全部指向同一个东西——架构设计。AI应用架构设计和传统软件架构最大的区别在于传统架构里输入输出是确定的你写个函数传3返回6它永远返回6但AI应用里同一个输入可能得到完全不同的输出模型可能幻觉、可能超时、可能拒绝回答。这意味着架构要额外处理不确定性——这是传统后端工程师最容易低估的地方。这篇内容适合三类人看一是正在从传统开发转向AI应用开发的工程师你需要知道架构层面多了哪些东西二是已经能跑通Demo但不知道怎么产品化的开发者你需要把能跑变成稳定跑三是技术负责人你需要判断一个AI应用方案到底靠不靠谱。我会围绕LLM、Agent、MCP这几个核心概念把AI应用架构从底到顶拆一遍配上我自己踩过的坑和实际可用的设计思路。先给一个全局视角。一个完整的AI应用架构从下到上大致分四层模型层LLM本身包括推理、微调、量化部署、能力层RAG检索、工具调用、记忆管理、编排层Agent逻辑、多Agent协作、任务规划、应用层对话界面、业务流程、权限控制。MCP则是一个横切关注点它解决的是能力层怎么标准化对接外部工具的问题。下面逐层展开。2. 模型层LLM选型和部署里那些没人告诉你的取舍2.1 闭源API和本地部署不是哪个好而是哪个合适模型层最基础的决策就是用云端API还是本地部署这个问题被问烂了但很多回答都停留在本地部署数据安全这种层面不够具体。我按实际项目经验给一个判断框架。先看几个硬指标。云端API的优势是开箱即用、模型能力强、免运维劣势是数据出域、按量计费成本不可控、网络延迟不可控。本地部署的优势是数据不出门、成本固定、可深度定制劣势是硬件投入大、模型能力通常弱于顶级闭源模型、需要专人维护。但真正做决策时我建议先问三个问题第一你的数据敏感度到底有多高很多团队一上来就说我们数据不能出域结果仔细一聊发现要处理的只是公开的产品文档。这种情况用云端API完全没问题。真正需要本地部署的是涉及个人隐私、商业机密、或者有明确合规要求的场景。第二你的调用量有多大算一笔账假设你用某云端模型每百万token输入收费几块钱一天调用100万token一个月就是几百块。这个量级下本地部署一张消费级显卡的成本可能两三年都收不回来。但如果一天调用上亿token本地部署的边际成本优势就出来了。第三你对延迟的容忍度是多少云端API的网络往返通常在几百毫秒到几秒本地部署可以做到几十毫秒。如果是实时对话场景这个差异用户能明显感知。我自己的做法是混合架构核心敏感数据走本地小模型通用任务走云端大模型中间加一层路由。这样既控制了成本又保证了敏感数据不出域。路由逻辑可以很简单比如按任务类型分流也可以复杂一点用小模型先判断任务复杂度再决定用哪个模型。2.2 量化部署让大模型跑在消费级硬件上的关键手段本地部署绕不开量化。所谓量化说白了就是把模型权重从高精度比如16位浮点压缩到低精度比如4位整数代价是精度损失收益是显存占用大幅下降。常见的量化方案有这么几档量化级别显存占用以7B模型为例精度损失适用场景FP16约14GB无有专业显卡追求最高质量INT8约7GB极小平衡选择INT4约4GB可感知消费级显卡、边缘设备2-3bit约2-3GB明显极端资源受限场景实测下来INT4量化在大多数对话和问答任务上效果和FP16的差距普通用户基本感知不到但显存占用直接砍掉三分之二。如果你的场景是结构化信息抽取或者代码生成量化带来的精度损失会更明显一些建议至少用INT8。量化工具方面主流的有llama.cpp自带的量化、GPTQ、AWQ等。llama.cpp的GGUF格式对CPU推理友好适合没有独立显卡的场景GPTQ和AWQ对GPU推理优化更好。选哪个取决于你的硬件环境没有绝对优劣。注意量化后的模型在长文本生成时更容易出现重复、跑题的问题。如果你的应用涉及长文写作建议做一轮量化前后的对比测试别直接上线。2.3 模型层的容错设计别把鸡蛋放在一个篮子里生产环境里单一模型源是不可接受的。云端API会限流、会宕机、会涨价本地模型会OOM、会卡死。架构上必须做多模型冗余。具体做法维护一个模型池每个模型标注能力标签擅长对话、擅长代码、擅长抽取和健康状态。请求进来时路由器根据任务类型选主模型主模型失败则自动降级到备用模型。降级策略要提前定义好比如主模型超时3秒就切备用备用也失败就返回兜底话术。这里有个容易忽略的点不同模型的输出格式可能不一样。比如同样要求返回JSON模型A返回的是标准JSON模型B可能带markdown代码块标记。所以路由层之后需要加一层输出规范化把不同模型的输出统一成应用层能处理的格式。这层不做后面会出各种诡异的解析错误。3. 能力层RAG、工具调用和记忆管理怎么搭才不塌3.1 RAG不是向量库大模型这么简单RAG检索增强生成现在几乎成了AI应用的标配但很多人对它的理解停留在把文档切块、存进向量库、查询时召回、拼进prompt。这个流程能跑通Demo但上线后会遇到一堆问题。第一个问题是切块策略。固定长度切块是最省事的但效果往往最差。一份技术文档按500字硬切很可能把一个完整的函数说明切成两半召回时只召回上半部分模型拿到残缺信息自然答不对。我的经验是按语义结构切块Markdown按标题层级切代码按函数/类切合同按条款切。切完之后给每个块加上元数据来源文件、所属章节、时间戳召回时可以按元数据过滤。第二个问题是召回质量。纯向量检索对语义相似但用词不同的查询效果好但对精确匹配比如查一个特定的错误码效果差。实际项目里我一般用混合检索向量检索关键词检索BM25两路结果合并后重排序。重排序可以用一个小的交叉编码器模型也可以用大模型做相关性打分。实测混合检索比纯向量检索的召回准确率能提升20%以上。第三个问题是上下文组装。召回了一堆文档块不能一股脑全塞进prompt。一是token有限二是无关信息会干扰模型。我的做法是先按相关性排序取Top-K通常3-5个然后做去重和压缩——把重复内容去掉把长块压缩成摘要最后按问题-证据-指令的结构组装prompt。3.2 工具调用让LLM从会说变成会做LLM本身只能生成文本要让它查数据库、发邮件、调API就得靠工具调用Function Calling。工具调用的架构设计有几个关键决策。工具描述怎么写。模型是根据工具的名称和描述来决定调不调的。描述写得太简单模型不知道什么时候该用写得太复杂占token还容易让模型困惑。我的经验是名称用动词开头如search_orders、send_email描述里写清楚什么时候用和参数含义并给一两个调用示例。比如{ name: search_orders, description: 根据用户ID和日期范围查询订单。当用户询问订单状态、订单金额、订单时间时使用此工具。, parameters: { user_id: 用户唯一标识字符串, start_date: 起始日期格式YYYY-MM-DD, end_date: 结束日期格式YYYY-MM-DD } }工具执行的安全边界。模型可能调用任何它认为合适的工具包括删除数据的工具。所以架构上必须做权限校验每个工具标注风险等级高风险工具写操作、删除操作需要二次确认或人工审批。我见过一个案例模型在用户说帮我清理一下的时候直接调了删除接口把用户数据删了。这种坑一定要在架构层面堵住。工具调用的错误处理。工具执行可能失败——网络超时、参数错误、权限不足。失败信息要返回给模型让模型决定是重试、换工具还是告诉用户。这里有个细节错误信息不要直接抛原始堆栈给模型要转成自然语言描述否则模型看不懂。3.3 记忆管理短期记忆、长期记忆和它们各自的坑AI应用的记忆分两种短期记忆当前对话的上下文和长期记忆跨对话的用户偏好、历史事实。短期记忆的核心问题是上下文窗口有限。多轮对话聊久了token会爆。解决方案有几种滑动窗口只保留最近N轮、摘要压缩把早期对话总结成一段话、关键信息提取只保留实体和意图。我一般组合使用最近5轮保留原文5轮之前的做摘要实体信息单独存一张表。长期记忆的核心问题是写入和召回的准确性。什么时候该记记什么怎么在需要的时候想起来我的做法是对话结束后用一个小模型做信息抽取把值得记的事实用户偏好、重要日期、已确认的决策存进结构化存储下次对话开始时根据当前话题召回相关记忆拼进system prompt。注意不要把所有记忆都塞进去只召回相关的否则会干扰模型。提示记忆管理最容易出的问题是记了不该记的。比如用户随口说了一句我今天心情不好如果被当成长期记忆存下来下次对话模型可能莫名其妙地安慰你。所以信息抽取时要加过滤规则只记事实性、稳定性强的信息。4. 编排层Agent架构和多Agent协作的真实玩法4.1 单Agent的经典架构ReAct、Plan-and-Execute怎么选Agent的本质是让LLM自己决定下一步做什么。最经典的架构是ReActReasoning Acting模型先思考Thought再决定行动Action执行后观察结果Observation循环直到任务完成。ReAct的优点是灵活、实现简单适合步骤不确定的探索性任务。缺点是容易陷入循环——模型可能反复调同一个工具或者在一个死胡同里打转。所以生产环境里必须加最大步数限制和循环检测如果连续两步调了同一个工具且参数相同就强制中断。另一种架构是Plan-and-Execute先让模型制定完整计划再逐步执行。优点是全局观强、不容易跑偏缺点是计划可能一开始就错了而且执行过程中遇到意外不好调整。我的经验是任务步骤明确、可预先规划的场景用Plan-and-Execute需要边做边看的场景用ReAct。也可以混合先规划大步骤每个步骤内部用ReAct。4.2 多Agent协作什么时候需要怎么避免互相甩锅多Agent协作听起来很酷但很多场景其实不需要。我见过不少项目明明一个Agent加几个工具就能搞定非要拆成规划Agent执行Agent审核Agent结果三个Agent之间通信开销比任务本身还大还容易互相甩锅——执行Agent说规划Agent给的任务不清晰规划Agent说执行Agent理解能力差。判断要不要多Agent我的标准是如果子任务需要不同的系统提示词、不同的工具集、或者不同的模型才考虑拆Agent。比如一个客服Agent和一个技术文档Agent前者需要亲和力后者需要严谨提示词差异大拆开合理。如果只是任务步骤多单Agent加工具就够了。多Agent协作的架构模式主要有两种中心化一个协调者Agent分配任务给执行者Agent和去中心化Agent之间平等通信。中心化模式可控性强适合大多数场景去中心化模式灵活但容易出现死锁和消息风暴除非有明确需求否则不建议。通信协议方面Agent之间传递的消息要结构化包含任务ID、状态、结果、错误信息。不要传自然语言否则解析起来全是坑。我一般用JSON字段固定每个Agent都按这个格式读写。4.3 MCP工具对接的标准化尝试MCPModel Context Protocol是最近很热的一个概念它要解决的问题是每个AI应用都要自己实现一遍工具对接重复造轮子。MCP定义了一套标准协议工具提供方按协议暴露能力AI应用按协议调用双方解耦。从架构角度看MCP的价值在于把工具层标准化。以前你接一个数据库要写连接、查询、结果解析接一个文件系统又要写一套。有了MCP这些工具如果有现成的MCP Server你直接接就行。对工具提供方来说实现一次MCP Server所有支持MCP的AI应用都能用。但MCP目前还在演进中实际使用有几个注意点一是MCP Server的质量参差不齐有些实现有性能问题或安全漏洞接入前要评估二是MCP的权限模型还在完善生产环境用的话要自己在外面加一层权限控制三是不是所有工具都值得MCP化如果只是内部用的一两个工具直接写代码调用可能更简单。我自己的判断是MCP适合工具生态丰富、需要频繁对接新工具的场景。如果你的应用就固定用三五个工具没必要为了MCP而MCP。5. 应用层与横切关注点那些决定产品能不能上线的细节5.1 流式输出和中断处理用户体验的关键用户等一个回答等10秒和等3秒但能看到字一个个蹦出来体验天差地别。流式输出Streaming是AI应用的标配但实现起来有几个坑。第一个坑是流式输出和工具调用的冲突。模型可能在流式输出到一半时决定调用工具这时候前面的文本已经发给用户了工具执行完还要接着输出怎么衔接我的做法是工具调用前的文本作为思考过程展示工具执行后重新开始一段输出。前端要做好状态管理别让用户看到混乱的拼接。第二个坑是中断处理。用户可能在模型输出到一半时发送新消息或者点击停止。这时候要能干净地中断当前生成释放资源并且保证对话历史的一致性。我见过一些实现中断后历史记录里存了半截回答下次对话模型看到半截内容会困惑。正确做法是中断时把已生成的部分标记为未完成或者直接丢弃。5.2 成本控制token是要花钱的AI应用的成本大头是token消耗。控制成本要从架构层面入手不能靠事后省。几个实用手段缓存——相同或相似的问题直接返回缓存结果尤其是FAQ类场景命中率能到30%以上模型分级——简单问题用小模型复杂问题用大模型用一个小分类器做路由prompt压缩——定期审查system prompt去掉冗余描述我见过一个项目的system prompt写了2000字压缩到500字后效果没变成本降了四分之三输出长度限制——给模型设置max_tokens防止它滔滔不绝。还有一个容易被忽略的点重试的成本。模型调用失败重试每次重试都是钱。所以重试策略要合理不要无脑重试三次。我的做法是网络错误重试模型返回格式错误不重试重试大概率还是错而是走降级逻辑。5.3 可观测性出了问题怎么查AI应用的可观测性比传统应用难做因为输出是不确定的。传统应用看日志就知道哪行代码出了问题AI应用可能同样的输入这次对下次错你根本不知道发生了什么。我的做法是全链路记录每次请求记录输入、检索到的文档、组装的prompt、模型原始输出、工具调用记录、最终输出。这些数据存下来出问题时可以回放。同时做质量监控用规则或小模型对输出做自动评估比如是否包含敏感词、是否格式正确、是否答非所问异常时告警。注意记录prompt和输出时要注意隐私合规。用户输入可能包含个人信息存储前要脱敏存储期限要明确。6. 我在实际项目里踩过的几个典型坑第一个坑是过度设计。刚开始做AI应用时我总想把架构做得完整——加缓存、加队列、加多Agent、加监控结果系统复杂度上去了开发速度下来了很多功能根本用不上。后来我学乖了先跑通最小闭环再按需加东西。一个对话应用先做到能稳定回答再考虑缓存和监控。第二个坑是忽视prompt的版本管理。prompt是AI应用的核心资产但很多人把它硬编码在代码里改一次要发一次版。我现在的做法是prompt存在配置中心或数据库里支持热更新每次修改记录版本和效果指标。这样调prompt不用发版A/B测试也方便。第三个坑是对模型能力估计过高。有些任务模型确实做不好比如精确计算、复杂逻辑推理。硬让模型做不如把任务拆解该用代码的用代码该用模型的用模型。架构设计的一个原则是能用确定性代码解决的不要交给模型。第四个坑是忽略冷启动。新上线的AI应用没有历史数据缓存命中率低检索效果差。这时候要么先用规则兜底要么用合成数据预热。我一般会准备一批常见问题上线前先跑一遍把结果缓存起来。7. 一套可落地的AI应用架构参考把上面的内容串起来给一个我实际用过的架构参考。这套架构适合中等规模的AI应用日调用量在十万到百万级别。接入层API网关负责鉴权、限流、路由。所有请求先到这里根据用户等级和任务类型分发。编排层Agent调度器维护会话状态决定用哪个Agent处理。单Agent场景下这层很薄多Agent场景下负责任务分配和结果汇总。能力层RAG检索服务、工具调用服务、记忆服务。每个服务独立部署通过内部接口通信。RAG服务包含向量库、关键词索引、重排序模型工具服务包含工具注册、权限校验、执行引擎记忆服务包含短期记忆存储和长期记忆存储。模型层模型路由 模型池。路由根据任务类型和模型健康状态选择模型模型池包含云端API和本地部署模型。基础设施日志、监控、缓存、消息队列。这些是支撑性的但缺了哪个都会出问题。这套架构不是唯一解也不是最优解但它是我在多个项目里验证过能跑通的。你可以根据自己的场景裁剪——小项目可能只需要接入层模型层大项目可能还要加数据飞轮、模型微调流水线。最后说一个我越来越深的体会AI应用架构的核心不是技术选型而是对不确定性的管理。模型会出错、工具会失败、用户会问奇怪的问题架构的价值就是让这些不确定性在可控范围内。把这一点想清楚很多设计决策就自然清晰了。
1. 从一张架构图说起为什么AI应用架构值得单独拎出来讲很多人第一次接触AI应用开发脑子里想的都是调个API就完事了。我刚开始也是这么想的——拿个大模型接口套个前端页面能对话就算跑通了。直到真正接手一个要上线的项目才发现事情远没有这么简单模型响应忽快忽慢、多轮对话上下文爆炸、工具调用动不动就超时、多个Agent之间互相甩锅……这些问题没有一个能靠调API解决它们全部指向同一个东西——架构设计。AI应用架构设计和传统软件架构最大的区别在于传统架构里输入输出是确定的你写个函数传3返回6它永远返回6但AI应用里同一个输入可能得到完全不同的输出模型可能幻觉、可能超时、可能拒绝回答。这意味着架构要额外处理不确定性——这是传统后端工程师最容易低估的地方。这篇内容适合三类人看一是正在从传统开发转向AI应用开发的工程师你需要知道架构层面多了哪些东西二是已经能跑通Demo但不知道怎么产品化的开发者你需要把能跑变成稳定跑三是技术负责人你需要判断一个AI应用方案到底靠不靠谱。我会围绕LLM、Agent、MCP这几个核心概念把AI应用架构从底到顶拆一遍配上我自己踩过的坑和实际可用的设计思路。先给一个全局视角。一个完整的AI应用架构从下到上大致分四层模型层LLM本身包括推理、微调、量化部署、能力层RAG检索、工具调用、记忆管理、编排层Agent逻辑、多Agent协作、任务规划、应用层对话界面、业务流程、权限控制。MCP则是一个横切关注点它解决的是能力层怎么标准化对接外部工具的问题。下面逐层展开。2. 模型层LLM选型和部署里那些没人告诉你的取舍2.1 闭源API和本地部署不是哪个好而是哪个合适模型层最基础的决策就是用云端API还是本地部署这个问题被问烂了但很多回答都停留在本地部署数据安全这种层面不够具体。我按实际项目经验给一个判断框架。先看几个硬指标。云端API的优势是开箱即用、模型能力强、免运维劣势是数据出域、按量计费成本不可控、网络延迟不可控。本地部署的优势是数据不出门、成本固定、可深度定制劣势是硬件投入大、模型能力通常弱于顶级闭源模型、需要专人维护。但真正做决策时我建议先问三个问题第一你的数据敏感度到底有多高很多团队一上来就说我们数据不能出域结果仔细一聊发现要处理的只是公开的产品文档。这种情况用云端API完全没问题。真正需要本地部署的是涉及个人隐私、商业机密、或者有明确合规要求的场景。第二你的调用量有多大算一笔账假设你用某云端模型每百万token输入收费几块钱一天调用100万token一个月就是几百块。这个量级下本地部署一张消费级显卡的成本可能两三年都收不回来。但如果一天调用上亿token本地部署的边际成本优势就出来了。第三你对延迟的容忍度是多少云端API的网络往返通常在几百毫秒到几秒本地部署可以做到几十毫秒。如果是实时对话场景这个差异用户能明显感知。我自己的做法是混合架构核心敏感数据走本地小模型通用任务走云端大模型中间加一层路由。这样既控制了成本又保证了敏感数据不出域。路由逻辑可以很简单比如按任务类型分流也可以复杂一点用小模型先判断任务复杂度再决定用哪个模型。2.2 量化部署让大模型跑在消费级硬件上的关键手段本地部署绕不开量化。所谓量化说白了就是把模型权重从高精度比如16位浮点压缩到低精度比如4位整数代价是精度损失收益是显存占用大幅下降。常见的量化方案有这么几档量化级别显存占用以7B模型为例精度损失适用场景FP16约14GB无有专业显卡追求最高质量INT8约7GB极小平衡选择INT4约4GB可感知消费级显卡、边缘设备2-3bit约2-3GB明显极端资源受限场景实测下来INT4量化在大多数对话和问答任务上效果和FP16的差距普通用户基本感知不到但显存占用直接砍掉三分之二。如果你的场景是结构化信息抽取或者代码生成量化带来的精度损失会更明显一些建议至少用INT8。量化工具方面主流的有llama.cpp自带的量化、GPTQ、AWQ等。llama.cpp的GGUF格式对CPU推理友好适合没有独立显卡的场景GPTQ和AWQ对GPU推理优化更好。选哪个取决于你的硬件环境没有绝对优劣。注意量化后的模型在长文本生成时更容易出现重复、跑题的问题。如果你的应用涉及长文写作建议做一轮量化前后的对比测试别直接上线。2.3 模型层的容错设计别把鸡蛋放在一个篮子里生产环境里单一模型源是不可接受的。云端API会限流、会宕机、会涨价本地模型会OOM、会卡死。架构上必须做多模型冗余。具体做法维护一个模型池每个模型标注能力标签擅长对话、擅长代码、擅长抽取和健康状态。请求进来时路由器根据任务类型选主模型主模型失败则自动降级到备用模型。降级策略要提前定义好比如主模型超时3秒就切备用备用也失败就返回兜底话术。这里有个容易忽略的点不同模型的输出格式可能不一样。比如同样要求返回JSON模型A返回的是标准JSON模型B可能带markdown代码块标记。所以路由层之后需要加一层输出规范化把不同模型的输出统一成应用层能处理的格式。这层不做后面会出各种诡异的解析错误。3. 能力层RAG、工具调用和记忆管理怎么搭才不塌3.1 RAG不是向量库大模型这么简单RAG检索增强生成现在几乎成了AI应用的标配但很多人对它的理解停留在把文档切块、存进向量库、查询时召回、拼进prompt。这个流程能跑通Demo但上线后会遇到一堆问题。第一个问题是切块策略。固定长度切块是最省事的但效果往往最差。一份技术文档按500字硬切很可能把一个完整的函数说明切成两半召回时只召回上半部分模型拿到残缺信息自然答不对。我的经验是按语义结构切块Markdown按标题层级切代码按函数/类切合同按条款切。切完之后给每个块加上元数据来源文件、所属章节、时间戳召回时可以按元数据过滤。第二个问题是召回质量。纯向量检索对语义相似但用词不同的查询效果好但对精确匹配比如查一个特定的错误码效果差。实际项目里我一般用混合检索向量检索关键词检索BM25两路结果合并后重排序。重排序可以用一个小的交叉编码器模型也可以用大模型做相关性打分。实测混合检索比纯向量检索的召回准确率能提升20%以上。第三个问题是上下文组装。召回了一堆文档块不能一股脑全塞进prompt。一是token有限二是无关信息会干扰模型。我的做法是先按相关性排序取Top-K通常3-5个然后做去重和压缩——把重复内容去掉把长块压缩成摘要最后按问题-证据-指令的结构组装prompt。3.2 工具调用让LLM从会说变成会做LLM本身只能生成文本要让它查数据库、发邮件、调API就得靠工具调用Function Calling。工具调用的架构设计有几个关键决策。工具描述怎么写。模型是根据工具的名称和描述来决定调不调的。描述写得太简单模型不知道什么时候该用写得太复杂占token还容易让模型困惑。我的经验是名称用动词开头如search_orders、send_email描述里写清楚什么时候用和参数含义并给一两个调用示例。比如{ name: search_orders, description: 根据用户ID和日期范围查询订单。当用户询问订单状态、订单金额、订单时间时使用此工具。, parameters: { user_id: 用户唯一标识字符串, start_date: 起始日期格式YYYY-MM-DD, end_date: 结束日期格式YYYY-MM-DD } }工具执行的安全边界。模型可能调用任何它认为合适的工具包括删除数据的工具。所以架构上必须做权限校验每个工具标注风险等级高风险工具写操作、删除操作需要二次确认或人工审批。我见过一个案例模型在用户说帮我清理一下的时候直接调了删除接口把用户数据删了。这种坑一定要在架构层面堵住。工具调用的错误处理。工具执行可能失败——网络超时、参数错误、权限不足。失败信息要返回给模型让模型决定是重试、换工具还是告诉用户。这里有个细节错误信息不要直接抛原始堆栈给模型要转成自然语言描述否则模型看不懂。3.3 记忆管理短期记忆、长期记忆和它们各自的坑AI应用的记忆分两种短期记忆当前对话的上下文和长期记忆跨对话的用户偏好、历史事实。短期记忆的核心问题是上下文窗口有限。多轮对话聊久了token会爆。解决方案有几种滑动窗口只保留最近N轮、摘要压缩把早期对话总结成一段话、关键信息提取只保留实体和意图。我一般组合使用最近5轮保留原文5轮之前的做摘要实体信息单独存一张表。长期记忆的核心问题是写入和召回的准确性。什么时候该记记什么怎么在需要的时候想起来我的做法是对话结束后用一个小模型做信息抽取把值得记的事实用户偏好、重要日期、已确认的决策存进结构化存储下次对话开始时根据当前话题召回相关记忆拼进system prompt。注意不要把所有记忆都塞进去只召回相关的否则会干扰模型。提示记忆管理最容易出的问题是记了不该记的。比如用户随口说了一句我今天心情不好如果被当成长期记忆存下来下次对话模型可能莫名其妙地安慰你。所以信息抽取时要加过滤规则只记事实性、稳定性强的信息。4. 编排层Agent架构和多Agent协作的真实玩法4.1 单Agent的经典架构ReAct、Plan-and-Execute怎么选Agent的本质是让LLM自己决定下一步做什么。最经典的架构是ReActReasoning Acting模型先思考Thought再决定行动Action执行后观察结果Observation循环直到任务完成。ReAct的优点是灵活、实现简单适合步骤不确定的探索性任务。缺点是容易陷入循环——模型可能反复调同一个工具或者在一个死胡同里打转。所以生产环境里必须加最大步数限制和循环检测如果连续两步调了同一个工具且参数相同就强制中断。另一种架构是Plan-and-Execute先让模型制定完整计划再逐步执行。优点是全局观强、不容易跑偏缺点是计划可能一开始就错了而且执行过程中遇到意外不好调整。我的经验是任务步骤明确、可预先规划的场景用Plan-and-Execute需要边做边看的场景用ReAct。也可以混合先规划大步骤每个步骤内部用ReAct。4.2 多Agent协作什么时候需要怎么避免互相甩锅多Agent协作听起来很酷但很多场景其实不需要。我见过不少项目明明一个Agent加几个工具就能搞定非要拆成规划Agent执行Agent审核Agent结果三个Agent之间通信开销比任务本身还大还容易互相甩锅——执行Agent说规划Agent给的任务不清晰规划Agent说执行Agent理解能力差。判断要不要多Agent我的标准是如果子任务需要不同的系统提示词、不同的工具集、或者不同的模型才考虑拆Agent。比如一个客服Agent和一个技术文档Agent前者需要亲和力后者需要严谨提示词差异大拆开合理。如果只是任务步骤多单Agent加工具就够了。多Agent协作的架构模式主要有两种中心化一个协调者Agent分配任务给执行者Agent和去中心化Agent之间平等通信。中心化模式可控性强适合大多数场景去中心化模式灵活但容易出现死锁和消息风暴除非有明确需求否则不建议。通信协议方面Agent之间传递的消息要结构化包含任务ID、状态、结果、错误信息。不要传自然语言否则解析起来全是坑。我一般用JSON字段固定每个Agent都按这个格式读写。4.3 MCP工具对接的标准化尝试MCPModel Context Protocol是最近很热的一个概念它要解决的问题是每个AI应用都要自己实现一遍工具对接重复造轮子。MCP定义了一套标准协议工具提供方按协议暴露能力AI应用按协议调用双方解耦。从架构角度看MCP的价值在于把工具层标准化。以前你接一个数据库要写连接、查询、结果解析接一个文件系统又要写一套。有了MCP这些工具如果有现成的MCP Server你直接接就行。对工具提供方来说实现一次MCP Server所有支持MCP的AI应用都能用。但MCP目前还在演进中实际使用有几个注意点一是MCP Server的质量参差不齐有些实现有性能问题或安全漏洞接入前要评估二是MCP的权限模型还在完善生产环境用的话要自己在外面加一层权限控制三是不是所有工具都值得MCP化如果只是内部用的一两个工具直接写代码调用可能更简单。我自己的判断是MCP适合工具生态丰富、需要频繁对接新工具的场景。如果你的应用就固定用三五个工具没必要为了MCP而MCP。5. 应用层与横切关注点那些决定产品能不能上线的细节5.1 流式输出和中断处理用户体验的关键用户等一个回答等10秒和等3秒但能看到字一个个蹦出来体验天差地别。流式输出Streaming是AI应用的标配但实现起来有几个坑。第一个坑是流式输出和工具调用的冲突。模型可能在流式输出到一半时决定调用工具这时候前面的文本已经发给用户了工具执行完还要接着输出怎么衔接我的做法是工具调用前的文本作为思考过程展示工具执行后重新开始一段输出。前端要做好状态管理别让用户看到混乱的拼接。第二个坑是中断处理。用户可能在模型输出到一半时发送新消息或者点击停止。这时候要能干净地中断当前生成释放资源并且保证对话历史的一致性。我见过一些实现中断后历史记录里存了半截回答下次对话模型看到半截内容会困惑。正确做法是中断时把已生成的部分标记为未完成或者直接丢弃。5.2 成本控制token是要花钱的AI应用的成本大头是token消耗。控制成本要从架构层面入手不能靠事后省。几个实用手段缓存——相同或相似的问题直接返回缓存结果尤其是FAQ类场景命中率能到30%以上模型分级——简单问题用小模型复杂问题用大模型用一个小分类器做路由prompt压缩——定期审查system prompt去掉冗余描述我见过一个项目的system prompt写了2000字压缩到500字后效果没变成本降了四分之三输出长度限制——给模型设置max_tokens防止它滔滔不绝。还有一个容易被忽略的点重试的成本。模型调用失败重试每次重试都是钱。所以重试策略要合理不要无脑重试三次。我的做法是网络错误重试模型返回格式错误不重试重试大概率还是错而是走降级逻辑。5.3 可观测性出了问题怎么查AI应用的可观测性比传统应用难做因为输出是不确定的。传统应用看日志就知道哪行代码出了问题AI应用可能同样的输入这次对下次错你根本不知道发生了什么。我的做法是全链路记录每次请求记录输入、检索到的文档、组装的prompt、模型原始输出、工具调用记录、最终输出。这些数据存下来出问题时可以回放。同时做质量监控用规则或小模型对输出做自动评估比如是否包含敏感词、是否格式正确、是否答非所问异常时告警。注意记录prompt和输出时要注意隐私合规。用户输入可能包含个人信息存储前要脱敏存储期限要明确。6. 我在实际项目里踩过的几个典型坑第一个坑是过度设计。刚开始做AI应用时我总想把架构做得完整——加缓存、加队列、加多Agent、加监控结果系统复杂度上去了开发速度下来了很多功能根本用不上。后来我学乖了先跑通最小闭环再按需加东西。一个对话应用先做到能稳定回答再考虑缓存和监控。第二个坑是忽视prompt的版本管理。prompt是AI应用的核心资产但很多人把它硬编码在代码里改一次要发一次版。我现在的做法是prompt存在配置中心或数据库里支持热更新每次修改记录版本和效果指标。这样调prompt不用发版A/B测试也方便。第三个坑是对模型能力估计过高。有些任务模型确实做不好比如精确计算、复杂逻辑推理。硬让模型做不如把任务拆解该用代码的用代码该用模型的用模型。架构设计的一个原则是能用确定性代码解决的不要交给模型。第四个坑是忽略冷启动。新上线的AI应用没有历史数据缓存命中率低检索效果差。这时候要么先用规则兜底要么用合成数据预热。我一般会准备一批常见问题上线前先跑一遍把结果缓存起来。7. 一套可落地的AI应用架构参考把上面的内容串起来给一个我实际用过的架构参考。这套架构适合中等规模的AI应用日调用量在十万到百万级别。接入层API网关负责鉴权、限流、路由。所有请求先到这里根据用户等级和任务类型分发。编排层Agent调度器维护会话状态决定用哪个Agent处理。单Agent场景下这层很薄多Agent场景下负责任务分配和结果汇总。能力层RAG检索服务、工具调用服务、记忆服务。每个服务独立部署通过内部接口通信。RAG服务包含向量库、关键词索引、重排序模型工具服务包含工具注册、权限校验、执行引擎记忆服务包含短期记忆存储和长期记忆存储。模型层模型路由 模型池。路由根据任务类型和模型健康状态选择模型模型池包含云端API和本地部署模型。基础设施日志、监控、缓存、消息队列。这些是支撑性的但缺了哪个都会出问题。这套架构不是唯一解也不是最优解但它是我在多个项目里验证过能跑通的。你可以根据自己的场景裁剪——小项目可能只需要接入层模型层大项目可能还要加数据飞轮、模型微调流水线。最后说一个我越来越深的体会AI应用架构的核心不是技术选型而是对不确定性的管理。模型会出错、工具会失败、用户会问奇怪的问题架构的价值就是让这些不确定性在可控范围内。把这一点想清楚很多设计决策就自然清晰了。
