ai-engineering-from-scratch这个项目名我在本地躺了好几个月。一开始以为就是照着教程调接口、拼几个提示词结果真上手做了几轮之后发现大模型应用工程化这件事真正吃时间的不是模型本身的调用而是模型外围的那一圈基础设施。今天想把这些散落在我好几个项目里的经验集中复盘一下给正准备从零搭AI服务的团队一些可以少走弯路的参考。我聊的范围主要是多业务方接入时的模型网关该怎么设计、Prompt怎么从写提示词升级成可评测的资产、Agent在真实业务里的状态与工具调用怎么才能不出乱子、以及最容易被忽视的质量防线和成本控制。这些内容不依赖某个具体的大模型厂商换哪家底座思路都成立。1. 为什么从零开始意味着先设计Model Gateway层很多团队接到AI需求后的第一反应是写一个Service直接调模型API凭感觉挺快。但只要接入方超过两个——App、Web、客服工作台、内部运营工具——调用关系立刻变得不可控。我见过最典型的局面是每个业务线各自申请了一个API Key各自写超时重试各自的上下文策略还不一样出了问题谁也说不清是模型的锅还是某个业务方的锅。所以我的建议非常直接项目一开始哪怕预估只有两个调用方也先搭一个Model Gateway层。这不是过度设计而是给后续所有工程化动作留一个统一收口的地方。1.1 先理清AI应用的整体调用拓扑搭Gateway之前先花半天把调用拓扑画清楚。问自己三个问题谁在调调哪个模型能力每种调用场景的容忍度是怎样的举个例子一个智能客服项目至少有三种调用形态用户进线时的意图识别需要低延迟300毫秒内必须出结果多轮回复生成可以接受2秒左右离线工单摘要完全不实时走队列异步处理就行。三种形态对模型的延迟、成本、上下文长度要求完全不一样如果都走一个裸接口最后必然是谁的需求都满足不好。画拓扑时我习惯用一张表格记录每个场景的SLA要求这直接决定后面Gateway的配置策略调用场景实时性要求最大容忍延迟单次上下文上限可接受成本级别意图识别高300ms1k token内低多轮对话生成中2s8k token内中工单摘要低5min32k token内高有了这张表你才知道模型路由、上下文压缩、重试策略该往哪个方向设计而不是等到上线前才问为什么这么慢。1.2 Gateway的三件套路由、上下文压缩与重试策略Model Gateway最核心的是三件事路由、上下文压缩、重试与熔断。路由不是简单按流量随机分而是按场景路由。同一个能力简单场景可以走小参数模型复杂场景走大参数模型。比如意图识别这种分类任务Top-5候选加一个打分逻辑小模型完全能搞定没必要每次都把几万token的上下文发给最强的模型。上下文压缩是我见过最容易漏掉的功能。很多团队觉得对话历史越多越好一股脑全塞给模型。实际情况是上下文一长延迟和成本都在涨效果还会因为迷失在中间而下降。我在Gateway里做了一个自动摘要层当对话历史超过6轮就把前面的内容压缩成一个200字左右的结构化摘要只保留实体、关键问题、已确认的信息。实测下来生成质量没有掉token成本降了接近一半。重试和熔断一定要做在Gateway这一层。模型API偶发超时几乎无法避免我的策略是连续3次超时触发熔断熔断持续30秒用滑动窗口统计错误率错误率超过5%就自动摘除该模型节点并切到备用模型。熔断期间返回一个降级话术给业务方而不是把超时错误直接抛给用户。2. Prompt工程化从提示词到可评测的资产Prompt是AI应用里最像代码的部分但很多人处理它的方式跟处理配置文件一样随意。我见过有人直接在代码里改Prompt字符串改完上线线上出问题后甚至不知道当前线上跑的是哪个版本。如果你把Prompt当成静态文本那它永远只是提示词如果你把Prompt当成一份需要版本管理、灰度上线、回滚的资产它才真正被工程化了。2.1 一个Prompt从草稿到上线要过的四道关我现在的习惯是团队里任何一个Prompt要上线必须过四道关。第一关是拆任务结构。一个理性可控的Prompt应该至少包含五个部分任务指令、用户输入、参考上下文、输出格式约束、评判标准。很多新手喜欢把这几样揉在一段自然语言里模型也能跑但出了问题你根本定位不到是哪块在影响结果。拆开之后调优才有的放矢。第二关是设计Few-shot样例。我踩过最大的坑是觉得样例越多越好结果用了12个样例反而比8个样例效果更差。原因是样例太多、太杂模型会从里面学到不一致的模式。我的经验是Few-shot控制在5到8个并且覆盖两类最常见的主路径3个边界和反例2到3个。少而精永远好过多而糙。第三关是跑对抗样本。空输入、超长输入、带恶意指令的输入、乱码、重复字符至少各准备10条。不要觉得这是测试同学的事Prompt的鲁棒性写Prompt的人自己要负第一责任。第四关是版本化。每个Prompt在Gateway里都有一个version字段请求日志里必须记录当时用的版本号。这样任何时候都能快速对比A版本效果比B版本好这个结论到底成不成立。没有版本号的Prompt出了线上问题你连排查的入手点都没有。2.2 评测集怎么建才不会被业务方质疑这是Prompt工程化里最容易被轻视的一环。很多团队建评测集就是拉几条业务方提供的典型问题然后让人工打打分完了。结果评测评测业务方一句这些题不是真实场景就白干。我建议评测集至少分三类。第一类是标准集从历史真实日志里抽样覆盖主要意图和典型话术大概200到500条。第二类是边界集专门放那些让人犹豫的case比如意图模糊、多个意图混杂、输入带错别字。第三类是回归集每次调整Prompt之后必须重新跑一遍防止修了A问题破坏B问题。评分标准最好是可计算的。意图识别可以用macro F1抽取任务可以用实体级别的精确率和召回率生成类任务可以用关键点命中率——先定义这个回答必须包含哪几个信息点模型输出里每个点是否出现算一个命中比例。别动不动就上人工打分人工打分的主观性会导致评测结果无法复现。评测集建好之后每次Prompt变动都要产出一份对比报告改动前和改动后在标准集、边界集、回归集上的指标变化。只有这个流程跑起来了业务方才愿意相信你的每次改动是有数据支撑的而不是拍脑袋。3. Agent状态与工具调用的可靠性设计如果说前面讲的是单次模型调用层面的工程化那Agent就是一个状态机和工具调用的组合问题。很多人第一次做Agent上来就写一个大循环把用户问题交给模型模型决定调工具拿到结果再交给模型循环往复。Demo阶段这样写完全没问题但一旦进入生产这个循环里没有任何状态边界任何一个步骤出错都可能导致整个对话跑飞。3.1 状态机的选择为什么不用无脑编排我的建议是给Agent定义一个显式的工作流状态机。每个会话都有一个状态字段取值大概是pending等待模型决策、running模型回答中、tool_called等待工具返回、need_human转人工、done完成、failed失败。每进入一个状态都写一条结构化日志。这里的关键不是状态本身而是状态转移的约束。比如从tool_called只能转移到running或failed不能直接跳到done。这个约束可以挡住一类非常隐蔽的问题模型输出一段话但工具实际没有执行成功结果系统把模型的计划描述当成已执行结果回给了用户。状态机还有一个好处是天然支持人工介入。用户说算了不问了你可以把状态置为need_human或done终止整个循环。没有状态机的Agent打断它是一件很麻烦的事你只能靠超时硬切。3.2 工具调用的错误处理与自愈机制Agent比单次Prompt复杂的地方在于模型会用自然语言描述工具调用但工具本身只认结构化参数。所以我的一个硬性要求是模型返回的tool_call必须过一层JSON Schema校验校验不通过直接让模型重新生成而不是把脏参数发到工具里。超时控制也要分两层。模型生成首token超时和工具执行超时是两件完全独立的事。我给工具的默认超时是8秒模型决策轮次的整体超时是30秒。工具超时后不直接fail整个Agent而是把错误信息作为下一次模型决策的输入让模型决定是重试、换工具还是直接给用户一个兜底回答。自愈机制里还有一个容易被忽视的点同一个工具调用同一个错误入参最多重试两次。我之前遇到过一个问题模型反复用同一个格式错误的参数去调天气接口白白浪费了4次调用每次都要等超时。加了重试上限之后这种情况直接被截断系统自动走降级流程。工具执行的日志里必须记录工具名、入参、出参、耗时、错误码。没有这套日志Agent出了问题你只能对着模型输出猜非常痛苦。4. 质量防线离线评测、回归集与线上观测很多团队做AI应用把大部分精力放在怎么让模型回答得更好上却很少投入精力建怎么证明模型没有变差的质量防线。在大模型这个领域模型版本会更新、Prompt会调整、业务数据分布会漂移任何一个变化都可能让线上表现肉眼可见地下滑。没有质量防线你连下没下滑都说不清。4.1 离线评测的召回率陷阱我最开始做离线评测时犯过一个挺典型的错误只盯着准确率看结果某些场景的召回率低到没法看业务方一反馈才发现。单看准确率的问题在于当某一类样本占大头时模型只要把所有case都判定成那一类准确率也能很好看但真正需要被识别出来的那部分稀有case全被漏掉了。所以评测报告永远要同时给出精确率、召回率、F1并且按意图类别分开列。不要只给一个总指标。比如在客服场景里退款投诉类意图的召回率比总准确率重要得多——漏掉一条投诉类型的识别损失的是一整个客诉升级流程的启动。回归集的价值就在这个时候体现。每次模型版本升级、Prompt调整或者业务上新功能全量跑一遍回归集对比各项指标和上一版本的变化。发现问题的时间越早修的成本越低。等到线上用户反馈再回头追往往已经晚了。4.2 线上日志要采集哪些字段才能还原问题离线评测再完善也替代不了线上观测。AI应用的线上日志采集字段要比普通接口多得多。我建议至少包含这些请求的唯一trace_id、Prompt版本号、模型名称和参数温度、top_p、输入上下文摘要、输出全文、各阶段耗时明细Gateway耗时、模型首token耗时、工具调用耗时、输入输出token数、用户后续行为是否点了反馈按钮、是否重新提问。这里有个实操细节完整输入上下文可能很大全量存日志成本很高所以我存的是特征化摘要——意图标签、关键实体、消息轮数、上下文总token数。原始上下文只在需要排查时通过trace_id去专门的存储里捞而且设置24小时自动清理既满足排查需求又控制成本。线上观测最核心的目的是能快速回答三个问题某个请求为什么这么慢、为什么错、为什么贵。没有这些字段这三个问题一个都答不了。5. 成本、延迟与并发稳定性的最后一公里AI应用上了线性能瓶颈往往不在你的服务本身而在模型API这一侧。模型API有延迟波动、有并发限制、有token成本而且这三件事高度耦合。我见过不止一个团队 Demo跑得很好一上线就被并发打垮或者月底看到账单直接懵掉。5.1 Token成本拆解与缓存策略Token成本拆解这件事最好从项目第一天就做。我的做法是在Gateway层面给每个业务线、每个调用场景打上成本标签每天用一张表汇总各场景调用次数、输入token总量、输出token总量、模型类型、预估费用。只有这样你才能第一时间发现某个场景一个月吞了60%的预算这种问题。成本控制最有效的手段是缓存。我这里说的缓存不是把完整输出缓存而是场景化缓存对于同类输入且模型温度设为0的任务可以精准命中缓存对于语义相近的输入用向量相似度缓存相似度阈值我设的是0.92。意图识别这种任务直接缓存相似意图的判定结果能省大概30%的调用量。还有一类成本优化是模型分级。在低风险场景用轻量模型在高风险场景用强模型。同样是摘要能力内部测试工具的摘要用轻量模型就够了面向客户的摘要才需要上最强模型。分级不是简单省成本而是把钱花在用户真正感知得到的地方。5.2 并发控制与限流的实操参数模型API的并发控制比普通接口复杂的地方在于你不光要保护自己的服务还要保护上游模型API。给每个业务方分配一个令牌桶单用户QPS设为2全局QPS设为50超出部分直接进队列而不是立刻报错。队列长度上限我设为100超过100就走降级——直接提示用户稍后再试或者切到备用模型。另一个值得注意的参数是并发缓冲。模型API给的官方并发上限不要用满至少留30%的余量。因为模型API的延迟是动态的高峰期一波动哪怕并发没有超限整体的排队时间也会指数级上升。留缓冲意味着给自己留了应对尖峰的空间。异步化也是降低延迟的重要手段。凡是用户不感知同步结果的任务全部踢到消息队列里走异步。比如工单摘要、语音转写、报表分析用户提交后直接返回任务已接收模型结果出来了再通过回调通知。这个改动的收益非常直接用户的等待时间从必须等模型跑完变成等任务状态变化。踩了几轮坑之后我个人最深的体会是AI工程化里大部分难题都不是模型不够聪明而是模型周围的基础设施不够可靠。Model Gateway、Prompt资产化、Agent状态机、质量防线、成本与并发控制这些东西单独看好像都不复杂但组合在一起才是让AI应用从Demo走向稳定产线的真正关键。先做哪个后做哪个我的建议是从Gateway入手——一切工程化都需要一个统一的收口有了这个收口后面的版本管理、评测、观测、成本拆解才都有地方挂靠。最后分享一个我一直在用的关注点任何AI功能上线前先问团队一句如果模型API挂了我们怎么办。能把这个问题答清楚的团队AI应用大概率差不到哪去。