1. 项目背景与核心问题为什么一个AI预算控制系统需要重构架构先聊点实际的。我在系统架构这个行当摸爬滚打了十几年见过太多AI项目从风光无限到烂尾收场。今年上半年接到一个互联网公司的预算控制AI系统架构重构项目标题上说的运维成本降40%确实是真实的但数字只是结果我更想拆解的是这个项目到底做了什么为什么做以及怎么做到的。先说项目的基本盘。这家公司规模不小员工几千人每年各个部门的预算申请、差旅报销、市场投放、采购审批流水般涌向财务系统。早期他们有一套基于规则引擎的预算控制系统跑了好几年规则从几百条堆到上千条逻辑复杂得没人敢动。业务的同事天天吐槽审批慢财务的同事天天人工核对异常单据技术团队则困在规则冲突和改配置的泥潭里。后来他们引入了AI能力用大模型做预算申请单的语义理解和初步审核效果是立竿见影的——审批时效提升了60%。但新问题接踵而至AI上线之后没人说得清模型为什么给出某个判断出问题时排障像大海捞针提示词稍微调一下就要人工回归测试半个月各业务线的提示词散落在不同的项目里改一行prompt都要层层审批推上线整个系统成了一个黑盒子转盘。这个场景其实特别典型。AI系统本身在算法层面跑得通不代表整个系统能稳定落地。模型推理结果不在预期内你去查什么日志提示词训练数据还是上下文窗口传统软件架构的排障套路在AI系统面前直接失灵。运维成本飙升的本质在于整个架构没有为不确定性设计配套的观测、回滚、评估和治理机制。这次重构的目标就是把这套缺失的机制补齐让AI系统像传统系统一样可预期、可控制、可运维。对于想参考这个案例的读者我先亮个底无论你是架构师、技术负责人还是做AI应用落地的工程师这篇拆解的核心价值不是那个40%的数字而是它背后一整套AI系统如何架构化落地的方法论。你大概率也会遇到同样的坑——模型不可解释、提示词难治理、效果不稳定、回归测试成本高。下面我把项目从设计到落地一步一步拆开讲。2. 整体架构重构的设计思路把模型从黑盒变成可治理的业务组件2.1 先盘旧账旧架构到底烂在哪里动手重构之前我们花了两周时间盘旧系统的现状得出的结论非常扎心。旧的预算控制AI系统本质上是一个大模型直连的单体结构业务系统把预算申请单文本直接丢给大模型模型输出通过、驳回、转人工三分类结果然后接一个审批流。表面上看流程很短但实际运行中积累了五类致命问题第一决策链路完全不可追踪。模型给一个驳回结论到底是基于预算超限、部门政策冲突还是上下文理解错误没有中间推理过程留存也没有置信度输出。财务对结果有异议时只有一行AI recommended reject的记录技术人员想解释都无从下手。第二提示词管理形同虚设。几十条业务规则直接堆在system prompt里各业务线各自为政有人改了prompt不通知任何人上线后效果波动互相甩锅。Prompt没有版本、没有评审、没有回滚机制出问题只能拍脑袋翻聊天记录。第三评估反馈闭环断裂。模型上线之后作用在真实业务上但模型结果是否正确、用户是否接受没有任何回流通道。数据不回流模型就永远无法持续进化系统上线即颠峰后面只有退化的份。第四没有精细的架构分层。预算控制业务其实有明确的分层需求意图识别、合规检查、预算计算、风险判断、审批策略。但旧架构把这些全部揉进一个模型调用里任何一个环节要调整都只能整体改prompt牵一发动全身。第五验测体系形同虚设。上线前用30条固定样例测一轮感觉差不多就放行。但AI模型是概率性的正常业务流量里几万种长尾表达30条样例根本代表不了分布。所以系统上线后经常出现测试全过、上线即崩的尴尬。这五类问题不是孤立的它们共同指向一个本质矛盾AI系统天然具有不确定性而你却用确定性系统的架构规范去承载它。所以这次重构不是简单换一个更大的模型或者调一调prompt而是从架构层面给不确定性做配套治理。2.2 新架构的四个核心设计支柱明确问题之后我们定了新架构的四根支柱所有设计决策都围绕它们展开支柱一可观测性优先。每个AI决策必须产生完整的决策链路记录包括输入上下文、中间推理步骤、各环节置信度、命中策略、耗时等字段。这不仅仅是打日志而是要求架构层面强制在关键节点埋点阻断式记录确保每一次模型调用都可回溯、可解释、可审计。支柱二模块化Agent编排替代单体模型调用。把预算控制拆分为五个独立Agent意图解析Agent、政策合规Agent、预算占用Agent、风险识别Agent、决策仲裁Agent。每个Agent职责单一内部模型可以独立迭代和替换相互之间通过结构化的协议通信而不是把全部逻辑压在一次大模型对话里。支柱三评估与回流常态化形成数据飞轮。每个决策不仅在线上跑还留一份到离线评估管道结合人工审批结果和用户申诉数据做持续评估。每周自动跑迭代淘汰效果差的提示词版本把效果好的样本回流到训练集形成正循环。支柱四分层治理与通用基座分离。业务侧的表达千变万化但底层的模型能力、鉴权、灰度、监控、限流这些技术能力是通用的。所以架构上把业务层和AI基础设施层拆开业务层管规则策略和业务数据基础设施层管模型路由、版本控制、降级熔断互不干扰。这四根支柱不是拍脑袋定出来的是从问题反推出来的——可观测性解决排障难Agent编排解决规则耦合评估回流解决进化停滞分层治理解决变更风控。每一根都对应旧系统的一类真实痛点。3. 核心细节拆解模块化Agent编排与关键机制设计3.1 五个Agent的分工与协作协议新架构落地后的核心运行逻辑是这样的业务系统提交一份预算申请单首先进入意图解析Agent它负责把申请单里的自然语言转成结构化意图包括申请类型差旅、采购、市场活动等、申请金额、申请人部门、期望执行时间等。这个Agent做的是信息抽取和实体识别输出必须严格遵循我们定义的JSON Schema字段缺失直接拒绝不做任何猜测。意图解析完成后政策合规Agent接管。它负责对照公司最新的预算政策库判断这笔申请是否符合政策规定。举个例子公司规定单次差旅住宿上限800元申请单里写上海住宿1200元/晚合规Agent就能给出超限标记并指出违反的具体政策条款编号。这里的关键在于政策库的组织方式——我们把政策拆成原子化的规则对象每条规则有独立编号、生效日期和适用范围而不是把政策全文堆在prompt里。预算占用Agent是纯工程逻辑不走大模型。它去查预算系统看对应部门的预算池还剩多少、已占用多少、在途申请冻结了多少。这部分用传统代码实现速度快、结果确定不给模型留任何含糊空间。这里我特别想强调一个设计取舍能不用大模型的地方坚决不用。预算计算是确定性的账务逻辑模型就算再聪明也不该碰它省得引入无谓的不确定性。风险识别Agent负责发现那些政策上合规但直觉上可疑的申请比如频繁小额拆分避审批、供应商信息异常、部门预算集中性突击申请等场景。这个Agent需要结合历史数据特征做判断是五个Agent里唯一允许输出模糊倾向的节点但它必须附带置信度分数和命中风险规则的编号。最后是决策仲裁Agent。它把前四个Agent的输出汇总按照预置的决策矩阵做最终判断。比如政策合规且有预算风险置信度低于0.3直接通过政策不合规转人工复核预算不足且无弹性空间直接驳回。决策仲裁Agent本身不做事实判断只做策略组合所以它的输出必须完全确定不允许模型自由发挥。这五个Agent之间怎么通信我们设计了一套基于JSON的Agent间协议Inter-Agent Protocol, IAP核心字段包括request_id链、agent_id、verdict、confidence、evidence引用、处理时间戳。每个Agent必须在固定字段里返回结论和证据谁都不允许在协议之外传小纸条。这个设计让整个链路的每一次判断都有据可查排障时沿着request_id就可以串起完整的决策链。3.2 提示词治理不让prompt散落在各业务线手里提示词在AI系统里本质上就是代码但绝大多数团队对待提示词的随意程度堪比随手写的便签。这次重构里我们把提示词当成一等公民来治理建了一套完整的提示词工程管线。首先是分级管理。每个Agent的提示词拆成三部分底座系统提示词模型行为设定、业务规则提示词动态注入策略、实例上下文提示词本次请求的数据。底座提示词由架构组统一维护变更要走评审业务规则提示词从配置中心动态加载按业务线隔离业务线可以自行调整但必须有版本记录实例上下文提示词由框架自动组装开发者不碰。其次是版本与灰度。每次修改提示词自动生成新版本平台支持两版本并行线上按流量比例灰度。灰度期间把两个版本的决策结果在影子模式下同时运行对比分歧率。只有分歧率低于预设阈值我们定的是5%且人工抽检无异常才允许全量切换。试运行半年最直观的收益是改prompt不再需要全量重新上线大版本一次策略微调半小时搞定。再就是上下文组装规范。模型调用时如果上下文窗口里有大量无关信息决策质量会明显下滑。我们明确规定了每类Agent的上下文组装模板意图解析Agent只注入申请单文本和少量历史样例合规Agent注入政策库中与本次申请类别相关的条目而不是全量政策。限定上下文范围既省了令牌费用又显著降低了模型想太多的几率。3.3 兜底与降级部署一套能救命的开关任何AI系统都可能遇到服务彻底不可用的情况——模型供应商服务不稳定、令牌超限、响应时间过长。新架构在模型网关之上设计了多级兜底策略这是从老系统模型挂了全站瘫的惨痛教训里学来的。第一级是模型路由。同一个Agent背后不止一个模型实例正常用主力模型比如旗舰推理模型网关实时监测各实例的错误率和时延超过阈值自动把流量切到备用模型比如轻量快模型。第二级是结果缓存。对于策略类判定如果模型输出和最近一次同类型判断一致且证据链相同可以走缓存直接复用降低调用量也提速。第三级是规则降级。如果所有模型都不可用网关自动进入规则兜底模式用确定性代码规则预算池判断、硬性政策校验保证核心预算控制功能不中断。降级模式下系统损耗的是智能度但保住了主流程的可用性。这套兜底机制特别重要。我见过不少AI项目做了一堆花哨的Agent能力但线上一次供应商故障就全盘瘫痪业务部门从此对AI系统失去信任。把降级预案做成架构的一部分而不是临头才想是这次项目经验里我认为最有普适价值的一条。4. 实操过程与关键环节实现从数据摸底到灰度上线的完整复盘4.1 准备阶段数据摸底与基线指标定义系统重构最怕拍脑袋尤其是AI系统没有基线数据后面所有优化都没法验证。我们第一步是花了两周做数据摸底目标就一句话把旧系统的真实表现量化出来。我们从预算审批系统中导出了过去12个月的历史数据包括申请单原文、审批结果、审批耗时、人工加判率、申诉率、通过/驳回分布等。这之后又对财务同事做了访谈把他们的日常工作量按类型拆解。这里要强调AI项目中的运维成本绝不仅仅是服务器和存储费用更大头是人力成本——金融审核差错时的排查成本、规则变更时的联调回归成本、模型效果波动的安抚解释成本。不把这些算清楚你根本说不明白降本40%的40%是怎么来的。摸底结果给了我们三组扎心的数字月度模型错误判定导致的财务复核量约占总单量的9%每次规则变更从需求到全量上线平均耗时11.5天因AI决策不透明导致的技术答疑工单约占IT部门月度总工单的22%每月大概消耗工程师48人时。这三组数字后来成了我们论证重构必要性的核心武器也成了项目验收时的对比基线。4.2 搭建评估集比模型训练本身更花心思的工作AI重构项目里最容易偷懒的就是模型评估环节。很多人拿二三十条样例跑一轮看着差不多就算通过这套做法在简单问答场景还凑合用在预算控制这种涉及钱和责任判断的系统里就是灾难。我们当时的做法是构建一个分层评估集从三个层面来测一共2000条真实脱敏样本。第一层是事实正确性占1000条要求模型对预算是否超限、政策是否合规等事实问题给出唯一正确答案这层数据由财务专家逐条标注。第二层是策略一致性占600条同一场景下模型判断必须稳定不能前一条说通过后一条说驳回。第三层是边界敏感性占400条专门选那些金额紧贴阈值、政策措辞模糊、多部门联合申请之类的极端场景。这400条是最难标注的我们拉了财务、法务、业务三条线的负责人一起评审最终确认了关键边缘case的处理准则。评估集建好后我们把它固化到CI管道里。每次模型升级、提示词改动、Agent逻辑变更都自动跑全量评估集输出效果回归报告——哪些指标升了哪些指标降了具体在哪几条case上翻转了判断。报告直接推送项目群作为上线决策的依据。这套机制极其有效可以说它是确保项目后期运行稳定的压舱石。4.3 开发与联调五个Agent串起来之前各自怎么测五个Agent如果直接全链路联调出问题根本定位不到是哪个环节。所以我们定了两个阶段的测试策略单Agent阶段和链路阶段。单Agent阶段我们为每个Agent准备了独立的评估集和测试用例集。例如意图解析Agent用300条不同业务线、不同写法的申请单测试抽取准确率字段级F1低于0.95不许进入下一阶段风险识别Agent用200条含可疑特征的申请单测召回率目标不低于0.9。每个Agent的输入输出都要做JSON Schema校验不合规的数据直接报错。链路阶段重点在于全链路追踪。我们用一个预设的追踪链机制贯穿五个Agent每条测试申请单进入系统都会生成全链路的执行记录每步的输入、输出、耗时、版本号全部落库。测试中我们用100条有代表性的复合场景比如市场部办大型活动涉及场地、差旅、物料、外包四项预算确认链路跑通且决策链路逻辑自洽。一个容易踩的坑是Agent间的数据传递。预算申请里金额是浮点数但意图解析Agent输出的时候可能格式化成字符串部门名称各业务线叫法不一解析Agent抽取出来对不上CMDB的编码。这类数据规范问题在单Agent测试里发现不了只有在串链路阶段才会集中爆发。我们开发了一个数据字典校验组件统一做实体映射与格式化解决得干净利落。4.4 上线灰度策略起步只放5%流量用影子模式跑了一周系统开发完成不等于可以全量上线。AI系统再自信也得保持对业务的敬畏尤其预算控制这种事情一旦模型乱了个套影响面不是误导几个用户而是直接造成财务风险。我们的灰度策略分四步第一步是影子模式Shadow Mode新旧系统并行跑一周。新系统所有Agent正常推理但结果不外发只对标注为影子样本的请求做全链路记录。我们把影子输出的决策和旧系统的实际决策做离线对比算一致性和分歧点供团队逐条人工分析。这一周我们发现最大的收获不是一致率而是分歧清单——每个分歧点都是一次发现模型问题或旧规则问题的机会。第二步是5%金丝雀放真实流量但只限内部员工批次。内部同事们在不知情的状态下提交预算申请系统自动进入新链路但所有判定结果仍要经过财务人工复核后才生效。我们在后台记录每一次AI判定与人工复核结果是否一致不一致的单独圈出来当晚复盘。这阶段我们连续跑了3天每日分歧率稳定在2%以内后才决定继续放量。第三步是逐步扩量按10%、25%、50%、80%这样分批加每一档停留24到48小时观察核心指标。扩到50%时风险识别Agent暴露了一个问题由于训练数据里拆分报销的样本占比偏高模型把很多正常的大额差旅申请也打成疑似拆分误伤率陡然升高。我们紧急调参在prompt里补充了单笔大额差旅且附完整行程单的豁免条件影子跑了一天确认误伤率回落才继续放量。第四步是全量切换。即便到了这一步我们还保留了旧规则引擎作为热备份新链路出任何兜底不了的问题30秒内切回旧系统这是最后一道真正的安全网。事实上这个安全网在后来的两个月里真派上过两次用场一次是上游预算系统变更导致预算数据短时缺失一次是模型提供商发布新版模型后Agent行为异常。这两次都是降到旧系统顶了一会儿确认无碍后再切回来。回滚能力本身就是AI系统架构里最值钱的投资之一。4.5 上线后的SRE体系除了监控还要看到每次决策的为什么系统上线只是开始运维真正的大戏在运行期。新架构配套建设了一套面向AI系统的SRE体系重点解决模型在黑盒里出了错怎么快速知道、如何快速定位、怎么快速修正三个问题。监控层面我们在Agent网关、模型网关、业务接口三个层级都建了监控大盘。传统监控看的是CPU、内存、时延、错误率这套监控还要多一层业务恶指标的观测预算池消费速率异常波动、AI决策驳回率突升、意图解析失败率上升、决策分歧率偏离基线。任何一个业务层的异常信号都会触发告警附带最近时间窗内的决策样本供排查。定位层面全链路请求追踪系统把一次预算申请从进入系统到最终决策的所有步骤串起来。排障时输入request_id就能看到每个Agent的输入摘要、输出结论、置信度、命中的规则、调用的模型版本和对应的prompt版本。这一切信息整理成决策报告展示体验比传统系统翻日志清爽太多。我甚至为了这个专门给系统做了个决策回放功能把一次判定重演一遍方便财务团队培训新人时直观理解AI的判断逻辑。修正层面我们建了一套AI运维工单流。业务或财务反馈一个错误判定工单自动带上该笔申请的全链路决策快照。运维人员基于快照判断问题出在哪个Agent、哪个规则、哪个prompt条件然后可以直接在线修改对应配置提交后走轻量化评审影子验证通过就发布。整个流程端到端最快能在4小时内完成收敛而旧架构的同类修复周期是3到5天。这种快速定位-快速修正-快速验证的闭环才是运维成本下降最直接的体现。5. 常见问题与排查技巧实录上线后踩过的那些真实的坑先说明一下这里的问题清单全部来自真实运行现场不是教科书示例。我把高频问题、排查思路和解决方式整理成了一份速查表方便你做同类系统的时候直接对照排查。问题一模型决策漂移同一笔单据隔几天给出不同结果这是AI系统运维中最头疼的问题。表征是财务复核发现同一张发票、同一段申请理由上周绕过这周拦了没有任何配置变更模型也没更新。排查思路是从数据侧入手检查申请单文本有没有细微变化比如多了个空格、标点换了半角全角模型对token敏感检查上下文里动态注入的政策文本是否有变动检查模型供应商是否在后台悄悄切换了版本这种供应商行为最容易忽视。我们最终的解决方案是给所有Agent调用打印输入hash并在决策记录里保存完整上下文快照每次判断都对得上再也不用靠记忆猜差异。问题二提示词微调导致蝴蝶效应式全链路行为异常有一段时间我们调了风险识别Agent的prompt单独回归测试各项指标都正常但上了全链路发现决策仲裁Agent的驳回率从8%飙到15%。排查后发现原因链是风险识别Agent的新prompt让它的疑似拆分信号输出更激进仲裁Agent收到更高比例的风险标记综合判断的时候自然更保守。根因是Agent之间耦合的隐式信号被打变了单个Agent的指标没暴露出来。这次教训之后我们把全链路的决策组合分布加进了每次Agent变更的回归指标里任何Agent变更新旧版本先跑一遍全链路影子对比确认终端决策分布漂移不超限才放行。问题三模型幻觉在预算场景里的低级错误大模型会在预算金额计算上犯很蠢的错误比如把差旅费12000会议费8000总预算20000直接抽成总金额28000或者把三日差旅的住宿费单日上限算成三日总上限。这类幻觉用评估集能拦住大部分但总有新写法让它漏过去。我们的防护策略是治理数据管道——从意图解析出口直接接一个确定性计算校验组件金额字段全部过代码逻辑复算累计项重新相加对比超差自动报警并降级转人工。宁可牺牲一点自动化的酷炫感也不让模型在算术这个环节自由发挥。问题四Agent通信协议字段被模型自由发挥最开始IAP协议里有一个备注字段本意是让模型补充说明结果模型经常把重点结论写在备注里而忽略了正式字段。解析端严格按JSON Schema解析发现备注字段有重要内容时已经晚了。这个问题的修复方式是收紧协议所有关键结论必须进结构化字段备注字段只接受不超过50字的简短补充说明多余截断。文化上也要向业务宣传AI输出的结构完整性比表达丰富性更重要。**问题五上游数据抖动导致AI误判系统运行中有一晚合规Agent突然大批量给出政策引用失败。查了半天发现是政策库配置中心发了一次变动通知部分策略条目在切换过程中短暂不可用合规Agent拿不到政策文本就返回了一个降级结果无匹配政策放行。这个降级策略本身没错但问题在于没有判断政策库不可用和政策不适用是两回事结果一批本应拦截的申请被放过去了。好在我们当时有影子模式对比和抽样复核48小时内发现了问题并修正。这事的教训是Agent的降级逻辑必须显式区分数据缺失导致的降级和正常策略决策出现未知状态时必须转人工宁可慢不可错。问题六需求方说为什么AI判错了时的沟通方法这类问题虽然是管理问题但对AI系统项目的推进极为关键。财务同事拿着被系统误拦截的申请单来找你第一反应往往是AI就是不行。如果只回一句算法概率问题难免出错项目基本就凉一半。我们的实际做法是对每一条争议都给出基于决策快照的完整解释——输入的哪些信息让系统判断超限、命中了哪条政策规则、置信度是多少、在什么条件下会放行。加了这层解释之后财务同事对系统的态度从质疑转向配合调优还主动提供了不少历史案例协助补充训练集。维护一个好的AI系统一半功夫在技术上另一半在于对业务方始终保持开放和清晰的沟通。6. 项目复盘运维成本降40%的本质是把模糊责任变成了清晰流程前面写了这么多技术细节最后绕回那个最容易被过度宣传的数字——运维成本降40%。我不想把这个数字做成一个响亮但空洞的口号而是把账算明白。重构前后我们按月度统计了预算控制系统的综合运维投入包括故障处理人时、规则变更人天、模型迭代人天、业务答疑工单人时和基础设施资源费用。旧系统时期月均约40人天的综合投入重构半年后稳定在月均24人天左右降幅正好落在40%附近。细看每个环节故障处理从每月8次降到了2次平均处理时间从6小时压到1.5小时规则变更从月度11.5天缩到2.5天业务答疑工单从48人时降到20人时。基础设施费用其实没什么大变化降的全是人的时间和情绪损耗。我想说明的是降本的根源不是某个模型更聪明了而是整个系统从不可解释的黑盒变成了可观测、可回滚、可评估的治理体系。AI系统的运维成本高低本质上是系统不确定性带来的连锁反应成本。你为不确定性设计的治理机制越完善隐性成本被吸收得就越多运维负担就越轻。最后分享两条我个人在这个项目里体会最深的心得供做同类项目的朋友参考。第一条AI系统架构重构不是换模型而是给系统装上仪表盘、刹车、油门和备胎。模型的每次替换都应该是平滑的、可验证的、可回退的不要做任何不可逆的技术决策。第二条永远要把业务方的信任当作一等公民来维护。信任不是说你的系统永远正确而是出问题时你能在半小时内给出有说服力的解释并快速修正。就好像人一样AI系统有时也会犯错但好的系统构建了快速修复的循环——这比任何华丽的架构图都更有说服力。如果你也在做类似的AI系统落地或架构重构希望这篇复盘能让你少走弯路。说到底架构没有标准答案只有对业务风险、团队能力和技术边界的清楚认知。祝好运。