前言
2025 年还在卷模型：上下文窗口谁长、跑分谁高、API 谁便宜。到了 2026 年，话题悄悄转了 ------ 模型之间的差距在收窄，真正卡住落地的，是模型上面那一层。
于是新概念一个接一个冒出来。Prompt Engineer 还没聊透，Context Engineer、Harness Engineer 又来了；Agent 刚有点搞明白，Agent Loop、Agent Runtime 又铺满了技术圈。名字越起越密，真动手搭过 Agent 的人反而越糊涂：这些词到底各自指什么？哪些是真要解决的问题，哪些只是旧东西换了个新壳？
这篇文章不追热点，就做一件事：把 Agent 运行时这条线上的核心概念拉出来，讲清楚它们各自解决什么问题、彼此是什么关系；再顺着 "从个人随手搭的 demo，到企业级 Agent 运行时" 这条路径，看看运行时到底该具备哪些基础组件。
最基础的 Agent Runtime
最基础的 Agent Runtime 核心由三部分构成：Model（模型）、Tool（工具）与 Agent Loop。
-
模型是智能体的大脑，是 Agent 执行任务的推理基础；
-
工具是 Agent 的手脚，作为 Agent 和外部世界交互的桥梁；
-
Agent Loop 是整套运行时的执行驱动机，可以简单理解为一次完整的Agent的会话是怎么执行的。如我们最熟悉的 ReAct，就是当前最通用的 Agent Loop 范式。
React
React 循环流程
一次完整的 React AgentLoop，就是一轮「思考 - 执行 - 观察反馈」的循环迭代。
| 阶段 | 做什么 |
|---|---|
| 思考 Thinking | 把当前上下文交给模型，模型决定下一步做什么（直接回答 or 调工具） |
| 行动 Action | 执行模型的决策：调用某个工具、输出文本、跳转分支 |
| 观察 Observation | 解析工具返回的结果，判断是否成功、是否需要继续 |
Plan-and-Execute
除 ReAct 之外，Plan-and-Execute 也是另一类主流的循环框架。
Plan-and-Execute 循环流程
| 阶段 | 核心动作 | 简要说明 |
|---|---|---|
| 规划 Planning | 一次性全局任务拆解 | 模型根据用户需求，提前生成完整有序的子任务清单，定义每一步目标、工具、任务依赖。✅【和 ReAct 最大区别：先出完整方案，再开始执行】 |
| 思考 Thinking | 基于当前子任务决策 | 读取计划里待执行子任务，结合历史结果，确定本轮动作 |
| 行动 Action | 执行工具调用 | 选定工具与参数，执行调用 |
| 观察 Observation | 校验子任务结果 | 接收工具返回，判断当前子任务是否完成；失败可重试 / 修改计划 |
| 循环校验 | 推进任务进度 | 子任务成功 → 进入下一个子任务，继续循环；子任务失败 → 重试或修正计划 |
React 和 Plan 模式对比
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 规划时机 | 无前置全局规划，每轮动态思考下一步动作 | 前置一次性全局规划，生成完整子任务清单后再执行 |
| 决策方式 | 边执行边思考，动态调整，没有固定步骤 | 按预定义子任务顺序执行，执行中可按需修正计划 |
| 适用场景 | 开放、不确定性高、任务步骤不可预判 | 长任务、多步骤、业务流程相对可预判的复杂任务 |
| 优点 | 灵活，遇到意外情况可随时调整思路 | 步骤可控、便于断点保存、方便人工查看整体方案 |
| 缺点 | 长任务容易偏离目标，迭代轮数不可控 | 前置规划容易一次性生成错误计划，后续全链路失效 |
简单来说，Agent Loop 负责调度模型与工具，不断迭代：把用户问题、历史上下文送入模型做思考，解析模型输出的工具调用指令，执行工具拿到返回结果，再将观测结果放回上下文，开启下一轮思考。循环会持续运转，直到模型判断信息足够、无需再调用工具，输出最终回答，会话结束。
这套最简 Runtime 足够支撑 Demo 级别的智能体。但它的短板也十分明显：没有持久记忆，上下文持续膨胀，工具异常、返回格式错误缺乏统一处理，缺少链路观测，很难直接迁移到企业生产场景。这些问题，也正是后续 Context 层、Harness、Agent Gateway 等组件需要解决的核心痛点。
标准模块化 Agent Runtime 架构
前文已经介绍了 Model、Agent Loop、Tool 三个基础组件，它们共同构成 Agent 的最小运行闭环：模型负责推理，Loop 负责循环调度，Tool 负责与外部环境交互。
但基础 Runtime 只能解决"能跑起来"的问题。面对复杂 Agent 场景时，还会遇到上下文窗口有限、记忆无法沉淀、长任务中断难恢复、执行过程黑盒等问题。因此，标准模块化 Agent Runtime 在基础组件之上，增加了四个核心增强模块：
-
Context Engineering：上下文工程
-
Memory：记忆系统
-
State：状态与持久化
-
Observability：可观测
它们不是替代 Model、Agent Loop、Tool，而是围绕基础 Runtime 提供工程化能力。
| 模块 | 一句话定位 | 解决的问题 | 与基础组件关系 |
|---|---|---|---|
| Context Engineering | 输入窗口管理器 | 本轮该给模型看什么 | 为 Model 准备 Prompt |
| Memory | Agent 知识库 | Agent 长期知道什么 | 为 Context 提供候选记忆 |
| State | Agent 进度条 | 执行到哪、如何恢复 | 为 Agent Loop 保存进度 |
| Observability | 监控仪表盘 | 为什么错、哪里慢、成本多少 | 横切所有组件 |
Context Engineering（上下文工程）｜输入窗口管理器
**核心定义：**专门负责每一轮"思考"阶段，给到模型的 Prompt 该如何组装、裁剪和压缩。它是一个独立工程域------Loop 只负责"拿组装好的上下文去问模型"，不关心 Prompt 是怎么拼出来的。
| 子能力 | 说明 |
|---|---|
| 组装 Assembly | 把系统提示词、用户问题、记忆片段、上一轮工具返回结果拼在一起，构成完整 Prompt。 |
| 裁剪 Trimming | 受限于模型 Token 上限，剔除过期、无关信息，保留高优先级内容，防止超限报错。 |
| 压缩 Compression | 对长对话、长工具返回结果做摘要压缩，缩减 Token 占用，避免上下文窗口溢出。 |
| RAG 检索 | 从知识库或长期记忆中召回相关片段，注入本轮 Prompt，补充外部知识。 |
为什么独立出来："往 Prompt 里塞什么"是一个独立的工程问题。如果让 Loop 自己拼 Prompt，随着对话变长、工具返回变复杂，Loop 会迅速被上下文管理逻辑淹没，主循环本身反而失去清晰度。
Memory（记忆系统）｜Agent 知识库
**核心定义：**持久存储 Agent 在交互中获取到的各类信息，分为短期会话记忆与跨会话长期记忆，提供写入、检索、遗忘更新三种能力。
| 类型 | 存储内容 | 举例 |
|---|---|---|
| 短期记忆 | 当前会话内的对话历史、本轮交互上下文 | "用户刚才要求查询天津天气" |
| 长期记忆 | 跨会话持久化存储，载体为向量库、KV 库、图数据库 | "用户偏好简洁回答""常住天津" |
关键策略：
-
**写入：**每轮交互结束后判断哪些信息值得长期保存，不是全量入库。
-
**检索：**Context 组装阶段，从记忆中捞出相关片段注入 Prompt。
-
**遗忘 / 更新：**清理过期信息，用新信息覆盖矛盾的旧信息。
易混区分：
Context：这一轮模型能看到哪些信息（临时视图）
Memory：Agent 知道哪些信息（存量知识库）
Memory 是仓库；Context 是本轮放到模型眼前的临时素材。
State（状态与持久化）｜Agent 进度条
最容易和 Memory/Context 混淆，
Memory 存内容，State 存执行进度
| 概念 | 回答问题 | 例子 |
|---|---|---|
| Memory | Agent 知道什么知识 | 用户住在天津 |
| Context | 本轮模型可见内容 | 当前 Prompt 包含的片段 |
| State | Agent 执行到哪一步 | 正在执行步骤 2，等待计算器返回结果 |
State 保存的具体内容：
-
当前执行到第几个节点 / 步骤
-
上一次工具调用的返回码、错误信息
-
是否在等待人工审批（HITL）
-
分支判断的选择结果、路由记录
-
任务 Checkpoint 快照（可恢复）
三大核心能力：
-
Checkpoint 断点续跑：长任务中断后，从快照恢复，无需从头执行
-
事件溯源 Event Sourcing：记录每一次状态变更，支持回放、调试
-
分布式一致性：多节点部署，保证同一个 Agent 实例状态不冲突
Observability（可观测）｜监控仪表盘
核心定义：全链路观测体系，解决 Agent 黑盒问题，让你知道每一步到底干了什么、为什么出错。
| 观测维度 | 查看内容 |
|---|---|
| Trace / Span | 一次完整请求的全链路步骤、每阶段耗时，串联整个 Agent Loop 流转 |
| 日志 | 工具调用入参返回、模型完整输入输出、异常堆栈 |
| Metrics 指标 | Token 消耗量、调用成功率、延迟、单次任务成本 |
| 回放 | 完整复现某次 Agent 执行流程，复现 bug 用于调试 |
没有可观测，Agent 就是黑盒------它给了一个错误答案，你无法区分是模型幻觉、工具返回错误，还是上下文组装环节出了问题。
四个模块在 Loop 中的位置
把四个增强模块叠回到基础三件套之上，它们与 Loop 的关系可以概括为：
| 模块 | 挂载在 Loop 的哪个阶段 | 解决裸 Loop 的什么问题 |
|---|---|---|
| Context Engineering | 思考阶段之前 | 对话变长后 Prompt 撑爆 Token、无关信息干扰模型 |
| Memory | 感知与思考阶段之间 | 每次会话都从零开始，记不住用户偏好和历史事实 |
| State | 贯穿 Loop 全程 | 长任务中断后全部丢失，必须从头重跑 |
| Observability | 挂在所有阶段外部 | 出错是黑盒，分不清是模型、工具还是上下文的锅 |
一句话总结 ：裸 Loop 是"自行车"，加上这四个模块才是"汽车"------有仪表盘（Observability）、有油箱记忆（Memory）、有里程表（State）、有变速箱（Context Engineering），才敢开上生产这条高速。
企业级 Agent Runtime：从单 Agent 到多 Agent、多租户与合规
前面七个标准模块------Agent Loop、Model、Tool、Context Engineering、Memory、State、Observability------已经能让单 Agent 在生产环境稳定运行。但在企业内部落地时，还会遇到三类绕不开的问题：
-
多 Agent 协作：一个任务需要多个 Agent 分工完成。
-
多租户使用：不同部门、不同客户共享同一套 Runtime。
-
安全与合规：代码不能乱执行，数据不能越权，审计必须可追溯。
因此，在标准模块化 Runtime 之上，再叠加四个企业级模块：Orchestration（编排）、Sandbox（沙箱）、Security（安全与合规）、Resource Scheduling（资源调度）。它们分别解决"调度得动、关得住、守得严、算得清"。
一次典型的企业级调用可以理解为：
Security 鉴权与租户识别 → Orchestration 拆解与路由 → Resource 分配配额与沙箱 → Agent Loop 执行 → Tool Runtime 调工具 → Sandbox 执行不可信代码 → Memory/State 读写 → Observability 监控、Security 审计。
四个企业级模块不是替代前七个标准模块，而是叠加在它们之上。
Orchestration（编排层）｜多 Agent 的"指挥中心"
核心定义：当任务复杂到单个 Agent 搞不定时，Orchestration 负责把大任务拆成子任务、分配给多个 Agent 并行或串行执行、汇总结果、处理 Agent 之间的通信与异常。它本身不做"思考"，只做"调度"。
| 子能力 | 说明 |
|---|---|
| 任务拆解 Decomposition | 把用户的大目标，如"做一份行业分析报告"，拆成可由不同 Agent 执行的子任务：数据搜集、竞品分析、报告撰写。 |
| Agent 注册与路由 | 维护 Agent 清单：每个 Agent 擅长什么、有哪些工具、当前负载、健康状态和版本；决定子任务分给谁。 |
| 编排模式 | 常见模式包括：串行流水线 A→B→C、并行扇出、主次协作 Planner-Worker、人工兜底 HITL。 |
| 状态同步 | 多个 Agent 共享上下文，上游输出作为下游输入，协调 State 快照，避免各跑各的。 |
| 异常与重试 | Worker Agent 失败时，决定重试、换 Agent 兜底，还是升级给人工；必要时引入幂等、补偿、熔断和降级。 |
和 Agent Loop 的区别：Loop 是单个 Agent 内部的"感知→思考→行动"循环；Orchestration 是多个 Agent 之间的任务调度。Loop 是发动机，Orchestration 是车队调度中心。
落地建议：先做 Agent 注册表、状态同步和异常重试；编排模式从串行、并行开始，再引入 Planner-Worker 和 HITL。
Sandbox（沙箱）｜不可信代码的"隔离间"
核心定义：Agent 的工具里经常包含"执行代码"类能力，如 Python、Shell、数据库查询。这些代码由模型生成，理论上不可信。Sandbox 负责把这类代码丢到隔离环境里运行，限制它能碰什么资源、能访问什么网络。即使代码有 bug 或被注入恶意指令，也炸不到宿主系统。
| 隔离维度 | 说明 |
|---|---|
| 文件系统隔离 | 代码只能读写指定临时目录，不能访问宿主机 /etc、用户目录、其他租户数据。 |
| 网络隔离 | 默认禁止外网访问；确需联网时走白名单代理，限制可访问域名，防止数据外带。 |
| 资源配额 | 限制 CPU、内存、执行时长，如 30 秒超时、最大输出体积，防止死循环或打满机器。 |
| 权限降级 | 以非 root 用户运行，禁止调用系统敏感 API，不能起新进程、不能改系统配置。 |
| 会话隔离 | 每次代码执行用独立容器或 microVM，执行完即销毁；不同 Agent、不同租户互不可见。 |
常见实现方式：轻量场景用 Docker 容器；更强隔离用 gVisor、Firecracker、microVM、Wasm；浏览器侧可用 iframe + Web Worker。隔离越强，启动开销越大，需要按场景权衡。
边界：Sandbox 管的是"代码执行时不闯祸"；Security 管的是"代码和工具调用前、调用后都守规矩"。
Security（安全与合规）｜企业的"门禁与审计"
核心定义：解决"谁能用这个 Agent、能调哪些工具、能碰哪些数据、出了事能不能查"的问题。
| 子能力 | 说明 |
|---|---|
| 身份认证 AuthN | 谁在调用这个 Agent？基于企业 SSO、OAuth、API Key 确认调用者身份。 |
| 权限控制 AuthZ | 这个用户或 Agent 能调哪些工具、访问哪些知识库、操作哪些数据。基于 RBAC / ABAC 做细粒度授权。 |
| 多租户隔离 | 不同租户，如部门、客户的 Memory、State、知识库、工具凭证互相隔离，A 租户看不到 B 租户数据。 |
| 数据脱敏与加密 | 进 Prompt 前对手机号、身份证、银行卡等敏感字段脱敏；落盘 Memory、State 做静态加密；传输走 TLS。 |
| 内容安全 | 对用户输入和模型输出做敏感词、越权指令、Prompt 注入检测，拦截违法或违规内容。 |
| 审计日志 | 谁、在什么时间、让 Agent 做了什么、调了哪个工具、返回了什么，全程留痕，满足等保与合规审计要求。 |
和 Observability 的区别：Observability 是研发视角的"排错监控"，看性能、看链路；Security 是合规视角的"门禁与审计"，看权限、看留痕。两者都产日志，但用途不同。
合规补充：面向等保、GDPR、SOC 2 等要求时，通常还需要数据分级、密钥管理、策略命中记录和租户级审计导出。
Resource Scheduling（资源调度）｜企业的"车队调度"
核心定义：当 Runtime 上同时跑着成百上千个 Agent 实例、成百上千个沙箱容器、成千上万次模型调用时，Resource Scheduling 负责把合适的资源分给合适的任务，让整体不浪费、不超限、不互相抢。
| 子能力 | 说明 |
|---|---|
| 模型配额与限流 | 按租户、Agent、用户分配模型 Token 配额；超配额时排队、降级或拒绝，防止一个大客户打满模型额度。 |
| 沙箱资源池 | 预热一批容器或 microVM 做成资源池，Agent 要用时直接取用，用完归还，避免每次冷启动开销。 |
| 弹性伸缩 | 高峰时自动扩容 Runtime 节点和沙箱池，低谷时缩容省钱；可与 K8s 等编排基础设施对接。 |
| 成本核算 | 记录每个租户、每个 Agent 消耗的 Token、沙箱时长、工具调用次数，算清账单，支持内部结算。 |
| 优先级与抢占 | 高优任务优先拿资源；低优后台任务可被抢占，保障核心 SLA。 |
落地建议：先做配额、限流和成本归集；再做沙箱池化、弹性伸缩和优先级抢占。
企业级四模块 vs 解决的问题
| 模块 | 解决的企业级问题 | 典型痛点 |
|---|---|---|
| Orchestration | 多 Agent 协作 | 一个任务要查资料、做分析、写报告，单 Agent 干不完也干不好。 |
| Sandbox | 不可信代码执行 | 模型生成的 Python / Shell 不能直接在宿主机跑，怕删库、怕外带数据。 |
| Security | 多租户隔离、权限、合规审计 | A 部门不能看到 B 部门数据；操作要留痕；敏感字段不能进 Prompt。 |
| Resource Scheduling | 大规模多租户下的资源与成本 | 高峰打满模型配额；沙箱冷启动慢；账单算不清。 |
三层能力分级总览
| 层级 | 目标 | 包含模块 |
|---|---|---|
| Demo 级 | 跑通就行 | Agent Loop + Model Gateway + Tool Runtime |
| 标准生产级 | 单 Agent 稳定可用 | + Context Engineering + Memory + State + Observability |
| 企业级 | 多 Agent、多租户、合规 | + Orchestration + Sandbox + Security + Resource Scheduling |
企业级 Agent Gateway：统一入口、模型路由与工具治理
单 Agent Demo 阶段，Agent 往往直连模型、直连工具、直连内部 API。跑通没问题，但一进企业生产环境就会暴露问题：
| 问题 | 典型表现 | Gateway 的价值 |
|---|---|---|
| 入口分散 | 每个 Agent 自己配模型 Key、自己调工具 API | 统一入口，集中管控 |
| 厂商绑定 | 换模型、换工具要改 Agent 代码 | 协议适配，屏蔽差异 |
| 安全失控 | 越权调工具、敏感数据进 Prompt、无审计 | 鉴权、脱敏、注入检测、审计 |
| 流量失控 | 单 Agent 打满模型配额、疯狂调第三方 API | 限流、熔断、重试、降级 |
| 成本不清 | Token 消耗、工具调用、租户账单算不清 | 计量、配额、成本归集 |
| 排错困难 | 模型、工具、Agent 日志散落各处 | 全链路 Trace、统一日志 |
所以企业级 Agent 的对外数据流交互部分，通常会引入一个专门的网关层，保证流量安全、可控、可计量、可审计、可治理。
常见企业级 Agent 构造的网关层包括：
-
全局网关层：统一入口 + 安全审计 + 流量治理。
-
Model Gateway：模型调用统一入口。
-
MCP Gateway：工具 / 服务调用统一入口。
可以用一句话理解三层网关的位置：
外部请求先过全局网关；
进入 Agent Runtime 后，模型流量走 Model Gateway，工具流量走 MCP Gateway。
全局网关层
定位
全局网关层是企业级 Agent 的统一前置入口。所有进出 Runtime 的流量，包括 Agent 会话请求、模型调用、工具调用，都可以先经过它，统一做身份、权限、内容安全、脱敏和审计留痕。
子能力
| 子能力 | 说明 |
|---|---|
| 身份认证 AuthN | 统一 SSO、API Key、JWT 校验，识别调用者是谁：用户 / 租户 / Agent 实例。 |
| 访问鉴权 AuthZ | 基于 RBAC / ABAC 判断主体能不能访问 Agent、模型、工具、知识库。 |
| 租户识别与隔离 | 识别请求属于哪个租户，后续 Memory、State、知识库、工具凭证按租户隔离。 |
| Prompt 注入防护 | 检测输入 Prompt 的注入、越狱、越权指令，在请求到达模型或工具前拦截。 |
| 内容安全过滤 | 对用户输入、模型输出做内容审核，拦截违规内容。 |
| 数据脱敏 | 请求转发前自动脱敏手机号、身份证、银行卡等敏感信息，防止敏感数据流入模型或工具。 |
| 全流量审计日志 | 记录调用主体、时间、请求载荷、响应、错误码，满足合规审计要求。 |
| 路由与分流 | 把请求分发到 Agent Runtime、Model Gateway 或 MCP Gateway。 |
| 限流与配额 | 在入口层做租户级、用户级、Agent 级限流，配合 Resource 调度。 |
Model Gateway（模型网关）
定位
Model Gateway 是大模型服务的接入网关，是 Agent 调用 LLM 的统一入口。它放在执行层，负责 Agent Loop 和底层模型服务之间的流量管理。
子能力
| 子能力 | 说明 |
|---|---|
| 多模型路由 | 根据任务复杂度路由到不同模型：简单任务小模型，复杂推理大模型，做成本优化；支持模型降级切换。 |
| 协议适配 | 统一接口，屏蔽 OpenAI、通义、DeepSeek 等不同厂商 API 差异，上层 Agent 不用改代码就能切换模型。 |
| Token 计量与成本统计 | 统计输入输出 Token，按租户 / Agent 维度统计消耗，用于计费、成本核算。 |
| 限流、熔断、重试 | 模型超时、报错自动重试；防止单 Agent 打满模型配额；后端模型故障自动切备用模型。 |
| 流式输出封装 | 统一封装 SSE 流式返回，上层 Agent 不用关心不同模型流式格式差异。 |
| 前置审计 / 日志 | 模型调用入参、返回、调用者身份提前埋点，交给 Observability 和 Security 审计。 |
| 缓存与降级 | 对重复 Prompt、相似请求做缓存；高负载时按策略降级到小模型或排队。 |
| Prompt 模板与版本 | 可集中管理 Prompt 模板、版本和灰度策略，避免 Prompt 散落在各 Agent 中。 |
边界
Model Gateway 只管模型流量。它不负责工具调用，也不替代全局安全审计。企业级场景下，它可以接受全局网关层的安全切面，也可以内嵌轻量安全能力。
MCP Gateway（MCP 工具网关）
定位
MCP Gateway 是所有 MCP 工具服务的统一接入网关，是 Agent 访问各类工具的前置入口，挂载在 Tool Runtime 之前。
子能力
| 子能力 | 说明 |
|---|---|
| MCP 协议路由 | 统一管理所有 MCP 服务，Agent 只访问网关，网关转发到对应 MCP Server：数据库工具、文件工具、API 工具等。 |
| 工具注册与发现 | 统一维护工具清单、工具 Schema，集中管控哪些工具可以被哪些 Agent 调用。 |
| 协议转换 | 兼容 MCP 协议，同时对接原生 OpenAPI，把普通 API 包装成 MCP 接口，对 Agent 透明。 |
| 工具调用鉴权 | 校验当前 Agent / 租户有没有权限调用这个工具，在调用前拦截越权请求。 |
| 调用限流与超时控制 | 限制工具调用 QPS，防止 Agent 疯狂调用第三方 API；统一超时管理。 |
| 调用审计记录 | 记录每一次工具调用：调用方、入参、返回结果、耗时，供安全审计和可观测使用。 |
| 工具版本与灰度 | 管理工具版本、Schema 变更和灰度发布，避免工具升级直接打挂 Agent。 |
| 结果脱敏与过滤 | 工具返回结果中的敏感字段可在网关层脱敏或过滤，再交给 Agent。 |
边界
MCP Gateway 只管工具和服务调用流量。它不负责模型路由，也不替代全局安全审计。它更适合解决"工具怎么统一接、权限怎么统一管、调用怎么统一审计"的问题。
三类网关的关系与边界
| 网关 | 管什么 | 不管什么 | 数据流位置 | 对应层级 |
|---|---|---|---|---|
| 全局网关层 | 统一入口、身份、权限、租户、脱敏、内容安全、审计、限流 | 不具体管模型路由和工具协议转换 | 外部请求 → 全局网关 → Runtime / Model / MCP | 企业级 Security + Resource + Observability |
| Model Gateway | 模型路由、协议适配、Token 计量、模型限流熔断、流式封装 | 不管工具调用、不替代全局审计 | Agent Loop → Model Gateway → LLM | 标准生产级 + 企业级成本治理 |
| MCP Gateway | 工具注册、协议路由、工具鉴权、工具限流、调用审计 | 不管模型调用、不替代全局审计 | Agent Loop → Tool Runtime → MCP Gateway → MCP Server | Tool Runtime 的企业级扩展 |
三者不是三选一，而是通常组合使用：
-
标准生产级：Model Gateway + MCP Gateway + 内嵌安全切面。
-
企业级：全局网关层 + Model Gateway + MCP Gateway + 资源配额 / 审计联动。
-
轻量场景：先做 Model Gateway，工具少时暂不拆 MCP Gateway。
-
多租户 / 合规场景：必须做全局网关层，统一租户识别、鉴权和审计。