智能体运维：部署与运营

持久状态与可恢复性

把智能体循环做成一次持久计算——事件溯源式历史、先写日志再产生副作用、以重放而非重新推导来恢复，使崩溃或重新部署绝不重启一个做了一半的任务。

并发、队列与扩缩容

智能体是批处理作业而非请求：带租约 worker 的队列、按租户并发上限、以日志为状态实现横向扩缩、以及有界扇出，才是能扛住生产负载的形态。

幂等、重试与副作用安全

四个叠加的重试源意味着每个写工具都会触发两次——除非你用源自意图的幂等键、失败分类与持久副作用账本构造出恰好一次。

在循环层面控制成本

智能体成本默认无界；把按任务的 token/步数/美元上限当作 fail-closed 熔断器，再对着质量指标调模型级联、提示与工具缓存、以及提前退出。

灰度发布、版本化与固定

行为是（模型、提示、工具）三元组；固定到带日期的快照、在每次运行上打戳，并只经影子/灰度加评估闸门提升新版本，配以即时配置切换回滚。

面向智能体的特性开关

面向 prompt、模型、工具与策略的开关——该把什么放进开关、如何放量，以及为何"默认关"对智能体开关是没得商量的。

急停开关

一个能停下整支正在运行的智能体队伍的按钮——它真正要拦下的东西（飞行中调用、排队任务、计划重试），以及如何在你真用上它之前就把它演练好。

事故响应与失控遏制

失控的智能体 fail-open 且持续行动；从速率与进展检测、用恢复路径也遵守的循环内 fail-closed 熔断遏制、依赖预装的爆炸半径界限，并把每桩事故变成回归测试。

速率限制与厂商容量

429 是一份容量合同而非瞬时故障，重试它会把缺口变成宕机；智能体的每分钟令牌消耗是平方级的，所以修法是一个共享的准入控制令牌桶、有意识的负载卸载，以及把跨厂商故障转移当作评估必须覆盖的行为变更。

模型退役与迁移

模型 ID 是一个带保质期、且无法 vendor 的依赖：通知下限低至 60 天甚至更短、为何切换是一次重新资格认证而非字符串替换、平台静默自动升级才是最糟的失败模式，以及把一次退役变成一天工作量的自动生成清单与常热候选通道。

为智能体自建推理

离开厂商 API，计价单位就从 token 变成 KV 缓存字节：容量是并发序列数乘上下文长度、前缀缓存命中率是路由问题而非引擎问题、自动扩缩在智能体的时间尺度上不管用，而盈亏平衡点是一个利用率数字。

智能体的多租户

智能体新添了五个你的行级策略从未触及的存储——提示词缓存、语义缓存、向量索引、记忆与限流额度池——而其中只有语义缓存会把一个租户的答案交给另一个租户。

智能体的 SLO 与错误预算

正确性在 SLI 必须通过的每一项测试上都不及格，所以对你能确定性计算的机械指标做预算、跑一份以"已采取动作数"而非"已服务请求数"为分母的第二份危害预算，并把裁判打分的质量降格到一张永不传呼的控制图上。

优雅降级与备用方案

备用方案是另一个智能体——不同的工具方言、上下文上限与拒答画像——它让最大的一股流量走上测试最少的路径，头顶还是照着一个已停止作答的模型校准的阈值：先决定卸掉什么再决定换成什么、对有副作用的操作失败闭合，并把降级做成一个有出口的具名状态。

退出一个托管智能体运行时

维护模式承诺既有负载继续运行，而这恰恰是让团队一等再等的原因——真正的期限是被冻结的模型目录不再提供你需要的某个模型的那一天；与此同时，人人以为最难的那个循环一个迭代周期就搬完了，而没人清点过的对话状态才是那次迁移：第一天就把导出验证掉、开双写，然后在一个已停止增长的积压面前去搬代码。

第三方工具漂移

工具描述是你 prompt 的一部分，而那段文字归别人所有，于是行为会在没有提交、也没有报错的情况下改变——吵闹的结构性破坏反倒是无害的那一类，而一句改写过的文档串会悄悄挪动工具选择率：给目录做快照、把它的哈希打在每条 trace 上，并在门面层而不是 prompt 里吸收这次变化。

定时与事件触发的智能体

没有用户在场时，"问"变成"弃权"，"重试"变成"对账"，默认的失效是沉默而不是报错——所以给每条排程装上守尸开关、让每次触发以"动了/无事/卡住"的判定收尾，并独立于智能体自身判断给通知频道限流。

给智能体系统做压测

第一个决定是拿副作用怎么办，而每一个答案都会改变测量本身——mock 掉的工具抹去了主导一条轨迹的那几秒真实延迟。用利特尔法则定规模、用采样出的真实任务而不是一条重复的提示来造负载、在负载下给质量打分（因为退化是无声的），并报出成功率开始下滑处的并发数，以及第一个返回 429 的依赖是谁。

重建索引与向量模型迁移

向量模型是一份没有原地迁移路径的 schema——两个模型身处不同空间，于是没有灰度、没有双读，只有一套完整的第二索引加一次原子切换——而那次发现切块器早已漂移的重建，正是质量差值再也归不了因的那一次。

修复智能体已经做过的事

遏制机制在四秒内触发，对付的却是三周前落地的故障；而几乎没有人告诉你，已经提交出去的那四千次错误动作该怎么办——每一次都是一个判断而不是一行记录，所以要按决策而非按记录划定范围，把损害分进重算、补偿、不可逆与派生四个桶，对照当时生效的钉住版本重放，并把回填做成一次以原始 run id 为幂等键、先计算后执行的分段迁移。

给智能体做预发布环境

把工具 mock 掉，等于删掉了你原本想抓的延迟、错误形态与 schema 漂移，而模型才是那个能免费钉住的部件——所以把直觉反过来：跑四级保真度台阶，每一级只能为「它本来抓得住其失败」的那一步发布把关，并把边界放在一个会返回「智能体会相信的成功」的出网写阻断器上。

工具目录的生命周期

工具选择是整份目录的函数，所以第四十个工具会改变那三十九项本来跑得好好的任务上的行为，而这些定义在每一份缓存前缀里都是一笔永久性的「每步成本」——于是新增工具的闸门是那份既有评测集而不是一份新的，按任务类型划范围比动态工具检索更值钱，而移除是一次带墓碑的迁移而不是一次删除。

协议版本与弃用窗口

协议版本是一项按别人的日历到期、又坐在一条你只拥有一端的连接两头的依赖，所以根本没有「切换」这回事——只有一个你有意去跑的双版本窗口；而窗口里每一个决定的输入，是一个几乎没人记录的数字：协商版本按流量占比、以及按去重调用方个数的分布。在边缘把两个版本归一，而不是把部署叉开；把已弃用的能力放进管着证书到期的那本日历；选库要看它历史上的版本滞后，而不是看它的吞吐。

长会话与零停机发布

滚动更新、连接排空与三十秒宽限期，都是为亚秒级请求设计的；而一次智能体会话是一通电话，于是你的发版节奏如今被会话时长分布的 p99 框死，而不是被你的流水线框死。把构建钉在会话上而不是去迁移它，并预期真正会坏的是新版本读不懂的会话状态——然后依据"你愿意排空多久"定出一个最长会话时长，有意地把尾部框住。

沙箱池与冷启动

每一个「百毫秒以内」的沙箱数字都是一次快照恢复、且是一个一个量出来的，而这两半碰上扇出都活不下来：在一份公开基准里，某家厂商串行录得 83 毫秒中位数，并发 100 时录得 14.8 秒，各家之间的排序还几乎倒置。「热」与「干净」是同一个旋钮——Firecracker 自家文档称从同一份状态恢复超过一次即不安全，因为熵、标识符与缓存下来的凭证都会重复——所以按你的信任边界给沙箱定键，用 Little 定律在一个以分钟计的持有时间上算池子大小，并查清你的厂商到底收不收空转的钱。

服务智能体流量

你这套 API 的设计假设受挫的客户端会停下来、困惑的客户端会去读文档；智能体两样都不会，所以 429 是一次暂停而不是一个信号，而你的错误响应体是一段提示词。2026 年自动化请求已越过 HTML 流量的 57.5%——先给流量类别打标签，把错误做成机器可执行的，为写操作公布一份幂等契约（因为调用方一定会重试），并且为操作而不是为会话定价。

超时与截止时间预算

你的智能体里每个超时值都是由一个看不见其他超时值的人定的，而它们的乘积才是你真正上线的最坏情况：二十步循环里三十秒的工具上限，配上 SDK 默认的十分钟与两次无声重试，是一趟以小时计的运行——而一个百分之一概率走慢路径的步骤，会让六分之一的运行变慢。像 gRPC 那样，把一个绝对截止时间沿运行往下传，并从剩余时间导出每一个超时；然后记住超时是把活儿丢下而不是取消掉，所以一次写操作到期后该走的是按幂等键对账，绝不是一次由模型提议的重试。

对智能体栈做故障注入

普通服务里依赖挂了你会拿到一个 500；智能体里你拿到的是一段流畅的错误答案和一张全绿的仪表盘，因为处理这个错误的组件是一个被训练成「接着往下做」的模型。在工具边界而不是网络层注入——空的成功、慢但正确、200 里装着错误、陈旧数据、运行途中凭证过期——用一份带种子的按运行故障计划，然后在轨迹上断言，把每次运行判成正确降级、诚实停下、或无声编造三者之一。只有第三种该卡发布，而一条机械的检查就能抓住其中大部分：同一次运行里，写入绝不能跟在一次出故障的读取之后。

未被钉住的厂商默认值

你生效的配置，是「你设置的」与「供应方、SDK、网关和 harness 替你选的」的并集——而一个钉住的快照钉住的是权重，不是你的请求省略掉的那些字段：Claude Opus 5.5 把 effort 默认为 medium，而其他每个模型默认都是 high，于是一次模型字符串替换把推理往下挪了一档，却没有任何 diff。请把解析后的配置记成一个指纹、每天在 CI 里对着活的 API 断言它、把任何会挪动成本或工具调用的参数显式设置下来，并把一次默认值变动当作一次发布。

智能体的跨区域故障切换

RTO 与 RPO 都假设恢复的单位是一次请求，而一次智能体运行不是：区域死掉时，一个四十分钟的任务已经施加了 n 个对外动作中的 k 个，而除非你写了副作用台账，k 是没有记录的。请把任务分成只读、带键与无键三类，并让类别来决定如何恢复；把准入控制与在途任务的决定分开；并预期真正的失败是容量——因为缓存是冷的、速率上限是按区域算的，而承诺额度可能不会跟着你走。

气隙环境中的智能体部署

人人都问模型跑在哪，而这恰是唯一有厂商答案的问题；真正昂贵的意外是那些隐式互联网依赖——软件包索引、工具注册表、托管评判模型、遥测、证书吊销列表——它们在气隙之内每一个都以「无法解释的质量回归」而非连接错误的形式失败。请在架构评审之前把主权云、自托管与气隙三者分开，把「模型档位会不一样」算进计划（IBM 的自托管版 Bob 保留了外壳，交付的是 Nemotron 与 Laguna，而不是托管的前沿模型），并接受那道验收闸：在预发环境里封掉对外访问跑一整天，数的是自信的错答，而不是失败的工具调用。