这两年聊AI应用架构很多人一上来就问用哪个框架、选哪个模型其实最该先想清楚的是一个更基础的问题你的系统里哪些决策交给模型做哪些决策交给代码做哪些决策必须留给人做。这个问题不掰扯清楚架构图画得再漂亮上线也是一地鸡毛。我打算从架构分层、核心组件、主流模式到落地实践把AI应用架构设计这件事掰开揉碎讲一遍。内容会面向正在做AI应用但不满足于“调个API就行”的开发者也适合准备从原型走向生产环境的团队。文章里不会有那种只能发朋友圈的“概念架构图”而是尽量给到能指导编码、能排查问题、能说服同事的实在拆解。1. 先从一张“全景图”理解AI应用架构1.1 架构分层不要把AI应用想成一坨代码我见过太多团队画架构图画出来就是一个框“AI”里面写着“大模型”。这不算架构设计最多算个示意图。真正的AI应用架构至少要分成五层来看基础设施层、模型接入层、Agent编排层、应用交互层、可观测运营层。每一层解决不同的问题而且每一层的技术选型和故障边界都不一样。基础设施层管算力、存储、网络模型接入层管API网关、模型路由、令牌管理Agent编排层管任务拆解、工具调度、状态管理应用交互层管对话界面、流式输出、权限控制可观测运营层管日志、指标、成本追踪和评估。五层缺一不可只是在不同阶段投入比重不同。理解分层的关键在于每一层都应该能独立升级、独立降级、独立排查。你说模型供应商明天升级了接口只有模型接入层要动用户反馈某条链路特别慢排查入口应该先落在编排层而不是模型层。如果所有逻辑搅在一坨代码里任何变更都是推倒重来这种架构不管图多好看都是不合格的。另外还要注意一个边界问题。很多团队习惯把“AI应用”和“普通后端服务”当成两套完全不同的系统来设计。这没必要也不对。AI应用仍然是应用数据库、缓存、消息队列、权限系统这些通用能力一个都少不了。新增的是模型调用、提示词管理、上下文处理这些AI特有环节。正确的分层方式是通用能力复用现有基础设施AI能力单独抽象成清晰模块两边通过接口通信。1.2 为什么需要Agent层而不是直接调模型有人问我直接在后端代码里调用模型API传一段prompt拿回结果返回给前端这不就是AI应用吗功能上是架构上不成立。一旦你想让AI完成多步骤任务比如查完订单再算运费再生成售后方案直接在业务代码里堆模型调用会变成一场灾难。Agent层的价值在于把“任务的拆解和执行”从业务代码中抽离出来。日常业务代码只需要向Agent层提交一个目标比如“用户请求退款并重新下单”Agent层负责判断需要调用哪几个工具、按什么顺序调用、中间结果如何处理、最终结果怎么组装。业务代码不再关心大模型的存在这样模型升级、提示词调整、工具替换都不会污染上游业务逻辑。实测下来Agent层的存在还有一个容易被忽略的好处让模型的行为可以被约束和控制。直接在业务代码里调模型模型返回什么业务就接受什么一旦输出格式不符合预期只能靠PTompt反复调试。有了Agent层你可以对模型的每一次输出做结构化校验、做格式修正、做分支重试甚至可以把模型拒绝执行的不确定性行为交给人工兜底。说白了Agent层就是把“模型的不可控”关在一个笼子里不让它在系统里乱跑。1.3 图解心智一张架构图应该画清楚什么“图解AI应用架构”的重点在“图解”但多数人画架构图的姿势有问题。我评审过不少团队的架构图最常见的问题是只画组件、不画关系。堆了十几个框框之间连了几条线但没人说得清数据流从哪里来、到哪里去、失败时怎么处理。一张能指导开发的架构图至少要画清楚四件事第一请求入口和响应出口的流向第二编排层和模型层、工具层的同步/异步边界第三状态存储的位置和生命周期第四监控、日志、成本数据的汇聚路径。其中最容易忽略的是同步/异步边界。AI应用有一个天然特点模型推理慢动辄几秒几十秒。如果你把所有调用都画成同步箭头图很好看但系统线上一定扛不住并发。我有个画图习惯每画一个组件必须顺手标注它的失败降级方案。用户登录服务挂了是降级成游客模式还是直接报错模型服务超时是重试还是返回缓存结果工具调用报错是终止任务还是换一条路径这些问题如果在架构图上没有答案这张图就只能给PPT用开发阶段帮不上忙。2. 核心组件拆解模型层、记忆层与工具层2.1 模型层选型、路由和上下文窗口的博弈模型层是整个AI架构的发动机但这台发动机不是越贵越好。选型核心看三件事任务复杂度、成本预算、响应延迟。一个做电商客服的团队来找我聊架构上来就说要接最强的推理模型我问他你的场景有多少比例需要真正复杂的多步推理他想了半天说可能不到10%。那就该考虑双模型路由90%的简单问答走轻量模型只有复杂任务才升级到强推理模型成本能降一个量级。模型路由听起来高深实现上就是一层转发逻辑。根据任务类型、输入长度、用户等级走不同模型。不过要注意路由判断本身也可能出错所以路由策略要保守一些宁可把简单问题发给复杂模型也别把复杂问题发给简单模型否则用户会明显感觉到“变笨了”。另外路由规则上的任何调整都得有日志记录方便追溯某次回答为什么质量出现问题。上下文窗口是另一个博弈点。很多人觉得上下文窗口越大越好这是个典型误区。窗口大意味着价格高、延迟高而且模型在超长上下文里注意力会分散反而可能忽略用户最新的一句话。架构设计上上下文窗口反而不该“无限容纳”而该做裁剪和压缩。系统里要有明确的token预算机制控制每轮请求进模型的有效token数超出的部分做摘要压缩或向量检索。价格上举个例子某主流模型的输入价格是每百万token几十元到上百元不等如果你的用户每个请求平均塞进2万token一天一万个请求那就是几百万token一个月跑下来光token费用就够难受的。所以模型层的架构核心不只是“选什么模型”更是“怎么省token”。提示词管理、上下文裁剪、结果缓存都是模型层必须考虑的工程问题。2.2 记忆层会话记忆、向量检索与长期知识AI应用的记忆是一个被严重低估的问题。用户很难接受一个“每次对话都失忆”的AI但记忆的存储和读取如果设计得不好会让架构变得极其臃肿。记忆按生命周期分三类会话内的短期记忆、跨会话的用户画像记忆、业务知识库的长期记忆。三类记忆的存储方式、读写时机、淘汰策略都不同不能混在一个库里面。短期记忆最直接就是把对话历史塞进上下文。但历史不能无限增长否则就是烧钱。业界常用窗口摘要的组合方式近N轮对话保留原文更早的内容由模型浓缩成摘要。摘要的生成时机很关键我建议放在每轮对话结束时异步做而不是在用户等待响应时同步做否则会拖慢响应速度。长期记忆和知识库最常用向量检索。这里有个常见误解以为向量数据库是唯一的记忆方案。其实不是。如果你的知识库只有几百条业务FAQ用普通数据库加上关键词匹配完全够用没必要引入向量库。只有当知识规模过万、检索复杂度上来之后向量检索的优势才体现出来。架构上建议做混合检索先用便宜的关键词召回一版再用向量做排序最后用重排模型精调效果远好于纯向量搜索。向量记忆的写入策略也容易踩坑。用户说完“我不喜欢打折促销”系统把这句话向量化存进去但下周用户又主动问促销活动旧向量还在召回之后模型会给出矛盾回答。解决方案是给记忆加“时间衰减”或“版本号”定期清理过期偏好或者用置信度权重决定是否覆盖旧记录。记忆层不是一个一次性写入的仓库它需要一套完整的生命周期管理。2.3 工具层给模型一套“可控的手”AI应用要落地模型必须能操作真实系统工具层就是模型和系统之间的桥梁。工具的本质很简单把函数或API包装成结构化描述告诉模型这个工具叫什么、能干什么、参数长什么样、应该在什么场景下调用。但这层包装的质量直接决定Agent的成功率。先说清楚一个观点给工具写描述要像给不认识的人写使用说明书不能只有短短一句话。很多团队工具描述就写“根据城市查天气”模型还真的不一定知道该传什么参数。至少要写清参数类型、必填项、取值范围以及常见的调用示例。我给团队培训时反复强调工具描述里的每一个字模型都会认真当prompt读写得越清晰模型的调用准确率越高。工具层的架构职责不只是描述还要做三层校验调用前校验参数合法性、调用中控制超时和重试、调用后校验返回值有效性。模型生成的参数经常“看起来合理但实际非法”比如日期格式不对、枚举值拼错。前端校验要挡住这批请求别让它们打到真实系统里造成脏数据。而对于下单、支付这类敏感工具必须做幂等设计同一笔订单重试多次不能产生多次扣款。工具调用失败的处理同样重要。真实系统不是每次都能成功外部接口会超时、会返回错误码。Agent架构里要定义清晰的失败传播规则工具失败后是重试、换工具、还是终止任务我见过不少Agent因为工具连续失败反复执行浪费了大量token和时间。工具层应该主动暴露“失败原因”和“可重试标记”让Agent根据标记决定行为而不是傻乎乎地重试。3. 主流架构模式从RAG到多Agent协作3.1 RAG架构的精髓检索不是全部重排和引用才是RAG检索增强生成现在是AI应用最主流的架构模式但不少人理解得比较浅以为就是“从向量库搜一段文本塞进prompt”。真正的RAG链路由四个环节组成文档预处理与切分、索引存储、召回排序、答案生成。每个环节都有独立优化空间缺一环效果就大打折扣。文档切分是整条链路的地基。很多人按固定字符数硬切比如一律切500个字符。这种切法会把一句话拦腰截断导致检索召回一堆语义不完整的片段。更合理的做法是按文档的语义结构切分以段落、小节为基本单位再根据模型的上下文预算合并相邻片段。切分粒度直接决定了后续检索质量这步偷懒后面全要还。召回阶段我建议做混合召回别只依赖向量。向量检索擅长语义匹配但关键词精确匹配反而会漏掉。比如用户搜“苹果13价格”向量可能召回一堆关于苹果公司的内容BM25关键词检索反而能准确命中商品页。混合召回之后再用重排模型精排序效果提升非常明显。重排模型虽然多一次调用但能把准确率拉高几个档次成本完全值得。RAG架构还有一个上线前必须考虑的点引用溯源。企业内部知识问答场景用户问“年假政策是什么”模型不能只甩一段答案还应当标注答案来自哪份文档、哪一页。没有引用溯源的RAG在严肃场景里根本不敢用——模型一本正经地编了一个政策员工照做了怎么办架构上要强制生成引用索引把每个关键结论映射到源文档ID和段落ID。3.2 Agent架构Plan-Execute-Act的循环怎么落地Agent是AI应用里最“诱人”也最“危险”的架构模式。诱人在于它看起来什么都能干危险在于如果循环设计不严密系统会失控。Agent的核心工作方式是一个循环规划、执行、观察、再规划。模型先生成一个任务计划然后调用工具执行观察返回结果再调整计划继续执行直到任务完成或达到终止条件。落地这个循环第一个关键设计是“终止条件”。没有终止条件的Agent就像没有刹车的车。必须要设置三个保险丝最大迭代次数、最长执行时间、最大token预算。任何一个条件触发Agent必须强制终止返回当前已完成的中间结果。我做过一个实验让Agent执行一个步骤比较多的任务不设迭代上限结果它在一个失败分支上循环了二十多次才被手动打断费用和延迟双双失控。第二个关键设计是“计划的可执行性”。模型在规划阶段产出的计划经常过于理想化第一步就想调用一个不存在于工具列表里的功能。架构上不能让Agent边执行边幻想每一步工具调用都必须经过工具注册表的校验工具名必须存在于注册表参数必须通过Schema校验。校验失败的调用直接返回错误并重新规划这个过程要记录日志方便分析是描述问题还是模型理解问题。第三个被很多人忽略的关键设计是“中间产物管理”。Agent执行多步任务时每一步都会产出中间数据比如查到的订单信息、算好的运费。这些中间产物不能只存在上下文里否则下一步模型可能会忘记精确数值。架构上要提供状态存储把每一步的结构化输出落地并在下一步做工具调用时显式注入。这一步做得好不好直接决定了Agent完成复杂任务的稳定性。3.3 多Agent协作编排与通信的常见误区单Agent搞不定的时候很多人自然想到多Agent协作让一个Agent当主管几个Agent当专员各司其职。方向没错但落地时我见到的失败案例比成功案例多得多。团队拿到一个复杂场景第一反应就是“拆成三个Agent”结果拆完发现Agent之间互相传递信息靠的是漫长对话消息调试起来像在破案。先泼盆冷水大多数场景不需要多Agent。单Agent配合工具调用和好的提示词就能覆盖绝大部分任务。多Agent真正的价值是在“职责边界清晰、专业上下文差异大”的场景比如一个负责代码生成、一个负责安全检查、一个负责测试用例三者掌握的知识范围差异明显拆开才有意义。如果拆完发现每个Agent的prompt里80%内容都一样那就是为了拆而拆纯属增加复杂度。多Agent架构做对了核心是通信协议的设计。Agent之间不是“互相聊天”而是通过结构化任务对象传递信息。我给团队定了一个约定每个任务对象必须包含task_id、请求方、意图类型、输入数据、期望输出格式、截止时间。Agent收到任务后要么按格式输出结果要么明确返回失败原因。绝不允许出现自由文本式的来回对话否则你没法审计、没法重放、没法排查问题。编排模式上我推荐先做“主管-执行者”模式就是由一个主Agent负责任务拆解和结果整合工作Agent只负责执行具体子任务。这个模式实现成本低主管Agent的调度逻辑容易审视和控制。更复杂的流水线式、辩论式协作对稳定性和成本的要求都高得多不是团队初期该尝试的方向。记住一句话编排层的复杂度就是未来运维层的痛苦指数。3.4 并发与性能Agent扛并发的问题怎么解“AI Agent怎么扛并发”是一个高频问题。很多人以为瓶颈在模型API的QPS实测跑下来真正的瓶颈往往在编排层。Agent任务不是一次API调用就结束而是一个链条规划一次、工具调用数次、反思一次每个环节都可能再触发模型调用。单个用户的一个任务可能产生5到10次模型调用服务100个并发用户实际模型调用量可能是500到1000次而且每个任务耗时几十秒。这种长耗时任务如果采用传统同步请求模式会占用大量连接和内存。架构上必须改造成异步任务模式用户请求进来系统先返回一个task_idAgent任务放到后台队列执行前端通过轮询或WebSocket推送获取进度。这么一改后端就能用有限的线程池处理海量任务而不是每个用户请求占住一个线程等模型慢慢吐字。并发设计上还需要注意状态外置。多实例部署Agent服务时任务状态绝不能放在进程内变量里否则负载均衡一转发任务就丢了。任务状态要落到Redis或数据库用task_id索引。工具调用的结果也要支持持久化和追溯这样即使服务重启也能从最后一步恢复执行。最后提一个不太起眼但很致命的点限流和降级不能只放在网关层还要放在工具调用层。模型API如果限流所有Agent任务一起失败工具服务如果超时任务会等完整个超时周期。我的习惯是给每个工具调用配置独立的超时和熔断参数比如连续失败5次则熔断30秒避免一个下游故障拖死整个Agent系统。4. 实战落地从概念图到生产架构的五步走4.1 第一步画出MVP架构草图很多团队做架构设计喜欢一上来就画一个大而全的“最终形态”十个模块、五个数据库、三个消息队列画完发现半年都做不出来。我个人的习惯反着来先识别这个应用“最核心的闭环”是什么把闭环跑通再考虑扩展。比如做一个“智能售后助手”MVP闭环可以是用户描述问题→Agent调用订单查询工具→获取订单信息→生成处理方案→返回给用户。这个闭环只需要模型接入层、一个工具、一个简单的记忆存储。画草图时我会用一个大大的虚线框标出边界哪些东西属于闭环内哪些虽然未来需要但本期不做。这一步能帮团队在项目推进时顶住“加个功能吧”的诱惑因为架构图就是拒绝需求的最好依据。4.2 第二步定义数据流和接口契约架构图上画完箭头下一步要定义箭头上传递的数据结构。人和人之间沟通可以含糊系统之间通信含糊就会出事故。我给每一个跨模块数据流都定义JSON Schema尤其是Agent内部的任务对象和工具调用的入参出参。别嫌麻烦这一步省下来的时间会在联调和排查阶段十倍回报。接口契约还承担着“防止模型乱来”的职责。模型输出天然不稳定今天输出JSON、明天可能在JSON外面包一层解释文字。所以要对模型输出做一层“结构化解析器”先清洗再校验不合法就让模型重试一次重试还不合法就直接走兜底分支。这一步本质上是把“模型的随机性”转换为“系统的确定性”。4.3 第三步选择基础设施基础设施选型方面我见过太多团队陷入“框架崇拜”一上来就集成全套LangChain、LlamaIndex最后出现问题都不知道是框架的bug还是自己的代码有坑。我的建议是分两步走原型阶段可以大胆用框架快速验证生产阶段要逐步替换掉“黑盒”部分把关键链路掌握在自己手里。具体选型上向量库如果数据量在百万级以内直接用PostgreSQL的pgvector就够了少一个中间件少一个维护负担。数据量大、并发高再考虑专业的向量检索服务。消息队列如果是轻量场景用Redis Stream就行重量级场景才需要上Kafka。模型网关如果有预算可以买成熟的LLM网关产品预算紧张的话自己实现一个“模型路由token统计”模块也不算难。4.4 第四步可观测性与评估体系AI应用和传统应用在可观测性上有本质区别。传统应用只要知道“接口报错没报错、延迟高不高”AI应用还得知道“模型输出质量好不好、token烧了多少”。这一层常常被团队放到最后才考虑但等上线出了问题才发现两眼一抹黑连复现问题都难。我在每个AI服务里强制要求三类日志模型调用日志记录输入、输出、token数、延迟、模型版本、工具调用日志记录参数、结果、错误信息、任务流程日志记录任务状态流转。这三类日志缺一类排查问题就会缺一块拼图。成本追踪更不能少每个任务结束后要把成本和延迟指标上报到统一监控一旦出现异常任务能第一时间发现。评估体系是AI应用质量的“测试用例”。上线前必须建一个回归评估集包含几十上百条典型问题、期望行为和禁止行为。每次提示词调整、模型升级、工具更新都要跑一遍评估集用“模型打分人工抽检”的方式对比新旧版本效果。没有这套评估流程AI应用的质量就基本靠祈祷。4.5 第五步灰度上线与迭代节奏AI应用发布和传统发布还有一个大区别模型版本和提示词版本的变更效果不可精确预知必须要做灰度。我见过一个团队提示词改了几句话全量上线结果某个分类下的客服回答风格彻底变了用户投诉率升高了一倍。从此他们把所有prompt纳入“配置”而非“代码”每次修改都走配置中心发布。灰度方案上最实用的做法是按用户ID分桶。新提示词、新模型路由规则先切10%的流量观察评估指标和用户反馈没问题再逐步放量。模型版本切换更是如此同一个模型的不同版本之间可能有隐性差异必须用数据说话而不是只看人工测试几个用例。迭代节奏方面我建议小步快跑一周一个版本是AI应用比较合理的节奏。每版只改一个关键变量要么改提示词要么改工具逻辑要么改模型路由不要一次修改多个变量否则出了问题没法定位到底哪一步导致的回退。AI应用的复杂度已经够高了别在发布环节再给自己增加定位难度。5. 踩坑实录AI应用架构里最常见的五个问题5.1 提示词太长导致成本失控我接手过的一个项目为了把任务说清楚研发同学往系统提示词里塞了三千多字的背景说明、规则条例、示例对话。单看一次调用效果不错但每次请求都要把这些token全部发送给模型一天几万次请求token费用直线上升。后来我们做了两个改动一是把固定不变的内容放到“系统提示词”中利用服务商的提示词缓存能力降低成本二是把大段示例从常驻提示词中抽离改成按需动态注入。这个问题的本质是混淆了“提示词质量”和“提示词长度”。质量取决于信息密度和结构清晰度不是字数越多越好。团队里应该有一个习惯每次改完prompt顺手估算token量记录到版本变更说明里。如果发现提示词膨胀到影响单位请求的毛利就需要做一次系统的提示词压缩优化。5.2 工具调用失败后Agent死循环这是Agent类应用最经典的翻车现场。一个Agent执行一个需要调用第三方物流查询接口的任务接口临时故障返回错误。Agent没能理解这个错误是“暂时性失败”不断重试每次重试又消耗一次模型调用加上日志输出几分钟烧掉了上百次调用最终还没完成任务。用户看到的只是“处理中”而系统在背后疯狂烧钱。解决思路分两层工具调用层配置合理的超时、重试上限和熔断Agent编排层增加失败语义的理解能力。工具返回错误信息时要带上机器可读的错误类型比如timeout、rate_limit、business_errorAgent根据错误类型决定是短暂重试、换方案、还是直接终止。同时在任务循环里设置“失败连续次数阈值”一旦达到阈值就停止重试并向用户返回一个诚实的结果。5.3 上下文窗口的“记忆错觉”上下文窗口从几K增长到几十K、上百K后很多人觉得模型“记忆力”变强了不需要精心设计记忆策略。实测完全不是这样。长对话进行到中后段模型经常忽略用户在前面明确说过的关键信息尤其当用户最新的需求和老信息冲突时模型倾向于只按最新信息做而忘记了更早期的约束。我处理过一个客户投诉场景用户在长对话里先后提出两个互相矛盾的需求模型最终执行了后一个但用户认为自己在前面已经明确说明不要这个方案了。技术上这属于上下文注意力覆盖问题解决方案是“关键信息持久化”。在对话轮次中实时抽取用户的核心偏好转成结构化标签存起来每轮生成答案前显式注入这些标签而不是完全依赖上下文窗口搬运原始文本。5.4 并发瓶颈不在模型API而在编排层一个Agent服务压力测试模型API的P95延迟没有明显恶化但整个服务在50并发时就开始大量超时。拉日志一看问题出在编排层的同步阻塞Agent任务每执行一步都要等上一步结果而线程被大量占住同时状态管理用了进程内Map多实例部署时状态不一致导致重复执行任务数量成倍膨胀。这次踩坑之后我把编排层改造成了异步执行模型任务进入队列后由独立worker消费状态落到Redis每一步通过事件驱动触发下一步不再用线程同步等待。改造后同样的50并发轻松应对成本没变吞吐量涨了好几倍。这里想提醒的是Agent架构的第一步往往很轻巧但并发上来后编排层的异步化改造是绕不过去的一道坎。5.5 测试与评估跟不上AI应用开发最常见的现状是功能迭代飞快测试还是老一套“手工点几个用例”。没有系统的回归评估集没有线上效果监控发布全靠感觉。这种项目会越做越慌因为每次改动都可能引入隐性回退今天好用的场景明天可能就变了。务实的做法是建一个“最小评估集”不必一开始追求几百条先从历史用户真实问题里挑三五十条覆盖主要场景配上期望行为和禁止行为。每次发布前跑一遍用一个大模型当裁判给新版本回答打分同时人工抽查十条关键用例。这套机制跑起来之后AI应用的迭代速度反而会更快因为每次上线的底气足了。6. 架构图设计复盘图解只是手段共识才是目的6.1 分层图、时序图、数据流图分别解决什么问题很多人以为“图解AI应用架构”就是画一张图就完事其实至少需要三类图配合分层架构图、关键时序图、数据流图。分层架构图解决“系统里有什么、属于哪一层”的问题用来对齐模块边界和职责范围时序图解决“一次请求怎么走一遍”的问题用来对齐调用顺序和异常路径数据流图解决“数据从哪里来、到哪里去、在哪些地方转换”的问题用来对齐存储设计和接口契约。这三类图的使用场景不一样。方案评审时先看分层架构图确认模块划分合理详细设计时看时序图确认交互逻辑没有遗漏线上排查问题时看数据流图快速定位数据在哪一环丢了或错了。团队里要有约定架构文档更新时必须三类图同步更新只更新一类会导致团队认知偏差。6.2 一张好的架构图要能回答哪三个问题我每次评审架构图都会向画图的人提三个问题每个组件存在的理由是什么数据在组件之间流动的路径清不清楚关键组件不可用时系统怎么兜底这三个问题能在五分钟内过滤掉大部分“看起来精致但根本没法落地”的设计。第一问是防御“过度设计”一个组件解释不清存在意义就该砍掉。第二问是检查“链路完整度”数据流含糊通常意味着方案没想清楚。第三问是验证“健壮性”AI应用里模型、工具、第三方服务都可能出问题没有兜底设计的架构图只能算理想状态图。把这三个问题回答清楚架构图就从“示意图”变成了“指导文档”。6.3 用表格维护组件清单画完架构图之后我还建议团队维护一张组件清单表格把架构图里的每个框细化成行。列可以是组件名、所属层级、技术选型、依赖关系、SLA要求、负责人、成本估算。这张表格是架构图和代码之间的桥梁也是后续容量评估和预算管理的基础。组件清单的价值在团队协作中尤其明显。新成员入职看架构图了解全貌看组件清单了解每个模块的细节和负责人提问成本大幅降低。运维排查问题时组件清单上的SLA和依赖关系能快速缩小故障影响范围。架构演进时组件清单也会自然暴露出哪些模块该重构、哪些模块已经没人在维护。最后分享我给自己定的一条规矩架构图必须能在十分钟内向一个新人讲明白。十分钟讲不明白说明图里有太多含糊的东西或者架构本身太复杂。回到最开始那个问题——系统里哪些决策交给模型、哪些交给代码、哪些留给人只要这张图能把这三种决策边界清清楚楚地画出来它就已经是一张合格的AI应用架构图了。