如果你做过几年后端开发大概率遇过这种场面线上接口突然被刷爆数据库CPU直接拉满监控图上红色告警一个接一个如果你最近又在折腾大模型应用大概率也遇过另一种场面同一个问题换几种问法模型给出的答案质量忽高忽低甚至一本正经地胡说八道。这两个问题初看毫无关系但我在同时做微服务网关治理和LLM应用开发时发现底层逻辑惊人一致——都是在做“输入端控制”。网关限流熔断控制的是请求的流量和稳定性Prompt工程控制的则是输入给模型的指令和上下文质量。理解了其中一个另一个基本就通了。这也是今天这篇文章的由来用微服务网关的限流熔断思路一次讲清大模型Prompt工程的核心原理。全文我会从真实项目视角出发把Sentinel限流降级、AOP注解限流、网关层的流量控制讲透再拿这些工程概念去对照Prompt设计中的上下文窗口、系统提示词、输出约束和降级策略。文章不算短但每一节都有实际可抄的配置、代码和思考路径适合正在做微服务架构、又想上手大模型应用的后端开发者。1. 为什么把网关限流熔断与Prompt工程放在一起讲1.1 两者共享同一个核心输入端决定输出端限流熔断的核心出发点是防止不可控的请求把系统打垮。一个接口如果每秒只能处理1000个请求你放进来2000个处理不了的请求就会堆积、超时甚至拖垮整个服务。所以网关要在入口处做一道闸门把流量控制在系统能承受的范围内。Prompt工程的核心出发点是让大模型在给定的上下文窗口内接收到最能被正确理解的信息。模型的能力上限就摆在那里你的提示词给得模糊它回得就模糊上下文塞得太乱关键信息被淹没模型就可能忽略你真正想要的内容。这两件事在抽象层面是同一个逻辑输出端的质量上限取决于输入端被控制的程度。网关控制的是请求量Prompt控制的是信息量。一个管“进不来太多”一个管“进来的都是对的”。我把这种对照进一步细化了直接列成一张表方便后续展开时反复引用对照维度微服务网关限流熔断大模型Prompt工程核心目标保护后端服务稳定性提升模型输出质量控制对象外部请求流量输入给模型的指令和上下文超限后果服务过载、雪崩上下文溢出、注意力分散常用手段限流、熔断、降级、隔离系统提示词、结构化指令、Few-shot示例、输出约束关键参数QPS阈值、熔断时间窗上下文窗口、温度参数、max_tokens策略配置规则下发到网关Prompt模板写入业务层1.2 后端工程师上手大模型最快的路径我见过不少后端同事学大模型一上来就啃Transformer论文看注意力机制公式研究损失函数怎么算结果看了一周还在前向传播里打转回头业务上连个像样的Prompt都写不好。我的建议是换个路径把你已经掌握的工程体系当作参照系。你已经懂了流量控制、服务保护、降级兜底那学Prompt工程的时候就带着这套框架去映射。看到“系统提示词”你就想这像不像网关里的全局规则看到“上下文窗口”你就想这像不像限流里的队列容量看到“温度参数”你就想这像不像调整限流阈值的旋钮。这种迁移式学习最大的好处是你不用从零建立认知模型而是在已有骨架上挂新知识。理解速度会快很多踩坑的时候也更容易找到原因。2. 微服务网关限流熔断的落地手段拆解2.1 Sentinel从规则配置到熔断降级先讲Sentinel这是阿里开源的流量防卫组件也是目前微服务架构里用得最多的限流熔断方案之一。它的核心模型分两块限流和熔断降级。限流这一块Sentinel提供了多种维度最常用的是QPS维度和并发线程数维度。QPS维度适合接口类场景比如某个查询接口每秒钟最多允许100个请求进来并发线程数维度适合处理时间不可控的场景比如业务里调了外部接口响应可能快也可能慢用并发线程数限制“同时处理几个请求”比单纯限制QPS更贴合实际。熔断这块Sentinel做的其实是三种状态之间的切换关闭、打开、半开。正常情况下熔断器是关闭状态请求正常通过当错误率或慢调用比例超过阈值熔断器打开后续请求直接拒绝经过一段时间后进入半开状态放少量请求试探如果试探成功熔断器关闭服务恢复如果试探失败继续熔断。看一个实际的规则配置片段我用的是Spring Boot Sentinel的集成方式Configuration public class SentinelConfig { PostConstruct public void initRules() { // 限流规则/api/order/create 接口QPS每秒最多20 FlowRule flowRule new FlowRule(); flowRule.setResource(/api/order/create); flowRule.setGrade(RuleConstant.FLOW_GRADE_QPS); flowRule.setCount(20); flowRule.setLimitApp(default); flowRule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); // 熔断规则接口异常比例超过50%熔断10秒 DegradeRule degradeRule new DegradeRule(); degradeRule.setResource(/api/order/create); degradeRule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO); degradeRule.setCount(0.5); degradeRule.setTimeWindow(10); degradeRule.setMinRequestAmount(100); FlowRuleManager.loadRules(Collections.singletonList(flowRule)); DegradeRuleManager.loadRules(Collections.singletonList(degradeRule)); } }这段配置里的几个参数要解释一下。setCount(20)是QPS阈值我当时的经验值是先看基线流量和压测数据比如单机这个接口的极限TPS是80那线上限流通常设置在极限值的四分之一到三分之一也就是20到30之间留足余量又防止单机被打穿。setCount(0.5)是异常比例阈值意思是100个请求里如果有50个抛出异常就触发熔断。实际项目中我一般设置在0.3到0.5之间太低会误伤偶发异常太高又起不到保护作用。setMinRequestAmount(100)这个参数很容易被忽略它的作用是防止流量太低时几个请求出错就触发熔断必须累积到100个请求再参与统计这个数字可以根据业务量往上调。2.2 网关层限流Spring Cloud Gateway RequestRateLimiter到了微服务架构里限流不应该只落在每个业务服务内部更应该在网关层做一层统一的流量控制。这样上游流量在入口就被拦住业务服务天然安全。我用的是Spring Cloud Gateway内置的RequestRateLimiter过滤器它基于令牌桶算法实现通过Redis配合完成分布式限流。令牌桶算法可以这样理解有一个桶里面以固定速率放入令牌每个请求进来必须取走一个令牌桶空了请求就被拒绝。相比计数器限流令牌桶的好处是可以应对突发流量比如桶容量是100令牌生成速率是每秒50个短时间内即使有100个请求同时进来只要桶里有足够令牌也能放进去不会立刻拒绝。Spring Cloud Gateway的配置长这样spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path/api/order/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 50 redis-rate-limiter.burstCapacity: 100 key-resolver: #{userKeyResolver}这里replenishRate代表每秒往桶里放多少令牌burstCapacity代表桶的最大容量。我实际项目里网关层和业务层的限流做了分层网关层限流是粗粒度防止入口被打爆阈值会设置得宽松一点业务层限流是细粒度针对不同接口的特点设置更精确的阈值。有一个特别容易踩的坑网关限流默认按IP维度做但用户如果经过Nginx转发所有请求的IP都是Nginx的限流就形同虚设。解决办法是自定义KeyResolver从请求头里取真实的用户标识Bean public KeyResolver userKeyResolver() { return exchange - { String userId exchange.getRequest().getHeaders().getFirst(X-User-Id); if (userId null) { userId exchange.getRequest().getRemoteAddress().getAddress().getHostAddress(); } return Mono.just(userId); }; }这个细节当时修复了一个线上大问题——如果不按用户维度区分一个用户疯狂请求就会把所有人的限额都占掉。2.3 AOP注解式限流接口级精准控制Sentinel和网关能覆盖绝大多数场景但对单个接口的灵活限流我更喜欢用AOP注解的方式做自定义。这种方式侵入性最小代码可读性最好适合那种“这个接口有点危险我要单独管一管”的场景。思路很简单定义一个注解RateLimit然后写一个切面拦截所有标注了该注解的方法。限流计数可以用Redis的原子操作完成也可以用本地内存做单机限流。我先展示一个基于Redis的实现Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RateLimit { String key() default ; long limit() default 100; long timeout() default 1; } Aspect Component public class RateLimitAspect { Autowired private StringRedisTemplate redisTemplate; Around(annotation(rateLimit)) public Object around(ProceedingJoinPoint joinPoint, RateLimit rateLimit) throws Throwable { String key rate_limit: rateLimit.key(); Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1L) { redisTemplate.expire(key, rateLimit.timeout(), TimeUnit.SECONDS); } if (count ! null count rateLimit.limit()) { throw new RuntimeException(请求过于频繁请稍后再试); } return joinPoint.proceed(); } }这个实现有几个可以优化的点。count 1时设置过期时间是为了避免每次请求都刷新过期时间导致限流窗口被无限拉长。但这种写法在高并发下会有一个问题如果同一瞬间有大量请求进来多个请求都会读到count为1都去设置过期时间虽然不影响限流本身的正确性但会产生多余的操作。更稳妥的方案是用两步操作写一个原子一点的逻辑或者在Redis里用Lua脚本。不过本地调试的时候我更喜欢用一个基于AtomicLong的简化版本省去Redis的依赖Component public class LocalRateLimiter { private final ConcurrentHashMapString, AtomicLong counters new ConcurrentHashMap(); public boolean tryAcquire(String key, long limit, long windowSeconds) { long currentWindow System.currentTimeMillis() / (windowSeconds * 1000); String counterKey key : currentWindow; AtomicLong counter counters.computeIfAbsent(counterKey, k - new AtomicLong(0)); long count counter.incrementAndGet(); if (count limit) { return false; } if (count 1) { // 清理旧窗口的计数器防止内存泄漏 clearExpired(key, currentWindow); } return true; } private void clearExpired(String key, long currentWindow) { counters.keySet().removeIf(k - k.startsWith(key :) !k.endsWith(: currentWindow)); } }这里用时间窗取整做计数器的Key窗口切分的思路和Sentinel的滑动窗口本质上是一样的只是粒度更粗糙。本地限流适合单机部署的场景多机部署还是得上Redis或者Sentinel集群。3. 从流量治理到Prompt工程控制策略的迁移3.1 服务质量与生成质量的量化标准把限流熔断的思维迁移到Prompt工程第一步是弄清楚一件事什么样的Prompt是“高可用”的网关限流有明确的指标——QPS、错误率、RTPrompt工程有没有对应的量化标准我自己实践下来Prompt工程的指标可以这么拆指标限流场景含义Prompt场景含义成功率请求被成功处理的比例模型输出符合预期格式和内容的比例垃圾输入无效请求、攻击请求无关上下文、矛盾指令、模糊表述超时请求处理时间超限模型输出过长、生成卡顿降级兜底服务挂了返回默认值模型输出异常时的备用方案容量规划系统能承受的最大QPS上下文窗口能容纳的最大信息量想通了这几个指标你就会发现调接口限流你得先知道系统瓶颈在哪调Prompt你得先知道模型在什么输入下会崩溃。两个过程都依赖“先测量再优化”而不是拍脑袋。3.2 阈值思维滑动窗口与上下文窗口的共同逻辑限流里最核心的算法之一是滑动窗口。它的思想是把一个大的时间区间切成多个小窗口统计当前时刻往前推移的窗口内的请求数量。每一秒都在变窗口也跟着滑这样既避免了固定窗口在临界点的突刺问题又比全量统计节省性能。大模型的上下文窗口也有类似的逻辑。以常见的32K上下文窗口为例模型一次能“看到”的信息量是有限的。超过这个量前面的信息就会丢失或者被压缩。你在写Prompt时本质上就是在做“滑动窗口管理”——只放入窗口内最高价值的信息把无关内容挡在外面给关键信息留出充足的“注意力空间”。我实际开发大模型应用时会把上下文窗口的预算做成一张表强制团队按这个预算写Prompt模板上下文窗口总预算32K tokens ├── 系统提示词System Prompt固定占2K长期保持稳定 ├── 用户输入平均占8K可动态变化 ├── 检索到的参考上下文占10K按相关性排序截取 ├── Few-shot示例占6K选择最能代表业务场景的3-5个示例 └── 输出预留占6K防止生成的答案被截断这个预算分配方案和网关限流设置QPS阈值是一个思路先摸清总量再按优先级分配最后留足缓冲。如果某个业务想把检索上下文加到15K就必须从Few-shot示例里缩。预算不够还硬塞结果就是模型注意力被稀释前后信息矛盾输出质量断崖式下降。4. Prompt工程核心实践一次讲清4.1 高可用Prompt的标准结构我写过很多Prompt模板也帮团队review过大量提示词最后总结出一个通用结构适用于绝大多数业务场景。这个结构分五层第一层是角色设定。给模型一个清晰的身份比如“你是一名客服助手”“你是一个数据分析师”。角色设定就像是网关里给某个路由打的标签决定了后续处理请求的默认行为。第二层是任务指令。明确告诉模型要做什么比如“根据用户问题从给定的资料中提取答案并简洁回复”。指令要具体、动作明确避免“帮我看看”“分析一下”这种模糊表达。第三层是上下文信息。这是模型回答的依据可以是业务数据、检索到的文档、用户历史记录等。这层对应限流里的“流量来源”来源的质量直接决定了结果的质量。第四层是示例数据。给模型几个输入输出对让它按照示例的格式和风格来回答。Few-shot是最有效的Prompt优化手段之一效果往往比语言描述强得多。第五层是输出约束。限定输出的格式、长度、语气比如“用Markdown列表输出”“不超过200字”“如果信息不足回答‘无法判断’”。这层对应的就是限流的“拒绝策略”超出能力范围就明确拒绝而不是硬答一气。4.2 从系统提示词到输出约束逐层往下拆听概念容易落到实际就难。我拿一个客服问答场景的Prompt模板来拆解这是我在一个演示项目里用过的结构比较典型系统提示词 你是一名电商平台的智能客服助手。你的任务是解答用户关于订单、退换货、物流、优惠券的疑问。 你必须遵守以下规则 1. 只能根据提供的资料回答不能编造信息。 2. 如果资料中没有答案直接回复“抱歉这个我暂时无法确认”。 3. 回答要简洁不超过150字。 4. 涉及金额、日期时必须和资料原文完全一致。 用户输入 订单20241218001到现在还没发货是什么情况 参考资料 [订单状态表] 订单号:20241218001 状态:已支付 预计发货时间:2024-12-20 物流异常:无 [物流配置表] 默认发货时效:48小时 特殊商品:预售商品发货时效为7天 模型输出 您好订单20241218001当前状态为已支付预计发货时间为2024年12月20日目前在正常发货时效内请耐心等待。这个模板里系统提示词设定了角色的行为边界规则里的“只能根据资料回答”和“没有答案就承认”就是降级策略避免模型胡编。参考资料给了模型回答所需的上下文但控制了范围没有把整个知识库塞进来。如果换成限流语言来理解系统提示词就是网关层的全局默认规则所有请求进来先受它约束用户输入是具体请求参数不同但都走同一条路由参考资料是上游数据源数据质量差后面的处理再精细也白搭。4.3 一步步打磨Prompt的高可用性很多新手把Prompt工程想得太玄或者反过来觉得太简单。我的经验是它和调限流参数一样是个逐步迭代的过程。第一步写一个“能跑”的初版。不用纠结优化先把角色、任务、上下文、约束四要素补齐保证模型能给出一个可用的输出。最低限度是固定格式让模型输出能被程序解析。第二步跑一批测试用例。准备20到50条覆盖正常、边界、异常场景的用户输入逐个跑一遍记录输出的质量和失败模式。这一步对应限流里的压测先摸清系统的真实表现。第三步定义你的“限流阈值”。统计哪些类型的输入会导致输出失败是上下文太长被截断还是模型回答超出了预期格式还是引用资料时张冠李戴把问题分成几类按频率排序。第四步针对Top3问题调整Prompt。比如模型总是不遵守输出格式就加“你必须严格按照以下JSON格式输出”比如模型回答过长就加硬性字数约束并在示例里展示一个短回答。我自己的经验是80%的输出质量问题集中在没给够示例和没交代清楚边界这两件事上。其余才是参数和模板结构的问题。5. 实际项目对照一个后端限流与LLM生成结合的演示5.1 演示项目背景与整体架构为了把上面的思路串起来我最近做了一个小的演示项目场景是“智能订单查询助手”用户在前端输入问题后端通过大模型生成答案同时整个查询链路要经过微服务网关保护。架构非常简单清晰前端请求 → Spring Cloud Gateway限流每用户每秒最多5个请求 → 订单查询服务SentinelQPS限流、异常率熔断 → 判断问题是否需要大模型辅助 ├── 不需要直接查订单库返回结构化数据 └── 需要调用大模型API使用预置Prompt模板 → 将AI回答返回前端网关限流管住入口流量服务层限流管住业务压力大模型调用这个环节单独做配额控制。三个层级各管一段对应到生产环境就是接入层防攻击服务层防过载外部依赖防超预算。5.2 微服务侧限流熔断的具体配置先看网关层的配置。因为这是个需要登录的系统限流维度选择了用户ID而不是IP。对应上面的KeyResolver配置中限流参数做了区分普通查询接口每用户每秒5个请求如果是大模型生成接口阈值更低每用户每秒2个请求因为大模型生成的成本远高于一次普通数据库查询。订单查询服务的Sentinel规则配置PostConstruct public void initOrderRules() { // 订单查询接口QPS限流撑不住就直接降级返回缓存数据 FlowRule orderFlow new FlowRule(); orderFlow.setResource(GET:/api/order/detail); orderFlow.setGrade(RuleConstant.FLOW_GRADE_QPS); orderFlow.setCount(200); // 大模型回调接口并发线程数限流防止外部模型响应慢时拖垮线程池 FlowRule aiFlow new FlowRule(); aiFlow.setResource(POST:/api/ai/chat); aiFlow.setGrade(RuleConstant.FLOW_GRADE_THREAD); aiFlow.setCount(10); // 订单查询接口慢调用比例超过30%就熔断时间窗30秒 DegradeRule orderDegrade new DegradeRule(); orderDegrade.setResource(GET:/api/order/detail); orderDegrade.setGrade(RuleConstant.DEGRADE_GRADE_RT); orderDegrade.setCount(500); // 超过500ms算慢调用 orderDegrade.setSlowRatioThreshold(0.3); orderDegrade.setTimeWindow(30); orderDegrade.setMinRequestAmount(50); }这里设置并发线程数限流是因为大模型接口有个特点响应时间波动大。正常情况下2秒返回模型负载高时可能10秒以上。如果用QPS限流请求虽然放进来了但每个请求都占用一个线程在等结果线程池很快就满了导致服务完全不可用。换用并发线程数限流直接限制同时有几个请求在处理反而是更合适的方式。5.3 大模型侧的Prompt实现与“降级”策略大模型生成接口的核心是根据用户问题动态构造Prompt。演示项目里我建了一个Prompt模板类用面向对象的方式管理不同的模板类型public class PromptTemplate { public static String orderQuery(String userQuestion, ListString orderInfo) { StringBuilder sb new StringBuilder(); sb.append(你是一名订单查询助手请从给定的订单信息中提取用户问题的答案。\n); sb.append(规则\n); sb.append(1. 只能基于给定的订单信息回答。\n); sb.append(2. 如果订单信息不完整或不相关回复当前系统暂未找到该订单信息。\n); sb.append(3. 用简洁的中文回答不超过100字。\n); sb.append(\n用户问题).append(userQuestion).append(\n\n); sb.append(订单信息\n); for (String info : orderInfo) { sb.append(- ).append(info).append(\n); } return sb.toString(); } }这里最关键的设计是降级策略。大模型调用有失败概率网络抖动、模型服务过载、内容安全拦截任何一环出问题系统都要有兜底方案。我的做法是如果大模型返回异常就降级为纯规则匹配。用户在问“我的订单到哪了”系统直接从订单库查状态字段按照预设好的话术模板生成回答。这个降级后回答体验差一些但至少保证接口不挂。完全对应微服务里“服务降级”的思想核心链路保留非核心功能让路优先保障主流程可用。5.4 两者联动用限流思路优化Prompt模板的几个体会在这个演示项目里跑通之后我最大的感触是这几点第一Prompt模板要像代码规则一样管理。网关限流规则变了你要能追溯是谁改的、为什么改Prompt模板也一样改一句话可能影响整个业务的输出风格必须纳入版本管理。我自己是把每个版本的Prompt和对应的测试集结果一起提交这样回滚时知道会退回什么效果。第二上下文的选择要和限流的“漏桶”思维对齐。请求量大的时候网关宁可拒绝一部分请求也要保护核心链路上下文塞得太满的时候Prompt也要敢于舍弃信息只保留和当前问题最相关的内容。不要总想把所有资料都塞给模型你要做的是在有限上下文里安排信息优先级。第三叫服务要设置超时和重试大模型调用更要设置。当时的经验是服务调外部接口一般设置2秒超时、最多重试1次大模型接口设置为5秒超时、不重试。为什么大模型不重试因为生成类任务重试成本高而且模型接口返回慢通常意味着服务端已经过载重试只会雪上加霜。6. 常见问题与排查技巧实录6.1 网关限流侧规则不生效、误拦截、统计口径混乱先聊几个我实际踩过且后台问的人最多的网关限流问题。**规则不生效。**Sentinel规则不生效90%的情况是资源名写错了。你代码里用SentinelResource(orderDetail)控制台配置的却是GET:/api/order/detail两边资源名对不上的时候规则当然不会执行。排查时先打开Sentinel控制台看实时监控接口有没有流量把资源名打出来一目了然。**接口被误拦截。**限流阈值设置得太死容易误伤正常用户。我之前把某个接口的单用户阈值设为每秒2次结果前端页面初始化时要并发调3个接口算上请求时间差同一个IP在1秒内触发了4次请求直接触发限流。前端还不断重试反而放大了流量。后来把阈值调高并加了提示语告诉前端被拦截后要做退避处理。前后端对限流的配合也很重要不是后端加个限流就万事大吉。**统计口径不一致。**网关层和业务层限流分别用了不同维度的统计网关按用户维度Sentinel按QPS总数。当某个用户疯狂刷请求时网关层的用户维度限流先触发但Sentinel控制台看到的统计里总量不大看起来没有任何异常。这会误导排查方向。我的建议是统一在网关层做用户维度限流服务层做非敏感性的总量保护两层各管各的维度不混用。6.2 大模型Prompt侧输出反模式与上下文规划失败Prompt侧的问题不像代码报错那么明显但它比代码报错更难排查。我遇到过几类高频问题。**格式不稳定。**你要求模型输出JSON第一次它规规矩矩输出了换了一个问法它开始在前面加解释文字或者用Markdown代码块包住JSON。这个问题的根源在于输出约束不够强。我用过的两种有效解法一是把输出格式写成严格的示例放在Prompt末尾比如“严格按下面格式输出{order_id: , status: }”二是用参数控制的提示在一些模型API里可以设置response_format: {type: json_object}来强制JSON输出。**上下文截断后输出质量波动。**系统刚上线时用户的输入长度没控制好一个长文档直接塞进来把上下文窗口占满了系统提示词反而被挤出去了。模型丢失了“只根据资料回答”的指令开始自由发挥。排查时看调用日志里的token用量才发现prompt里的then被截断了。后来加了输入长度前置检查超过阈值就拒绝处理或者先做文本摘要。**模型“一本正经地胡说八道”。**这其实就是所谓的幻觉。我给出的限制方案是在Prompt里明确写“如果你是不知道答案的直接说不知道”同时用Few-shot示例告诉模型“不确定时要主动承认”。实践中这个方案能把幻觉率显著降低但不能完全消除。该加的防护还是得加——比如对关键事实做后置校验这就像系统不可靠时要有降级预案。6.3 结合项目的排查速查表与避坑笔记我最后整理了这样一张表放在项目README里团队处理问题时照着排查现象可能原因排查方式解决方案接口大量503网关限流触发查看网关日志的RateLimiter过滤器调整replenishRate和burstCapacity熔断器频繁打开依赖服务RT飙高查看Sentinel监控的慢调用比例给下游调用加缓存、缩短超时时间提示词生效但输出跑偏上下文窗口被用户输入挤占查看实际发送的prompt完整内容截断输入、压缩上下文、调整预算模型偶尔输出垃圾内容系统提示词与示例不匹配测试集回归统一措辞风格补充反例大模型调用超时导致主流程失败未设置合理的降级策略查看异常日志增加降级逻辑改异步处理压测时误触发限流阈值设置低于正常峰值对比压测报告和限流阈值重跑压测按极限值的一半设置这张表你不用照抄但建议在做类似项目时自己整理一份因为排查问题的思路会在整理的过程中清晰很多。最后再分享一个和这次主题相关的小技巧。在调试Prompt时我习惯把每一次调用的完整请求和响应都打到日志里内容包括版本号、Prompt模板ID、token用量、模型返回的原始内容和后处理的解析结果。大模型应用出问题最难的就是复现。日志一旦缺少关键信息排查一个线上问题可能要来回试几个小时。有了完整的调用链路日志你会发现Prompt工程和微服务治理在运维层面是同一套方法论可观测性是所有优化的前提。
用微服务限流熔断思路，一次讲透大模型Prompt工程
如果你做过几年后端开发大概率遇过这种场面线上接口突然被刷爆数据库CPU直接拉满监控图上红色告警一个接一个如果你最近又在折腾大模型应用大概率也遇过另一种场面同一个问题换几种问法模型给出的答案质量忽高忽低甚至一本正经地胡说八道。这两个问题初看毫无关系但我在同时做微服务网关治理和LLM应用开发时发现底层逻辑惊人一致——都是在做“输入端控制”。网关限流熔断控制的是请求的流量和稳定性Prompt工程控制的则是输入给模型的指令和上下文质量。理解了其中一个另一个基本就通了。这也是今天这篇文章的由来用微服务网关的限流熔断思路一次讲清大模型Prompt工程的核心原理。全文我会从真实项目视角出发把Sentinel限流降级、AOP注解限流、网关层的流量控制讲透再拿这些工程概念去对照Prompt设计中的上下文窗口、系统提示词、输出约束和降级策略。文章不算短但每一节都有实际可抄的配置、代码和思考路径适合正在做微服务架构、又想上手大模型应用的后端开发者。1. 为什么把网关限流熔断与Prompt工程放在一起讲1.1 两者共享同一个核心输入端决定输出端限流熔断的核心出发点是防止不可控的请求把系统打垮。一个接口如果每秒只能处理1000个请求你放进来2000个处理不了的请求就会堆积、超时甚至拖垮整个服务。所以网关要在入口处做一道闸门把流量控制在系统能承受的范围内。Prompt工程的核心出发点是让大模型在给定的上下文窗口内接收到最能被正确理解的信息。模型的能力上限就摆在那里你的提示词给得模糊它回得就模糊上下文塞得太乱关键信息被淹没模型就可能忽略你真正想要的内容。这两件事在抽象层面是同一个逻辑输出端的质量上限取决于输入端被控制的程度。网关控制的是请求量Prompt控制的是信息量。一个管“进不来太多”一个管“进来的都是对的”。我把这种对照进一步细化了直接列成一张表方便后续展开时反复引用对照维度微服务网关限流熔断大模型Prompt工程核心目标保护后端服务稳定性提升模型输出质量控制对象外部请求流量输入给模型的指令和上下文超限后果服务过载、雪崩上下文溢出、注意力分散常用手段限流、熔断、降级、隔离系统提示词、结构化指令、Few-shot示例、输出约束关键参数QPS阈值、熔断时间窗上下文窗口、温度参数、max_tokens策略配置规则下发到网关Prompt模板写入业务层1.2 后端工程师上手大模型最快的路径我见过不少后端同事学大模型一上来就啃Transformer论文看注意力机制公式研究损失函数怎么算结果看了一周还在前向传播里打转回头业务上连个像样的Prompt都写不好。我的建议是换个路径把你已经掌握的工程体系当作参照系。你已经懂了流量控制、服务保护、降级兜底那学Prompt工程的时候就带着这套框架去映射。看到“系统提示词”你就想这像不像网关里的全局规则看到“上下文窗口”你就想这像不像限流里的队列容量看到“温度参数”你就想这像不像调整限流阈值的旋钮。这种迁移式学习最大的好处是你不用从零建立认知模型而是在已有骨架上挂新知识。理解速度会快很多踩坑的时候也更容易找到原因。2. 微服务网关限流熔断的落地手段拆解2.1 Sentinel从规则配置到熔断降级先讲Sentinel这是阿里开源的流量防卫组件也是目前微服务架构里用得最多的限流熔断方案之一。它的核心模型分两块限流和熔断降级。限流这一块Sentinel提供了多种维度最常用的是QPS维度和并发线程数维度。QPS维度适合接口类场景比如某个查询接口每秒钟最多允许100个请求进来并发线程数维度适合处理时间不可控的场景比如业务里调了外部接口响应可能快也可能慢用并发线程数限制“同时处理几个请求”比单纯限制QPS更贴合实际。熔断这块Sentinel做的其实是三种状态之间的切换关闭、打开、半开。正常情况下熔断器是关闭状态请求正常通过当错误率或慢调用比例超过阈值熔断器打开后续请求直接拒绝经过一段时间后进入半开状态放少量请求试探如果试探成功熔断器关闭服务恢复如果试探失败继续熔断。看一个实际的规则配置片段我用的是Spring Boot Sentinel的集成方式Configuration public class SentinelConfig { PostConstruct public void initRules() { // 限流规则/api/order/create 接口QPS每秒最多20 FlowRule flowRule new FlowRule(); flowRule.setResource(/api/order/create); flowRule.setGrade(RuleConstant.FLOW_GRADE_QPS); flowRule.setCount(20); flowRule.setLimitApp(default); flowRule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); // 熔断规则接口异常比例超过50%熔断10秒 DegradeRule degradeRule new DegradeRule(); degradeRule.setResource(/api/order/create); degradeRule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO); degradeRule.setCount(0.5); degradeRule.setTimeWindow(10); degradeRule.setMinRequestAmount(100); FlowRuleManager.loadRules(Collections.singletonList(flowRule)); DegradeRuleManager.loadRules(Collections.singletonList(degradeRule)); } }这段配置里的几个参数要解释一下。setCount(20)是QPS阈值我当时的经验值是先看基线流量和压测数据比如单机这个接口的极限TPS是80那线上限流通常设置在极限值的四分之一到三分之一也就是20到30之间留足余量又防止单机被打穿。setCount(0.5)是异常比例阈值意思是100个请求里如果有50个抛出异常就触发熔断。实际项目中我一般设置在0.3到0.5之间太低会误伤偶发异常太高又起不到保护作用。setMinRequestAmount(100)这个参数很容易被忽略它的作用是防止流量太低时几个请求出错就触发熔断必须累积到100个请求再参与统计这个数字可以根据业务量往上调。2.2 网关层限流Spring Cloud Gateway RequestRateLimiter到了微服务架构里限流不应该只落在每个业务服务内部更应该在网关层做一层统一的流量控制。这样上游流量在入口就被拦住业务服务天然安全。我用的是Spring Cloud Gateway内置的RequestRateLimiter过滤器它基于令牌桶算法实现通过Redis配合完成分布式限流。令牌桶算法可以这样理解有一个桶里面以固定速率放入令牌每个请求进来必须取走一个令牌桶空了请求就被拒绝。相比计数器限流令牌桶的好处是可以应对突发流量比如桶容量是100令牌生成速率是每秒50个短时间内即使有100个请求同时进来只要桶里有足够令牌也能放进去不会立刻拒绝。Spring Cloud Gateway的配置长这样spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path/api/order/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 50 redis-rate-limiter.burstCapacity: 100 key-resolver: #{userKeyResolver}这里replenishRate代表每秒往桶里放多少令牌burstCapacity代表桶的最大容量。我实际项目里网关层和业务层的限流做了分层网关层限流是粗粒度防止入口被打爆阈值会设置得宽松一点业务层限流是细粒度针对不同接口的特点设置更精确的阈值。有一个特别容易踩的坑网关限流默认按IP维度做但用户如果经过Nginx转发所有请求的IP都是Nginx的限流就形同虚设。解决办法是自定义KeyResolver从请求头里取真实的用户标识Bean public KeyResolver userKeyResolver() { return exchange - { String userId exchange.getRequest().getHeaders().getFirst(X-User-Id); if (userId null) { userId exchange.getRequest().getRemoteAddress().getAddress().getHostAddress(); } return Mono.just(userId); }; }这个细节当时修复了一个线上大问题——如果不按用户维度区分一个用户疯狂请求就会把所有人的限额都占掉。2.3 AOP注解式限流接口级精准控制Sentinel和网关能覆盖绝大多数场景但对单个接口的灵活限流我更喜欢用AOP注解的方式做自定义。这种方式侵入性最小代码可读性最好适合那种“这个接口有点危险我要单独管一管”的场景。思路很简单定义一个注解RateLimit然后写一个切面拦截所有标注了该注解的方法。限流计数可以用Redis的原子操作完成也可以用本地内存做单机限流。我先展示一个基于Redis的实现Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RateLimit { String key() default ; long limit() default 100; long timeout() default 1; } Aspect Component public class RateLimitAspect { Autowired private StringRedisTemplate redisTemplate; Around(annotation(rateLimit)) public Object around(ProceedingJoinPoint joinPoint, RateLimit rateLimit) throws Throwable { String key rate_limit: rateLimit.key(); Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1L) { redisTemplate.expire(key, rateLimit.timeout(), TimeUnit.SECONDS); } if (count ! null count rateLimit.limit()) { throw new RuntimeException(请求过于频繁请稍后再试); } return joinPoint.proceed(); } }这个实现有几个可以优化的点。count 1时设置过期时间是为了避免每次请求都刷新过期时间导致限流窗口被无限拉长。但这种写法在高并发下会有一个问题如果同一瞬间有大量请求进来多个请求都会读到count为1都去设置过期时间虽然不影响限流本身的正确性但会产生多余的操作。更稳妥的方案是用两步操作写一个原子一点的逻辑或者在Redis里用Lua脚本。不过本地调试的时候我更喜欢用一个基于AtomicLong的简化版本省去Redis的依赖Component public class LocalRateLimiter { private final ConcurrentHashMapString, AtomicLong counters new ConcurrentHashMap(); public boolean tryAcquire(String key, long limit, long windowSeconds) { long currentWindow System.currentTimeMillis() / (windowSeconds * 1000); String counterKey key : currentWindow; AtomicLong counter counters.computeIfAbsent(counterKey, k - new AtomicLong(0)); long count counter.incrementAndGet(); if (count limit) { return false; } if (count 1) { // 清理旧窗口的计数器防止内存泄漏 clearExpired(key, currentWindow); } return true; } private void clearExpired(String key, long currentWindow) { counters.keySet().removeIf(k - k.startsWith(key :) !k.endsWith(: currentWindow)); } }这里用时间窗取整做计数器的Key窗口切分的思路和Sentinel的滑动窗口本质上是一样的只是粒度更粗糙。本地限流适合单机部署的场景多机部署还是得上Redis或者Sentinel集群。3. 从流量治理到Prompt工程控制策略的迁移3.1 服务质量与生成质量的量化标准把限流熔断的思维迁移到Prompt工程第一步是弄清楚一件事什么样的Prompt是“高可用”的网关限流有明确的指标——QPS、错误率、RTPrompt工程有没有对应的量化标准我自己实践下来Prompt工程的指标可以这么拆指标限流场景含义Prompt场景含义成功率请求被成功处理的比例模型输出符合预期格式和内容的比例垃圾输入无效请求、攻击请求无关上下文、矛盾指令、模糊表述超时请求处理时间超限模型输出过长、生成卡顿降级兜底服务挂了返回默认值模型输出异常时的备用方案容量规划系统能承受的最大QPS上下文窗口能容纳的最大信息量想通了这几个指标你就会发现调接口限流你得先知道系统瓶颈在哪调Prompt你得先知道模型在什么输入下会崩溃。两个过程都依赖“先测量再优化”而不是拍脑袋。3.2 阈值思维滑动窗口与上下文窗口的共同逻辑限流里最核心的算法之一是滑动窗口。它的思想是把一个大的时间区间切成多个小窗口统计当前时刻往前推移的窗口内的请求数量。每一秒都在变窗口也跟着滑这样既避免了固定窗口在临界点的突刺问题又比全量统计节省性能。大模型的上下文窗口也有类似的逻辑。以常见的32K上下文窗口为例模型一次能“看到”的信息量是有限的。超过这个量前面的信息就会丢失或者被压缩。你在写Prompt时本质上就是在做“滑动窗口管理”——只放入窗口内最高价值的信息把无关内容挡在外面给关键信息留出充足的“注意力空间”。我实际开发大模型应用时会把上下文窗口的预算做成一张表强制团队按这个预算写Prompt模板上下文窗口总预算32K tokens ├── 系统提示词System Prompt固定占2K长期保持稳定 ├── 用户输入平均占8K可动态变化 ├── 检索到的参考上下文占10K按相关性排序截取 ├── Few-shot示例占6K选择最能代表业务场景的3-5个示例 └── 输出预留占6K防止生成的答案被截断这个预算分配方案和网关限流设置QPS阈值是一个思路先摸清总量再按优先级分配最后留足缓冲。如果某个业务想把检索上下文加到15K就必须从Few-shot示例里缩。预算不够还硬塞结果就是模型注意力被稀释前后信息矛盾输出质量断崖式下降。4. Prompt工程核心实践一次讲清4.1 高可用Prompt的标准结构我写过很多Prompt模板也帮团队review过大量提示词最后总结出一个通用结构适用于绝大多数业务场景。这个结构分五层第一层是角色设定。给模型一个清晰的身份比如“你是一名客服助手”“你是一个数据分析师”。角色设定就像是网关里给某个路由打的标签决定了后续处理请求的默认行为。第二层是任务指令。明确告诉模型要做什么比如“根据用户问题从给定的资料中提取答案并简洁回复”。指令要具体、动作明确避免“帮我看看”“分析一下”这种模糊表达。第三层是上下文信息。这是模型回答的依据可以是业务数据、检索到的文档、用户历史记录等。这层对应限流里的“流量来源”来源的质量直接决定了结果的质量。第四层是示例数据。给模型几个输入输出对让它按照示例的格式和风格来回答。Few-shot是最有效的Prompt优化手段之一效果往往比语言描述强得多。第五层是输出约束。限定输出的格式、长度、语气比如“用Markdown列表输出”“不超过200字”“如果信息不足回答‘无法判断’”。这层对应的就是限流的“拒绝策略”超出能力范围就明确拒绝而不是硬答一气。4.2 从系统提示词到输出约束逐层往下拆听概念容易落到实际就难。我拿一个客服问答场景的Prompt模板来拆解这是我在一个演示项目里用过的结构比较典型系统提示词 你是一名电商平台的智能客服助手。你的任务是解答用户关于订单、退换货、物流、优惠券的疑问。 你必须遵守以下规则 1. 只能根据提供的资料回答不能编造信息。 2. 如果资料中没有答案直接回复“抱歉这个我暂时无法确认”。 3. 回答要简洁不超过150字。 4. 涉及金额、日期时必须和资料原文完全一致。 用户输入 订单20241218001到现在还没发货是什么情况 参考资料 [订单状态表] 订单号:20241218001 状态:已支付 预计发货时间:2024-12-20 物流异常:无 [物流配置表] 默认发货时效:48小时 特殊商品:预售商品发货时效为7天 模型输出 您好订单20241218001当前状态为已支付预计发货时间为2024年12月20日目前在正常发货时效内请耐心等待。这个模板里系统提示词设定了角色的行为边界规则里的“只能根据资料回答”和“没有答案就承认”就是降级策略避免模型胡编。参考资料给了模型回答所需的上下文但控制了范围没有把整个知识库塞进来。如果换成限流语言来理解系统提示词就是网关层的全局默认规则所有请求进来先受它约束用户输入是具体请求参数不同但都走同一条路由参考资料是上游数据源数据质量差后面的处理再精细也白搭。4.3 一步步打磨Prompt的高可用性很多新手把Prompt工程想得太玄或者反过来觉得太简单。我的经验是它和调限流参数一样是个逐步迭代的过程。第一步写一个“能跑”的初版。不用纠结优化先把角色、任务、上下文、约束四要素补齐保证模型能给出一个可用的输出。最低限度是固定格式让模型输出能被程序解析。第二步跑一批测试用例。准备20到50条覆盖正常、边界、异常场景的用户输入逐个跑一遍记录输出的质量和失败模式。这一步对应限流里的压测先摸清系统的真实表现。第三步定义你的“限流阈值”。统计哪些类型的输入会导致输出失败是上下文太长被截断还是模型回答超出了预期格式还是引用资料时张冠李戴把问题分成几类按频率排序。第四步针对Top3问题调整Prompt。比如模型总是不遵守输出格式就加“你必须严格按照以下JSON格式输出”比如模型回答过长就加硬性字数约束并在示例里展示一个短回答。我自己的经验是80%的输出质量问题集中在没给够示例和没交代清楚边界这两件事上。其余才是参数和模板结构的问题。5. 实际项目对照一个后端限流与LLM生成结合的演示5.1 演示项目背景与整体架构为了把上面的思路串起来我最近做了一个小的演示项目场景是“智能订单查询助手”用户在前端输入问题后端通过大模型生成答案同时整个查询链路要经过微服务网关保护。架构非常简单清晰前端请求 → Spring Cloud Gateway限流每用户每秒最多5个请求 → 订单查询服务SentinelQPS限流、异常率熔断 → 判断问题是否需要大模型辅助 ├── 不需要直接查订单库返回结构化数据 └── 需要调用大模型API使用预置Prompt模板 → 将AI回答返回前端网关限流管住入口流量服务层限流管住业务压力大模型调用这个环节单独做配额控制。三个层级各管一段对应到生产环境就是接入层防攻击服务层防过载外部依赖防超预算。5.2 微服务侧限流熔断的具体配置先看网关层的配置。因为这是个需要登录的系统限流维度选择了用户ID而不是IP。对应上面的KeyResolver配置中限流参数做了区分普通查询接口每用户每秒5个请求如果是大模型生成接口阈值更低每用户每秒2个请求因为大模型生成的成本远高于一次普通数据库查询。订单查询服务的Sentinel规则配置PostConstruct public void initOrderRules() { // 订单查询接口QPS限流撑不住就直接降级返回缓存数据 FlowRule orderFlow new FlowRule(); orderFlow.setResource(GET:/api/order/detail); orderFlow.setGrade(RuleConstant.FLOW_GRADE_QPS); orderFlow.setCount(200); // 大模型回调接口并发线程数限流防止外部模型响应慢时拖垮线程池 FlowRule aiFlow new FlowRule(); aiFlow.setResource(POST:/api/ai/chat); aiFlow.setGrade(RuleConstant.FLOW_GRADE_THREAD); aiFlow.setCount(10); // 订单查询接口慢调用比例超过30%就熔断时间窗30秒 DegradeRule orderDegrade new DegradeRule(); orderDegrade.setResource(GET:/api/order/detail); orderDegrade.setGrade(RuleConstant.DEGRADE_GRADE_RT); orderDegrade.setCount(500); // 超过500ms算慢调用 orderDegrade.setSlowRatioThreshold(0.3); orderDegrade.setTimeWindow(30); orderDegrade.setMinRequestAmount(50); }这里设置并发线程数限流是因为大模型接口有个特点响应时间波动大。正常情况下2秒返回模型负载高时可能10秒以上。如果用QPS限流请求虽然放进来了但每个请求都占用一个线程在等结果线程池很快就满了导致服务完全不可用。换用并发线程数限流直接限制同时有几个请求在处理反而是更合适的方式。5.3 大模型侧的Prompt实现与“降级”策略大模型生成接口的核心是根据用户问题动态构造Prompt。演示项目里我建了一个Prompt模板类用面向对象的方式管理不同的模板类型public class PromptTemplate { public static String orderQuery(String userQuestion, ListString orderInfo) { StringBuilder sb new StringBuilder(); sb.append(你是一名订单查询助手请从给定的订单信息中提取用户问题的答案。\n); sb.append(规则\n); sb.append(1. 只能基于给定的订单信息回答。\n); sb.append(2. 如果订单信息不完整或不相关回复当前系统暂未找到该订单信息。\n); sb.append(3. 用简洁的中文回答不超过100字。\n); sb.append(\n用户问题).append(userQuestion).append(\n\n); sb.append(订单信息\n); for (String info : orderInfo) { sb.append(- ).append(info).append(\n); } return sb.toString(); } }这里最关键的设计是降级策略。大模型调用有失败概率网络抖动、模型服务过载、内容安全拦截任何一环出问题系统都要有兜底方案。我的做法是如果大模型返回异常就降级为纯规则匹配。用户在问“我的订单到哪了”系统直接从订单库查状态字段按照预设好的话术模板生成回答。这个降级后回答体验差一些但至少保证接口不挂。完全对应微服务里“服务降级”的思想核心链路保留非核心功能让路优先保障主流程可用。5.4 两者联动用限流思路优化Prompt模板的几个体会在这个演示项目里跑通之后我最大的感触是这几点第一Prompt模板要像代码规则一样管理。网关限流规则变了你要能追溯是谁改的、为什么改Prompt模板也一样改一句话可能影响整个业务的输出风格必须纳入版本管理。我自己是把每个版本的Prompt和对应的测试集结果一起提交这样回滚时知道会退回什么效果。第二上下文的选择要和限流的“漏桶”思维对齐。请求量大的时候网关宁可拒绝一部分请求也要保护核心链路上下文塞得太满的时候Prompt也要敢于舍弃信息只保留和当前问题最相关的内容。不要总想把所有资料都塞给模型你要做的是在有限上下文里安排信息优先级。第三叫服务要设置超时和重试大模型调用更要设置。当时的经验是服务调外部接口一般设置2秒超时、最多重试1次大模型接口设置为5秒超时、不重试。为什么大模型不重试因为生成类任务重试成本高而且模型接口返回慢通常意味着服务端已经过载重试只会雪上加霜。6. 常见问题与排查技巧实录6.1 网关限流侧规则不生效、误拦截、统计口径混乱先聊几个我实际踩过且后台问的人最多的网关限流问题。**规则不生效。**Sentinel规则不生效90%的情况是资源名写错了。你代码里用SentinelResource(orderDetail)控制台配置的却是GET:/api/order/detail两边资源名对不上的时候规则当然不会执行。排查时先打开Sentinel控制台看实时监控接口有没有流量把资源名打出来一目了然。**接口被误拦截。**限流阈值设置得太死容易误伤正常用户。我之前把某个接口的单用户阈值设为每秒2次结果前端页面初始化时要并发调3个接口算上请求时间差同一个IP在1秒内触发了4次请求直接触发限流。前端还不断重试反而放大了流量。后来把阈值调高并加了提示语告诉前端被拦截后要做退避处理。前后端对限流的配合也很重要不是后端加个限流就万事大吉。**统计口径不一致。**网关层和业务层限流分别用了不同维度的统计网关按用户维度Sentinel按QPS总数。当某个用户疯狂刷请求时网关层的用户维度限流先触发但Sentinel控制台看到的统计里总量不大看起来没有任何异常。这会误导排查方向。我的建议是统一在网关层做用户维度限流服务层做非敏感性的总量保护两层各管各的维度不混用。6.2 大模型Prompt侧输出反模式与上下文规划失败Prompt侧的问题不像代码报错那么明显但它比代码报错更难排查。我遇到过几类高频问题。**格式不稳定。**你要求模型输出JSON第一次它规规矩矩输出了换了一个问法它开始在前面加解释文字或者用Markdown代码块包住JSON。这个问题的根源在于输出约束不够强。我用过的两种有效解法一是把输出格式写成严格的示例放在Prompt末尾比如“严格按下面格式输出{order_id: , status: }”二是用参数控制的提示在一些模型API里可以设置response_format: {type: json_object}来强制JSON输出。**上下文截断后输出质量波动。**系统刚上线时用户的输入长度没控制好一个长文档直接塞进来把上下文窗口占满了系统提示词反而被挤出去了。模型丢失了“只根据资料回答”的指令开始自由发挥。排查时看调用日志里的token用量才发现prompt里的then被截断了。后来加了输入长度前置检查超过阈值就拒绝处理或者先做文本摘要。**模型“一本正经地胡说八道”。**这其实就是所谓的幻觉。我给出的限制方案是在Prompt里明确写“如果你是不知道答案的直接说不知道”同时用Few-shot示例告诉模型“不确定时要主动承认”。实践中这个方案能把幻觉率显著降低但不能完全消除。该加的防护还是得加——比如对关键事实做后置校验这就像系统不可靠时要有降级预案。6.3 结合项目的排查速查表与避坑笔记我最后整理了这样一张表放在项目README里团队处理问题时照着排查现象可能原因排查方式解决方案接口大量503网关限流触发查看网关日志的RateLimiter过滤器调整replenishRate和burstCapacity熔断器频繁打开依赖服务RT飙高查看Sentinel监控的慢调用比例给下游调用加缓存、缩短超时时间提示词生效但输出跑偏上下文窗口被用户输入挤占查看实际发送的prompt完整内容截断输入、压缩上下文、调整预算模型偶尔输出垃圾内容系统提示词与示例不匹配测试集回归统一措辞风格补充反例大模型调用超时导致主流程失败未设置合理的降级策略查看异常日志增加降级逻辑改异步处理压测时误触发限流阈值设置低于正常峰值对比压测报告和限流阈值重跑压测按极限值的一半设置这张表你不用照抄但建议在做类似项目时自己整理一份因为排查问题的思路会在整理的过程中清晰很多。最后再分享一个和这次主题相关的小技巧。在调试Prompt时我习惯把每一次调用的完整请求和响应都打到日志里内容包括版本号、Prompt模板ID、token用量、模型返回的原始内容和后处理的解析结果。大模型应用出问题最难的就是复现。日志一旦缺少关键信息排查一个线上问题可能要来回试几个小时。有了完整的调用链路日志你会发现Prompt工程和微服务治理在运维层面是同一套方法论可观测性是所有优化的前提。
