稳定支柱

理由

任何单一模型服务都可能出现不可用或性能退化的情况。通过配置主模型-备用模型-缓存三级兜底策略，确保在主服务出现问题时业务不中断。

实施指引

设计三级兜底链路：主模型→备用模型→缓存/规则系统。主模型处于正常状态时承担100%流量。当主模型出现异常（响应超时、错误率超过阈值、质量评分下降），流量自动切换至备用模型。备用模型通常选择成本更低但能力足以支撑基本业务的模型（如将主模型从大参数模型降级为中等参数模型）。当备用模型也不可用时，降级至缓存系统（返回预计算的常见问题答案）或规则系统（基于模板生成标准化回复）。

引入熔断器模式（Circuit Breaker）管理模型切换。熔断器维护三个状态：闭合（正常使用主模型）、断开（切换至备用模型）、半开（尝试恢复主模型）。触发断开的条件包括：连续N次请求失败、滑动窗口内错误率超过阈值、平均延迟超过SLA上限。断开持续一定时间后进入半开状态，放行少量请求试探主模型是否恢复。

主备模型之间的输出格式须保持兼容。若主模型使用gpt-4级别的模型而备用模型是gpt-3.5级别，两者的输出Schema应保持一致，业务代码无需因模型切换而调整解析逻辑。

反模式：单一模型服务无兜底配置，模型服务一旦异常则业务完全中断。或配置了兜底但未进行兼容性测试，切换后输出格式不兼容导致下游解析错误。

阿里云实现：AI网关支持配置多个模型端点，结合自定义的路由逻辑实现主备切换。PAI-EAS可部署多个模型服务实例，通过ALB的健康检查机制自动剔除不健康的后端实例。

理由

API配额和限流是云端AI服务的固有约束。不合理的流量模式可能导致关键请求在配额耗尽时被拒绝，而非关键请求却消耗了宝贵的配额。需要在客户端侧建立配额管理和流量监控机制，实现对上游限流的优雅应对。

实施指引

令牌桶（Token Bucket）算法实施客户端侧限流。基于已知的API配额（如每分钟100K Token），在客户端维护一个令牌桶，每个请求按预估消耗的Token数获取令牌。桶为空时请求进入等待队列而非直接失败。这样将API的硬限流（直接拒绝）转化为客户端的软限流（排队等待），提供更平滑的用户体验。

反压（Backpressure）机制：当请求队列积压超过阈值时，向上游（用户端或调用方）反馈系统繁忙信号，由调用方自行决定是等待、重试还是降级处理。反压信号应包含预估等待时间，帮助调用方做出合理决策。

请求优先级：为不同类型的请求设定优先级。关键业务请求（如实时客服对话）优先获取配额，非实时请求（如批量数据处理、报告生成）在低峰时段执行。优先级队列确保配额紧张时关键请求不被非关键请求挤占。

配额预热：在可预见的流量高峰前（如电商大促、营销活动），提前与云服务商协调提升配额，或预部署额外的推理实例。结合历史流量模式进行预测，在高峰到来前完成资源准备。

反模式：不感知上游配额限制，以不可控的速率发送请求，导致大量请求被限流拒绝后重试，进一步加剧拥塞（重试风暴）。

阿里云实践：阿里云上的AI网关支持API 限流策略，此策略专为大模型服务及高并发调用场景设计，支持基于 Token 消耗量、请求数和并发数的多维度动态控制机制。该策略可针对消费者身份、请求 Header 参数、Query 参数、Cookie、客户端 IP、模型名称等多维度配置限流规则，并提供 API 级别的全局限流能力。这种多维度限流模式能精准匹配大模型计算资源消耗特性，有效防止系统过载、接口滥用及恶意调用，同时保障核心业务在复杂场景下的稳定运行。

理由

单可用区部署面临机房级别故障的风险。虽然机房级故障概率较低，但一旦发生影响范围大、恢复时间长。AI推理服务的跨AZ部署可保障在单AZ故障时业务持续运行。

实施指引

推理服务至少部署在同一Region的两个可用区中。每个可用区独立部署完整的推理服务实例（包括模型加载和GPU资源），而非仅做主备配置。正常状态下两个AZ均承担流量，单AZ故障时另一AZ承接全部流量。

部署负载均衡器进行健康检查和流量路由。健康检查不仅验证进程存活（TCP/HTTP探针），还应包含模型可用性验证——即定期发送轻量级推理请求验证模型是否正常加载并可响应。仅进程存活但模型加载失败（如GPU驱动异常）时，传统的TCP健康检查无法发现问题。

跨AZ容量规划须留有冗余：每个AZ的容量应能独立支撑全部流量（N+1模式），而非假设所有AZ始终可用。否则单AZ故障时剩余AZ过载，形成连锁故障。

反模式：所有推理实例部署在同一可用区，或虽然跨AZ部署但单AZ容量不足以承载全部流量。

阿里云实践：PAI-EAS支持跨AZ部署推理服务，建议选择至少2个可用区来部署。百炼支持私网连接（privatelink），支持多可用区的网络接入，确保跨AZ的容灾能力。结合ALB（应用负载均衡）进行流量分发和健康检查路由。ALB支持自定义健康检查路径，可配置为模型服务的推理探针端点。

理由

当AI的输出需要被下游系统程序化消费时（如JSON格式的API响应、结构化的决策结果），输出格式的可靠性直接影响系统稳定性。大模型可能输出格式不完整、字段缺失、类型错误的结构化内容，导致下游解析失败。

实施指引

使用JSON Schema定义期望的输出格式，包括必填字段、字段类型、枚举值范围、嵌套结构等约束。在模型调用时通过Function Calling或Response Format参数指定输出Schema，约束模型生成符合Schema的结构化输出。

在模型输出后、发送给下游前，执行Schema校验。校验不通过的输出进入重试流程——将校验错误信息反馈给模型，附加更明确的格式要求后重新生成。重试次数设上限（通常2-3次），超过后走降级逻辑（返回默认值或告知用户当前无法处理）。

流式输出（Streaming）场景的额外处理：流式生成可能在中间被中断（如Token超限、网络异常），导致输出的JSON不完整。对流式输出须在接收完成后进行完整性校验，不完整的输出视为失败进入重试。

对于关键业务场景，可考虑使用Constrained Decoding（约束解码）技术，在生成层面就保证输出严格符合语法要求（如JSON语法、特定的枚举值），从根本上消除格式错误的可能。

反模式：不对模型输出做格式校验，直接以字符串拼接或正则提取的方式解析输出。模型输出格式的轻微变化（如多了一个空格、字段顺序不同）即导致解析崩溃。

阿里云实现：百炼的Function Calling支持通过Schema定义返回格式。DashScope API支持response_format参数指定JSON模式输出。应用代码中结合JSON Schema校验库实现校验-重试逻辑。

理由

对于输出结果将直接影响重大决策的场景（如风控评分、合规判定、医疗辅助建议），单次模型推理的结果不够可靠。通过多次推理并比对结果的一致性，可以识别模型不确定性高的情况，避免基于单次不稳定输出做出关键决策。

实施指引

多次推理投票（Self-Consistency）：对同一输入执行N次推理（N通常取3-5），比较N次结果是否一致。若多数结果一致，以多数结果为准；若结果分散无多数一致，标记为"模型不确定"，流转至人工决策或要求用户提供更多信息。

跨模型验证：使用两个不同的模型对同一输入进行推理，比较结果是否一致。不同模型具有不同的训练数据和偏见模式，两者一致的结果可信度更高。不一致时触发人工审核或第三个模型仲裁。

一致性评分：将一致性量化为评分指标（如5次推理中4次一致则评分为0.8），设定不同业务场景的一致性阈值。低于阈值的结果不自动执行，而是附加不确定性声明或升级处理。

成本控制：多次推理会成倍增加推理成本。应仅对关键决策场景启用自洽性校验，对于信息查询、闲聊等低风险场景使用单次推理即可。通过业务分级控制校验策略。

反模式：对所有请求无差别地启用多次推理校验（成本不可控），或对关键决策场景仅使用单次推理就直接执行（风险不可控）。

阿里云实现：AI网关支持配置多个模型端点，结合SLS记录每次推理的原始结果，用于事后的一致性分析和模型质量评估。

理由

模型对提示词的措辞敏感——相同语义的不同表述可能导致不同质量的输出。当一次推理失败（输出质量不达标或格式错误）时，通过调整提示词的表述方式重试，可能获得更好的结果。这是一种利用模型对提示词敏感性的"正面利用"。

实施指引

何时触发变体重试：仅在输出校验不通过（格式错误、内容不完整、安全检查未通过）时触发，而非对所有请求预防性地执行。首次尝试使用主提示词，失败后使用预定义的变体提示词重试。

变体策略设计：预定义2-3个语义等价但表述不同的提示词变体。变体之间的差异可包括：指令措辞（"请生成"→"请输出"）、格式强调方式（增加格式示例、使用XML标签包裹期望格式）、思维链引导（增加"让我们一步步思考"的引导）、约束条件的表述顺序调整等。变体设计基于经验——某些表述方式在特定模型上表现更好。

成本预算：每个请求设定最大重试次数和最大Token消耗预算。重试时累计Token消耗接近预算上限时停止重试，走降级逻辑。避免无限重试导致成本失控。

重试间隔：变体重试之间无需等待（与网络重试不同），因为变体重试的目的不是等待服务恢复而是尝试不同的表述方式。但若重试是因为上游限流导致的失败，则需遵循退避策略。

反模式：使用完全相同的提示词无限重试（相同输入大概率得到相同的失败结果），或变体提示词之间语义差异过大导致功能偏移。

阿里云实现：在百炼应用中配置多个提示词模板，应用代码中实现校验-变体切换-重试的编排逻辑。通过ARMS监控重试率和最终成功率，高重试率触发提示词优化告警。

理由

知识库是RAG系统准确性的根基。知识库内容过时是一个渐进过程——系统不会突然崩溃，而是回答越来越不准确。若缺乏主动的新鲜度监控，可能在大量用户收到错误回答后才发现问题。

实施指引

为每个知识库定义新鲜度SLA——即内容的最大允许过时时间。SLA根据内容类型差异化设定：价格信息SLA为24小时（次日必须更新）、政策法规SLA为48小时（新规发布后两个工作日内入库）、产品文档SLA为7天。

建立知识库内容更新监控：记录每篇文档的最后更新时间和来源文档的变更时间。通过定时任务扫描知识库中每篇文档是否超过其SLA时限，超期文档触发告警通知负责人更新。

来源文档变更检测：对知识库内容对应的源头（如官网页面、内部Wiki、政策发布网站）进行定期爬取或Webhook监听，检测源头内容是否发生变更。变更后自动触发知识库更新流程（或至少触发人工review流程）。

过时内容标记：对于已超过SLA但尚未更新的文档，在检索结果中附加"信息可能过时"的标记，在模型生成时附加不确定性声明。避免系统以高置信度呈现可能过时的信息。

反模式：知识库一次性灌入后不再更新维护，或依赖人工记忆来判断哪些内容需要更新。

阿里云实现：DataWorks的数据质量监控能力可用于知识库内容的新鲜度监控。百炼知识库支持API驱动的文档更新，可与CI/CD流水线集成实现自动化更新。SLS记录知识库变更事件，ARMS配置新鲜度告警规则。

理由

向量库是RAG系统的检索引擎，其不可用将直接导致AI系统无法基于知识回答问题，只能依赖模型自身知识（可能不准确或过时）。向量库的高可用设计需兼顾数据一致性和服务连续性。

实施指引

多副本架构：向量库数据至少保持两个副本，分布在不同的可用区。读请求可分发到任意副本，实现读扩展和AZ级容灾。写操作同步或异步复制到所有副本（根据一致性要求选择）。

跨AZ部署：向量库节点分布在同一Region的多个可用区中。单AZ故障时，其他AZ的副本可继续提供服务。结合负载均衡器的健康检查实现自动故障切换。

数据备份与恢复：定期对向量库进行全量快照备份，支持快速恢复。快照频率根据数据变更频率确定——频繁更新的知识库每小时快照，稳定的知识库每天快照。验证快照恢复流程的可行性和耗时。

索引重建能力：保留向量库的原始数据源（未向量化的文本数据），确保在向量库出现不可恢复的损坏时，能从原始数据完整重建索引。重建流程应自动化且有明确的时间预期。

反模式：向量库单实例单AZ部署，无副本无备份。或有备份但从未验证过恢复流程的可行性。

阿里云实现：阿里云向量检索服务支持多副本和跨AZ部署。结合SLS监控向量库的查询延迟和可用性指标。数据备份可利用OSS作为存储目标，定期执行快照任务。

理由

RAG系统中检索环节可能出现多种失败：向量库超时、检索结果为空（知识库中无相关内容）、检索结果质量过低（相似度分数都低于阈值）。对这些情况需要设计明确的降级策略，而非让模型在无有效检索结果的情况下"自行发挥"。

实施指引

向量库不可用时的降级：当向量库超时或返回错误时，根据请求类型选择降级策略。对于简单的常见问题，切换至预计算的FAQ缓存直接返回；对于复杂问题，诚实告知用户"知识库暂时不可用，回答可能不完整"并基于模型自身知识生成回复同时降低置信度声明。

检索结果为空的处理：明确告知用户"当前知识库中没有找到相关信息"，而非让模型编造一个答案。可选地提供相关建议（如"您可以尝试以下关键词重新提问"或"该问题可能需要联系人工客服"）。

检索结果质量低的处理：当所有检索结果的相似度分数都低于预设阈值时，判定检索结果不可靠。此时生成回复应明确声明"以下信息仅供参考，未找到高度匹配的知识"，并标记该次回复的不确定性等级。

降级状态可观测：所有降级事件须被记录和监控。降级率突然升高可能意味着知识库出现问题（如索引损坏、数据过期）或向量库服务异常，需要及时介入排查。

反模式：检索失败时静默忽略，让模型在没有检索上下文的情况下直接生成回复——用户无法区分这个回复是有知识支撑的还是模型"胡说"的。

阿里云实现：百炼知识库配置中可设置检索结果的相似度阈值。应用代码中实现降级逻辑判断。SLS记录检索结果的质量指标（相似度分数、返回条数），ARMS配置降级率告警。

理由

智能体执行的复杂任务可能涉及多个步骤，耗时数分钟甚至数小时。中间任何环节的失败不应导致整个任务从头重来——尤其是已成功完成的步骤涉及外部副作用（如已发送的邮件无法撤回、已提交的数据无法回滚）。断点续跑能力确保任务可以从最后一个成功检查点继续执行。

实施指引

任务状态持久化：将任务的执行状态定期保存到持久化存储（如数据库或对象存储）。状态包括：已完成的步骤列表、每步的输出结果、当前执行到的步骤、下一步的输入参数。持久化频率为每完成一个步骤后立即保存。

检查点设计：在任务的步骤之间设置检查点。每个检查点记录到该点为止的完整执行状态和中间结果。失败后恢复时，从最近的检查点加载状态继续执行，跳过已成功完成的步骤。

幂等性保障：恢复执行时可能会重新执行上次失败的那一步——因此每个步骤须设计为幂等的（重复执行不产生额外副作用）。对于天然非幂等的操作（如发送邮件），在执行前检查"执行记录"判断是否已成功执行过，避免重复执行。

手动恢复入口：提供界面或API允许运维人员手动触发任务恢复，可选择从特定检查点恢复或跳过失败步骤继续后续步骤。对于无法自动恢复的场景（如需要人工介入修正中间结果），支持人工注入修正数据后继续执行。

反模式：长链路任务无状态持久化，失败后只能从头重来。或虽有检查点但恢复逻辑存在bug，导致恢复后重复执行已完成的步骤产生数据重复。

阿里云实现：利用函数计算（FC）或云工作流实现任务编排和状态持久化。百炼工作流支持步骤级别的执行状态记录。SLS记录任务执行轨迹，用于故障定位和恢复验证。

理由

智能体依赖的外部工具（API、数据库、第三方服务）可能出现不可用或响应缓慢的情况。若不加以控制，智能体可能反复重试失败的工具调用，不仅浪费资源还延长了用户的等待时间。熔断器模式可及时切断对故障工具的调用，避免资源浪费并加速故障恢复。

实施指引

为每个外部工具配置独立的熔断器实例。熔断器记录工具调用的成功/失败/超时状态，基于滑动窗口统计故障率。

熔断触发条件：在滑动窗口（如过去30秒）内，工具调用失败率超过阈值（如50%）或平均延迟超过SLA（如超时时间的2倍），触发熔断器断开。

熔断期行为：熔断器断开后，后续对该工具的调用不再实际执行，而是立即返回预定义的降级结果。降级结果应是信息性的——告知模型"该工具当前不可用"而非返回伪造的正常结果。模型收到工具不可用的信息后，应能调整策略（跳过该步骤、使用替代方案、或告知用户无法完成）。

恢复策略：熔断一段时间后（如30秒）进入半开状态，放行少量请求试探工具是否恢复。若试探请求成功，恢复正常调用；若仍失败，继续保持熔断。

工具依赖度分类：区分"必需工具"和"可选工具"。必需工具熔断时整个任务进入等待或降级状态；可选工具熔断时跳过该步骤继续执行后续步骤。

反模式：工具调用无超时设置、无重试上限、无熔断机制，单个工具的故障拖垮整个智能体的响应。或熔断粒度过粗——一个工具的某个端点故障导致对该工具所有端点的调用都被熔断。

阿里云实现：ARMS提供服务调用的健康度监控。应用代码中使用Sentinel等熔断组件实现工具级别的熔断策略。SLS记录每次工具调用的结果和耗时，ARMS配置基于故障率的告警规则。

理由

智能体的"服务质量"不能仅用传统的可用性指标（如99.9% uptime）来衡量。一个智能体可能持续在线（可用性100%），但任务完成率只有60%、平均完成时间远超用户预期。需要定义AI系统特有的SLO（服务级别目标），全面衡量智能体的服务质量。

实施指引

定义核心SLI（服务级别指标），至少包括：

任务完成率：智能体接受的任务中成功完成的比例。需明确"完成"的定义——是模型返回了结果即算完成，还是结果通过了质量校验才算完成。建议采用后者。

端到端时延：从用户发起请求到收到最终结果的总时间。对于多步骤任务，记录总时延而非单步时延。分P50/P90/P99分位值设定目标。

首次输出时延（Time to First Token）：流式场景中用户感知到"开始响应"的等待时间。影响用户体验感受。

输出质量评分：通过自动化评估（如LLM-as-Judge）或用户反馈（点赞/踩）量化输出质量。可分维度评估（准确性、完整性、相关性）。

基于SLI设定SLO目标。例如：任务完成率>=95%、P90端到端时延<=30秒、输出质量评分>=4.0/5.0。SLO目标根据业务场景差异化——客服助手场景对时延要求更高，数据分析场景对准确性要求更高。

建立Error Budget（错误预算）机制：当SLO余量充足时允许做激进的变更（如更新模型、优化提示词）；当SLO接近阈值时冻结变更，集中精力改善稳定性。

反模式：不定义AI特有的SLO，仅依赖传统基础设施指标（CPU利用率、内存使用率、进程存活状态）来评判AI系统健康度。系统"在线但无用"的状态无法被发现。

阿里云实现：ARMS支持自定义业务指标的SLI定义和SLO看板。SLS用于采集和计算任务完成率、时延分位值等指标。结合钉钉告警，SLO恶化时实时通知值班人员。ARMS的Prometheus接口可将AI SLI纳入统一的可观测体系。