Agent基础架构平台

当多个业务开始共用模型、工具和记忆系统，重复建设的问题会逐渐变得具体：同一份凭据散落在几个项目里，调用失败后不知道是否已经计费，一个团队的长任务挤占另一个团队的容量，旧会话又在发布后读到了新配置。

Agent 平台的价值，是把这些共享约束变成可执行的契约。 业务仍然负责目标、领域规则和结果质量，平台负责身份、版本、任务状态、资源分配与执行证据。前十二篇讨论的运行时、记忆、协作和评估能力，到这里需要统一管理，但不必全部拆成独立服务。

本文沿用订单调查场景：用户要求解释订单状态，Agent 查询支付与履约记录，必要时等待人工补充信息。它涉及长任务、多工具和敏感数据，足以说明平台要解决的关键问题。

哪些能力值得沉淀到平台

微服务平台已有的身份认证、队列、持久化、配置管理和链路追踪仍然有用。传统系统也有长流程、并行分支和非确定性外部依赖，不能把它们简化为短时、无状态的线性调用。

Agent 带来的变化，是这些约束以新的组合出现：

是否平台化，要看重复需求和治理成本。两个团队反复实现同一套凭据与预算控制，可能已经值得抽取；一百个低频、相互独立的脚本，也不意味着必须建设完整平台。

用五类职责组织架构

下面的分层描述职责归属，箭头表示主要调用方向。状态存储、权限检查和观测贯穿其中，不是只有最下层才处理安全。

接入层确认调用者身份和请求格式，返回任务标识；调度层选择已发布的 Agent 版本并安排运行；运行时推进步骤、保存检查点、处理取消和等待；能力层提供模型、工具、检索与记忆的统一接口；基础设施层承载数据、计算和密钥。小规模部署可以把前四类职责放在同一个应用中，接口清晰比服务数量更重要。

一次运行应固定 Agent、Prompt、工具契约和模型配置的版本。注册中心保存这些定义及其发布状态，运行实例的存活与容量由调度系统管理。不能因为新版本已发布，就在旧运行的下一步悄悄替换它所依赖的工具语义。

长任务如何跨连接继续运行

一次 HTTP 请求可以提交任务并立即获得 run_id，后续通过查询、SSE 或 WebSocket 观察进度。交互式回答适合流式输出，批量任务则可以只提供状态查询和结果下载，不必强制所有入口保持长连接。

这里要区分三个标识：

• request_id：一次接口请求，用于定位接入失败与重试
• run_id：一次任务执行，包含多个模型和工具步骤
• session_id：一组交互的上下文，可能包含多次运行

以 SSE 为例，断线重连需要服务端保存带序号的事件，并按客户端最后确认的位置重放。只有 Last-Event-ID 字段，没有事件存储和访问校验，并不能恢复任务。客户端消费太慢时，可限制缓冲、合并进度事件或中断订阅；暂停读取上游网络不等于停止模型推理，也不保证停止计费。

运行权同样需要管理。采用租约或其他互斥机制时，旧执行者失去租约后必须停止提交新步骤；关键持久写入还需要版本或 fencing 校验，避免新旧执行者同时修改状态。外部动作另有幂等键和核验接口，不能靠检查点回滚已发送的申请。

会话粘性可以减少迁移成本，但不是持久化的替代品。只有内存状态的进程退出后，即使负载均衡器仍记得原实例，也恢复不了任务。

配额控制先统一口径，再处理并发

模型服务的 RPM、TPM，租户的月度金额预算，以及运行时的并发上限，分别约束请求速率、token 用量、支出和同时占用的资源。它们不能互相替代，更不能用“本月尚未超额”来代替本次调用的准入判断。

金额预算至少需要三个量：额度 limit、已结算支出 spent、在途预留 reserved。准入条件是：

spent + reserved + 本次预留 <= limit

例如额度为 100 元，已支出 80 元、在途预留 15 元，新调用需要预留 8 元，就应拒绝或排队。只检查 80 小于 100，会放进无法覆盖的任务。

下面是事务语义的伪代码，用于说明一致性要求，不是可直接接入数据库的实现：

reserve(operation_id, account, period, amount, payload_hash):
    在同一个持久事务中：
        按固定顺序锁定本次涉及的预算账户与账期
        若 operation_id 已存在：
            核对账户、账期、金额与 payload_hash 一致
            返回原记录，不重复预留
        验证 amount 非负且所有账户都配置了有效额度
        对每个账户检查 spent + reserved + amount <= limit
        同时增加 reserved，并写入唯一的预留记录
    提交成功后才允许发送对应调用

settle(operation_id, actual_amount, settlement_id):
    在同一个持久事务中：
        锁定预留记录及其原账期账户
        若已结算，校验结算标识与金额后返回原结果
        释放该记录的预留额，增加实际支出
        保存唯一的结算结果

账期在预留时固定，跨月完成的调用不能随意扣到新月份。重试必须复用同一业务操作标识，结算也必须幂等。实际费用超过预留时，应如实入账、记录超额并限制后续调用，不能截断账单来维持“预算未超”的表象。

预留金额只有在对应服务提供可约束的最大用量、价格和附加费用时，才可能形成足够可靠的上界。普通估算用于控制风险，不能承诺绝不超支。网络超时后的调用若可能已经执行或计费，应保留待核验状态，通过供应商用量与业务记录对账；不能立即释放后再次发起，造成重复支出。

Redis 脚本可以原子更新同一 Redis 执行范围内的计数，但不能把 Redis 操作和另一个数据库的写入自动合成事务。选择单一账本作为一致性来源，再将速率计数、缓存和账单对账围绕它组织，比两个存储各自扣一次更容易解释和恢复。Redis 脚本原子性说明

多层预算还要解决租户、团队和用户账户的一致准入。若这些账户不在同一事务范围内，需要明确协调与补偿协议，不能将上面的本地事务伪代码直接当成跨分片实现。

共享模型能力如何保持业务语义

LLM Gateway 适合统一凭据、请求转换、路由、用量记录和错误分类。它提供稳定的业务接口，但不同模型的输入结构、工具调用方式和能力并不因此完全相同。

路由先筛选满足任务要求的候选：数据可发送范围、上下文容量、工具与结构化输出能力、延迟目标和预算。再根据同一评测集上的结果选择主路径与候选降级路径。

降级需要明确哪些错误允许重试：

每次尝试单独记录用量，降级链还要有总次数、总时限和总成本约束。换供应商不能突破数据发送范围，换 API Key 也不是绕过供应商额度的办法。

缓存首先适合确定性高、权限与时效边界清楚的查询。缓存键需包含租户、授权范围、输入、模型与 Prompt 版本，以及相关数据版本或失效条件。订单状态查询若命中旧内容，就可能给出错误解释；相似问题的向量距离再近，也不能证明订单、用户和权限相同。语义缓存应有独立的正确性评估，不以一个通用相似度阈值承诺可复用。

工具、记忆与执行环境如何隔离

Tool Service 应把参数验证、资源级授权和业务执行放在可信边界内。运行时只把本次允许的工具暴露给模型，工具服务仍需再次核验实际调用者与目标资源。订单查询返回数据前应确认该用户可访问这张订单，不能只验证租户字段存在。

工具按影响安排不同执行环境：受控查询接口、需要出网的浏览器、执行生成代码的沙箱，不必共享同一个凭据与文件系统。线程和协程不提供独立进程的内存隔离；容器、虚拟机和远程托管运行各有边界，应结合实际威胁与运行约束选择。“Serverless”描述服务交付方式，本身不能证明具有什么隔离强度。

记忆系统也需要权限过滤、来源、版本、保留期限与删除机制。单 Agent 面向多个用户时同样需要隔离。更换 embedding 模型后，应重建或明确分离索引，在一致口径上评测召回质量，不能把不同模型的相似度分数直接混排。

删除当前索引中的记录不等于所有副本已删除；还需处理缓存、源文件、日志和备份的保留策略。这里的复杂度来自数据生命周期，而不是向量数据库的名称。

扩容必须对准实际瓶颈

Agent 进程等待模型响应时，CPU 可能很低，却占用了连接、内存、任务槽位和供应商并发额度。另一些任务执行代码、渲染网页或处理媒体，CPU 和内存仍可能是主要瓶颈。因此扩缩容应观察排队时长、活跃运行数、内存、连接数和工具池容量，并保留 CPU 等基础指标。

Kubernetes HPA 可以使用自定义或外部指标。增加 Pod 之前，要确认下游配额与工具容量是否支持；供应商 TPM 已耗尽时，增加工作进程只会增加竞争。缩容需要停止接收新任务并交接或等待现有运行，不能直接丢弃正在执行的步骤。Kubernetes HPA 文档

自托管模型的容量取决于权重精度、上下文长度、KV Cache、并发、批处理和运行时开销，不能仅按参数量给出固定显存配置。GPU 共享方案也要区分：MIG 在支持的设备与 profile 下划分硬件资源，MPS 协调多个进程共享 GPU 执行，不能把两者写成同一种任意比例切卡能力。NVIDIA MIG、MPS

是否自托管，比较的是目标质量与延迟下的总成本：实例、闲置容量、运维、升级、容灾与工程投入都要计入。不存在脱离模型与负载条件的统一月 token 分界线，也不应先承诺固定节省比例，再寻找论据。

平台如何证明自己改善了运行

一次订单调查的 Trace 可以包含并行查询、重试、模型调用与等待事件。传统分布式追踪同样能表达分支；需要补充的是 Agent 版本、模型尝试、工具参数摘要、token 用量、审批和任务结果等语义。

任务总耗时按实际时间线或关键路径分析，不能把并行 Span 的耗时全部相加。跨异步运行可以使用关联标识与 Span Link 保留关系。采样 Trace 用于诊断，完整计费账本和必要审计记录则独立保证，不能依赖采样碰巧留下证据。

观测系统需要回答三组问题：任务是否完成，执行为何失败，资源花在何处。原始提示词与工具结果可能含敏感信息，应按需要脱敏、限制读取与保留；只保存摘要时，也要承认其对故障复现的限制。

平台效果最终体现在业务接入与运行结果中：接入一个新工具减少了哪些重复工作，同类任务的完成率和延迟如何变化，超额调用是否得到控制，故障能否定位到具体步骤。比较时固定任务分布、版本和统计口径，避免把业务变简单误写成平台变强。

从最小闭环演进，而不是一次建齐

第一阶段先统一身份、凭据、任务标识、必要日志和预算上限，让首个业务能够受控运行。权限与成本控制从这里就开始。

第二阶段在多个业务出现真实复用需求后，抽取模型网关、工具注册和版本发布能力。第三阶段根据长任务与故障恢复需求，完善持久运行、配额账本和调度隔离。之后再根据实际规模建设自助接入、容量规划和跨区域治理，而不是按 Agent 数量机械决定阶段。

每一次抽取都应减少业务团队必须自行处理的共性问题。若新增平台接口反而要求团队重复描述同一份权限、修补同样的恢复逻辑，说明职责边界还没有划清。平台建设的长期收益，来自这些边界稳定、证据可追溯，并能随着业务变化继续扩展。