当 Agent 系统只有一个 Spring Boot 服务时线程、数据库事务和本地异常处理已经能够解决许多问题。随着任务执行、知识检索、模型调用和工具服务逐渐独立部署原本位于一个进程内部的方法调用会转化为网络通信。网络具有延迟和失败的不确定性服务也可能独立扩容、重启或暂时不可用因此系统需要额外处理服务定位、故障传播、重复执行以及运行状态诊断。本篇集中说明这些进入生产环境后最常见的工程概念。目录一、服务发现、网关与远程调用二、超时、重试、熔断与并发限制三、幂等、任务状态与最终一致性四、日志、指标与链路追踪一、服务发现、网关与远程调用1. 微服务微服务是一种将应用按照相对独立的业务能力拆分为多个可独立部署服务的软件架构方式。一个早期 Agent 项目完全可以把用户接口、任务执行、RAG 检索和模型调用放在同一个应用中。当模型调用和检索服务开始具有不同的资源需求、发布周期或扩缩容方式时才可能逐步拆分为task-service、retrieval-service、model-service等独立服务。微服务拆分本身会增加通信和运维成本因此服务边界通常应来源于真实的业务与资源差异而不是简单按照代码目录拆分。2. 服务发现服务独立部署以后首先需要解决实例定位问题。服务发现是指调用方根据逻辑服务名称动态获得当前可用服务实例地址的机制。例如model-service可能同时运行三个实例每次重新部署后 IP 地址都可能变化。调用方如果直接把地址写入代码就需要随着实例变化持续修改配置。Nacos 等注册中心允许服务启动时登记自身地址调用方再根据model-service这个稳定名称获取当前健康实例。服务发现因此解决的是内部服务之间“当前应该调用谁”的问题。3. API 网关API 网关解决的是外部请求入口问题。客户端通常只访问一个统一域名再由网关根据路径、请求头或其他条件将请求转发给不同内部服务。例如/api/tasks/**可以进入任务服务/api/users/**可以进入用户服务。网关还适合集中处理跨服务通用逻辑例如基础身份认证、访问日志、跨域处理和入口限流。具体业务权限仍需要下游服务再次校验因为通过网关完成身份认证只表示“知道调用者是谁”并不能自动证明调用者有权访问某一条业务数据。可以将二者的职责放在同一条通信链中理解客户端通过网关进入系统内部服务再通过服务发现找到目标实例。对 Agent 开发而言这一结构很常见因为任务服务、模型服务和工具服务通常拥有不同的运行特征。初学阶段掌握这一层关系已经足够无需同时深入注册中心选举、网关底层 Reactor 模型等内部实现。二、超时、重试、熔断与并发限制1. 超时超时是指调用方为一次远程请求设置最大等待时间当连接建立或响应读取超过限定时间以后主动结束等待。缺少超时控制时一个已经失去响应的模型服务可能长期占用调用线程和网络连接随着异常请求不断积累上游服务最终也会出现资源耗尽。因此任何外部 HTTP、RPC、数据库或模型调用都应存在明确的时间边界。2. 重试重试是指一次调用失败以后重新发起有限次数的尝试。它适合处理具有短暂恢复可能性的错误例如瞬时网络抖动、连接重置或者部分临时限流。对于参数错误、权限不足、业务校验失败等确定性错误重复执行通常不会改变结果。生产系统中的重试还需要控制次数并配合退避策略逐渐延长等待时间避免下游服务已经出现故障时上游大量请求立即重复发送而进一步增加压力。3. 熔断当某个依赖已经持续失败时熔断器会暂时停止真实调用并让请求快速返回失败或降级结果。它通常根据一段时间内的失败率或慢调用比例判断下游是否处于异常状态达到阈值以后进入打开状态经过等待时间后再允许少量请求探测服务是否恢复。超时、重试和熔断解决的是不同层次的问题超时限定单次请求等待时间重试处理少量临时失败熔断阻止持续故障继续向上游传播。这三者经常共同出现但每一项都需要独立设置合理参数。Agent 系统还必须处理容量限制。模型 API、数据库连接和搜索服务都具有明确并发上限即使 Java 应用自身还能创建更多线程也不能无限制把请求压向下游。线程数量决定应用能够同时推进多少任务限流与并发额度决定下游实际允许进入多少任务。两者共同使用才能避免“应用自身没有崩溃但下游已经被压垮”的情况。三、幂等、任务状态与最终一致性1. 幂等幂等性是分布式后端中非常重要的可靠性概念。它表示同一个业务操作执行一次或重复执行多次最终产生的业务状态保持一致。网络环境中经常出现一种情况服务端已经成功创建任务但返回结果途中连接断开客户端因此认为请求失败并再次提交。如果系统没有幂等控制两次请求就可能创建两个完全相同的任务。常见做法是给每次业务请求分配唯一的requestId或幂等键服务端处理前先检查这个编号是否已经成功执行。幂等与重试必须结合考虑。查询操作通常天然适合重复执行而创建任务、扣减额度、支付和发送通知都可能产生副作用因此需要保存操作状态或执行结果。对于 Agent Workflow同一个模型调用甚至可能非常昂贵如果任务恢复后简单重新执行全部步骤会增加费用并产生重复外部操作。任务系统因此通常需要保存每个关键步骤已经完成到什么位置使重试能够从正确状态继续而不是无条件重新开始整个流程。2. 任务状态与最终一致性服务进一步拆分以后一次任务可能同时涉及多个独立系统。例如任务服务先写入任务记录额度服务完成额度预占随后向消息队列发送执行消息。传统数据库事务只能覆盖单个数据源很难直接保证这些跨服务操作在同一个 ACID 事务中完成。最终一致性允许系统短时间存在中间状态再通过可靠消息、重试、状态检查和补偿操作最终恢复到满足业务约束的状态。例如任务已经创建而消息发送失败时可以将任务标记为WAITING_MESSAGE后台程序继续尝试发送如果最终取消任务则释放此前预占的额度。这类设计与 Agent 的 Checkpoint、Durable Execution 具有直接联系。一个持续几十秒甚至数分钟的 Agent 任务不适合长期占用一个数据库事务更合理的方式是不断保存阶段性状态例如CREATED、RETRIEVING、MODEL_RUNNING、TOOL_RUNNING、COMPLETED和FAILED。服务发生重启以后系统仍然能够根据状态判断任务执行到了哪里并决定继续执行、重试还是补偿。因而幂等保证重复执行不会破坏业务状态状态持久化记录执行位置最终一致性负责跨服务恢复这三者共同构成长任务可靠性的基础。四、日志、指标与链路追踪可观测性是指通过系统主动暴露的运行数据理解内部状态并据此定位性能问题和故障原因的能力。现代后端通常使用日志、指标和链路追踪三类信号。日志记录离散事件例如某个任务在哪一步发生了模型超时指标把大量事件聚合成可持续观察的数值例如一分钟任务成功率、P95 延迟、队列长度和当前模型并发数链路追踪则描述一次请求在多个服务之间经过了哪些步骤以及每一个步骤分别消耗多少时间。这三类数据具有不同用途。假设用户反馈任务1001执行失败日志可以告诉开发者具体异常内容指标可以判断这是单个任务问题还是整个模型服务的失败率都在升高链路追踪则可以显示请求经过 Gateway、Task Service、Retrieval Service 和 Model Service 后究竟在哪个阶段发生异常。Agent 系统的执行步骤通常比普通 CRUD 请求更长因此在日志中保留traceId、taskId、执行步骤、耗时、状态和错误类型十分重要。涉及 Prompt、访问令牌和用户数据时还需要进行脱敏不能为了排障直接记录所有原始输入。OpenTelemetry 提供了统一生成和传播 traces、metrics 与 logs 相关上下文的标准化方案。一次请求进入网关以后可以生成或接收traceId随后通过 HTTP Header、消息属性继续传递到任务服务、模型服务和工具服务。这样即使一次 Agent 执行跨越多个线程、多个进程甚至消息队列仍然能够在观测平台中恢复完整调用关系。这也解释了为什么上一部分介绍的ThreadLocal只能解决进程内问题跨服务链路需要额外的上下文传播机制。当服务部署到 Docker 和 Kubernetes 环境以后可观测性还需要与运行平台结合。Kubernetes 的就绪探针用于判断实例是否能够开始接收流量存活探针用于判断应用是否已经进入需要重启的异常状态资源限制则防止单个服务无限占用节点 CPU 和内存。可以将整个生产运行关系概括为日志和 Trace 提供故障证据指标反映系统趋势健康检查帮助平台判断实例状态容器编排负责根据状态进行调度和恢复。对 Agent 后端而言这些能力决定了系统能否从“能够完成一次模型调用”进一步发展为可持续运行的服务。