Agent基础架构平台（上）：从全景架构到核心层设计
Agent 基础架构平台（上）：从全景架构到核心层设计
让一个 Agent 跑通 demo 是下午茶的事；让一百个 Agent 在生产环境中稳定、安全、经济地运行，是一个平台工程问题。本文不讨论 Agent 怎么写，而是讨论 Agent 在什么上面跑。
1. 引言：为什么需要 Agent 基础架构平台
1.1 Agent 开发 ≠ Agent 运营
大多数 Agent 教程的终点是一个能跑通的 demo：配置好 Prompt，接入几个工具，LLM 能做出合理的决策并完成任务。但从 demo 到生产，从一个 Agent 到一百个 Agent，中间隔着的不是"更多的 Agent 代码"，而是一整套基础架构平台。
一个有意思的类比：早期互联网公司的后端开发，每个团队各自搭建 Web 框架、各自管理数据库连接、各自实现日志系统。后来演化出了统一的微服务平台——服务注册发现、配置中心、API 网关、链路追踪、容器编排——开发者只需关注业务逻辑，基础设施由平台统一提供。
Agent 领域正在经历同样的演进。当前许多团队的做法是：每个 Agent 项目自己管理 LLM 调用、自己实现会话存储、自己处理工具调用、自己搭建监控——大量重复建设，且质量参差不齐。Agent 基础架构平台的价值，正是要把这些共性需求抽象出来，成为可复用的基础设施。
1.2 典型演进路径
Agent 基础设施通常经历三个阶段：
阶段一：脚本化
一个 Python 脚本直接调用 OpenAI API
对话历史存在内存里
工具调用硬编码在代码中
↓ 问题：不可维护、不可监控、不可扩展
阶段二：单体服务化
包装成 Web 服务，对外提供 API
用 Redis 存会话，用 PostgreSQL 存日志
有了基础的错误处理和超时控制
↓ 问题：Agent 间大量重复代码、无法统一治理
阶段三：平台化
统一的 LLM 网关、工具服务、记忆存储
Agent 以配置化方式注册和部署
平台层提供监控、限流、灰度、审计等能力
开发者专注于 Agent 的 Prompt 和业务逻辑
本文聚焦的正是第三阶段：当组织内需要运行多个 Agent，面向多个业务场景，服务多租户时，如何设计和构建一个支撑 Agent 规模化运行的基础架构平台。
1.3 本文的定位与结构
本文分上下两篇。上篇（本文）从宏观架构全景出发，深入四大核心层——接入层、调度层、运行时层、能力层——的设计原理与工程实践。下篇将聚焦运维侧：弹性伸缩、可观测性、安全治理、测试保障和平台演进路径。
需要说明的是，Agent 基础架构平台并非一个全新的事物。它大量复用了微服务平台、Serverless 平台和流处理平台的成熟模式。本文会着重分析 Agent 场景下的特殊性——那些使得传统基础设施方案"不够用"或"需要变通"的地方。
2. 平台全景架构
2.1 分层架构总览
一个完整的 Agent 基础架构平台可以抽象为五层：
┌─────────────────────────────────────────────────────┐
│ 接入层 Access Layer │
│ API Gateway / WebSocket / SSE │
│ 认证鉴权 / 协议适配 / 流量治理 │
├─────────────────────────────────────────────────────┤
│ 调度层 Orchestration Layer │
│ Agent Registry / Scheduler / Router │
│ 多租户 / 生命周期 / 灰度发布 │
├─────────────────────────────────────────────────────┤
│ 运行时层 Runtime Layer │
│ Agent Runtime / Sandbox / Session Manager │
│ 上下文管理 / 执行沙箱 / 超时熔断 │
├─────────────────────────────────────────────────────┤
│ 能力层 Capability Layer │
│ LLM Gateway / Tool Service / Memory Store │
│ Prompt 管理 / Embedding / 知识检索 │
├─────────────────────────────────────────────────────┤
│ 基础设施层 Infrastructure Layer │
│ K8s / MQ / Redis / VectorDB / Object Storage │
│ GPU 集群 / 网络 / 存储 / 安全 │
└─────────────────────────────────────────────────────┘
自上而下：接入层负责面向外部的协议适配和流量管理；调度层负责 Agent 的注册、路由和生命周期管理；运行时层负责 Agent 的实际执行、状态管理和安全隔离；能力层提供 Agent 运行所需的共享基础能力；基础设施层是底层的计算、存储和网络资源。
各层之间遵循单向依赖原则：上层依赖下层，下层不感知上层。这种分层不是为了画图好看，而是为了实现关注点分离——每一层可以独立演进和替换。
2.2 与传统微服务平台的核心差异
在深入各层设计之前，有必要先理解 Agent 平台与传统微服务平台的本质差异，因为这些差异直接决定了架构设计的关键决策。
差异一：长会话 vs 短请求
传统微服务处理的是无状态的短请求：一个 HTTP 请求进来，几十毫秒到几百毫秒返回，请求之间无关联。Agent 的交互模式是长会话：一次会话可能包含数十轮对话，持续几分钟到几小时，每一轮的决策依赖于之前所有轮次的上下文。
这意味着：会话状态必须持久化和管理；负载均衡需要支持会话亲和性；资源的分配和回收粒度从"请求级"变为"会话级"。
差异二：非确定性 vs 确定性
传统服务的执行路径是确定性的——相同输入总是产生相同输出，你可以通过代码审查推断行为。Agent 的核心是 LLM 推理，同一个输入可能产生不同的工具调用序列、不同的执行路径、不同的结果。一次请求可能走 2 轮循环，也可能走 8 轮。
这意味着：资源消耗不可预测，需要更灵活的超时和限流策略；排障不能只靠日志，需要完整的运行时追踪；质量保障不能只靠单元测试，需要统计性的评估体系。
差异三：Token 经济 vs 计算经济
传统服务的成本主要是 CPU 和内存——可以通过加机器线性扩展，单位成本基本固定。Agent 的主要成本是 LLM 的 Token 消耗——API 调用按 Token 计费，且价格差异巨大（GPT-4 与 GPT-3.5 相差 20-60 倍）。
这意味着：流控的核心维度从 QPS 变为 TPM（Tokens Per Minute）；成本优化不是省机器，而是省 Token——Prompt 压缩、模型路由、缓存命中率成为关键指标；预算管理需要精确到单次调用级别。
差异四：工具调用带来的安全边界
传统服务调用下游 API 是开发者在编码时确定的——调什么接口、传什么参数，都在代码中写死。Agent 的工具调用是 LLM 在运行时动态决策的——调哪个工具、传什么参数，取决于 LLM 的推理结果。
这意味着：工具调用需要沙箱隔离和权限控制；参数需要运行时校验，不能信任 LLM 的输出；敏感操作需要人工审批机制。
理解了这四个核心差异，我们才能理解后续每一层设计中那些"看似过度设计"的地方，其实都是在应对这些本质性的挑战。
3. 接入层：面向外部的高性能入口
接入层是平台面向外部世界的门面，负责接收请求、协议适配、认证鉴权和流量治理。Agent 场景下的接入层有几个独特挑战：长连接管理、流式响应、大超时和 Token 维度的流控。
3.1 协议选择与流式响应架构
Agent 的交互模式与传统 REST API 有本质不同。用户发送一条消息后，Agent 的响应不是瞬时返回的——它需要经过多轮 LLM 推理和工具调用，整个过程可能耗时数十秒。如果用传统的 HTTP 请求-响应模式，用户会面对一个漫长的空白等待。
因此，Agent 平台几乎都采用流式响应架构。主流有三种协议选择：
┌──────────────┬──────────────┬──────────────┬──────────────────┐
│ 协议 │ 方向 │ 连接模式 │ 适用场景 │
├──────────────┼──────────────┼──────────────┼──────────────────┤
│ HTTP + SSE │ 单向推送 │ 长连接 │ 大多数 Agent API │
│ WebSocket │ 双向通信 │ 长连接 │ 交互式会话 │
│ gRPC Stream │ 双向流 │ 长连接 │ 内部服务间通信 │
└──────────────┴──────────────┴──────────────┴──────────────────┘
SSE（Server-Sent Events）是目前最常见的选择：客户端发起 HTTP 请求，服务端通过 SSE 逐步推送 Agent 的输出——包括 LLM 的流式文本、工具调用的中间状态和最终结果。SSE 的优势在于基于标准 HTTP，与现有基础设施（CDN、API Gateway、负载均衡器）兼容性好。
WebSocket 适合需要双向实时交互的场景，比如用户需要在 Agent 执行过程中随时中断或提供额外输入。但 WebSocket 与很多 API Gateway 和 CDN 的兼容性较差，运维成本更高。
流式响应架构需要处理几个关键问题：
背压控制：当客户端消费速度低于服务端产生速度时，需要流控机制避免内存溢出。常见做法是在服务端维护一个有界缓冲区，当缓冲区满时暂停 LLM 推理流的消费。
断线重连：长连接不可避免会断开——网络波动、客户端切后台、负载均衡器超时。断线重连的设计要点是：服务端为每个 SSE 流分配唯一的 stream_id 和递增的 event_id；客户端重连时携带 Last-Event-ID；服务端从该位置恢复推送，已推送的事件需要在 Redis 或消息队列中缓存一段时间。
Client Server
│ │
│─── SSE Connect ─────────────>│
│ │ stream_id: s_001
│<── event_id: 1, token: "你" ─│ 缓存 event 到 Redis
│<── event_id: 2, token: "好" ─│ TTL = 5min
│ │
│ ✕ 连接断开 │
│ │
│─── Reconnect ───────────────>│
│ Last-Event-ID: 2 │
│ │ 从 event_id: 3 恢复
│<── event_id: 3, token: "，" ─│
│<── event_id: 4, tool_call:.. │
│ ... │
多路复用：一个客户端可能同时与多个 Agent 进行会话。为避免为每个会话建立独立的长连接，可以通过单连接多路复用——在事件中携带 session_id 进行区分。
3.2 API Gateway 的特殊考量
传统的 API Gateway（Kong、Envoy、APISIX）默认面向短请求设计：超时通常在秒级，请求体在 KB 级，不需要处理流式响应。Agent 场景下，这些默认配置几乎都需要调整。
超时配置：一次 Agent 执行可能需要 30 秒到数分钟。如果网关的默认超时是 30 秒，Agent 还没执行完就被断开了。需要将网关的 read timeout 和 idle timeout 设置为远大于 Agent 最大执行时间的值——但又不能设置为无限大，否则恶意或异常请求会耗尽连接资源。
推荐的做法是分层超时：网关层设一个较大的最大超时（比如 5 分钟）作为兜底，运行时层设一个更精细的每轮超时（比如 30 秒/轮、最多 10 轮），以及总执行超时。
请求体大小：Agent 的请求可能携带大量上下文——对话历史、文件内容、长文档。默认 1MB 的请求体限制很可能不够。需要适当放大，同时在网关层对过大的请求进行拒绝和告警。
连接管理：SSE 长连接会长时间占用网关的连接槽。如果网关连接池配置不够大，少量长会话就能耗尽连接资源，影响其他正常请求。需要单独配置 Agent 相关路由的最大连接数，并监控连接使用率。
健康检查：传统的 HTTP 健康检查用短请求探测后端是否存活。但 Agent 服务可能处于"活着但过载"的状态——能响应健康检查但无法接受新任务。更好的做法是健康检查中包含当前负载信息（活跃会话数、排队请求数），网关据此做智能路由。
3.3 认证鉴权与多租户入口
Agent 平台通常服务于多个业务方（租户），接入层需要在请求入口完成租户识别和认证鉴权。
Request
│
├── API Key / OAuth Token
│ └── 识别租户身份
├── Tenant ID
│ └── 确定资源配额
├── Agent ID
│ └── 路由到目标 Agent
└── Session ID（可选）
└── 恢复会话上下文
认证方案的选择需要平衡安全性和便利性。对外部接入（开放 API），API Key + HMAC 签名是主流方案；对内部服务间调用，可以用 mTLS 或服务网格的身份机制。
关键原则是：认证在接入层完成，调度层及以下不再处理认证逻辑。接入层将认证结果转化为标准化的上下文信息（租户 ID、权限列表、配额信息），注入到请求上下文中向下传递。
3.4 Token 维度的流量治理
这是 Agent 平台接入层最独特的设计点。传统的流量治理以 QPS（每秒请求数）为核心维度——一个请求消耗的资源大致相同，限制请求频率就能保护系统。
但在 Agent 平台中，同一个请求的资源消耗可能相差百倍：一个简单的问答消耗 500 Token，一个复杂的多步推理任务可能消耗 50000 Token。仅限制 QPS 无法有效保护模型资源——10 个"重请求"可能比 1000 个"轻请求"消耗更多的 Token 预算。
因此，Agent 平台需要双维度流控：QPS 限流保护接入层和调度层，TPM（Tokens Per Minute）限流保护模型资源和预算。
TPM 流控的实现比 QPS 流控复杂，因为一个请求的 Token 消耗在请求开始时是未知的——只有 LLM 执行完毕才知道实际消耗了多少 Token。
一种实用的方案是预估+事后结算：
1. 请求进入时：
- 根据输入长度和 Agent 类型估算 Token 消耗（简单 Agent 系数 2x，复杂 Agent 系数 5x）
- 检查租户的 TPM 余额是否足够
- 预扣预估量，允许请求通过
2. 执行过程中：
- 实时累加实际消耗的 Token 数
- 如果超出预估量的阈值（如 150%），触发告警或终止执行
3. 请求完成后：
- 用实际消耗量替换预估量
- 更新租户的 TPM 使用记录
- 动态调整该 Agent 类型的预估系数
这种机制类似信用卡的授权和结算：先预授权一个金额，交易完成后按实际金额结算。
一句话：Agent 平台的接入层难点不在"接"，在于长连接管理和 Token 维度的流量治理——传统网关的默认配置几乎全要改。
4. 调度层：多 Agent 的平台化管理
调度层是 Agent 平台从"跑一个 Agent"跨越到"管一群 Agent"的关键。它负责 Agent 的注册与发现、生命周期管理、路由调度和多租户隔离。如果说接入层是平台的大门，调度层就是平台的大脑。
4.1 Agent Registry：注册中心
Agent Registry 是调度层的核心组件，管理平台上所有 Agent 的元数据。与微服务的服务注册中心（如 Nacos、Consul）类似但有所不同，Agent Registry 除了管理服务实例的地址和健康状态，还需要管理 Agent 特有的属性。
一个 Agent 的注册信息通常包含：
# Agent 注册元数据示例
agent:
id: "agent-customer-support-v2"
name: "客服助手 V2"
version: "2.3.1"
status: "active" # active / canary / deprecated / disabled
# Agent 配置
config:
model: "gpt-4o" # 使用的模型
max_turns: 10 # 最大对话轮次
max_tokens_per_turn: 4096
temperature: 0.7
system_prompt_ref: "prompt://customer-support/v2.3"
tools: # 声明依赖的工具
- "tool://order-query"
- "tool://refund-process"
- "tool://knowledge-search"
# 资源需求
resources:
memory: "512Mi"
cpu: "0.5"
max_concurrent_sessions: 100
# 路由规则
routing:
tenants: ["tenant-a", "tenant-b"]
traffic_weight: 80 # 灰度流量百分比
fallback_agent: "agent-customer-support-v1"
# 健康状态（运行时更新）
health:
instances: 3
active_sessions: 47
avg_latency_p95: 3200ms
last_heartbeat: "2026-03-27T10:30:00Z"
Registry 的存储选型取决于规模。小规模（<100 Agent）用 Redis 或 etcd 即可满足需求；中等规模（100-1000 Agent）可以用 PostgreSQL + 缓存层；大规模（>1000 Agent）需要专门的元数据服务，支持分片和多区域复制。
Registry 需要支持几个核心操作：注册与注销、配置更新与热生效、版本管理与回滚、健康状态上报与查询。其中"配置更新与热生效"对 Agent 平台尤为重要——Prompt 的修改、模型版本的切换、工具列表的调整，都需要在不重启服务的情况下即时生效。
4.2 多租户隔离
当平台同时服务于多个业务方时，租户间的隔离是刚性需求。隔离需要在多个层面实施：
资源隔离：每个租户分配独立的资源配额——最大并发会话数、每分钟 Token 上限、每月 Token 总额、可用 Agent 列表。配额的设计需要区分硬限制（不可突破）和软限制（可临时超出但触发告警）。
┌─────────────────────────────────────────────────┐
│ 资源配额模型 │
├──────────────┬──────────────┬───────────────────┤
│ 维度 │ 硬上限 │ 软上限 │
├──────────────┼──────────────┼───────────────────┤
│ 并发会话数 │ 200 │ 150 (触发告警) │
│ TPM │ 500K tokens │ 400K (触发限速) │
│ 月度 Token │ 50M tokens │ 40M (通知管理员) │
│ 单次执行 │ 100K tokens │ 50K (触发审查) │
│ 工具调用/分 │ 100 次 │ 80 次 │
└──────────────┴──────────────┴───────────────────┘
数据隔离：不同租户的对话数据、日志、向量索引必须严格隔离。实现方式有两种——逻辑隔离（共享存储，通过 tenant_id 字段过滤）和物理隔离（独立数据库/命名空间）。对于安全要求高的租户，应提供物理隔离选项。
模型隔离：不同租户可能使用不同的模型和模型配额。某个租户的请求不应该因为占满了模型供应商的速率限制而影响其他租户。这要求 LLM Gateway 层能够实现租户级别的请求排队和速率控制。
4.3 Agent 生命周期管理
一个 Agent 从创建到下线，经历完整的生命周期。平台需要提供标准化的流程和工具来管理这个生命周期。
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌───────┐
│ 创建 │────>│ 配置 │────>│ 测试 │────>│ 发布 │────>│ 运行 │
└──────┘ └──────┘ └──────┘ └──────┘ └───┬───┘
│
┌──────┐ ┌──────┐ │
│ 下线 │<────│ 回滚 │<──┘
└──────┘ └──────┘
创建阶段：开发者通过 SDK 或管理界面定义 Agent 的基本信息——名称、描述、系统 Prompt、使用的模型、依赖的工具、资源需求等。平台生成唯一的 Agent ID 和初始配置。
配置阶段：配置 Agent 的运行参数——模型参数（temperature、max_tokens）、对话策略（最大轮次、超时时间）、路由规则（服务哪些租户、流量权重）等。所有配置通过配置中心管理，支持版本化。
测试阶段：在 Staging 环境运行 Agent，使用预定义的测试用例（golden dataset）验证 Agent 的行为是否符合预期。这一步是质量保障的第一道防线，会在下篇详细展开。
发布阶段：Agent 的发布通常采用灰度策略，不会一次性切换全量流量。
运行阶段：Agent 在生产环境中接受请求。平台持续监控其健康状态、性能指标和质量指标。
回滚与下线：当发现问题时，可以快速回滚到上一个稳定版本。Agent 不再需要时，走下线流程——停止路由流量、等待存量会话结束、清理资源。
4.4 灰度发布与动态路由
Agent 的灰度发布比传统服务更为重要，因为 Agent 的行为是非确定性的——即使通过了测试，新版本在面对真实流量时也可能表现不同。
Agent 平台的灰度发布通常有三种策略：
按流量比例灰度：最基本的方式，将一定比例的新请求路由到新版本。比如先放 5% 流量到 V2，观察 1 小时后扩大到 20%，最终全量切换。
按租户灰度：先在特定租户（通常是内部租户或合作较深的外部租户）上发布新版本，收集反馈后再向其他租户推广。
按场景灰度：对于同一个 Agent 的不同使用场景（如不同类型的用户问题），可以选择性地在某些场景上切换到新版本。
动态路由的实现通常基于路由规则引擎：
路由规则示例：
1. 如果 tenant_id == "internal"
→ 路由到 agent-v3-canary
2. 如果 request.metadata.scenario == "simple_qa"
→ 按权重分配：80% agent-v2-stable, 20% agent-v3-canary
3. 默认
→ 路由到 agent-v2-stable
路由规则存储在配置中心（如 Nacos、Apollo），支持动态更新，无需重启服务即可调整路由策略。路由决策在调度层的 Router 组件中执行，每次请求进入时评估规则链，决定路由到哪个 Agent 版本。
4.5 配置中心与 Prompt 版本化
Agent 平台的配置中心除了管理传统的应用配置外，还需要特别管理两类 Agent 特有的配置：Prompt 和工具列表。
Prompt 版本化是一个经常被低估的需求。在 Agent 系统中，Prompt 不是"一段文字"，而是"核心业务逻辑"——它决定了 Agent 的行为模式。Prompt 的修改等同于代码的修改，需要同等级别的版本管理和发布流程。
Prompt 版本管理模型：
prompt://customer-support/
├── v1.0 (deprecated) 创建时间: 2026-01-15
├── v2.0 (deprecated) 创建时间: 2026-02-01
├── v2.1 (stable) 创建时间: 2026-02-20 ← 当前生产版本
├── v2.2 (canary) 创建时间: 2026-03-10 ← 灰度中
└── v3.0 (draft) 创建时间: 2026-03-25 ← 开发中
每个版本的 Prompt 需要记录：完整内容、变更说明（类似 commit message）、关联的测试结果和评估指标、审批记录。支持版本间的 diff 对比，方便排查 Prompt 变更导致的质量问题。
工具配置热更新：Agent 使用的工具列表和工具的参数配置也需要支持热更新。比如某个外部 API 临时维护，需要从 Agent 的工具列表中移除；或者新增一个工具能力，需要让 Agent 能够使用。
配置的热更新通过配置中心的推送机制实现：配置变更后，配置中心通过长轮询或 WebSocket 通知所有相关的 Agent 运行时实例拉取最新配置。运行时收到新配置后，在下一次请求开始时生效——不影响正在执行中的会话。
一句话：调度层让平台从"跑一个 Agent"变成"管一群 Agent"——注册中心是基座，多租户隔离是底线，灰度发布是安全网。
5. 运行时层：隔离、状态与会话管理
运行时层是 Agent 实际执行的地方，解决的核心问题是：Agent 本身不可控（非确定性、可能超时、可能死循环、可能调用危险工具），但平台必须可控。运行时层需要在给 Agent 足够自由度的同时，确保平台的稳定性和安全性。
5.1 Agent 运行时模型
Agent 的运行时是一个循环执行引擎。简化来看，一次 Agent 执行的核心循环如下：
Agent 运行时核心循环：
while not done:
1. 构建上下文（对话历史 + 系统 Prompt + 可用工具）
2. 调用 LLM 推理
3. 解析 LLM 输出：
- 如果是最终回答 → done = True
- 如果是工具调用 → 执行工具 → 将结果加入上下文 → 继续循环
4. 检查终止条件：
- 达到最大轮次？
- 超出 Token 预算？
- 超时？
- 检测到死循环？
平台层的运行时需要对这个循环进行标准化封装，提供统一的生命周期钩子和控制机制。开发者只需要定义 Agent 的配置（Prompt、工具、参数），运行时负责执行循环、管理状态、处理异常。
运行时的部署粒度有几种选择：
进程级：多个 Agent 会话共享一个进程，通过协程或线程池隔离。资源利用率高，但一个会话的异常可能影响其他会话。适合轻量级 Agent 和成本敏感场景。
容器级：每种 Agent 运行在独立的容器中，共享该类型 Agent 的资源池。容器内多个会话通过协程隔离。这是最常见的方案，平衡了隔离性和资源效率。
Serverless：每次会话按需启动一个函数实例。隔离性最好，完全按使用付费，但冷启动延迟和状态管理是挑战。适合低频但对隔离要求高的场景。
5.2 会话（Session）管理
会话管理是运行时层的核心能力之一。一个 Agent 会话不是一次性的请求-响应，而是一个有状态的、可能持续很长时间的交互过程。
会话状态的持久化：会话状态包括对话历史、上下文变量、执行进度等。这些状态需要持久化到外部存储（Redis、数据库），因为运行时实例可能随时重启或迁移。
会话状态模型：
Session {
id: "sess_abc123"
agent_id: "agent-customer-support-v2"
tenant_id: "tenant-a"
status: "active" # active / paused / completed / expired / error
created_at: "2026-03-27T10:00:00Z"
last_active_at: "2026-03-27T10:15:00Z"
ttl: 3600 # 会话超时时间（秒）
# 对话历史
messages: [
{role: "system", content: "..."},
{role: "user", content: "我的订单什么时候到？"},
{role: "assistant", content: null, tool_calls: [{...}]},
{role: "tool", content: "{order_status: 'shipping'}"},
{role: "assistant", content: "您的订单已发货..."},
...
]
# 运行时上下文
context: {
turn_count: 3
total_tokens: 4521
tools_called: ["order-query"]
user_profile: {vip: true}
}
# 执行中状态（仅当会话正在执行时存在）
execution: {
current_turn: 4
started_at: "2026-03-27T10:15:30Z"
assigned_instance: "runtime-pod-07"
}
}
Session 亲和性：为了避免每次请求都从外部存储加载完整的会话状态，通常希望同一个会话的请求路由到同一个运行时实例。这称为 Session 亲和性。
实现方式有两种：在接入层的负载均衡器中配置基于 session_id 的一致性哈希路由；或者在调度层维护一张 session-to-instance 的映射表。前者简单但在实例扩缩容时会导致部分会话重新路由，后者更精确但引入了额外的元数据管理。
更稳健的设计是：将 Session 亲和性作为优化而非依赖——即使会话被路由到新实例，也能通过从外部存储加载状态来正常工作，只是会多一次存储访问的开销。
会话的生命周期管理：会话不能无限存活，需要超时回收机制。常见策略是：设置空闲超时（如 30 分钟无活动自动过期）和绝对超时（如创建后 24 小时强制过期）。过期的会话需要清理运行时状态和释放预留资源，但对话历史通常会保留更长时间（用于审计和分析）。
5.3 Context Window 管理
LLM 的 Context Window 有限（即使是最新的模型，有效利用的上下文长度也是有限的），而 Agent 的对话历史会随着轮次增加而不断增长。当对话历史超出 Context Window 时，Agent 的表现会急剧下降。Context Window 管理是运行时层必须解决的问题。
平台级的 Context Window 管理策略有几种：
滑动窗口：保留最近 N 轮对话，丢弃更早的。最简单但信息丢失最严重，适合上下文依赖较弱的场景（如独立问答）。
摘要压缩：当对话超过阈值时，用 LLM 对早期对话生成摘要，替换原始对话。信息保留较好，但摘要过程本身消耗 Token 和时间。
Context 管理示例（摘要压缩）：
原始对话（12轮，8000 tokens）：
[Turn 1] 用户问了订单状态
[Turn 2] Agent 查询了订单 API
[Turn 3] 用户追问物流详情
...
[Turn 12] 用户询问退款政策
压缩后（6轮，4000 tokens）：
[摘要] 用户 Alice 就订单 #12345 进行了多轮咨询，包括物流状态查询（已发货）、
修改收货地址（已确认不可修改）和发票需求（已发送到邮箱）。
[Turn 9-12] 保留原始对话
分层上下文：将上下文分为多个层次——系统级上下文（Prompt、工具定义）始终保留；会话级上下文（用户画像、业务状态）择要保留；对话级上下文（具体对话内容）按滑动窗口或摘要策略管理。
Token 预算分配：给定 Context Window 的总容量，平台需要合理分配给各部分：系统 Prompt 占比、工具定义占比、对话历史占比、生成回复预留占比。这个分配比例需要可配置。
Context Window Token 预算分配示例（以 128K 模型为例）：
┌─────────────────────────────────┐
│ System Prompt 8K │ 6.25%
├─────────────────────────────────┤
│ Tool Definitions 12K │ 9.4%
├─────────────────────────────────┤
│ Conversation History 80K │ 62.5%
│ ├── Summary of old turns │
│ └── Recent N turns (raw) │
├─────────────────────────────────┤
│ Current Input 8K │ 6.25%
├─────────────────────────────────┤
│ Reserved for Output 20K │ 15.6%
└─────────────────────────────────┘
平台应该提供统一的 Context Manager 组件，Agent 开发者通过配置选择策略和参数，不需要自己实现上下文管理逻辑。
5.4 工具执行沙箱
Agent 调用工具是平台安全的关键风险点。LLM 生成的工具调用参数是不可信的——可能包含注入攻击、越权访问、恶意代码。运行时层需要在 Agent 和工具之间设置安全边界。
参数校验：对 LLM 生成的工具调用参数进行严格的 Schema 校验——类型检查、值域检查、必填项检查。不符合 Schema 的调用直接拒绝，不传递给工具服务。
权限控制：每个 Agent 只能调用其声明的工具列表中的工具。即使 LLM 输出了调用其他工具的指令，运行时也应该拦截。不同租户的 Agent 可以有不同的工具权限。
代码执行沙箱：如果 Agent 具备代码执行能力（如代码解释器），代码必须在严格隔离的沙箱中运行——限制网络访问、文件系统访问、执行时间和内存占用。常见方案是用 gVisor 或 Firecracker 提供的轻量级虚拟化。
敏感操作审批：对于高风险的工具操作（如发送邮件、修改数据库、执行支付），平台可以提供人工审批机制——Agent 生成工具调用后，暂停执行，等待人工确认后再继续。
工具执行的安全流水线：
LLM 输出 tool_call
│
├── [1] 权限检查：该 Agent 是否有权调用此工具？
│ └── 否 → 拒绝，记录日志
│
├── [2] 参数校验：参数是否符合 Schema？
│ └── 否 → 拒绝，返回错误信息给 LLM
│
├── [3] 风险评估：是否为敏感操作？
│ └── 是 → 进入审批队列，等待人工确认
│
├── [4] 沙箱执行：在隔离环境中执行工具
│ └── 超时或资源超限 → 强制终止
│
└── [5] 结果过滤：检查工具返回是否包含敏感信息
└── 脱敏后返回给 Agent
5.5 超时与熔断机制
Agent 的非确定性使得超时和熔断设计比传统服务更为重要。没有适当的控制，一个失控的 Agent 可以在几分钟内消耗掉整个月的 Token 预算。
多层超时机制：
┌──────────────────────────────────────────────┐
│ 总执行超时 (如 5 分钟) │
│ ┌────────────────────────────────────────┐ │
│ │ 单轮超时 (如 30 秒/轮) │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ LLM 调用超时 (如 15 秒) │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ 工具执行超时 (如 10 秒) │ │ │
│ │ └──────────────────────────────────┘ │ │
│ └────────────────────────────────────────┘ │
│ │
│ 最大轮次限制 (如 10 轮) │
│ Token 预算上限 (如 50K tokens/次) │
└──────────────────────────────────────────────┘
死循环检测：Agent 可能陷入重复调用同一工具或重复相似思考的循环。运行时需要检测这种模式：如果连续 N 轮的工具调用序列高度相似（编辑距离小于阈值），或 LLM 输出内容的重复度超过阈值，触发干预——可以注入提示信息试图打破循环，或直接终止执行。
Token 预算熔断：设置单次执行的 Token 消耗上限。当累计消耗接近上限时发出预警，达到上限时强制终止。这是防止成本失控的最后防线。
级联熔断：当下游依赖（LLM 服务、工具服务）出现故障时，运行时应快速失败而不是无限重试。熔断器的设计参考 Circuit Breaker 模式，但阈值设置需要考虑 LLM 服务的特殊性——LLM 的偶尔慢响应是正常的，不应轻易触发熔断。
一句话：运行时层解决的核心问题是——Agent 不可控，但平台必须可控。沙箱、超时、熔断是给 Agent 自由的同时保住底线的三道防线。
6. 能力层：可复用的共享基础设施
能力层是平台复用性的核心。它提供所有 Agent 都需要的共享基础能力，避免每个 Agent 项目重复建设。能力层的设计原则是：对上提供统一抽象，屏蔽底层实现差异；对下适配多种实现，支持灵活替换。
6.1 LLM Gateway：统一模型路由
LLM Gateway 是能力层最核心的组件。它在 Agent 运行时和 LLM 供应商之间建立了一层抽象，提供统一的调用接口、智能路由、容错和成本管理。
统一接口抽象：不同 LLM 供应商（OpenAI、Anthropic、Google、本地模型）的 API 格式、参数命名、功能支持都不同。LLM Gateway 对上层提供统一的调用接口，屏蔽这些差异。Agent 开发者只需调用 llm.chat(model, messages, tools)，不需要关心底层走的是哪个供应商的 API。
Agent Runtime
│
│ 统一接口: llm.chat(model, messages, tools)
▼
┌─────────────────────────────────────────┐
│ LLM Gateway │
│ │
│ ┌─────────┐ ┌─────────┐ ┌────────┐ │
│ │ Router │ │ Limiter │ │ Cache │ │
│ └────┬────┘ └────┬────┘ └───┬────┘ │
│ │ │ │ │
│ ┌────▼────────────▼───────────▼────┐ │
│ │ Provider Adapters │ │
│ │ ┌───────┐ ┌───────┐ ┌───────┐ │ │
│ │ │OpenAI │ │Claude │ │ Local │ │ │
│ │ └───────┘ └───────┘ └───────┘ │ │
│ └──────────────────────────────────┘ │
└─────────────────────────────────────────┘
智能路由：根据请求特征（任务复杂度、Token 长度、延迟要求、成本预算）选择最合适的模型。比如简单问答路由到低成本模型（GPT-4o-mini），复杂推理任务路由到高能力模型（Claude Opus），代码生成路由到代码专长模型。路由策略可以基于规则，也可以基于历史数据的学习。
Fallback 策略：当主模型不可用或响应超时时，自动降级到备选模型。Fallback 链通常是：主模型 → 同级备选模型 → 低一级模型 → 错误响应。
Fallback 链示例：
Claude Opus (主选)
│ 超时/限流/错误
▼
GPT-4o (同级备选)
│ 超时/限流/错误
▼
Claude Sonnet (降级)
│ 超时/限流/错误
▼
返回错误 + 触发告警
语义缓存：对于相同或语义相似的请求，直接返回缓存结果，节省模型调用成本和时间。语义缓存基于 Embedding 相似度匹配，而非精确字符串匹配。实现方式是将请求的 Embedding 存入向量数据库，新请求来时先查相似度，超过阈值直接返回缓存结果。
语义缓存的适用场景有限——它只适合确定性较高、时效性要求不高的请求（如知识问答），不适合需要个性化响应或实时信息的场景。命中率和准确率需要持续监控，缓存错误的回答比不缓存更危险。
请求排队与优先级：当模型供应商的速率限制成为瓶颈时，LLM Gateway 需要维护请求队列，按优先级调度。高优先级租户的请求优先发出，低优先级请求排队等待。队列的设计要支持超时取消——排队超过一定时间的请求应该返回服务繁忙错误，而不是让用户无限等待。
6.2 Tool Service：工具注册与发现
Agent 的能力边界由其可用工具决定。Tool Service 是工具的注册中心和执行代理，负责工具的统一管理、发现和调用。
工具注册：每个工具以标准化的元数据格式注册，包括名称、描述、参数 Schema（JSON Schema）、返回值 Schema、权限要求和调用限制。
{
"tool_id": "tool://order-query",
"name": "query_order_status",
"description": "查询订单的当前状态和物流信息",
"parameters": {
"type": "object",
"properties": {
"order_id": {
"type": "string",
"pattern": "^ORD-[0-9]{10}$",
"description": "订单编号"
}
},
"required": ["order_id"]
},
"returns": {
"type": "object",
"properties": {
"status": {"type": "string", "enum": ["pending", "shipping", "delivered"]},
"tracking_number": {"type": "string"},
"estimated_delivery": {"type": "string", "format": "date"}
}
},
"auth": {
"type": "api_key",
"scopes": ["order:read"]
},
"rate_limit": {
"rpm": 100,
"burst": 20
}
}
工具发现：Agent 需要知道有哪些工具可用。工具的发现机制有两种：静态声明——Agent 配置中明确列出使用的工具；动态发现——Agent 根据任务需求从工具库中搜索合适的工具。动态发现更灵活，但也更复杂，需要工具描述的质量足够高，让 LLM 能准确理解工具用途。
MCP 协议集成：Model Context Protocol（MCP）是正在成为 Agent 工具调用的事实标准。Tool Service 应该支持 MCP 协议，使得外部工具供应商可以通过标准化协议接入平台。这极大地扩展了平台的工具生态。
工具调用的抽象与代理：Tool Service 作为中间层，将运行时对工具的调用转化为对实际后端服务的 API 调用。这一层可以添加统一的认证、限流、超时、重试、日志和监控。Agent 运行时不直接调用后端 API，而是通过 Tool Service 间接调用，降低耦合度。
6.3 Memory Store：记忆服务
记忆是 Agent 的核心能力之一，平台需要提供统一的记忆存储和管理服务。Agent 的记忆按时间范围和用途可分为三类：
工作记忆（Working Memory）：当前对话的上下文。存储在会话状态中，生命周期与会话一致。已在运行时层的 Session 管理中覆盖。
短期记忆（Short-term Memory）：跨会话但有时效的信息。比如用户的最近偏好、上次对话的摘要、最近执行的操作历史。通常存储在 Redis 中，设置合理的 TTL。
长期记忆（Long-term Memory）：持久化的知识和经验。比如用户画像、历史对话总结、Agent 学到的经验。存储在关系型数据库或向量数据库中，不自动过期。
记忆的三层架构：
┌─────────────────────────────────────────────┐
│ Agent Runtime │
│ │
│ Memory API: │
│ memory.get(key, scope) │
│ memory.set(key, value, ttl) │
│ memory.search(query, top_k) │
└──────┬─────────────┬──────────────┬─────────┘
│ │ │
┌────▼────┐ ┌─────▼─────┐ ┌────▼──────┐
│ Working │ │Short-term │ │ Long-term │
│ Memory │ │ Memory │ │ Memory │
│ │ │ │ │ │
│ Session │ │ Redis │ │ VectorDB │
│ State │ │ w/ TTL │ │ + RDBMS │
└─────────┘ └───────────┘ └───────────┘
向量化与检索：长期记忆的写入通常包括文本向量化（Embedding）和索引存入向量数据库。检索时通过语义搜索找到相关记忆。平台应提供统一的 Embedding 服务，避免各 Agent 各自调用 Embedding API。
跨 Agent 的知识共享：在某些场景下，不同 Agent 之间需要共享记忆。比如客服 Agent 查到的用户信息，技术支持 Agent 也应该能获取。这需要在 Memory Store 中支持不同的作用域——private（仅当前 Agent）、shared（指定 Agent 组共享）、global（全平台共享）。
记忆的生命周期管理：记忆不是越多越好。过时的记忆会误导 Agent，冗余的记忆会增加检索噪声。平台需要提供记忆的老化、归并和清理机制——定期评估记忆的使用频率和相关性，归档低频记忆，删除过时记忆。
6.4 Prompt 管理服务
Prompt 是 Agent 的"灵魂"，其管理的重要性前面已经强调。能力层的 Prompt 管理服务提供 Prompt 的全生命周期管理。
Prompt 模板与变量注入：生产环境的 Prompt 通常不是一段静态文本，而是包含动态变量的模板。比如：
你是 {{company_name}} 的客服助手。
当前用户: {{user_name}}，VIP等级: {{vip_level}}
可用工具: {{available_tools}}
当前时间: {{current_time}}
请遵循以下规则：
{{business_rules}}
Prompt 管理服务负责在运行时将模板与变量绑定，生成最终的 Prompt。变量可以来自多个来源——Agent 配置、租户配置、用户会话上下文、实时查询结果。
Prompt 的 A/B 测试：Prompt 的优化是一个持续的过程。平台应该支持对同一个 Agent 同时运行多个 Prompt 版本，按比例分配流量，比较各版本的效果指标（任务成功率、用户满意度、Token 消耗）。这本质上是 Prompt 级别的灰度发布。
Prompt 仓库：跨 Agent 的可复用 Prompt 片段（如通用的安全规则、输出格式要求、思考链模板）可以抽取到 Prompt 仓库中，通过引用而非复制来使用。修改仓库中的 Prompt 片段可以影响所有引用它的 Agent。
6.5 Embedding 与检索服务
向量化和检索是多个能力（长期记忆、RAG、语义缓存）的共同底层依赖。平台应该提供统一的 Embedding & Retrieval 服务，避免各 Agent 重复建设。
统一向量化接口：屏蔽不同 Embedding 模型的差异（OpenAI text-embedding-3-small、BGE、E5 等），提供统一的 embed(text) → vector 接口。支持批量向量化，做好请求合并和限流。
多索引管理：不同 Agent 和不同用途（记忆检索、知识检索、缓存匹配）可能需要独立的向量索引。服务应支持多索引的创建、更新和删除，以及跨索引的联合检索。
检索质量优化：平台级的检索优化包括：Reranking（对粗检索结果进行精排）、Hybrid Search（向量检索 + 关键词检索的混合）、Metadata Filtering（基于元数据的预过滤），这些通用能力由平台统一提供，Agent 开发者通过参数配置即可使用。
一句话：能力层是平台复用性的核心——每个 Agent 不应该重复造 LLM 调用、工具管理、记忆存储和 Prompt 管理的轮子。
7. 多 Agent 协作与编排
当平台上运行多个 Agent 时，它们之间常常需要协作完成复杂任务。多 Agent 协作的基础设施是平台架构中容易被忽视但日益重要的部分。
7.1 协作模式
Agent 之间的协作有几种典型模式：
委托模式（Delegation）：一个主 Agent 将子任务委托给专门的子 Agent。比如一个"全能客服 Agent"将退款问题委托给"退款专员 Agent"，将技术问题委托给"技术支持 Agent"。
主 Agent（路由/分发）
│
├──→ 退款 Agent（处理退款相关问题）
├──→ 物流 Agent（处理物流相关问题）
└──→ 技术 Agent（处理技术相关问题）
流水线模式（Pipeline）：多个 Agent 按顺序处理，每个 Agent 处理一个阶段。比如"信息收集 Agent"→"分析 Agent"→"报告生成 Agent"。
讨论模式（Discussion）：多个 Agent 以对话方式协作，各自提供不同视角，最终达成共识。比如"乐观分析师 Agent"和"风险评估 Agent"共同评估一个投资方案。
7.2 协作基础设施
平台层需要提供几个基础设施来支撑多 Agent 协作：
消息总线：Agent 之间的通信通道。可以是同步的（RPC 调用）或异步的（消息队列）。同步方式延迟低但耦合度高；异步方式解耦但增加了状态管理的复杂度。
对于委托模式，同步调用通常足够；对于流水线和讨论模式，异步消息队列更合适——每个 Agent 从队列中消费消息，处理完后将结果发到下一个 Agent 的队列。
值得关注的是，Agent 间通信的标准化正在发生。Google 提出的 A2A（Agent-to-Agent）协议试图为 Agent 之间的发现、认证和通信定义统一的标准——类似 MCP 之于工具调用，A2A 之于 Agent 间协作。A2A 定义了 Agent Card（描述 Agent 能力的元数据）、Task（跨 Agent 的任务生命周期管理）和 Message（Agent 间的消息格式）等核心概念。虽然 A2A 目前仍处于早期阶段，生态尚不成熟，但在设计消息总线时预留对标准协议的扩展接口是值得的——当标准成熟时可以低成本接入，而不需要重新设计通信层。
上下文传递：协作的 Agent 之间需要共享上下文信息。平台需要定义标准化的上下文传递协议——哪些信息需要传递（用户输入、中间结果、元数据），哪些信息需要过滤（减少无关信息对下游 Agent 的干扰），传递的格式和编码方式。
上下文传递模型：
SharedContext {
// 全局信息，所有参与 Agent 可见
global: {
task_id: "task_001"
user_id: "user_abc"
original_query: "帮我分析一下上季度的销售数据"
deadline: "2026-03-27T12:00:00Z"
}
// 累积结果，上游 Agent 的输出
results: [
{agent: "data-collector", output: {...}, tokens_used: 1200},
{agent: "data-analyzer", output: {...}, tokens_used: 3400},
]
// 当前 Agent 的私有上下文
private: {
agent_specific_config: {...}
}
}
编排引擎：对于复杂的多 Agent 协作流程，需要一个编排引擎来定义和执行协作逻辑。编排方式有两种：
静态编排（DAG）：协作流程在开发时定义为一个有向无环图，每个节点是一个 Agent，边定义了数据流向和条件分支。类似工作流引擎（如 Temporal、Airflow），但节点是 Agent 而非函数。适合流程确定的场景。
动态编排：由一个"编排 Agent"在运行时根据任务需求动态决定调用哪些 Agent、以什么顺序、传递什么上下文。更灵活但更难控制和预测。
两种方式各有适用场景，平台应该同时支持。实践中，大多数场景从静态编排开始，在少数需要高灵活性的场景引入动态编排。
以静态编排为例，一个基于 DAG 的编排配置可能如下（类似 Temporal Workflow 的声明方式）：
# 多 Agent 协作编排配置示例
workflow:
id: "quarterly-report-generation"
name: "季度报告生成"
timeout: 600s
token_budget: 200000
steps:
- id: "collect"
agent: "agent-data-collector"
input:
query: "{{user_query}}"
data_sources: ["sales_db", "crm"]
timeout: 120s
on_failure: "abort"
- id: "analyze"
agent: "agent-data-analyzer"
depends_on: ["collect"]
input:
raw_data: "{{steps.collect.output}}"
analysis_type: "trend"
timeout: 180s
on_failure: "retry"
retry: {max_attempts: 2, backoff: "exponential"}
- id: "visualize"
agent: "agent-chart-generator"
depends_on: ["analyze"]
input:
analysis_result: "{{steps.analyze.output}}"
timeout: 60s
- id: "write"
agent: "agent-report-writer"
depends_on: ["analyze", "visualize"] # 等待分析和图表都完成
input:
analysis: "{{steps.analyze.output}}"
charts: "{{steps.visualize.output}}"
template: "prompt://report-template/v2"
timeout: 120s
而动态编排的核心是一个"编排 Agent"，它接收用户任务后，自主决定调用哪些 Agent 以及调用顺序。其决策流程大致如下：
编排 Agent 的决策循环：
1. 接收用户任务描述
2. 查询 Agent Registry，获取可用 Agent 列表及其能力描述
3. 调用 LLM 制定执行计划：
→ "这个任务需要先用 data-collector 收集数据，
然后用 data-analyzer 分析，最后用 report-writer 生成报告"
4. 按计划依次调用子 Agent，传递上下文
5. 每步完成后评估：
- 结果是否符合预期？→ 继续下一步
- 结果有缺失？→ 补充调用或修改计划
- 遇到异常？→ 决定重试、跳过或终止
6. 所有步骤完成后，汇总结果返回用户
动态编排的灵活性更强，但对编排 Agent 的推理能力要求很高，且执行路径不可预测——Token 消耗、耗时、调用的 Agent 数量都由 LLM 在运行时决定。因此在生产环境中使用动态编排时，必须配合严格的 Token 预算、轮次上限和超时控制。
7.3 协作的治理
多 Agent 协作引入了额外的治理需求：
Token 预算分配：一个协作任务的 Token 总预算如何在参与的多个 Agent 之间分配？可以预先分配（每个 Agent 固定预算），也可以动态分配（共享预算池，先到先得但有上限）。
超时与故障处理：上游 Agent 超时了怎么办？是等待、重试、跳过还是终止整个流程？需要在编排层定义 Agent 级别的超时和异常处理策略。
调用链追踪：多 Agent 协作的调用链比单 Agent 更长更复杂。Trace 需要能清晰展示 Agent 之间的调用关系、数据流向和时间分布，便于排障。
一句话：多 Agent 协作的基础设施本质上是一个工作流引擎——但节点是非确定性的 Agent 而非确定性的函数，这让编排、预算和容错都变得更复杂。
8. 上篇小结
本篇从全景架构出发，深入分析了 Agent 基础架构平台的四大核心层设计：
接入层解决"怎么把请求接进来"——流式响应、长连接管理和 Token 维度的流量治理是核心挑战。
调度层解决"怎么管一群 Agent"——Agent 注册中心、多租户隔离、生命周期管理和灰度发布构成了平台化管理的基础。
运行时层解决"怎么安全可控地执行"——会话管理、Context Window 管理、工具执行沙箱和超时熔断确保了在 Agent 非确定性行为下的平台稳定性。
能力层解决"怎么避免重复造轮子"——LLM Gateway、Tool Service、Memory Store 和 Prompt 管理服务为所有 Agent 提供可复用的共享能力。
在这之上，多 Agent 协作与编排的基础设施为复杂场景提供了支撑。
但架构设计只是故事的一半。一个平台真正能在生产环境中跑起来，还需要解决弹性伸缩、可观测性、安全治理、测试保障和持续演进等问题。这些将在下篇中详细展开。
下篇：《Agent 基础架构平台（下）：从可观测到规模化运营》——弹性伸缩与 GPU 调度、分布式追踪与 Agent 级监控指标体系、安全治理与合规审计、测试与质量保障、数据层架构、开发者体验以及从 MVP 到成熟平台的演进路径。