从“接个API”到“画明白架构图”中间隔着多少个坑这两年我看了太多AI应用项目的架构设计文档。有个现象特别有意思很多团队拿到一个AI应用需求第一版架构图画出来就是一个浏览器框、一个后端框、一个数据库框然后再画一个大方块写着“LLM API”。没了。等到真正开始开发、联调、上线问题才一个个爆出来上下文塞爆了、响应太慢、Agent跑飞了、多轮对话记忆对不上、模型换了提示词又不好使了……问题出在哪出在很多人还在用传统Web应用的心态去画AI应用的架构图。传统应用处理的是确定性逻辑请求进来代码走一遍分支数据库查一次返回结果。AI应用本质上是概率性决策加动态工具编排它不是一个“输入-处理-输出”的直线而是模型在多个节点上做判断、决定要不要调工具、决定怎么整合上下文的一个环路。架构图如果还按照老方法画画出来的一定是错的或者说是“画了等于没画”。这篇文章我想把我画AI应用架构图的一些经验和思路完整梳理一遍。包括怎么理解AI应用的组成单元、怎么分层、怎么表达Agent这种动态过程、以及哪些设计权衡必须在图里就体现出来。内容比较多但能保证每一段都是实操中的真实体会。1. 为什么传统应用架构图画不出AI应用——从“确定性”到“概率性”的转变1.1 传统Web的“确定性问题域” vs AI应用的“概率性决策”先明确一个核心差异。传统Web应用里所有逻辑都是可枚举的。用户点了“注册”按钮后端校验参数、写数据库、发邮件每一步都是确定的。你可以画一个非常精确的流程图每个分支都有明确的触发条件。这种系统的架构图本质上是一张数据流加状态机的图。AI应用不一样。你给模型一个用户的自然语言输入模型输出什么在生成之前没人能100%确定。它会根据提示词、上下文、温度参数做出一个概率性判断。这就意味着架构图上很多节点之间的连接关系不再是“A调用B”而是“A根据模型判断结果决定要不要调用B、调用哪个B、调用完B的结果再喂回给A做下一轮判断”。这种差异带来的直接后果是传统架构图中的控制流画法是“实线加箭头”AI应用架构图里的决策路径是“虚线加问号”。如果整张图全是实线箭头一定是在用一个伪确定性的思路设计AI应用后期必然出问题。1.2 AI应用引入的三大新元素模型、记忆、工具传统Web应用也有状态、也有第三方依赖但AI应用多出了三个传统架构图里没有的构成元素。第一是模型。模型不是一个简单的外部API它本身是系统的“推理核心”。它同时承担了意图理解、任务规划、内容生成、结果校验等多个职责。模型的能力边界、上下文窗口、输出延迟直接决定了架构的天花板。架构图里必须体现模型在整个链路中的位置而不是塞在一个角落写个“调用GPT”。第二是记忆。传统应用的“会话状态”就是存个session ID加一堆变量。AI应用的多轮对话、个性化服务、长期用户画像都需要一种分层记忆体系——短期记忆当前对话上下文、业务记忆用户订单、偏好、长期记忆历史对话摘要、行为模式。记忆放哪里、怎么存取、哪些记忆要进Token、哪些记忆只在需要时检索这是架构设计里绕不开的问题。第三是工具。AI应用里的Agent需要通过工具与外部世界交互查数据库、调搜索、发邮件、操作第三方系统。工具不是简单的外部依赖而是模型“可以用手抓东西”的延伸。这就需要在架构里单独规划一个工具注册与调用的层统一管理工具的schema、权限、执行结果回传。1.3 架构师思维转变从“数据流”到“决策流”我自己画AI应用架构图最大的一个转变是不再把用户请求当成一条“数据流”而是当成一条“决策流”。传统架构里数据是主角逻辑是配角。你关心数据从哪里来、往哪里去、在哪里被写入。AI应用架构里决策是主角。模型的每一次输出都是一个决策架构要回答的问题是这个决策在哪一层做出、依据什么做出、失败之后怎么办、决策结果如何被验证。举个例子。用户说“帮我查一下昨天订单的物流状态”。传统架构的思维是解析请求参数查订单表调物流接口返回结果。AI架构的思维是先让模型理解意图这是个查询请求、提取实体订单、时间范围、决定是否需要调工具查订单、查物流、把工具结果组织成回复、同时还要判断是否需要追问用户订单号没提出来要不要反问。这条链路里每一步都是模型在做决策。架构图必须把这个“决策节点”显式画出来并且标清楚每个决策节点的输入是什么、可选分支是什么、兜底策略是什么。这就引出下面要讲的五层结构——我建议所有AI应用架构图都围绕这五层来画。2. 一张图读懂AI应用的五层核心结构接入、编排、模型、知识、记忆经过一段时间的反复实践我总结了一套AI应用架构的分层方法。不一定适合所有场景但大多数中大型AI应用项目照这个框架去画都不会漏掉关键模块。2.1 接入与交互层不只有聊天窗口接入层最容易画但也最容易画错。很多人直接在架构图最左边画一个“Web前端”框完事。实际上接入层要表达的内容远不止一个前端。首先要看交互形态。是单轮问答、多轮对话、还是流程式表单交互是纯文本、图文、还是语音不同形态对后端的编排层有完全不同的要求。比如纯对话场景后端要管理多轮上下文流程式表单交互则需要强状态管理每一步都要校验用户输入和模型输出的格式。其次要看渠道。同一个AI能力可能同时暴露给Web端、小程序、企业微信、开放API等多个渠道。每个渠道的鉴权方式、限流策略、消息格式都不同。架构图上至少要标出统一的API网关以及渠道适配器不能让每个渠道直接穿透到业务层。还要考虑流式输出。大模型生成内容需要时间用户体验要求你一个字一个字地吐出来。这意味着接入层和编排层之间的通信协议要支持SSEServer-Sent Events或WebSocket而不是简单的HTTP请求响应。很多团队第一版架构图没画流式通道后期强行加连接管理、断线重连、流量控制全是一堆坑。2.2 编排层唯一的“大脑容器”五层结构里编排层是AI应用架构的核心也是人和人之间架构图差异最大的地方。编排层解决的核心问题是模型在什么流程里做决策。它承载的是Agent运行时、任务规划器、状态机、工具调度逻辑。如果用LangGraph或者其他Agent框架这一层就是你画Graph的地方。如果自己写编排这一层就是你的工作流引擎。编排层在架构图上必须表达清楚三件事。第一编排流程的类型。是这个请求走的是单轮直答用户问一句模型直接答还是走ReAct循环模型Think→Act→Observe不断循环还是走一个预设的多步骤工作流先规划、再执行、再校验、再回答。不同类型的流程复杂度完全不同。第二状态管理。编排层要不要维护一个会话级的状态对象状态里存哪些字段状态在哪个环节被读取、被更新这些问题直接关系到后续多轮对话和任务中断恢复的实现方式。第三与模型层的交互方式。编排层和模型层是“一个请求一个响应”还是“流式多轮交互”Agent场景下通常是后者——模型输出一个工具调用指令编排层收到后执行工具把结果追加进消息列表再次请求模型。这个循环是编排层最重要的控制流架构图上要用带编号的步骤标清楚。我把编排层叫“大脑容器”是因为它本身不产生智能但它决定了智能能在什么范围内发挥。同一个模型放在一个设计糟糕的编排流程里表现可能不如一个设计良好的流程里的小模型。2.3 模型层与模型网关模型层解决的是”到底用哪个模型“的问题。这一层在架构图上不只是画一个”GPT-4”的框而是要画出一个模型网关。为什么要有模型网关因为你在生产环境里几乎不可能只用一个模型。日常对话可能用一个通用模型复杂推理可能需要更强的主力模型摘要提取可能用一个便宜的小模型图片理解又要单独一个多模态模型。更麻烦的是同一个模型可能有多个供应商渠道或者需要配置不同的版本、不同的地域节点。模型网关要做的事情包括统一接入屏蔽不同厂商API的差异、路由转发根据请求类型路由到不同模型或不同供应商、弹性容灾主供应商超时降级到备用渠道、成本与额度管理跟踪每个模型的调用量、Token消耗。在架构图上模型网关应该画成一个独立的服务所有模型调用都经过它而不是每个服务各自直连模型API。还有一个容易忽略的点是Prompt管理与模板服务。生产级的AI应用不会把Prompt写在业务代码里而是有一个独立的Prompt管理模块存放不同场景的提示词模板、做版本管理、支持A/B测试。这个模块在架构图上可以放模型层旁边它是模型调用的“前置配置”。2.4 知识层RAG不是必须但要有位置很多AI应用需要结合私有知识库回答用户问题这就用到RAG检索增强生成。架构图上知识层要表达的核心组件是文档解析与索引管线、向量数据库、检索服务。我强调”RAG不是必须“是因为不是所有AI应用都需要搭一套完整的RAG。如果业务知识量小、变化慢可能把知识写进Prompt就够。但如果知识库大、更新频繁、或者对答案准确性有高要求RAG就是核心模块。知识层在架构图上的关键信息有三个。一是数据来源知识库的原始数据从哪里来人工录入、爬虫、业务系统同步二是更新频率数据是离线批量更新还是实时增量同步这决定了索引管线的设计。三是检索策略是单纯的向量相似度检索还是混合检索关键词向量需不需要重排序模型这些如果梳理不清楚架构图画出来知识层就是一个孤零零的“向量数据库”框没有任何设计含量。2.5 记忆层短期记忆和长期记忆的落位记忆层是我见过被忽略得最严重的一层。很多人画AI应用架构图根本不画记忆仿佛模型天然记得所有对话历史。实际上模型什么都不记得所有上下文都是你显式塞给它的。架构层面记忆层至少要做两层设计。短期记忆对应“当前会话上下文”。实现方式有两种一种是把完整的对话历史按Token限制截断后随每次请求发送另一种是用滑动窗口加摘要压缩太长的历史先摘要再发送。架构图上要标清楚记忆存储在哪里Redis或内存、上下文窗口上限是多少、摘要触发条件是什么。长期记忆对应“跨会话的信息沉淀”。用户上次说了自己的需求偏好下次再来系统要能想起来。这块通常需要一个独立的记忆存储数据库或向量库在合适的时机把对话中提取出的关键信息写入在后续会话中检索出来作为Prompt的一部分。长期记忆的设计在架构图上要能看出谁负责提取信息、存到哪里、什么时候被读取。3. 骨架搭建从一条最简单的请求链路开始画图前面的分层是理论框架真正动手画图时我有一套自己固定的顺序。每次都从一条最简请求链路开始逐步加厚。3.1 第一步先画一条“主链路”不管系统多复杂先画核心链路用户进来、编排层接住、调用模型、返回结果。不要加任何修饰。比如一个客服机器人最简链路就是用户输入 → 接入层 → 编排层判断意图→ 模型层生成回复→ 返回输出这一步的核心目的是确定数据的起点和终点。起点是用户的自然语言输入终点是系统生成的自然语言响应。中间多少个节点、哪些分支后面再加。3.2 第二步把数据依赖补上去主链路上每一根线问自己一个问题这个节点正常运行需要什么数据模型生成回复时需不需要业务数据如果需要是从哪来是直接查业务库还是通过工具调用查询需不需要查知识库做RAG如果需要向量化和检索的管线画在哪里多轮对话时历史上下文从哪取是编排层自己管理还是有一层独立的记忆存储补数据依赖的过程你会发现主链路旁边逐渐长出几个支撑模块知识库、记忆存储、业务API。这些不是主链路节点而是主链路上模型决策的信息来源。架构图上它们应该画在主链路的旁边用带方向的线标出数据流向不要画成串行链路。3.3 第三步把控制流变成“可回退的环”普通请求链路的控制流是直线AI应用的Agent链路是环。第三步就是把这个“环”画出来。具体来说模型生成的不是最终答案而是一个工具调用指令比如“调用查询订单接口参数是订单号XXX”。编排层拿到指令后执行工具把结果回传给模型模型根据工具结果再生成下一轮指令或最终答案。这个循环在架构图上通常表现为编排层 → 模型层 → 工具层 → 编排层 → 模型层。画法上我习惯用带序号的小圆圈标出循环次序第一步模型输出工具调用第二步编排层调度工具第三步工具结果返回第四步编排层把结果追加上下文后再次请求模型。3.4 一个具体例子客户问答机器人架构图展开一个具体例子方便直观理解。假设做一个电商客服问答机器人支持查询订单、咨询售后政策、闲聊。画这张图时主链路是用户消息 → 接入层 → 编排层 → 模型层 → 回复用户。编排层内部画一个简单的意图路由意图识别用模型做识别结果分三路。查询订单意图进入订单工具调用子流程售后咨询意图检索售后知识库回答闲聊意图直接生成回复。旁边画三个支撑模块。一是业务工具层封装查询订单API、查询物流API每个工具提供名称、描述、参数Schema。二是知识层售后政策文档经过离线解析、向量化后存入向量库检索服务按用户问题查询TopK段落。三是记忆层当前会话历史存储在Redis按最近N条消息生成上下文同时把用户ID、购买偏好等结构化信息沉淀到长期记忆库。这张图的核心路径就是那个“调用工具→拿到结果→再生成回复”的环。只要这个环节画清楚了整个系统的骨架就立起来了。4. 架构图里的“动态灵魂”Agent、工具调用与多模型协作的绘图方法静态的分层架构图画完之后真正的难点来了怎么表达Agent的动态行为。这是目前AI应用架构图和传统架构图差异最大的地方。4.1 静态分层图说不清楚Agent流程分层图能表达“有什么模块、模块之间什么关系”但表达不了“一次完整的Agent任务是怎么在模块间流转的”。比如一个研究助理Agent用户让它调研某个行业。它需要先拆解调研问题为多个子课题然后针对每个子课题搜索相关网页、阅读文本、提炼要点、交叉验证最后汇总成一份报告。这个过程不是简单的分层图能表达的——它的流转路径是分叉的、并行的、循环的。我的做法是一张图不够用两张图。一张是逻辑分层图表达系统有哪些模块另一张是行为流程图用泳道或时序的方式表达一次任务的完整流转路径。行为流程图重点是表达“同一份数据在不同Actor用户、编排层、模型、工具、知识库之间的流动和加工过程”。具体形式我推荐泳道时序图横向按Actor分泳道纵向按时间顺序排列消息与动作。每个动作标注是谁发出的、输入是什么、输出是什么、调用了哪个工具、耗时大概多少。画完之后整个Agent的执行过程一目了然。4.2 用时序图表达ReAct循环ReAct循环是Agent最经典的执行模式Reason推理→ Act行动→ Observe观察→ 再Reason。在时序图里表达这个循环我习惯画三层嵌套。外层是用户与Agent的对话消息。中间层是Agent内部多个轮次的循环——每一轮循环对应一次Reason和一次Act。内层是工具调用的细节——哪个工具、传了什么参数、返回了什么结果、工具结果是否满足预期。举一个典型的例子。用户说“帮我查一下北京明天适合穿什么衣服”。第一轮Reason模型判断需要查询北京明天天气Act调用天气查询工具参数city北京,date明天Observe工具返回气温10-18度、小雨。第二轮Reason模型根据天气信息推理生成穿衣建议同时判断是否需要补充查询湿度或降水概率如果不需要直接输出最终回答。这个在两轮循环内的流转路径在时序图上要一格一格画清楚。为什么要在架构图阶段就做这个动作因为画一遍ReAct循环等于把Agent的状态流转逻辑从头到尾走了一遍很多隐藏问题会直接暴露出来。比如模型调用工具的时空顺序问题——如果工具A的输出是工具B的输入时序图上就画出一条明确的依赖边如果没画这条边说明你的编排器没有约束工具执行的先后顺序运行时就可能乱套。4.3 工具调用架构图上必须预留“工具注册表”Agent的工具调用和普通REST API调用有个本质区别模型不“知道”有哪些API可用除非你把每个工具的描述和参数Schema注入到Prompt里。所以架构上必须有一个工具注册表模块。工具注册表干三件事。一是注册每个新工具上线时把名称、功能描述、参数Schema注册进来二是发现与注入编排层按需从注册表中选择相关工具把工具信息拼进Prompt三是执行与校验模型返回一个工具调用请求后按注册表的参数定义做格式校验再路由到具体执行器。架构图里工具注册表应该画在编排层和工具层之间的连接位置。它决定了模型的“行动边界”有多大——注册表里没有的工具模型永远调用不到。这也是一种安全设计你想限制Agent只能访问某些系统那就只把允许访问的工具注册进去模型就不会跨出这个边界。4.4 多模型/多Agent协作的三种拓扑再往复杂走就是多Agent协作系统。不是所有的AI应用都需要多Agent但一旦需要架构图上的拓扑结构有三种常见模式。第一种是路由分发模式一个主Agent接收用户请求根据意图把任务分发给多个专业Agent客服Agent、数据分析Agent、内容生成Agent各自完成后汇总结果。架构图上主干清晰适合垂直场景。第二种是流水线模式一个任务按固定流程拆成多个阶段每个阶段由一个Agent负责前一个Agent的输出作为后一个Agent的输入。适合流程固定的内容生产类任务但链路里任何一环出错都会影响最终结果图上应该画出每个阶段的质量校验节点。第三种是协商协作模式多个Agent没有固定的主从关系通过消息通信共同推进任务。这是复杂度最高的模式也最难控制。架构图上通常会有一个协调者组件负责消息分发和冲突处理如果图画出来没有协调者却有一堆Agent互相直连那这个系统大概率会失控。画多Agent结构时我的建议是先用路由分发模式起步跑通后按需演进。不要一开始就设计一个Agent社会大概率会把自己绕进去。5. 画图之外的关键设计权衡上下文、RAG、成本与延迟、可观测性架构图的意义不只是画结构更是帮团队在同一张图上对齐关键设计决策。下面几个决策点我在画图时都会在旁标注出来很多时候它们直接决定架构的成与败。5.1 上下文窗口Token流要单独画一条线上下文窗口是AI应用架构最硬的天花板之一。模型一次能接收多少Token决定了你能给它的输入上限。而这个输入上限被对话历史、系统提示词、工具描述、检索出的知识片段、当前用户消息共同瓜分。这个矛盾在架构设计阶段的体现是上下文不能无限增长必须在一个固定预算内做分配。架构图上我建议单独画一条“Token预算线”标注出每条消息的预算组成。比如系统提示词占2000Token工具描述占1500Token检索知识最多占3000Token最近对话历史最多占4000Token当前用户消息预留1000Token。加起来约1.1万Token如果用的模型上下文是8K这个预算就超标了必须砍掉某些部分。画这条线的价值在于团队在开发时会很明确地知道哪些内容优先进入上下文哪些内容要在外围处理。比如历史对话过长时是直接截断还是做摘要压缩RAG检索结果太多时是裁掉TopK还是用重排序精化。这些实现层面的选择在设计阶段就应该在Token预算的约束下提前决定。5.2 RAG放哪里查询前、生成中、还是后置校验RAG的检索时机也是一个架构图上要明确的问题。最常见的做法是查询前检索用户问题进来先做向量检索拿到相关文档再把文档拼进Prompt让模型基于资料回答。这种方式实现简单但有个问题——用户问题里的实体可能表述不清直接拿原始问句去检索效果不好。进阶方案是先让模型把用户问题改写成一个更精确的检索查询再做检索。另一种是动态检索模型先根据问题判断是否需要外部知识如果需要在生成过程中触发检索再带着检索结果继续生成。这种方式更灵活但编排层的流程设计会更复杂。它特别适合那种“大部分问题不需要查知识库偶尔需要查一下”的场景。还有一种容易被忽略的是后置校验模型先生成答案然后拿答案里的关键信息去知识库里做核验发现不正确就重新生成或二次检索修正。这在医疗、法律这类对准确性要求极高的场景里特别好用。这三种RAG位置在架构图上用不同颜色的流线标注出来整个系统的知识使用逻辑立刻变得清晰。5.3 成本与延迟图上要标注“贵的路径”AI应用有个特点每一层都可能引入额外的一次模型调用而每次模型调用都在消耗金钱和时间。架构图如果不标注成本和延迟设计者很容易画出一种“豪华版”架构上面有十个Agent节点每个节点都要调一次大模型——确实很酷但跑一次完整请求可能要花几十秒、烧掉几块钱。我在架构图上会给不同路径标注等级普通路径、高成本路径、高风险路径。比如多Agent协作场景下每个Agent都用自己的模型调用主Agent还要汇总多次调用这条链路就是高成本路径。设计时就要考虑能不能降级某些子任务是否可以用小模型某些中间过程是否可以用缓存命中替代模型调用某些串行步骤是否可以并行发出请求延迟也是同样的道理。一个对话请求的端到端延迟由多个模型调用串行叠加而成——一次意图识别0.5秒一次检索0.1秒一次ReAct循环1.5秒可能还要再调一次模型生成最终回答总延迟轻松超过3秒。如果你画图的时候意识到这个时间累计自然就会思考意图识别能不能走一个小模型检索能不能提前预取历史上下文能不能缓存拼接5.4 可观测性与评测LLM的调试和传统监控不一样传统Web应用的监控三板斧日志、指标、链路追踪。AI应用这些都要但不够。因为AI系统的“错误”常常不是报错而是输出质量不可接受——模型生成了流畅但错误的内容没有异常没有堆栈一切都很正常但答案就是错的。架构图上我会单独画一个可观测性与评测模块并且明确两部分职责。第一部分是传统可观测性每次模型调用的请求参数、响应内容、Token消耗、延迟、成本全部记录到日志系统。这部分有一个特殊要求Prompt和响应正文必须完整记录。模型输出是概率性的出了质量问题唯一能排查的就是当时模型看到了什么输入所以Prompt日志不能省。第二部分是质量评测每次交互之后针对特定场景做输出质量评估。评估方式可以是规则校验比如必含字段是否齐全、格式是否正确也可以是用一个评测模型去给主模型打分还可以结合用户反馈点赞、点踩、是否复制答案。AI应用的质量不是一个上线前测试能搞定的问题需要在架构上具备持续评测的闭环能力。6. 踩过的一些坑架构图“画对了但做错了”的几种典型情况最后分享一下我在AI应用架构设计里踩过的一些比较典型的坑。这些坑的共同特点是架构图看起来没什么大问题但实现、运维、迭代时都付出了不小的代价。6.1 把供应商SDK当成核心组件第一版架构图上直接画了一个“OpenAI SDK”框所有服务都直连它。后来要接入国产模型做降级才发现SDK的调用散落在各个服务里改起来牵一发动全身。我的建议是架构图上模型层必须用模型网关抽象最迟在项目第一个里程碑之前加上。前期只用一个模型的时候不觉得有必要等到模型切换、多供应商容灾的需求一来网关就是你的救星。6.2 编排层退化成if-else地狱另一个反面案例是核心链路用编排层串起来了但每个节点的内部逻辑全是hard code的if-else。用户问天气就调天气API问订单就调订单API每个意图一句判断。刚开始还行等到意图种类变多、出现组合意图、需要多轮追问时这种硬编码的编排逻辑很快就会膨胀到无法维护。现在我会建议至少要把编排流程做成可配置的图结构——节点和边的定义从代码里抽出来放到配置文件或可视化的流程画布里。不一定要上LangGraph这种重型框架但基础的图结构设计比堆if-else要先进得多。6.3 Prompt里塞了整个业务逻辑这是一开始最容易犯的错误。大量业务规则、示例、边界情况全写进系统提示词导致系统提示词长达4000多Token。结果就是上下文预算被占掉大半、模型每次请求都消耗大量Token、修改业务逻辑时还要小心翼翼地改Prompt生怕影响其他部分的输出。正确的思路是能用代码实现的逻辑不要塞进PromptPrompt只保留“需要模型智能判断”的部分。比如订单超过30天不能退款这个规则应该用代码校验而不是要求模型理解并执行。架构图里应该有一个明确的“规则引擎”或“业务校验”模块在必要节点拦截和校验而不是把所有职责交给模型。6.4 没有兜底路径AI模型的输出是概率性的意味着它一定会出错。但很多架构图里没有设计出错时的兜底路径。兜底路径分几层。一是格式错误兜底模型返回的JSON无法解析或者工具调用参数缺失时编排层是重试一次、修正提示词再见一次还是放弃本次工具的调用并明确告知用户二是能力边界兜底用户提出的问题超出了系统边界比如让机器人算命、问敏感话题模型应该怎么拒绝三是服务降级兜底模型服务超时或不可用时是返回一个预设的应急话术还是切换到备用模型这些都要在架构图上明确标注而不仅仅是靠模型自己“随机应变”。6.5 架构图画了但没有人维护最后这点其实比任何技术细节都重要。架构图的价值在于它是团队的“活文档”随着系统迭代要持续更新。但我见过很多团队的架构图只在项目初期画过一次之后系统演进了好几版架构图还是老样子后来成员照着老图理解系统产生了大量误解。我现在的习惯是架构图和代码仓库放一起每次有重大结构变更都必须同步更新架构图。拆不拆分模块、新增工具、调整模型路由都需要在图上体现。否则等到图已经和实际系统产生严重偏差时它的参考价值就已经消失了甚至变成误导信息。说实话AI应用架构设计这件事说难也难说简单也简单。难在你需要同时理解模型能力边界、系统设计原则和业务流程简单在于只要把“决策流”这个概念想清楚画出来的图自然就能贴合实际。核心还是我之前强调的那句话不要画给外人看的漂亮图要画能在开发、联调、运维、迭代各个阶段真正指导团队做决策的一张“活地图”。多花一点时间在架构图阶段把该标的风险、该留的兜底、该画的循环都交代清楚后面省下来的时间绝对远超你的预期。