L3 · Agent System 如何接入和管理 AI 模型？ - Model Services

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：02 · Agent System 是如何构建和运行的？ - Technical Architecture
文档类型：模型服务技术架构、接口契约与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent System 如何将不同厂商、不同协议、不同模态和不同部署方式的 AI 模型接入为可治理的系统能力？模型服务层如何设计统一调用契约、能力发现、模型选择、路由、限流、重试、超时、流式输出、用量与成本核算、版本管理和故障处理，并在不破坏 Agent Engine 决策语义的前提下，向上层提供可靠、可观测、可替换的模型调用能力？

专题导读

本篇属 Technical Architecture。一个 Agent System 可以只调用一个模型 API，也可以同时使用远程大模型、本地推理服务、Embedding 模型和专门的分类或重排序模型。随着任务数量、工具使用和模型能力需求增长，直接把供应商 SDK 调用散落在各个 Agent 中，会使协议差异、密钥、配额、重试、价格、版本与故障处理难以一致管理。L3 Model Services 的研究对象，就是如何将“模型调用”从零散的函数调用，发展为边界清楚、契约稳定、可按需演进的软件能力。

本篇承接 L1 Infrastructure 的计算与网络环境、L2 Platform Services 的存储、队列、身份和遥测能力，向 L4 Agent Engine 提供模型推理接口。重点区分三件事：模型本身的能力（01 · AI）、单个 Agent 如何使用模型完成认知和行动（02 · Agent），以及系统如何统一提供和治理模型调用（本篇 L3）。模型服务层负责让调用可用、可控、可追溯；是否继续思考、何时调用工具、何时终止任务，原则上由 L4 的执行机制和 Agent 策略决定。

全文从职责边界、协议与数据契约、路由与容量、故障与一致性、用量成本、安全治理、框架对照、工程案例和可复现实验设计展开。文中的 JSON、Python 和配置均为参考设计，不代表任何一家模型厂商的完整实际 API Schema。文章末尾分别列出原始资料入口与验证边界，避免将架构建议误写成已经完成的生产验证。

一、研究定位：L3 究竟负责什么

1.1 六层架构中的位置

L6 Application                用户、外部 API、结果呈现
       │
L5 Orchestration & Collaboration 任务编排、多 Agent 协作
       │
L4 Agent Engine               推理 - 行动循环、Run/Step、停止条件
       │  ModelRequest / ModelResponse / StreamEvent
       ▼
L3 Model Services             模型目录、适配、路由、执行策略、计量
       │  provider-specific requests / streams
       ▼
外部模型 API / 自建推理端点
       │
L2 Platform Services          密钥、配置、缓存、数据库、遥测等依赖
L1 Infrastructure             计算、网络、GPU、容器和进程

这是职责图而非强制的进程拓扑。最小系统可以在同一 Python 进程内用一个 ModelClient 实现 L3；成熟系统可以将模型网关部署为独立服务。L3 不一定要拥有数据库、队列、GPU 或专门网关。

1.2 核心职责与非职责

职责	L3 应负责	不应混淆为
模型接入	适配协议、鉴权和返回格式	训练模型权重
能力目录	声明可用模态与功能	保证模型实际质量
调用治理	配额、并发、超时和预算检查	决定任务是否完成
模型选择	根据明确策略选候选模型	替 Agent 制定任务计划
结果处理	规范化输出、错误和用量	自动证明事实正确
运行证据	记录版本、延迟、调用和成本	无限制保留敏感 Prompt

特别注意：工具调用协议属于模型输出接口的一部分；工具是否真正执行、是否获授权，属于可信执行层的职责。模型服务返回 tool_call 不意味着系统已经执行该工具。

1.3 最小可用 L3 与独立服务的区别

最小形态：一个可配置模型客户端、超时、错误分类和基本用量记录即可。多模型形态：增加能力目录、模型路由、凭据隔离与适配测试。生产化形态：增加分级配额、跨租户账本、故障切换、模型版本治理、数据驻留策略和服务等级指标。是否拆成独立服务，应由复用程度、隔离需求和运营复杂度决定，而非以“是否微服务”衡量成熟度。

二、模型调用契约：统一什么，保留什么差异

2.1 请求结构的逻辑模型

推荐以显式契约隔离 L4 与具体供应商。下例是本知识库提出的逻辑 Schema，不是某厂商原生 API：

{
  "request_id": "req-203",
  "run_id": "run-018",
  "step_id": "step-006",
  "tenant_id": "team-a",
  "task_class": "evidence_synthesis",
  "capabilities": ["text", "tool_calling"],
  "messages": [{"role": "user", "content": [{"type": "text", "text": "比较两种方案"}]}],
  "tools": [{"name": "search_docs", "input_schema": {"type": "object"}}],
  "output_contract": {"type": "json_schema", "schema_id": "report-v2"},
  "policy": {
    "max_latency_ms": 20000,
    "max_output_tokens": 1200,
    "cost_ceiling_usd": 0.10,
    "data_class": "internal",
    "allowed_regions": ["approved-region"]
  },
  "model_preference": {"alias": "research-reasoning", "fallback_allowed": false}
}

实际落地需要额外规定字段合法性、上限、消息顺序、工具 Schema 版本、附件引用、幂等/关联 ID、输入大小和可选能力的兼容性。allowed_regions 只有在能够验证供应商处理区域、传输和存储策略时才可执行；一个字符串字段本身不能保证数据驻留。

2.2 响应结构与终止语义

统一响应至少应包含：选用的供应商和模型标识、有效版本/快照（若可获得）、内容块、工具调用提议、停止原因、用量、请求追踪 ID、错误分类及完成状态。常见停止原因包括正常结束、工具调用、长度限制、内容限制或供应商自定义状态。不能把不同供应商的停止原因强行一一对应；应保留原始状态字段并映射为少量稳定的上层分类。

{
  "request_id": "req-203",
  "route": {"provider": "provider-x", "model": "model-y", "revision": null},
  "status": "completed",
  "finish_reason": "tool_calls",
  "content": [],
  "tool_calls": [{"call_id": "c-01", "name": "search_docs", "arguments": {"query": "..."}}],
  "usage": {"input_tokens": 1200, "output_tokens": 180, "cached_input_tokens": null},
  "provider_metadata": {"request_id": "opaque-provider-id"}
}

模型服务只能保证正确传递或转换其实际收到的用量。供应商不提供某字段时应记录 null 或 unavailable，不能以零代替。不同厂商对缓存 token、推理 token、图像/音频计费单位的定义可能不同，统一账本必须保留计量来源和价格版本。

2.3 三层契约：稳定核心、能力扩展、原生透传

第一层为所有调用共用的核心契约：消息、追踪、超时、结果与错误。第二层是按能力协商的扩展：结构化输出、工具调用、视觉、音频、流式事件、上下文复用等。第三层是供应商专有参数透传：仅在明确授权、可记录且不破坏安全策略时开放。把所有参数塞进 extra 会失去可验证性；反过来追求完全统一，也会掩盖重要功能差异。

2.4 能力矩阵与主动协商

能力维度	示例	兼容性检查
输入模态	文本、图像、音频	端点是否接受该输入
输出模态	文本、语音、图像	输出格式与流式行为
工具使用	函数调用、并行调用	参数与工具回合协议
结构化输出	JSON 模式、Schema 约束	约束强度与拒绝行为
上下文	最大输入与输出限制	单位、截断策略
状态语义	无状态、服务端会话	恢复、保留和重放限制

能力目录应包含“声明支持”“已通过契约测试”“暂不可用”三个不同状态。文档支持不等于当前租户、区域、模型版本和具体端点都可用。每次路由先过滤硬要求，再比较软偏好。

三、协议适配：不只是改字段名

3.1 Provider Adapter 的责任

适配器至少完成：请求字段转换、鉴权与端点选择、消息和多模态编码、工具调用协议转换、流事件解析、停止原因映射、用量解析、异常分类、供应商请求 ID 关联。必须防止丢失原始错误、隐式截断输入、静默删除不支持的功能。

典型调用链：

Agent Engine
  → validate(request)
  → capability_filter(candidates)
  → select_route(policy, health, budget)
  → reserve_capacity_and_budget()
  → provider_adapter.encode()
  → transport.send()/stream()
  → provider_adapter.decode()
  → reconcile_usage_and_release_reservation()
  → ModelResponse / ModelError

当请求具有服务端会话 ID、已有生成状态或已开始输出流时，重试和跨供应商切换会引入不同于无状态请求的语义风险。不能假定同一输入换个模型会得到兼容的工具调用或相同结构。

3.2 Responses、Chat Completions 与原生协议

以 OpenAI Agents SDK 官方模型文档为例，SDK 提供 OpenAIResponsesModel 与 OpenAIChatCompletionsModel 两种路径，并说明部分能力只适用于 Responses 路径；非 OpenAI 供应商的兼容端点不一定完整支持 Responses。这里可得出的工程结论是：“OpenAI-compatible”只表示某种协议兼容意图，不意味着所有语义和功能等价。必须为实际使用的功能建立契约测试，特别是工具调用、结构化输出、流式事件、usage、错误与会话语义。官方资料见附录 A。

3.3 多模态和附件处理

文本之外，模型输入可能携带图像、音频、视频帧或文档引用。L3 需要决定是否传递内联数据、预签名对象 URL 或供应商上传后的文件标识，并检查尺寸、MIME、生命周期、权限和数据驻留。L2 对象存储负责对象访问与过期，L3 负责按模型协议组织内容；L4 决定为何需要这些材料。跨供应商回退时尤其要检查附件是否能够迁移，避免“回退成功但遗漏证据”。

四、模型目录与路由：先满足硬约束，再优化软目标

4.1 目录数据结构

模型目录建议记录：provider、model_id、api_surface、capabilities、context_limit、region、data_policy、price_version、availability、contract_test_status、deprecation_date、revision。若供应商未提供可锁定版本，应显式记录“别名可能漂移”。模型 ID、能力和价格都是时间敏感信息，不应硬编码为永久事实。

4.2 两阶段路由

阶段一：可行性过滤。硬约束包括：必需模态、工具/Schema 能力、区域、数据类别、审批策略、上下文需求、租户许可、预算硬上限。无法满足任一硬约束的模型不得进入候选。

阶段二：目标优化。在候选内根据任务类别、经验证的质量、延迟分位数、价格、故障率、剩余配额和缓存命中情况选择。可使用加权评分、规则优先级或实验性 Bandit，但权重与探索范围必须事先定义。质量指标应来自相近任务分布，而非直接照搬公开排行榜。

例如：

候选模型
  ├─ 必须支持工具调用？不支持 → 排除
  ├─ 数据处理区域符合要求？不符合 → 排除
  ├─ 最大上下文足够？不足 → 排除或要求 L4 先压缩
  ├─ 可用配额足够？不足 → 排队或选其他候选
  └─ 比较质量 / P95 延迟 / 预计成本 / 近期故障率

4.3 回退策略的约束

回退有三种：同模型不同可用端点、同能力不同模型、降级能力模型。第一种相对容易保持语义；第二种必须重新验证能力与输出契约；第三种必须由任务策略明确允许。例如需要严格 JSON Schema 的研究报告生成，不能在不告知 L4 的情况下回退到仅能生成自由文本的模型。

安全回退不等于无条件换供应商：敏感数据可能限制可用区域；模型输出可能依赖先前服务端状态；已经产生的工具调用提议不能自动跨模型重放。模型切换事件应写入 Run 轨迹并包含原因。

4.4 粘性路由与一致性

长任务的不同 Step 可以使用不同模型，但若某一执行阶段依赖供应商会话、特定 tokenizer、结构化输出模式或模型特有工具协议，应考虑阶段级粘性路由。若发生切换，需重建独立于供应商的可移植上下文，并记录已知语义损失。不要把“同名模型”视为跨时间行为完全一致。

五、容量管理：限流、并发、排队与背压

5.1 四种不同的限制

请求速率（RPM）、token 吞吐（TPM）、同时在途请求数、预算/金额上限是不同维度。某供应商还可能有按模型、组织、项目、区域或服务等级划分的限制。容量规划必须按实际提供的配额口径实现，而不能假设所有提供商统一采用 RPM/TPM。

机制	保护对象	关键风险
令牌桶	突发与平均速率	估算 token 不准确
信号量	在途并发数	慢请求占满槽位
有界队列	排队资源	排队超时与饥饿
租户配额	公平性和费用	热点租户挤占资源
熔断器	故障中的依赖	错误阈值误判

5.2 预约与结算

请求开始前可以按预计输入/输出 token 或费用进行保守预约；请求结束后用供应商实际返回的用量结算。估算不等于最终账单，尤其涉及缓存、推理 token、图像、音频和供应商计费规则时。硬预算需要定义“最大可接受未结算暴露额”，并将并发请求的预约额度计入可用余额。对于供应商不可返回精确费用的情形，采用有界估计并显式标记不确定性。

5.3 背压与排队超时

当上游提交速率超过 L3 服务能力时，必须选择：立即拒绝、有限排队、优先级调度或降级模型。无限排队只会把故障转化为延迟和内存增长。排队时应保留绝对截止时间：一个排队 30 秒的请求不应再获得完整的 30 秒执行超时，除非契约明确允许。

5.4 容量规划的简化估算

在稳定负载、满足统计前提的情况下，可用 Little's Law 估计平均在途数 L = λW。若平均每秒 2 个请求、平均在途时长 8 秒，则平均在途约 16。实际限流还需要考虑 P95/P99、突发、token 长尾、失败重试和供应商配额；不能把平均值直接当作生产容量上限。

六、失败语义：超时、重试、熔断和取消

6.1 错误分类

建议至少区分：认证失败、权限/区域拒绝、能力不支持、输入无效、上下文超限、配额/限流、网络超时、上游服务错误、内容策略拒绝、解析失败、调用取消、预算拒绝。分类需要保留原始状态码和供应商错误类型，不要将所有非成功响应都标记为 retryable。

6.2 重试条件与风险

只有在调用可以安全重放且错误可能短暂恢复时才考虑自动重试。常见策略是有界次数、指数退避、抖动和尊重 Retry-After（若提供）。认证失败、参数错误、能力不支持通常不应盲目重试。即使网络请求超时，也不能推断上游未收到请求：供应商可能已经完成生成并产生费用。重试可能重复计费，或者使模型产生另一种结果。

对有服务端会话或已开始流式输出的请求，重放安全性更复杂。OpenAI Agents SDK 的模型文档专门讨论了重试策略与重放限制；生产实现应以实际 SDK 版本和供应商协议为准，而不是假定“HTTP 5xx 都可以无害重试”。

6.3 取消语义

L4 发出取消后，L3 应尝试终止本地等待、关闭流连接并释放并发槽位。但客户端取消不等于供应商端计算立即停止，也不等于不会计费。应将取消请求时间、上游确认（若有）、实际用量和最终状态分开记录。

6.4 流式响应的部分失败

REQUESTED → ROUTED → CONNECTING → STREAMING → COMPLETED
                         │             │
                         └→ FAILED      ├→ INTERRUPTED
                                       └→ CANCELLED

流式输出可能已向 L4 交付部分 token 或部分工具参数。断流后不能把不完整 JSON 当成有效工具调用；也不能静默重新请求并把新流接在旧流后面。建议通过 event_index、message_id、content_delta、tool_call_delta、usage_update、final、error 等类型形成内部事件契约，并规定只有在 final 或经验证的完整工具调用事件后才允许执行副作用。

七、用量、成本与版本治理

7.1 账本分层

至少保留三个口径：供应商报告用量、内部成本估算、最终供应商账单对账。它们可能因为缓存、批量价格、汇率、服务等级和账单调整而不同。每次调用应关联 run_id、step_id、tenant_id、route_id、provider_request_id、price_version 与状态。

7.2 价格快照

历史任务不能使用今天的模型价格回算成“当时真实成本”。建议在调用时保存价格表版本、币种、计费单位及价格来源；如果价格未核实，则标记为估算。将 token 用量直接乘单一价格可能忽略输入/输出、缓存命中、推理、工具或多模态计费差异。

7.3 模型版本与可重复性

记录显式模型 ID、可见修订号、请求参数、Prompt 模板版本、工具 Schema 版本、适配器版本、输入摘要和响应追踪 ID。即使这些全部固定，也不保证跨时间完全确定，因为供应商服务和外部环境可能变化。对于重要任务应保留可重放的测试数据、输出样本与回归结果，而不是只记录模型名称。

7.4 缓存策略

模型响应缓存可能节省费用，但不应默认开启。缓存键至少需要考虑模型/版本、请求语义、工具定义、输出契约、租户、数据敏感级别及策略版本；高风险或个性化输出通常不适合跨用户共享。供应商侧 Prompt Cache 与应用侧完整响应缓存是两种不同机制，不应混淆。缓存命中也不能证明响应仍符合最新外部事实。

八、安全与治理：模型服务的信任边界

L3 位于用户任务、内部数据与外部模型供应商之间，是重要的数据出口。应检查调用者身份、模型访问权限、数据类别、允许的供应商/区域、凭据范围、输出保留策略和日志脱敏。授权决策由可信代码执行，不能仅由 Prompt 指令保证。

8.1 密钥与凭据

凭据由 L2 的 Secret Management 或安全配置服务提供，L3 在调用时按租户、环境和供应商选择合适凭据。避免将密钥放进日志、异常栈、Prompt 或客户端响应；建立轮换、撤销和权限最小化机制。多租户共享凭据时，应同时实施租户级预算与调用审计。

8.2 数据外发与日志

默认只记录请求 ID、摘要、计量、模型标识、状态与延迟；完整输入和输出是否保留应由数据分类、合规要求与调试必要性决定。摘要也可能泄露敏感元信息，应控制访问。不得把“供应商支持某项隐私模式”直接等同于当前账户已配置该模式。

8.3 提示注入与输出验证

外部文档中的恶意指令可以影响模型输出，但 L3 不应把模型生成的工具参数视为已获授权。L3 可以提供结构化解析、内容策略结果和风险标签，最终工具执行授权仍应由 L4 的工具网关及 H2 Security 的可信策略控制。模型服务不是通用的事实核验器，也不是唯一安全边界。

九、真实框架与实现路径对照

9.1 OpenAI Agents SDK

官方模型文档说明了模型选择、不同 API 形态、每个 Agent 或 Run 级模型配置、非 OpenAI 提供商接入及混合提供商时的功能差异。这证明 SDK 已包含部分 L3 的模型适配与配置能力；但 SDK 不等于完整的组织级模型网关，也不自动满足跨租户预算账本、区域治理与供应商账单对账。官方文档的默认模型和可用功能可能随版本变化，本文不以某个默认模型名称作为架构前提。

9.2 LiteLLM 等统一网关

统一网关可提供多提供商接入、路由、代理和计量相关能力，但实际支持范围取决于网关版本、提供商端点与配置。即使网关宣称兼容统一接口，也必须对工具调用、结构化输出、流事件、取消和用量字段进行端到端契约测试。本文没有对任何 LiteLLM 版本执行实测。

9.3 自建推理端点

自建推理服务（例如采用 vLLM 等服务软件）让组织控制部署环境、部分调度和模型版本，但也需要自行承担 GPU 容量、推理延迟、热更新、模型权重来源、安全补丁和可用性。其 API 兼容范围同样需要逐功能验证。L1 负责 GPU/容器等基础设施，L3 负责把该端点作为一个受治理的模型来源；L2 可提供注册与监控依赖。

9.4 选择 SDK、网关或自建 L3

路径	适合情境	主要代价
SDK 内部适配	单应用、少量模型	跨应用治理分散
独立模型网关	多应用、多租户	新增服务与故障域
自建推理服务	部署可控、专用模型	GPU 与推理运维成本
混合模式	多环境、多能力组合	路由与数据治理复杂

这四种不是互斥选项。应先确认应用数量、任务规模、模型功能差异、数据处理要求和运营能力，再决定部署拓扑。

十、贯穿案例：技术研究助理的模型服务设计

10.1 任务分解与模型需求

研究助理接收研究问题后，可能经历术语抽取、检索查询生成、证据阅读、比较推理、报告生成和格式检查。不是每一步都必须使用相同模型，也不是每一步都需要大模型。例如确定性 Schema 校验更适合交给普通程序，Embedding 与 Reranker 可使用专门模型接口。

10.2 三阶段演进

阶段 A：个人原型。 一个供应商客户端、明确超时、基本调用日志和调用预算；L4 直接调用本地 L3 模块。此时不需要单独部署网关。

阶段 B：团队服务。 引入模型目录、凭据隔离、租户额度、请求追踪、失败分类、结构化输出契约测试；将费用关联 Run 与研究项目。

阶段 C：多 Worker 与混合模型。 引入分级路由、跨 Worker 配额协调、熔断与故障切换、账单对账、灰度发布和模型回归评测。只有在实际测量表明需要时，才进一步拆分独立模型服务。

10.3 一个完整调用序列

1 用户提交研究任务 → L6 创建 Task
2 L5/L4 规划当前 Step → 生成 ModelRequest
3 L3 验证能力、数据政策与预算
4 L3 从模型目录选择端点 → 预约配额
5 Adapter 将逻辑请求转换为供应商请求
6 供应商返回文本、工具调用提议或流事件
7 L3 校验协议、记录用量、完成结算
8 L4 根据结果决定：继续推理、调用工具、终止或升级
9 H1/H3 对执行轨迹、质量与成本进行评估

如果第 6 步发生网络超时，L3 记录“结果未知”或适当错误状态，不能自动认定没有费用；如果第 6 步返回工具调用，L4 的工具网关必须独立验证权限；如果第 7 步发现 usage 缺失，账本应保留未知值和估算来源。

十一、工程实践：参考接口、测试与验收

11.1 Python 接口草案

以下示例只展示契约形状；没有集成真实供应商，不应直接视为可运行生产客户端。

from dataclasses import dataclass
from typing import Any, Protocol

@dataclass(frozen=True)
class ModelRequest:
    request_id: str
    run_id: str
    capability: str
    payload: dict[str, Any]
    timeout_s: float

@dataclass(frozen=True)
class ModelResult:
    request_id: str
    provider: str
    model: str
    content: list[dict[str, Any]]
    usage: dict[str, Any] | None
    finish_reason: str

class ModelAdapter(Protocol):
    async def invoke(self, request: ModelRequest) -> ModelResult: ...

class ModelRouter(Protocol):
    def select(self, request: ModelRequest) -> ModelAdapter: ...

接口设计中还需要补充流式事件协议、取消传播、异常类型、预算预约和计量结算。Python dict 只是教学上的简化；正式实现应使用 Schema 验证和版本化类型。

11.2 关键不变量

1. 不满足硬能力或数据政策约束的模型不能被选中。
2. 请求被预算网关拒绝后不得向供应商发出调用。
3. 每个已发出的调用必须拥有可追踪的关联 ID 和最终可解释状态。
4. usage = unavailable 不得被静默计为零成本。
5. 工具调用提议未经可信授权不得执行外部副作用。
6. 流中断不能产生“完整工具调用”假象。
7. 回退不得隐式降低安全策略或丢失必需能力。
8. 并发预约和结算必须避免同一预算被重复消费。

11.3 测试矩阵

场景	注入条件	预期证据
能力过滤	端点不支持工具	路由拒绝
数据限制	禁止的区域	无外发请求
限流	超出 RPM/TPM	排队或明确拒绝
超时	上游不响应	状态与用量不确定性
流中断	JSON 尚未完成	无工具执行
重试	429/5xx	有界退避记录
取消	客户端中断	槽位释放与状态分离
预算竞争	多 Worker 并发	无超额预约
回退	模型能力不匹配	禁止不安全回退
计量缺失	无 usage 字段	未知值保留
版本漂移	模型别名变更	回归触发与版本记录
安全审计	诱导泄露凭据	日志脱敏、授权拒绝

以上均为待执行的测试设计，不是已经完成的测试结果。真实测试应固定适配器版本、供应商端点、模型 ID、测试时间、环境、样本和判定规则；对于费用与重试场景，需要检查供应商实际账单而不仅是本地计数。

11.4 可观测性指标

建议记录：成功率（按错误类别拆分）、P50/P95/P99 延迟、首 token 延迟、流中断率、重试率、路由分布、能力拒绝率、配额等待时间、每任务 token/费用、供应商 usage 缺失率、预算拒绝率及回退次数。必须区分用户取消、策略拒绝和供应商故障，避免把合理拒绝计入服务不可用。

11.5 发布门禁

模型适配器上线前至少验证：协议字段和能力矩阵；结构化输出与工具调用；限流/重试/超时/取消；数据与凭据隔离；成本账本；流式中断；版本回归。对跨供应商路由，测试集应覆盖实际要使用的功能组合，而不只测试“Hello World”。

十二、常见误区与设计取舍

误区一：统一 API 就代表模型可互换。 模型能力、上下文、工具语义和数据政策不同，协议转换不能消除这些差异。

误区二：模型路由越动态越好。 路由变化可能影响可复现性、上下文兼容性与成本；简单场景应优先固定模型并建立基线。

误区三：重试总能提高可靠性。 已产生部分输出或存在服务端状态时，重试可能带来重复费用、重复结果和不一致轨迹。

误区四：返回 token 数即可精确计费。 不同模型的计费维度和价格版本不同，必须保存来源并与账单对账。

误区五：Prompt 写了安全规则就完成授权。 数据出口策略、密钥权限和工具执行必须由可信代码强制执行。

误区六：需要高并发就必须先上模型网关。 是否独立部署取决于跨应用复用、治理要求和运维成本；单体内部同样可以实现严格的接口与预算控制。

十三、研究结论

L3 Model Services 的核心不是把多个模型 API 包装成一个同名函数，而是建立可验证的模型能力契约、可信的调用控制与可追溯的运行证据。合理的架构应先定义模型能力、数据政策和预算等硬约束，再进行质量、延迟和成本优化；应将协议兼容与语义兼容分开，将模型生成的工具调用提议与真实工具执行分开，将用量报告与最终账单分开。

对最小 Agent System 而言，一个具备超时、错误分类和基本计量的适配器就可能足够；当多个 Agent、多个团队或多种模型共用推理资源时，再逐步引入目录、路由、配额、故障切换和版本治理。设计的成熟度不取决于服务数量，而取决于其是否能够在明确任务、风险和环境约束下持续提供可解释的模型调用行为。

本篇为下一专题 「L4 · Agent 如何被驱动并持续执行任务？ - Agent Engine」 提供模型接口与调用语义基础。L4 将进一步研究如何把模型响应接入 Agent 的决策 - 行动循环、状态机、工具执行和停止机制；L3 不代替这些运行时职责。

附录 A：参考文献与原始资料入口

以下优先列出规范、官方文档与工程原始资料。访问时间为 2026 年 10 月 28 日；具体功能和价格具有版本时效性，使用前应重新核验。文中架构设计并非任何单一来源的原文标准。

1. OpenAI Agents SDK - Models：模型配置、Responses/Chat Completions、非 OpenAI 模型、混合提供商及能力差异。openai.github.io/openai-agents-python/models （本次检索核对）
2. OpenAI API - API Reference：模型请求与响应的原生契约。platform.openai.com/docs/api-reference （原始资料入口；本文未逐端点核验）
3. OpenAI API - Rate Limits：模型 API 限流与配额的官方说明。platform.openai.com/docs/guides/rate-limits （原始资料入口；实际配额以账户为准）
4. Anthropic API Documentation：消息、工具使用与错误处理的原生协议。docs.anthropic.com （原始资料入口；本文未逐端点核验）
5. Google Gemini API Documentation：多模态输入、模型调用与结构化输出。ai.google.dev/gemini-api/docs （原始资料入口；本文未逐端点核验）
6. LiteLLM Documentation：多提供商适配与代理服务。docs.litellm.ai （原始资料入口；本文未部署测试）
7. vLLM Documentation：开源模型推理与服务部署。docs.vllm.ai （原始资料入口；本文未部署测试）
8. OpenTelemetry Documentation：分布式追踪、指标与日志。opentelemetry.io/docs （原始资料入口）
9. AWS Builders' Library - Timeouts, retries, and backoff with jitter：超时、退避、重试风暴的工程原理。aws.amazon.com/builders-library/time...ackoff-with-jitter （原始资料入口）
10. NIST AI Risk Management Framework：AI 风险识别、治理和测量的框架参考。www.nist.gov/itl/ai-risk-management-framework （原始资料入口）

附录 B：研究证据、验证边界与后续实验

资料核验范围。 本次通过网络检索核对了 OpenAI Agents SDK 的 Models 官方文档，并以其支持的模型接口与跨提供商差异为框架对照依据。其余链接作为进一步研究的官方原始资料入口列出，未逐页核对其截至本文日期的全部细节。本文未依赖任何固定价格、配额或模型默认版本作出长期有效的断言。

概念与工程建议的性质。 文中的六层职责映射、逻辑 JSON Schema、模型目录字段、路由阶段、预算预约方法、事件类型、测试矩阵和发布门禁属于本知识库综合形成的工程参考设计，并非 OpenAI、Anthropic、Google 或其他组织发布的统一行业标准。

实验状态。 本篇未调用真实模型 API、未部署 LiteLLM/vLLM、未进行负载测试、故障注入、账单对账或跨供应商能力测试。Python 代码仅为接口草案，未声称执行通过。关于重试、并发、缓存和路由的结论是技术机制分析与设计约束，不是对某一生产环境的性能保证。

下一步可验证事项。 应建立固定版本的适配器测试套件，在沙箱中执行能力协商、工具调用、结构化输出、流式断连、429/5xx、取消、跨租户预算竞争、费用核算及模型切换回归；记录测试日期、供应商/模型/SDK 版本、输入快照、请求 ID、实际用量、判定器和失败证据。只有在完成这些测试后，才能对具体部署配置给出经验性可靠性结论。