1. 从一张架构图说起AI应用到底由哪些层组成很多人第一次接触AI应用开发脑子里冒出来的第一个问题不是“怎么写代码”而是“这东西到底长什么样”。我刚开始做AI应用的时候也有这个困惑——网上文章要么讲得太虚全是“感知、决策、执行”这种大词要么一上来就甩代码连整体轮廓都没交代清楚。后来我养成了一个习惯拿到任何一个AI应用先逼自己在纸上画一张架构图画不出来就说明还没真正理解它。这张图不需要多漂亮但必须能回答几个问题用户输入从哪进来中间经过哪些处理环节模型在哪里被调用结果怎么返回状态存在哪出了问题去哪查把这几个问题回答清楚一个AI应用的骨架就立起来了。从工程视角看一个典型的AI应用架构可以拆成五层。接入层负责和用户打交道可能是Web界面、API网关、聊天窗口也可能是某个桌面软件的插件。编排层是整个应用的大脑决定一次请求要经过哪些步骤、调用哪些工具、什么时候该让模型做决策、什么时候走固定逻辑。模型层包含实际调用的大语言模型LLM可能是一个也可能是多个可能走云端API也可能跑在本地。工具与数据层是模型伸手去够外部世界的地方包括MCP工具、数据库、文件系统、第三方API。基础设施层则是支撑这一切运行的东西——日志、监控、缓存、密钥管理、限流。这五层不是教科书上的标准答案而是我在实际项目里反复调整后觉得最顺手的划分方式。它的好处是每一层职责清晰出问题的时候能快速定位是哪一层的锅。比如用户说“回答太慢”你顺着图一看是接入层网络问题编排层步骤太多模型层本身慢还是工具调用卡住了一层层排查比漫无目的地翻代码高效得多。画架构图这件事重点不在于画得好看而在于逼自己把每个模块的输入输出想清楚。想不清楚的地方就是后面会出bug的地方。2. 编排层才是AI应用真正的“大脑”2.1 为什么说编排层决定了应用的上限很多人以为AI应用的核心是模型模型越强应用就越强。这话对了一半。模型确实重要但在实际工程中编排层才是决定一个AI应用好不好用的关键。同一个模型编排做得好和做得差用户体验能差出十万八千里。举个具体的例子。用户问“帮我查一下上个月的销售数据然后做个同比分析”。一个粗糙的编排是这样的把这句话直接丢给模型模型要么说“我无法访问你的数据库”要么胡编一个数据。而一个好的编排会这样处理先让模型理解意图识别出这是一个“数据查询分析”的复合任务然后调用数据库查询工具拿到真实数据接着把数据交给模型做分析最后格式化输出。整个过程模型被调用了多次每次职责单一结果就可靠得多。编排层的核心工作可以归纳成三件事任务分解、工具调度、状态管理。任务分解是把用户的模糊需求拆成可执行的步骤工具调度是决定每一步该调用哪个工具、传什么参数状态管理是记住上下文让多轮对话和多步任务能连贯进行。这三件事做扎实了应用的基本盘就稳了。2.2 从ReAct到Plan-and-Execute编排模式的演进早期做Agent编排最常用的是ReAct模式——推理加行动交替进行。模型先想一步Reasoning决定做什么然后执行一个动作Action观察结果Observation再想下一步。这个模式简单直观适合步骤不多的任务。但它有个明显的问题容易在长任务中迷失。因为模型每一步都只看眼前缺乏全局规划走到后面可能忘了最初的目标。后来Plan-and-Execute模式流行起来。思路是先让模型制定一个完整计划把任务拆成若干步骤然后逐步执行。执行过程中如果遇到意外再触发重新规划。这个模式对复杂任务友好得多因为有了全局视角。但代价是前期规划可能不准而且规划本身也要消耗token。我在实际项目里的做法是混合使用对于步骤少于五步的简单任务直接用ReAct省时省力对于复杂任务先走一轮轻量规划生成步骤列表然后逐步执行每执行完一步检查一下是否偏离目标偏了就重新规划。这个策略在大多数场景下都能兼顾效率和可靠性。2.3 状态管理被低估的工程难点状态管理是编排层里最容易被低估的部分。很多人一开始用简单的对话历史数组存上下文跑demo没问题一上生产就出问题。问题出在几个地方对话历史越来越长token消耗爆炸多用户并发时状态互相污染任务执行到一半崩溃重启后状态丢失。我的经验是状态管理要分三层来做。会话状态存当前对话的上下文需要做窗口截断或摘要压缩避免无限增长。任务状态存当前任务的执行进度比如已经完成了哪几步、中间结果是什么这个要持久化崩溃后能恢复。用户状态存跨会话的偏好和记忆比如用户习惯用什么格式、之前聊过什么话题这个可以存数据库或向量库。状态管理做不好应用就像金鱼记忆每轮对话都从零开始。做得好用户会觉得“它记得我”体验完全不同。3. 模型层选型不是越强越好而是越合适越好3.1 云端API与本地部署的取舍模型层的第一个决策是用云端API还是本地部署这个问题没有标准答案取决于你的场景。云端API的优势是省心不用管硬件、不用管运维、模型能力通常也更强。劣势是数据要出本地、有网络延迟、按量计费长期成本可能不低。本地部署的优势是数据可控、无网络依赖、长期成本固定。劣势是硬件投入大、模型能力受限于你能跑动的规模、运维复杂。我一般这样判断如果应用涉及敏感数据、或者对延迟极其敏感、或者调用量巨大且稳定考虑本地部署如果追求快速上线、模型能力要求高、调用量波动大先用云端API。很多项目其实是混合的——核心敏感逻辑走本地小模型复杂推理走云端大模型。3.2 模型能力与成本的平衡点怎么找选模型不是选最强的而是选最合适的。我见过太多项目一上来就用最贵的模型结果成本失控。正确的做法是按任务分级。简单任务比如意图识别、格式转换、简单问答用轻量模型就够了复杂任务比如多步推理、代码生成、长文分析才上大模型。具体怎么找平衡点我的方法是做A/B测试。同一个任务分别用轻量模型和重量模型跑一批样本对比准确率和成本。如果轻量模型准确率能到90%以上而成本只有十分之一那大部分流量就该走轻量模型只把轻量模型搞不定的case升级到重量模型。这个“路由”逻辑本身也可以让一个小模型来判断。任务类型推荐模型档位理由意图识别、分类轻量任务简单准确率差异小简单问答、摘要轻量到中档质量要求中等成本敏感多步推理、规划中档到高档需要较强推理能力代码生成、复杂分析高档能力差距明显值得花成本3.3 多模型协作的常见坑多模型协作听起来很美——各取所长实际上坑不少。第一个坑是格式不一致。不同模型对同一个prompt的输出格式可能不同A模型返回JSONB模型返回带markdown的JSON解析起来很头疼。解决办法是在prompt里严格约束格式并且在解析层做容错。第二个坑是上下文传递损耗。模型A的输出要传给模型B中间如果经过压缩或转换信息可能丢失。我的做法是尽量传递结构化数据而不是自然语言减少歧义。第三个坑是错误传播。A模型错了B模型基于错误输入继续错最后结果离谱。所以关键节点要有校验发现异常及时中断或重试。4. MCP与工具层让模型真正“能干活”4.1 MCP解决了什么问题MCPModel Context Protocol这两年被讨论得很多但很多人没搞明白它到底解决什么问题。简单说MCP是一套让模型和外部工具对话的标准协议。在MCP之前每接一个工具就要写一套适配代码工具多了维护成本爆炸。MCP把这些适配标准化了工具提供方按协议暴露能力应用方按协议调用双方解耦。打个比方以前的工具集成像是每个电器配一个专用插座形状各异MCP像是统一了插座标准什么电器都能插。这个类比不完全准确但能帮你理解它的价值——降低集成成本提高复用性。4.2 工具设计的三条实用原则工具设计直接决定模型能不能用好它们。我总结了三条原则。第一工具描述要像写给新员工的说明书。模型不了解你的业务描述里要说清楚这个工具做什么、什么时候用、参数什么意思、返回什么。描述写得含糊模型就会乱用或不用。第二参数设计要防呆。能枚举的就别用自由文本能设默认值的就别强制传能校验的就在入口校验。模型不是万能的它会传错参数好的设计能让它在犯错时得到清晰反馈而不是莫名其妙失败。第三工具粒度要适中。太粗的工具比如一个“处理数据”工具什么都干模型不知道怎么用太细的工具比如把查询拆成十步模型要调十次又慢又容易错。我的经验是一个工具对应一个完整的、有明确语义的操作比如“查询订单状态”“发送邮件”“计算同比”而不是“执行SQL”这种底层操作。4.3 工具调用失败的容错设计工具调用失败是常态不是异常。网络会抖、API会限流、参数会传错、返回会超时。容错设计要做在几个层面。重试对于瞬时故障自动重试两三次但要有退避策略别把对方打挂。降级主工具挂了有没有备选方案比如主搜索API挂了能不能走备用搜索兜底实在不行给用户一个清晰的错误提示而不是让整个应用卡死。我踩过最大的坑是没做超时控制一个工具调用卡住整个请求就挂在那用户等半天没反应。后来所有工具调用都强制设超时超时就中断并返回部分结果或错误提示。5. 记忆与上下文AI应用的“记性”怎么设计5.1 短期记忆与长期记忆的分工AI应用的记忆分两种。短期记忆是当前会话的上下文存在内存或缓存里会话结束就清掉。长期记忆是跨会话的信息比如用户偏好、历史事实存在数据库或向量库里。两者分工明确不能混。短期记忆的关键是控制长度。对话轮次多了上下文会超出模型窗口。常见做法是滑动窗口只保留最近N轮或者摘要压缩把早期对话总结成一段话。滑动窗口简单但会丢信息摘要压缩保留信息但增加一次模型调用。我一般用混合策略最近几轮保留原文更早的做摘要。长期记忆的关键是检索准确。存进去容易取出来难。用户问一个问题怎么从海量记忆里找到相关的那几条向量检索是常用方案但纯向量检索有时不准。我的做法是向量检索加关键词检索混合再让模型做一次相关性排序效果比单一方案好不少。5.2 上下文窗口的工程处理上下文窗口是硬约束处理不好应用就崩。除了上面说的截断和摘要还有几个技巧。按重要性排序把最重要的信息放在上下文开头或结尾中间部分模型容易忽略。结构化组织用清晰的标记分隔不同部分比如“以下是历史对话”“以下是检索到的资料”“以下是当前问题”让模型知道每段是什么。动态裁剪根据当前任务只保留相关上下文不相关的先放一边需要时再取。5.3 记忆污染与一致性维护记忆用久了会“脏”。用户改了主意旧记忆还在事实变了旧记忆没更新错误信息被存进去后面一直被引用。这就是所谓的记忆污染。维护一致性要做几件事写入时校验明显矛盾的信息不要存定期清理过期的、低价值的记忆删掉冲突检测新记忆和旧记忆矛盾时以新的为准并标记旧的失效。6. 可靠性工程让AI应用不“抽风”6.1 输出校验与兜底策略模型输出不可控这是AI应用和传统软件最大的区别。传统软件输入确定输出就确定AI应用同样的输入可能给出不同输出。所以输出校验是必须的。校验分两层格式校验比如要求JSON就检查是不是合法JSON内容校验比如要求回答不能包含某些信息就做关键词或分类检查。校验不通过怎么办重试是一种但要有次数上限别陷入死循环。降级是另一种比如模型输出格式错了用一个规则解析器尽量提取有用信息。兜底是最后手段返回一个预设的安全回复并记录日志供后续分析。6.2 可观测性日志、追踪与评估AI应用出问题排查比传统应用难因为中间有模型这个黑盒。所以可观测性要做足。日志要记录每次请求的完整链路输入是什么、编排走了哪些步骤、每步调用了什么工具、模型返回了什么、最终输出是什么。追踪要给每个请求一个唯一ID方便串联所有相关日志。评估要定期跑一批测试用例监控准确率、延迟、成本的变化。我习惯在开发阶段就把日志打全宁可多打也别漏。上线后遇到问题第一件事就是翻日志看是哪一步出的岔子。没有日志的AI应用出问题就是抓瞎。6.3 限流、降级与熔断生产环境和demo最大的区别是流量。demo跑一个请求生产可能同时跑几百上千个。限流防止系统被压垮按用户、按接口、按模型分别限。降级在资源紧张时保证核心功能可用非核心功能先关掉。熔断在某个依赖持续失败时快速失败避免拖垮整个系统。这些机制在传统后端开发里很成熟但AI应用有它的特殊性。比如模型调用比普通API慢得多限流的阈值要重新算模型调用成本高降级策略要考虑成本模型可能返回慢而不是失败熔断的判断条件要调整。7. 从架构图到可运行系统落地路径7.1 最小可行架构的搭建顺序别一上来就追求完美架构先跑通最小闭环。我的建议顺序是第一步接入层加模型层做一个最简单的问答验证模型能通。第二步加编排层把单轮问答扩展成多步任务。第三步加工具层接一两个核心工具让模型能干活。第四步加记忆和状态管理支持多轮对话。第五步加可观测性和容错准备上生产。每一步都跑通了再加下一步别跳步。跳步的后果是出了问题不知道是哪层的锅排查成本极高。7.2 迭代节奏与常见返工点AI应用的迭代和传统软件不太一样因为模型行为有不确定性很多问题要跑起来才发现。常见的返工点有几个。prompt反复调一开始写的prompt往往不够好要基于实际输出反复优化。工具接口反复改模型用不好工具往往是接口设计问题要改。编排逻辑反复调任务分解粒度、重试策略、超时时间都要根据实际表现调整。我的经验是前期把编排层和工具层的接口设计得灵活一点方便后面调整。别把逻辑写死留出配置和扩展的空间。7.3 上线前的检查清单上线前我会过一遍这个清单模型调用有没有超时和重试工具调用有没有容错输出有没有校验日志打全了吗限流配了吗成本监控有了吗敏感信息过滤了吗异常情况有没有兜底回复这些看起来琐碎但每一条都是踩过坑之后加的。架构设计这件事说到底是在灵活性和复杂度之间找平衡。层分得太细维护成本高分得太粗扩展性差。我的原则是当前够用、未来好改就是好架构。别为了架构而架构能跑通、能维护、能扩展比什么都强。