智能体面试准备三十九智能体可靠性工程——把不确定的 Agent 做成可信的系统本篇是 B 系列前沿延伸第九篇。此前我们讲了生产化改造B30、可观测B20、安全对抗B32、编排B34。本篇聚焦一个把它们串起来的主题——可靠性工程Reliability Engineering当 Agent 是非确定性、长链路、多工具、依赖外部世界的系统怎么让它像传统分布式服务一样稳、可控、可降级、可复盘。这是 Agent 从 Demo 走到生产最硬的一关。一、为什么 Agent 比传统服务更难可靠传统微服务是确定性的给定输入、走固定分支、返回固定结果。Agent 不是。维度传统服务智能体路径确定代码分支不确定LLM 动态决策依赖已知依赖未知外部工具/API失败可枚举长尾、难复现输出结构稳定可能格式漂移、幻觉这意味着靠写好代码无法保证可靠必须靠系统层的容错、护栏、可观测与回归来兜住。面试里能讲清Agent 可靠性不是测试问题而是工程纪律问题已经胜过多数候选人。二、容错与重试幂等是第一原则Agent 调用外部工具出错时重试是本能但必须保证幂等同一工具调用重复执行不能产生副作用翻倍如重复下单、重复发消息。tool(idempotency_keyorder-{req_id}) # 同一 key 重复调用只生效一次 def create_order(req): if cache.exists(key): return cache.get(key) result do_create(req) cache.set(key, result, ttl3600) return result重试策略用指数退避 抖动避免对故障服务造成重试风暴对暂时性故障超时、限流重试对永久故障权限、参数错误快速失败。最终兜底进死信队列DLQ由人工或定时任务处理而不是无限重试烧预算。三、熔断与降级不让一个工具拖垮全局当某外部工具持续失败继续调用只会堆积超时和成本需要熔断器Circuit Breaker闭合(正常) ──失败率超阈值──▶ 打开(暂停调用, 快速失败) ▲ │ │ 冷却期过, 试探调用成功 │ └──────────────────────────┘配合降级路径工具不可用时Agent 不硬撑而是降级到更弱但稳的能力——例如检索工具挂了就改走缓存摘要、或显式告知用户该能力暂不可用、或直接优雅转人工。降级的本质是预设能力边界内的次优解而不是让用户在无限重试里干等。四、超时与步数护栏Agent 最容易烧预算的两个失控点是卡死循环和慢工具。必须有两道硬护栏步数上限max_steps超过 N 步未完成就强制终止并交人工避免 Agent 陷入调用-失败-重试死循环呼应 B22 长时任务。单工具超时每个工具调用都有独立超时超时即按失败处理并触发降级而非阻塞整条链路。总预算/总成本护栏按请求设 token 与金额上限逼近上限就降频或终止。护栏要写在编排层而非依赖 LLM 自觉——LLM 不会自己停必须系统强制。五、混沌测试与故障注入Agent 上线前要主动制造故障来验证容错是否真生效这就是混沌工程Chaos Engineering注入故障 预期行为 工具超时 → 触发降级/重试, 不阻塞 工具返回脏数据 → 校验拦截, 不污染下游 模型幻觉指令 → 护栏拒绝, 转人工 依赖服务宕机 → 熔断器打开, 快速失败 LLM 慢响应 → 步数/超时护栏介入不经过故障注入就宣称可靠等于没测。生产团队会把这些故障场景固化成常态化回归用例每次发布前自动跑。六、回归门禁与评测守门新版本 Agent 不能直接全量。要在发布前用回归集确认不比旧版差非劣性检验这就是发布门禁代码合并 ─▶ 单元/工具契约测试 ─▶ 回归集评测(非劣性) ─▶ 影子流量 ─▶ 1%/5%/50%/100% 灰度 ─▶ 全量 │ 不达标则拦截回归集要覆盖已知正确路径、已知失败边界、真实日志采样。门禁规则通常用关键指标掉点不超过 X% 才放行。这一步把凭感觉发版变成靠数据放行。七、错误预算与 SLO借鉴 SRE 的错误预算Error Budget先定义 Agent 的 SLO如成功解决率 ≥ 90%、严重失败率 ≤ 1%再用预算消耗速率决定是否敢发版。错误预算 1 - SLO 达成缺口 消耗过快 → 冻结新功能发布, 先修稳定性 预算充足 → 允许灰度新能力这给要不要冒险上新的自主能力一个客观判据而不是凭老板心情。八、可观测与事故复盘可靠性工程的最后一公里是看清发生了什么全链路 Trace谁委派了谁、调了什么工具、花了多久多少钱、结构化决策日志、用户反馈埋点。出事故后做无责复盘blameless postmortem定位根因、归档到错误样本库、反喂进评测集与护栏形成失败→归因→改进的飞轮。深度延展可靠性工程的 SRE 落地与真实事故把可靠性工程落到生产最成熟的参照系其实是传统 SRE站点可靠性工程那套方法论只是到了 Agent 这里要处理非确定性这个新变量。先讲 SLO 与错误预算的实操。定义 SLO 不能拍脑袋要选用户真在乎的指标对客服 Agent 是首解率和错误率对代码 Agent 是任务完成率和引入缺陷率对数据分析 Agent 是结果准确率和超时率。指标选定后错误预算就是允许失败的额度比如 SLO 要求成功解决率不低于百分之九十二那么百分之八的缺口就是预算。预算消耗速率决定发布节奏预算充足时允许灰度新能力消耗过快则冻结功能发布、先修稳定性。这套机制把要不要冒险上新功能从一个主观争论变成客观数字是工程成熟度的分水岭。再说可观测为什么是可靠性的眼睛。Agent 的失败长尾难以复现没有全链路 Trace 就等于盲人摸象。生产级可观测要覆盖四件事第一每一次交互的 Trace 要记录 Agent 走了哪些步骤、调了哪些工具、每步耗时和花费出问题时能顺着 Trace 定位是哪一步、哪个工具、哪个依赖把整条链路带偏第二结构化决策日志要记录 Agent 每一步的思考摘要和工具入参出参方便事后审计它为什么这么干第三成本与延迟埋点要进看板异常波动比如某类请求突然变贵第一时间告警第四用户反馈要闭环把用户转人工和用户差评反喂进评测集让评测跟着真实分布走。这四件事齐全可靠性才有眼睛。讲一个真实事故形态帮助理解这是多团队都踩过的典型。某团队上线数据分析 Agent平时稳某天一个外部数据接口开始间歇性返回脏数据Agent 没有做数据校验把脏数据当作真实结果继续推理产出一堆错误报表且因为没触发显式报错问题潜伏了一整天才被用户发现。根因有三一是缺少工具返回的数据校验层二是没有结果可信度的兜底判断三是可观测里没有对异常数据特征做监控。修复方案是三管齐下在工具层加返回结构校验与值域校验、在 Agent 层加数据异常则转人工的护栏、在监控层加脏数据特征告警并用混沌测试把工具返回脏数据固化成常态回归用例。能讲出这种从事故到根因到修复的闭环比背定义值钱得多。还要补多智能体场景下的可靠性难点呼应 B37。单 Agent 的熔断器、错误预算好算多智能体网络里一次用户请求可能横跨三到五个智能体、经过两次委派任何一个环节的失败都可能是别的智能体引起的归因因此变难。工程上要强制每次委派都带全局追踪标识让跨智能体的调用链可追溯错误预算要按端到端任务而非单智能体调用核算否则某个子智能体的高成功率会掩盖整体任务的失败熔断要支持级联一个智能体被熔断后上游编排能自动把任务降级到替代智能体或转人工而不是卡死。这把可靠性从单点工程升级成了网络工程。最后落到工程文化与门禁。可靠性不是一个人的事而是一种团队纪律。发布门禁回归集非劣性、影子流量、分级灰度要写进流程任何人不能绕过混沌测试用例要随新故障持续扩充不能上线即弃无责复盘要常态化出事故先定位系统弱点而非追责个人否则没人敢上报隐患。这套纪律把Agent 能不能稳住从依赖某个高手变成依赖一套机制这正是 B30 生产化、B35 成熟度模型想传达的内核能上线只是开始能持续稳、可控、可查、可回才是本事。再强调一次面试问可靠性考的不是你知不知道熔断这个词而是你有没有真在生产里扛过 Agent 半夜告警、定位过跨工具失败、建过回归门禁——把这份真实体感讲出来远比名词堆叠有说服力。再补一个工程现实可靠性工程最难的不是技术而是组织有没有把它当回事。很多团队把可靠性当成上线后的救火平时不建门禁、不跑混沌、不写复盘等到半夜告警才手忙脚乱结果同类事故反复发生。成熟的团队会把可靠性写进研发节奏每次提交自动跑工具契约测试和单元测试每日跑回归集评测每周做一次混沌演练每月做一次无责复盘并把新故障固化进用例。这套节奏让可靠从靠运气变成靠机制。面试里被问你们怎么保证 Agent 不崩想听的就是这套机制而不是某个人很厉害。还要讲一个容易被低估的护栏输入与输出的校验层。Agent 调用外部工具拿回来的数据可能不是预期结构、可能越界、可能带注入呼应 B32 安全对抗如果 Agent 直接信任并继续推理错误会被放大。正确做法是在工具层加返回结构校验与值域校验在 Agent 层加数据异常则降级或转人工的判断在安全层对不可信内容做隔离。这三层校验叠加才构成一个能兜住脏数据的可靠边界。能讲出工具返回也要校验这种细节说明你真在生产里被脏数据坑过而非只在原型里转圈。最后落到一句话收束Agent 可靠性工程的本质是把一个非确定性、长链路、依赖外部世界的系统用容错、护栏、可观测、回归、预算这五件传统 SRE 的武器重新变得可控。它不性感但它是 Agent 从 Demo 走向生产真正那道坎。本篇与 B30 生产化、B20 可观测、B32 安全、B34 编排、B37 互操作共同构成了生产级 Agent的完整工程面缺任何一块都会在某次线上事故里露馅。把这整张图装在脑子里面试时从容讲出权衡与落地你就已经是那个有实战视角的候选人。再讲一个容易被忽略的可靠性维度时间维度的可靠性也就是长时任务和断点续跑。很多 Agent 任务不是几秒能完成的可能跨分钟甚至跨天如分析上个月全部日志并出报告。这类任务一旦中途失败从头重来成本是灾难级的因此可靠性工程必须包含检查点与可恢复句柄呼应 B22 长时任务与断点续跑。工程上要把长任务切成可独立验证的阶段每完成一阶段就持久化中间结果和进度句柄失败时从最近检查点续跑而非归零用户取消任务时也要能顺着调用链取消下游子任务避免资源泄漏。这把可靠性从单次请求扩展到了长时间运行的维度是生产级长时 Agent 的标配。最后补一个和成本的关联因为可靠性和成本常常打架。为了可靠你会加重试、加降级、加人工兜底、加影子流量灰度每一层都增加成本和延迟为了省钱你又想砍掉这些护栏。成熟的做法是用错误预算做裁判预算充足时多投可靠性、预算吃紧时优先保核心路径的护栏。但有一条不能砍——幂等和超时这两道最便宜的护栏它们几乎不增加成本却能挡掉绝大多数灾难是可靠性的地基。面试能讲出可靠性和成本用错误预算权衡、但幂等超时不可省会显得你对生产约束有真实体感。最后再强调一次可靠性工程的投入要分层、要讲 ROI。不要把所有护栏一把梭地全上而是按故障的影响面分级影响资金、安全、合规的故障护栏拉满、混沌常跑影响体验但不致命的门禁即可、人工兜底纯内部、可逆的先监控后优化。这种按风险分层投入可靠性的思路既保证关键链路稳又不至于让工程成本失控。面试能讲出分层投入而非一刀切会显得你对生产约束有真实体感。最后还要点出一个常被忽略的可靠性视角可靠性的目标不是零失败而是失败可预期、可控制、可恢复。追求零失败要么不现实要么代价无穷大成熟团队追求的是把失败关进笼子里——失败发生时用户感知最小、系统不雪崩、数据不损坏、且能快速定位恢复。这套容错而非杜绝的 mindset是 SRE 文化的精髓也是 Agent 可靠性工程真正要交付的东西。面试时能讲清我追求的是可控失败而非零失败会显得你对生产约束有远超同龄人的体感。最后再补一句关于可靠性的度量的提醒很多团队把解决率当成唯一可靠性指标结果为了冲解决率让 Agent 硬答错误率和投诉反而上升。可靠性要用一组指标共同度量——解决率、错误率、幻觉率、转人工率、平均恢复时间——且要同看。单追某一个都会跑偏这和 B35 行业落地里强调的四张表同看是同一套思想。面试能讲出可靠性不能用单指标衡量会显得你对生产度量有真实体感。再补一个关于混沌工程在 Agent 上的特殊性的提醒传统混沌工程注入的故障是确定性的杀进程、断网络但 Agent 的失败常是非确定性的这次成功下次失败因此 Agent 的混沌测试不能只注入外部故障还要注入模型行为变异——比如故意让模型输出错误指令或越界调用验证护栏能否拦住。这种对智能体自身不可靠的测试是 Agent 可靠性区别于传统服务可靠性的核心。面试能讲出要测模型行为本身的不确定性会显得你对 Agent 可靠性有真知灼见。最后再强调一遍可靠性不是一次性达标而是持续对抗。今天拦住的故障明天会换包装今天稳的系统三个月后可能因数据漂移而悄悄退化。因此可靠性工程要左移写代码时就加护栏、要闭环失败反喂评测、要常态化混沌与复盘成节奏。能把可靠性当成持续军备而非一次建设才是生产级 Agent 团队真正该有的姿态也是面试里最加分的那层认知。把可靠性当成持续军备而非一次达标这层认知正是生产级 Agent 团队和 Demo 玩家的分水岭。面试速答问Agent 可靠性和传统服务可靠性有什么不同答Agent 路径不确定、依赖外部未知、失败长尾难复现所以不能靠写好代码保证要靠容错、护栏、可观测、回归等系统纪律兜住。问怎么防 Agent 无限重试烧预算答工具调用做幂等键、指数退避、按错误类型区分重试/快失败、超步数/超时/总成本三道硬护栏。问熔断和降级有什么区别答熔断是检测到依赖持续故障后暂停调用、快速失败降级是故障时切到次优但稳的能力或转人工二者常配合使用。问发布门禁怎么设答回归集做非劣性检验、影子流量对比、按 1%/5%/50%/100% 灰度关键指标掉点超阈值就拦截。高频追问清单Agent 的幂等键怎么设计才能保证重试不重复发消息LLM 本身可能输出错误指令护栏怎么拦和工具超时有什么不同降级到人工的成本怎么控会不会沦为全转人工混沌测试在 Agent 上最大的难点是什么非确定性导致不可复现错误预算耗尽但业务又催着上新功能怎么权衡多智能体B37下熔断和错误预算怎么跨智能体核算长时任务B22的可靠性靠什么checkpoint/可恢复句柄怎么度量Agent 可靠性本身而不只看解决率