企业平台与推理部署：把 Agent 接进生产的那一层

一句话：企业平台不是给模型套一层 API，而是把入口、能力、权限、预算和推理资源拆成可治理的层；换来的是多团队复用和故障可控，代价是每一层都要自己承担边界与成本。

适用：2026 年企业级 Agent 平台与推理服务的落地实践；产品能力与参数以官方文档为准。

为什么需要

Demo 阶段只有一条链路：一个应用、一个模型、一把密钥。接进企业后，问题会变成：十几个团队共用一套模型，谁超支了；调用方是员工还是外部租户，能看哪些数据；模型降价或故障时怎么切换；一次请求慢，是网关排队、工具超时还是推理排队。

最常见的错误是把网关当成万能层。网关能准入、转发、记账，但不能替业务判断任务是否成功；也不能因为请求过了网关，就认为它有权限调用后面的工具。另一个错误是平台一上来就铺七层，结果每层都薄，故障时没人说得清问题落在哪。

平台的价值不是“组件齐全”，而是一次请求的每一段都有明确的权威和退出路径：谁放行、谁限流、谁保存任务状态、谁对业务结果签字。AI Coding 专栏的全闭环架构讲的是编码会话的状态机；本文讲通用平台与推理层，两者不重复。

核心机制

分层：把一次请求拆成可治理的段

分层的作用是让故障和成本可以落到具体一段：入口决定谁能进来，网关决定这次请求走哪个模型、花多少预算，能力层决定任务怎么跑，推理层决定每个 token 的成本。层数本身不产生价值，跨层重试和预算相乘才会失控——网关重试 3 次、能力层再重试 3 次，下游可能收到 9 次调用。

层	主要职责	不该由它决定
接入	身份、协议、租户识别	业务是否正确
网关	路由、限额、缓存、内容安全、计量	任务状态与业务 Outcome
能力	编排、工具调用、知识检索、记忆	模型怎么跑
推理	批处理、显存管理、输出采样	谁能调用、能花多少
治理	策略、审计、版本、成本分摊	替业务签字

网关与预算：三种语义，别让一个组件背三种权威

LLM 网关管模型调用：路由、降级、限额、计量。MCP 网关管工具接入：发现工具不等于授权调用，顺序是身份认证、协议校验、授权、转发。Agent 网关管任务入口：租户配额、任务关联、会话归属。三者可以共用一个进程，但授权和权威不能混。

预算至少分四层：请求速率、时间窗 token、余额配额、严格预算。前两层防突发，第三层防超支，严格预算才能证明“最多花多少”——它需要原子预留、幂等结算，失败也要把预留释放。重试必须先分类错误：429、503 可重试，参数错、权限拒绝重试只会放大成本。

任务级的时间、步数、模型调用、工具调用和 Token 五重预算，以及预算超限后的处理，见 09-生产治理与降级。平台侧的统一口径是降级阶梯 L0–L6：L0 完整，L1–L3 按 LLM / RAG / 工具哪个先挂跳级，L4–L6 是资源、错误率和兜底链；不要再保留另一套粗粒度的分级说法。

超时要分五个：连接、首包、首 token、流式空闲、总时长。只设一个总超时，长流式任务会被误杀；只设首 token 超时，模型卡在中间无限输出又没人管。

身份与多租户：权限是交集，不是某一个字段

用户身份、工作负载身份、代授权范围、资源侧限制，四者取交集才是有效权限。常见做法是 OAuth 令牌交换或代表用户调用，换短时凭证，绝不把调用方凭证原样透传给下游。

隔离要落到键上：记忆、缓存、任务、日志都用 {tenant}:{session} 前缀，避免“查到了别人的会话”。审计记录谁在什么时间对什么资源做了什么，但审计不等于业务证据——业务是否真的完成，仍要回到业务系统或授权验证方。

推理部署：显存、批处理与缓存

Prefill 把整段输入算一遍，吃算力；Decode 逐 token 生成，吃显存带宽，所以输出通常比输入贵。KV Cache 与上下文长度、并发数成正比，是显存里最紧张的部分；PagedAttention 用固定大小的块管理它，按公开资料，碎片率可从约四成降到个位数，并发能力提升约 2–3 倍（具体随模型与负载变化）。连续批处理按 step 调度而不是按请求调度，让新请求随时插入，公开资料常给出 10–20 倍吞吐提升，同样需要按自己的负载校准。

前缀缓存把重复的系统提示、工具定义、长文档做成可复用的块，命中就跳过对应的 Prefill。Agent 负载正好是“输入长、输出短、前后高度重复”，所以缓存命中率几乎直接等于成本。工程上要注意两点：gpu_memory_utilization 是保险丝不是越高越好，留不出余量会在长请求时 OOM；max_model_len 要按业务上限设，否则一个超长请求会把显存打满。

自建推理适合负载稳定、利用率高、数据必须留在自有环境的场景；波峰波谷大、缺少 GPU 运维能力时，托管 API 的总成本通常更低。分布式推理里，张量并行切层内矩阵、通信密集，流水并行切层间、适合跨机，选择取决于模型能否单卡放下以及互联带宽。

平台的两端：长任务与边缘

长任务不能占着 HTTP 连接：提交即返回 Task ID，执行生命周期与请求生命周期分开。Task 的权威在业务应用，队列、调度器和状态机只负责推进；Checkpoint 能复用计算结果，但不等于外部副作用幂等，已经发生的写操作只能补偿。Pod 池、11 状态机、HITL 中断恢复与幂等写回见 04-运行态Pod池与任务编排。

边缘只承接“不需要权威状态、无写副作用、符合数据驻留”的请求：鉴权、路由、缓存查询、安全初筛。涉及一致性、顺序、恢复语义和写操作的必须回中心；语义缓存只对公开、幂等、低风险请求开放，键里要带租户、权限域、模型和知识版本。

实战场景

场景：第一个 Agent 还没接上，平台已经建到第五层

现象：一家企业按“企业级”清单先建平台，接入、网关、能力、推理、治理五层齐备，投入两名架构师加六名后端约一个季度（经验值，需校准）。半年后平台上只有两个 Agent 在跑，其中一个是演示。业务团队回退到直连模型 API：走平台接入要提 6 个工单、跨 4 个团队，平均周期 3 周（经验值，需校准），比自建还慢。

排查过程：不数功能，数权威——一次请求的每一段都要有明确的权威和退出路径，即谁放行、谁限流、谁保存任务状态、谁对业务结果签字。逐层问这四个问题：接入层有权威（身份、协议、租户识别），网关有权威（路由、限额、计量），能力层只是 SDK 转发，既不保存状态也不对结果签字；推理层是上游代理；治理层的审计只记录“请求进过”。五层里两层是空壳，故障定位反而更慢：一次“响应慢”要跨四层查，而固定排障顺序（先看网关是否限流或重试，再看能力层是否工具超时，再看推理队列与显存，其余才怀疑模型质量）落不了地，因为空壳层没有指标可看。

对症做法：按链路建，不按层建。先挑一条真实业务链路，把接入、网关、能力、推理四段的权威与退出路径写清，用最小上手那组字段（route、timeout、budget、retry、isolation）跑通判据：同一租户超限返回 429 而不是拖垮全局、下游故障按配置切换且不重复计费、长任务在请求断开后仍能凭 Task ID 恢复、缓存命中与未命中的成本能在账单里分开看到。判据跑不通才补这一层，跑通了才加下一层；加一层的唯一理由是现有某层的权威被违反。

复盘要点：层数本身不产生价值，跨层重试和预算相乘才会失控。平台是否建对，看故障能否定位、成本能否算清、能不能回退，不看组件是否齐全。

案例：一个夜间批量任务饿死全平台——配额与缓存没按租户分区

现象：某租户把评测任务放到白天跑，推理服务并发被吃满，在线 Agent 的 TTFT 从 1–2 秒涨到分钟级，排队时长 P95 冲到十几分钟（经验值，需校准），波及 7 个团队（经验值，需校准）。复盘发现平台只有一层全局请求速率限制，租户级的余额配额和严格预算都没上。

排查过程：按排障顺序取三段证据，并把归因分成策略、实现、容量三类。

段	看的指标	观察	归类
网关	限流命中、预算拒绝	没有租户维度的拒绝记录，全局阈值先到	策略缺失
能力层	队列深度、任务并发	批量与在线共用一个队列和同一组键	实现问题
推理层	GPU 利用率、KV Cache 占用、并发数	利用率打满，长输入批量请求挤占显存带宽	分区缺失，不是总量不足

关键区分：GPU 总量够用、并发上限未触顶，所以不是容量问题；max_model_len 按平台上限而非业务上限设，一个超长批量请求就能把显存打满，gpu_memory_utilization 又调得过高留不出余量，这是配置与实现问题；只有“租户维度没有配额”属于策略。三类归因修法不同，混成一谈就只会加卡。

对症做法：四层预算全部落到租户维度——请求速率与时间窗 token 防突发，余额配额防超支，严格预算才能证明“最多花多少”，它需要原子预留、幂等结算，失败也要把预留释放；批量任务走独立队列与独立实例，按提交即返回 Task ID 的任务句柄形态跑，不占在线连接；隔离键从 {tenant}:{session} 上推到租户级并发与 KV Cache 配额，前缀缓存按租户分区，命中率才能归因到租户；队列深度设告警做背压，重试只对 429、503 开放并在租户预算内退避。

quotas:
  tenant:      {rpm: per_tenant, tokens_per_hour: per_tenant, daily_cost: strict_reserve}
  workload_class: {online: {max_concurrency: cap_online, kv_cache_share: share_online},
                   batch:   {queue: separate, max_model_len: business_cap}}
backpressure: {queue_depth_alert: depth_limit, on_saturated: fallback_chain}  # 阈值经验值，需校准

复盘要点：一个租户的突发升级成全平台事件，通常是策略、实现、容量三件事都没做，只做了扩容。隔离要落到键上，配额要落到权威上，缺一，限流就只是排队。

场景：发布与扩容排在同一窗口——两层各自“正常”，故障拖了 100 分钟

现象：网关版本发布与推理层扩容安排在同一窗口。发布改掉了前缀缓存键里的 Prompt 版本，命中率断崖，全量请求重跑 Prefill；扩容脚本按队列深度补了一批节点，调度开销与显存碎片一起上升。两边各自看监控都显示“已恢复”，在线 P95 延迟实际劣化持续 100 分钟（经验值，需校准），影响 3 个租户档位。

排查过程：照固定排障顺序逐段拿证据。网关：错误率不涨，但同一请求出现多次上游调用——网关重试 3 次、能力层再重试 3 次，下游可能收到 9 次调用，重试相乘把排队进一步放大。能力层：工具耗时正常，排除。推理层：TTFT 大幅上升而单卡吞吐没有上升，前缀缓存命中率曲线在发布时刻断掉——Agent 负载输入长、输出短、前后高度重复，命中率几乎直接等于成本。基础设施：新节点数与排队时长同时上涨，扩容把症状当容量补。定性结论：报文完好，不是协议问题；新网关功能通过单测，不是实现缺陷；是发布改了缓存这一容量前提，自动扩容把它放大。

对症做法：平台发布与推理扩容互斥，各有冻结窗口，同窗口变更默认拒绝；扩容判据不用单一排队指标，至少与命中率、KV Cache 占用、单位成功任务成本一起看；重试预算全局一份，跨层相乘必须能在日志里数出来，写操作的幂等键必填；灰度按单租户 → 单团队 → 全量推进，每个变体至少观察 7 天、累计上千次任务并保留固定对照，发布门槛不是平均分而是关键场景不退化、P95 延迟不超预算、单任务成本不上升；缓存键变更当作一次容量事件做预案，把命中率回落的成本算进灰度期。

复盘要点：分层是为了让故障和成本能落到具体一段，不是为了允许两层同时改。同窗口的两个“正常变更”会互相污染指标，让每一层都以为对方已经恢复。

最小上手

# 示意：网关准入配置的最小字段
route:      {primary: model-a, fallback: [model-b], by: tenant}
timeout:    {connect: 1s, first_byte: 3s, ttft: 5s, idle: 30s, total: 120s}
budget:     {rpm: 60, tokens_per_hour: 200000, daily_cost: 50, strict: true}
retry:      {max: 2, on: [429, 503], backoff: exponential, idempotency_key: required}
isolation:  {key_prefix: "{tenant}:{session}", credential: short_lived}

跑通判据：同一租户超限时返回 429 而不是拖垮全局；下游故障时按配置切换且不重复计费；一个长任务在请求断开后仍能凭 Task ID 恢复；缓存命中与未命中的成本能在账单里分开看到。

生产动作

监控五组指标：延迟（TTFT、总时长、分位）、容量（并发、队列深度、GPU 利用率）、质量（成功率、工具错误率、降级率）、成本（单成功任务成本、缓存节省、租户 Top-N）、边界（越权拦截、预算拒绝、内容安全命中）。

灰度按“单租户 → 单团队 → 全量”推进，经验上每个变体至少观察 7 天、累计上千次任务，并保留固定对照；发布门槛不是平均分，而是关键场景不退化、P95 延迟不超预算、单任务成本不上升。排障顺序固定为：先看网关是否限流或重试，再看能力层是否工具超时，再看推理队列与显存，最后才怀疑模型质量。降级按 L0–L6 走：先退到缓存/知识库或小模型，再关非关键工具，最后转人工或稍后重试，而不是直接报错；完整阶梯与阈值见 09-生产治理与降级。

平台指标也是自进化的输入，怎么用它做归因和实验见10-自进化与持续优化；确认是模型能力缺口而不是平台问题时，再看12-微调与模型适配。

边界

• 适合：多团队、多租户、多模型并存，成本需要分摊、权限需要审计的组织；不适合：单团队单模型、流量很小、一个人就能看完链路的场景。
• 适合：负载稳定、数据驻留要求高、有 GPU 运维能力时自建推理；不适合：波峰波谷剧烈、团队没有推理调优经验时为了“省 API 费”自建。
• 适合：用网关统一入口、限额和记账；不适合：让网关承担任务状态、业务成功判定或工具授权。
• 常见误区一：平台层数越多越“企业级”。层数多但每层没有权威，只会让故障定位更慢。
• 常见误区二：请求过了网关就等于有权限。网关只证明“允许进入”，工具和数据仍要各自校验。
• 常见误区三：自建一定比 API 便宜。只算 GPU 单价、不算利用率、运维和空闲成本，账通常是反的。

讲清楚

平台把请求拆成入口、网关、能力、推理和治理几层，每层有权责和退路。网关管准入、路由、限额、记账，不替业务判成功；身份取调用方、工作负载、代授权与资源限制的交集，隔离落到租户会话键上。推理成本由 Prefill、Decode、KV Cache 与命中率决定；长任务与边缘请求按是否需权威状态、有无写副作用决定。平台是否建对，看故障能否定位、成本能否算清、可回退。

适用：2026 年企业级 Agent 平台与推理部署实践 | 初稿 2026-10