1. 为什么AI应用架构不能照搬传统后端1.1 传统后端与AI应用的核心差异先说结论传统后端架构追求的是“确定性”AI应用架构要解决的是“在不确定性的前提下保证可用性”。过去十年我们熟悉的那套后端设计思路——请求-响应、事务、数据库约束、面向接口编程——在AI应用里依然有用但多了一个关键变量模型本身是概率引擎。传统Web接口的输入输出是可枚举的。你传商品ID和数量返回订单号哪怕业务再复杂状态总是可跟踪的。AI应用完全不同同一个Prompt模型可能给出完全不同的回答你今天部署的模型明天可能因为供应商升级SDK、调整限流策略、下线某个版本而行为突变。更麻烦的是模型消费的Token直接和成本挂钩。传统接口几百毫秒返回压测时每秒几百上千并发都不慌AI应用一个请求十几秒中间还穿插多次模型调用和工具调用瞬间就可能烧掉大量预算。所以AI应用架构设计的本质是把不确定性隔离在可控范围内同时统一管理模型能力、上下文和成本。这不是在传统后端架构上“加一个AI模块”而是从分层、并发、监控到部署都需要重新考虑。1.2 不确定性带来的具体设计约束这个约束渗透到每一层。第一输出格式不稳定。模型即使被要求返回JSON也有可能夹杂解释文字或输出非法字符。所以架构里必须有“解析-校验-修复重试”这条链路而不是直接信任模型输出。很多线上事故本质都是“默认模型输出合法”导致的。第二上下文窗口有限。大模型的输入窗口虽然越做越大但依然有上限而且塞得越多越贵、越慢。架构必须在每次请求前决定这段对话历史该怎么压缩、截断、摘要、检索而不是无脑把所有消息都塞给模型。可以类比人脑的工作记忆——你不可能把整本《红楼梦》放在脑子里再回答问题只能记住情节梗概和关键细节。模型的短期记忆就是上下文窗口长期记忆就得靠外部存储。第三模型供应商是外部依赖。外部API会限流、会故障、会调整计费。你的架构不能假设某个模型永远可用必须有路由、降级、重试机制。这里要特别提醒模型供应商的“服务等级协议”和传统云服务不是一个概念大模型经常出现你完全无法控制的抖动要在设计初期就给“模型不可用”留好预案。第四任务时长。Agent任务不是一次HTTP请求能解决的它可能包含多轮工具调用、多步推理。传统请求-响应模型承载不了这种长任务需要引入任务队列、异步执行、状态存储。一个任务从开始到结束可能跨分钟级客户端和服务器之间怎么保持连接、怎么恢复状态都需要重新设计。1.3 架构师面对的新问题清单我把实际做AI应用时绕不开的问题列一下你可以当checklist用看看自己的架构是否已经有答案多个模型如何统一接入切换供应商时接口要改多少同一个问题能不能命中缓存语义缓存怎么设计用户在对话里的历史信息存在哪里用向量库还是Redis还是数据库Agent调用工具失败后怎么办重试还是放弃如何保证不重复扣费模型输出格式不对时怎么处理重试一次还是直接交给用户大量用户在同一时段发起任务怎么限流而不影响核心体验每次调用的Token归到哪个用户、哪个场景成本怎么分摊模型升级后行为变化如何让架构不受波及一个Agent任务被中断如何恢复中间状态存在哪里这些问题不是某个中间件能单独解决的需要从整体架构层面回答。这也是“AI应用架构设计”这个领域和普通后端架构分道扬镳的地方。你如果发现自己在代码里到处处理这些问题说明该停下来做一次系统性的分层了。2. 核心架构拆解从模型接入到应用编排的分层设计看别人的架构方案时我的习惯是先找它的分层边界。AI应用架构经过这一年多的发展基本收敛出四个清晰层次应用接入层、应用编排层、推理调度层、模型接入层。下面按从外到内的顺序拆。2.1 模型接入层统一封装多个大模型供应商模型接入层是离模型最近的一层。它的目标非常简单上层只和你的SDK打交道不直接依赖某个供应商的SDK。这一层暴露的方法通常只有几个chat(messages, options)embed(texts)tool_call(messages, tools)file_parse(content)对外部的差异统一屏蔽。比如OpenAI的消息结构和Anthropic的格式不完全一致模型公司A的tool call字段名是function_call模型公司B叫tool_calls接入层要把这些差异消化掉。另一个很重要的职责是统一错误码把上游的限流错误、超时错误、鉴权错误、余额不足错误映射成自己系统内部的错误类型上层才能做统一的容错处理。内部要做的事包括兼容不同供应商的接口差异、统一重试策略、统一Token计数。我见过很多项目在早期直接调用某个大模型SDK等想换成更便宜或性能更好的模型时发现代码里散落了大量厂商细节改起来牵一发动全身。模型接入层就是为了避免这个局面。有很多企业级框架如LangChain等也提供了类似的抽象但我个人更倾向于自己做一层轻封装——框架更新频繁、依赖重而且很多时候你只需要其中20%的能力。实测经验接入层最好在构建请求时就把Token预算算好超过预算直接拒绝或截断不要等模型那边报错。还要注意不同模型的temperature、max_tokens等参数语义不完全一致最好在接入层做参数映射而不是交给业务代码。2.2 推理调度层模型路由、上下文管理、语义缓存如果说接入层是“翻译官”调度层就是“指挥官”。它负责三层核心能力。第一模型路由。简单指令任务如分类、改写用小模型复杂推理任务如写代码、多步分析用大模型。路由规则可以放在配置中心例如按意图分类、按Token预算、按用户等级。实现时要注意路由判定要快不能为了路由多等一次模型调用否则延迟得不偿失。现在的做法通常是用一个小模型或规则引擎做意图识别把请求判断个大概方向然后再决定调用哪个大模型。这一步能明显省钱因为小模型的成本可能只有大模型的五分之一到十分之一。第二上下文管理。传统后端没有这个字段AI应用里却最致命。每次对话都携带全部历史是懒人做法既贵又慢。调度层要负责把消息列表压缩成符合模型窗口的形态。常用策略包括滑动窗口、重要性评分、摘要记忆、向量库检索。后面第3节详细展开。这里只强调一点上下文管理是架构的“核心决策”不是一处改完就完它需要和路由策略联动。比如你准备调用小模型时可能需要把上下文压得更短因为小模型的窗口通常更小。第三语义缓存。传统缓存按key精确命中AI场景里“语义接近”的请求也可以复用。实现上需要用embedding把用户请求向量化再在向量库做相似度检索命中后直接用缓存结果可以大幅节省成本。这里要注意相似度阈值要压准太松会答非所问太紧命中率低。我的经验是0.90到0.95之间起步结合业务场景调参。缓存还要设置过期时间——不是所有知识都永久有效比如天气、新闻、时效性强的信息缓存的意义就不大反而会输出过时信息。2.3 应用编排层Agent运行时与工作流引擎再往上就是和业务强相关的编排层。这里有两种形态。第一种是Agent运行时。系统让模型自己决定调用什么工具、按什么顺序执行。典型结构是一个循环感知当前状态 - 模型决定下一步动作 - 执行工具 - 观察结果 - 循环直到完成。这个循环需要一个运行时容器来承载状态、控制步数上限、处理异常。在没有现成框架时可以用一个状态机实现把每个步骤的输入输出都记录在案方便后面调试和审计。第二种是工作流引擎。如果业务路径相对固定比如“先抽取信息再查知识库再生成回复”就不需要模型天马行空编排用工作流引擎把步骤固定下来反而更稳。工作流的好处是每一步都是人肉可控的出问题时你知道卡在哪个环节。我建议把工作流和自由Agent同时保留简单业务走工作流复杂业务走Agent。还有一个折中模式用工作流定义主流程在主流程的某些节点上允许Agent自主选择工具或策略。这种“半自由半受控”的形态在落地时比纯自由Agent稳定得多。编排层还需要提供统一的任务模型每个任务有生命周期排队、执行、等待工具、成功、失败、超时状态存哪里、并发怎么控制都是这一层的事。任务状态适合放到Redis或数据库中配合异步队列做并发控制而不是交给网关层处理。2.4 一个最小可用架构的文字化图解我不画复杂架构图给你一个可以抄的分层示意[接入层] Web / App / 内部系统 / 消息机器人 | [编排层] Agent运行时 / 工作流引擎 / 多Agent调度器 | [调度层] 模型路由 / 上下文管理 / 语义缓存 / Prompt模板库 | [接入层] 统一模型SDK(超时/重试/限流/Token计量) | [模型服务] OpenAI / Claude / 国产大模型 / 开源私有化模型 [旁路依赖] 向量数据库(记忆/检索) / 任务队列(长任务) / 工具服务(内部API) / 可观测平台这个结构里的每一条竖线都是模块边界也是未来的扩展点。模型接入层和调度层可以复用到所有业务场景编排层按业务定制接入层的形态最灵活。只要守住分层边界替换模型、调整Prompt、修改工作流都不会波及其他部分。很多人一上来就把全部逻辑堆在一个“AI网关”里短期看省事长期看所有变更都挤在一起每一步都会让你心惊胆战。3. 多Agent协作架构的设计支点上下文、记忆与工具调用关于AI Agent的问题非常多我单独开一节讲多Agent协作架构因为这是当前AI应用架构里最容易被忽视又最容易翻车的部分。3.1 单Agent还是多Agent先泼一盆冷水不是所有系统都应该上多Agent。单Agent加一个强大的工具集能解决大多数问题。多Agent的本质是“分工”——把一个大目标拆成子任务让不同Agent各管一段最后汇总。好处是每个Agent的提示词更聚焦、上下文更短、可靠性更高代价是通信开销、状态同步和失败传播。我的判断标准是如果任务可以被自然拆成不同专业领域比如“分析数据”和“生成报告”是两个独立能力并且子任务之间边界清晰才值得多Agent。如果只是复杂但线性的流程工作流引擎比多Agent更合适。举个例子一个客服机器人检索订单、生成回答、安抚情绪这些步骤有依赖关系放一个Agent里串行执行就行而一个“行业研究助手”需要同时搜政策、看财报、读新闻、做交叉验证这种并行任务才需要多个Agent各管一条线。还要考虑团队维护成本。每个Agent本质上都是一套独立的Prompt加工具集意味着需要单独调优、单独测试。Agent数量一多你管理的就不再是代码而是“一群性格各异的小人”。没有足够的工程投入不要轻易上多Agent。3.2 上下文与记忆多Agent场景下的头号难点多Agent协作时每个Agent看到什么上下文直接决定输出质量。这里要区分四类记忆会话短期记忆本次任务中的对话轮次。适合放在运行时变量里任务结束就释放。工作记忆Agent执行过程中的中间状态例如已经查过的数据、已经生成的草稿。适合用结构化对象存储每个Agent可以从共享状态中取出需要的部分。长期记忆用户的历史偏好、领域知识。需要持久化通常用向量库或关系数据库。全局记忆多个Agent之间的共享结论。例如研究任务中“已经确认的事实”。需要写入一个共享黑板或事件流避免每个Agent重复查询。实际工程里我建议把“全局记忆”做成一个独立的存储服务而不是让Agent拿着整个上下文副本到处传。这样既省Token也能避免并发写冲突。所谓“黑板模式”在这里很适用多个Agent往一块公共黑板上写信息、读信息各取所需。架构上可以是一个Redis实例、一个数据库表或者一个事件流关键是明确这个黑板的读写权限和数据结构否则几个Agent同时更新同一字段会出现互相覆盖。3.3 工具调用的架构实现从自定义协议到MCP工具调用是Agent能力的放大器。架构上工具必须被抽象成“可以被模型以JSON方式调用”的接口。你需要为每个工具提供功能描述、入参schema、出参schema、错误信息。模型读了这些定义后生成一次函数调用请求运行时校验参数、执行工具、返回结构化结果。这里要提一下MCPModel Context Protocol。它解决的问题是如果每个工具都要自己定义一套协议每接一个新模型就要重写一次工具适配器成本极高。MCP统一了模型与工具之间的交互格式相当于给工具调用装了一个标准插座。现在很多主流模型平台和工具生态都在往这个方向靠新项目值得从一开始就按类似思路设计工具接入层至少把工具定义和协议保持中立不要和某个具体框架耦合。我的经验是工具返回结果要给模型留“旁白”字段。比如一个订单查询工具除了返回数据最好附带一句人类可读的摘要“用户近三个月消费总额是xx同比增长xx%”模型直接引用摘要比让它从原始JSON里自己找结论更稳。这个细节看似简单实际能显著减少模型瞎猜的概率。3.4 Agent之间的通信协议设计多Agent协作最少不了通信问题。直接用一个共享内存字典是最容易想到的方案但在分布式场景下会变成单点或竞态地狱。更稳的模式是事件驱动每个Agent订阅自己关心的主题发布事件时带上结构化负载。例如检索Agent完成后发布“retrieval.done”事件生成Agent订阅该事件获取结果。通信协议要定义清楚负载格式、消息幂等性和过期时间。Agent可能因为超时或异常重复发布结果接收方要做去重。事件流可以用Redis Stream或消息队列承载轻量场景用数据库任务表轮询也能跑重点是别把Agent之间的通信和业务数据库混在一起。要有一套统一的事件Schema注册中心否则每个Agent各定义各的线上排查时你会非常痛苦。另外一个关键设计是步数上限。无论Agent多想继续执行架构上要设硬上限比如单个任务最多30步、最长执行5分钟。没有硬上限的Agent系统迟早会在某个奇怪输入下陷入死循环。这个上限本身要可配置不同业务场景要求不一样。比如一个代码生成Agent可能需要更多步来修复编译错误而一个简单问答Agent可能5步就够。步数上限不只是保护系统资源也是控制成本的手段——每多跑一步就多消耗一次Token。4. 并发场景下的架构治理限流、降级、超时与成本控制热词里有人问“AI Agent怎么扛并发”我把这个问题的答案拆成四块并发模型、限流、降级、成本规划。这部分是AI应用架构里和传统后端差异最大、也最容易出事故的地方。4.1 AI应用并发为什么棘手传统后端一个请求通常几十毫秒到几百毫秒返回线程池模型够用。AI应用一个请求可能十几秒到几十秒期间还可能发起多次模型调用和工具调用。如果你用同步线程去扛线程池很快被打满后续请求全部排队用户体验变成“转圈圈”。更麻烦的是模型供应商的API有并发限制比如每分钟请求数、每分钟Token数你内部再快出口被限住也是白搭。这有点像水管出口细你家里面再大的水压外面还是会慢慢滴。所以并发设计要从两端入手对外用请求队列接纳大量用户请求让任务慢慢消耗模型额度对内按模型供应商的配额做流量整形避免突发流量打爆上游。整体上AI应用更适合用“异步任务流式输出”的模式而不是同步等待结果。用户端收到SSE流式输出后延迟感会明显降低哪怕模型推理要用20秒用户也在持续看到内容变化而不是盯着空白页面等。4.2 限流API层与业务层的双层保护我常用的方案是双层限流。第一层在API网关按用户/租户维度限流例如每个用户每秒最多发起2个新任务防止单个用户刷爆额度。第二层在模型接入层按模型供应商的配额做令牌桶限流比如每分钟最多调用1000次或每分钟最多消耗100万Token。第二层是很多人会漏的。你的网关限了用户流量但模型接入层没有针对上游配额的整形一旦某个爆款活动推高流量先挂的往往是供应商接口报429之后你的服务反而被重试风暴拖垮。实现时可以用Redis做分布式令牌桶把每个模型的配额独立维护。注意令牌桶的容量和速率要分别配置容量应对突发速率保证长期稳定。限流后返回什么也很关键。对用户友好的做法不是直接拒绝而是返回“当前请求量过大请稍后再试”并提示可以排队。对内部系统则可以返回一个特定的错误码让上层决定是降级还是延迟重试。这里要谨慎对待“重试风暴”一旦上游限流下游大量重试只会加重拥堵。使用指数退避加抖动jitter是标准做法不要使用固定间隔的激进重试。4.3 超时与降级模型不可用时的容错设计AI应用的服务降级链路比传统后端多好几级。我按模型调用的失败场景排列模型A超时或不可用路由到模型B比如从大模型降到中小模型。全部模型不可用尝试语义缓存命中返回最近相似问题的答案。缓存也没有返回兜底话术同时记录告警让用户知道“暂时无法回答”而不是死循环。工具调用失败区分可重试错误网络超时、临时故障和不可重试错误参数错误、权限不足。可重试的做指数退避重试最多2到3次不可重试的直接回传错误给模型让模型调整策略。超时值参考单次模型调用15到30秒比较合理复杂Agent任务整体超时建议120到180秒但用户端看到的是流式输出不会觉得离线。如果采用同步HTTP暴露接口建议把超时和任务队列解耦不要让客户端一直挂着等。可以用“提交任务-绑定任务ID-异步轮询/WebSocket推送结果”的模式这更符合AI应用的执行特征。4.4 Token怎么纳入容量规划这是AI应用架构独有的问题。容量规划不能只看QPS要把Token消耗作为一等公民。我举一个实际估算例子假设一个问答任务平均消耗输入2000 tokens输出800 tokens。单用户平均并发2个任务业务高峰期在线用户100人其中20%同时活跃。峰值任务速率 100 × 20% × 2 40个任务/分钟。每分钟Token消耗 40 × (2000 800) 112,000 tokens/分钟。如果按小时算就是672万tokens。再乘你用的模型单价就能算出这个功能一个月成本。然后你可以在模型接入层设置Token预算告警单日消耗超过预估120%就通知超过150%自动降级到便宜模型。没有这套计量等月底账单出来才发现成本失控就晚了。Token计量的粒度至少要细到“场景”级别比如“智能客服问答”“文档总结”“代码生成助手”各自消耗多少Token。这样才能知道哪个功能是烧钱大户。有些场景实际使用频率低、输出长单价却很高优化时优先处理这些高消耗场景。5. 可观测性设计链路追踪、Token消耗与输出质量评估AI应用比传统后端更难排查问题因为“为什么模型这么回答”是个黑盒。可观测性设计的目标就是把这个黑盒拆成可追踪的阶段。你不可能让每一个模型输出都解释得清但你可以记录每个阶段的输入输出和关键指标让复盘有据可查。5.1 需要观测哪些独特指标传统监控看延迟、错误率、饱和度AI应用还要加几项模型调用次数与Token消耗单任务、单用户的消耗。缓存命中率语义缓存命中率高说明大量重复问题架构效果好且成本低。工具调用成功率Agent的核心风险点。重试次数与失败原因模型超时、限流、输出校验失败要分类。输出质量分通过自动评估或用户反馈得到。其中工具调用成功率是Agent系统的命门。一个Agent任务里工具调用失败可能导致后续步骤完全跑偏。不要只统计“调用失败/成功”还要记录失败发生在哪个工具、错误类型是什么这样才能推动工具服务方优化。5.2 链路追踪把Prompt、模型调用和工具调用串起来最简单的做法是给每个业务请求生成一个trace_id然后在所有关键节点埋点。每个span至少记录阶段名称如“模型调用:claude-3.5-sonnet”、输入Token数、输出Token数、耗时、状态。关键trace_id要跟随用户在对话中的每次请求这样多个轮次也可以串成一条完整链路。埋点数据建议统一落一份到日志系统同时抽样聚合到监控面板。不要把所有Trace都做完整采样成本高且噪音大我一般对线上请求做10%到20%抽样对异常请求有告警的、输出结构反复解析失败的全量采样。全量采样不仅成本高而且排障时信息过载反而妨碍定位。关键是要有“按trace_id即时检索”的能力这样出现线上问题时能快速拉出完整链路。可以用OpenTelemetry等开源工具做基础采集再配合自己的业务埋点。5.3 Token消耗监控与成本归因Token监控要做到“可归因”从哪个产品、哪个功能、哪个用户、哪个模型消耗了多少Token。成本归因的意义不只是算账更重要的是告诉你优化方向。比如发现某个Agent的Prompt模板特别长、命中率低就可以针对性地缩短模板或加缓存。很多团队优化成本时盲人摸象就是因为缺乏Token维度的可视化。预算告警按天和按月设两级。我习惯在模型接入层统一计量而不是在业务代码里各处手动上报避免漏统计。不同模型的价格差异极大计量时要带上模型名成本汇聚时才不会失真。还有一个容易被忽略的点输入Token和输出Token的计费价格不同很多模型厂商输出Token比输入Token贵好几倍。所以监控面板上要分开看“输入Token消耗”和“输出Token消耗”优化策略也不同。输入侧靠缓存和上下文压缩来省输出侧靠控制生成长度和路由到便宜模型来压。5.4 输出质量与安全策略的评估机制架构层面要留出一层“输出评估”。最简单的方式是用另一个模型评估当前输出AI-as-Judge给评估模型几个维度——相关性、格式合规、幻觉程度、安全性让它返回分数。这个分数用于灰度发布和模型路由。如果新版模型的输出分明显低于旧版可以考虑自动回滚路由。安全方面无论什么应用接入层都要设置内容安全过滤与格式校验。我自己在架构里会放一道“输出验证器”规则包括必须用UTF-8、必须是合法JSON或Markdown片段、禁止包含不符合要求的敏感规则命中。这属于纯工程层面的防线和业务无关。安全策略不能只靠模型自身要在应用层做可配置的过滤规则和人工复核入口。对于一个面向用户的AI产品来说输出验证器是最后一道保险宁可在这里多花一点时间也不要让明显有问题的内容流到用户面前。6. 落地AI应用架构时最容易踩的坑最后分享几个我在真实项目里踩过的坑也算是给前面那些理论补上一些“血泪教训”。这些都是常规文档里不会写的细节但实际影响非常大。6.1 坑一把Prompt和代码写死在一起项目早期Prompt字符串直接写在业务代码里改一个字都要发版。后来Prompt越调越多不同场景的Prompt散落在各个服务里版本根本没法定。建议把Prompt模板放到独立的配置中心按场景和版本管理代码里只引用模板ID和参数。这样调整Prompt可以走配置发布流程不需要重新部署应用且回滚也是秒级。还要注意Prompt模板的“可测试性”。我见过太多团队调整了一个Prompt后效果变差了却不知道是哪里引起的。解决方案是为每个Prompt模板建立对应的评测集改动后跑一遍回归。即使只是加了一句“请用简洁的语言回答”也可能会对输出风格产生很大影响。没有评测集的Prompt修改等于在盲飞。6.2 坑二忽略模型输出的非结构化问题我见过不止一次系统假设模型一定会返回合法JSON结果某一天模型升级后输出里多了一行说明文字整个解析链路全挂。架构上一定要有“解析-校验-修复重试”三步先尝试标准解析失败就用修复提示让模型重新输出一次再失败才放弃。这条链路比任何参数调优都值钱。修复重试也有很多细节。修复提示要包含具体的错误信息和当前输出片段让模型知道哪里错了。比如“你的输出没有通过JSON格式校验错误是Unexpected token请只输出合法JSON”比笼统的“请重新输出”有效得多。重试次数建议1到2次就够再多既费钱效率也低。6.3 坑三工具调用没有重试和幂等Agent调用支付、发消息、改状态这类工具时如果超时无响应直接重试可能导致重复执行。要求所有工具开发者实现幂等键idempotency keyAgent运行时在重试时带上同一个幂等键。这个约束必须在工具接入层强制不能指望业务自觉。比如一个“发送邮件”工具如果第一次调用实际已经发出去但响应超时了你重试一次用户就会收到两封邮件。解决方法是每次任务开始时生成一个幂等键工具服务端保存已处理过的幂等键重复请求直接返回上次结果。6.4 坑四并发预估完全照搬传统Web传统Web架构的并发预估通常基于页面点击量AI应用则要看“任务复杂度”和“Token预算”。同一批用户任务简单和任务复杂时的系统压力可能差两个数量级。压测时也要用真实的Prompt和工具调用组合不要用空Prompt去压模型接入层结果完全失真。我见过一个项目根据用户量预估出每秒20个并发结果上线后一个复杂的文档分析任务把每次请求的Token消耗拉高了几十倍模型接入层的成本直接翻了四倍。后来他们才在架构里加入“任务复杂度预估”模块在路由时根据任务类型选择不同的模型和额度策略才把成本压回来。6.5 架构收敛的优先级做AI应用架构没必要一口气上齐所有组件。我的落地顺序建议是第一先把模型接入层做出来所有模型调用走统一入口第二把上下文管理和语义缓存加上这一步能立刻降低成本和延迟第三做链路追踪和Token计量第四再上多Agent、工作流引擎这些上游编排能力。先把地基打好后面的扩展都是自然生长不用推倒重来。有些团队一上来就引入一个庞大的Agent框架结果发现框架本身难以理解、排查问题困难反而阻碍了业务迭代。框架能用但不要贪大求全。从一个最小的“模型调用入口加路由”开始跑通一条真实业务链路再逐步添加组件这样每一步的风险都可控。我自己做AI应用架构最大的体会是AI应用架构设计不是选一个漂亮的技术栈而是围绕“不确定性、上下文、成本”这三个主题不断做取舍。你把这三件事在架构层面安排明白了模型换哪个、Agent怎么搭都不是问题。模型更新换代很快但架构的底层逻辑——怎么隔离不确定性、怎么管理上下文、怎么控制成本——会在很长一段时间内约束着整个系统的上限。